跳到主要内容

单次正确成本,而非 Token 成本:账单不会告诉你的单位指标

· 阅读需 13 分钟
Tian Pan
Software Engineer

我认识的一个团队在上个季度通过将支持邮件分类流程从顶级模型(frontier model)迁移到中级模型,将推理费用降低了 40%。CFO 还专门发了感谢信。六个月后,客户支持团队增加了两名全职员工(FTE),平均解决时间上升了 35%。没有人把这些点联系起来,因为这些“点”分布在不同的仪表盘上:推理费用在平台团队的仪表盘上,而支持工作量在运营团队的仪表盘上。在所有人都在追踪的唯一指标上,这次迁移看起来是一次胜利。但指标错了。

这就是“单 Token 成本”(cost-per-token)陷阱。你的账单告诉你花了多少钱在 Token 上,但它无法告诉你每个“正确”任务花了多少钱,因为推理供应商根本不知道在你的领域里什么是“正确”。他们卖给你的是原始算力。而你买的是结果——或者你以为你买的是结果。这两个单位之间的差距,就是 AI 单元经济(unit economics)悄然崩溃的地方。如果不去衡量正确的分母,团队就只算了一半的账,而在另一半的交付上处于盲目状态。

当分母缺失时,分子在撒谎

单 Token 成本是一个很清爽的数字。供应商在账单上提供给你,你可以跨请求进行汇总,并逐月绘制图表。它看起来像是一个单元成本。但它不是。它是总成本(gross cost)——以原始推理尝试次数为单位,而不是以完成的工作为单位。

对于 AI 功能,正确的衡量单位是“每个完成且正确的任务所花费的美元”。一旦你写下这个分数,Token 账单从未显现的两种动态就会浮现:

  • 一个需要重试三次才能得出可接受答案的廉价模型,实际上并便宜。它产生的是三份每百万 Token 的账单而不是一份,外加三倍的往返延迟,以及三次用户放弃流程的机会。
  • 一个能一次性完成任务的高价模型,实际上并昂贵。一份账单。一次往返。你虽然在 Token 上支付了“溢价”,但通过吞吐量、重试预算以及减少的客户投诉单赚了回来。

行业分析已经开始意识到这一点。最近对生产环境中 LLM 成本的分析指出,真正的成本公式是乘法性的——基础 Token 数 × 缓存倍数 × 批处理倍数 × 推理倍数 × 重试倍数。仅仅是静默重试(silent retries),在用户流量没有任何变化的情况下,就能让 Token 使用量翻 2 到 5 倍。只关注表面费率的团队看到的是一条平滑的线。而关注每个任务成本的团队看到的则是一个正在悄悄消耗三倍资源的功能。

为什么供应商无法提供这个数字

供应商知道他们提供了多少 Token。但他们不知道哪些 Token 在你的领域产生了正确的答案。他们无法知道。正确性是由你的评测集(eval set)定义的——包括黄金数据集(gold dataset)、评分标准(rubric),以及判断“这次分类是否将邮件路由到了正确的队列”或“这次代码审查是否抓住了预期的 bug”的人工或 LLM 裁判。这些资产存在于你的代码库中,而不是他们的。

这就是为什么“正确率成本”(cost-per-correctness)从根本上来说是一个你必须自己构建的指标。没有哪个 SaaS 仪表盘会直接把它交给你。这项工作的流程如下:

  1. 单次请求推理支出,通过请求 ID 关联到
  2. 单次请求评分结果,评分来自你的评测流水线(人工审核、校准了人工标准的 LLM 评判、确定性检查或混合模式)
  3. 按功能汇总,这样你就可以计算:“本周这个 AI 功能花费了 X,并产生了Y个评分正确的任务,因此X,并产生了 Y 个评分正确的任务,因此 X/Y 就是单元成本。”

这项底层工作并不光鲜。它需要将历史上属于两个不同团队的数据流进行合并:平台团队负责推理日志,评测团队负责评分结果。想要得到正确数字的团队必须让这两股数据流交汇。而不愿这么做的团队将继续优化账单上提供的数字——而那个数字是错的。

看起来像是一次胜利的迁移

“迁移到更廉价的层级并看着账单下降”是目前行业内最常见的 AI 降本动作。如果不追踪正确率成本,这种做法也最容易导致质量悄然下降。其病理过程如下:

  • 第一季度:一个功能在顶级模型上发布。Token 支出很高。财务部门发出了警示。
  • 第二季度:平台团队将该功能迁移到更廉价的模型。可见的推理账单下降了 40%。工程团队写了一篇庆祝贴。
  • 第三季度:由 AI 路由的路径,其支持请求量开始呈上升趋势。工单描述很模糊——“机器人没帮上忙”、“它给了我错误的答案”。找不到单一的根本原因。
  • 第四季度:支持团队扩招。受 AI 服务的用户群体的客户满意度(CSAT)下降。该细分市场的留存率走软。
  • 第五季度:一份独立的分析(通常由一名没有先入为主观念的新员工完成)将支持请求的激增与之前的迁移联系了起来。一旦算入支持成本、流失成本和品牌损失,之前的“节省”被证明实际上是负收益。

这种情况不断发生的结构性原因是:推理成本的节省是显而易见的,以美元计价,并直接体现在一个团队的仪表盘上。而质量的倒退是分散的,以支持工时和流失率计价,并分布在另外三个团队的仪表盘上。除非有人构建了“正确率成本”指标,否则组织内就没有工具能将它们联系起来。只有这时,之前的迁移才会在追溯中显现为该指标上的倒退。

必须确立的思维转变是:将功能降级到更廉价的模型层级不是一个单纯的成本决策。它是一个“质量-成本”的权衡,必须在设计阶段就将其定价。 有时廉价层级确实没问题,评测证实了这一点,节省是真实的。有时廉价层级会导致正确率下降 8 个百分点,后果由支持团队承担,而节省只是幻觉。评测是唯一能在实验于生产环境上线之前,告诉你属于哪种情况的手段。

建立单任务成本分类账

具体而言,需要落地的规范是:

单任务成本分类账。 每一个推理调用(inference call)都会被标记一个任务 ID —— 即用户真正关心的工作单位。一个“任务”取决于你的产品定义:可以是完成一封邮件分类、一次代码审查,或是一次客户查询的解决。一个任务可能跨越多个模型调用(检索、生成、验证、重试)。分类账汇总该任务中所有调用的支出,并与该任务经评估(eval)评定的结果相关联。单位成本是根据成功的任务来计算的,而不是总请求量。

路由决策框架。 当平台团队提议进行层级迁移(tier migration)时,提议中应包含评估增量(eval delta),而不仅仅是成本增量。一次节省了单任务 0.003 美元但将正确率从 94% 降低到 86% 的迁移,应被记录为质量决策,而非成本胜利。这种权衡在设计阶段就应明确,并在功能的单次正确成本发生变化时重新审核。

财务伙伴关系模型。 FP&A 团队将“单次正确成本”视为与“单 Token 成本”同等重要的一级指标。前者反映在客户流失率、支持工单和续订率上;后者反映在发票上。如果财务团队只看发票,他们会不断批准那些看起来在省钱、实则产生了财务团队在自身数据中无法看到的隐藏成本的迁移方案。

季度审查中,单次正确成本的上升应触发评估刷新,而非迁移到更便宜的模型。 如果单位成本在爬升,问题不应该是“我们能换个更小的模型吗?”,而应该是“评估指标是否仍然在衡量正确的东西?任务分布是否发生了偏移?提示词(prompt)是否早就该调整了?”迁移到更便宜的模型应该是最后的手段,而非首选。

这听起来像是额外的开销。它确实是开销 —— 但正是这种开销,区分了是将 AI 功能当作“产品”运营的团队,还是将其当作“已上线的 Demo”运营的团队。

单次正确成本揭示了单 Token 成本无法看到的问题

一旦建立了分类账,它就能揭示出在 Token 账单上无法察觉的权衡:

  • 重试经济学。 一个在低置信度输出时进行重试的工作流,其单次请求成本可能比不重试的工作流更高。但如果开启重试的工作流正确率为 96%,而不重试的版本仅为 78%,那么其“单次正确成本”会显著降低。Token 账单让重试显得昂贵,而单位成本则揭示了它才是更经济的选择。
  • 缓存与新鲜调用决策。 一个语义缓存(semantically cached)的响应如果只有 90% 的效果,虽然 Token 成本很低,但在高风险路径上,其正确性可能会明显变差。没有单次正确成本指标的团队会不断提高缓存命中率,将其视为省钱的胜利;而拥有该指标的团队则能看到正确性的底线,并知道在哪里止步。
  • 顶级模型的 ROI。 尖端模型的“单 Token 成本”更贵。但如果它能消除重试、减轻人工审核负担并减少下游支持压力,它的“单次正确任务成本”反而可能更低。如果没有单位成本指标,使用顶级模型看起来像是一种奢侈;有了它,它可能是处理高风险任务最高效的选择。
  • 提示词变更归因。 一个在 Token 支出上“看起来差不多”的提示词修订,可能会让正确率上下波动 5–10 个百分点。单次正确成本能在下一次分类账运行中捕捉到这种退化,而 Token 支出则会永久掩盖它。

其规律是:AI 系统中的每一个架构选择都是质量与成本的权衡。Token 账单只为这一权衡的一半定价,评估(eval)为另一半定价。将两者相乘或相除,得到的单位成本是唯一能同时涵盖两者的数字。

何时可以跳过(以及何时不能跳过)

并非每个 AI 功能在第一天都需要单次正确成本分类账。仅由 30 名员工使用的内部工具,仅靠 Token 支出指标就足够了 —— 糟糕输出的支持成本受限于愿意提交工单的人数,而这个数字通常很小。没有评估的临时原型还不需要分母,因为分子部分还配不上工程投入。

单次正确成本变得至关重要(load-bearing)的分界线在于:

  • 该功能服务于终端客户(不仅仅是员工)。质量退化会体现为用户流失,而你无法在推理账单上看到流失。
  • 规模足够大,以至于 Token 支出已成为董事会级别的数字。 一旦财务部门开始询问,你的答案就需要一个正确的分母,否则下个季度的优化行动将会误入歧途。
  • 正在认真考虑更便宜的备选方案。 这是建立单次正确成本指标的最关键时刻。无论有没有这个指标,迁移决策都会产生 —— 最好还是有。
  • 任务具有你可以生成的质量评分。 如果你已经有了评估,你就有了原始素材。如果你还没有评估,请在建立分类账之前先建立评估;没有评估的分类账只是一张更好看的 Token 账单。

架构层面的觉醒

AI 单位经济效益是一个“以成本为分子、以评估结果为分母”的评分问题。仅衡量分子的团队并不是在衡量单位经济效益 —— 他们在衡量推理运维(inference operations),这是恰好以相同货币计价的另一回事。这两者很容易混淆,而且一旦在一个季度内基于错误的指标做出了大量决策,就很难修正。

及早意识到这一点的团队会获得一种奇特的“超能力”:他们可以自信地在推理账单该增长时让其增长,该缩减时让其缩减,因为他们确信每一步行动对于他们真正关心的单位指标都是正确的。即使 Token 支出随流量波动,他们的单次正确成本依然保持稳定或处于下降趋势。他们的迁移能够平稳落地,因为评估增量已预先定价。他们的财务团队信任他们,因为单位成本与业务结果挂钩,而不是挂钩在一个除了平台团队外没人理解的计数器上。

而没有意识到这一点的团队,会在接下来的两年里优化错误的数字,然后在第三年进行流失分析,将损失追溯到那些所谓的“降本胜利”后,再花时间去拆解这些优化。到那时,廉价的迁移方案已经固化在架构中,扭转局面的成本将远超最初“节省”下来的费用。

你从推理供应商那里拿到的发票并不是你的 AI 成本。它只是你 AI 成本的一个输入。另一个输入是你的评估报告。在你将这两个数据流合并之前,账单上的数字虽然精确、有面值、可审计,但却在唯一关键的维度上是不完整的。

References:Let's stay in touch and Follow me for more thoughts and updates