为什么 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% 这一级别跌至个位数，而在发票到来之前，捕捉到这一点的唯一方法是将命中率作为一级指标进行监控。将任何周同比超过几个百分点的下降视为需要寻找“部署相关性”的信号，而不是噪声。

按错误类别切分的失败重试开销。 没有抖动（Jitter）或预算限制的朴素重试循环会反复冲击已经过载的端点，并在几毫秒内耗尽你的重试预算。按错误类别（频率限制、超时、模型侧 5xx、工具侧错误）标记每次重试调用，并绘制每个错误类别的成本图。一个静默退化的新依赖项会在其他任何地方察觉之前，先在这里显现出来。

如果你的仪表板没有在这四个维度上进行切分，那么你观察到的就是一条融合了四个独立机制的单一曲线。这条线只会告诉你发生了什么，而永远不会告诉你为什么 —— 当你面对财务部门时，“为什么”是唯一重要的问题。

在账单寄达前就触发的告警面

月度账单是一个延迟 30 天的标量。你无法基于它来运行功能。告警面必须触发在那些领先于账单数日、而非落后于账单数周的信号上。

一套行之有效的方案包含三个层级。基于用户群组（user cohort）的滚动 P95 支出能捕捉到重度用户涌现模式：当一小部分用户的日均成本上升到预算假设之外的尾部时，你希望在当周就知晓，而非等到下一季度。在网关层为每个 API 调用标记 user_id、cohort_id 和 feature_id，然后运行流式聚合。针对每种查询类型的成本异常检测能捕捉到组合偏移和多样性漂移：将“每个意图的成本”作为指标，拟合一个区间，并在过去 24 小时的数据偏离该区间时报警。预算消耗率（burn-rate）告警用于捕捉断崖式变化：如果在 15 分钟窗口内，某个 Key 的支出速度超过其过去 7 天平均值的 3 倍，则自动限制流量并呼叫值班人员。网关式的预算熔断模式——单次请求上限、单次会话滚动预算、单个 Key 的配额——之所以存在，正是为了让失控的循环不会运行长达八小时。

在实践中，有两个非显而易见的点让这套机制发挥作用。首先，告警必须与“预测”挂钩，而非“阈值”。对于一个日成本每周增长 20% 的功能，“你在第 18 天消耗了 60% 的预算”是一个毫无用处的告警——预测显示在第 25 天就会超标，但阈值告警直到第 22 天才会触发。正确的做法是 AWS 风格的“你将在周二超过配额”这种基于变化率而非绝对值计算的预测。其次，熔断器往往是大多数团队最后才添加、却最先感到后悔的部分。网关层的有界退避（bounded-backoff）和单次会话 token 上限，正是为了防止你在睡觉时发生“一周烧掉 47,000 美元”的惨剧。

这是 FinOps 领域多年前在云支出方面达成的结构性共识，现在正被应用于 AI：token 成本不是一份你在月底核对的发票，而是一系列遥测事件，你应该像对待延迟或错误率一样对待它。一旦你这样做了，仪表盘、告警和值班响应都会立刻转化为你现有可观测性栈中已有的成熟模式。

双仪表盘难题

存在一种组织病态，会在关于成本的讨论开始前就将其摧毁。工程团队构建了一个由网关遥测支撑的仪表盘，以 token 为单位，按功能和群组切片，并实时更新。财务团队构建了一个由供应商发票支撑的仪表盘，以美元为单位，分配到各个成本中心，且每月更新一次。这两个数字永远对不上。它们不可能对得上——它们是在不同的时间窗口内、基于不同的归因规则计算不同的东西——而首次发现这一差异的会议通常会耗费 90 分钟，而这些时间原本没人打算花在对账上。

解决方案不是做一个更好的仪表盘，而是一个双方都能查询的单一事实来源。在网关层标记财务所需的一切信息（成本中心、产品线、用于扣费的客户 ID），这样工程团队的流数据和财务团队的分配数据都源自相同的 Span 数据。每月根据发票进行一次核对作为校验，而非作为主要信号。网关计算成本与发票成本之间的差距本身就是一个有用的指标——它能揭示供应商价格变动、缺失的遥测数据以及未标记的调用——但它是一个调试信号，而非头条新闻。

更深层的一点是，AI 功能的单元经济效益（unit economics）是一个跨职能指标。产品需要“每个结果的成本”来为功能定价。工程需要“每次请求的成本”来优化架构。财务需要“每个成本中心的成本”计入总账（GL）。这些视图都没有错，但它们都必须源自同一个原子事件——带标签的 Span——否则讨论就会陷入细节的迷雾中。

像对待延迟一样对待 Token 成本

这一切背后的架构认知很简单，但如果你在没有这种认知的情况下就发布了功能，那可能会有点令人沮丧：token 成本是实时信号，而非月度报表。正如没人会在没有 P95 延迟仪表盘和针对性能退化的告警的情况下发布面向用户的功能一样，任何团队都不应在没有按群组和意图切片的“单次请求成本”仪表盘，以及连接到观察延迟的同一套值班流程的异常检测的情况下，发布 AI 功能。

这个比喻非常精准。当下游依赖降级、代码路径增加了同步调用、缓存失效或流量组合向慢分支偏移时，延迟会发生漂移。成本也会因为同样的原因、在相同的时间尺度上发生同样的变化——而且，如果你构建得当，成本仪表盘在结构上与延迟仪表盘完全一致。指标变了，但应对方案没变。

在第一张发票寄达前就明白这一点的团队，与那些没明白的团队相比，处于完全不同的境遇。他们与财务讨论的是“预测”而非“解释”。他们推出针对特定群组的价格调整，而非全功能回滚。他们能捕捉到周三下午破坏缓存的错误时间戳配置，而不是在三个月后，当趋势线最终超过某个在预算会议上设定的随意阈值时才发现。

发布后的预测偏差并不是预测的失败，而是探测的失败。预测注定会出错；问题在于你是实时发现还是事后才后知后觉。像你已经知道答案是错的那样去构建遥测系统，惊喜就会变得小得多——而且便宜得多。