当廉价模型变得更昂贵时
财务团队指出,本季度的 LLM 账单上涨了 18%。一名工程师调出使用情况仪表板,发现 70% 的流量现在流向了经济型模型(budget model)而非前沿模型(frontier model),他感到有些困惑:路由更改本应是为了削减开支。每 token 价格确实如电子表格预测的那样下降了。但账单还是上涨了。
这不是计费错误。这是成本优化在悄无声息中发生逆转的最常见方式。证明降级合理的电子表格衡量的是一件事——token——而生产系统支付的是完全不同的另一件事:完成的任务。较弱的模型不仅仅是产生更便宜的 token。它还会改变其周围每个组件的行为,而这些二阶效应最终都会反映在同一张发票上。
这个陷阱非常诱人,因为一阶数学逻辑确实是正确的。经济型模型的每 token 价格可能比前沿模型便宜 10 到 30 倍,且对于大部分流量,它返回的答案在质量上是难以区分的。错误不在于路由决策。错误在于在错误的边界衡量路由决策。
每 Token 成本是错误的衡量单位
每个模型比较页面都会引用每百万 token 的美元成本。这是一个错误的除数。你的用户买的不是 token;他们买的是已解决的请求。仪表板上显示的数字应该是每个成功任务的成本——即在每次尝试、重试、回退(fallback)和工具调用中的总支出,除以最终得到可用答案的请求数量。
这两个数字的偏差会迅速扩大。考虑一个分类步骤:前沿模型每次调用成本为 3 美分,成功率为 95%。经济型模型每次调用成本为 1 美分,成功率为 75%。按每 token 计算,经济型模型显然更胜一筹。但按成功次数计算,前沿模型每个解决任务的成本约为 3.2 美分,而经济型模型约为 1.3 美分——虽然仍然便宜,但差距已从 3 倍缩小到大约 2.5 倍,这还没算上那 25% 失败请求后续的处理成本。
这些失败并不会凭空消失。它们会重试、回退、上报给人工处理,或者输出一个错误的答案,由下游的某人去捕获。这些结果中的每一个都有代价,而这些代价都不会出现在每 token 的比较中。一个每调用价格极低但成功率仅为 60% 的模型,在每个成功任务上的成本通常高于一个价格高出三倍但成功率为 95% 的模型。头条数据告诉你的结论恰恰相反。
如果你的可观测性堆栈只报告按模型划分的 token 和成本,却无法报告按解决任务划分的成本,那么你就是在依赖一个最可能出错的指标进行决策。
重试和回退是隐藏的账单项
最大的放大器是重试。较弱的模型更经常无法通过结构化输出验证——格式错误的 JSON 对象、缺失的必填字段、它自创的枚举值。大多数生产系统会自动响应:重新运行调用。每一次重试都是一次完整的推理过程,整个提示词(prompt)会再次发送。在实践中,无声的重试可能在用户流量完全没变的情况下,将 token 使用量增加 2 到 5 倍。
这种成本在设计上是隐形的。重试发生在系统内部,仪表板按模型聚合 token,额外的支出被归因于“经济型模型”,就好像它是正常负载一样。没有人看到标有“由降级引起的重试”的账单项。他们看到经济型模型的 token 数量攀升,便认为该功能只是得到了更多使用。
回退链(Fallback chains)隐藏了一个更极端的版本。一个构建良好的系统会先路由到廉价模型,验证输出,失败后再升级到前沿模型。这是正确的工程实践——但这意味着每一次失败的经济型模型调用都会让你付出双倍代价:一次是为了那个没起作用的廉价尝试,再加上那次成功的前沿模型调用的全价。将 70% 的流量路由到失败率为 20% 的经济型模型,意味着 14% 的总流量现在要支付两次费用。经济型层级不再是一个你可以推导的成本中心,而变成了对前沿层级征收的一种税收。
解决方法不是取消重试或回退,而是将它们的成本归因于导致它们的路由决策。 为每一次重试和每一次回退打上触发它的模型标签,这样经济型模型在每个任务上的真实成本就不会再隐藏在聚合的 token 计数中了。
提示词长度税
较弱的模型很少会失败到足以触发验证器的程度。更常见的情况是它会微妙地退化——答案更模糊、遗漏边界情况、语气略有偏差——团队的本能反应是在提示词中进行补偿。增加两个 few-shot 示例。详细说明模型一直遗漏的三个边界情况。附加一段更长的关于格式的系统指令。
这些增加的每一项都是每一条请求上永久的输入成本。这就是提示词长度税:经济型模型需要更厚重的提示词才能达到前沿模型仅凭精简提示词就能达到的质量标准。关于过度提示(over-prompting)的研究清晰地展示了这种模式——token 成本随增加的每个示例呈线性增长,而准确率的增益在最初几个示例之后就开始趋于平缓。你支付得越来越多,挽回的损失却越来越少。
在请求层面计算一下账。假设降级在原始生成上为每次调用节省了 1.5 美分,但为了支撑起经济型模型,每次请求都需要额外增加 800 token 的示例和指令。按经济型模型的输入费率计算,这可能只有几分钱,所以这笔交易看起来仍然不错——直到你记起,这个膨胀的提示词也是每次重试时重新发送的内容,也是带入每次回退的内容。提示词长度税和重试放大器会相互叠加。更厚重的提示词让每次重试更昂贵,而更弱的模型让重试更频繁。
还有上下文窗口(context-window)的成本。示例占用了实际任务输入所需的空间。在窗口较小的模型上,长文档加上足以建立模式的 few-shot 示例可能根本装不下,从而被迫进行截断或分块——而这又是失败的新来源和新一轮调用的开始。
工作并不会消失——它发生了转移
当一个模型变得更弱时,它曾经承担的工作并不会凭空消失。它会转移到系统中最薄弱的地方,而这些地方的单位成本通常比模型本身要高得多。
工作转移到了下游工具。前沿模型可能只需一次尝试就能解决模糊的请求;而低成本模型则需要发起三次工具调用来获取本可以推断出的上下文,且每次调用都有其自身的延迟,通常还有独立的计费成本。
工作转移到了人工审核。这是目前为止最昂贵的去处。工程师高昂的工时费让任何 Token 账单都显得微不足道。如果模型降级导致哪怕只有一小部分流量从“自动解决”变为“需要人工查看”,人力成本就会抵消所有的 Token 节省,甚至更多。总体拥有成本(Total cost of ownership)——即真实的数字——包括了故障响应、工程师诊断质量下降所耗费的工时,以及不断增长的审核队列。那些只追踪 API 支出的团队通常会发现,他们的实际消耗是预估值的两到三倍。
工作转移到了用户身上。将下降的质量转嫁给提问者是最廉价的做法——更模糊的回答、重复提问、被放弃的会话。这部分成本永远不会出现在你的发票上。它影响的是留存率,而你会在一个季度后才发现这一点。
基本原则是:模型降级并不会减少工作量,而是重新定价了工作。而且它几乎总是调高了价格,因为模型曾是系统中成本最低的劳动力。工作流向的所有环节——重试、工具、人工——其计费标准都更高。
在任务边界测量,而非调用边界
防止这一切的准则是:**模型路由的变更是一项系统级变更,在发布之前需要进行端到端的成本评估。**而不是简单的每 Token 成本对比。这种评估需要将具有代表性的真实流量样本同时跑在旧路径和新路径上,直到得出最终结果,并报告每条路径的四个指标:
- 每个成功任务的成本 (Cost per successful task) —— 包括重试和降级方案在内的总支出,除以最终可用的任务数。
- 成功率 (Success rate) —— 无需升级(escalation)即可解决的任务比例,由生产环境使用的同一套评估门控来测量。
- 重试与降级率 (Retry and fallback rate) —— 低成本路径触发第二次尝试或升级到前沿模型的频率。
- 有效提示词规模 (Effective prompt size) —— 实际发送的输入 Token,包括为了支撑模型表现而增加的任何示例(Few-shot)。
运行这些评估,这种“反向优化”会在财务团队发现之前暴露出来。你会发现有时低成本模型确实能完胜——这正是路由的意义所在,在简单、高频且边界清晰的任务中,它确实有效。但你也会看到,一旦计入重试和降级,它有时会输。无论哪种结果,你交付的是基于测量的决策,而不是猜测。
这也重新定义了路由层本身。路由器是一个决定每个请求走“廉价”还是“昂贵”路径的分类器,而错误路由是一种独特的失败模式——它不是模型错误,而是路由错误——聚合成本仪表盘对这种错误在结构上是盲目的。路由器值得拥有自己的回归测试集和评估切片,因为一个过于激进的路由器会产生一种 看起来像成功的症状:低成本模型的使用率很高,但紧随其后的是不断攀升的账单。
总结
低成本模型并不是谎言。它是一个真实的杠杆,在合适的流量上,它能实现电子表格中所承诺的成本削减。谎言在于电子表格中的单位。每 Token 成本(Cost per token)衡量的是没人买的东西;而每个成功任务的成本(Cost per successful task)衡量的才是你实际交付的东西。
在下次降级之前,请先对任务边界进行埋点。将每一次重试和降级都归因于导致它们的路由决策。计算你为了补偿模型能力而增加的提示词 Token。观察被挤出的工作量落在了哪里。然后端到端地运行这两条路径,比较那个唯一重要的数字。
做到这一点,路由才会成为它应有的成本利器。否则,你将不断发布那些看起来 Token 成本为零、却在一个季度后带来谁也解释不清的巨额账单的降级版本。
- https://www.codeant.ai/blogs/cheap-llm-models
- https://www.codeant.ai/blogs/why-token-pricing-misleads-llm-buyers
- https://www.codeant.ai/blogs/llm-production-costs
- https://inferbase.ai/blog/hidden-costs-of-llm-apis
- https://www.braintrust.dev/articles/how-ai-observability-helps-lower-llm-cost-at-scale
- https://www.ptolemay.com/post/llm-total-cost-of-ownership
- https://blog.logrocket.com/llm-routing-right-model-for-requests/
- https://arxiv.org/html/2509.13196v1
- https://divyam.ai/blog/hidden-cost-of-llmflation/
