
最近被多模态的效果圈粉，感觉距离那个"OCR 糊成一团、指令理解弱到离谱、幻觉高到吓人"的时代也没过去多久，但多模态模型的效果已经发生了飞跃式的进步。

这篇文章我们来系统梳理这背后的"进化轨迹"：模型骨架如何一步步演变、位置编码如何从一维延伸到三维、图片分辨率的难题如何被逐步破解，以及多模态训练策略背后最关键的两个反直觉发现。

# 一、多模态骨架的三次进化

在进入细节之前，先建立一个整体认知框架：多模态模型的架构演进，本质上是在回答同一个问题——

> **"图片和文字，到底应该在哪里、用什么方式融合？"**

每个时代给出了不同的答案。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/5e531f407653b4465cc00cbd631e4de7.jpg)

## Era1. 给语言模型装上眼睛（2022–2023）—— Llava，Qwen-VL1-2
> Visual Instruction Tuning（Liu et al., 2023）

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/e2ac2e992e868814fd80fcba4fb8d47a.jpg)

核心设计哲学：视觉编码器和 LLM 都很贵，冻住它们，只训练中间的"翻译官"。

这个逻辑很朴素——既然视觉编码器（CLIP ViT）和语言模型（Vicuna/Qwen-7B）都已经在各自领域预训练得很好了，那就别动它们，只用少量数据和算力训练中间的桥梁就好。

LLaVA 的两阶段训练：

|阶段|	冻结什么|	训练什么|	用什么数据|
|-----|-----|-----|-----|
|阶段一：特征对齐|	视觉编码器 + LLM|	只训练适配器|	图像描述（Caption）类任务|
|阶段二：指令微调|	只冻结视觉编码器|	适配器 + LLM|	图像对话问答类任务|

Qwen-VL 在此基础上加了第三阶段： 解冻全部参数，用 OCR、Visual Grounding等任务，专门强化模型的细粒度感知能力。这是从"看到是什么"向"感知空间关系"的第一步迈进。

但 Era1 有三个根本性的缺陷，驱动了后续的演进：
- 🔴 **“语言优先”的模态失衡**：视觉模态就像新朋友无法融入文本群体，往往被忽略。导致很多图像理解问题上模型幻觉高的吓人
- 🔴**模态“拼接”的本质缺陷**：视觉模态和文本模态天然存在分布差异、范数差异、信息密度差异，导致单纯拼接表征，模型很难提取出有效信息
- 🔴 **深层图像理解能力缺失**，固定分辨率、和输入层融合导致更多高分辨率细节、空间感知任务的完成都并不好

## Era2. 让大脑“看见”更深层（2024-2025）- Qwen-VL3

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/a9792534472a56503b2d88c0f9a86ef2.jpg)

Era1 的翻译官只工作了一次——在图片进入大脑之前。进了大脑，视觉信息就和文字混在一起，靠 LLM 自己去消化。

问题是：视觉信息中的细节（小字体、空间位置关系、图表结构）很容易在 LLM 的深层网络里被"稀释"掉。

**Era2 的核心思想：全面深入，让视觉模态真正参与到模型的每一层学习中。**同时攻克三个关键技术难题（位置编码、动态分辨率、训练策略），我们后面会重点展开。

Qwen-VL3给出的方案是DeepStack,从 ViT 的多个中间层抽取特征，分别注入 LLM 的不同层, 低层 ViT 特征保留边缘、纹理等细节信息，高层特征保留语义信息, 这样不同层的语言模型能看到不同粒度的视觉信息。

```text
图像 → [ViT编码器] → 第6层特征 ──→ 注入LLM第5层
                    → 第12层特征 ─→ 注入LLM第15层
                    → 第18层特征 ─→ 注入LLM第25层
                    → 第24层特征 ─→ 注入LLM第35层
                                    ↓
文本Token ──────────────────────→ [LLM主干] → 回答
```


## Era3. 打掉眼睛和耳朵，统一多模态架构 (2026+)- Gemma4

有了Era2把融合做到极致，那下一步自然是索性去掉融合的过程，让多模态从最初就开始统一训练, 也就是丢掉视觉、语音编码器，多模态从头融合训练。

Gemma4直接在架构层去掉图片、音频编码器，让多模态在输入层就进行融合，具体实现：

- 图片怎么进来？ 把图像切成 48×48 像素的图块（patch），通过一个约35M参数的投影矩阵，直接映射到和文字 token 一样的向量空间。
- 音频怎么进来？ 把 16kHz 的音频按每 40ms 切一片，复用和图片一样的投影矩阵，也变成同维度的向量。
- 然后呢？ 图片 token、音频 token、文字 token，按用户输入的顺序拼在一起，由同一个 Transformer 用同一套注意力机制处理——没有任何模态特权。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/5ebfe539991c411c499ff2b18ea48df5.jpg)

这里有个值得注意的设计细节：为什么要把图片和音频切得这么"粗"？

因为图片和音频的信息密度，天然比文字低很多。一个文字 token 承载了高度压缩的语义信息；而图片的一个像素区域，信息其实是高度冗余的。所以更大的信息粒度和文字 token 的信息密度更接近，Transformer 处理起来才不会"浪费注意力在背景像素上"。当然参考后面动态分辨率的处理思路，按预算和语义密度进行动态切割或许是更好的方案。

# 二、三大核心技术难题 ——把“问题从何而来”讲清楚

说完架构层面的变化，下面我们接着说几个核心问题的攻克
- **位置编码如何表征空间和时间**:把 2D/3D 世界硬压成 1D 序列，长视频尤其受损
- **如何支持动态分辨率**:固定 224/336 一刀切导致 OCR/文档/小目标崩
- **如何训练解决模态冲突**：视觉加入时机与比例不当会拉低语言能力或导致“看不见”

## 难题一：位置编码如何表征空间和时间？

语言模型的 Transformer 在处理 token 序列时，天然不知道哪个词在前、哪个词在后——注意力机制本身是"无序的"。位置编码给每个 token 打上一个"我在第几位"的标签，让模型能感知顺序。

对于纯文字，这很简单：每个词有一个位置编号，1、2、3……往后排。

但图片不一样。图片里的信息是二维的——一个像素块不只有"在第几位"，还有"在第几行、第几列"。视频更复杂，还加了"在第几帧"这个时间维度。

把二维、三维信息硬压成一维序列，就像把一张地图折叠成一条线——空间关系全乱了。

### M-RoPE：给模型装三块"表盘"

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/09260e97e5ff4cc681d0f099457cf95d.jpg)

Qwen-VL2 引入了 M-RoPE（多模态旋转位置编码），核心思想是：给每个 token 配三块表盘，而不是一块。

|模态|	T 表盘（时间/帧）|	H 表盘（垂直位置）|	W 表盘（水平位置）|
|-----|------|-----|-----|
|文字	|随位置递增	|同 T	|同 T（退化为 1D）|
|图片|	固定不动|	随行号变化|	随列号变化|
|视频	|随帧数递增|	随行号变化|	随列号变化|

对于文字，三块表盘转速一样，等价于原来的 1D 位置编码，没有额外损耗。对于图片和视频，模型只需要"看表盘的指针夹角"，就能天然感知到像素之间的空间距离和帧之间的时间顺序——不需要额外记忆坐标。

**实现上的一个关键演进：频段分配方式**

具体实现时，每个注意力头的维度要被切成三份分别给 T/H/W。Qwen-VL2 的做法是顺序切分——前 1/3 给 T，中间 1/3 给 H，最后 1/3 给 W。

但 Qwen-VL3 发现这个做法有个隐患：每个维度只能感知特定频段的信息，会导致模型对某些空间频率无法感知。Qwen-VL3 的修正方案叫交错分配：

```
通道索引 0, 1, 2,  3, 4, 5,  6, 7, 8 ...
          ↓  ↓  ↓  ↓  ↓  ↓  ↓  ↓  ↓
分配：    T, H, W, T, H, W, T, H, W ...
```

### 一个有趣的延伸：时间位置编码的"语义化"转向

Qwen-VL2 用视频帧的整数 ID（第1帧、第2帧……）来做时间轴的旋转编码。Qwen-VL3 做了一个反直觉的改动：把时间位置编码，改成直接在视觉 token 前插一段文字 <3.0 seconds>。

为什么这么改？ 整数帧 ID 作为位置编码有两个缺陷，放在一起理解更清晰：

- ❌ 问题一：信息稀疏：文本的 token 位置是连续密集的（1,2,3,4,5...），视频帧的采样却是稀疏的（1,5,10,20,50...）→ 模型对"帧间距离"的感知被稀疏采样严重扭曲

- ❌ 问题二：语义错配：30fps 采样时，帧ID=30 代表"第1秒"，1fps 采样时，帧ID=30 代表"第30秒" → 同样的 ID，在不同采样率下代表完全不同的时刻

而直接使用语义\<xx seconds\>可以同时规避以上两个问题，它不需要再去“换算”巨大的数字，而是像读小说章节标题一样，直接“读懂”了当前视频片段的时间点。
  
## 难题二：动态分辨率如何在保留细节的同时控制 Token 数量？
先理解为什么这是个两难困境。

固定分辨率（比如 224×224）的问题：图片一律缩放到这个尺寸，高清文档里的小字、密集表格里的数字——统统模糊掉了。这是前期多模态模型 OCR 能力弱的根本原因。

但支持高分辨率也不是免费的，越高的分辨率，如果不压缩，就会直接转换成更多的输入token。

所以动态分辨率的核心矛盾是：细节 vs. Token 预算。

![83128e69fabf57fe84ece337c76a09b2_9c68faa7-8e29-4283-8bfb-88af0f1d6582_timestamp=1787271082&nonce=e0569f586ca029bb122331a26b44a5c8&sign=sg2cTNT2QnKJErqiUWARUVlvNeqzrXQWg73106ofvmo=](https://developer.qcloudimg.com/http-save/yehe-6190096/2b5d1053cc23a36a24c9f901c1bb738d.jpg)

### Tiling（切片拼图）—— 不动 ViT，绕道走
首先是滑动分块方案，既然 ViT 只接受固定大小的输入，那就把大图切成多个小块，每块单独送进 ViT。

LLaVA 的 AnyRes 方案在此基础上更进一步：同时送入一张缩小的**全局缩略图**（保留整体布局信息）和**多个局部高清切片**（保留细节信息），将所有编码结果拼接成完整序列。

这个方案的优点是实现简单、不需要修改 ViT；缺点是切割的边界会打断跨区域的语义关系（比如一个表格被切成两半），而且 token 数量随分辨率线性增长，治标不治本。

Gemma 的改进方向是：把 ViT 支持的最大输入分辨率直接扩大（从 336 扩到 896），减少切片次数，从而减少切割引入的碎片化。

### VIR（视觉分辨率路由器）—— 让模型自己决定压缩多少

Tiling 是用同一个压缩率处理所有区域——但实际上，图片里的天空背景和密密麻麻的文字，对信息密度的需求完全不同。

VIR 的核心思想：引入一个"语义感知"的动态压缩路由器，让模型自己判断每个 patch 该用多少 token 来表达。

训练分两步：
1. 训练对压缩不敏感的"底子"

随机对输入图片做 4 倍或 16 倍压缩，训练模型在不同压缩率下输出尽量一致的结果。目的是让模型学会"即使图糊了，我也能猜出大概"——建立对压缩的鲁棒性。

2. 训练路由器本身

冻结 ViT 和语言模型，只微调 VIR 路由器部分。路由器本质上是一个二分类器，对每个 patch 输出 0 或 1：
```
标签的来源: 不需要人工标注！
直接比较 Loss(4倍压缩) vs Loss(16倍压缩)：
  → 如果压缩后损失大（信息损失严重）：标签=0，保留高分辨率
  → 如果压缩后损失小（信息本来就稀疏）：标签=1，可以大幅压缩
```

训练用 OCR、VQA 等对信息密度极敏感的任务——因为只有这类任务，"压不压缩、压多少"的影响才显而易见。

推理时，路由器对每个 patch 实时决策，密集信息区域精细保留，大片背景区域大幅压缩，实现了真正的"按需分配"。

### Native VIT(原生动态分辨率) —— 从根上改 ViT
前两个方案都是在不动 ViT 内核的前提下绕道解决。Qwen-VL2 选择直接"动手术"：

- 引入二维相对位置编码（M-RoPE 的 H/W 维度），让 ViT 从输入端就能处理任意尺寸的图片，patch 数量随图片实际尺寸动态变化。
- 引入 2×2 的 MLP 池化压缩，把 4 个相邻 patch 的特征合并成 1 个，将视觉 token 数量压缩到原来的 1/4，有效控制长图的 token 爆炸。

>💡 个人思考：Qwen-VL2 的动态分辨率（解决了"怎么灵活输入"）+ VIR 的信息密度感知（解决了"输进来之后怎么高效表达"），两者其实并不矛盾。如果进一步结合，或许可以走向**预算驱动的自适应表示——给每张图设定一个 token 上限，根据内容的信息密度，动态决定哪些区域精细表达、哪些区域粗略压缩**。这或许是动态分辨率的下一站。


## 难题三：多模态该如何训练？

架构解决了"图片怎么进来"的问题，训练策略解决的是"图片进来之后，怎么让模型真正学会用它"。

这里有两个反直觉的核心发现，都来自 Kimi-K2.5 的实验。

### Insight 1：视觉和语言，越早在一起越好

**先理解"模态竞争"是什么感觉。**

想象你已经是一个母语中文、英语流利的人。这时候有人要求你从零学日语，并且要求你的中文和英语能力不能下降。你会发现，在大脑里，三种语言会互相"抢地盘"，很难真正平衡。

这正是 Era1/Era2 多模态模型的训练困境：LLM 已经用纯文本训练得很好了，这时候再"注入"视觉模态，就会产生模态竞争：
- 样本中视觉占比过高 → 文本能力断崖下跌
- 样本中视觉占比过低 → 模型学会"偷懒"，能不看图就不看图

之前大家的解决方案多是通过多阶段训练，以及动态调整两种模态的混合比例，来拉偏架，本质是水多了加面，面多了加水。

![73706448f1d4080a01f42203d371765c_b2e212bb-8d1c-4b96-ad4c-0937012fcd8c_timestamp=1787271440&nonce=ad78cb1bc37f2c2f6bd4c7a6a3f41c92&sign=fWItKLXEiD75FX0onjWeNae3Upmr3YOPlEJaeAIcYOA=](https://developer.qcloudimg.com/http-save/yehe-6190096/ca421f46827ce9099ca3ce4f6bce7dc3.jpg)

而Kimi-k2.5试验后给出的结论是**在固定 token 预算下，早期融合适度视觉比例的效果，优于晚期大量注入视觉数据。**，所以kimi-k2.5采用的是，早期整合视觉，全程协同优化两种模态以学习均衡的多模态表示。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/75141f4327f2d82b7f0f7c4a52692493.png)

视觉和文本两种模态如果在训练早期就一起“长大”，它们之间的对齐是自然形成的，就像双语环境中长大的孩子，两种语言在大脑中共生。而“先学文本、后补视觉”就像成年人学第二语言——再怎么努力，也很难达到母语级别的融合，而且学第二语言时还会干扰母语（语言退化）

### Insight2：文本和视觉，不再是"零和游戏"

更惊喜的是，Kimi-K2.5 发现了两个跨模态正向迁移的现象：

**现象一：纯文本 SFT，能激活视觉推理能力** 

当前高质量的多模态工具调用数据极度稀缺，但高质量的纯文本 Agentic 数据（推理、规划、工具使用）非常丰富。由于模型的视觉和文本已经在预训练中深度融合，在文本上练出来的推理和规划能力，会自然迁移到视觉任务上。先练文本，反而让视觉 Agentic 能力的激活效果更好。

**现象二：视觉 RL，反过来提升文本长文本推理能力**

研究者的解释是：Visual Grounding这类任务，在结构上类似于文本中的"结构化信息抽取"——都需要在大量信息中精准定位目标，只是输入的信息分布不同。因此，视觉 RL 训练实际上在强化同一种底层能力，并通过多样化的输入分布提升了模型的泛化性。

### Kimi-K2.5 完整训练流程
因为感觉还要再等等多模态重头融合训练的方案，这里不展开说了直接看图吧。

![cb4e886d33c5311258eaadd528c0bd53_9d287aeb-f8fc-44d4-924d-24031211bd2f_timestamp=1787275078&nonce=ea45f2a90841f9dddd249b8a35582826&sign=8VbBEOiLV3y0htj1dgC80yvFqCBxzC6PQ5DgRAOVZBA=](https://developer.qcloudimg.com/http-save/yehe-6190096/322c547a4b9b3a650aef0192476fb947.jpg)


最近被多模态的效果圈粉，感觉距离那个"OCR 糊成一团、指令理解弱到离谱、幻觉高到吓人"的时代也没过去多久，但多模态模型的效果已经发生了飞跃式的进步。

解密Prompt系列72. 多模态大模型进化史：从"翻译官"到"原生双语大脑"

这一章我们从多模态模型的架构演进，动态分辨率输入、多模态位置编码和训练策略等三大技术难题入手，聊聊多模态能力飞跃背后的技术演变。

人工智能

多模态模型从2022年的“翻译官”架构演进至2026年的全统一架构，核心突破集中在三大技术：M-RoPE位置编码实现三维空间感知、动态分辨率与VIR路由器平衡细节与Token预算、以及“早融合”训练策略消除模态竞争。跨模态正向迁移进一步激活视觉推理，推动OCR、文档理解等能力实现飞跃式提升。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

解密Prompt系列72. 多模态大模型进化史：从"翻译官"到"原生双语大脑"-腾讯云开发者社区-腾讯云

解密Prompt系列72. 多模态大模型进化史：从"翻译官"到"原生双语大脑"

解密Prompt系列72. 多模态大模型进化史：从"翻译官"到"原生双语大脑"

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐