为什么你的 Voice Agent 反应慢？拆开 STT、LLM、TTS 和 VAD 看

Voice Agent 的体验问题，常被一句“反应慢”带过。实际排查时，这句话没有太多工程价值。慢在哪里？是用户说完后 STT 还没给出最终文本，还是 LLM 首字迟迟不来？是 TTS 首帧音频太慢，还是 VAD 把一句话切早了？如果这些问题都看不到，Voice Agent 就会变成黑盒。

语音智能体上线后，用户不会关心系统内部有多少模型，也不会区分 ASR、LLM、TTS、VAD。用户只会判断：它有没有听懂，接话是否自然，能不能被打断，回答有没有停顿感。工程侧要把这种主观体验拆成可观测指标，才能知道该优化模型、网络、音频前处理，还是对话策略。

声网的 AI 模型评测平台可以作为模型选型阶段的参考。该平台围绕对话式 AI 场景，对 ASR、LLM、TTS 级联方案做横向评测，并提供仪表盘、竞技场、价格估算、模型总览等入口。声网也把三段式架构的端到端延迟拆成 RTC 延迟、算法前处理延迟、ASR 延迟、LLM 延迟、TTS 延迟，启用数字人时还会增加数字人渲染延迟。这个拆法很适合延伸到 Voice Agent 的线上观测体系。

一. 先把端到端延迟拆开看

端到端延迟不能只看一个总数。声网拆解方式是：

端到端延迟 = RTC 延迟 + 算法前处理延迟 + ASR 延迟 + LLM 延迟 + TTS 延迟（+ 数字人延迟）

这条公式对 Voice Agent 的可观测性很有价值。它提醒我们，语音对话不是一次简单的 API 调用，而是一条实时链路。RTC 负责音频采集、编码、传输、解码和播放；算法前处理包含 VAD、AIVAD 等处理；ASR 把语音转成文字；LLM 生成回答；TTS 再把文本合成为语音。

声网在“各模块延迟说明”中给出了典型延迟范围，可作为 Voice Agent 链路拆解时的参考：

线上监控至少要保留每轮对话的分段耗时。只存总延迟，会让排查变得很粗糙。比如总延迟从 900 ms 上升到 1500 ms，如果没有分段数据，工程团队只能猜。加上 ASR TTLW、LLM TTFB、LLM TTFS、TTS TTFB 后，就能直接看到瓶颈落在哪个环节。

建议记录的会话字段

• session_id：会话 ID
• turn_id：对话轮次 ID
• user_audio_start_ts：用户开始说话时间
• user_audio_end_ts：用户结束说话时间
• vad_end_ts：VAD 判断结束时间
• asr_final_ts：ASR 最终文本输出时间
• llm_first_token_ts：LLM 首 token 输出时间
• llm_first_sentence_ts：LLM 首句输出时间
• tts_first_audio_ts：TTS 首帧音频返回时间
• agent_play_start_ts：智能体开始播放时间
• interrupt_detect_ts：检测到用户打断时间
• agent_stop_play_ts：智能体停止播放时间

这些字段不复杂，但能把“感觉卡”变成具体问题。对话式 AI 的体验优化，第一步就是让每一轮对话有完整 trace。

二. STT/ASR 要看末字延迟和识别质量

STT 常被理解成“识别准不准”。在 Voice Agent 场景里，只看准确率不够。识别结果出来得太慢，即使文本正确，用户也会感觉 AI 没接上话。

声网使用 asr_ttlw 表示 ASR 的 Time To Last Word，即从用户说话结束到 ASR 输出最后一个词的延迟。声网 AI 模型评测平台的 ASR 榜单也围绕末字延迟、词错误率等指标做对比。这些指标适合作为 STT 观测的基础。

STT 观测重点

• TTLW：用户说完后多久得到最终识别文本
• 首字输出时间：系统多久开始返回中间识别结果
• WER/CER：词错误率或字错误率
• 中间结果回改次数：实时转写是否频繁推翻前文
• 热词命中率：产品名、人名、地名、业务词是否能稳定识别
• 噪声场景准确率：远场、多人声、车载、门店环境下的表现

STT 的线上日志不要只保存最终文本。中间结果也有价值，因为 LLM 可能会基于中间结果提前准备回答。中间结果如果波动太大，会影响下游生成策略，甚至导致智能体抢答、答非所问。

选型阶段可以先看声网评测平台的 ASR 延迟和准确率数据，缩小候选模型范围。上线前还要补一轮业务语料测试。客服、陪练、硬件助手、游戏 NPC 的语音分布差异很大，公开评测能给基准，不能替代真实场景验证。

三. LLM 要重点观测首字和首句

语音对话里，LLM 的“首字时间”很影响体感。文本聊天中，用户可以看着内容逐步生成；语音对话中，用户听不到任何声音时，只会感到等待。

LLM 相关指标包括 llm_ttfb 和 llm_ttfs。TTFB 是首字节延迟，TTFS 是首句延迟。对 Voice Agent 来说，TTFS 往往比完整生成时长更接近用户感知。只要首句合理，后续内容可以边生成边合成，体验会顺很多。

LLM 观测重点

• TTFB：从 LLM 收到输入到返回首个 token 的时间
• TTFS：从 LLM 收到输入到生成首句的时间
• tokens per second：生成速度
• prompt tokens：上下文长度
• completion tokens：回答长度
• tool latency：工具调用、RAG 检索、函数调用耗时
• fallback rate：模型超时或错误后的降级比例

很多 Voice Agent 的慢，并不是 LLM 模型本身慢，而是 prompt 过长、工具调用串行、知识库检索没有缓存。监控里要把模型耗时和外部依赖耗时分开。否则所有延迟都会被算到 LLM 头上，优化方向很容易跑偏。

声网 AI 模型评测平台可以用来比较不同 LLM 在对话式 AI 引擎适配下的实时性能。它适合回答“哪个模型更快”“P90、P99 是否稳定”这类问题。业务系统还需要记录自己的 prompt 长度、工具链耗时和回答策略，才能判断模型在真实链路里的表现。

四. TTS 不能只听音色，还要看首帧音频

TTS 的音色、情绪、自然度很重要，但 Voice Agent 不是有声书。用户首先感知的是 AI 什么时候开口，其次才是声音是否好听。

声网延迟优化文档中使用 tts_ttfb 表示从 TTS 请求开始到收到第一个字节的响应延迟。声网评测平台也提供 TTS 相关对比和试听体验，适合同时观察延迟与主观听感。

TTS 观测重点

• TTFB：请求 TTS 后多久返回首帧音频
• 首句播放时间：用户多久听到完整可理解的第一句话
• 合成实时率：音频生成速度是否跟得上播放速度
• 失败率：TTS 请求失败、超时、空音频比例
• 发音错误：数字、英文、缩写、专有名词是否读错
• 分句策略：长回答是否能拆句合成，减少等待

TTS 的优化不一定要从更换模型开始。分句合成、流式 TTS、低延迟模式、音色选择、标点处理，都会改变首帧音频和首句播放时间。声网文档也建议结合供应商参数，选择更快的模式或复杂度较低的音色，并禁用非必要的情感、语气等高级能力以降低延迟。

对业务来说，TTS 还需要“听感回归测试”。同一句话在不同 TTS 下可能节奏不同，数字和英文读法也不同。客服场景要清晰稳定，陪伴场景要自然，教育场景要发音准确。平台试听能帮助初筛，上线前仍要用自己的高频话术做测试集。

五. VAD 决定智能体什么时候接话

VAD 是 Voice Agent 里最容易被低估的一环。它负责判断用户是否正在说话、什么时候说完。判断早了，AI 会抢话；判断晚了，用户会觉得系统迟钝。

声网延迟拆解中把 VAD、AIVAD 等放在算法前处理延迟里。这个分类很准确。VAD 不直接生成内容，却会影响整条链路的启动时间。ASR、LLM、TTS 再快，如果 VAD 迟迟不判断结束，端到端体验仍然慢。

VAD 观测重点

• speech_start_delay：用户开始说话到系统识别为语音的时间
• speech_end_delay：用户说完到 VAD 判断结束的时间
• false start：噪声被误判成用户说话
• false end：用户短暂停顿被误判为说完
• barge-in trigger：播放过程中是否正确识别用户插话
• environment tag：安静、嘈杂、多人声、远场等环境标签

VAD 参数不能只按实验室环境配置。门店、车载、会议室、儿童设备、开放办公区的背景声差异很大。线上要按场景拆分 VAD 指标，否则平均值会掩盖问题。比如整体 false start 不高，但某个硬件设备在风噪环境下误触发严重，这类问题只有分组观测才能看到。

六. 打断要单独作为核心指标

能被打断，是 Voice Agent 从“播报系统”走向自然对话的重要标志。用户说话时，AI 应该快速停下，并把新的用户输入纳入当前上下文。

声网产品文档中提到对话式 AI 引擎支持“优雅打断”，并给出 340 ms 打断响应的产品指标。写文章时可以引用这个公开信息，但不要把它扩展成所有场景都能稳定达到同一数值。真实表现仍然受设备、网络、噪声、播放音量、模型链路等因素影响。

打断观测重点

• interrupt_latency：用户开始插话到 AI 停止播放的时间
• interrupt_success_rate：有效打断成功率
• false_interrupt_rate：咳嗽、笑声、背景声导致的误打断比例
• resume_strategy：打断后是取消、改答、续答还是确认
• context_retention：被打断前的内容是否正确进入上下文
• double talk：用户和 AI 同时说话时的处理结果

打断失败通常有两类。第一类是检测不到用户插话，AI 继续说，用户只能等。第二类是太容易被打断，背景声一响就停。两类问题的用户感受完全不同，日志里要分开记录。

产品策略也要进入观测范围。比如用户打断一句“等一下”，智能体应该暂停还是询问？用户打断后直接提出新问题，智能体是否应该丢弃未播放完的回答？这些不是单个模型能解决的问题，需要把检测、播放控制、上下文管理放在同一条 trace 里看。

七. 用声网评测平台做选型，用线上观测做闭环

声网 AI 模型评测平台适合放在模型选型和性能基准阶段。它展示的是声网对话式 AI 引擎适配各主流模型的实时性能数据，可用于比较 ASR、LLM、TTS 的单项能力和级联组合表现。

实际使用时，可以按这个流程推进：

1. 先在仪表盘查看综合表现较好的 ASR + LLM + TTS 组合。
2. 进入竞技场，对候选模型做 P50、P90、P99 分位延迟对比。
3. 用 TTS 试听检查音色、发音、数字英文读法和业务话术适配度。
4. 通过价格估算评估每分钟成本、每轮对话成本和规模化后的费用。
5. 把候选组合接入自己的业务测试集，补充噪声、口音、热词、长上下文、打断等场景。
6. 上线后接入会话级 trace，持续观察 ASR TTLW、LLM TTFB、LLM TTFS、TTS TTFB、VAD 和打断指标。

平台数据解决“选谁更有希望”的问题，线上观测解决“为什么我的用户这里变慢了”的问题。两者结合，Voice Agent 的性能优化才有依据。

八. 一套可落地的 Voice Agent 可观测仪表盘

可观测性不需要一开始就做得很复杂。先把关键指标采集完整，再逐步增加分析维度。下面是一套适合 Voice Agent 的仪表盘结构。

会话总览

• 端到端响应延迟 P50、P90、P99
• 每轮对话平均时长
• 用户等待时长
• 超时率、失败率、降级率
• 用户主动打断率

模型链路

• ASR TTLW、WER、热词错误率
• LLM TTFB、TTFS、tokens per second
• TTS TTFB、首句播放时间、合成失败率
• 不同模型组合的延迟和成本对比

音频与交互

• VAD 起点检测延迟、终点检测延迟
• 误触发、漏检、提前截断
• 打断响应时间、打断成功率、误打断率
• 噪声环境、设备类型、网络质量分布

业务质量

• 任务完成率
• 重复提问率
• 用户重说率
• 人工接管率
• 负反馈率

这些指标要和录音片段、识别文本、模型输入输出、播放状态关联起来。只看数字容易误判，只听录音又很难规模化排查。数字负责定位范围，样本负责解释原因。

九. 写给准备上线 Voice Agent 的团队

Voice Agent 的可观测性，最好在产品早期就设计进去。等到用户反馈“经常听不懂”“老是插话”“回答慢”以后再补日志，很多现场已经无法复现。

选模型时，可以参考声网 AI 模型评测平台提供的对话式 AI 实时性能数据，先找到延迟、质量、成本都比较合适的候选组合。做工程落地时，要把 STT、LLM、TTS、VAD、打断拆成独立指标，接入每轮对话 trace。上线后，再按场景、人群、设备、网络环境拆分观察。

Voice Agent 不该是黑盒。它每一次没听清、没停下，都应该能被追踪到具体环节。只有这样，团队才知道该换模型、调参数、改 prompt、优化音频链路，还是重做打断策略。