一个团队发布了一款支持聊天机器人。在测试阶段，每月账单看起来还在可控范围内——工程团队演示期间仅花费了几百美元。上线三周后，发票寄到了：4.7 万美元。没人虚报 Token 数量，也没人算错账。生产环境的工作负载与他们模拟的完全不是一回事。
这种模式在不断重复。团队估算 LLM 成本的方式就像估算数据库查询成本一样——通过测量一个典型的请求并乘以预期访问量。这种思维模型在 LLM 上彻底失效了，因为两个最大的成本驱动因素（输出 Token 长度和工具调用开销）是在推理阶段决定的，其行为在设计阶段无法完全预测。
本文讨论的是如何在发布前进行更好的预测，而不是在账单到期后如何优化。
为什么设计阶段的估算会失败
天真的成本公式是这样的：估算平均 Prompt 大小，乘以每日请求数，再乘以模型的每 Token 单价。对于大多数生产系统来说，这会导致数量级上的错误。
问题首先出在输出 Token 上。每个模型对输出的计费都比输入贵——通常每 Token 贵 4 到 8 倍——因为自回归生成对每个 Token 进行一次顺序推理，而输入处理是在单次并行前向传递中完成的。一个输入 1,000 Token、生成 50 Token 的 Prompt，其成本与生成 500 Token 的 Prompt 截然不同。输出长度取决于用户意图、任务复杂性和模型 Temperature。在设计阶段，这些都不是固定的。
第二个失效模式是工具调用（Tool-call）开销。在 Agent 系统中，工具输出会被重新注入 Context（上下文），用于后续的推理步骤。用户消息可能只贡献 50 个 Token，但它触发的工具响应可能轻易达到 5,000 个。当你以直接提示（Direct Prompting）为基准进行测试时，这种 100 倍的放大效应是不可见的，但在执行真实查询、API 调用或代码执行的生产环境 Agent 中，它会立即显现。
第三：对话历史的累积。每一轮都发送完整对话上下文的系统，随着会话变长，成本会呈现超线性增长。第二轮花费 0.01 美元的会话，在第十轮可能花费 0.08 美元——这不是因为用户行为发生了变化，而是因为在架构决策时没有考虑到历史记录的增长。
演示流量不会暴露这些问题。工程师运行的是简短、受控的 Prompt。他们不会模拟一个粘贴了 2,000 字文档并提出后续问题的用户，也不会模拟一个重试三次失败工具调用的 Agent。
在发布前分解成本差异
在进行准确预测之前，你需要根据驱动因素分解你的 Token 预算。这三类行为各不相同，需要不同的缓解策略。
输入 Token 是最可预测的。你可以控制系统 Prompt 的长度。你可以测量同类产品中用户消息长度的分布。如果你使用的是检索增强（RAG），你可以测量每次查询注入了多少个 Chunk。输入 Token 是成本模型中真正可以被设计的部分。
输出 Token 是差异存在的地方。同一个查询发送十次，返回的答案可能从两句话到十段话不等。在生产系统中，输出与输入 Token 的比例通常在 0.1 到 2.0 之间，具体取决于任务类型。摘要生成的输出相对于输入较短，而开放式生成可能会反转这一比例。如果你没有特定任务类型的经验数据，请假设输出 Token 会出乎意料地偏高。
工具调用 Token 是 Agent 系统中的变数。每次工具调用都会将其响应注入上下文，并且 Agent 在产生最终响应之前可能会多次调用工具。在开发过程中跟踪工具调用深度和平均工具响应长度。一个平均每个用户请求进行三次工具调用、且工具响应平均为 800 Token 的系统，每个请求在开销上花费了 2,400 Token，而这根本不会出现在你的初始成本估算中。
推理 Token 是一个新兴的第四类目。具有内置思维链处理功能的模型——o 系列模型、带有思维模式的 Gemini、带有扩展思维的 Claude——会为隐藏在应用程序输出之外的内部推理步骤计费。这种溢价通常是基础费率的 2 到 4 倍。如果你正在使用这些模型，你看到的可见 Token 数量可能会使实际成本被低估三倍。
在金丝雀流量之前的模拟
发布前模拟的目标是获得每个请求的成本分布，而不仅仅是一个平均值。平均值掩盖了长尾效应——而在 LLM 系统中，长尾成本非常昂贵。
首先建立一个反映预期生产输入的 Prompt 语料库。这意味着：
- 从现有产品（论坛、支持单、类似产品）中采样真实的用户查询
- 如果没有，则根据复杂度等级创建合成 Prompt
- 包括对抗性案例：最大长度输入、触发多次工具调用的模糊查询、导致冗长输出的请求
在你的实际系统架构上运行这个语料库，而不是简化的桩程序（Stub）。使用真实模型、真实工具集成、真实检索管道。捕获分解为输入、输出和工具调用开销的单次请求 Token 计数。建立一个直方图。
该直方图的 P50 是你的规划估算，P95 是你的预算上限。它们之间的比例告诉你的长尾有多厚。P95/P50 比例超过 5 意味着一小部分用户产生的成本将使平均用户相形见绌——你应该在发布前在产品层面限制这些会话，而不是在发布后。
对于 Agent 系统，运行不同 Agent 深度的模拟。在测试中两步完成的任务，在生产环境中当用户查询含义模糊时可能需要六步。建模每个步骤深度的成本，并提前决定你允许的最大 Agent 深度。在发布前为架构建立硬性限制成本很低，但在发生账单事故后再进行补救则不然。
金丝雀部署作为成本控制手段
一旦你有了模拟估算，金丝雀流量可以在全面铺开之前，根据真实用户数据对这些估算进行验证。
标准的金丝雀方法是将一小部分生产流量路由到新系统，而其余流量继续走旧路径。为了进行成本预测，在金丝雀发布期间需要追踪的关键指标包括：
- 每会话平均成本（不是每请求成本——会话级聚合能捕获多轮对话的开销）
- P95 每会话成本
- 智能体步骤深度的分布（针对智能体功能）
- 如果你实施了语义缓存，则需关注缓存命中率
将这些指标与你的模拟估算进行对比。如果生产环境的 P95 超过模拟 P95 的两倍，说明你的语料库未能捕获足够的极端情况（hard cases）。在扩大发布范围之前，深入研究高成本会话并识别其模式。
一种未被充分利用的技术是会话受限的金丝雀部署 (session-capped canary deployment)。与其无限期地将一定比例的用户路由到新系统，不如在金丝雀发布期间设置每个会话的 Token 预算，并在会话达到上限时进行平滑降级。这为你提供了验证期间的成本上限，并能揭示用户是否经常触及会话上限——这会在你投入正式生产预算之前，告诉你需求的弹性如何。
生产环境中的动态预算执行
模拟和金丝雀部署会减少意外，但无法消除意外。用户总能找到你意想不到的系统使用方式，你需要执行逻辑来防止最坏的情况演变成灾难。
框架级的预算执行比供应商级的速率限制（rate limits）更可靠。供应商的速率限制是为了保护供应商，而不是为了保护你的账单。一个执行完毕但消耗了 50,000 个 Token 的请求通常不会被供应商的速率限制拦截，但它会击穿你在应用代码中执行的每会话预算。
有效的执行机制分为三个层级：
每会话上限 (Per-session caps) 为单次对话设置最大 Token 预算。当会话接近上限时，显示平滑降级消息，而不是静默截断上下文或报错。经常触及会话上限的用户是一个信号，表明你的上限设置过低，或者你的使用场景与设计初衷有所偏差。
每用户每日预算 (Per-user daily budgets) 防止个人用户通过反复的长会话产生失控成本。这对于内部工具（工程师会压力测试你的系统）比对消费级产品更重要，但两者都能从中受益。
智能体循环的熔断机制 (Circuit breakers for agent loops) 对智能体系统尤为重要。一个陷入循环的智能体——例如不断重试失败的工具调用，或反复搜索找不到的信息——其消耗 Token 的速度会比人类交互高出几个数量级。通过追踪没有最终响应的连续工具调用来检测循环模式，并以错误形式终止，而不是让循环继续。对于没有构建这种保护机制的团队，无限制的智能体循环曾导致过每周五位数的账单。
渐进式节流在触及硬限制之前实现平滑降级。当一个会话达到其预算的 80% 时，为剩余轮次切换到更便宜的模型。当达到 95% 时，返回更短的响应。100% 时的硬切断是必要的，但不应是主要的机制。
不可或缺的估算
使成本预测发挥作用的纪律是在开发过程中测量组件级的 Token 计数，而不仅仅是 API 响应级别。了解你的系统提示词（system prompt）贡献了多少 Token。了解你的检索步骤平均以及在 P95 水平下注入了多少 Token。了解目标数据集中典型用户消息的长度。了解你的工具响应平均包含多少 Token。
这些数据让你建立一个能够解释偏差（variance）而不仅仅是报告偏差的成本模型。当生产成本偏离估算时，组件级模型会告诉你哪个驱动因素发生了变化——是用户行为的转变、系统提示词的膨胀，还是工具响应变得出乎意料地冗长。
跳过这一步的团队往往会陷入一种常见的境地：收到一份意外的账单却无法明确归因——这是最糟糕的结果，因为你无法修复你无法解释的问题。
预测 LLM 成本与预测数据库或计算成本有本质区别，因为很大一部分成本是由动态行为决定的，而不是由你决定的。面对这种不确定性，反应不应该是放弃估算，而是构建能够约束不确定性的系统，在发布前根据经验测量偏差，并执行防止尾部风险主导预算的限制。
那些没有被 LLM 账单吓到的团队，并不是因为他们估算得更准确，而是因为他们构建了执行逻辑，并在上线生产环境前验证了该逻辑确实能约束成本。