实时语音助手:从 ASR 到 LLM 到 TTS

实时语音助手:从 ASR 到 LLM 到 TTS

本节摘要:一个「感觉对」的语音 Agent,端到端延迟要在 800ms 以内,知道你何时说完,能处理打断(Barge-in),还能在不卡顿的情况下调用工具。Retell、Vapi、LiveKit Agents、Pipecat 在 2026 年都达到了这条线。它们用的是同一个形态:一个流式 ASR、一个轮次检测器、一个流式 LLM、一个流式 TTS,全经 WebRTC 串联,每一跳都有激进的延迟预算。本节要求你构建一个,度量 WER、MOS、误截断率,并在丢包下跑它。你会学到为什么真正的难点不在模型调用,而在打断仲裁、轮次检测阈值与丢包下的反压。

对应原课程:Phase 19 · Lesson 03 · realtime-voice-assistant(原英文 phases/19-capstone-projects/03-realtime-voice-assistant/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 解释「感觉对」的语音交互的量化标准:首音频 p50 < 800ms、误截断率 < 3%、MOS > 4.2。
2. 搭建五级流式管线:音频入、ASR、轮次检测、流式 LLM、流式 TTS。
3. 实现打断(Barge-in):用户开口时立即取消 TTS、丢弃剩余 LLM 输出、重新武装 ASR。
4. 用侧信道跑工具调用,在延迟超 300ms 时让 LLM 预发一句填充语避免冷场。
5. 在丢包 3% 的条件下度量 WER 与轮次稳定性,并实现反压。
6. 在单台 g5.xlarge 上压测 50 路并发呼叫的可持续首音频 p95。

一、问题与直觉

语音是 2025~2026 年迭代最快的 AI 体验品类。OpenAI Realtime API、Gemini 2.5 Live、Cartesia Sonic-2、ElevenLabs Flash v3、LiveKit Agents 1.0、Pipecat 0.0.70 都把首音频 800ms 以内变成了可达。难点不是延迟本身,而是交互手感:不打断用户、不被用户打断、从半句打断中恢复、对话中调用工具不卡音频、在抖动的移动网络下存活。

你没法靠拼三个 REST 调用做到。架构是端到端的流式管线。亲手搭一个,失败模式就显形了:为电话音频调的 VAD 在背景电视声上误触、轮次检测器等永远不来的标点、TTS 在吐音前缓冲 400ms。本节就是把这些一个一个在负载下修掉,并发布一份延迟与质量报告。

二、从零实现

管线有五个流式阶段:音频入(从浏览器或 PSTN 经 WebRTC)、ASR(Deepgram Nova-3 或 faster-whisper 的流式部分转录)、轮次检测(VAD 加一个读部分转录找完成线索的小模型)、LLM(轮次判定完成后尽快流式出 token)、TTS(首个 LLM token 后约 200ms 内流式出音频)。

三个横切关注点。打断(Barge-in):用户在 Agent 说话时开口,TTS 立即取消、ASR 立即接管。工具使用:对话中的函数调用(天气、日历)必须跑在侧信道,不卡音频;若延迟超 300ms,Agent 预发一句确认 token(「稍等……」)。反压:丢包时,部分转录被暂存、VAD 抬高语音门阈值、Agent 避免对未确认的消息抢话。

轮次判定的双重门控(避免误截断):

def turn_complete(vad_silence_ms, partial, score):
    # VAD 静默 >= 500ms 且 轮次检测完成度评分 > 0.6 才提交
    return vad_silence_ms >= 500 and turn_detector(partial) > 0.6
​

度量线是量化的:15 dB SNR 下 Hamming VAD 基准的 WER < 8%;100 次呼叫的首音频 p50 < 800ms;误截断率 < 3%;TTS 的 MOS > 4.2;单台 g5.xlarge 上 50 路并发。这些数字就是交付物。

三、架构与技术栈

• 传输:LiveKit Agents 1.0(WebRTC)+ Twilio PSTN 网关;Pipecat 0.0.70 作为备选框架。
• ASR:Deepgram Nova-3(流式,首部分 < 300ms)或自托管 faster-whisper Whisper-v3-turbo。
• VAD:Silero VAD v5 + LiveKit 轮次检测器(读部分转录的小 Transformer)。
• LLM:OpenAI GPT-4o-realtime(紧集成)、Gemini 2.5 Flash Live、或级联的 Claude Haiku 4.5(流式补全,独立音频路径)。
• TTS:Cartesia Sonic-2(首字节最低)、ElevenLabs Flash v3、或开源 Orpheus 自托管。
• 工具:FastMCP 侧信道跑天气/日历/订票;工具 >300ms 时 Agent 预发填充语。
• 可观测性:OpenTelemetry 语音 span,Langfuse 语音 trace 配音频回放。
• 部署:单台 g5.xlarge(24GB VRAM)自托管 Whisper + Orpheus;最低延迟用托管 API。

四、可复用产物

outputs/skill-voice-agent.md 是交付物。给定一个领域(客服、排程、自助终端),它搭起一个调到度量线的 LiveKit Agent。评分量表:

一次典型交互:

caller: "what is the weather in tokyo tomorrow"
[asr  ] partial @280ms: "what is the"
[asr  ] partial @540ms: "what is the weather"
[turn ] completion score 0.82 at @820ms; commit
[llm  ] first token @960ms
[tool ] weather.tokyo tomorrow -> 68/52 partly cloudy @1140ms
[tts  ] first audio-out @1040ms: "Tokyo tomorrow will be partly cloudy..."
turn latency: 1040ms user-stop -> audio-out
​

五、框架对比

LiveKit Agents 1.0 是 WebRTC 参考实现,JS/TS 生态最完整,适合生产;Pipecat 是 Python 优先的备选,对算法实验更友好。模型路径上,GPT-4o-realtime 与 Gemini 2.5 Live 把 ASR/LLM/TTS 折成一个端到端语音模型,延迟最低但成本高;级联方案(Haiku 4.5 + 独立 ASR/TTS)更灵活、可逐跳优化。TTS 侧,Cartesia Sonic-2 首字节最快,ElevenLabs Flash v3 音质略优,自托管 Orpheus 省 API 费但需 GPU。

六、练习

1. 换 ASR:把 Deepgram Nova-3 换成 g5.xlarge 上的 faster-whisper v3 turbo,度量延迟与 WER 差距,指出 CPU vs GPU 决策在哪些环节关键。
2. 打断策略:加一个打断仲裁策略——用户在工具调用中打断时 Agent 怎么办?对比三种策略(硬取消、做完工具再停、排队下一轮)。
3. 对抗轮次检测:给用户长句中长停顿,调 VAD 静默阈值与轮次评分阈值,在误截断最低且不超 900ms 之间找平衡。
4. 上 PSTN:经 Twilio 把同一 Agent 部署到 PSTN,对比 PSTN 与 WebRTC 的首音频,解释抖动缓冲与编解码差异。
5. 多语言 VAD:加日语、西班牙语的语音活动检测,度量 Silero VAD v5 的误触率 vs 语言专用微调。

本节要点回顾

1. 手感标准:首音频 p50 < 800ms、误截断率 < 3%、MOS > 4.2、50 路并发。
2. 五级流式:音频入 → ASR → 轮次检测 → 流式 LLM → 流式 TTS,逐跳压延迟。
3. 轮次双重门控:VAD 静默 ≥ 500ms 且 检测器评分 > 0.6 才提交,降误截断。
4. 打断:用户开口即取消 TTS、丢剩余 LLM、重武装 ASR。
5. 工具侧信道:工具 > 300ms 时预发填充语,避免冷场且不卡音频。
6. 反压:丢包时部分转录暂存、VAD 抬阈、不抢话。
7. 度量即交付:WER、误截断率、首音频、MOS、并发数,数字就是报告。

下一节,我们从「语音」转到「视觉」——构建一个视觉优先、能处理表格与图表的多模态文档问答系统。