从开发到生产的成本冲击：为什么你的 AI 功能在测试环境仅需几分钱，而在生产环境却要花费数美元

一个概念验证（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）。用户向你的预发布部署询问一个简单问题，会得到一个清晰的工具调用、一个有效的响应和一个成功的日志。真实用户的查询并非如此。

加载中…