小模型，大账单：为什么单 Token 成本更低反而更贵

由财务主导的“切换到更小模型”的指令，是让你的 LLM 账单季度环比增长最可靠的方式之一。采购团队盯着的仪表盘——单次调用成本、每次请求的平均 token 数——一直在下降。与此同时，发票金额却在不断攀升。当有人终于把这两者对上账时，团队已经花了六个月的时间进行提示词（prompt）迭代，以补偿那个在任务处理上表现更差的模型，而且团队已经陷得太深，如果不承认最初的切换是个错误，就无法走回头路。

错误不在于定价，而在于计量单位。当推理深度、重试次数和提示词大小都随模型而异时，单 token 价格是一个具有误导性的维度。正确的指标是“单次成功完成所需的 token 数”，在这个维度上，更便宜的模型往往会输。

每个人都会算错的算术

天真的算法是这样的：模型 A 每百万输入 token 的成本是 10 美元，模型 B 是 1.50 美元，所以从 A 切换到 B 应该能减少大约 85% 的 LLM 支出。首席财务官（CFO）喜欢这张 PPT。展示这张 PPT 的工程师也喜欢它。供应商网站上的模型介绍页面也支持这一点。

但这张 PPT 没算进去的成本包括：

• 重试率。能力较弱的模型出错频率更高。其中一部分失败是明显的（JSON 无法解析、函数调用签名格式错误、正则表达式评估器拒绝输出），并会触发自动重试。每次重试都会按新模型的价格产生一笔完整的请求费用——包括输入 token、输出 token 以及任何推理 token。
• 为补偿而导致的提示词膨胀。较弱的指令遵循能力会被更多的示例、更多的“你必须”、更明确的约束以及更长的系统提示词所掩盖。突然之间，每次调用的输入 token 数量变成了大模型的 3 倍。
• 更长的思维链。推理模型会产生中间 token，这些 token 不会出现在最终响应中，但会出现在账单上。较小的推理模型往往比大模型需要更多的“思考”token 才能得出相同的结论，有时甚至多出一个数量级。推理模型每次请求可以生成 10–30 倍的思考 token，而且这个比例并不会随着模型尺寸的减小而线性下降。
• 发布给用户的隐性失败。上述重试是可见的失败。隐性失败是指那些通过了 schema 验证、在日志中看起来正常，但给出的答案质量较差的情况。这些失败不会出现在成本仪表盘上，而是体现在用户流失、支持工单以及没人能解释的 NPS（净推荐值）下降中。

综上所述，在更小的模型上完成每个成功任务的总成本，可能会超过在更大模型上完成相同任务的成本。计量单位应该是“任务”，而不是“调用”。

会欺骗你的仪表盘

这个陷阱之所以难以察觉，是因为单次调用成本确实在下降。单 token 成本在下降。根据仪表盘的聚合方式，每次调用的 token 数有时也会下降。这些数字都没错——它们只是测量了错误的东西。

你真正想要在仪表盘上看到的是按任务类型分层的 “单次成功结果成本”。为了计算它，你需要三样大多数团队并不具备的东西：

1. 每个调用类型的成功定义。不是“模型返回了 200”。而是类似于“提取的地址可解析、类别标签在允许范围内、代理的工具调用在第一次尝试时就成功了”。
2. 重试计数器。大多数 LLM 客户端库会在 SDK 内部默默处理重试，只报告最终的可计费使用量。你必须进行显式埋点：为任务范围内的每一次调用增加 attempts 计数，然后计算 cost_per_success = total_billed_cost / count(successful_tasks)。
3. 运行在部分生产流量样本上的评判模型或基于规则的分级器。这是捕捉 schema 检查漏掉的隐性失败的关键。如果没有它，你唯一的信号就是用户投诉，而这对于一个本应是实时的指标来说，反馈周期长达数周。

一旦这三点连接起来，小模型上的“单次任务成本”往往会讲述一个与“单 token 成本”完全不同的故事。有时它确实更便宜——那就好，发布吧。有时两者持平。而有时它是大模型成本的 2 倍，在这种情况下，最初的采购决策单从纯单元经济效益来看就已经是在亏钱了，更不用说质量问题。

严谨的比较框架

如果你正在评估切换模型，必须在真实工作负载上进行端到端的比较。规格表对比或简单的五次提示词“凭感觉”检查比没有对比更糟糕，因为它们会让你对错误的答案产生极高的信心。

一个可行的方法框架如下：

• 校准样本工作负载。从生产环境中提取分层样本——按任务类型、按用户群体、按难度（如果你能标记的话）。几百个任务通常足以看出成本形态；几千个任务则足以看出质量的长尾效应。
• 端到端运行每个候选模型。相同的提示词脚手架、相同的重试策略、相同的输出验证器。不要让一个模型在为另一个模型优化的提示词下接受评估——那是干扰变量，而不是对比。
• 在多维度上评分。单次任务价格、单次任务延迟、重试率、验证器通过率、评判模型质量率。单一维度的价格对比会丢失关键信息。
• 分解账单。输入 token、输出 token、推理 token、重试开销。如果小模型在输入上赢了但在推理上输了，这就是关于你工作负载的真实情况——也许你可以在这项任务中完全避免推理模式，也许不能，但不进行分解你就无从得知。
• 使权衡明确化。“为了将重试率降低 4%，我们接受单次任务价格增加 1.3 倍”是一个合理的决策。“我们切换到了更便宜的模型”则不是，因为它忽略了决定账单的五个维度中的三个。

关于模型路由（model-routing）的文献在两年前就提出了类似的观点：问题往往不在于选择哪一个模型，而在于如何将查询路由到正确的模型。级联路由（cascade-routing）方法——先尝试便宜的模型，在置信度低时再升级——已被证明能以约四分之一的成本在某些基准测试中达到前沿模型 97% 的准确率。这之所以有效，是因为级联路由在进行采购决策没能做到的“单次任务核算”——仅在便宜模型无法完成任务时才升级，仅在任务需要时才支付昂贵模型费用。

云实例类比

LLM 定价正面临着与十年前云实例定价相同的陷阱。廉价实例类型每小时的价格总是更低，这是一个不争的事实。但账单依然上涨了，因为工作负载与实例不匹配——较小的实例发生抖动，处理任务耗时更长，在负载均衡器后需要更多实例，最终消耗的总实例小时数比单个大型实例还要多。

业界花了数年时间才内化这一规律：每小时价格是成本等式的输入，而不是答案。正确的单位是每个已完成任务的成本，或在给定 P99 延迟下处理每个请求的成本，或者是工作负载所支撑的每美元收入。一旦团队开始以这些单位思考，“始终选择廉价实例”的直觉就被针对特定工作负载的实例选择所取代——FinOps 也随之成为一门学科。

LLM 的成本现状也是如此。每 Token 价格是等式的输入。你真正关心的单位是每个成功任务的成本，或者每美元产品价值的成本，或者每个留存用户的成本。将每 Token 价格视为答案，与将每小时实例价格视为答案属于同类范畴错误。这会导致决策在幻灯片上看起来很聪明，但在账单上却在亏钱。

本季度该做什么

以下是一些能迅速产生回报的举措：

• 针对你排名前三的任务类型，监测“每次成功完成消耗的 Token 数”。这是你可以交付的杠杆率最高的可观测性改进。没有它，每一个模型决策都是在盲目进行。
• 审计财务团队正在查看的仪表板。 如果这些仪表板显示的是“单次调用成本”和“每 Token 成本”而非“每个任务的成本”，那么下一次由采购驱动的模型切换将基于错误的维度。在下一次季度评估之前，把正确的数字摆在他们面前。
• 重新评估过去一年中做出的任何“切换到更便宜模型”的决策。 对比你之前的模型和当前模型，运行校准后的工作负载。有时最初的切换是正确的，但有时并非如此，团队可能一直在默默地通过重试和提示词膨胀来消化成本。
• 停止仅凭单一数字对比模型。 任何只有单一价格列的模型选择备忘录都是错误的。增加重试率、在留存测试集上的质量以及每个任务的推理 Token 数等列，对话会立即发生改变。

在 LLM 单位经济效益上获胜的团队并不是那些使用最便宜模型的团队。他们是那些衡量正确指标的团队，并且深知“便宜”的选择仅仅是在一个无关紧要的指标上显得便宜而已。