生产环境 AI 系统中的成本与延迟

理解模型成本、缓存、批处理、路由、输出长度、流式传输和延迟预算，让你能用数字来论证生产级 AI 的权衡取舍。

由前沿部署编辑团队审阅

演示只为一个用户服务，速度慢，而且没人看到账单。生产环境要为成千上万的用户服务，受延迟预算约束，而且财务部门每个月都会看到账单。这两个世界之间的差距，正是许多 AI 部署悄然失败的地方，而弥合这一差距正是 FDE 的职责所在。本页讨论决定一个可用的原型能否成为可行产品的两个数字：每次请求的成本和响应时间。

为什么这是这份工作的核心

典型场景：试点让五十个用户感到惊喜，客户说“推广到五万人”，于是同样的设计成本暴涨一百倍，共享模型在高负载下变得缓慢。FDE 是那个预见到了这一点并提前设计了应对手段的人。一个无法用生产环境的语言讨论每请求成本和 p99 延迟的工程师，说明他没有运营过真正的部署，面试官对此心知肚明。

在继续阅读之前： 你的原型对每个用户问题调用一次大模型，效果很棒。现在要求你在同样的预算下支撑 100 倍的流量。在想到“更大的集群”之前，先说出两个手段。

影响最大的两个手段：不必调用大模型时就不要调用（缓存重复请求，把简单问题路由到小模型），以及不要发送超出需要的 token（精简提示词和检索到的上下文）。这两者都不是基础设施问题，而是设计问题。

成本手段

• 缓存重复请求。 许多生产级工作负载中，大量请求几乎完全相同。对完全相同或语义相近的重复请求建立响应缓存，可以直接省掉模型调用——最便宜的请求就是你根本不发起的那个。
• 合理选择模型规模。 大多数问题很简单，少数问题很难。把简单的多数问题路由到小而便宜的模型，把大模型留给困难的尾部问题。在前面加一个快速分类器，其收益会成倍地覆盖成本。
• 精简 token。 成本与 token 数量线性相关，因此过度检索的上下文是对每次请求征收的税。检索更少但更相关的段落（这同时还能降低延迟并提升有据性——同一个举措解决三个问题）。
• 缓存共享前缀。 当每个请求都共享一段很长的系统提示词或对话前缀时，缓存其已计算的状态可以避免每次调用都重复处理相同的部分。

真实锚点，注明日期

这个方法需要真实数字才有说服力，所以这里列出两家供应商的旗舰模型和小模型的标价。价格波动很大——在向面试官或客户引用之前，请重新查看链接页面。

除了绝对数字之外，还要从表中读出两点。每一行中，输出 token 的价格都是输入 token 的若干倍，这使得冗长的回答本身就是一个成本杠杆。而且每家厂商的小模型价格只是其旗舰模型的一小部分，这正是让路由杠杆从“整理”变成“真金白银”的关键：每把一个简单问题路由到小模型，就能省掉该请求的大部分成本。

提示词缓存与批处理，定价

“缓存共享前缀”这一杠杆有厂商公布的经济数据。在 Anthropic 的定价中，将前缀写入五分钟缓存的成本是基础输入价格的 1.25 倍，而后续缓存命中的成本是 0.1 倍——同一页面还指出，五分钟档“只需一次缓存读取即可回本”。OpenAI 将缓存输入定价为标准输入的十分之一。回本逻辑如下：

Anthropic five-minute cache; prices relative to base input = 1.0
  cache write = 1.25        cache hit = 0.10
  2 requests, uncached:  1.0  + 1.0  = 2.0
  2 requests, cached:    1.25 + 0.10 = 1.35   → ahead after a single hit
  10 requests, cached:   1.25 + nine hits at 0.10 each = 2.15
                         vs 10.0 uncached — most of the prefix cost gone

需要坦率说明的限制：节省只适用于共享前缀，前缀在请求之间必须逐字节完全相同，且缓存条目会过期，因此经济性取决于同一前缀在缓存生命周期内重复出现的频率。还有一个已公布的杠杆：两家厂商都以 Anthropic 五折和 OpenAI 五折的价格提供批处理——异步、非交互式——这是任何可以等待的任务（包括评测）最便宜的选择。

延迟杠杆

• 流式输出 token。 这是感知延迟上最大的单项提升：在 token 生成的同时就输出，让用户立即看到响应开始。首 token 时间成为关键指标，它远小于完成时间。
• 缓存前缀。 同一个节省成本的前缀缓存也能减少重新处理长共享提示词所花的时间，从而直接缩短首 token 时间。
• 在可行之处使用更小或更快的模型。 省成本的路由策略通常也能省延迟——小模型更快。
• 并行化流水线。 检索、护栏检查以及任何彼此不依赖的工具调用都应并发运行，而不是串成一条链。

需要明说的矛盾：成本、延迟和质量相互牵制。更大的模型更准确，但更慢也更贵；激进的缓存便宜又快，但有陈旧风险。能加分的是说明你在优化什么、为什么——并联系到实际会破坏部署的因素。

延迟基准，注明日期

本页成本部分的方法锚定在真实标价上；延迟部分也需要锚点。两个数字描述了模型的使用体感：首 token 时间（TTFT）和输出速度。Artificial Analysis 是人们最常引用的基准，它对这两个指标给出了精确定义：TTFT 是“从向服务或系统发送请求到收到响应第一个 token 之间的时间（秒）”，输出速度是“收到第一个 token 之后，每秒收到的平均 token 数”。TTFT 是用户盯着看的沉默；输出速度则决定答案一旦开始输出后需要多久才能完成。

两个实测锚点，各对应一家厂商的小模型：

把两行放在一起对比：gpt-5.4-mini 一旦开始输出，流式速度更快，但用户要等六秒以上才能看到任何内容——这个首 token 数字反映的是推理模式变体在回答前先花费思考时间，与下文前沿模型注意事项中描述的效果相同。哪个模型“感觉更快”取决于你的流程暴露的是哪个数字。这些基准数据会持续变动——新的模型版本、新的服务硬件——所以引用时要注明访问日期，本表即是如此。

前沿推理模型需要单独提醒，单一的 TTFT 数字无法公正反映它们：推理模式在输出第一个答案 token 之前会先花费思考时间，这可能使用户可见的等待时间远超小模型的 TTFT。Artificial Analysis 单独追踪这一指标，称为“Time to First Answer Token”（首个答案 token 时间）。围绕这一差异设计面向用户的流程——为约一秒沉默调优的流程，在思考时间把等待拉长到远超此值时，需要进度指示器、中间状态提示，或改用更小的模型。

两家厂商都公布了该拉哪个杠杆。OpenAI 的延迟优化指南量化了一个值得记住的不对称性：把输出 token 减半大约可将延迟减半，而把输入 token 减半只能将延迟改善大约百分之一到百分之五。输出长度才是关键杠杆，这使得“简洁作答”、设置最大输出上限以及采用精简的结构化格式，既是延迟优化手段，也是成本优化手段。Anthropic 的指南是定性描述，但指向相同：选择足够用的最快模型（“对于速度敏感的应用，Claude Haiku 4.5 提供最快的响应时间，同时保持高智能”），限制输出长度，并使用流式输出。

一个 p99 预算，实操演算

只有把延迟目标按阶段分解，它才成为工程问题。来自可观测性追踪的受保护流水线——检索、护栏预检查、模型调用、事实依据检查——是一条链，用户的等待时间就是阻塞路径上各环节之和。在分布的两个点上做预算：p50 对应典型请求，p99 对应支持团队经常听说的长尾。

示例性端到端预算——本框中每个数字都是虚构的；值得带走的是方法。回答长度 300 tokens。阶段 p50 p99 检索 90 ms 450 ms 护栏预检查 15 ms 40 ms 模型：首 token 时间 800 ms 2,500 ms 模型：生成 300 tokens ÷ 60 tokens/秒 = 5,000 ms 事实依据检查 400 ms 1,800 ms 首个可见 token，流式（检索 + 预检查 + TTFT）：p50：90 + 15 + 800 = 905 ms p99：450 + 40 + 2,500 = 2,990 ms 完整响应，事实依据检查阻塞流：p50：90 + 15 + 800 + 5,000 + 400 = 6,305 ms p99：450 + 40 + 2,500 + 5,000 + 1,800 = 9,790 ms

两个教训蕴含在这两个总数中。第一，用户感知的是首个可见 token 的时间，因此流式输出几乎隐藏了全部生成时间：同一条流水线，体验可能不到一秒，也可能超过六秒，取决于 token 是否边生成边显示在屏幕上。第二，事实依据检查会打破这一技巧。正如护栏页面所指出的，评判器是串行运行的，在完整草稿生成之后、用户看到任何内容之前，因此一个阻塞式检查会把流式体验重新变回完整响应的等待。这就剩下三种设计：把检查做得足够快以符合预算（用小型评判模型处理简短回答）、改为抽样或按风险路由执行而非每个请求都执行，或者先流式输出草稿、检查失败时再撤回——只有在短暂显示的错误答案可以容忍的情况下才可行，而在受监管的部署中，这往往不可行。

有一个注意事项能让这些算术保持诚实：像本框那样把各阶段的 p99 相加，得到的是保守的规划上界，而非真正的 p99，因为最慢的百分之一检索和最慢的百分之一模型调用大多发生在不同的请求上。实践中，端到端长尾由自身长尾最肥的那个阶段主导。所以要按阶段做预算、按阶段测量——即可观测性追踪记录的同样的分阶段计时——并从生产环境中读取真实的端到端分布，在那里修正表格的估算。

上限：速率限制

容量先于价格耗尽：每个提供商都会对每个账户的吞吐量设置上限，因此一次发布可能在账单还很宽裕时就撞上硬性天花板。Anthropic 的限制按使用层级设定，并针对每个模型类别以三种方式衡量：每分钟请求数、每分钟输入 token 数（ITPM）和每分钟输出 token 数（OTPM）。超出任何一项都会返回“429 错误”并附带 retry-after 头部，其执行采用令牌桶算法，因此容量是持续补充的，而不是在时钟边界重置。同一页面还通过一个专门的示例，将本章的缓存杠杆与容量以及成本联系起来：“在 2,000,000 ITPM 限制和 80% 缓存命中率下，你实际上每分钟可以处理 10,000,000 总输入 token”（Anthropic 速率限制）。你之前定价的前缀缓存不仅在成本上划算，也在天花板之下买到了余量。

OpenAI 的限制具有相同的结构：每分钟或每天的请求数和 token 数，应用于组织和项目层面，使用层级会随着支出累积自动升级。

FDE 的经验：发布日的算术必须包含天花板。峰值并发用户数乘以每次请求的 token 数，与每分钟 token 数限制对照，就能在第一个用户登录之前判断这次发布是否适应当前层级——而针对 429 的指数退避重试路径应从一开始就纳入设计。

自托管：交叉点问题

一位追问成本分析的面试官会再推进一步：什么时候自托管开放权重模型比支付 API 更划算？推理过程比任何具体数字都重要。API 提供商将加速器成本摊销到众多租户上，因此它买到了单个客户很少能达到的利用率水平；自托管者要为自己流量峰值周围的闲置容量买单，还要在运维人力上再次付出成本以保持推理服务健康。因此，自托管往往在三种情况下胜出：持续的高流量足以让硬件保持忙碌、API 无法提供的定制微调模型，或者数据驻留与合规约束彻底排除了 API（安全、合规与数据涵盖第三点）。并且要直白地说出数字不会替你说的：可信的公开交叉点数据并不存在——各种调查声称的数据相差两个数量级——所以任何引用盈亏平衡点的人都必须给出他们的假设：流量、利用率、硬件和人力成本。先点明驱动因素，再要求对方给出这些假设，才是有力的面试回答。

差 / 好 / 卓越 — “让它在规模化下工作”

差 — “我们会水平扩展，增加更多实例。” 你把 AI 系统当成了无状态的网络服务。成本按 token 计，延迟存在于模型调用中，所以增加实例对两者都毫无影响——你只是在瓶颈周围加了服务器，却根本碰不到瓶颈。

不错——“成本就是 token 数乘以调用量，延迟就是首 token 时间；我会尽量做缓存，能用小模型就用小模型。” 框架正确，抓手真实——扎实的中级水平。差距在于：没有判断哪个因素占主导，哪个约束最接近崩溃。

很好——“我会先测量每个请求的成本和 p99 延迟，找出占主导的因素，然后针对它下手：缓存高频头部流量，把简单的多数请求路由到小模型，削减过度拉取的上下文，并用流式输出改善体感延迟。我会从第一天起就对这两项做逐请求埋点，因为在规模化之后，一点小小的退化就意味着一大笔账单或一长串工单。而且我会优先优化最接近让部署崩溃的那个约束，而不是最容易优化的那个。” 你把“它能扩展”变成了基于实测数字的具体抓手，还给出了优先级规则。

面试中要带上的要点

在系统设计环节中，“它能扩展”等于没回答。说出两个数字——每请求成本、p99 延迟——指出哪个更接近让部署崩溃，并针对占主导的因素给出具体抓手。先讲测量，再讲它带来的优先级。

相关： 可观测性与调试——你只能优化你正在监控的数字。

下一篇： 安全、合规与数据——这些约束决定了系统是否被允许存在。

下一篇：安全、合规与数据