你的语音助手响应慢可能不是因为大语言模型。
摘要
一位开发者驳斥了常见的观点，即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%，让用户感觉更快。
@DanKornas: 实时语音智能体需要的不仅仅是 LLM 调用——它们还需要传输、语音组件、通话处理以及部署路径。
TEN 是一个用于构建实时多模态对话式 AI 智能体的框架，提供可配置的 STT、LLM 和 TTS 组件、可视化设计器，以及包括自托管和拆分部署在内的部署选项。
我给我的语音代理更换了TTS，结果它比任何其他方式都更有效地减少了人们实际感受到的延迟
作者分享了将语音代理中的TTS替换为专为双语（阿拉伯语和英语）对话设计的自定义模型（Banter 1）的经验，这显著降低了感知延迟。
语音代理延迟：如何判断是模型还是网络的问题
关于区分语音代理中的延迟源于模型还是网络的指南，帮助开发者识别瓶颈。