Date：2025.09.24（截止当前暂未发布技术报告） 【GitHub】

模型结构

从官方博客来看：

• 相比Qwen2.5VL，对于Vision token处理，采用了DeepStack（Qwen VL家族第一次引入）
• 位置编码采用了MRoPE-Interleave，相较于原来按时间、高度、宽度的顺序分块划分方式，该方式对t、h、w采用交错分布的方式
• 将视频时序建模T-RoPE --> 文本时间戳对齐机制，采用时间戳-视频帧交错的输入方式，实现帧级时间信息同视觉内容的对齐
  从Transformers库更新来看：【GitHub】
• Vision Encoder改变：

  • 激活函数：silu --> gelu_pytorch_tanh

  • patch尺寸：14 --> 16

  • Qwen3-VL/vision_config:

  • Qwen2.5-VL/vision_config:

  • 疑惑：反直觉的是，整体看来模型的深度是降低了，模型更加稀疏

  • 总结：patch_size的增加有助于减少token数量，降低计算量，缺点是更容易丢失局部信息。

  • 输入token数量：$（N=(H\times W)/{patchsize}^2）$

• images processor 和 tokenizer同Qwen2.5VL相同，延续Qwen2的相同配置
• 视频方面，原先的缩放只针对空间进行缩放，现在拓展到时间维度，对视频处理更加合理
• MRoPE:

  • T-RoPE：Qwen2.5VL采用人工设计的、规则性的方式对时间序列进行编码（主要是指在视频中），但Qwen3VL创新性的提出，MRoPR的时间维度在视觉token中不起作用，恒为0。真正的时间顺序捕捉依赖于<t1> <t2>等文本时间戳token的文本位置，以语言模型的注意力机制来实现的。简言之，让模型感受到文本描述中的事件发生顺序。

    疑问：既然采用时间戳的方式，那为何还需要手动设置t_index在视觉方面不应用。

  • Interleave：交错(T, H, W)三元组的位置编码，并不是Qwen2.5VL顺序排列三个维度

    • Qwen2VL系列做法：1、对于视频，T的index随帧递增；2、对于图片，固定T不变，HW随位置变化 变化二维index；3、对于文本，（T，H，W）均默认相等；4、位置编码就按照三元组的顺序递增

    • Qwen3VL做法：假设原始位置编码为[T1,T2,T3,H1,H2,H3,W1,W2,W3] --> [T1,H1,W1..]，推测这种交错可以理解为每个视觉token都是一个三元组的位置编码形式？或者说每个三元组对应一个patch的时空位置。

    • 在配置文件中，写到mrope_section = [24, 20, 20]，分别指THW的索引分布，T在前旋转角度慢，可以建模长时间依赖（但实际上是保持风格一致，具体实现为全0），HW在后，旋转快，对短距离细节建模有好处。至于为何索引总和为64，因为这是head_dim的维度整除2。原因是：RoPE采用对维度拆为两半，采用不同的变化方式。

    • 关于multi-head Attention为防止后续疑惑，在此写出：多头注意力机制的每个head的维度并不是隐藏层的维度，而是hidden_dim // num_heads，后续通过reshape操作reshape(B,L,-1)将[B, L, num_heads, head_dim]重新映射为[B, L, hidden_dim]，其可以理解为将hidden_dim拆分为多个head进行计算注意力最后concat一起，但这个过程并不是显示进行的，而是隐式的。该方法不仅可以降低计算量，降低显存占用，更能充分利用计算、映射，得到更深层次的语义信息。

• 🧠🧠🧠Deepstack：一句话总结：将视觉特征分层次注入语言模型多个中间层，目的是为让语言模型在抽象层次上能更好的理解视觉语义，提升细粒度理解能力。
  具体来说：Deepstack也是一种残差链接！
  • 配置：在config中写到deepstack_visual_indexes=[8, 16, 24]代表ViT那些层输出用于deepstack
  • 步骤1：将在索引中的输出通过patch merger处理特征
  • 步骤2：在语言模型的前N层（N = len(deepstack_visual_indexes)）注入视觉特征(_deepstack_process函数)，简单来说，如果符合注入规则，那么将改层输出的对应位置直接相加该部分的视觉编码（因此类似于残差链接）