语音智能体延迟怎么压：一句话结论
端到端延迟压进 500 毫秒以内对话才「像人」，预算要按层分配：网络 30-80ms 、 VAD 判停 150-300ms 、 LLM 首 token 150-400ms 、 TTS 首音频 100-200ms——先选架构，再逐层抠。
先选架构：级联管线 vs 单模型语音到语音
OpenAI 官方语音智能体指南把架构分成两条路，这是所有延迟讨论的起点：
| 架构 | 适合 | 特点 |
|---|---|---|
| 语音到语音（Speech-to-Speech） | 自然、低延迟的实时对话 | 模型直接处理实时音频输入输出，省掉中间转写环节 |
| 级联管线（Chained） | 流程可预期、复用已有文本智能体 | 应用层显式串起 STT → 文本推理 → TTS，每步可控可替换 |
级联管线的每一跳都要等上一跳完成才能开工：转写要等音频、推理要等转写、合成要等回复——流式传输能缩小差距但消不掉底数，且转写错误会级联放大。单模型架构一次前向完成音频进出，结构上就省 100-200ms，OpenAI 的 Realtime API 目标是 200-500ms 端到端。对延迟敏感的开放对话选前者，需要审计中间文本、复用现有文本智能体的选后者。
逐层预算与可动手的优化点
网络：30-80ms（基本不可优化）
主导因素是用户与你服务、与模型 API 的地理距离。能做的只有两件事：模型端点和你的服务部署在同一区域；有边缘加速端点就用。路由病态才值得花时间，否则别碰。
VAD 与轮次判定：150-300ms（最见功力的一层）
用户说完话到系统判定「他说完了」的耗时。纯静音阈值（如 200ms）是基线；生产级系统用韵律感知的判停模型，能压到 ~150ms 而不误断。这层的权衡是响应速度 vs 误打断率——判停太激进，智能体会在用户换气时抢话。成熟平台（Vapi 、 Retell 、 LiveKit）都把判停做成可调参数，自研不如调参。
LLM 首 token：150-400ms（软件侧最大杠杆）
- 开 Prompt Caching：稳定的系统提示词在服务端缓存，TTFT 能降 200-400ms，这是语音场景零成本的最大单项优化。
- 换小模型：Flash/Haiku 级小模型首 token 快 2-3 倍，语音对话里质量差距常不可感知而延迟差距非常可感知。
- 系统提示词写短：prefill 越少越快，语音场景对简洁提示词的敏感度远高于文本聊天。
- 别用推理模型：先思考两秒再回答的模型在实时语音里不可用。
TTS 首音频：100-200ms（最常被忽视）
选主打低延迟的合成服务（OpenAI TTS 、 Cartesia 、 Deepgram Aura 都瞄准 200ms 内），边合成边播——第一个音频块在收到首批 LLM token 后 100-200ms 内就该到耳朵，绝不能等整句合成完。
打断（Barge-in）与节奏恢复
对话感不只取决于快，还取决于被打断后的恢复质量：用户说「等等，不对」，智能体要立刻停、听、再答。好的设计是优雅的打断恢复——偶尔误判打断也没关系，只要恢复顺畅，判停参数激进一点换来 200ms 级响应反而值得。评估时看 P95 端到端延迟和打断后恢复时长，别只看平均值。
落地路线
- 先做需求判断：要自然对话选语音到语音；要中间文本可审计、复用文本智能体选级联管线。
- 用平台 SDK 起步（如 OpenAI RealtimeSession / VoicePipeline），别先自建传输层。
- 系统提示词压缩到最短，开 Prompt Caching 。
- 接入后逐层测延迟：网络、判停、首 token 、首音频，找到最大头再优化。
- 上线前压测 P95 延迟与打断恢复，而不是只在实验室测平均。
单模型语音方案的深入分析见 OpenAI Realtime API 实战；智能体本身的构建方法（工具、交接、护栏）与文本智能体一致，参考 OpenAI Agents SDK 入门。
常见问题
800ms 的延迟真的不能接受吗？
级联管线就一定慢吗？
延迟和成本怎么平衡？
评论 (0)