我给我的语音代理更换了TTS，结果它比任何其他方式都更有效地减少了人们实际感受到的延迟
摘要
作者分享了将语音代理中的TTS替换为专为双语（阿拉伯语和英语）对话设计的自定义模型（Banter 1）的经验，这显著降低了感知延迟。
我一直在构建 Banter 1，这是一个针对需要在同一对话中处理阿拉伯语和英语的语音代理的文本转语音模型。我启动这个项目的理由是：我尝试过的大多数技术栈在英语上表现很好，但把阿拉伯语当成事后才考虑的事情，导致阿拉伯语输出平淡、发音错误或方言不对，而且句子中间的语码转换完全崩溃。我宁愿听到它在哪里出问题，而不是它哪里表现得好。所以，如果你在构建双语语音代理：你们目前是如何处理这个问题的？我的模型和你们正在使用的相比，到底能不能胜任？每种语言分开使用不同的语音，还是用一个模型处理两种语言？
相似文章
我们的语音代理p99为280ms，竞争对手为450ms，但用户却觉得我们的更慢。我们测量了原因。
一个语音代理团队发现，尽管端到端延迟更低（280ms对比竞争对手的450ms），但由于糟糕的打断响应时间（380ms对比60ms），用户感知更慢。他们确定了三项修复措施——内存锁定、VAD阈值调整和更小的TTS块——将100ms阈值下的打断率从41%提升至89%，让用户感觉更快。
语音代理的最大延迟未必来自模型
语音代理常面临延迟问题，主要并非源于模型，而是端点检测等组件；优化VAD和采用合适的基准测试可有效降低轮次延迟。
你的语音助手响应慢可能不是因为大语言模型。
一位开发者驳斥了常见的观点，即LLM延迟是语音助手响应慢的主要原因，并解释说，延迟往往源于更早的阶段，如音频捕获、语音活动检测（VAD）和语音转文字（STT）。他建议记录特定的延迟指标，并测试不同的STT/TTS提供商和编排框架来诊断问题。
为服务型企业运行生产级语音代理6个月：延迟计算远比演示所暗示的复杂。
在为服务型企业运行语音AI代理6个月后，作者揭示了现实世界中的延迟是双峰的（中位数约800ms，p95约2.4s），而p95决定了用户的感知。诸如VAD误触发、长提示词下函数调用退化、以及TTS质量等问题比LLM的选择更重要，而多语言支持则增加了显著的成本。
拆分了我们的实时语音栈（STT -> LLM -> TTS），成本降低约14倍。代价是延迟增加，外加一个我未预料到的好处。
将融合的实时语音AI栈拆分为独立的STT、LLM和TTS阶段，成本降低了约14倍，但延迟增加，意外的好处是内容护栏的可检查性提升。