先把流水线捋清楚：
语音输入 → STT（语音转文本） → LLM（大模型理解 & 生成回答） → TTS（文本转语音） → 语音输出

这就是级联（Cascade）：多个独立模块串行串起来，一个模块的输出作为下一个模块的输入，和自动驾驶经典「感知 → 预测 → 规划 → 控制」的串行级联思路很像。

一、模块拆解

  • STT（Speech-to-Text，语音转文字）：内部又拆成 VAD + ASR
    • VAD：语音活动检测，判断「用户有没有在说话、什么时候开始 / 结束说话」，用来截断静音、减少无效推理；
    • ASR：语音识别，把人声音频翻译成文字。
  • LLM：拿到文本，理解意图、做推理、生成回复文本。
  • TTS（Text-to-Speech）：把 LLM 输出的文字，合成人声语音播放出去。

二、级联模式两大核心痛点

① 误差级联放大 + 梯度无法回传

每个模块是单独训练的：ASR 一套权重、LLM 一套、TTS 一套。

  • 训练时，最终的 Reward / 反馈信号没法跨模块反向传播。
  • 举个例子：ASR 把「打开空调」识别错成「打开天窗」，LLM 跟着理解错，最后 TTS 读出错误回答。错误从上游一路传到下游、越放越大。
  • 出问题之后很难定位到底是谁的锅：是 ASR 识别错？还是 LLM 理解错？错误轨迹很难用来统一修正整套系统。

这也是现在端到端 Audio LLM 兴起的核心动机：音频直接进大模型，跳过中间文本这个中转，整套模型一起训练，反馈可以全局回传。
还有折中方案：半级联，把 ASR 和 LLM 合并成 Audio LLM，只保留【Audio LLM + TTS】，减少串联环节。

② 线性串行，延迟高

几个模型必须依次跑，有强依赖：必须等 STT 识别完，LLM 才能开始；必须等 LLM 生成完文本，TTS 才能合成语音。

推理延迟是各模块耗时叠加，很难压到极低的实时对话水平。

三、传输层：实时语音用什么协议

实时双向语音 Agent 一般优先 WebRTC：

  • 底层默认 UDP，允许少量丢包、优先保证低延迟，适合双向实时音视频通话；
  • 备选方案：SSE / Streamable HTTP（流式 HTTP），走 TCP，可靠性好一点，但延迟和丢包容忍度不如 WebRTC，不是实时语音首选；
  • 阿里还有一个 AOQ——面向 Agent 特化的实时音频协议，和 WebRTC 同属这一层的选择，端到端产品里三者常并列出现（后面第六节会再提到）。

四、级联 vs 端到端 Audio LLM 一句话对比

  • ✅ 级联：成熟、易上手、每个模块可以单独调优替换；但是延迟高、错误会逐级放大、不能联合训练。
  • ✅ 端到端 Audio LLM：音频直接输入模型，直接输出音频 / 文本，减少中间环节、可以全局优化 Reward；但是训练成本高、模型更重，技术门槛更高。

五、半级联架构（折中路线）

把 ASR + LLM 合并成 Audio LLM（音频直接进大模型，不再先出文本），后面再接独立 TTS。

流水线变成：语音输入 → Audio LLM → TTS → 语音输出，减少了一个串联边界，缓解一部分级联误差和延迟问题，是现在很多语音 Agent 落地的主流折中方案。

目前座舱的语音 Agent 就是这种级联模式：ASR、LLM、TTS 各自独立，链路清晰、单模块好替换，但延迟和误差逐级放大的问题也实打实存在，这也是为什么半级联 / 端到端方案正在被越来越多地拿来讨论和落地。

六、端到端的输入输出与 Qwen-Audio

级联把输入锁死成「语音进、语音出」，中间文本只是不得不路过的传送带。端到端真正解锁的，是输入输出形态的自由组合——文本从「强制中转环节」变成「可选产物」，同一个模型可以流式地同时吐 text token 和 audio token。

端到端的能力边界：看输入输出形态

输入 输出 说明 典型场景
语音 文字 纯音频理解 / 转写问答（audio-to-text） 会议摘要、音频质检
语音 语音 speech-to-speech 直接对话，能保留语气 / 情绪等副语言信息 实时语音助手
语音 + 文字 语音 + 文字 混合模态输入输出，一边播报一边同步出可读字幕 / 指令 座舱、客服

关键点：端到端不是「只能语音进语音出」，而是输入输出可以任意搭配；中间那层文本不再是硬瓶颈，可以只出文字、只出语音，也可以文字 + 语音同时出。

工程落地：产品、延迟与协议

「语音进、语音出、单一模型、不走级联」这条路线已经有实际产品落地：Qwen-Audio-3.0-Realtime、豆包 Seeduplex、OpenAI GPT-Live-1，端到端延迟普遍压在 250ms–400ms 左右——对比级联叠加出来的延迟，这才够得上「实时对话」的体验。传输层用的正是第三节那套：AOQ / WebRTC / WebSocket。

还有一点容易误读：端到端只是架构设计，不影响继续用 Harness 流程做上下文和 Prompt 管理。文本 Prompt 照样能给，工具照样能提供给模型调用（Realtime 支持 Function Calling 就是例子）。区别只在于上下文的存放形态：可以是音频也可以是文本，但音频 token 体量太大，实践中通常还是以文本为主。

重点：最新的 Qwen-Audio 系列

Qwen-Audio 是阿里云通义千问家族的开源音频语言大模型（Large Audio-Language Model, LALM），主打端到端统一音频理解：语音、环境音、音乐、歌声都能直接作为输入，区别于传统「ASR + LLM」串联。它的演进正好对应上面那张输入输出表：

  • 首代 Qwen-Audio（2023.11）：音频编码器 + 千问 LLM 基座，统一做音频-文本对齐，重点在理解。
  • Qwen2-Audio（2024）：用自然语言提示统一做多任务预训练 + SFT/DPO 对齐，音频进、文本出，在 AIR-Bench 上优于同期 Gemini 1.5 Pro 音频赛道；这版是主流开源可部署版本（Qwen2-Audio-7B / -Instruct，权重在 ModelScope、HuggingFace 开源，宽松商用许可）。
  • 云上 Qwen-Audio-3.1 产品线：把能力拆成三个子模型——
    1. ASR-Next：专业语音识别、分说话人转写、热词、时间戳，多语言 + 中文方言；
    2. Realtime：全双工实时语音 Agent，语音进、语音出，自带语义 VAD（smart_turn），不被「嗯、啊」语气词误打断，支持 Function Calling、联网搜索、音色复刻；
    3. TTS-Next：新一代音频生成，不止人声，可同时生成语音 + 音效 + 环境音。

⚠️ 开源可部署版（Qwen / Qwen2-Audio）侧重音频理解（audio-to-text），不带 TTS 语音生成；语音输出、全双工实时对话是云上 3.1 子系列的能力。一句话对比 Whisper：Whisper 是纯 ASR 只做转写，Qwen-Audio 是音频理解大模型，转写只是其中一项，还能对音频内容做推理、问答、赏析。

落到座舱：唤醒判断 + 模型推理 + 生成结果

在座舱领域，上面这些能力最终会收敛成一套多轮交互闭环，对应三段式设计：

  1. 唤醒判断：决定「是不是在对我说话、要不要进入对话」。传统靠 KWS 硬唤醒词 + VAD；端到端之后逐步过渡到语义 VAD / smart_turn，能结合语义判断说完没有、该不该响应，减少误打断。
  2. 模型推理：Audio LLM 直接吃语音，结合多轮上下文做意图理解 + 推理 + 工具调用（车控：空调 / 导航 / 车窗 / 多媒体），这步就是端到端取代「ASR+LLM」串联的核心价值。
  3. 生成结果：同时产出 TTS 语音播报 + 屏幕文字 + 下发的车控指令，对应上表「语音 + 文字输出」。

三者接起来就是：唤醒 → 听 → 推理/调用 → 边播边执行 → 等下一轮，靠全双工 + 语义打断实现「边听边想边说」的多轮对话。座舱为什么偏爱往半级联 / 端到端走：驾驶场景对延迟敏感、误识别容忍低（“空调”听成“天窗”有安全隐患），而且需要保留语气做情绪判断。

七、总结

级联胜在成熟、每个模块都能单独替换，代价是延迟叠加、误差逐级放大。半级联砍掉 ASR 和 LLM 之间的边界，端到端则把音频理解整个吸收进大模型，输入输出不再是“语音进、语音出”。

从级联到半级联再到端到端，推的其实是同一件事：在工程可用性和联合优化之间找位置。座舱里那套「唤醒 → 推理 → 生成」闭环，就是这条路线落地后的样子。