语音 AI 生产落地：构建 300ms 延迟预算

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

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

为什么是 300 毫秒

人类对话的自然响应延迟为 200-300 毫秒。这是一个人说完话和另一个人开始说话之间的间隙——快到足以让人感觉是真正的对话而非轮流发言。研究一致表明，超过约 400 毫秒的停顿是可察觉的，而超过 1.5 秒的停顿会从根本上改变用户的心理模型，从“对话”变为“查询-响应”。一旦发生这种情况，再怎么提升音质也无法挽救体验。

问题在于，构建语音 AI 流水线需要串联三个组件——语音转文字 (STT)、大语言模型 (LLM) 和文字转语音 (TTS)——且每个组件都会增加延迟。一个幼稚的顺序实现如下：

1. 等待用户说完话
2. 将完整的音频发送给 STT → 等待转录 (150-500 毫秒)
3. 将转录文本发送给 LLM → 等待完整响应 (350 毫秒-1 秒以上)
4. 将完整的响应文本发送给 TTS → 等待音频生成 (100-500 毫秒)
5. 开始播放音频

将这些加起来，在用户听到第一个词之前，你已经花费了 600 毫秒到 2 秒的时间。这种架构对于原型来说没问题，但它不是一个生产级的语音系统。

流式架构是必选项

语音 AI 中最大的单项延迟优化不是模型选择、硬件或网络路由，而是通过在所有三个阶段同时进行流式传输 (streaming) 来消除顺序等待。

在流式架构中，每个阶段都在前一个阶段完成之前开始：

• 流式 STT 在用户仍在说话时发出部分转录，通常以 20 毫秒的音频块为单位。LLM 在最后一个词说出之前很久就开始处理部分转录。
• 流式 LLM 在 token 到达时立即发送给 TTS，而不是等待完整的响应。
• 流式 TTS 从第一个句子片段开始合成音频，并在 LLM 仍在生成后续段落时将音频块流式传输给客户端。

在实践中，流式 STT 可节省 100-200 毫秒，流式 TTS 可节省 200-400 毫秒，且 LLM 生成与 TTS 合成之间的重叠会在此基础上进一步节省时间。总的来说，与批处理 (batch processing) 相比，实现良好的流式架构可减少 300-600 毫秒的端到端总延迟。

这就是为什么预算分解比单一数字更有用。300 毫秒的目标大致分配如下：

阶段	预算
STT 最终确定	50-100 毫秒
LLM 首字延迟 (TTFT)	100-200 毫秒
TTS 首包延迟 (TTFB)	50-80 毫秒
传输 (WebRTC)	20-50 毫秒

如果任何阶段超出了预算，用户就会察觉。LLM 几乎总是瓶颈——它是最难优化的，且处于链路的中间。

模型选择受限于延迟

大多数团队最初根据质量基准选择 LLM。对于语音，你需要重新审视这一点：主要的限制因素是首字延迟 (TTFT)，而不是吞吐量或基准测试分数。

不同供应商之间的差异很大。在当前的生产系统中，像 Groq 托管的 Llama 变体等快速模型可以实现 50-100 毫秒的 TTFT。gpt-4o-mini 的运行速度为 120-200 毫秒。Gemini Flash 1.5 约为 300 毫秒。GPT-4o 大约为 700 毫秒。前沿推理模型——o3、带思维链 (thinking) 的 Claude——对于实时语音循环来说完全不予考虑；它们的延迟是以秒而非毫秒计的。

这造成了真正的能力权衡。速度足以胜任语音的模型往往较小，在复杂推理、工具使用或细微对话方面能力较弱。天下没有免费的午餐：部署速度较慢、能力更强的模型需要其他架构补偿（激进的流式传输、对冲、限制响应长度）以保持可接受的感知延迟。

一个值得考虑的模式是 LLM 对冲 (hedging)，即并行运行两个 LLM 调用，并使用最先返回可用首个 token 的那个。这显著降低了 P99 延迟，而无需提高平均性能，但 P99 正是决定用户是否将体验描述为“偶尔卡顿”的关键。

没人告诉过你的话轮检测问题

流式架构解决了其中一个延迟来源。话轮检测 (Turn detection) 是另一个团队经常低估的问题。

语音活动检测 (VAD)——检测音频中包含的是语音还是静默——是决定用户何时结束说话的朴素方法。它有效，但它引入了延迟底线：VAD 通常需要 600 毫秒的静默才能触发响应。在 300 毫秒的预算下，在 LLM 看到第一个字符之前，你已经用掉了两倍的预算。

更微妙的是，仅使用 VAD 的系统深受误报 (false positives) 之苦。句中停顿、犹豫和拖尾元音在 VAD 检测器看来都像是静默。智能体在用户还在构思时就开始回应，这种感觉比慢更糟糕——它让人觉得系统出故障了。

生产环境的解决方案是语义话轮检测 (semantic turn detection)：一种轻量级模型，它结合了声学信号（音调下降、能量下降，通常代表提问结束）和词法信号（句末 token、疑问标记）来确定对话的完整性。语义端点检测可以将真实的话轮结束检测降至 300 毫秒以下，同时与仅使用 VAD 的方法相比，减少约 45% 的错误打断。

加载中…