语音大模型入门手册：从半双工、全双工到主流架构

第一遍：语音大模型是怎样从“会听写”走到“会对话”的

“语音大模型”并不是一个单一结构。它可以指接收语音、输出文字的音频理解模型，也可以指语音输入、语音输出的 spoken dialogue model；有些模型只在用户说完后工作，有些则持续接收音频，并在自己发声时仍然建模用户声音。为了避免把产品演示、传输协议和模型论文混成一件事，下面先按技术演进重建主线，再进入结构化比较。

第一阶段：ASR、文本 LLM、TTS 串成一条可靠流水线

最常见的语音助手把问题拆成三件成熟任务：自动语音识别（ASR）把波形变成文字，文本大模型理解并生成回复，文本转语音（TTS）再把回复读出来。前面通常还有声学回声消除、降噪和语音活动检测，后面还有音频缓冲与播放。每一段都能单独替换、打日志和评估，所以客服、会议助手、车载命令与企业 Agent 至今大量采用这种级联。

代价也很明确：延迟逐段相加；ASR 一旦把实体或数字听错，后面的 LLM 看不到原始证据；语调、哭声、笑声、犹豫与说话人特征很容易在 transcript 这道窄门里消失。系统可以把声学特征作为旁路元数据补回去，但它仍不是原生的音频推理。

第二阶段：给文本 LLM 接上一双“耳朵”

SALMONN、Qwen2-Audio 一类模型使用预训练 speech/audio encoder 提取音频表示，再通过 Q-Former、projector 或 adapter 把它们映射到 LLM 的输入空间。SALMONN 甚至并用 Whisper speech encoder 与 BEATs audio encoder，试图区分语音内容、一般声响与音乐。它们的核心价值是让 LLM 不必先依赖外部 ASR 文本，也能完成音频问答、情绪识别、声学事件理解和音乐描述。

但“能听懂音频”不等于“能原生说话”。Qwen2-Audio 的公开架构主要是 audio/text input 到 text output；给它接一个 TTS，产品也能语音聊天，却仍然是理解模型加语音合成器。这个类别最适合把音频当作需要分析的材料，而不是要求模型持续控制一场自然对话。

第三阶段：把语音也变成 LLM 能预测的离散 token

SpeechGPT、AudioPaLM、GLM-4-Voice 等工作推进了另一条路线：先用神经音频 codec 或语音 tokenizer，把连续波形压缩成离散符号；随后扩展 LLM 词表，让同一个自回归模型同时学习文本 token 与语音 token。SpeechGPT 用跨模态预训练和 instruction tuning 建立 speech-to-text、text-to-speech、speech-to-speech 能力；AudioPaLM 把文本语言知识与 AudioLM 的语音建模结合；GLM-4-Voice 则用 12.5 Hz、单 codebook 的低码率语音 token，配合流式语音 decoder。

这类模型开始保留说话人、韵律和情绪，也能减少显式 ASR/TTS 边界。不过离散化制造了新的矛盾：token 太密，序列很长、推理昂贵；token 太稀，细节会丢失。语义 token 容易承载“说了什么”，多层声学 codebook 更擅长重建“怎么说”，但会增加每个时间步的预测负担。因此许多架构用一个大 temporal transformer 建模时间，再用较小 depth transformer 处理同一时刻的多个 codec codebook。

第四阶段：流式 speech-to-speech 不再等待整句

Mini-Omni、GLM-4-Voice、Qwen2.5-Omni 等系统把音频编码和解码做成流式：输入以 block/chunk 到达，输出语音 token 也能边生成边解码。Qwen2.5-Omni 的 Thinker–Talker 很有代表性：Thinker 负责多模态理解和文本生成；Talker 直接读取 Thinker 的隐藏表示，用双轨自回归结构生成音频 token；滑窗 DiT 再把 token 流解码成音频。这种分工保留了文本推理骨干，同时避免必须等完整文字答案结束后才启动 TTS。

这里最容易出现误读：流式输入、流式输出、同时生成文字与语音，仍不自动等于原生全双工。如果系统必须等待外部 VAD 判断“用户已经说完”，然后才允许 assistant 开始，它仍是流式半双工。流式解决的是分块计算和首包延迟；双工解决的是同一时间轴上谁在听、谁在说、重叠时做什么。

第五阶段：把两个人的声音放到同一条时间线上

Moshi 的关键不是单纯 audio-in/audio-out，而是同时建模两条平行音频流：一条是用户正在说什么，一条是模型自己正在说什么；模型还生成与自身语音对齐的文本“内在独白”。因此用户讲话、模型讲话、停顿、插话和重叠不再需要先切成严格轮次。论文报告的理论延迟为 160 ms、实践可低至约 200 ms，但更重要的是它把 turn-taking 从外部规则移进了生成分布。

2026 年出现的 BayLing-Duplex、DuplexSLA 又把这条路线向前推。BayLing-Duplex 从 turn-based GLM-4-Voice 出发，通过多通道交错序列和少量对话状态 token，让单个自回归 LLM 决定听、说和停止；DuplexSLA 则把用户音频、assistant 音频与结构化 action channel 对齐到同一个 160 ms chunk 时钟，使模型在说话过程中仍可规划和发出工具调用。与此同时，DuplexChat 这类数据工作开始从播客中构建说话人分离的双流语料，因为单声道“混在一起的对话”无法直接教模型哪条声音属于谁。

以上按主题重建了公开论文与官方说明的技术演进。下面开始把双工概念、系统组件、架构选择、训练和评测抽象成一套可复用框架。

核心判断：架构与双工是两条正交轴

单工、半双工、全双工：先从时间轴理解

三个层次不要混用

1. 传输层全双工：麦克风上行和扬声器下行可以同时传输，例如 WebRTC 会话。它只证明网络通道能双向工作。
2. 产品级全双工：播放期间仍运行 AEC、VAD/ASR；用户开口时客户端停止或淡出音频，取消当前生成，把已听到的部分提交给会话。它可以由多个模块拼出来。
3. 模型原生全双工：模型在共享时间轴上联合建模用户流与自身输出流，自己学会何时继续、附和、暂停、停止或回答，不依赖外部“轮次已经结束”开关。

产品文案中的“支持打断”通常只能证明第二层的一部分。真正的原生全双工还要处理非指向系统的旁人说话、背景电视、用户的“嗯嗯”附和、句中自我修正，以及模型是否应该在用户长停顿时抢话。

一套实时语音系统实际由什么组成

端到端延迟为什么不能只报“模型首 token”

半双工系统经常把最大延迟花在 endpoint：为了不抢话，必须等几百毫秒静音；全双工模型可以更早形成假设，却要承担误判和回滚。一个模型即使推理只要 150 ms，如果端点检测等 800 ms、网络和播放缓冲再加 300 ms，用户仍会感到迟钝。

产品级打断的最小状态机

state = LISTENING

for audio_chunk in microphone_stream:
    clean_chunk = aec(audio_chunk, playback_reference)
    input_stream.append(clean_chunk)          # 始终持续接收

    if user_speech_started(clean_chunk):
        if state == SPEAKING:
            playback.fade_out()
            generation.cancel()
            conversation.truncate_to_heard_audio()
        state = LISTENING

    if semantic_end_of_turn(input_stream):
        generation.start(input_stream)
        state = THINKING

    if generation.has_audio_chunk():
        playback.enqueue(generation.pop_audio_chunk())
        state = SPEAKING

真正困难的不是调用 cancel()，而是回答被截断后的状态一致性。假设模型生成了十句话，用户只听到前三句，服务端却把十句话全部写进历史，那么下一轮模型会误以为用户知道后七句。可靠系统需要记录播放进度，截断未听内容，同时取消工具副作用或明确其已不可撤销。

主流实时接口已经把这一步写进协议。Gemini Live API 的说明是：VAD 检测到用户打断后，正在进行的生成会被取消并丢弃，会话历史只保留已经发送到客户端的内容。但“已发送”仍可能多于“已播放”：服务端生成音频的速度快于实时播放，客户端缓冲区里常常还有没播出去的部分。OpenAI Realtime API 为此提供 conversation.item.truncate 事件，客户端报告 assistant 音频实际播放到第几毫秒（audio_end_ms），服务端据此截断音频并删除对应的文字转写，保证上下文里不存在用户没有听到的内容。换句话说，截断必须以播放进度为准；当音频以快于实时的速度推给客户端时，只有播放端才知道用户实际听到了哪里。

目前常见的五类语音大模型架构

A. 级联式：ASR → LLM → TTS

优势：模块成熟；transcript 天然可观察；ASR、LLM、TTS 可独立迭代；文本模型的推理和工具生态最完整。弱点：错误传播和延迟累加；paralinguistic information 容易丢；跨模块状态与取消逻辑复杂。

B. Audio encoder + adapter + 文本 LLM

代表思路包括 SALMONN、Qwen2-Audio。它不要求 LLM 学会生成高频音频 token，因此训练和推理更轻，适合“听一段录音后分析”。但语音输出不是模型的原生动作；如果外接 TTS，声音风格与内容推理之间仍存在接口。

C. 统一离散 token 的 speech-to-speech LM

把文本和 speech codec token 放进同一个自回归词表，通过 next-token prediction 学习多种模态转换。SpeechGPT、AudioPaLM、GLM-4-Voice 属于这一大类的不同实现。它能直接生成语音单位，并更容易保留声音身份和韵律；难点是音频 token 率、多个 codebook 的组合爆炸、长上下文成本，以及文本能力在语音继续预训练中退化。

D. Thinker–Talker / 文本隐状态驱动的双头架构

Qwen2.5-Omni 是典型例子：Thinker 保留强文本、多模态推理能力；Talker 读取 Thinker hidden states，并以流式方式生成 speech token。它不是传统“先生成完文字，再调用独立 TTS”，因为 Talker 可以随着 Thinker 的表示同步工作；但它仍保留清晰的“想”和“说”分工，便于训练不同目标。

这种架构的工程意义是避免两个极端：既不让主 LLM 承担全部高频声学预测，也不把语音完全降级成句后 TTS。代价是双模块调度、隐藏状态接口、文本与语音时序对齐，以及 Talker 是否过度依赖显式语言骨架。

E. 原生双流 / 多流全双工模型

Moshi 把 user audio 和 system audio 作为平行流；BayLing-Duplex 用交错多通道序列和 dialogue-state token 让一个 LLM 学习听说控制；DuplexSLA 再加入 action stream。它们共同把问题从“收到一句语音，生成一句语音”改写为：

也就是说，每个时间片都同时观察用户到当前的声音、自身已经发出的声音和已有动作，再决定下一块 assistant 音频与工具动作。这更接近真实互动，却需要双声道/说话人分离数据、因果流式编码、共享时钟、特殊的 overlap 训练和在线评测。

这些模型怎样训练：数据比模型名字更决定双工能力

四类数据分别教不同能力

1. 语音–文本配对：ASR、TTS、speech translation 数据建立内容对齐，但天然偏向完整句子和清晰轮次。
2. 无标注音频：用 next-token prediction 学声音连续性、说话人和声学结构；需要高质量 tokenizer，计算量也大。
3. 语音 instruction 数据：教模型听懂命令、回答问题、控制情绪/语速/方言，并维持文本 LLM 的指令能力。
4. 说话人分离的双流对话：保留精确重叠、停顿、附和和打断时间，是 native duplex 的关键。DuplexChat 的意义正在于把播客单声道转成每位说话人独立声道。

如果训练集把所有重叠都清理掉，模型不会凭架构自动学会打断；如果所有对话都是 TTS 合成的严格一问一答，它可能在语义问答上很好，却无法应对真实口吃、假启动、背景说话和设备回声。全双工首先是数据分布变化，其次才是特殊层或 token。

常见训练阶段

训练时还要保护文本能力：一种办法是混合大量文本数据；另一种是保留 Thinker 或 text teacher，用蒸馏约束 speech student。部署时则要保证训练的 chunk size、codec frame rate 和服务端批处理策略不会破坏实时性。离线 benchmark 很好的模型，如果必须积累长 block 才编码，仍然做不好低延迟对话。

怎样评测：WER 和 MOS 都不够

Full-Duplex-Bench v1.5 把重叠语音拆成四类场景：用户打断（user interruption）、用户附和（user backchannel）、用户对旁人说话（talking to others，早期版本称 side conversation）和背景语音（background speech，早期版本称 ambient speech）。对每类场景，它分别统计模型的对话行为类别、停止与回应延迟，以及语速、音高、音强和预测 MOS（UTMOSv2）在重叠前后的变化。这比只问“能不能被打断”更接近真实风险：模型不该把每个“嗯”都当成抢话，也不该对电视里的声音执行工具。

作者评测了 Freeze-Omni、Moshi、Gemini Live、Amazon Nova Sonic 与 GPT-4o Realtime 五个系统，发现“快速让出话轮”和“稳健守住话轮”之间存在稳定权衡。GPT-4o 代表 responsive 策略：真实打断时停得最快（平均停止延迟约 0.23 s），却会系统性地对“用户在跟旁人说话”和背景语音误响应；Nova Sonic 与 Gemini 代表 floor-holding 策略：最能分辨用户是不是在对系统说话，但面对真实打断过于保守，停止延迟超过 2 s。这说明打断成功率和误打断率必须成对报告，单看其中一个指标会奖励某种极端策略。需要注意，这些结果对应论文评测时的具体接口版本（如 2024 年 12 月的 GPT-4o Realtime 预览版和 Gemini 2.0 Flash Live），不能直接外推到之后的模型版本。

工程选型：什么时候不该追求原生全双工

实际生产最可能长期存在的是混合架构：原生音频模型负责自然交互与 turn-taking，旁路 ASR 提供 transcript 和审计；高风险实体交给文本校验器；工具调用走结构化 action channel；复杂回答可切到更强但更慢的文本 reasoning model。统一模型减少接口损失，模块化系统提供可控边界，两者不是非此即彼。

面试高频追问

1. 流式 ASR + 流式 TTS 是全双工吗？

不一定。流式只说明数据按 chunk 增量处理。若模型发声时关闭上行识别，或仍要等 VAD 宣布用户轮次结束才生成，就是流式半双工。产品级全双工至少需要持续监听、AEC、打断和状态截断；模型原生全双工还要联合学习听说时间轴。

2. VAD 和 EOU detection 有什么区别？

VAD 判断“现在有没有人声”；EOU 判断“用户的意思是否说完”。“帮我查一下明天……”后面停顿 500 ms，VAD 可能判定 silence，语义 EOU 却应继续等待。反过来，“谢谢”虽然很短，语义上却已经完整。

3. 为什么端到端模型仍保留文本 token 或 inner monologue？

文本数据规模大、语义密度高，适合承载推理和知识；纯音频 token 很长，容易在语言内容上退化。文本中间状态不必等于外部 ASR transcript，它可以是与输出音频同步的内部语义骨架，为高频声学生成提供约束。

4. 单 codebook 和多 codebook 怎么选？

单 codebook token rate 低、对 LLM 友好，但重建细节压力大；多 codebook 可以分层保存音质，却需要处理同一帧多个 token 的依赖。常见折中是 semantic codebook 由主模型预测，其余 acoustic codebook 由 depth model 或专用 decoder 生成。

5. 打断时为什么要 truncate conversation？

因为服务端生成的内容不等于用户听到的内容。若用户在第三句打断，历史里却保存十句完整回答，后续上下文就与用户真实认知不一致。应根据播放时间截断音频与 transcript，并单独处理已经触发的工具副作用。

6. 怎样判断模型是真全双工，还是产品外壳模拟？

看它是否在 assistant 输出期间持续消费用户音频；turn-taking 是否依赖外部 VAD；训练/推理是否有独立 user/assistant time-aligned streams；是否能区分 backchannel、interruption、side speech；benchmark 是否测 stop latency、false interruption 与动态多轮，而不只是 demo。

7. 语音大模型最难的不是 ASR 吗？

ASR 是基础，但自然对话的难点已经转向交互控制：同一句“不是”可能是纠正、反对，也可能对旁人说；同一个静音可能代表思考或轮次结束。模型要把声学、语义、会话历史、播放状态和动作风险放在一个时间决策里。

边界与风险

• “端到端”“原生音频”“实时”“全双工”在不同论文和产品中的口径并不统一；本文只在有明确持续听说或双流建模证据时称为模型原生全双工。
• 商业模型可验证的是公开接口行为，不足以还原内部 tokenizer、训练数据、模块边界和推理图；产品能力不能反推论文级架构。
• 论文给出的理论/实验延迟依赖硬件、网络、chunk、codec、batch 与实现，不能直接当作手机、车机或跨地域 API 的端到端体验。
• 说话人分离和合成 duplex 数据能扩大规模，但 separation artifact、TTS 韵律与真实对话分布可能让模型学到伪线索。
• 全双工扩大了安全面：模型可能听到旁人隐私、把背景声当命令、在被打断后留下未对齐状态，或在说话时悄然执行工具。

独立判断：下一代语音模型是在学习“共享时间”，不只是声音

文本聊天把世界离散成一条条 message：用户提交后模型才开始，边界由 UI 免费提供。语音对话没有这项免费条件。停顿、重叠、拖长音、笑声、呼吸、背景说话和播放进度都在连续变化；模型每几十或几百毫秒都要决定继续听、开始说、简短附和、让出话权，还是执行动作。

因此 native duplex 的真正贡献不是把两个音频通道接到 Transformer，而是让模型获得一种共享时钟上的策略。它同时包含感知问题、语言问题和控制问题。越接近 Agent，action 也必须进入这条时钟：模型可能一边说“我正在查”，一边调用搜索；用户说“算了”时，系统必须知道工具是否还能取消。

这也说明生产路线不会简单地从 cascade 一步跳到单体 omni model。级联的可观察性、文本生态和安全闸门仍然重要；原生音频模型提供自然 turn-taking 和副语言理解；结构化 action channel 负责可靠执行。更可能的终局是一套分层系统：底层连续听说，中层维护可审计语义状态，上层按风险选择快速回应、深度推理或确认后行动。

证据边界与资料索引

本文以截至 2026 年 8 月 16 日公开的论文、官方仓库和实时接口说明为基础。2026 年 9 月 30 日复核了全部论文条目与链接：Full-Duplex-Bench v1.5 已修订到第 4 版（2026 年 4 月），场景命名和评测结论按该版正文更新；打断后的会话截断语义依据 Gemini Live API 文档与 OpenAI Realtime 的 conversation.item.truncate 事件定义补充。论文数字属于发布方报告，商业系统只按公开行为和文档描述，不推断未披露内部结构。

• SpeechGPT: Empowering Large Language Models with Intrinsic Cross-Modal Conversational Abilities
• AudioPaLM: A Large Language Model That Can Speak and Listen
• SALMONN: Towards Generic Hearing Abilities for Large Language Models
• Qwen2-Audio Technical Report
• Mini-Omni: Language Models Can Hear, Talk While Thinking in Streaming
• Moshi: a speech-text foundation model for real-time dialogue；官方实现
• GLM-4-Voice: Towards Intelligent and Human-Like End-to-End Spoken Chatbot；官方实现
• Qwen2.5-Omni Technical Report
• Full-Duplex-Bench v1.5: Evaluating Overlap Handling for Full-Duplex Speech Models；持续更新的 benchmark 仓库
• DuplexSLA: A Full-Duplex Spoken Language Model with Synchronized Speech, Language, and Action；项目页与 DuplexSLA-Bench
• BayLing-Duplex: Native Full-Duplex Speech Dialogue with a Single Autoregressive LLM；官方实现
• DuplexChat: Constructing Speaker-Separated Full-Duplex Dialogue Speech at Scale
• OpenAI: Hello GPT-4o；Realtime API reference；官方 SDK 中 conversation.item.truncate 的事件定义
• Google Gemini Live API capabilities