3.2 端到端语音实时交互架构

3.2 端到端语音实时交互架构

本节摘要：把流式 ASR、LLM、流式 TTS 串成完整的实时语音交互系统，难点不在单个组件，而在组件间的流式咬合和实时交互逻辑。核心问题包括：ASR 的最终结果什么时候送 LLM、LLM 的输出什么时候送 TTS、用户中途打断怎么处理、播放中的音频怎么停。本节讲级联式架构（ASR→LLM→TTS 三段）的设计和这些工程难题的解法，并介绍端到端语音模型（如 GPT-4o Realtime）带来的新范式——直接吃音频吐音频，跳过文字中转，延迟更低但可控性弱。

学习目标

阅读完本节，你应当能够：

1. 设计一个级联式 ASR→LLM→TTS 的端到端语音交互架构
2. 处理用户中途打断时的状态机和资源清理
3. 解释为什么端到端语音模型能降低延迟但牺牲可控性
4. 对比级联式架构和端到端架构的优劣与适用场景
5. 实现基本的流式咬合与缓冲管理

一、问题与直觉

上一节我们把 ASR 和 TTS 各自的流式机制讲透了。但把它们和 LLM 串起来时，会遇到单组件时不存在的新问题。

最典型的是打断（barge-in）。用户说到一半，AI 开始回复了，TTS 正在播放回复的语音。这时用户突然改口"不对，我说的是……"。级联式系统怎么处理？第一，ASR 要能检测到用户又开始说话了（即使在播放中），并立刻通知系统。第二，正在播放的 TTS 音频要立刻停。第三，正在生成的 LLM 要能中断。第四，已经合成但没播放的音频要丢弃。这四件事要原子地发生，否则用户会听到 AI 把旧回复说完才理他，体验崩坏。

另一个问题是"什么时候开始合成"。LLM 第一个 token 出来时，能送 TTS 吗？通常不能——一个 token 太短，可能只是个标点或半个词。要等 LLM 攒够一个短语（几个 token 或一个标点）才送 TTS。但等太久又增加首音延迟。这个"攒多少"的判断直接影响体验。

这些工程难题让端到端语音交互远比文本对话复杂。本节聚焦怎么把组件咬合好、怎么处理这些实时交互的边角情况。

二、核心原理

2.1 级联式架构的整体设计

级联式（cascaded）架构是当前最成熟的方案，三段独立组件串联：

关键设计点在于中间的"缓冲与切分"层——它负责在 ASR 和 LLM 之间做平滑过渡。ASR 输出最终结果（一句完整的话）后，这里决定是立刻送 LLM 还是攒几句。多数对话场景是送一句就够，但有些场景（用户说很长的一段话）需要攒语义完整的片段再送，避免 LLM 基于不完整的上下文回复。

2.2 打断处理的状态机

打断处理是级联式架构最考验工程设计的地方。用一个状态机描述系统状态：

打断发生时（状态从"回复中"或"处理中"转到"打断处理"），要做的事：

# 概念性打断处理
class InterruptionHandler:
    async def on_user_speech_detected(self):
        # 1. 立刻停止音频播放
        self.audio_player.stop_immediately()
        # 2. 中断正在进行的LLM生成
        if self.llm_task and not self.llm_task.done():
            self.llm_task.cancel()
        # 3. 清空已合成未播放的音频队列
        await self.tts_queue.clear()
        # 4. 清空ASR到LLM的待处理缓冲
        self.asr_buffer.clear()
        # 5. 切回听取状态，开始处理新的语音
        self.state = "listening"
        # 注意：以上操作要尽量原子，避免半清理状态
​

⚠️ 常见坑：打断处理最容易出 bug 的地方是"半清理"——停了播放但没断 LLM 生成，结果 LLM 还在跑，把旧回复的剩余 token 又送进了 TTS 队列，用户听到一段莫名其妙的半截话。务必确保四个清理动作（停播放、断生成、清音频队列、清ASR缓冲）要么全做、要么都不做，用一把锁或事务包起来。

2.3 端到端语音模型的新范式

级联式架构虽然成熟，但有个根本局限：它必须经过"语音→文字→文字→语音"的中转，每一次转换都有延迟和精度损失。如果 ASR 把"我要打车"识别成"我要答车"，LLM 基于错文字回复，整条链就错了。

端到端语音模型（如 GPT-4o Realtime）走另一条路：直接吃音频、吐音频，中间不显式转文字。模型内部把音频当作一种"模态"处理，理解语音里的语义（包括语气、情绪），直接生成回复的音频。这跳过了 ASR 和 TTS 两个独立组件，延迟更低，且能保留语气、情绪这类文字表达不了的信息。

但端到端模型也有明显代价。可控性弱——你很难像级联式那样在中间插入业务逻辑（比如拦截敏感词、改写回复、记录对话文字）。级联式能在 ASR 后做内容审核、在 LLM 后改写，端到端模型这些中间环节都看不到。调试难——出问题时你不知道模型是听错了还是回复错了，因为没有中间的文字可查。定制化弱——级联式可以换不同 ASR、TTS、LLM 组合，端到端模型是一坨，灵活性低。

三、工程实践要点

3.1 流式咬合的缓冲管理

三段组件的流式咬合，核心是管理好它们之间的缓冲。ASR 出中间结果时不送 LLM（避免基于变化的输入），出最终结果才送；LLM 出 token 时不立刻送 TTS（太短），攒够一个短语才送；TTS 合成的音频进播放队列，队列空了就卡顿，满了就占内存。

缓冲的容量是个权衡。ASR 到 LLM 的缓冲太小，LLM 频繁基于短输入回复，上下文不完整；太大，延迟增加。LLM 到 TTS 的缓冲类似——太小 TTS 频繁启动开销大且语音不自然，太大首音延迟高。实践中 ASR 缓冲按句（VAD 句末就送），LLM 到 TTS 缓冲按短语（遇到逗号、句号或字数到阈值就送）。

3.2 全双工与半双工

语音交互分全双工和半双工。半双工是"一次只有一方说话"——用户说完，AI 说，AI 说完用户再说，像对讲机。全双工是"可以同时说"——用户说到一半可以打断 AI，AI 也能在用户说话时插入反应（像真人聊天）。

全双工难得多，要求系统能同时听和说，且智能判断"什么时候该插话"。这需要更复杂的 VAD（区分"用户停顿"和"用户说完了"）、回声消除（播放的自己的声音别被麦克风收进去当用户输入）、以及对话状态管理。目前多数产品是半双工（按住说话或检测明显停顿才回复），全双工是前沿研究方向。

3.3 网络与部署优化

实时语音对网络延迟极敏感。云端部署时，音频要上传到服务器、结果要下传，网络往返延迟直接影响体验。优化手段：

就近部署：把服务部署在离用户近的数据中心，降低网络往返。全球服务要多区域部署。

音频压缩：原始音频（如 16kHz 16bit PCM）每秒 256KB，上传下行都吃带宽。用 Opus 等低延迟编码压缩到十几 KB/s，质量损失小，带宽大幅下降。

WebRTC：浏览器和移动端的实时音视频通信标准，内置低延迟传输、丢包处理、回声消除。很多实时语音产品基于 WebRTC 做传输层。

💡 关键直觉：实时语音交互的延迟预算是所有实时 AI 里最紧的。文本 LLM 用户能容忍几百 ms 到 1 秒的 TTFT，但语音对话里从用户说完到 AI 开口超过 1 秒，用户就觉得"卡"。这意味着每个环节都要极致优化，且要算网络往返——别把服务部署在离用户跨大洲的地方。

本节要点回顾

• 级联式架构是当前成熟方案：ASR→LLM→TTS 三段串联，中间有缓冲与切分层做平滑过渡。
• 打断处理要原子清理四个资源：停播放、断 LLM 生成、清音频队列、清 ASR 缓冲，半清理会导致半截话 bug。
• 端到端语音模型是新范式：直接吃音频吐音频，延迟低、保留情绪，但可控性弱、调试难、定制化弱。
• 级联式和端到端各有场景：需要业务逻辑插入和可控性的用级联式，追求极致低延迟且不需要中间干预的用端到端。
• 流式咬合靠缓冲管理：ASR 按句送 LLM，LLM 按短语送 TTS，缓冲容量要在延迟和开销间权衡。
• 全双工是前沿：同时听说、智能插话，需要复杂 VAD、回声消除、对话状态管理，多数产品仍是半双工。
• 网络延迟是硬约束：就近部署、音频压缩、用 WebRTC，把网络往返压到最低。

下一章我们转向另一个方向——把 AI 推理从云端搬到边缘设备，看模型压缩和移动端部署怎么让 AI 在手机、IoT 上跑起来。

端到端语音模型的架构演化与落地观察

GPT-4o Realtime 把"端到端语音"推到台前后，这个方向的架构细节逐渐清晰。它不是简单地把音频编码器接到 LLM 上：训练时要用大量配对的语音对话数据教模型理解音频 token 的时序特性（打断、迟疑、语气词都是信息），推理时要处理音频 token 与文本 token 的粒度失配——一秒语音大约对应几十个音频 token，模型的上下文消耗比文本对话大一个量级，这直接推高了成本，也是各家后来力推"音频 token 压缩"和"混合模态缓存"的原因。开源侧的 MOSHI、开源实时语音方案走的路数类似：小规模 LLM 骨干加音频进出通道，牺牲知识容量换实时性。

落地观察两条。第一，端到端模型的"可控性弱"在实践中具体表现为：说话时机不可控（该停的时候不停，抢话）、输出格式不可控（让它报数字可能连报三遍）、拒答边界不可控（级联管线里加一道文本层过滤器很容易，端到端要在音频输出上做安全拦截，目前手段笨拙）。所以真实系统常见的折衷是"端到端做闲聊壳、文本层做业务芯"：语音模型负责自然对话和转场，涉及业务动作时模型输出结构化文本指令，由传统管线执行，兼顾体验和可控。第二，成本模型要重算：级联管线三段可以各自弹性扩缩（ASR 和 TTS 的单位成本远低于 LLM），端到端模型是一整块算力，闲聊时也在烧钱。日均通话时长长的客服场景，两代架构的成本差可能到数倍，切换前要用真实通话时长分布模拟月账单。

打断处理的工程细节再补一层。除了原子清理四个资源，还有两个容易漏的坑：一是回滚 TTS 缓冲时要把"已送进声卡但未播完"的音频也算进去，某些播放 API 的停止是异步的，需要等确认事件；二是打断后的 ASR 要丢弃"机器说话期间混入的回声"，没有做回声消除（AEC）的系统在打断场景的字错率会翻倍—— speakerphone 场景尤其严重，这也是为什么浏览器端的 WebRTC 栈（自带 AEC）成为实时语音交互的主流接入方式。