多步 Agent 的延迟预算：为什么 P50 会说谎，而 P99 才是用户的真实感受

仪表盘显示智能体很快。P50 停留在 1.2 秒，团队开会庆祝，然后放弃率却在持续攀升。没有人关注用户真正体验到的那个图表。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E5%A4%9A%E6%AD%A5%E6%99%BA%E8%83%BD%E4%BD%93%E7%9A%84%E5%BB%B6%E8%BF%9F%E9%A2%84%E7%AE%97%EF%BC%9A%E4%B8%BA%E4%BB%80%E4%B9%88%20P50%20%E4%BC%9A%E8%AF%B4%E8%B0%8E%EF%BC%8C%E8%80%8C%20P99%20%E6%89%8D%E6%98%AF%E7%94%A8%E6%88%B7%E7%9A%84%E7%9C%9F%E5%AE%9E%E6%84%9F%E5%8F%97"]

这是生产环境中多步智能体可靠的失效模式：中位数是你能够达到的指标，而尾部延迟才是你用户感受到的指标。随着你在流水线上不断增加子调用，这两者之间的差距会呈非线性增长。一个包含四个步骤的智能体，即使每一步在“中位数表现”上都很快，其 P99 通常也会比任何单步操作糟糕 6 到 8 倍。用户体验到的不是中位数，而是他们那次特定请求中最慢的一步。

如果你的团队优化了错误的分位线，你交付的系统将拥有出色的基准测试表现和精美的演示效果，但在你从未监测的长尾场景中，用户正不断流失。

数学逻辑：为什么组合会惩罚中位数

以一个包含五个步骤的智能体为例：意图分类、文档检索、重排序、生成、验证。每一步的中位数（P50）为 200 毫秒，P99 为 2 秒 —— 也就是中位数与尾部之间有 10 倍的差距，对于基于 LLM 的步骤来说，这还是保守估计。直观的错觉会认为端到端的 P50 是 1 秒，端到端的 P99 是 10 秒，事情就结束了。

这种直觉在两个方向上都是错误的，而且错得最离谱的那个方向正是最伤人的。

对于独立延迟的加和，均值相加，方差也相加。标准差随步骤数量的平方根增长，因此平均而言，随着步骤的增加，系统看起来会更可预测 —— 这正是陷阱所在。平均化只在均值处起作用。总和的尾部是由任何一个组件的尾部主导的。具体来说：你的流水线中某一步落入其自身 1% 尾部的概率是 1 - 0.99^N。对于 N=5，这大约是 5%，这意味着用户可见的 P95 被拉低到了接近单步 P99 的水平。对于 N=10，用户可见的 P90 就会被拉低到单步 P99 的水平。

翻译一下：随着步骤的增加，“出现一个慢步骤”的分位线会向左移动，吞噬掉分布中越来越大的比例。Jeff Dean 和 Luiz Barroso 的《Tail at Scale》为扇出（fan-out）系统阐述了这种数学逻辑的经典版本 —— 一个平均延迟 10 毫秒、P99 为 1 秒的服务器，如果每次请求查询 100 次，产生的分布中 63% 的用户请求将超过 1 秒。同样的逻辑也适用于串行组合，只是坡度稍缓，而且它永远不会向着有利于你的方向弯曲。

这就是为什么在生产环境中观察中位数延迟的团队会被系统性地误导。他们的仪表盘测量的是最可靠的用户体验。而最不可靠的用户体验 —— 那些导致用户流失的体验 —— 在他们选择的分位线上是不可见的。

为什么 LLM 的尾部延迟比数据库更糟糕

经典分布式系统中的尾部放大源于排队、垃圾回收、网络波动和“嘈杂邻居”。这些尾部是真实存在的，但也是有界的 —— P99/P50 比例通常在 5-10 倍。而在 2026 年，基于 LLM 的步骤常规性地显示出 20-50 倍的比例，且原因更为复杂：

• 输出长度的波动。 一个在中位数情况下生成 50 个 token 的模型，当它决定“详尽”一点时，可能会生成 2000 个 token。逐 token 生成的延迟与输出长度呈线性复合关系，而输出长度是输入的属性，你无法仅凭输入就预测它。同一类 prompt 可能在 800 毫秒内返回，也可能耗时 28 秒，这取决于模型的决定。
• 提供商端的排队。 托管推理是多租户的。当提供商的 GPU 池饱和时，你会陷入一个你看不见的队列。状态页显示绿色并不代表尾部延迟也是健康的。
• 工具冷启动。 如果某一步调用了沙盒代码执行环境、无服务器函数或刚刚缩容的向量数据库，冷启动路径的耗时是热启动路径的 5-30 倍。
• SDK 内部的重试风暴。 许多提供商的 SDK 会在遇到 429 和 500 错误时使用指数退避算法透明地进行重试。除非你接入了正确的钩子，否则第一次失败的尝试及其退避过程在你的追踪（trace）中是不可见的，但在用户的等待中却非常明显。
• 流式 TTFT 与完整生成。 首字生成时间（TTFT）可能很合理，但完整生成时间可能非常糟糕。如果下游步骤阻塞并等待完整输出，你继承的是完整生成的延迟，而不是 TTFT。

实际意义在于：你无法通过阅读模型卡片或供应商的基准测试来估算端到端延迟。你必须针对你真实的 prompt 分布，测量每一步从端到端的尾部延迟。

“延迟预算”到底意味着什么

预算是系统与用户之间的一种契约。它表明：在 99% 的情况下，我们将在 X 秒内做出响应，并在剩下的 1% 情况下优雅降级。预算不是愿景。它是每一步都必须满足的约束。没有预算，“让它更快”就是无边界且无法确定优先级的口号。

一个有效的预算包含三个部分：

1. 端到端的目标分位线和数值。 选择用户真实感受到的指标。对于交互式 UX，这通常是 P95，有时是 P99。选择一个产品层面可以承诺的数值（“95% 的回答在 4 秒内完成”），而不是团队目前能达到的数值。

加载中…