工具延迟尾部：为什么 p99 重塑了智能体架构而 p50 掩盖了问题

我上个季度合作过的一个团队发布了一个包含七个步骤的智能体（agent），并以显而易见的方式构建了其延迟预算：搜索返回耗时 200ms，SQL 查询耗时 80ms，电子邮件发送耗时 150ms，链条中的其他环节以此类推。将中位数相加，再加入一些缓冲，数学计算表明该智能体能轻松地保持在两秒的 SLA 之内。仪表板连续几周证实了这一点。中值延迟（median latency）表现优异。接着，客户开始抱怨该功能慢得无法使用，而仪表板看起来依然是代表正常的绿色。

他们互相转述的故事是错误的，因为他们是围绕 sum(p50) 构建的架构，而用户体验到的却是 sum(p99)。经过三到四个步骤后，链条中的 任何 环节掉入其自身尾部概率（tail probability）的可能性就不再微不足道了。经过七个步骤后，这种概率接近于掷硬币。没有任何单项工具的仪表板变红，因为没有任何单项服务表现异常 —— 问题在于没有人负责这种乘法复合（multiplicative composition）效应。

这并不是什么新教训。分布式系统研究人员已经为此撰写了四十年的文章。新鲜的是，每个构建智能体的团队都在最后期限的压力下，痛苦地重新发现这一点。

没人算的乘法链数学

假设一个工具的中位数是 200ms，p99 是 1.5 秒。单独使用一次时，它几乎符合任何合理的预算。将其与另外六个具有类似特征的工具组合在一起，用户感知到的延迟就不再是中位数的总和，而是开始变成每次调用落入的百分位数值的总和。乘法链的中位数由每个环节的中位数主导，这就是为什么单项工具的仪表板保持绿色的原因。而用户感知的体验受链条尾部（tail）的支配，这就是为什么支持工单不会保持绿色的原因。

算术是无情的。如果每次调用有 1% 的概率落入其自身的 p99 尾部，那么在一个七步链条中，至少有一次调用触及尾部的概率是 1 − 0.99⁷ ≈ 6.8%。这就是智能体运行中端到端延迟受最差情况工具支配（而非团队预算中的中位数）的比例。如果将链条增加到二十步 —— 这在进行规划、浏览、阅读和综合的研究型智能体中越来越常见 —— 这个概率就会超过 18%。现在，近五分之一的运行是尾部运行，而单项工具端没有任何监控能察觉到这一点。

Dean 和 Barroso 在 2013 年发表的 "Tail at Scale" 论文在仓库规模（warehouse-scale）的服务中具象化了这一点：当一个请求分发到一百个后端时，至少有一个后端变慢的概率趋近于 100%。智能体目前还没有分发到一百个，但它们会分发到七个，然后是二十个，同样的复合效应开始生效。这些智慧是相通的。第一次阅读它的团队将其视为启示。事实并非如此 —— 只是大多数应用工程师已经有四十年不需要考虑这个问题了。

撒谎的仪表板

这种故障模式之所以如此持久，是因为每个人的仪表化（instrumentation）在孤立状态下看起来都是正确的。搜索团队的仪表板显示其服务的 p99 在 SLA 范围内。数据库团队的仪表板显示的也是如此。邮件发送服务是健康的。模型提供商的状态页面显示没有事故。每个工具的所属团队都可以理直气壮地回答 “我的服务达标了吗？” —— 是的。而这个答案并不是智能体用户所问的问题。

用户问的问题是端到端的。而在电话会议上，没有人拿薪水来负责这个数字。智能体产品经理看着工具团队构建的中值延迟仪表板，看到的是绿色。可靠性团队看着每个服务的 SLO，看到的是绿色。实际的 SLA —— 从接收请求到交付响应的墙上时钟时间（wall-clock time）—— 在实践中没有任何团队负责，在实践中也没有任何仪表板跟踪。

这就是组织故障模式。每个工具团队的指标都锁定在单次调用的边界上。智能体平台的指标锁定在单一步骤的边界上。用户的指标锁定在单一请求的边界上。这三个不是同一个数字，而且当你最需要它们一致时，它们的差异最为剧烈。

真正的准则是什么样的

在乘法链停止反噬之前，必须落实三件事。

根据 p99 而非 p50 设定预算。 一个中位数预算总和为 1.4 秒的七步智能体，其 p99 预算接近 9 秒，因为每个环节的尾部可能是其中位数的 5–10 倍，而链条会为特定运行中出现尾部延迟的环节支付代价。要么架构必须适应更大的数字 —— 这通常意味着更宽松的 SLA、更多的并发容量，或两者兼而有之 —— 要么链条必须缩短。数学规律就是如此。你不能根据你偏好的数字来设定预算。

对冲慢速工具调用。 这是搜索基础设施已经使用了几十年的技术。当一个工具调用在（例如）尾部阈值时间内没有返回时，向同一服务发送一个重复请求，并使用最先响应的那个。其成本是少部分额外的负载 —— 生产环境中的对冲实现报告了 5–10% 的额外开销 —— 而好处是任何单一的慢速环节都无法再挟持整个链条。Hedge 的作者报告称，在他们的参考实现中，通过约 9% 的开销将 p99 从 64ms 降低到了 17ms。对于受尾部限制（tail-bound）的工作负载来说，这种比例并不罕见。

加载中…