语音代理的最大延迟未必来自模型
摘要
语音代理常面临延迟问题，主要并非源于模型，而是端点检测等组件；优化VAD和采用合适的基准测试可有效降低轮次延迟。
构建语音代理时值得注意的一点是：单独基准测试每个组件，语音轮次仍可能保持在约1.5秒。一个典型轮次有七个跳转，仅端点检测就可能占用约700毫秒——大约占预算的53%。团队常花数周优化LLM延迟，却忽略了VAD配置。另一个常见错误：累加每跳的p95值。百分位数不可相加，因此该数字可能具有误导性。本网站上的一个计算器使用发布的供应商数据来建模完整的语音轮次延迟预算。如果您的实际数字不同，这个差距可能揭示真正的瓶颈所在。
相似文章
语音代理延迟：如何判断是模型还是网络的问题
关于区分语音代理中的延迟源于模型还是网络的指南，帮助开发者识别瓶颈。
你的语音助手响应慢可能不是因为大语言模型。
一位开发者驳斥了常见的观点，即LLM延迟是语音助手响应慢的主要原因，并解释说，延迟往往源于更早的阶段，如音频捕获、语音活动检测（VAD）和语音转文字（STT）。他建议记录特定的延迟指标，并测试不同的STT/TTS提供商和编排框架来诊断问题。
在修复流式传输后，语音代理延迟还隐藏在哪里？
本文讨论了在启用流式传输后，语音代理系统中隐藏的延迟来源，并寻求关于实时代理关键性能指标的建议。
为服务型企业运行生产级语音代理6个月：延迟计算远比演示所暗示的复杂。
在为服务型企业运行语音AI代理6个月后，作者揭示了现实世界中的延迟是双峰的（中位数约800ms，p95约2.4s），而p95决定了用户的感知。诸如VAD误触发、长提示词下函数调用退化、以及TTS质量等问题比LLM的选择更重要，而多语言支持则增加了显著的成本。
我们的语音代理p99为280ms，竞争对手为450ms，但用户却觉得我们的更慢。我们测量了原因。
一个语音代理团队发现，尽管端到端延迟更低（280ms对比竞争对手的450ms），但由于糟糕的打断响应时间（380ms对比60ms），用户感知更慢。他们确定了三项修复措施——内存锁定、VAD阈值调整和更小的TTS块——将100ms阈值下的打断率从41%提升至89%，让用户感觉更快。