42 篇博文 含有标签「latency」

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

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

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

研究跨语言话次转换（turn-taking）的语言学家们得出的结论惊人地一致：日常对话中说话者之间的间隙大约为 200 到 300 毫秒。任何更长的停顿都会被解读为犹豫、疏远或顺从；任何更短的停顿则会被视为打断。这个窗口是如此狭窄，以至于人类显然在对方说完之前就开始构思回复了 —— 倾听和计划是并行发生的，而非顺序进行。

错过这个窗口的语音智能体并不仅仅是让人觉得有点慢，而是让人觉得“不对劲”。在聊天产品中没人会注意到的 700 毫秒延迟，在语音交互中会让智能体显得迟钝、心不在焉，或者导致用户因失去耐心而打断它。1.5 秒的间隙足以让用户开始重复他们说过的话。满足这一时间预算并非简单的打磨工作 —— 它迫使开发者做出文本智能体从未面临过的架构选择，而这些选择重塑了整个技术栈的构建方式。

用户点击发送。智能体被配置了 30 秒的时间配额。规划器（planner）检查任务，发现一条耗时约 12 秒的“深度研究”路径和一条耗时 3 秒的“快速查询”路径，并自信地选择了深度路径，因为“我们有充足的时间”。28 秒后，响应返回，比团队上季度发布的 SLA 晚了 2 秒。仪表盘显示，智能体的推理是正确的，重试逻辑是正确的，工具调用也成功了。没有人能解释为什么用户的加载动画转了 46 秒。

这个 bug 不在任何单一组件中。它存在于组件之间的缝隙中，存在于一个系统从未想过要刷新的值里：智能体对于还剩多少时间的认知。在请求受理与模型的下一个规划步骤之间，发生了一次透明重试，挂钟时间在流逝，但截止时间的元数据却没有更新。模型现在正根据它在 15 秒前就已经花掉的预算进行推理，而它自己对此一无所知。

在上个季度的某个时候，你团队的一名工程师在 Slack 上发了一个帖子，开头是“模型变慢了”。他们展示了一张图表：你的助手功能的 p95 延迟从早上 7 点开始稳步攀升，在东部时间上午 10 点左右达到顶峰，午餐期间处于平台期，并在下午 5 点后悄然恢复。这种形态在第二天、第三天不断重复。团队追溯了他们的部署记录，指责了分词器（tokenizer）的更改，接着是上下文长度的退化，最后发现没什么是特别确定的。修复方案从未落地，因为 Bug 根本不在你的代码里。

顶尖模型提供商运行着共享的推理集群。当你的用户醒来时，北美其他地区也醒了，再加上欧洲的下午，以及每一家购买了相同 API 的公司的每一个内部工具。提供商端的队列深度翻倍，GPU 竞争加剧，你的 p95 延迟也随之翻倍——而你的代码库没发生一行代码变更。这是你技术栈中最可预测的生产事故，但几乎没有团队会为此建立仪表板。

你的 LLM API 返回的 P50（中位数）延迟为 800 毫秒。你的仪表板显示为绿色。你的 SLA 规定“两秒以内”。接着，一个用户提交了工单：“它转了 30 秒然后就放弃了。”你检查日志，发现 P99 延迟高达 28 秒。

这种差距——中位数与尾部延迟之间 35 倍的比率——并非偶然。这是 LLM 工作原理的结构性属性，仅仅通过调整超时时间是无法消除的。

大多数关于AI延迟的讨论都搞错了方向。团队痴迷于GPU利用率、模型量化和批处理大小。与此同时，真正让用户感到烦躁的延迟——AI开口说话前的那段停顿——几乎完全由推理开始前发生的事情决定。瓶颈在于上下文，而非算力。

首Token时间（TTFT）是决定AI功能感觉灵敏还是迟钝的关键指标。而TTFT主要由预填充阶段主导：在生成任何输出Token之前，处理完整输入上下文所需的时间。对于128K Token的上下文，预填充可能耗时数秒。GPU在努力工作，但用户什么也看不到。

解决方案不是更好的GPU，而是在用户提问之前就预先加载好上下文。

用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。

这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。

你的智能体管道很慢，于是你把任务拆分给五个并行子智能体。p50 下降了，你把它上线了。三天后，告警响了：一批用户请求超时。你挖进去发现 p99 从 4 秒涨到了 22 秒。单个智能体本身没有任何变化。超时是因为编排层在等最慢的那个——它以 1% 的概率遇到了检索抖动，但现在任何触碰全部五条路径的请求都会遇到这个概率。

这就是并行陷阱：这个模式看起来是显而易见的提速方案，实则以一种伤害真实用户更多的方式重构了延迟分布，p50 的改善远不能弥补 p99 的恶化。在生产基准测试中，单个智能体在 64% 的评估任务上能匹配甚至超过多智能体管道。并行扇出奏效的时候，确实奏效得很干净——但仅限于特定类别的问题。把扇出当作默认选项，才是错误所在。

查看你的网关重试配置。三次尝试。带有抖动的指数退避。在 5xx 错误和超时时重试。最大延迟限制在几秒钟。这看起来很合理，而且是某人两年前从微服务运行手册中复制过来的。但这正是你的 P99 是 P50 两倍、在服务商发生故障期间 Token 费用激增，以及相当一部分用户在默默流失前盯着 30 秒加载圈的最主要原因。

专为 50 毫秒 RPC 设计的重试策略在面对 8 秒的 LLM 调用时注定会失效。失败的形式不同，每次尝试的成本不同，用户感知到的时间维度也不同。默认设置并不安全，只是让人感到熟悉。大多数团队通过同样的方式发现这一点：在一次事后回顾中，网关日志显示响应成功，而客户的截图却显示 UI 已经卡死。

仪表盘显示智能体很快。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 倍。用户体验到的不是中位数，而是他们那次特定请求中最慢的一步。

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

我最近交流的一个团队为他们的 AI 助手构建了一个所谓的“深度防御”（defense in depth）流水线。一个输入分类器检查提示词注入；一个越狱过滤器扫描对抗性模式；模型生成回复；一个输出审核环节扫描结果；一个拒绝检测器检查模型是否回避了问题，如果是，则通过重新表述步骤，用更委婉的框架再次提问。评估套件显示该提示词在 1.4 秒内生成了答案，但真实用户的等待时间中值是 3.8 秒，p95 则超过了 9 秒。

每一个安全层都是一次往返。每一次往返都包含网络跳数、排队时间、模型加载和解码。当你将它们串行地堆叠在生成调用前后时，你为产品设定的延迟预算就会灰飞烟灭——而几乎没人在设计评审时考虑到这一点。更糟糕的是：流水线中最慢、最昂贵的路径往往是那些触发了安全边缘提示词的路径，而这恰恰是你的安全机制存在所要处理的长尾场景。你正在默默地用普通用户的账单来补贴这些长尾流量。

评估套件在凌晨 2 点运行。流量很低。缓存是冷的，但队列是空的。供应商的连续批处理程序有空闲插槽，并将以接近其 TTFT（首 Token 延迟）底线的水平处理每个请求。延迟分布很紧凑，评测模型分数稳定，仪表盘显示一片绿色。团队发布上线。

六个小时后，太平洋时间上午 8 点，同样的 Prompt 在美国早高峰期间进入生产环境。p95 延迟是评估报告的 2.4 倍。相当一部分请求从一个供应商那里收到了 529 错误，并回退到另一个供应商的较小路由层级。流式传输的节奏更加断断续续。评测模型（当天晚上对生产环境追踪样本进行重新运行）给出的中位数得分比凌晨 2 点给出的相同 Prompt 的得分低了半分。代码库没有变化。Prompt 没有变化。只是挂钟时间变了。

必须意识到的架构真相是：LLM 调用不是其输入 Token 的纯函数。它是一个随机分布式系统调用，其输入包括挂钟时间、供应商集群的负载、Prompt 缓存的状态、当前解码批次的大小，以及供应商负载均衡器在你的请求到达的那一毫秒所做出的路由决策。在凌晨 2 点运行评估的团队，是在一种用户永远无法体验到的条件下校准仪器。