33 篇博文 含有标签「latency」

一个在所有转写层级基准测试（benchmark）中得分完美的语音智能体，在实际通话中可能仍然让人感觉有些微妙的不对劲。文字没错，推理也没错。仪表盘上的端到端延迟显示为 520ms，这正是预期的目标。然而，电话另一端的人却不断卡顿、抢话、重说，甚至提前挂断。团队发布了更好的模型，数据提升了，但体感依然没有改善。

究其原因，与模型说了什么几乎无关，而与它何时说话几乎全盘相关。语音并非仅仅是附带了音频的文本。人类的对话运行在一个严密的半双工（half-duplex）协议之上，包含插话（barge-in）、反馈信号（backchannel）和重叠语音，其时间预算是以毫秒计算的。大多数语音智能体的问题，在解决了第一周的幻觉修复后，本质上都是轮次协商（turn-negotiation）问题。而轮次协商是架构层面的问题——你无法通过提示词工程（prompting）来解决它。

如果你曾剖析过一个莫名其妙跑得很慢的AI Agent，大概率会发现一个瀑布。Agent调用工具A，等待，再调用工具B，等待，再调用工具C——即便B和C根本不依赖A的结果。你为1倍的工作量付出了3倍的延迟。

这个模式并非边缘情况，而是几乎所有Agent框架的默认行为。模型在单次响应中返回多个工具调用，执行循环则逐一按顺序运行它们。修复并不复杂，但前提是要有一种可靠的方法来识别哪些调用真正相互独立。

大多数构建多步 agent 管道的工程师会在第一次生产故障后约两周发现同一个问题：他们在 API 网关设置了 5 秒超时，但 agent 管道有四跳，而整个系统的行为就好像根本没有超时一样。第三跳的 agent 不知道上游调用方三秒前就已放弃等待，它继续运行、继续调用工具、继续生成 token——而用户早已离开。

这不是配置错误，而是结构性问题。延迟约束默认不会跨 agent 边界传播，主流编排框架也没有任何一个让截止时间传播变得容易。结果是一类看起来像延迟问题、实则是上下文传播问题的故障。

你的产品在第 10 秒到第 45 秒之间存在一个“空洞”，在这个时间段内，你设计的任何东西都不再起作用。用户在 10 秒左右就会放弃无响应的 UI —— Jakob Nielsen 在 90 年代就确定了这个阈值，现代的眼动追踪研究显示的偏差也不过一两秒。现代智能体（Agent）的工作通常需要 30 到 120 秒。多步规划、检索、几次工具调用，可能在最终输出前还要经过一轮反思 —— 延迟预算不再只是预算，而是一个巨大的深渊。

大多数团队在第一次发布智能体功能并查看会话录像时都会发现这一点。用户疯狂点击提交按钮。他们将查询粘贴到第二个标签页中。他们关闭窗口并从头开始重试，坚信系统已经崩溃。功能本身没问题，但等待过程出了问题。“加载动画出现”与“答案送达”之间的空白地带是 AI 产品设计中最被忽视的环节，而它正是决定用户认为你的智能体是聪明还是死机的关键。

你发布的每一个 AI 功能，在成为产品决策之前，都首先是一个架构选择：这个模型调用是发生在用户的请求链路中，还是在用户无需等待的地方运行？这个选择通常由编写第一个原型的人做出，之后便不再被审视，并默默地决定了该功能在余下生命周期中的 p99 延迟。当事后分析（Post-mortem）询问为什么生产环境仪表盘在每周一上午 10 点变得无法使用时，答案几乎总是：某些本应属于冷路径（Cold-path）的东西被焊死在了热路径（Hot-path）中——而在 p50 时表现良好的模型，在流量扇出（Fan out）时，其 p99 的表现会变得极具灾难性。

热路径与冷路径的区别比 LLM 还要早。CQRS、流式架构、Lambda 架构——它们都在“必须立即响应”和“可以最终送达”之间划定了相同的界限。AI 工作负载的不同之处在于，走错方向的代价比以前高出了一个数量级。一个耗时 50 ms 的同步数据库查询变成 200 ms 是一次回归（Regression）。而一个在 p50 时耗时 1.2 秒的同步 LLM 调用在 p99 时变成 11 秒，则是你无意中做出的一项商业决策。

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样，这个参数要么没设置，要么设成了模型的最大值，或者是半年前随便选的一个像 4096 这样的整数，之后就再也没动过。它是 API 请求中一个显眼的预算旋钮，却在默默地为你从未使用过的冗余买单。

在中等商业模型上，输出 token 的成本大约是输入 token 的四倍，而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的：你在 max_tokens 中留下的每一分未使用的余量，都是你可能需要支付的成本；而且由于解码是顺序进行的，你生成的每一个 token 都会线性地增加你的 P50 延迟。然而，大多数生产系统都将此参数视为安全阀——设置得高高的，然后忘掉它，继续开发。

大多数团队引入护栏的方式，和引入日志一样随意：直接挂上去，以为代价很小，然后继续往下走。但代价并不小。一次内容审核检查要花 10–50ms，再加上 PII 检测，又是 20–80ms；再叠上输出 schema 校验和毒性分类器，在第一个 token 到达用户之前，串行开销就已累积到 200–400ms。加上 500ms 的模型响应，你那个"快速"的 AI 功能现在给人的感觉就是迟钝。

把锅甩给 LLM 是错的。护栏才是瓶颈。解决方案不是去掉安全措施，而是停止把安全检查当成一堆无差别的任务，改用架构思维来对待它。

大多数构建语音 AI 的团队都会以同样的方式发现延迟问题：在生产环境中，面对真实用户。演示 (Demo) 感觉不错。原型 (Prototype) 听起来也令人印象深刻。但当有人在实际通话中使用它时，会觉得它很机械——不是因为声音不好听，而是因为每次回复前的微小停顿让整个交互感觉像是和卫星信号不好的人在说话。

这种停顿几乎总是在 600 毫秒到 1.5 秒之间。而目标是低于 300 毫秒。这两个数字之间的差距解释了语音 AI 系统实际构建方式的一切。

大多数 LLM 流水线在无意中表现出了令人尴尬的顺序执行特征。一个智能体调用天气 API，等待 300 ms，调用日历 API，再等 300 ms，调用流量 API，再次等待 —— 最后才综合出一个答案。如果这三个调用是并行运行的，那 900 ms 的总延迟本可以缩减到 300 ms。没有人故意将系统设计成顺序执行；这只是在编写一个接一个的异步调用时自然而然产生的结果。

推测执行（Speculative execution）是一系列技术的统称，这些技术通过在你确定需要某些工作之前就提前执行它们，来降低感知的延迟 —— 包括运行并行的假设、预取可能的后续步骤以及同时生成多个候选输出。这些技术直接借鉴了 CPU 设计，自 20 世纪 90 年代以来，处理器就一直在推测性地执行未来的指令。应用到 AI 流水线时，这种本能 —— 押注可能的结果、取消失败者、接受偶然的浪费 —— 可以产生显著的加速。但如果你不小心选择应用时机，协调开销也可能会抵消所有的收益。