Qwen-Omni 系列的技术演进：从音频理解到端到端全模态交互

2026-07-12

语音助手可以由三套独立系统串联完成：

1	用户语音 → ASR 转写 → LLM 生成文本 → TTS 合成语音

这条链路的每个箭头都会引入信息损失或等待时间。ASR 错误会传入 LLM；语气、节奏与环境声无法完整保留在转写文本中；LLM 必须等 ASR 结束，TTS 又要等待可用文本；加入视频后，声音与画面还需要共享时间坐标。

区分 Qwen-Audio、Qwen2-Audio、Qwen2.5-Omni 和 Qwen3-Omni，不能只看“支持了几种模态”。更具体的差异位于四条数据路径上：波形以多大的时间粒度进入语言模型；音频与视频怎样获得同一时间位置；文本 token 与语音 token 由哪些模块生成；流式输出必须等待多少上下文。下面沿着这四条路径逐代展开。

一、Qwen-Audio：用一套编码器承接三十多类音频任务

1. 波形怎样进入 Qwen-7B

Qwen-Audio 于 2023 年 11 月公开。

Qwen-Audio 由一个音频编码器和 Qwen-7B 组成。音频编码器使用 Whisper-large-v2 初始化，共 32 层、约 640M 参数；语言模型为 32 层 Transformer Decoder，隐藏维度 4096，约 7.7B 参数。[2]

音频前端先将输入重采样为 16kHz，再计算 80 通道 Mel 频谱。分析窗长为 25ms、步长为 10ms；Whisper 主干中的卷积层完成初次下采样，额外的 stride-2 pooling 再压缩一次。因此，送入语言模型的每个音频表示约对应原波形中的 40ms。训练时还会使用 SpecAugment 对频谱做数据增强。[2]

16kHz 波形
   ↓ 25ms window / 10ms hop
80-channel Mel
   ↓ Whisper-large-v2 + pooling
1 个音频表示 / 40ms
   ↓
Qwen-7B 自回归生成文字

这里没有先做 ASR。语音、狗叫、乐器声或歌曲都会经过同一个音频编码器，编码结果直接作为 Qwen-7B 的条件输入。

2. 层级标签具体解决什么冲突

Qwen-Audio 的预训练数据覆盖八种语言、三十多类任务。不同数据集的目标并不统一：ASR 要逐字转写，情绪识别只输出一个类别，音频描述输出自然语言，声音事件检测还要带时间戳。如果直接混合，相同音频可能对应多种格式不同的答案，形成一对多映射。

模型因此在正文答案之前生成一组层级标签，顺序包含：[2]

转写或分析：<|startoftranscripts|> 用于识别、翻译，<|startofanalysis|> 用于其余任务。
音频语言：八种训练语言各有 token；无语音的自然声与音乐使用 <|unknown|>。
任务类型：transcribe、translate、caption、analysis、question-answer 五类。
输出语言：指定后续文本使用的语言。
时间戳：timestamps 或 notimestamps。
输出指令：继续限定具体子任务与答案格式。

共享标签让相近任务复用表示，后部标签再区分输出格式。Speech Recognition with Word-level Timestamps（SRWT）还会在每个转写词前后分别生成起止时间 token，而不是只给整句时间。论文的消融实验将 SRWT 与 ASR、声音定位和音频问答的改善联系起来。[2]

训练数据的量级也能说明任务覆盖范围：多语言 ASR 为 30,000 小时，英中 SRWT 合计 21,000 小时，音乐描述为 25,000 小时，口语语言识别为 11,700 小时，音乐流派识别为 9,500 小时，自动音频描述为 8,400 小时。其余说话人、情绪、场景、事件、乐器和问答任务大多以约 1,000 至 5,000 小时的数据参与训练。[2]

3. 两个训练阶段并不同时更新全部参数

多任务预训练阶段冻结 Qwen-7B，只更新音频编码器，使音频表示对齐到既有语言空间。随后训练 Qwen-Audio-Chat 时反过来冻结音频编码器，只更新语言模型。指令微调数据约 20,000 条，包含人工示例、基于原始标签扩写的问题与答案、音频对话以及纯文本指令，并统一成 ChatML 格式。[2]

这种训练方式保留了 Qwen-7B 的初始文本参数，也限定了音频能力进入语言模型的方式。Qwen-Audio 在 LibriSpeech test-clean / test-other 上的 WER 为 2.0 / 4.2，并在 Aishell1、CochlScene、ClothoAQA 和 VocalSound 的论文对比中取得当时的最高结果。[2]

其公开边界也很具体：官方仓库建议音频长度不超过 30 秒；基础模型依赖层级标签确定任务；输出只有文字。[1] 下一代首先修改的不是音频编码器能否识别更多声音，而是用户是否还需要理解这套内部标签。

二、Qwen2-Audio：把任务标签改成自然语言指令

1. 前端从 Whisper-large-v2 更新到 large-v3

Qwen2-Audio 于 2024 年 7 月公开。

Qwen2-Audio 仍由单个音频编码器连接 Qwen-7B，但编码器改用 Whisper-large-v3 初始化。输入保持 16kHz，Mel 通道由 80 增加到 128，窗长和步长仍为 25ms 与 10ms；stride-2 pooling 后，每个输出表示仍对应约 40ms。模型总参数为 8.2B。[3]

这一代的训练分为三个阶段：

预训练：用自然语言 prompt 替代 Qwen-Audio 的层级标签，并扩充音频数据。
监督微调：共同训练 Audio Analysis 与 Voice Chat 两类交互数据。
DPO：对同一音频输入构造人工标注的优选回答与拒绝回答，使输出向事实性和指令遵循对齐。[3]

2. 两种模式如何共存在一个模型中

Audio Analysis 接收“音频 + 文本问题”，用于离线分析语音、自然声、音乐或混合录音；Voice Chat 允许只用语音发出问题，也可以在对话中切换为文字。两类数据共同训练，不通过 system prompt 切换模式。[3]

论文给出的例子是一段先出现键盘敲击、随后有人问“这是什么声音”的录音。模型需要把后半段识别为指令，把前半段识别为被询问对象，再回答键盘声。这里同时包含声音事件检测、语音识别和指令路由，不能由固定任务标签预先指定。

3. 改进出现在哪些指标上

Qwen2-Audio 报告中的同口径结果如下：[3]

任务	Qwen-Audio	Qwen2-Audio
LibriSpeech test-clean WER ↓	2.0	1.6
LibriSpeech test-other WER ↓	4.2	3.6
CoVoST2 英→中 BLEU ↑	41.5	45.2
CoVoST2 中→英 BLEU ↑	15.7	24.4
VocalSound Accuracy ↑	0.9289	0.9392
AIR-Bench Speech / Sound / Music / Mixed ↑	6.47 / 6.95 / 5.52 / 6.08	7.18 / 6.99 / 6.79 / 6.77

AIR-Bench 的四组结果由 GPT-4 按 0 至 10 分评估，覆盖语音、自然声、音乐和混合音频。它衡量的是开放式音频指令回答，不等同于传统 ASR 的 WER。[3]

4. 自然语言交互没有自动补齐推理能力

Qwen2.5-Omni 报告后来使用语音指令比较 Qwen2-Audio 与纯文本 Qwen2-7B。MMLU 中，文本 Qwen2-7B 为 69.3，Qwen2-Audio 为 33.2；GSM8K 分别为 82.3 和 18.4。[4] 这组结果对应的是音频条件下的知识与数学推理，而不是转写准确率。

Qwen2-Audio 也仍然只输出文字，不包含视觉编码器和语音解码器。完整语音对话仍需外接 TTS，视频输入则需要另一套视觉模型。Qwen2.5-Omni 的架构变化由此集中在三个具体接口：音频与视频的时间坐标、文字与语音的并行生成、编码与解码的流式处理。

三、Qwen2.5-Omni：在同一时间轴上处理音频与视频

1. 四种输入分别怎样编码

Qwen2.5-Omni 于 2025 年 3 月公开。

Qwen2.5-Omni 的 Thinker 接收文本、音频、图像和视频：[4]

文本：使用 151,643 个常规 token 的 byte-level BPE tokenizer。
音频：16kHz 波形转换为 128 通道 Mel 频谱，经 Qwen2-Audio 音频编码器得到 40ms 一帧的表示。
图像与视频：使用约 675M 参数的 Qwen2.5-VL ViT；视频按内容动态采样帧率，单张图片在序列中视为两帧相同画面。
视觉 token 压缩：ViT patch size 为 14，相邻 2×2 token 通过 MLP 合并为一个 token。

音频编码器不再对整段录音做全局注意力，而是按 2 秒分块计算。这样，输入仍在持续到来时，前面的块已经可以送入 Thinker 做 prefill，不必等待完整录音或视频结束。[4]

2. TMRoPE 怎样把声音和画面对齐

普通一维 RoPE 只有 token 顺序。Qwen2.5-Omni 将旋转位置拆成 temporal、height、width 三个分量，并加入绝对时间，形成 TMRoPE：[4]

文本的三个位置 ID 相同，因此退化为一维位置编码。
音频的三个位置 ID 也相同，每增加 1 对应 40ms。
图像中所有 token 的 temporal ID 固定，height 与 width ID 按 patch 位置变化。
视频帧的 temporal ID 按真实时间戳递增，时间分辨率同样为 40ms；帧率变化时，ID 间隔随实际时间调整。

对带音轨的视频，模型再按真实时间切成 2 秒片段。每个片段内部先排列视觉表示，再排列同一时间段的音频表示，然后继续下一个 2 秒片段：

1	[0–2s 视频] [0–2s 音频] [2–4s 视频] [2–4s 音频] ...

因此，杯子落地的画面 token 与撞击声 token 不需要相邻，但会落在相同的绝对时间区间。多段不同模态连续输入时，后一段的位置从前一段最大位置 ID 加一开始，避免位置编号重叠。[4]

3. Thinker 与 Talker 之间传递两类信息

Thinker 是负责文本生成的 Transformer Decoder。Talker 是双轨自回归 Transformer Decoder，同时接收两类条件：[4]

Thinker 的高维隐藏表示，其中包含尚未完全输出的语义、语气与上下文信息。
Thinker 已采样出的离散文本 token，用于确定具体字词和发音。

只使用隐藏表示会遇到一个问题：语义相近但发音不同的词在表示空间中可能距离很近；只等待离散文本又会增加语音启动时间，并丢失一部分提前可用的语气信息。Talker 因此在文本尚未完整生成时，就根据两条输入流预测 qwen-tts-tokenizer 的离散语音 token。训练数据不要求文字与语音具有逐词时间戳对齐。

多模态输入 ─→ Thinker ─→ 文本 token
                    │          │
                    │隐藏表示  │离散词元
                    └────┬─────┘
                         ↓
                       Talker ─→ 语音 token

4. 语音 token 到波形仍需等待局部右上下文

Qwen2.5-Omni 使用 Flow-Matching DiT 将语音 token 转为 Mel 频谱，再由修改后的 BigVGAN 重建波形。为实现流式解码，连续 token 被分成块，DiT 的感受野限制为四块：向前看两块、当前块、向后看一块。BigVGAN 也按固定感受野逐块输出。[4]

这个设计不再等待整句语音，但当前块仍要等到一个未来块可用。Qwen3-Omni 后续改用只依赖左侧上下文的因果解码器，修改的正是这里的 lookahead。

5. 预训练与 Talker 训练分别进行

Thinker 的预训练包含三个阶段：[4]

冻结 Qwen2.5 LLM，先训练视觉和音频 adapter，再分别训练两个编码器。
解冻全部参数，加入约 800B 图像与视频 token、300B 音频 token、100B 音视频 token，并混合纯文本数据。
将最大序列长度从 8,192 扩展到 32,768，同时提高长音频和长视频数据比例。

Talker 另有三阶段训练：先用带多模态上下文的语音对话做 next-token continuation；再根据 WER 和标点停顿错误构造偏好对，使用 DPO 降低漏词、错词和停顿错误；最后做多说话人微调，控制音色与表达方式。[4]

6. 具体结果与资源边界

语音指令推理结果显示，MMLU 从 Qwen2-Audio 的 33.2 提高到 65.6，GSM8K 从 18.4 提高到 85.4；作为参照，纯文本 Qwen2-7B 分别为 69.3 和 82.3。[4] 在 Seed-TTS Eval 上，Qwen2.5-Omni 的 test-zh、test-en、test-hard WER 分别为 1.42%、2.33% 和 6.54%。[4]

代价反映在显存上。官方仓库给出的 BF16 理论最低值中，7B 模型处理 15 秒视频需要 31.11GB，60 秒需要 60.19GB；实际使用通常至少为理论值的 1.2 倍。[5] 公开版本支持流式输入和输出，但示例交互仍以一轮输入对应一轮输出为主，没有列出输出期间持续收音、用户打断和主动发言等全双工接口。

四、Qwen3-Omni：替换音频编码器与语音解码链路

1. 组件规模不能只用 A3B 表示

Qwen3-Omni 于 2025 年 9 月公开。

Qwen3-Omni-30B-A3B 的完整推理链由多个模型组成：[6]

模块	架构	参数量或激活量
Audio Encoder	AuT	约 650M
Vision Encoder	SigLIP2-So400M	约 540M
Thinker	MoE Transformer	30B-A3B
Talker	MoE Transformer	3B-A0.3B
MTP	Dense Transformer	80M
Code2Wav	Causal ConvNet	200M

30B-A3B 表示 Thinker 每个 token 激活约 3B 参数，并不表示部署时只加载 3B 权重。Talker 自身也是 3B-A0.3B 的 MoE，此外还有两个编码器、MTP、Code2Wav、KV Cache 和视觉 token。

2. AuT 将音频时间粒度从 40ms 改为 80ms

Qwen3-Omni 不再以 Whisper 初始化音频编码器，而是使用从零训练的 Audio Transformer（AuT）。AuT 约 0.6B 参数，训练数据为 2,000 万小时监督音频，其中 80% 是中英文伪标注 ASR，10% 是其他语言 ASR，10% 是音频理解数据。[6]

波形仍重采样为 16kHz，并使用 128 通道 Mel、25ms 窗长和 10ms 步长。Conv2D 在注意力层之前做 8 倍下采样，使输出速率降到 12.5Hz，即每个表示对应约 80ms。AuT 使用 Flash Attention 和 1 至 8 秒的动态注意力窗口，在离线任务的上下文范围与流式 prefill 缓存之间切换。[6]

1 2	Qwen2 / Qwen2.5 音频表示：25 Hz = 40ms / token Qwen3-Omni 音频表示： 12.5 Hz = 80ms / token

相同音频时长下，进入 Thinker 的音频 token 数约减半。Qwen3-Omni 公开能力说明也将单次音频理解长度扩展到 40 分钟以上。[6][7]

3. TM-RoPE 取消固定 2 秒音视频切块

Qwen3-Omni 延续时间、高度、宽度三维位置，但重新分配旋转角：temporal、height、width 分别使用 24、20、20 个交错角度。音频每 80ms 增加一个 temporal ID，视频帧根据真实时间戳映射到相同的 80ms 时间网格。[6]

Qwen2.5-Omni 需要把音视频表示切成固定 2 秒块再交错排列；Qwen3-Omni 直接依据绝对 temporal ID 对齐，不再要求输入长度是 2 秒块的组合。这一变化使任意长度的流式音频与视频可以继续追加位置 ID。[6]

4. Talker 不再依赖 Thinker 的文本隐藏状态

Qwen2.5-Omni 的 Talker 同时读取文本隐藏表示和离散文本 token。Qwen3-Omni 将文本侧解耦：Talker 使用离散文本 token，并保留音频、视觉等多模态高维特征与完整对话历史，但不再以 Thinker 的文本隐藏状态作为必要条件。[6]

这一接口允许 RAG、函数调用或安全过滤器先修改 Thinker 的文字结果，再把处理后的文本交给 Talker；Thinker 与 Talker 也可以使用不同 system prompt，分别控制答案内容和语音风格。[6]

5. 多码本预测去掉了 DiT 的右侧等待

Qwen3-Omni 的语音 codec 使用残差向量量化（RVQ）多码本。每个 80ms 帧的生成顺序如下：[6]

Talker 主干读取当前上下文，用线性头预测第 0 个主码本。
80M 参数的 MTP 模块以固定步数预测当前帧剩余的残差码本。
200M 参数的因果 Code2Wav 只读取左侧历史，将该帧码本立即还原为波形。

文本 token + 多模态上下文
          ↓
Talker：主码本 c0
          ↓
MTP：残差码本 c1 ... cn
          ↓
Code2Wav：当前 80ms 波形

Qwen2.5-Omni 的 DiT 需要当前块之后的一个块；Qwen3-Omni 在首个 codec 帧产生后即可合成。Thinker 与 Talker 的 prefill 也异步执行：Thinker 完成当前输入块后，Talker 立即 prefill 该块，Thinker 同时继续处理下一块。[6]

论文给出的 vLLM、torch.compile 与 CUDA Graph 理论延迟拆分如下：[6]

并发数	音频首包	视频首包	Talker 生成速度	语音 RTF
1	234ms	547ms	140 token/s	0.47
4	728ms	1517ms	125 token/s	0.56
6	1172ms	2284ms	110 token/s	0.66

这些数字是指定软硬件优化下的理论端到端首包时间，不是网络 API 的固定延迟。RTF 小于 1 表示生成 80ms 语音所需计算时间低于 80ms，可以连续输出；并发增加时，首包时间仍由各模块串行时间累积。[6]

6. 预训练数据从编码器对齐延伸到长上下文

Qwen3-Omni 的预训练同样分三阶段：[6]

Encoder Alignment：LLM 初始化自 Qwen3，视觉编码器来自 Qwen3-VL，音频编码器使用 AuT；固定 LLM，先训练 adapter，再分别训练编码器。
General Stage：报告称使用约 2T token，分项列出文本 0.57T、音频 0.77T、图像 0.82T、视频 0.05T、音视频 0.05T，并从早期阶段同时混入单模态与跨模态数据。
Long Context：最大长度由 8,192 提升到 32,768，并增加长音频与长视频占比。

Thinker 的后训练依次使用 SFT、Strong-to-Weak Distillation 和 GSPO。蒸馏阶段先使用教师回答做 off-policy 训练，再让学生采样回答，并以 Qwen3-32B 或 Qwen3-235B-A22B 的 logits 最小化 KL 散度。Talker 则经过大规模语音映射、优质数据持续预训练与长上下文训练、多语言 DPO、指定说话人微调四个阶段。[6]

7. 指标变化分别来自识别、推理和合成

Qwen3-Omni 报告中可以直接与 Qwen2.5-Omni 对照的结果包括：[6]

任务	Qwen2.5-Omni	Qwen3-Omni-30B-A3B
LibriSpeech clean / other WER ↓	1.74 / 3.45	1.22 / 2.48
Common Voice 15 中文 WER ↓	5.13	4.31
VoiceBench Overall ↑	73.6	85.5
MMAU 音频推理 ↑	65.5	77.5
SEED-TTS 中文 / 英文 WER ↓	1.42 / 2.33	1.07 / 1.39

语言范围为 119 种文本语言、19 种语音输入语言和 10 种语音输出语言。官方汇总的 36 项音频与音视频基准中，32 项为开源模型最高结果，22 项为全部参评模型最高结果。[7]

显存仍由总权重与上下文决定。官方仓库的 BF16 理论最低值中，15 秒视频需要 78.85GB，120 秒视频需要 144.81GB。[7] 技术报告还明确列出长视频限制：位置外推能力和上下文长度不足；在 Video-MME、LVBench 等长视频评测中，Qwen3-Omni 并未同步取得音频任务上的相对结果。[6]

五、仍未闭合的具体接口

1. 流式生成与全双工不是同一个接口

Qwen3-Omni 的 234ms 指标测量“收到尾包后多久产生首个音频包”。全双工还要求输出期间继续接收输入，并定义至少三类事件：检测用户插话后停止当前生成；在用户短暂反馈时保持原轮次；持续观察音视频并决定是否主动发言。Qwen3-Omni 的公开仓库没有给出这三类事件的接口或评测。[7]

MiniCPM-o 4.5 将音频、视频输入流与文本、语音输出流放入统一时间线，并以 1Hz 频率判断是否发言，公开模型规模为 9B。[8] 其仓库同时列出 Omni 模式下的发音稳定性、中英文混合和全双工基础能力限制。Moshi 通过同步建模用户与系统两路语音 token 实现语音全双工，但不接收视觉输入。[9] 两项工作分别补充了主动音视频交互和双向语音建模，输入模态与基础模型能力不同。

2. 40 分钟音频不等于持续视频记忆

Qwen3-Omni 支持超过 40 分钟的单次音频理解，但预训练长上下文上限为 32,768 token，技术报告也直接记录了长视频位置外推与上下文限制。[6] 持续视频还要求在上下文写满之前压缩历史事件，并在新证据出现后更新旧事件状态；公开模型没有给出这种长期记忆模块。

Qwen3-VL 的原生上下文为 256K，可扩展到 1M，官方说明覆盖数小时视频与秒级事件定位。[10] 它不包含 Qwen3-Omni 的 Talker、MTP 和 Code2Wav。因此，长视觉上下文与实时语音输出目前位于两套模型中。

3. 输入有四种，原生输出只有两种

Qwen3-Omni 原生输入为文本、图像、音频、视频，原生输出为文本和语音。[7] 图像编辑、音乐续写和视频生成需要调用独立生成模型。

NExT-GPT 使用投影层连接不同模态编码器，再通过输出适配器调用图像、视频和音频扩散模型；语言模型负责生成模态信号 token，而实际内容由外部解码器生成。[11] Unified-IO 2 则把文本、图像、音频和动作量化成统一离散序列，由同一个 encoder-decoder Transformer 预测。[12] 前者保留专用生成器，后者统一 token 空间，两者都没有采用 Qwen3-Omni 的实时 Talker 链路。

4. 激活参数与驻留参数是两组数字

A3B 降低的是每个 token 的激活计算量，不会移除未被当前 token 选择的专家权重。完整本地部署还要为视觉与音频编码器、Talker、MTP、Code2Wav 和 KV Cache 预留显存。vLLM-Omni 通过分模块调度、张量并行和流水线执行处理多模态生成，AWQ、GGUF 等格式降低权重精度；这些方法分别减少调度开销或权重体积，不改变视频 token 随时长增长的事实。[15]

5. ASR 与 TTS 已拆成独立部署分支

Qwen3-ASR 提供 0.6B 和 1.7B 两种规模，支持 30 种语言、22 种中文方言、歌曲识别、流式与离线转写，并可连接 ForcedAligner 输出词级时间戳。[13] Qwen3-TTS 支持 10 种语言、三秒声音克隆、自然语言音色描述和语音控制，其 tokenizer 的理论首包时间为 97ms。[14]

这些模型不需要加载 Omni 中与目标任务无关的视觉或生成模块。相应地，采用 ASR → LLM → TTS 重新组成系统时，转写损失、模块间等待和跨模态状态传递又需要由系统层处理。统一模型与专用模型的差异因此可以落到可测量项上：总驻留参数、首包延迟、跨模块错误传播，以及是否保留语气和视觉上下文。