一个概念验证（PoC）花费了你 200 美元的 API token。你获得了上线的许可。六周后，账单变成了 18,000 美元。这并非定价变动或计费错误——而是成本建模的失败，也是 AI 工程中最可预见的意外。
AI 功能在预发布（staging）环境和生产环境之间的成本差距并非偶然。它遵循一个一致的模式：预发布环境在结构设计上（通常是无意的）隐藏了生产环境中每一个关键的成本驱动因素。理解这些驱动因素是避免首份账单演变成危机的关键。
预发布环境是一个成本幻象
当你在预发布环境中运行 AI 功能时，有几件事在悄然误导你：
模拟的工具调用。 在开发中，你返回硬编码的工具响应或使用测试存根（stubs）。模型不会进行真实的下游调用。在生产环境中，每次工具调用都是真实的 API 调用，伴随着真实的延迟和成本。更重要的是，工具调用错误会触发重试逻辑，这在测试中几乎从不发生，但在生产中却频繁出现。
微小且同质的测试流量。 你的预发布环境只有几名工程师在运行少量具有代表性的查询。真实用户的需求是异质的，有着古怪的输入、你未预见到的边界情况，以及会触发测试从未覆盖的代码路径的查询。生产环境中的 token 分布与你在预发布环境中衡量的完全不同。
单机缓存。 预发布环境通常运行在带有热缓存（warm cache）的单个服务器上。生产环境则运行在负载均衡器之后，将流量分配到多个节点，每个节点都有自己的缓存状态。预发布环境从未经历过的冷启动在生产环境中不断发生。
供应商补贴的开发抵扣金。 许多早期测试是使用免费额度或试点定价进行的。你的模型卡（model card）中引用的生产定价通常与第一个月的实际测试成本有实质性的不同。
结果是，成本模型建立在受控的虚构之上。96% 的组织报告称，在从试点转向生产时，基础设施成本高于预期。
Prompt 缓存命中率如何在发布时崩塌
Prompt 缓存是 LLM 系统中最有效的成本杠杆之一。使用 Anthropic 的前缀缓存（prefix caching），重复的 prompt 前缀每百万 token 的成本约为 0.30 美元，而不是 3.00 美元——降低了 90%。OpenAI 的自动缓存为超过 1,024 个 token 的 prompt 提供类似的节省。在预发布环境中，由于你针对热单实例缓存反复触发相同的少量测试查询，命中率看起来非常出色。
生产环境在两个关键方面有所不同。
首先，你的负载均衡器将流量分配到不同实例。每个实例都以冷启动开始。在部署后或流量激增导致新容量扩容的几小时内，很大一部分请求都是缓存未命中。你在预发布环境中衡量的成本下限（假设缓存为热态）实际上并不是你在生产初期所经历的下限。
其次，生产流量是多样化的。一个团队追踪了一个语义缓存，发现在评估集上的命中率为 40%，但在真实用户流量下下降到了 8%。评估集看起来很有代表性，但事实并非如此。真实用户表达查询的方式会微妙地破坏前缀匹配。
对于智能体（agentic）系统，这个问题会更加严重。一个执行十次连续 LLM 调用的智能体循环，如果每次调用都有 30% 的概率命中冷缓存，那么整个链条中至少有一次调用未命中的概率超过 97%。这次缓存未命中的成本是缓存版本的十倍，并且会拉高延迟，从而可能导致连锁反应般的更多重试。
解决方法不仅仅是“使用缓存”。解决方法是将缓存命中率作为首要的生产指标，独立于成本和延迟进行衡量，并显式地为冷启动阶段预留预算，而不是根据预发布环境的热态数据进行推断。
工具调用扇出在真实查询下成倍增加
测试查询遵循快乐路径（happy path）。用户向你的预发布部署询问一个简单问题，会得到一个清晰的工具调用、一个有效的响应和一个成功的日志。真实用户的查询并非如此。
在生产环境中，一个简单的用户问题可能会扇出成一个链条：架构查找、语义解析、查询编译、执行、血缘检查、策略验证。每一步都是一个工具调用，每个工具调用都可能是输出 token，而每个失败的工具调用都会触发重试逻辑，从而使该请求的调用次数翻倍甚至翻三倍。
与简单的补全相比，智能体工作流的 token 倍率是 5 倍到 20 倍，具体取决于任务复杂度。一个作为直接补全成本为 0.01 美元的 prompt 响应，作为多步智能体调用则需要 0.10 到 0.15 美元。在每日 500,000 次请求的情况下，这种差异意味着每月 5,000 美元账单与 75,000 美元账单之间的鸿沟。
在预发布环境中难以建模的原因在于，扇出是由输入的多样性驱动的。合成测试数据会给你可预测的扇出，因为你编写了测试用例，且它们被设计为能够顺利成功。生产输入则会暴露你的重试逻辑、错误路径以及仅在边界情况查询中才会激活的工具依赖。
你未曾进行的 Token 计数审计
生产环境中的 Token 计数与预发布环境（staging）在几个方面存在差异，每个差异点看似微小，但累积起来却是毁灭性的。
结构化数据在 Token 化过程中会产生严重碎片。在代码中看起来很简洁的 JSON 键值对，其 Token 数量会比同等长度的普通文本多得多。处理结构化用户输入、数据库记录或工具响应的 AI 功能，其单次请求的 Token 数量通常比单纯按字符数估算的要多 30% 到 50%。
标点符号、格式化字符和 Schema 模板都会被单独 Token 化。一个因为格式冗长而导致每次请求浪费 200 个 Token 的 Prompt，在测试规模下是无法察觉的，但在每天一百万次请求的规模下，每年将耗费 200,000 美元。
大多数团队跳过的务实步骤是针对具有生产代表性的输入进行 Token 计数审计。这意味着你需要使用真实的或高度模拟的用户查询，而不是整洁的测试集，通过分词器运行你的实际 Prompt。观察 Token 效率的分布情况。识别高昂请求的长尾效应。处于第 99 百分位数的请求，其 Token 计数通常是中位数的 5 到 10 倍。
再加上随着用户交互增加而产生的上下文窗口增长：会话上下文不断累积，工具响应被追加到 Prompt 中，起初只有 1,000 个 Token 的请求在几轮交互后可能会变成 15,000 个 Token。由于测试脚本通常无法完全模拟冗长的用户会话，预发布环境很少能体现这种多轮交互的深度。
防止危机的成本建模规范
第一份账单带来的“惊喜”是可以预防的。这需要三项实践，但大多数团队因为在发布前觉得这些是额外负担而选择跳过。
流量模拟。在发布之前，对预期的生产环境流量进行建模：预期的请求量、按复杂度划分的请求分布、预期的多轮交互深度、重试率假设。利用这些数据预测三种场景下的 Token 消耗——中位数、第 90 百分位数和峰值。中位数是你的期望，第 90 百分位数是你的规划依据，而峰值则是你的速率限制（rate limits）应该防护的底线。
缓存未命中预算。假设每次部署后的最初几个小时是冷启动期。通过刻意以防止缓存的间隔触发每个 Prompt 前缀，测量零缓存预热时的请求成本。这是你的生产成本底线，而不是预发布环境的预热平均值。基于底线而非上限来构建你的预算预测。
发布前的成本归因。在进入生产环境之前，为每个 LLM 调用添加功能级和用户级标签。如果没有归因，你无法识别哪 20% 的功能驱动了 80% 的成本。在缺乏可观测性的情况下发布的团队，往往会面对一份五位数的账单，却无法将其追踪到具体的代码路径。设置可观测性只需要一天时间，而调查账单则需要一周，且只能得到近似答案。
这三项实践结合在一起，能让你得到的生产成本估算与现实的差距控制在 2 倍以内，而不是 10 倍。从 2 倍到精确估算的差距，是模型路由、语义缓存和 Prompt 压缩发挥作用的地方——但这些优化需要归因数据才能落到实处。
弥合差距
从开发到生产的成本冲击是一种可预见的故障模式，而非随机事件。预发布环境是为开发速度优化的，而非成本保真度。每一个让预发布环境变得便利的属性——模拟后端、预热过的单实例缓存、精选的测试输入、快乐路径（happy-path）覆盖——都是隐藏真实生产成本驱动因素的诱因。
这种规范并不是要让预发布环境变得更昂贵，而是要针对预发布行为与生产行为之间的差距建立明确的模型，在发布前从你能测量的维度（Token 分布、缓存冷启动成本、工具调用深度）衡量这种差距，并根据生产环境的底线而非预发布环境的平均值来确定预算规模。
做到这一点的团队会发现，第一份生产环境账单与他们的估算非常接近。而没能做到的团队则会发现，第一份账单变成了关于该功能是否应该上线的重新谈判。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
