1.多模态统一训练的复杂性#

在现实世界中，各个模态（文本、图像、语音和视频等）的数据分布和特征形式大不相同。传统大模型最喜欢的文本模态是离散符号序列，音频则更关注短时频谱动态，图像/视频有二维甚至三维时空结构。想要把这些模态放到同一个模型中进行端到端的统一训练，首先就需要面对大规模的数据标签风格和模态差异带来的对齐问题。所以，模型必须具备一种“系统性方法”来实现图像-文本、视频-文本、音频-文本等对齐，这既要求模型本身具备足够灵活的结构，也需要能够在训练阶段让所有模态“互相促进”，而不是各管各的。

更进一步，如果将多模态特征全部简单拼接在一起，很可能导致不同模态之间互相干扰，甚至把原本在各模态上已学到的特征能力“破坏”掉。为了克服这一难点，Qwen2.5-Omni 会在模型结构和训练数据上进行特别设计，例如先通过大量单模态或双模态对齐数据进行预训练，再逐步纳入更大规模的多模态混合数据等。

2.时间同步与多维位置编码#

音频、视频都具有时间维度，并且二者需要对齐以保证“所见即所听”。如果在时间轴上对它们进行不当处理，一方面容易损失视频时序或音频节奏信息，另一方面还会造成语音与视频帧不同步。报告里提出的一大创新是 TMRoPE（Time-aligned Multimodal Rotary Position Embedding），通过对输入序列做“时间切块+多维位置编码”，在 40ms 这一相对统一的时间粒度下，让音频帧和视频帧逐步匹配。加之对图像、视频的高度与宽度位置编码进行区分，最终在单一的 Transformer 模型里实现了多模态时空信息的对齐与融合。

对于不同帧率的视频，Qwen2.5-Omni 也会通过动态插值、块状处理等策略来减少长序列带来的内存开销，进而实现实时处理，保证了多模态编码器不会因为“时序过长”而失效。

3.同时生成多模态输出的相互干扰#

与常见的“多模态输入、单模态输出”不同，Qwen2.5-Omni 还要能在输出侧同时生成文本和语音，并且是以流式的方式生成，这里另一个难点就出现了：如何避免文本和语音在解码过程中的相互干扰？

报告中专门提出了 Thinker-Talker 架构：

• Thinker 相当于“语言大脑”，进行高层的语言思考、生成文本，并提供抽象的语义向量给到后续。
• Talker 则只关注如何把 Thinker 的这些高维语义表示转成语音编码，并进一步流式输出音频。

通过这样的解耦，模型能在同一套流水线（同一个 Transformer）里，并行完成“文本思考”和“语音生成”两件事，不至于出现语音编码和文本编码在输出层互相“污染”的问题；同时还能根据用户需求，决定用文字还是语音来回复，也可以两者都输出。

在其他多模态模型里，如果直接共享一个单一解码器输出多模态，极易导致参数竞争、梯度冲突，从而影响整体生成质量。

4.全模态模型在流式场景下对模型结构和推理效率的高要求#

要支持实时语音对话或视频对话，单纯解决输入和输出的模态融合并不够，还得兼顾“延迟”——尤其是语音、视频数据量大，且往往需要连续接收和生成。如果仍使用传统的全局注意力机制去处理几分钟甚至更长的音视频序列，模型规模和计算量都会成倍飙升。

为此，Qwen2.5-Omni 在多模态编码器上采用了“块状（block-wise）”或“滑动窗口”的注意力机制，对长序列进行分块处理；又在生成端使用了分段自回归的方式（双轨自回归 + Streaming DiT），能在相对有限的上下文内完成一段语音的生成，再与下一个音频块顺畅衔接，减少初始包时延。这些设计都是为了真正做到“边输入边输出”，而不是一次性拿到所有音视频后再统一推理。

1.Thinker模块：负责理解与文本生成#

Thinker模块本身就可以被视为一个大语言模型（LLM），用来接收来自多种模态的输出（文本、图像、音频、视频），将这些信息转化为高层语义表示。在在输入端，Thinker 通过一系列编码器（Audio Encoder、Vision Encoder）获取语音、图像 / 视频的表示，再和文本序列的表示在统一的 Transformer 解码器中融合。不同模态在实际处理时，通过 TMRoPE 等时间对齐机制确保时序信息一致，从而让 Thinker 能获得对多模态的整体理解。

当用户需要纯文本回答时，Thinker 就直接把语义向量转化为文本输出（经典的自回归生成过程）。从架构上看，它承担了大部分复杂的“语言思考”和 “语义推理”工作。

2.Talker模块：负责语音生成#

• “嘴巴”角色，双轨自回归

  Talker 采用了 dual-track autoregressive 方式，专门针对语音生成而设计。它在训练和推理过程中，会和 Thinker 同步进行，但只需要关注如何将 Thinker 的高维语义表示转换成音频编码再合成语音。

  Talker模块会接收来自 Thinker 采样文本标记的高层表示和嵌入。作为一种流式算法，语音生成必须在整个文本完全生成之前预测内容的声音和态度。Thinker 提供的高维表示隐式传达了此类信息，从而实现更自然的流式生成过程。

  Qwen团队还设计了一种高效的语音编解码器 qwen‑tts‑tokenizer。qwen‑tts‑tokenizer 能够高效地表示语音的关键信息，并且可以通过因果音频解码器流式地解码为语音流。接收信息后，说话者开始自回归地生成音频标记和文本标记。语音生成不需要与文本在词级和时标级上进行对齐。这显著简化了训练数据和推理过程的要求。

• 融合文本 token 与高维向量

  语音生成并非仅依赖 Thinker 的隐藏语义表示——报告中提到，为了让模型在需要实时输出、并且可能有丰富情感或语气时能生成更自然的声音，Talker 还会拿到一部分实际采样出的文本 token 作为参考，以消解同音词、语义模糊等问题，保证与文本意义相匹配的音频生成。

• Streaming DiT 实现流式语音输出

  Talker 输出的语音编码最终会通过后端的 DiT（Diffusion Transformer）模块生成音频波形，而这个环节采用了“滑动窗口”分块处理，用相对有限的上下文就能持续生成音频，减少延迟，这也是整个系统能支持“边录音、边回复”的关键。

NOTE

在初始预训练阶段，Qwen2.5-Omni的LLM组建用的是Qwen 2.5，视觉编码器与Qwen2.5-VL相同，音频编码器则使用Whisper-large-v3进行初始化。