你的语音助手响应慢可能不是因为大语言模型。
摘要
一位开发者驳斥了常见的观点，即LLM延迟是语音助手响应慢的主要原因，并解释说，延迟往往源于更早的阶段，如音频捕获、语音活动检测（VAD）和语音转文字（STT）。他建议记录特定的延迟指标，并测试不同的STT/TTS提供商和编排框架来诊断问题。
调试了几个语音助手流程后的感想：每个人都先责怪LLM。但很多“这个语音助手感觉很慢”的问题，在LLM甚至拿到稳定的转录文本之前就已经出现了。延迟可能来自：麦克风/音频捕获 WebRTC / SIP / 电话 VAD STT 第一个部分结果 STT 最终结果 端点检测 LLM 第一个 token 工具调用 TTS 第一个音频 音频播放 中断处理 如果你只测量总响应时间，你什么也学不到。我建议记录：user_speech_start stt_first_partial stt_final llm_first_token tool_call_start tool_call_done tts_first_audio playback_start barge_in_detected 对于STT，我会测试Deepgram、AssemblyAI、Smallest AI Pulse、Speechmatics、Soniox、OpenAI realtime/transcribe。对于TTS，我会测试ElevenLabs、Cartesia、Deepgram Aura、PlayHT。对于编排，根据你想要的掌控程度，可以选择LiveKit/Pipecat/Vapi/Retell。奇怪的是，最快的演示栈并不总是最好的生产栈。在真实通话中，端点检测和部分结果的稳定性非常重要。你们是怎么测量延迟的？p50？p90？p95？还是仅仅“感觉像真人”？
相似文章
为服务型企业运行生产级语音代理6个月：延迟计算远比演示所暗示的复杂。
在为服务型企业运行语音AI代理6个月后，作者揭示了现实世界中的延迟是双峰的（中位数约800ms，p95约2.4s），而p95决定了用户的感知。诸如VAD误触发、长提示词下函数调用退化、以及TTS质量等问题比LLM的选择更重要，而多语言支持则增加了显著的成本。
我们的语音代理p99为280ms，竞争对手为450ms，但用户却觉得我们的更慢。我们测量了原因。
一个语音代理团队发现，尽管端到端延迟更低（280ms对比竞争对手的450ms），但由于糟糕的打断响应时间（380ms对比60ms），用户感知更慢。他们确定了三项修复措施——内存锁定、VAD阈值调整和更小的TTS块——将100ms阈值下的打断率从41%提升至89%，让用户感觉更快。
AI语音代理的实际工作原理
关于AI语音代理五层架构的详细解释，包括语音转文字、大语言模型（LLM）、文字转语音、编排器和电话通信，所有层均在500毫秒延迟约束下运行，以保持自然的对话流畅度。
我搭建了一个完全离线的语音循环，对接Ollama和LM Studio——100% CPU，无需GPU，数据绝不离开你的电脑（Silero VAD + Parakeet STT + Supertonic TTS 3）
一个完全离线、仅使用CPU的语音循环，用于本地大模型，采用Silero VAD、Parakeet STT和Supertonic TTS，通过一条命令整合安装。兼容Ollama、LM Studio以及多种代理框架。
在构建 AI 辅导系统时，延迟比模型选择更重要
一位从业者认为，在 AI 辅导系统中，语音启动延迟才是关键因素，而非模型的选择。他建议将语音启动延迟控制在 1 秒以内，并强调流式 TTS 是优化效果最显著的手段。文章梳理了从 ASR 到 TTS 再到虚拟形象同步的完整处理链路，并指出延迟叠加最严重的环节。