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

作者:风雨中的小七日期:2026/8/28

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

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

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

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

"图片和文字,到底应该在哪里、用什么方式融合?"

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

Era1. 给语言模型装上眼睛(2022–2023)—— Llava,Qwen-VL1-2

Visual Instruction Tuning(Liu et al., 2023)

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

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

LLaVA 的两阶段训练:

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

Qwen-VL 在此基础上加了第三阶段: 解冻全部参数,用 OCR、Visual Grounding(让模型指出图片中特定区域的位置)等任务,专门强化模型的细粒度感知能力。这是从"看到是什么"向"感知空间关系"的第一步迈进。

但 Era1 有三个根本性的缺陷,驱动了后续的演进:

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

Era2. 让大脑“看见”更深层(2024-2025)- Qwen-VL3

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

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

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

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

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

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

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

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

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

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

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

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

说完架构层面的变化,下面我们接着说几个核心问题的攻克

  • 位置编码如何表征空间和时间:把 2D/3D 世界硬压成 1D 序列,长视频尤其受损
  • 如何支持动态分辨率:固定 224/336 一刀切导致 OCR/文档/小目标崩
  • 如何训练解决模态冲突:视觉加入时机与比例不当会拉低语言能力或导致“看不见”

难题一:位置编码如何表征空间和时间?

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

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

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

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

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

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 的修正方案叫交错分配:

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

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

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 预算。

Tiling(切片拼图)—— 不动 ViT,绕道走

首先是滑动分块方案,既然 ViT 只接受固定大小的输入,那就把大图切成多个小块,每块单独送进 ViT。

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

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

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

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

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

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

训练分两步:

  1. 训练对压缩不敏感的"底子"

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

  1. 训练路由器本身

冻结 ViT 和语言模型,只微调 VIR 路由器部分。路由器本质上是一个二分类器,对每个 patch 输出 0 或 1:

1标签的来源: 不需要人工标注!
2直接比较 Loss(4倍压缩) vs Loss(16倍压缩)
3   如果压缩后损失大(信息损失严重):标签=0,保留高分辨率
4   如果压缩后损失小(信息本来就稀疏):标签=1,可以大幅压缩
5

训练用 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 已经用纯文本训练得很好了,这时候再"注入"视觉模态,就会产生模态竞争:

  • 样本中视觉占比过高 → 文本能力断崖下跌
  • 样本中视觉占比过低 → 模型学会"偷懒",能不看图就不看图

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

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

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

Insight2:文本和视觉,不再是"零和游戏"

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

现象一:纯文本 SFT,能激活视觉推理能力

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

现象二:视觉 RL,反过来提升文本长文本推理能力

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

Kimi-K2.5 完整训练流程

因为感觉还要再等等多模态重头融合训练的方案,这里不展开说了直接看图吧。


解密Prompt系列72. 多模态大模型进化史:从"翻译官"到"原生双语大脑"》 是转载文章,点击查看原文


相关推荐


Go 编程实战:Map——使用 Key-Value 管理键值数据
程序员爱钓鱼2026/8/20

上一篇我们学习了 Slice。Slice 非常适合保存一组动态数据,例如: users := []string{"Tom", "Jack", "Lucy"} 但是 Slice 主要通过数字下标访问元素: users[0] users[1] 实际开发中,我们经常希望通过用户名、商品编号、配置名称等直接查找数据。例如: "Tom" -> 90 "Jack" -> 85 "port" -> 8080 "host" -> localhost 这种“一个 Key 对应一个 Value”的数据结构,就


【计算机毕业设计】基于Hadoop的智慧政务大数据可视化平台设计与实现
xiaotianyuanma2026/8/7

1.系统介绍 随着数字化政务建设的持续推进,传统政务服务存在流程繁琐、信息分散、数据处理效率低等问题,难以满足公众便捷办事与政府高效管理的需求。为实现政务服务智能化、数据管理可视化,本文设计并实现了基于 Hadoop 的智慧政务大数据可视化平台,助力政务服务数字化转型。 平台采用 Java 语言开发,基于 SpringBoot+Vue 前后端分离架构,结合 MySQL 数据库与 Hadoop 大数据框架构建。平台分为用户端与管理员端,用户端提供注册登录、政策推荐、服务预约、在线咨询、数据统计


第13篇:《把PDF变成AI能懂的"密码":我用向量数据库建了个知识库》
第一行代码HW2026/7/29

承上:上一篇我们把文档切成了高质量的小碎片,但它们还只是文本。AI不认识文本,只认识数字。今天,我们要把这些文本碎片变成一串串数字——向量,存入向量数据库,让AI真正能"理解"你的私有知识。 1. 先搞懂:什么是Embedding? 1.1. 用后端老鸟的类比 假设你是数据库管理员,要给1000本书建立索引: 传统索引: "Java编程思想" → 按书名倒排 → J字母开头 → 第3排第5本 向量索引: "Java编程思想" → 转成一串数字[0.23, -0.15, 0.78, ...]


Python 函数式编程:从思想到实践
卷无止境2026/7/21

函数式编程(Functional Programming,FP)是一种把"计算"看作数学函数求值的编程范式——它不像面向对象那样关注"对象状态",而是强调用函数来描述数据的变换过程。Python 并非纯函数式语言,但它对这套思想的支持相当完善,掌握它能让你的代码更简洁、更易测试、更少 bug。下面我们一层一层把这件事讲清楚。 🧭 核心思想:函数式编程在想什么? 函数式编程的哲学核心只有一句话:数据流过一系列纯函数,产生结果,过程中不改变任何外部状态。 这和流水线工厂很像——每道工序只做一件


Kotlin Flow 深入解析:`stateIn()` 的真正核心,其实是 SharingStarted
潜龙勿用之化骨龙2026/7/13

很多 Android 开发者使用 stateIn() 时,代码几乎都是以下这种: stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000), initialValue = UiState.Loading ) 这其实已经是标准写法了。 实际上: stateIn 做的事情只有两件: 1、把冷流升级为热流 2、通过 SharingStarted 控制上游生命周期 这里最关


Claude Sonnet 5 上线:别再让 Claude Code 一律烧 Opus
鲁大猿2026/7/5

Claude Sonnet 5 上线:别再让 Claude Code 一律烧 Opus 6 月 30 日,Anthropic 发布 Claude Sonnet 5。 如果你平时用 Claude Code,这条消息不应该只理解成“又来了一个更强模型”。 它真正影响的是一个更具体的团队决策:以后 Claude Code 到底什么时候用 Sonnet,什么时候用 Opus,什么时候必须让人接管? 我的判断很直接: 不要全员默认 Opus。 也不要一听 Sonnet 5 便宜、上下文长,就把所有 Ag


你好,我叫Token——AI世界里最忙的搬砖工
Kfaino2026/6/27

码农的AI翻身之旅(一) 你好,我叫Token——AI世界里最忙的搬砖工 大家好。 我叫 Token。 别看我名字洋气,其实我就是个打零工的。 AI世界里,所有人都认识ChatGPT,认识DeepSeek,认识Claude,认识Gemini…… 可是,没有几个人认识我。 然而,没有我,他们一句话都说不出来。 我的出生 某一天。 一个程序员打开了ChatGPT。 他说: 帮我写一个Spring Boot项目。 于是,我出生了。 准确来说,不是我一个。 而是一大群兄弟。 因为AI眼里,根本没


一篇看懂 VKE AI Profiling:AI 应用性能分析优化实战
火山引擎Agent社区2026/6/18

你有没有遇到过这样的情况: AI 模型在训练时 GPU 利用率忽高忽低,容器资源明明给够了,训练时长却总是超出预期?或者在推理服务上线后,延迟时不时抖动,重启一下又好了,但问题根本找不到? “我的模型在裸机上跑只要 2 小时,放到容器里怎么变成 3 小时了?” “资源都给了,CPU 和内存也没瓶颈,我不知道还要看什么。” 很多团队在模型效果验证通过后,真正进入上线或规模化使用时,往往会遇到一个共同问题:GPU 看起来很忙,但整体效率并不高;系统投入不少,性能瓶颈却不容易快速定位。 这正是 A


架构视图与文档:C4 模型从入门到实战
ltl2026/6/10

你上次打开团队的架构图是什么时候? 大多数团队都有架构图。Confluence 上躺着一张两年前画的系统拓扑图,Visio 文件在某个共享盘里,PowerPoint 里有几页"技术方案评审"的框线图。问题是:没人信它们。新人入职时看一眼,发现和实际系统对不上,从此再也不看。老人心里有一张"真正的架构图",但那张图只存在于他的脑子里。 这不是个别现象。Simon Brown 在 2018 年的调查中发现,超过半数的开发者认为自己团队的架构文档"基本没用"或"严重过时"(Simon Brown, "


Java MyBatis-Flex 实战指南:从 BaseMapper 到 QueryWrapper 的轻量 ORM 用法
唐青枫2026/6/3

简介 MyBatis-Flex 是一个基于 MyBatis 的增强框架。 它的定位很直接: 保留 MyBatis 写 SQL 的灵活性,同时补上通用 CRUD、链式查询、分页、逻辑删除、乐观锁等常用能力。 普通 MyBatis 项目里,常见代码结构是: Entity Mapper 接口 Mapper XML Service Controller 如果只是做一张表的增删改查,也要写不少重复 SQL。 MyBatis-Flex 的思路是: 简单 CRUD 交给 BaseMapper 复杂条件交给

首页编辑器站点地图

本站内容在 CC BY-SA 4.0 协议下发布

Copyright © 2026 聚合阅读