Token 预算是变相的人员编制决策

最近我交流的一个团队花了三个工程师周的时间，将平均 Prompt 从 4,000 Token 削减到了 2,600 Token。他们以此为荣 —— 纯 35% 的降幅，实打实的数据，幻灯片里漂亮的图表。然后有人反向算了一笔账：这笔节省每月大约为 1,800 美元。而他们投入的三个工程师周，折算成全额薪酬成本大约是 25,000 美元。按照这个月度消耗率，这笔优化大约需要 14 个月才能回本 —— 这还是假设 Prompt 永远不变、模型永远不降价，且那些工程师没有更有价值的东西可做的情况下。

然而，这些假设一个都没成立。下个季度 Prompt 改了两次。他们使用的模型本身就降价了 40%。而那些工程师那个月没能发布的特性，恰恰是最大客户一直询问的功能。

这就是隐藏在每个 Token 预算背后的陷阱。我们将 Prompt 大小视为成本（COGS）问题 —— Token 越少，账单越低，显而易见的好事。但你支付给供应商的账单几乎从来都不是最昂贵的部分。昂贵的部分是你为了追求降本而消耗的工程师时间，是当你为了精简 Prompt 而导致质量下降时产生的支持压力，以及为了省那几分钱而引入的基础设施复杂性。Token 预算看起来像是推理发票上的一行字，但它实际上是披着成本优化外衣的人员配置决策。

没人会写在 PPT 里的比例

首先来看一个能重构一切认知的数字：对于大多数软件组织，云和基础设施支出占技术总成本的 20–30%。工程师薪水占另外 70%。一位 CTO 可以将每月 6 万美元的 AWS 账单削减到 4 万美元，同时每月支付 20 万美元的工程师薪酬 —— 正如一位 FinOps 作家所言，这就像是在死盯着买菜账单，却忽略了房贷。

LLM 推理是基础设施支出的一个新项目，它继承了同样失衡的经济逻辑。你的 Token 支出是真实且变动的，它显示在仪表盘上，让你感到紧迫。但盯着那个仪表盘的人，其成本是仪表盘最惨淡月份的 3 到 4 倍。他们每花一小时优化 Token，成本就是 80–150 美元（全额薪酬），而这只是为了减少一个结构上比他们薪水小得多的数字。

这并不意味着 Token 优化永远不值得。它意味着优化是否值得，取决于两个几乎从未同时出现的变量：你每月节省的金额，以及你为了节省这些钱而消耗的工程师工时。大多数团队虔诚地追踪前者，却完全不理会后者。所以优化看起来总是“免费”的，因为成本是从一份没有人去对账的预算 —— 工资单 —— 中扣除的。

你实际支出的三项成本

当你决定给 Prompt 多少 Token 预算时，你买的不只是推理服务。你实际上是同时在三个账户里进行隐形采购，而其中只有一个会出现在发票上。

• 推理费用 (Inference dollars)。显而易见的一项。输入 Token 乘以输入价格，输出 Token 乘以输出价格，在旗舰模型上，输出通常比输入贵 4–5 倍。这随流量线性增长，最容易预测。
• 工程师时间 (Engineer time)。缩减 Prompt 的成本，以及至关重要的一点 —— 保持精简 的成本。精简的 Prompt 更脆弱。它应对下一个边界情况的余地更小，因此每个新需求都意味着要在更紧张的 Token 预算下重新调整、重新评估和重新测试。这项成本是持续且隐形的。
• 支持和质量压力 (Support and quality load)。当你削减 Token 时，你通常会削减上下文、示例或护栏 (Guardrails)。有时质量能撑住，但有时它会以某种方式退化，并在两周后表现为支持工单、糟糕的输出，以及原本该被该功能取悦的客户产生的信任问题。这项成本落在了另一个团队的预算里，这正是它在决策时被忽视的原因。

错误并不在于花掉其中任何一笔钱，而是在没有衡量其他支出的情况下只花其中一笔。如果削减 35% 的 Token 会带来持续的评估负担和缓慢流失的质量投诉，那么即使推理成本曲线在下降，最终结果也极有可能是负向的。

什么时候这种交换显而易见是值得的

有一种清晰的类别，Token 优化几乎等于白捡钱，它有一个定义性特征：工程师成本接近于零或是一次性的，而节省则是永久持续的。

Prompt 缓存 (Prompt caching) 是最典型的例子。两大主流供应商现在对缓存输入读取的计费大约是标准费率的 10% —— 相当于缓存部分打了 1 折。对于在每次调用中重复使用大量静态系统提示词的 Agent 或聊天产品，将该提示词组织成稳定的缓存前缀，可以在实际应用中削减 70–90% 的输入成本。工程工作通常只是对构建 Prompt 的方式进行一次性结构调整，有时甚至什么都不用做，因为供应商侧的缓存会在超过 Token 阈值时自动触发。一次性成本，永久节省，且无损质量。这种事每次都该做。

同样的逻辑也适用于其他几个杠杆：

• 结构化输出 (Structured outputs)。要求根据 Schema 输出 JSON 会同时约束内容和长度。响应会变得更短且更易解析，因此你既节省了 Token，又减少了下游的解析代码。成本只需编写一次 Schema。
• 针对简单流量的廉价模型路由 (Cheap model routing for easy traffic)。如果请求中有相当一部分是琐碎的，将其路由到更小的模型只需要更改配置，就能获得巨大的持续回报。陷阱在于“相当一部分”这个词 —— 详见下文。
• 清理死掉的上下文 (Killing dead context)。不再发挥作用的少样本示例 (Few-shot examples)、重复了三次的指令、没人看的检索片段。删除这些纯属利好；Prompt 变得更便宜，通常还会变得更好，因为模型在处理臃肿上下文时注意力会下降。

统一的测试标准是：如果优化是结构性且一次性的，那就去做。你只需支付一次工程师成本，并将其分摊到未来的每一次调用中。而在我开头例子中让那个团队栽跟头的计算，只有在工程师成本是 持续性 的时候才会出错 —— 也就是当你需要对每次更改进行手动微调、盯着评估数据并反复测试的时候。

当权衡在悄悄亏钱时

亏损的权衡往往呈现出相反的形态：持续投入的工程精力所追求的节省，远小于投入本身，而且往往将成本转移到了你看不到的预算项中。

最明显的例子是在低调用量下的单条提示词（prompt）手动优化。如果一条提示词每月只触发几千次，每月的总支出可能也就几百美元。没有任何优化值得让一名资深工程师花上一周时间去应对一个 300 美元的支出项。但团队还是会这样做，因为 Token 数量是可见的，而工程师的时间成本并没有计入同一个账本。

更隐蔽的陷阱是激进减支带来的评估税（evaluation tax）。要判断一个更便宜的模型或更精简的提示词是否“足够好”，你必须为每项任务定义“足够好”，构建评估系统（evals），收集代表性数据，并进行对比。这是真正的工程工作，却不交付任何功能。跳过它，你就是在盲飞——你削减了 Token，质量却在默默下降，而支持队列（support queue）吸收了由此产生的差额。如果操作得当，你可能会发现评估基础设施的成本，比它所保护的多年节省额还要高。坦诚的做法是在承诺减支之前，先评估评估工作的规模，并让其规模决定是否否决这些低赔率的优化。

还有对动态目标的过早优化。模型价格下降的速度非常快，只要你简单地等待，相当一部分“节省”就会免费到来。花费一个冲刺（sprint）来手动抵消一项成本，而下一次降价或下一个更便宜的模型本来就能抹去这项成本，这正是 LLM 时代的“优化编译器即将为你优化的代码”。

一个框架：在做权衡之前先让它显性化

解决方法不是“总是优化”或“从不优化”的政策。而是在开始之前写下权衡的双方，这样决策就不再默认是免费的。四个问题能让这笔账变得透明：

1. 今天这条提示词或路径的月度推理成本是多少？ 不是单位成本，而是总额。一个单次调用昂贵但很少触发的提示词并不是你的问题。在动手之前，先找到真正的大头支出。
2. 工程成本是一次性的还是持续性的？ 一次性的结构性胜利（缓存、Schema、删除无效上下文）几乎总是值得的。除非规模巨大，否则持续性的手动调优几乎从不划算。
3. 这会将压力转移到哪项预算上？ 如果削减 Token 是用推理成本换取技术支持工单或评估维护时间，请明确说出来。一种只是将成本转移到你并不管理的团队的“节省”，根本不是节省。
4. 等待一个季度会让这件事变得免费吗？ 如果价格下降或更便宜的模型很可能会自动抵消成本，那么投资回报率（ROI）最高的举动就是什么都不做，把工程师的那一周花在产品上。

运行这四个问题后，“显而易见”的优化方案会大幅减少。剩下的是一份关于结构性、高业务量、一次性胜利的简短清单——这才是真正省钱的地方，也正是大多数团队因为在细枝末节上耗尽精力而从未触及的清单。

视角重构

这种看法的最深刻之处不在于成本核算技巧。而在于认识到在 AI 产品中，你最稀缺的两种资源——工程师的精力和推理预算——是可以相互转换的，且在一个方向上的兑换率极其糟糕。你几乎总是可以花费工程师的时间来降低 Token 成本。但你很少能通过花费 Token 来换回工程师的时间。而当你能做到这一点时——比如用一个稍大的提示词消除一类边缘情况的 Bug，或者用更慷慨的上下文窗口取代脆弱的检索管道——这通常是更好的权衡，因为它是在用廉价资源偿还昂贵资源。

所以，下次有人提议缩减提示词时，问问这在真正主导你预算的货币中成本是多少。有时答案是“没成本，这只是改一行缓存的代码，发布吧”。有时则是“要花三个工程师周，去节省每月 1800 美元的支出，而这笔费用反正也会降下来”。这并不是同一个决策，唯一让它们看起来一样的原因是你拒绝把这两个数字放在同一张幻灯片上。一个不考虑人力成本的 Token 预算不是预算。它只是关于你觉得哪种资源可以被挥霍的猜测。