你拥有的每一份延迟优化手册（latency playbook）都是为那些单次请求工作量大致恒定的系统编写的。数据库查询耗时相对固定。图像缩放随像素数变化，而这是预先可知的。甚至经典的 LLM 补全也有可预测的成本范畴：输入多少 token，输出有限的 token。推理模型悄无声息地打破了这一假设。当模型在运行时自行决定思考多久——且它是基于问题难度来决定时——响应时间便不再是基础设施的属性，而变成了问题本身的属性。
后果首先体现在你的分位数指标上。在生产环境中运行推理模型的团队报告称，p99 延迟会激增到 p50 的三到五倍，这不是因为主机变慢或缓存失效，而是因为百分之一的请求恰好真的很难。你的自动扩缩容策略、超时策略和 SLO 仪表板都是针对一个“这种差异意味着系统出现故障”的世界而调整的。而现在，这却意味着系统正按设计运行——你用来管理尾部延迟的所有工具都指向了错误的原因。
延迟曾是基础设施的属性，现在则是模型的决策
在固定成本推理的时代，尾部延迟（tail latency）有基础设施层面的解释：排队、资源竞争、垃圾回收或坏的副本。Google SRE 的经典准则——最著名的莫过于《规模化下的尾部延迟》（Tail at Scale）系列研究——正是建立在这一前提之上的。请求本身是“无辜”的，是环境让它变慢了。因此，补救措施也是环境层面的：重试到另一个副本、隔离慢主机、优化调度器。
推理模型增加了第二个、也是更大的变量来源，它存在于请求内部。思维链（Chain-of-thought）的长度取决于输入，并且是增量决定的：模型不断输出思考 token，直到其内部的置信感提示停止。充满自我反思和不确定性标记的路径会持续进行；而简单的问题则会提早结束。关于高效推理的研究一致发现，这种动态退出行为会在单次请求的计算中产生沉重的右尾（heavy right tails）——极小部分的输入消耗了不成比例的 token 和墙钟时间（wall-clock time）。
令人不安的是，在运行请求之前，难度是不可观测的。你可以估算它——路由和难度分类器正是为此而存在的——但真相只有在模型思考时才会揭晓。这意味着你的延迟分布在任何实用意义上都不再是静态的。它会随着你的流量组合而漂移：一次吸引了更难问题的产品发布，一群粘贴了更长文档的新用户，或者一个开始触及边缘情况的 Agent 工作流。你的基础设施没有任何改变，但 p99 却翻了一倍。
还有一个值得一提的叠加效应：过度思考（overthinking）。高效推理的相关文献表明，模型经常在推理路径的早期就得出了正确答案，但随后仍继续生成验证步骤。因此，长尾不仅仅是“难题耗时更长”。其中一部分是模型在已经解决的问题上空耗 token——产生了纯粹的延迟和成本，却没有任何质量回报。你的 p99 既包含合理的难度，也包含病态的沉思，从外部看，它们完全一样。
“调高超时时间”会将延迟 SLO 转化为成本事故
当推理请求开始触发你设置的 30 秒超时限制时，本能的修复方案是调高超时时间。这看起来很安全，实则不然，原因在于计费模式。
当推理模型思考时，你正在为它产生的每一个 token 付费——思考 token 的计费方式与输出 token 相同，而在顶尖推理模型上，输出定价通常是输入定价的数倍。因此，超时不仅仅是延迟的边界，它还是单次请求唯一的硬性成本上限。将超时从 30 秒提高到 180 秒，每个失控请求在系统放弃之前，现在可能会多消耗六倍的成本。再叠加重试策略，将同一个硬核提示（hard prompt）再次发给同一个模型——由于问题难度并未改变，第二次思考的时间依然会同样长——你实际上构建了一个机器，它通过反复付费来响应难题。
这就是延迟 SLO 如何悄然演变成成本事故的。过程几乎总是一样的：
- 尾部请求开始超过超时限制，用户看到错误。
- 调高超时时间，错误消失。
- 增加重试和对冲（hedges）以保护剩余的尾部。
- 账单寄到，财务询问为什么在流量增长 20% 的情况下，token 支出翻了三倍。
自动扩缩容（Autoscaling）也有同样的盲点。大多数扩缩容策略以请求速率或 GPU 利用率为核心指标，这两者都假设请求是大致等同的工作单元。当单次请求的计算量相差一个数量级时，请求速率就无法再预测负载了。十个困难请求就能使足以轻松服务一百个简单请求的容量达到饱和。更新的推理服务层研究通过基于工作量的信号来解决这个问题——基于 token 速率（流经 prefill 和 decode 阶段的 token 速率）而非请求数量进行扩缩容。但如果你的扩缩容策略早于推理模型出现，它几乎肯定是在测量错误的指标，并且在队列已经积压之后才做出反应。
对冲（Hedging）有效——前提是对冲到不同的模型，而不是副本
经典的尾部延迟（tail-at-scale）解决方案是“对冲请求”（hedged request）：如果主请求在 p95 预期延迟内没有响应，则向另一个副本发送一个备份请求，并采用最先完成的结果。在 Google 著名的 BigTable 基准测试中，这种方法以约 2% 的额外负载将 p99.9 从 1,800 毫秒降低到了 74 毫秒。它之所以奏效，是因为变慢的原因在于环境——另一个副本通常不会遇到同样的环境问题。
推理延迟打破了这一假设。如果请求变慢是因为问题本身很难，那么在完全相同的模型上运行的备份请求也会思考同样长的时间。你付出了两倍的代价，却等待了同样的时间。对冲策略依然存在，但第二个请求必须在真正导致延迟的维度上有所不同：推理开销（reasoning effort）。
行之有效的模式是这样的：向你的高性能推理模型发送主请求。如果“首个答案 Token 时间”（time-to-first-answer-token）超过了根据你的延迟分布（该请求类别的 p90 或 p95）设定的阈值，则向一个较小或低开销的配置发送对冲请求：例如非推理模型，或者限制了推理开销的相同模型。如果主请求在截止日期内完成，则取消对冲并流式传输更好的答案。如果截止日期先到，则提供对冲请求的答案。这通常已经足够好了，因为大多数超出截止日期的请求正是因为陷入了推理纠结（rumination），而不是因为任务本身真的无法完成。
两个实现细节比看起来更重要：
- 基于答案的首个 Token 时间进行对冲，而不是 HTTP 响应。 推理模型在回答之前会流式输出思考过程；HTTP 响应头很早就到达了，但它们什么也说明不了。你需要的信号是“模型是否已经开始致力于输出答案”。
- 限制对冲速率。 在对冲上设置令牌桶（token bucket）可以防止出现以下失效模式：当供应商出现部分故障（brownout）导致所有请求变慢时，每个请求都触发对冲，导致你向一个已经降级的系统注入双倍的流量。延迟对冲（deferred hedging）能将额外负载保持在个位数百分比；而在故障期间进行无限制的对冲则是自杀式的 DDoS。
这种成本计算是有利的，因为对冲目标模型很便宜。将 5% 的流量对冲到成本仅为十分之一的模型上，只会增加不到 1% 的支出，同时能为用户感知的尾部延迟设定一个硬性上限。
开销上限就是截止日期，因此要按路由进行设置
现在每个主流供应商都提供了一个调节模型思考程度的“旋钮”——推理开销等级（reasoning-effort levels）、思考预算（thinking budgets）或自适应开销参数。大多数团队只设置一次全局变量，取值标准仅在于能通过评估套件。这浪费了这个旋钮。开销上限本质上是延迟策略，而不同路由的延迟要求差异巨大。
研究方向也说明了这一点。诸如“具备 Token 预算意识的推理”之类的研究表明，通过提示（prompting）或训练模型以适应适当的预算，可以在大多数任务中减少 60% 以上的推理 Token，而准确度损失极小——因为默认的推理长度中有很多是冗余的，而非实质内容。具备预算意识和自我预算的方法都收敛于同一个原则：思考量的多少应该是任务的函数，因此上限也应该是任务的函数。
在操作层面上，这意味着你需要根据延迟容忍度对请求路径进行分类，并相应地分配开销：
- 交互式、阻塞用户（聊天回复、自动补全、行内建议）：低开销或无扩展思考，硬性超时设为秒级。如果一个请求确实需要深度推理，那就是产品设计问题——应该将其改为异步模式，而不是让用户看着加载图标转圈。
- 交互式但用户有预期（“深度分析”按钮、用户主动调用的研究代理）：中高开销，配合明显的进度展示，截止日期设为数十秒，并按上述方式进行对冲。
- 异步（评估、批量分类、隔夜代理运行、报告生成）：高开销，宽泛或不设单次请求截止日期，理想情况下应路由到针对延迟不敏感工作定价的批处理层级。
这种构架能让你的团队更好地理解：开销上限是模型真正可以服从的截止日期。超时是在你已经付过费后强行终止工作；而开销上限则是从一开始就防止过度工作的尝试。一个是断路器（circuit breaker），另一个是准入控制（admission control）。你两者都需要，但开销上限承担了主要的经济效益。
一个警告：在某些模型上，开销参数控制的不只是思考长度——它还会改变模型使用工具和遵循指令的彻底程度。要像对待更换模型一样对待开销变动：针对每个路由运行评估，不要只是全局调低参数并假设质量保持不变。
围绕难度而非仅仅时间重建 SLO
如果延迟是难度的函数，而难度是流量的属性，那么对所有请求使用统一的延迟 SLO 就是一种范畴错误（category error）。当你的用户开始问更难的问题时，它会触发警报；而当简单请求的性能悄悄下降时，它却显示正常。解决方法是让衡量单位匹配新的现实。
具体来说，这意味着按请求类别细分延迟 SLO——至少将开启推理的路由与普通补全（completion）路由分开，理想情况下应按开销层级分开。在每个类别中，将“首个答案 Token 时间”和“Token 吞吐量”与“总持续时间”分开跟踪，因为它们的失效模式不同：首个 Token 慢意味着排队或思考时间长；吞吐量慢意味着推理能力（serving-capacity）有问题。此外，除了以时间计量的错误预算外，还要保留一个以 Token 计量的错误预算——按百分位统计每个请求的 Token 数——因为这是针对成本异常以及在更换模型或提示词后出现“过度思考”回归的早期预警信号。
更深层次的转变在于文化。二十年来，肥大的延迟尾部意味着你的系统运行异常，解决方案在于基础设施。但在推理模型中，尾部在某种程度上是信号：它是难题所在，盲目地切断它意味着对难题给出了糟糕的答案。你的工作不再是消除尾部，而是明确地为每个路由决定每个请求有权消耗多少思考量——并确保当模型需要的思考时间超过截止日期时，系统能降级为一个快速的回答，而不是返回一个超时错误和一张重试的账单。
处理得好的团队都有一个共同习惯：他们将“模型可以思考多久”视为一个产品决策，按端点记录下来，并附带截止日期、对冲路径和预算。处理得差的团队则只有一个全局超时常量，且每季度翻一倍。思考的 p99 时代已经到来；唯一的问题是你在管理它，还是仅仅在为它买单。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
