延迟预算：那个亚秒轮次实际花在哪里。
在文本里，慢的智能体令人烦躁。在语音里，慢的智能体是坏了——人类把沉默解读为掉线、误解，或一台蠢机器，于是开始抢话。语音智能体被感知到的全部智能，都被一个数字卡住：来电者说完到智能体开口之间的那段间隔。本文是一道记账题：每一毫秒，去了哪里，以及如何花掉它。
真正要紧的那个数字是响应延迟，而且它很小。
自然对话中人类轮次切换的典型间隔约为 200 ms；人们远在整整一秒之前就会察觉并感到不适。语音智能体响应延迟——来电者停止 → 首段音频输出——端到端的工作目标是亚秒级，而最好的原生栈把模型的那一份推向几百毫秒。
对你在测什么要精确。响应延迟是用户语音结束到首段音频输出。它不是完整回复耗时，也不是孤立的模型 TTFT——它包含端点检测延迟，那往往是最大的一块，也是团队忘了计入的那块。
预算，逐行拆。
这个轮次是一个总和。你无法改善一个你没拆解过的总数，所以拆解它。
# response_latency = sum of these, ms network_in # mic/carrier → your edge endpoint_detect # "is the user done?" — often the biggest stt_finalize # cascade only; 0 for native S2S model_ttft # prompt → first output token/frame tts_first_audio # cascade only; first synthesized chunk network_out # your edge → speaker/carrier playout_buffer # jitter buffer before audio plays
对级联，每一行都活着。对原生语音到语音，stt_finalize 与 tts_first_audio 坍缩进 model_ttft——原生栈更快的结构性原因不是模型更好，而是少了两个串行跳。
端点检测是你选择花掉的延迟。
智能体在它相信来电者已说完之前不能开口。朴素的静音检测会等一个固定超时（比如 700 ms 的安静）——那个超时被直接加到每一个轮次的延迟上，无论来电者只是想到一半停顿，还是真的说完了。
这正是为何语义端点检测对延迟要紧，而不仅是对正确性：一个能从词语预测"这句话完整了"的模型，可以在约 100–300 ms 触发，而不必耗完一个最坏情况的静音定时器。你是用一个固定的悲观延迟，换一个可变的、通常更短的延迟。正确性那一面见 turn-taking-and-barge-in；此处它纯粹是预算。
把端点检测调低以省延迟，会直接抬高你在句子中途打断来电者的比率。这个旋钮在响应延迟与打断率之间做权衡。它没有免费档位——两者都测，按用例挑工作点，绝不要盲调其一而不看另一。
流式与部分结果掩盖你无法消除的延迟。
有些延迟不可约减。诀窍并不总是消除它，而是盖住它，让来电者从不经历沉默。
- 流式输出。在头几个 token 上就启动 TTS／发出音频，而非等完整回复。首段音频输出是指标；总长度不是。
- 流式输入。在部分转写文本上就跑 STT 并开始推理，这样来电者停下时模型已经"热"了。
- 快速应答。一句 150 ms 的"嗯哼"或"我查一下"会被感知为有响应，哪怕真正的答案还在两秒之外。被感知的延迟，而非挂钟时间，才是用户的现实。
- 推测。在部分结果上就开始起草回复；若最终转写文本相符，你已经付过模型成本了。
工具调用的悬崖。
上面的预算描述的是没有工具调用的轮次。智能体一旦必须打数据库或调 API，你就直接冲穿了亚秒预算——单是一次 400 ms 的 API 调用就是整个对话间隔。语音让工具延迟成为一等的对话问题，而非后端细节。
no-tool turn: ~500-900ms acceptable
tool turn: ~500ms + API + 2nd model pass
= often 2-4s → DEAD AIR unless covered
解法是对话性的，而不仅是工程性的：在工具调用之前和期间说话（"稍等，正在调出来…"）、并行跑相互独立的工具调用，且绝不让音频通道在后端干活时陷入沉默。这在 voice-tooling-and-state 中完整展开。
诚实的权衡。
你从端点检测或模型尺寸里夺回的每一毫秒，都是你花在更高打断率或更笨答案上的一毫秒——没有免费的延迟胜利，只有一个你判定值得的延迟代价。