大多数构建语音 AI 的团队都会以同样的方式发现延迟问题：在生产环境中，面对真实用户。演示 (Demo) 感觉不错。原型 (Prototype) 听起来也令人印象深刻。但当有人在实际通话中使用它时，会觉得它很机械——不是因为声音不好听，而是因为每次回复前的微小停顿让整个交互感觉像是和卫星信号不好的人在说话。
这种停顿几乎总是在 600 毫秒到 1.5 秒之间。而目标是低于 300 毫秒。这两个数字之间的差距解释了语音 AI 系统实际构建方式的一切。
为什么是 300 毫秒
人类对话的自然响应延迟为 200-300 毫秒。这是一个人说完话和另一个人开始说话之间的间隙——快到足以让人感觉是真正的对话而非轮流发言。研究一致表明，超过约 400 毫秒的停顿是可察觉的，而超过 1.5 秒的停顿会从根本上改变用户的心理模型，从“对话”变为“查询-响应”。一旦发生这种情况，再怎么提升音质也无法挽救体验。
问题在于，构建语音 AI 流水线需要串联三个组件——语音转文字 (STT)、大语言模型 (LLM) 和文字转语音 (TTS)——且每个组件都会增加延迟。一个幼稚的顺序实现如下：
等待用户说完话
将完整的音频发送给 STT → 等待转录 (150-500 毫秒)
将转录文本发送给 LLM → 等待完整响应 (350 毫秒-1 秒以上)
将完整的响应文本发送给 TTS → 等待音频生成 (100-500 毫秒)
开始播放音频
将这些加起来，在用户听到第一个词之前，你已经花费了 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% 的错误打断。
正确处理反向情况——插话检测 (barge-in detection) （用户在智能体回答中途打断）——需要双向管道支持。当用户插话时，系统需要在数十毫秒内取消缓存的 TTS 音频、清除 LLM 生成队列并重启 STT 流水线。能够正确处理这一点的系统让人感觉在进行真正的对话。做不到这一点的系统，就是用户所描述的“不听人说话”的那类。
传输并非无代价的变量 优化 STT、LLM 和 TTS 延迟的团队经常会忘记音频必须跨越网络传输。传输层并非没有代价。
WebRTC 是浏览器和移动应用的正确选择，它会增加大约 20-50ms 的传输延迟。传统的 PSTN（通过运营商基础设施进行的电话通话）会增加 150-700ms 的网络传输延迟，这主要源于运营商的交换路由。对于基于电话的部署，这意味着 300ms 以上的惩罚，无论如何优化模型都无法挽回。
地理位置的邻近性至关重要。如果你的用户在澳大利亚，而你的 LLM 供应商最近的数据中心在弗吉尼亚，那么在模型处理第一个 token 之前，你就已经增加了 200-300ms 的往返延迟。对于国际化部署，区域模型推理或对常见回复进行激进的缓存可以有所补偿，但根本的限制在于光速。
一个容易被忽视的细节：WebSocket 连接和 TCP 握手在每次请求时都会增加延迟。语音系统在整个通话过程中应使用持久连接，而不是每个请求建立一个连接。具有低算法延迟的 Opus 音频编解码器是语音管道的标准选择 —— 它增加了极小的编码延迟，并且在丢包时能优雅地降级。
为什么在你解决延迟后，“语音听起来依然很奇怪” 这是交付后常见的失败模式：延迟低于 300ms，转写准确，TTS 语音单独听起来很好 —— 但用户仍然反映感觉有些不对劲。
这个问题几乎总是韵律（Prosody） 。延迟衡量的是音频开始播放的时间；而韵律决定了音频听起来是否自然。人类的言语具有节奏、重音、音高变化和语调模式，这些传达了词语之外的含义。LLM 生成的文本往往是陈述性的且结构均衡，这种方式无法自然地转化为语音。
TTS 系统已经有了巨大的进步，但它们是在合成文本，而不是在模拟一个人在对话语境中会如何自然地表达特定的回复。其结果是，回复听起来像是在朗读文档，而不是人在说话。
一些显示出实际效果的方法：
语气词（Disfluencies） ：提示 LLM 偶尔加入一些填充词（“嗯”、“让我查一下”），可以使回复听起来更自然，并为外部 API 调用争取时间，而不会让人觉得是系统卡顿。简洁性约束 ：为文本编写的长篇 LLM 回复并不适用于语音。具有自然对话结构的简短陈述句（“明白了，正在查询 —— 请稍等。”）比长篇大论效果更好。标点符号作为韵律信号 ：TTS 系统将标点符号作为言语节奏的代理。与没有显式标点引导的回复相比，能产生良好标点输出的结构化提示词始终能产生听感更好的音频。 外部 API 调用：延迟的变数 大多数生产环境下的语音代理在对话过程中需要调用外部系统 —— 数据库、CRM、调度 API。这是延迟预算变得不可预测的地方。
错误模式：在关键路径上同步发出 API 调用，阻塞 LLM 回复的生成直到调用返回，并寄希望于调用在 100ms 内完成。在实践中，外部调用的耗时从 50ms 到 500ms 以上不等，且波动很大。
生产模式：按可预测性对工具调用进行分类。对于在通话开始时几乎肯定会发生的调用（获取账户信息、加载客户上下文），请在第一次用户回复之前的通话启动阶段触发它们。对于在对话中途触发的调用，使用并发处理：在 API 调用并行运行时确认请求（“让我把信息调出来”），同时生成填充性回复音频来掩盖等待时间。如果调用超过了延迟阈值，则返回一句衔接语而不是保持沉默。
心理模型是：将外部调用视为需要掩盖的事件，而不是阻塞管道的同步操作。
衡量真正重要的指标 STT 的 WER、LLM 的 TTFT、TTS 的首字节时间等标准指标并不能捕捉到用户的真实体验。端到端延迟测试需要模拟实际的通话条件：音频输入经过真实的音频管道，全编排堆栈处于激活状态，测量从用户说话结束到代理音频开始的时间。
单组件基准测试对调试很有用，但不足以判断生产质量。组件之间的交互 —— token 流从 LLM 传导到 TTS 的速度、轮次检测模型是否造成了不必要的缓冲、插话（Barge-in）如何中断 TTS 队列 —— 才是真实延迟的所在，而这些只会在端到端测试中体现。
在生产环境中值得追踪的指标：
P50 和 P99 端到端延迟 （用户说话结束 → 第一个音频字节）误触发中断率 （代理过早打断用户的频率）插话处理成功率 （用户插话被正确处理的频率）轮次检测延迟 （语义完成后多久代理才做出反应） 对于语音来说，P99 与 P50 同样重要 —— 用户对异常体验的记忆比对平均水平的记忆更深刻。
技术栈决策 构建语音 AI 有三种架构方法，各有利弊：
级联流水线（批处理） ：STT → 等待 → LLM → 等待 → TTS。总延迟：800-2000 毫秒。适用于原型制作。在生产环境中不可接受。
流式流水线（自定义） ：每个阶段都向下一个阶段流式传输；对每个组件拥有完全控制。可实现 200-500 毫秒的总延迟。需要大量的编排工程工作，但在延迟、模型选择和错误处理方面为你提供最大的控制权。
全能 API （例如 GPT-4o Realtime、Gemini Live）：单个 API 在内部处理 ASR → LLM → TTS。总延迟：500-1200 毫秒。发布速度更快，灵活性较低，对单个阶段优化的控制有限。
正确的选择取决于你对质量和控制的要求。当进入市场的速度比延迟优化或模型选择灵活性更重要时，全能 API 是合适的。当你需要达到 400 毫秒以下的目标、集成特定领域的 TTS 语音或使用特定的 LLM 时，自定义流式流水线更为合适。
战略观察：随着全能 API 的改进，差距正在缩小。对于 2026 年的大多数团队来说，问题不再是构建自定义还是使用 API —— 而是你的延迟要求或定制需求是否极端到足以证明这些工程投入的合理性。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
