跳到主要内容

成本看板不是财务报表,而是产品决策工具

· 阅读需 5 分钟
一介布衣
全栈开发者 / 技术写作者

补档说明:本文属于「AI 工程落地周记」系列,计划发布时间为 2025-09-10 09:10。当前先保留为草稿,后续补充真实案例、代码片段和复盘细节后再发布。

很多团队把 AI 成本看板做成了另一种账单页面:

  • 本月花了多少钱
  • 各供应商占比多少
  • 同比上月涨了还是跌了

这些数字不是没用,但如果成本看板只能回答财务问题,它对产品和工程团队的帮助会非常有限。因为真正要做决策的人,通常更关心另外一些问题:

  • 哪条业务链路最贵
  • 贵是因为用户变多了,还是因为系统变胖了
  • 哪个实验让成本突然上升
  • 哪类请求根本不值得走强模型

所以我现在越来越不把成本看板当“财务报表”,而把它看成一块产品控制面板。

财务视角和产品视角关注的不是同一件事

财务更关心

  • 月度总花费
  • 预算执行率
  • 供应商结算口径

产品和工程更关心

  • 某个功能的单位成功成本
  • 某次改版是否让 token 暴涨
  • 回退到强模型的比例是不是失控
  • 缓存命中率下降是不是正在抬高总账单

如果你的看板回答不了这些问题,它就很难指导版本取舍。

一个真正有用的成本看板,应该能支持这些判断

1. 这笔钱花在哪条业务链路上

不要只按模型或供应商聚合,要按 route 看:

  • 问答
  • 审核
  • 摘要
  • 路由决策
  • 内容生成

因为真正要做取舍时,团队通常不是在问“OpenAI 贵不贵”,而是在问“哪条产品能力现在最烧钱、最值得优化”。

2. 这笔钱换来了什么结果

我很少只看 cost / request,更看重:

  • cost / successful_request
  • cost / resolved_ticket
  • cost / published_article

也就是说,成本指标最好跟一个真实产出挂钩。
否则你只知道系统在烧钱,不知道钱花得值不值。

3. 成本变化是由什么驱动的

这点很关键。
成本上涨,背后可能完全是不同原因:

  • 用户量变多
  • Prompt 变长
  • 检索上下文变厚
  • 强模型 fallback 变多
  • 重试率上升
  • 缓存命中率下降

如果看板不把这些拆开,团队就只能靠猜。

我现在最常留的几个字段

现在做请求级成本日志,我几乎都会保留这些字段:

{
"route": "content_review",
"model": "gpt-x",
"promptVersion": "v12",
"inputTokens": 3821,
"outputTokens": 412,
"retryCount": 1,
"fallbackModel": "gpt-x-large",
"cacheHit": false,
"toolCostUsd": 0.002,
"llmCostUsd": 0.031,
"status": "success"
}

这些字段的价值在于,你后面不只是能算总账,还能按:

  • route
  • 模型
  • Prompt 版本
  • fallback 路径
  • 成功/失败状态

去切片分析。

一个我很看重的指标:单位成功成本

AI 产品里最误导人的一种情况是:某版本平均请求成本下降了,但成功率也降了。
这时如果只看平均成本,你会误以为系统更高效了。

所以我更喜欢看这种指标:

单位成功成本 = 总成本 / 成功完成的业务数

这样你才能发现:

  • 虽然单次调用便宜了
  • 但由于失败重试和人工补救变多
  • 最终完成一个业务目标的成本其实更高

看板最好能直接支持“改哪一层”的动作

一个有用的成本看板,不该只让你焦虑,而应该让你知道下一步怎么动手。

例如看到:

  • inputTokens 暴涨 说明要查上下文拼装和检索策略
  • fallbackRate 暴涨 说明要查路由阈值和解析失败原因
  • retryCount 暴涨 说明要查超时、幂等和错误分类
  • cacheHit 暴跌 说明要查缓存 key 或缓存层设计

这时看板已经不是报告工具,而是诊断工具。

我不太喜欢只按供应商维度展示首页

不是说供应商维度不重要,而是它太容易把问题描述成“采购问题”。
但很多 AI 成本膨胀根本不是供应商涨价,而是系统设计自己变胖了。

所以如果只能选首页第一层视图,我更愿意按下面的顺序展示:

  1. 业务链路
  2. 实验版本
  3. 路由与 fallback
  4. 模型/供应商

这样看板更接近产品和工程的决策顺序。

总结

成本看板不是财务报表,而是产品决策工具。它最有价值的地方,不是帮你知道“总共花了多少钱”,而是帮你知道“钱是在哪一层、以什么方式、为了什么结果被花出去的”。

只有当成本被拆回到业务链路、版本实验、失败路径和成功结果里,团队才真正有能力做出聪明的优化,而不是只在月底对着一张更大的账单发愁。