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

2026-07-12

在原生端到端语音模型出现之前，语音助手通常采用上一代的级联式工作流：

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

这套 workflow 把识别、推理和合成拆成三个可独立替换、监控与审核的模块，至今仍适用于模块边界优先的生产系统。它的问题集中在模块之间：ASR 错误会传入 LLM；语气、节奏与环境声无法完整保留在转写文本中；LLM 通常要等待可用转写，TTS 又要等待可用文本；加入视频后，声音与画面还需要由系统层维护同一时间坐标。

Qwen-Audio 到 Qwen3.5-Omni 的演进，可以看作这些外部接口逐步被移入模型：先让波形绕过 ASR 直接进入语言模型，再把音频与视频放到同一时间轴，随后加入文本与语音的并行生成，最后把轮次判断、语义打断和工具调用纳入实时交互。区分各代模型不能只看“支持了几种模态”，还要看五条数据路径：波形以多大的时间粒度进入语言模型；音频与视频怎样获得同一时间位置；文本 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]

五、Qwen3.5-Omni：把长上下文、语音同步与轮次判断放进同一代模型

Qwen3.5-Omni 于 2026 年 4 月公开技术报告，包含 Plus 与 Flash 两个 instruct 版本。报告只说明模型扩展到数千亿参数，并未列出两个版本各自的总参数、激活参数和层数；因此，Plus 与 Flash 不能像 Qwen3-Omni-30B-A3B 一样由名称直接还原模型规模。[16]

1. AuT 的输出速率从 12.5Hz 继续降到 6.25Hz

Qwen3.5-Omni 沿用从零训练的 AuT，但输入频谱经过四个 Conv2D block 做 16 倍下采样，最终每秒只向 Thinker 送入 6.25 个音频表示，即每个表示覆盖约 160ms。作为对照，Qwen3-Omni 为 12.5Hz、约 80ms 一个表示，Qwen2.5-Omni 为 25Hz、约 40ms 一个表示。[16]

1
2
3

Qwen2 / Qwen2.5：25 Hz   =  40ms / audio token
Qwen3-Omni：      12.5 Hz =  80ms / audio token
Qwen3.5-Omni：     6.25Hz = 160ms / audio token

AuT 使用 Qwen3-ASR 生成的 4,000 万小时音频—文本对训练，覆盖二十多种语言；中文、英文和其他多语言数据比例为 3.5 : 3.5 : 3。它继续使用动态注意力窗口，使流式 prefill 时可以复用局部缓存，离线音频任务又能使用更长的上下文。[16]

文本侧的 byte-level BPE 词表从约 15 万扩展到 25 万。报告给出的多语言编码效率变化为 10% 至 60%；这不仅减少纯文本 token，也直接改变 ARIA 后续需要协调的文本—语音速率。[16]

2. 绝对时间不再只写进 RoPE

Qwen3.5-Omni 保留 TM-RoPE：音频每 160ms 增加一个 temporal ID，视频帧按真实时间戳映射到同样的 160ms 网格。但长视频中，相邻视觉帧对应的 temporal ID 可能非常稀疏；若只依赖位置旋转，模型还需要在训练数据中见过足够多不同帧率与时长的组合。[16]

这一代因此又加入一条显式时间通道：每个视频或音视频 temporal patch 前插入格式化为秒数的文本时间戳，纯音频序列也会在随机间隔插入时间戳。TM-RoPE 提供连续的位置结构，文本时间戳提供模型可以直接读写的 timecode。代价是序列略微增长，但结构化字幕可以直接输出场景分段、起止时间、人物与声音关系，而不必在解码后另做时间对齐。[16]

3. Thinker 与 Talker 都换成 Hybrid Attention MoE

Qwen3.5-Omni 的 Thinker 和 Talker 均采用 Qwen3.5 系列的 Hybrid Attention MoE：以 Gated DeltaNet（GDN）承担主要的线性时间序列建模，并保留 Gated Attention 层处理需要精确回看的内容。[16][17]

普通全注意力在长上下文中需要持续读写随序列增长的 KV Cache；GDN 把历史压入固定状态，主要减少长音频和长视频推理中的 KV-cache I/O。保留全注意力则用于弥补纯线性注意力在精确检索上的限制。Qwen3.5-Omni 报告没有公开两个版本的层数、专家数或 GDN 与全注意力的具体层比例，只公开了这套结构同时用于 Thinker 与 Talker。[16]

4. ARIA 把两条生成轨道改成一个交错序列

Qwen3-Omni 的 Talker 需要并行维护离散文本 token 与语音 codec token。问题在于两类 tokenizer 的效率并不恒定：同一句话在中文、英文、数字、缩写或低资源语言中会产生不同数量的文本 token，而语音 token 数主要由发音时长决定。使用固定交错比例时，文本轨可能过早耗尽，也可能落后于语音轨，具体表现为漏词、错读和数字发音歧义。[16]

ARIA（Adaptive Rate Interleave Alignment）取消固定交错率和 MFA 逐词对齐，把文本 token 与语音 token 组织成单个单调交错序列。它使用每条训练样本的整体语音—文本 token 比作为上限：对生成序列的任意前缀，已生成语音 token 相对文本 token 的累计比例都不能超过该样本的全局比例。模型可以先生成任意长度的文本前缀，再在约束内插入足够的语音 token，并随语言和语速动态改变两者间隔。[16]

Qwen3-Omni：   text stream ─────────────→
               speech stream ───────────→  两轨分别调度

Qwen3.5-Omni：text₀ text₁ speech₀ speech₁ text₂ ...
               └──── ARIA 单调速率约束 ────┘

Talker 仍预测 RVQ 主码本，MTP 补齐当前帧的残差码本，因果 Code2Wav 逐帧恢复波形。ARIA 修改的是文本与语音单元进入 Talker 解码序列的时间，而不是把 Qwen3-Omni 的 MTP 与 Code2Wav 再替换一遍。[16]

5. 256K 是 Thinker 上下文，Talker 另有 64K 训练阶段

Thinker 的预训练分三段：[16]

Encoder Alignment：LLM、视觉编码器与音频编码器分别从 Qwen3.5、Qwen3.5 Vision Encoder 和 AuT 初始化；冻结 LLM，先训练 adapter，再训练两个编码器。
General Stage：解冻全部参数，在 32,768 长度下训练约 4T token，其中纯文本 0.92T、音频 1.99T、图像 0.95T、视频 0.14T、音视频 0.29T。
Long Context Stage：把最大长度从 32,768 提升到 262,144，并增加长音频和长视频样本比例。

报告将这套上下文换算为超过 10 小时音频，或 1 FPS 下超过 400 秒的 720P 音视频输入。这里的两种时长不能直接互换：视频帧还会产生空间 patch token，因此同样的 256K 在视频上消耗得更快。[16]

Talker 的训练长度并不等于 Thinker。其 General Stage 使用超过 2,000 万小时、带多模态上下文的多语言语音；后续高质量持续预训练把 Talker 上下文扩展到 64K，再经过 DPO、GSPO 与 speaker fine-tuning。由此，256K 描述的是多模态理解与文本生成主干，不能直接解释为一次语音回复可以自回归生成 256K token。[16]

6. 实时交互增加了语义打断，但仍有会话层上限

Qwen3.5-Omni 的技术报告新增原生 turn-taking intent recognition：模型区分真正要求打断的内容、用户的简短附和与背景声音，并能在语音指令中控制音量、语速和情绪。Talker 的独立 system prompt 还可以接收文字描述和参考音频 codec，从而执行零样本音色克隆。[16]

在 Alibaba Cloud 的 realtime 接口中，这些能力落成两种轮次检测方式：server_vad 根据声学活动和静音时长切分轮次，semantic_vad 再根据语义完整性过滤填充词、附和与背景噪声；客户端通过 WebSocket 或 WebRTC 连续发送音频、图像帧和控制事件。Plus 版本支持内置 Web Search 与 Function Calling，但两者当前不能同时开启。[18]

实时 API 的会话记忆短于离线模型的理论输入上限。qwen3.5-omni-plus-realtime 单连接最长 120 分钟，但仅保留最近 100 轮或累计 600 秒音频；视频为 50 轮或累计 240 秒。达到上限后会丢弃最早历史。因此，“模型可理解 10 小时音频”描述单次长输入能力，“实时会话保留 600 秒音频”描述在线服务的滚动状态，二者不是同一指标。[18]

7. 延迟与同口径指标发生了哪些变化

报告在内部 vLLM、torch.compile、CUDA Graph 条件下给出单并发理论首包：Flash 的音频 / 视频输入为 235 / 426ms，Plus 为 435 / 651ms。Flash 的 Generation RTF 为 0.178，Plus 为 0.187；8 并发时分别升至 0.257 与 0.334。报告同时说明两个版本的模型规模和并行策略差异较大，不能用首包数字直接比较模型质量。[16]

与 Qwen3-Omni 报告中同名评测可对照的结果如下：[6][16]

接口或任务	Qwen3-Omni-30B-A3B	Qwen3.5-Omni-Plus
AuT 输出速率	12.5Hz（80ms）	6.25Hz（160ms）
Thinker 最大训练长度	32,768	262,144
LibriSpeech clean / other WER ↓	1.22 / 2.48	1.11 / 2.23
VoiceBench Overall ↑	85.5	93.1
SEED-TTS 中文 / 英文 WER ↓	1.07 / 1.39	0.99 / 1.26
语音输入语言与方言	19 种语言	113 种语言与方言
语音输出语言与方言	10 种语言	36 种语言与方言

Qwen3.5-Omni-Plus 还在 215 个音频与音视频子任务及基准上汇总结果；其中 MMAU 为 82.2、VoiceBench 为 93.1、Omni-Cloze 为 64.8、OmniGAIA 为 57.2。后两项分别对应音视频字幕与工具使用，不应与 ASR 的 WER 合并成一个“全模态分数”。[16]

六、最新实时方案的差异：五套系统解决的不是同一个接口

截至 2026 年 7 月，Qwen3.5-Omni、Thinking Machines Lab Interaction Models、Seeduplex、Grok Live 和 GPT-Live 的公开形态不同：有的是技术报告与云端模型，有的是研究预览，有的是已经上线的消费产品或 Voice Agent API。下面只比较公开材料明确给出的接口，不根据产品演示反推未披露的内部架构。

方案	时间组织	输入与输出	轮次、打断与主动性	公开边界
Qwen3.5-Omni Realtime	chunked prefill；TM-RoPE + 文本时间戳；ARIA 交错文本/语音	文本、音频、图像/视频 → 文本、语音	`server_vad` / `semantic_vad`；语义打断；idle timeout	模型报告 + 商业 API；未披露固定 micro-turn 调度
TML Interaction Model	输入与输出均切成 200ms micro-turn，按 `input₀ output₀ input₁ output₁` 排列	文本、音频、视频 → 文本、语音	模型原生决定沉默、附和、插话和视觉触发	研究预览；276B MoE、12B 激活；长会话管理仍在研究
Seeduplex	持续接收用户音频，联合建模声学与语义状态	文本、音频 → 文本、语音	原生 listen-while-speaking；语义端点、目标说话人过滤、用户打断	已用于豆包；视觉、backchannel、边听边搜索仍列在后续计划
Grok Live / Voice Agent	WebSocket 双向流；服务端 VAD 或手动提交轮次	API 为文本、音频 → 文本、语音	VAD 阈值/静音时长；idle timeout；工具调用时后台推理	商业 API；内部 token 时间结构未公开；消费端相机能力不等同于 API
GPT-Live	连续全双工；每秒多次决定说、听、停、打断或调用工具	当前产品为语音输入/输出与视觉卡片	原生附和、重叠语音、暂停与打断；复杂任务委派后台模型	ChatGPT 产品；截至发布时尚未开放 API，且不支持视频/屏幕共享

1. Thinking Machines Lab：把交互时间离散成 200ms micro-turn

TML-Interaction-Small 不等待用户轮次结束。系统每次读取 200ms 的音频、视频或文本输入，同时生成对应 200ms 的文本或音频输出，再把两路数据按 input₀, output₀, input₁, output₁... 写进一个自回归序列。沉默、重叠说话和打断因此都是训练序列中的普通状态，而不是外部 VAD 触发后再补写的事件。[19]

其输入侧没有 Whisper 规模的独立编码器：音频 dMel 经过轻量 embedding，图像切成 40×40 patch 后经过 hMLP，音频输出由 flow head 生成，所有组件与 Transformer 从头联合训练。为了让频繁的 200ms 小 prefill 不被推理框架开销吞没，服务端把每次请求追加到 GPU 中的持久序列，并为双向 serving 单独优化 attention 与 MoE kernel。[19]

TML 还把实时 interaction model 与异步 background model 分开：前者持续处理用户、保持对话和接收新输入，后者执行长推理、搜索和工具任务；结果生成后再流回实时模型。其公开演示与 TimeSpeak、CueSpeak、ProactiveVideoQA、Charades 评测覆盖按时间提醒、听到指定口误立即纠正、看到动作发生才开口等主动行为。[19]

这套方法的约束也由官方材料直接给出：TML-Interaction-Small 为 276B 总参数、12B 激活，连续音视频会快速累积上下文；更大的预训练模型尚不能满足该 serving 延迟，长会话需要额外上下文管理，网络抖动也会直接破坏 200ms 节奏。[19]

2. Seeduplex：先解决持续收音中的对象与端点

Seeduplex 的重点不是视觉理解，而是语音全双工中的两个判断：当前声音是否在对模型说话，以及用户究竟是在思考还是已经说完。模型持续接收用户侧音频，把声学特征、语义内容和对话上下文共同用于“开始回答、继续听、响应打断”三类状态决策，不再只由一段静音触发下一轮。[20]

官方公布的豆包线上对照均以此前 half-duplex 模型为基线：端点延迟减少约 250ms，复杂场景中 AI 过早插话率下降 40%，处理用户打断的响应时间减少约 300ms，误响应率与误打断率减半；Endpoint MOS 提升 8%，Dialogue Fluency MOS 提升 12%。这些是同一产品内的 A/B 与主观评测，不是与 Qwen、TML、Grok 或 GPT-Live 的统一基准。[20]

官方路线图同时说明当前能力边界：backchannel 主动附和、由声学上下文发起对话、视觉输入，以及“边听边思考 / 边听边搜索”仍属于后续工作。也就是说，Seeduplex 已把双向语音的节奏控制放入模型，但还没有公开 Qwen3.5-Omni 与 TML 所覆盖的实时视觉接口。[20]

3. Grok Live：产品侧强调语音 Agent，API 仍显式保留 VAD

xAI 当前的 Voice Agent 模型为 grok-voice-think-fast-1.0，grok-voice-latest 指向该版本。API 通过 WebSocket 双向传输音频与文本，支持 Web Search、X Search、Collections、MCP 和自定义函数；reasoning.effort 默认为 high，官方将其描述为在后台进行实时推理。[21][22]

它的轮次接口仍然显式暴露 server_vad：开发者可以设置激活阈值、静音结束时长和前缀音频，也可以关闭 VAD 后手动 commit。idle_timeout_ms 会在助手说完且用户持续沉默时主动再次发言。该 API 与 OpenAI Realtime 事件协议大体兼容，还增加了断线续接、强制播报和发音替换事件。[21]

这套公开接口能确认的是双向流、VAD、工具和后台推理，不能确认模型内部是否像 TML 一样按固定 micro-turn 训练。Grok 消费端 Voice Mode 已提供相机画面理解，但 Voice Agent API 的能力表只列文本与音频输入输出；两者应分别描述。[21][23]

4. GPT-Live：把全双工前台与 GPT-5.5 后台解耦

GPT-Live 于 2026 年 7 月 8 日发布，包含 GPT-Live-1 与 GPT-Live-1 mini。它与此前 GPT-Realtime / Advanced Voice Mode 的差异不是只缩短 VAD 静音阈值：模型在生成输出时持续处理输入，每秒多次决定继续听、开始说、暂停、打断或调用工具，因此可以在用户说话时附和，也可以保持沉默等待用户思考。[24]

复杂任务由另一个模型异步执行。发布时 GPT-Live 将搜索、深度推理和 agentic 工作委派给 GPT-5.5，自己继续维持语音对话，再接收后台结果。这个前台实时模型 + 后台推理模型的系统边界与 TML 的公开描述相似，但 OpenAI 没有披露 GPT-Live 的 micro-turn 大小、音频 token 格式或参数规模。[24]

GPT-Live 发布时只用于 ChatGPT Voice，API 仍在计划中；初始版本也不支持视频或屏幕共享。开发者当前可调用的是另一条产品线 GPT-Realtime-2.1：它在 GPT-Realtime-2 上修改了字母数字识别、静音与噪声处理和打断行为，提供 128K 上下文、可调 reasoning effort、图像输入、语音输入输出和 Function Calling，但不接收视频。因而，GPT-Live 的全双工产品行为不能直接当作 Realtime API 已公开的能力。[24][25]

5. Qwen3.5-Omni：同时开放四类输入，但主动视觉评测仍缺位

Qwen3.5-Omni 同时公开了音视频编码、长上下文、语音生成和实时 API，并在同一实时接口中组合文本、音频、图像和视频输入。semantic_vad 与原生 turn-taking recognition 已经补上 Qwen3-Omni 缺少的语义打断接口，实时服务也支持 WebRTC、WebSocket、工具调用和滚动会话历史。[16][18]

但其技术报告的实时指标集中在首包延迟、RTF、语音质量和音视频问答；没有像 TML 一样公布“看到指定视觉事件后应在何时主动开口”的评测，也没有公开固定的双向 micro-turn 训练序列。由现有资料可以确认低延迟流式输入输出和语义打断，不能进一步推断任意视觉事件触发下的主动发言能力。

七、仍未闭合的具体接口

1. 全双工语音、实时全模态与主动视觉是三个层级

全双工语音要求模型在说话时继续听，并正确处理附和、抢话和背景声；实时全模态还要求视频与音频共享时钟；主动视觉进一步要求模型在没有新问题时持续判断“现在是否该说话”。Seeduplex 已公开前一层，Qwen3.5-Omni 覆盖前两层并提供语义打断，TML 的研究预览把第三层也作为训练和评测对象。[16][19][20]

MiniCPM-o 4.5 将音频、视频输入流与文本、语音输出流放入统一时间线，并以 1Hz 频率判断是否发言，公开模型规模为 9B。[8] 其仓库同时列出 Omni 模式下的发音稳定性、中英文混合和全双工基础能力限制。Moshi 通过同步建模用户与系统两路语音 token 实现语音全双工，但不接收视觉输入。[9] 这些工作补齐的接口不同，不能仅按首包延迟排成一条榜单。

2. 10 小时输入不等于 10 小时持续记忆

Qwen3.5-Omni 将 Thinker 训练长度扩展到 256K，并报告超过 10 小时的单次音频理解；实时 Plus API 却只保留累计 600 秒音频和 240 秒视频，超出后滚动丢弃最早历史。[16][18] 持续会话还需要把已经发生的事件压缩为可更新状态，并在新证据出现后修正旧结论；扩大一次请求的 token 上限并不会自动产生这类长期记忆。

TML 也把 continuous audio/video 的上下文快速累积列为限制。[19] Qwen3-VL 的原生上下文为 256K、可扩展到 1M，可处理数小时视频与秒级事件定位，但它不包含 Omni 的 Talker、MTP 和 Code2Wav。[10] 长视觉记忆、全双工语音和主动交互仍需要在系统层协调。

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

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

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

4. 最新方案仍缺少统一交互评测

首包延迟、turn-taking latency、endpoint MOS、FD-bench 和产品满意度测量的是不同对象。Qwen3.5-Omni 的 235ms 是指定内部推理栈上的理论音频首包；TML 的 0.40 秒是 FD-bench 中的轮次响应；Seeduplex 的 250ms 是相对上一代豆包模型减少的端点延迟；Grok 与 GPT-Live 的公开材料又主要给出产品或 API 指标。[16][19][20][22][24]

可直接横向比较的评测至少要固定网络、音频设备、VAD 策略、并发、是否允许后台模型与工具，并同时记录误打断、漏打断、附和识别、响应内容正确率和主动发言时机。当前公开数字不足以把五套系统压缩为单一排名。

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

3B 或 12B 的激活参数降低的是每个 token 的计算量，不会移除未被当前 token 选择的专家权重。完整部署还要为视觉与音频编码器、Talker、MTP、波形解码器和 KV Cache 预留显存。Qwen3.5-Omni-Plus 与 Flash 没有公开参数明细，TML-Interaction-Small 则公开为 276B 总参数、12B 激活参数，两者都不能只根据激活参数估算显存。[16][19]

vLLM-Omni 通过分模块调度、张量并行和流水线执行处理多模态生成，AWQ、GGUF 等格式降低权重精度；这些方法分别减少调度开销或权重体积，不改变音频、视频 token 与会话时长持续增长的事实。[15]

6. 专用 ASR 与 TTS 仍会把系统带回级联工作流

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

这些模型不需要加载 Omni 中与目标任务无关的视觉或生成模块。相应地，采用 ASR → LLM → TTS 重新组成系统时，就回到了文章开头的级联式 workflow：它换来模块可替换、可单独扩缩容和更清晰的审计边界，也重新引入转写损失、模块间等待与跨模态状态传递。两条路线可以用总驻留参数、首包与端点延迟、跨模块错误传播、工具可控性，以及是否保留语气和视觉上下文分别评估。