为什么 Token 预测在上线后会发生偏移 —— 以及如何在财务发现前捕捉到异常峰值

发布前的成本模型通常是一张精美的电子表格。它假设通过代表性的提示词（Prompt）运行模拟流量，并在测试过的缓存命中率和干净的工具调用路径下运行。但发布后的现实是，一旦功能真正开始运作，这些假设都将不复存在。模拟流量未涵盖的意图恰恰是用户最常使用的。工程团队没收到会议通知的营销活动所带来的流量，最终落在了路由树中成本最高的分支上。在第三周，使用量超过中位数 40 倍的重度用户群体才会开始出现。

这类问题在全行业内已屡见不鲜：调查显示，约 80% 的企业对 AI 成本的预测偏差超过 25%，并报告在成功发布后的几个月内，成本通常会增加 5 到 10 倍。这些数字中关键的细节是“成功”二字。失败的 AI 功能才能维持在预算内。成本偏差是由功能的成功运行驱动的，而不是因为团队做错了什么。这使得它成为一个规划产物（planning artifact）问题，而不是工程问题 —— 而大多数团队依赖的规划产物，即每月账单，其实是最糟糕的检测器。

你的预测出错的三种分布

发布前的成本模型几乎总是针对每个查询给出一个单一数值：平均输入 Token、平均输出 Token、平均工具调用深度。这个单一数值是一个尚未被观察到的分布的均值。在发布当天，会发生三件事，使得这个均值变得毫无意义。

意图分布（Intent distribution）发生偏移。 模拟评估集是由一个小团队构思用户可能输入的内容而构建的。实际流量则由团队从未想过要测试的意图所主导。处理此类模式的客服队列报告称，意图分布在发布后会发生重塑，并导致高流量层级中的路由错误 —— 在 LLM 工作流中，路由错误不仅意味着错误的答案，还意味着进入更昂贵分支的完整额外往返。仅占查询量 5% 的长尾意图可能占 Token 支出的 30%，因为它们往往落入具有最大上下文和最深工具链的模型中。

每个用户的分布是幂律（Power-law）分布，而非正态分布。 当一个用户的请求量是中位数的 40 倍时，均值就失去了意义。这并非异常，而是规律。一旦某个功能变得有用，一小群专业用户就会像运行自动化程序一样运行它，而不是将其当作聊天工具。你的预测模拟的是中位数用户；而账单则由 99 百分位用户主导。除非你从第一天起就按群体切分成本，否则在财务部门询问为什么曲线弯曲之前，重度用户是不可见的。

工具调用重数分布（Tool-call multiplicity distribution）具有由失败驱动的肥尾（Fat right tail）。 五个服务调用链的每一层进行三次重试，会导致每个用户请求产生 3^5 = 243 次后端调用 —— 而使用干净数据的模拟评估集只产生了一次。生产团队曾报告过递归代理循环，其费用在 11 天内从 127 美元/周攀升至 47,000 美元/周，还有隔夜重试循环在有人醒来之前就进行了数千次完全相同的计费工具调用。预测假设的是模型本身并不总是遵循的“快乐路径”。

结论：任何引用单一平均每请求 Token 数的预测都已经失败了。你需要预测的单位是分布，而分布在功能上线时会发生变化。

分解必须呈现的样子

对于已上线的 AI 功能，一个有用的单元经济效益分析至少应包含四个维度，漏掉其中任何一个都会在成本激增时将其掩盖。

按意图类别切分的输入与输出 Token。 在大多数尖端 API 上，输出 Token 的成本约为输入 Token 的 3 到 8 倍，而 2026 年的中位数输出输入比约为 4:1。即便其他因素保持不变，向产生长响应意图（解释、摘要、生成的文档）的混合转变也会提高你的加权平均请求价格。你无法从“总 Token”图中检测到这一点；该曲线持续增长看起来像是使用量增加，但实际上是每个查询的价格增加了。

每个工作流的工具调用重数。 追踪每个用户发起的请求所对应的模型调用和工具调用次数，而不是每次 API 调用。一个因为有人添加了新的验证步骤而悄悄从 3 次模型调用增加到 7 次的工作流，表现为 130% 的成本增加，而任何单一提示词的更改都无法解释这一点。重数偏差是“我们什么都没改，账单却翻了一倍”故事的第一大来源。

缓存命中率的周同比偏差。 缓存命中率被称为生产环境 LLM 成本中杠杆率最高的单一指标，而它发生偏差的最常见原因是平庸的：有人为了调试在系统提示词中添加了请求时间戳，该时间戳每秒都在变化，导致每次请求的缓存失效。由于一行代码的修改，缓存节省可能从 80% 这一级别跌至个位数，而在发票到来之前，捕捉到这一点的唯一方法是将命中率作为一级指标进行监控。将任何周同比超过几个百分点的下降视为需要寻找“部署相关性”的信号，而不是噪声。

加载中…