位置编码

当模型不再只处理文本时，位置编码就会变得更有意思。在纯语言模型里，位置是一个一维概念：每个 token 都只是在序列中占一个位置。但在视觉语言模型和 omni 模型里，这个假设不再成立。图像 token 位于二维网格上，视频 token 位于时空网格上，音频 token 又有自己的一套时间坐标。此时真正的问题不再只是“如何编码顺序”，而是“如何编码结构”。

本页按这一条演化路线组织三类相关方法：

RoPE：面向一维 token 序列
M-RoPE：面向多模态或时空坐标
TM-RoPE：进一步强调跨模态时间对齐，尤其是音频与视频

下面会保留必要的公式，但重点仍然放在每一类方法到底试图保留什么结构。

RoPE

Rotary Position Embedding 的核心思想，是在 query 和 key 的二维子空间上做旋转，从而把位置信息直接写进 attention 的几何关系中。设

\[ x \in \mathbb{R}^d \]

并把隐藏向量按相邻两维分组：

\[ x = (x_0, x_1, x_2, x_3, \ldots). \]

对于位置 \(p\)，第 \(i\) 个二维子空间上的旋转角定义为

\[ \theta_i(p) = p \, \omega_i, \]

其中 \(\omega_i\) 是第 \(i\) 个频率分量。对应的旋转写成

\[ \begin{pmatrix} x'_{2i} \\ x'_{2i+1} \end{pmatrix} = \begin{pmatrix} \cos \theta_i(p) & -\sin \theta_i(p) \\ \sin \theta_i(p) & \cos \theta_i(p) \end{pmatrix} \begin{pmatrix} x_{2i} \\ x_{2i+1} \end{pmatrix}. \]

标准的频率设计通常是几何级数：

\[ \omega_i = 10000^{-2i/d}. \]

RoPE 最重要的性质在于，它让 attention 对 相对位置 敏感。也就是说，经过旋转之后，query 和 key 的内积不再只反映内容相似性，还会自然包含它们之间的位置差。这就是 RoPE 与“把一个绝对位置向量直接加到 embedding 上”最本质的区别：它不是把位置附着在表示上，而是直接改写了表示之间的几何关系。

对文本来说，这套机制非常自然，因为语言 token 本来就是一条一维序列。但一旦进入视觉和视频场景，问题就变得复杂了。图像 patch 不是只有一个序号，它还同时具有高度和宽度坐标；视频 token 更进一步，还带有时间坐标。此时如果继续用原始 RoPE 的一维位置索引，就相当于把原本有明确几何结构的时空网格压平成了一条序列。

M-RoPE

M-RoPE 可以理解为把 RoPE 从一维位置推广到多维坐标。在视觉和视频模型里，一个 token 更合理的描述方式通常是

\[ (t, h, w), \]

其中 \(t\) 表示时间，\(h\) 表示高度，\(w\) 表示宽度。M-RoPE 的目标，就是让 rotary position embedding 能够处理这样的多维位置。

一个很自然的抽象方式，是把隐藏维度拆成多个子空间：

\[ d = d_t + d_h + d_w. \]

然后分别在这些子空间上编码不同坐标轴：

\[ \mathrm{M\mbox{-}RoPE}(x; t,h,w) = \big[ \mathrm{RoPE}_t(x_t; t), \mathrm{RoPE}_h(x_h; h), \mathrm{RoPE}_w(x_w; w) \big]. \]

这个表达更适合作为理解框架，而不应被视为所有模型都逐项按此实现的字面公式。它要表达的核心是：时间、垂直位置和水平位置不再共享同一个一维位置索引，而是分别进入 rotary phase。因此 attention 可以显式依赖

\[ (t-t', h-h', w-w') \]

这样的相对时空差。

在 Qwen2.5-VL 这类模型里，官方文档和博客把 MRoPE 与动态分辨率、动态 FPS 采样以及视频 absolute time encoding 放在一起讨论。它的工程含义是：模型不再把视频看成一串平铺 patch，而是显式保留时间与空间结构；同时，时间位置也不只是“第几帧”，而可以尽量对齐真实采样间隔。这也是 Qwen2.5-VL 相比更早的图文模型，在视频理解上明显更像一个真正的视频模型的原因之一。

不过，M-RoPE 也有自己的局限。因为总维度是固定的，一旦把维度分给时间、高度和宽度，每个坐标轴实际上只能占用部分频谱资源。原始 RoPE 中，一个位置轴可以使用完整频谱；而在 M-RoPE 中，每个坐标轴只能使用自己的那一部分。这对静态图像通常不是大问题，但对长视频来说，时间维很可能恰恰是最需要长距离建模能力的轴，如果它分到的维度和频率资源不够，就会出现时间建模偏弱的问题。

TM-RoPE

TM-RoPE 可以看作是在 M-RoPE 基础上的进一步发展，它特别面向 omni 场景下的音频与视频联合建模。到这个阶段，时间已经不再只是三个坐标轴中的一个，而是不同模态之间必须共享的参考系。

Qwen2.5-Omni 的公开说明把 TMRoPE 描述为一种用于同步 video 和 audio timestamp 的机制。这一点非常关键，因为它告诉我们 TM-RoPE 的真正目标不是“再多一个维度”，而是 跨模态时间对齐。换句话说，一个来自音频流的 token 和一个来自视频帧的 token，即使它们在拼接后的序列中相距很远，只要它们对应同一物理时刻，模型就应当能够在位置空间中把它们视为相互对齐的对象。

从抽象角度看，TM-RoPE 可以理解为不再把

\[ (t,h,w) \]

严格拆到彼此独立的子空间里，而是允许多个坐标轴共同参与同一个频率分量的相位生成。一个便于理解的概念形式是

\[ \theta_i(t,h,w) = \alpha_i t + \beta_i h + \gamma_i w, \]

其中 \(\alpha_i\)、\(\beta_i\)、\(\gamma_i\) 决定第 \(i\) 个频率分量如何综合时间与空间坐标。对应的旋转写成

\[ R\big(\theta_i(t,h,w)\big), \]

并作用在第 \(i\) 个二维子空间上。

这里同样要强调，这个公式更适合作为理论上的统一视角，而不是对具体实现细节的逐行复刻。它表达的是一种建模假设的变化：

在 M-RoPE 中，不同坐标轴主要被分配到不同子空间
在 TM-RoPE 中，多个坐标轴可以共同决定同一个相位

这种变化带来两个直接好处。第一，时间维不再只能使用某一小段固定频谱，而是可以共享更完整的频率资源，因此更适合长时间跨度建模。第二，跨模态时间对齐更容易表达，因为音频 token 和视频 token 可以被映射到同一个时间参考系中，而不是各自维护一套局部位置编号。

一个统一视角

这三类方法其实都可以放进同一个模板里理解：

\[ \theta_i = \sum_k \lambda_{i,k} \, p_k, \]

其中 \(p_k\) 表示位置分量，\(\lambda_{i,k}\) 表示第 \(i\) 个频率分量如何使用这些位置分量。

对标准 RoPE 来说，只有一个一维位置：

\[ \theta_i = \omega_i p. \]

对按轴拆分的 M-RoPE，可以写成

\[ \theta_i = \begin{cases} \omega_i t, & i \in \mathcal{I}_t \\ \omega_i h, & i \in \mathcal{I}_h \\ \omega_i w, & i \in \mathcal{I}_w \end{cases} \]

对耦合式的 TM-RoPE，则可以写成

\[ \theta_i = \lambda_{i,t} t + \lambda_{i,h} h + \lambda_{i,w} w. \]

从这个角度看，三者之间的关系就很清楚了：

RoPE：一维相位编码
M-RoPE：按坐标轴拆分的多维相位编码
TM-RoPE：更强调多轴耦合和跨模态时间对齐的多维相位编码

对比

方法	位置空间	频谱使用方式	保留的相对结构	最直观的理解
RoPE	一维序列位置	一个轴使用完整频谱	token 相对顺序	序列旋转编码
M-RoPE	多维坐标，如 \((t,h,w)\)	频谱按轴拆分	相对时间与相对空间	多轴 RoPE 扩展
TM-RoPE	多维且跨模态对齐的坐标	更共享、更耦合的频谱使用	相对时间、相对空间与跨模态时间同步	统一时空相位编码

实际理解

如果模型只处理文本，RoPE 已经足够，因为它只需要知道 token 在一维序列里的相对顺序。
如果模型需要处理图像和视频，M-RoPE 就变得必要，因为视觉 token 不应被看作单纯的平铺序列，而应该被看作带时空坐标的结构化对象。
如果模型进一步进入 omni 场景，需要同时处理音频和视频，并且要求两者在同一物理时间轴上对齐，那么 TM-RoPE 就会变得更自然。

因此，这条演化路线不只是“位置编码越来越强”，而是“位置本身的定义在变化”：

从序列中的顺序，
到时空坐标，
再到跨模态共享的时空参考系。

备注

本页中的 RoPE 公式属于标准写法。
对 M-RoPE 和 TM-RoPE，本页给出的公式是帮助理解的抽象表达，重点在于说明它们在建模层面如何从一维相位编码走向多维和跨模态相位编码。公开的 Qwen 文档明确说明了它们的作用，但不一定总以单一闭式公式的形式完整展开。
与 Qwen 相关的公开参考资料主要包括：
Qwen2.5-VL documentation
Qwen2.5-VL blog
Qwen2.5-Omni repository