1. Thinker-Talker 双核架构#

Qwen3.5-Omni 延续了从 Qwen2.5-Omni 开始的 Thinker-Talker 设计，但做了大幅度升级。

**Thinker（思考者）**负责”理解”：

• 视觉编码器：采用 SigLIP2，处理图像和视频帧
• 音频编码器（AuT，Audio Transformer）：从零训练，基于 4000 万小时音频-文本对，输出 token 速率 6.25Hz（即每秒约 6 个 token）
• 骨干网络：Hybrid-Attention MoE Transformer，用 TMRoPE 做时间位置编码，让视频、音频、文本三个模态在时间维度上精确对齐
• 输出：文本推理结果

**Talker（表达者）**负责”说话”：

• 接收 Thinker 的多模态语义和文本输出
• 通过 MTP（Multi-Token Prediction）模块 + 因果卷积网络（Causal ConvNet）解码器 生成 RVQ codec tokens
• 用 ARIA 机制做文本-语音动态对齐
• 输出：流式语音

关键点在于：Thinker 和 Talker 共享同一个 Hybrid MoE 骨干，不是两个独立模型。这意味着语音生成和文本推理在底层表示上是互通的，不会出现”理解了一回事、说出来变成另一回事”的问题。

2. GDN：把 O(n²) 打回 O(n)#

这是 3.5-Omni 最硬核的架构升级。传统 Transformer 的自注意力复杂度是 O(n²)，序列越长越慢，KV Cache 也线性增长。Qwen3.5 的解法是用 GDN（Gated Delta Net，门控差分网络） 替换掉 75% 的标准注意力层，保留 25% 的全局注意力层，两者按 4<1> 的比例交替排列。

GDN 的核心思路：

1
标准注意力：QKV 全量计算 → O(n²) 复杂度，KV Cache 线性增长
2
GDN：       状态压缩 → 增量更新 → O(n) 近似复杂度，KV Cache 恒定大小

效果是惊人的：在 256K 上下文时推理吞吐提升 8.6 倍，在 1M 上下文时提升 19 倍。这就是为什么 Qwen3.5-Omni 能一口气处理 10 小时音频——不是因为硬件变强了，而是因为算法复杂度降了一个数量级。

3. ARIA：流式语音生成的”稳拍器”#

做过流式 TTS 的人都知道一个痛点：文字生成和语音生成的速度不一样，经常会出现语音”抢拍”（文字还没生成完，语音已经开始念下一个词）或者”吞字”（某些词被跳过）。

Qwen3.5-Omni 提出的 ARIA（Adaptive Rate Interleave Alignment，自适应速率交错对齐） 用一个很优雅的约束解决了这个问题：在双通道（文本 + 语音）生成中，累积的语音-文本 token 比率不能超过全局的 item 级别比率。简单说就是：语音不能跑在文字前面太远，也不能落后太多。

ARIA 把双通道生成统一成了单通道公式，动态调整语音 token 的插入速率。实际效果是：流式语音的韵律稳定、不吞字、不抢拍，接近离线 TTS 的质量。

4. TMRoPE：时间对齐的位置编码#

从 Qwen2-VL 的 M-RoPE（把位置编码分解为 temporal/height/width 三维）到 Qwen2.5-Omni 的 TMRoPE（把音频也纳入时间维度对齐），再到 Qwen3.5-Omni 的进一步改进——不再依赖绝对时间 ID，而是给视觉和音频 patch 直接附加显式字符串时间戳。这个改动看似简单，但对长视频理解至关重要：模型不再需要”数 token 来推算时间”，而是直接”看到”每个片段的时间标记，长程时间感知能力大幅提升。

1. 预训练：三阶段递进#

Qwen3.5-Omni 的预训练分三个阶段：

阶段一：初始对齐（Initial Alignment）

• 冻结骨干语言模型参数
• 只训练视觉适配器和音频适配器
• 目的：让各模态的 token 表示初步对齐，不破坏已有的语言能力

阶段二：通用训练（General Phase）

• 解冻全部参数
• 使用约 4 万亿 tokens，序列长度 32K
• 数据分布：音频 1.99T、文本 0.92T、图像 0.95T、视频 0.14T、音视频联合 0.29T
• 音频数据来源超过 1 亿小时的音视频内容

阶段三：长上下文训练（Long Context Stage）

• 序列长度扩展到 262K tokens
• 专门针对长音视频场景训练
• 让模型学会在超长序列中保持信息连贯

2. 后训练（Thinker）#

Thinker 的后训练包括三步：

• 专家蒸馏（Expert Distillation）：用各领域的专家模型当老师，把领域知识注入到统一网络里
• On-Policy 训练：用高质量文本回答作为训练目标，但输入是音频——这相当于让模型学会”听到问题后像读过问题一样回答”，弥合了模态间的理解差距
• 强化学习（RL）：针对多轮对话的稳定性和一致性做对齐

3. 后训练（Talker）#

Talker 的训练流程更独立：

• 通用训练：2000 万小时多语种语音数据
• 长上下文延续训练
• 偏好优化：DPO（Direct Preference Optimization） + GSPO
• 针对性语音微调

1. 文本理解：没有因为多模态而退步#

这是很多人担心的问题——一个模型什么都能干，会不会什么都干不好？Qwen3.5-Omni Plus 的文本评测给出了否定答案：

和同级别的纯文本模型 Qwen3.5-Plus-Instruct 相比，文本能力基本持平，没有因为引入音频和视觉模态而退化。这得益于阶段一的冻结训练策略——先保住语言能力，再逐步对齐其他模态。

2. 音频理解：超越 Gemini 3.1 Pro#

在通用音频理解和语音交互评测上，Qwen3.5-Omni 超越了 Gemini 3.1 Pro。语音识别方面，Fleurs ASR 错误率 6.55，Common Voice 15 英语 4.83，LibriSpeech-clean 1.11。

3. 视觉理解：视频理解是亮点#

静态图像理解和同级别纯视觉模型相当，但视频理解是明显优势——MLVU 86.8、MVBench 79.0，这得益于 256K 的长上下文和 GDN 对长序列的高效处理。

4. 音视频联合理解：新赛道的新标杆#

在音视频联合理解这个较新的评测领域，Qwen3.5-Omni 在 DailyOmni 上达到了 84.6 的 SOTA，音乐理解（MuchoMusic 72.4 vs Gemini 3.1 Pro 的 59.6）更是拉开了巨大差距。

5. 语音生成：TTS 能力令人意外#

这可能是 Qwen3.5-Omni 最被低估的能力。作为一个全模态模型的”附属功能”，它的 TTS 表现甚至打败了专用 TTS 系统：

• SEED 英语 WER：1.26（接近完美）
• 跨语种：中文到韩语 WER 4.03（对比 CosyVoice3 的 14.4，相对下降 72%）
• 多语种：在大多数语言上击败 MiniMax-Speech 和 ElevenLabs
• 语音相似度：在 29 种语言上保持说话人特征迁移
• 词错误率：2.06%，对比 ElevenLabs 的 12.62% 和 Gemini 2.5 Pro 的 2.72%

支持的语言覆盖：113 种语音输入（74 种语言 + 39 种中国方言），36 种语音输出（29 种语言 + 7 种中国方言）。

1. 首包延迟（First-Packet Latency）#

2. 分阶段延迟#

几个关键观察：

• Flash 版的音频首包延迟 235ms，已经低于人类对话中”自然停顿”的感知阈值（约 300ms），这意味着实时语音对话体验接近真人对话
• Talker 的首 token 延迟只有 54-61ms，说明语音生成几乎在 Thinker 输出文本的同时就开始了，双通道并行效率极高
• 采用了分块预填充（Chunked Prefilling） 技术来降低首包延迟
• 在 8 路并发下，Flash 的整体延迟仍保持在 352ms，Plus 为 955ms，扩展性良好
• 实时生成因子（RTF）始终低于 1.0，保证流式播放不会卡顿

3. 智能语义打断#

Qwen3.5-Omni 支持智能语义打断（Semantic Turn-Taking）：能区分用户是在”组织语言”还是”真的想打断”。这比简单的 VAD（语音活动检测）高级得多——模型在理解语义层面的意图后才决定是否中断当前输出。

1. Audio-Visual Vibe Coding#

这是 Qwen3.5-Omni 最酷的演示场景：对着摄像头展示一个 UI 截图或手绘草图，同时口述需求，模型直接生成可执行代码。全程不需要外部编排器（Agent Framework），不需要 ASR 转写中间步骤，从音视频信号直接到代码。

这个能力之所以叫”涌现”，是因为训练数据里并没有专门的”看视频写代码”样本——它是视觉理解 + 音频理解 + 代码生成三种能力在原生全模态架构下的自然组合。

2. 结构化视频字幕#

模型能自动对长视频进行场景分割，生成带时间戳的结构化字幕。比如给它一集 50 分钟的《老友记》，它能理解完整剧情并输出按场景划分的字幕摘要。这得益于 256K 的长上下文和显式时间戳机制。

3. 即时语音克隆#

给定几秒钟的参考语音，Qwen3.5-Omni 就能克隆说话人的声音特征，并跨 29 种语言保持音色一致性。这个能力在跨语种配音、个性化助手等场景有直接应用价值。

1. 发生了什么#

Qwen3.5-Omni 采用了部分开源策略：

• 技术报告公开发表在 arXiv（CC BY 4.0 协议）
• 基础权重”逐步释放”给公众
• 商业应用需要通过阿里云 API 调用
• API 定价（每千 token）：文本 0.004 元、图像 0.02 元、音频 0.1 元、视频 0.5 元

对比前代 Qwen2.5-Omni-7B 的完全开源（Apache 2.0 协议，权重直接下载可用），这是一个明显的策略转向。

2. 为什么这么做#

从商业逻辑看，这并不意外：

• 训练成本暴涨：4 万亿 token 的预训练、1 亿小时音视频数据、4000 万小时的音频编码器训练——这些资源的投入量远超上一代，完全开源等于把巨额投入拱手送人
• 竞争压力：Gemini 3.1 Pro、GPT-4o 等闭源模型在多模态赛道竞争激烈，Qwen 需要在商业 API 市场建立收入来支撑后续研发
• 阿里云的商业化需求：正如多篇分析指出的，“阿里云越赚钱，开源生态越危险”——云厂商的核心利益和开源社区之间存在天然张力

3. 对社区的影响#

短期来看，开源社区确实受到了一定冲击。Qwen2.5-Omni-7B 曾经是最受欢迎的开源全模态模型之一，完全开源、性能出色、中文优化好。3.5 代的闭源转向意味着：

• 研究者无法再直接下载权重做实验和微调
• 创业公司无法在本地部署做离线推理
• 社区的二次开发生态受到限制

但长期来看，也有积极的一面：技术报告的详细程度依然很高，架构细节、训练流程、评测数据全部公开。后续也有报道指出 Qwen3.8 系列重新回归了开源路线，说明这种”部分开源”可能只是一个阶段性策略，而非永久转向。

模型规格#

关键架构组件#

延迟数据#

核心评测分数#

语言覆盖#

Qwen 多模态演化时间线#

数据来源：arXiv<2604>.15804 论文正文，Qwen 官方博客，以及公开技术报道。部分延迟数据来自论文 Table 的 1-concurrency 设置。