视觉语言模型技术指南：LLaVA、Qwen-VL、MiniCPM-V 等主流方案差别在哪？

上一篇我们把"图像到底是怎么接进语言模型"的底层链路拆开了。

现在可以往前走一步，进入很多人真正关心的问题：

同样都是 VLM，为什么 LLaVA、Qwen-VL、MiniCPM-V、InternVL 这些模型，实际体验会差这么多？

有些模型更像"给 LLM 加了看图能力"，适合通用图文问答。

有些模型明显更擅长：

文档理解
OCR 文字读取
多图比较
高分辨率图像输入
移动端或边缘端部署

还有些模型在 benchmark 上很强，但一上线就暴露出：

显存压力太大
输入分辨率限制很死
图文 token 太多
OCR 稳定性一般
多图场景延迟偏高

这背后并不只是"参数规模不同"。

更关键的是，它们在四个地方做了不同取舍：

视觉前端怎么选：CLIP、SigLIP、InternViT 还是自研视觉 backbone
视觉信息怎么接到 LLM 上：MLP projector、cross-attention，还是更复杂的连接结构
输入策略怎么做：固定分辨率、动态分辨率、切图、tile、多图组织
训练目标和数据分布偏向哪里：偏通用对话、偏 OCR 文档、偏高分辨率理解，还是偏轻量部署

这篇文章我想做的，不是罗列一堆模型名字，而是从工程视角讲清楚：

主流 VLM 路线到底在设计上差在哪，这些差异最后又怎样影响精度、吞吐、延迟、显存和落地可用性。

如果你正在选型，或者准备自己搭建图文系统，这篇比单纯看排行榜更有用。

一、先给结论：主流 VLM 的差别，核心不在"会不会看图"，而在"怎么看、看多少、看完后怎么交给 LLM"

很多入门讨论容易把 VLM 模型看成同一种东西。

仿佛区别只是：

底模大小不同
参数量不同
benchmark 分数不同

但如果从系统结构看，更关键的问题其实是这三个：

图像先被编码成什么样的视觉表示
这些视觉表示以什么形式进入语言模型
模型是否被训练去处理高分辨率、多图、文档和 OCR 这类复杂任务

这三件事会直接决定最终体验。

比如两个模型参数量接近，但如果一个：

只支持中等分辨率单图
用简单 MLP projector 接入
训练数据以 caption 和通用 QA 为主

另一个：

支持动态高分辨率输入
针对文档和 OCR 做了专门数据增强
输入组织和视觉 token 压缩更激进

那它们在真实业务里的表现，可能完全不是一个物种。

所以看主流 VLM，不要只问：

"哪个模型更强？"

而要问：

"它到底优化了哪类视觉任务，以及为此付出了什么代价？"

二、先立一个分析框架：比较 VLM，我最建议看这五层

如果你以后要持续比较多模态模型，我建议固定看五层。

1）视觉编码器层

关注点包括：

用的是什么视觉 backbone
patch size 多大
原生支持的输入分辨率多高
是否偏向通用语义，还是偏向文档/OCR 细节

这是模型"看图的底座"。

2）模态桥接层

关注点包括：

是简单线性映射还是多层 MLP
是否用了 cross-attention
是否存在 query-based 压缩结构
视觉 token 是否会被重新采样或压缩

这决定视觉信息能不能高效、稳定地传给 LLM。

3）语言主干层

关注点包括：

用的是哪类 LLM 底模
上下文窗口多大
是否对工具调用、长上下文、多轮对话友好

视觉能力再强，如果语言主干弱，多轮问答和复杂推理仍然会拉胯。

4）输入组织层

关注点包括：

单图还是多图能力强
是否支持高分辨率切块
图像 token 会不会爆炸
文本和图像的拼接顺序如何组织

这直接决定部署时的吞吐和显存成本。

5）训练与任务偏置层

关注点包括：

数据是偏 caption、偏 VQA，还是偏 OCR / 文档 / chart
是否有多轮多模态指令数据
是否做过专项强化，比如表格、GUI、数学图像

这一层往往最容易被忽略，但实际最决定"模型适不适合你的业务"。

三、LLaVA 路线：为什么它成了很多人理解 VLM 的起点？

如果说哪条路线最适合入门理解 VLM，基本就是 LLaVA。

因为它的设计非常典型，也非常工程化：

用已经训练好的 vision encoder
用一个相对简单的 projector 接到 LLM 上
再做多模态指令微调

这条路线的价值在于：

它把"多模态能力接到现成 LLM 上"这件事，做到了足够清晰、足够实用。

1）LLaVA 的核心思路：尽量少改结构，快速把视觉能力接进文本大模型

LLaVA 的典型做法可以概括成三步：

用 CLIP 类视觉编码器把图像变成视觉特征
用 MLP projector 把视觉特征映射到 LLM hidden size
把这些视觉 token 和文本 prompt 一起送入语言模型

它的优点非常明确：

结构简单
容易复现
训练成本相对可控
非常适合做开源社区扩展

这也是为什么 LLaVA 系模型生态特别活跃。

2）LLaVA 路线的优势：搭建门槛低，通用图文问答性价比高

如果你的目标是：

先做一个能工作的图文对话系统
单图问答为主
不追求极端 OCR 和文档精度
希望训练和推理链路尽可能简单

那 LLaVA 路线很合适。

它通常在这些场景里够用：

通用看图问答
场景描述
简单图文推理
基础教育演示
多模态聊天原型

3）LLaVA 路线的短板：高分辨率、文档细节和复杂多图任务往往不是强项

它的问题也很明显。

由于很多 LLaVA 风格模型：

视觉输入分辨率比较保守
连接方式偏轻量
训练偏通用对话

所以一旦任务变成：

小字 OCR
高分辨率海报解析
多页文档理解
多图细节比较
GUI 元素定位

性能就常常开始掉。

这不是说 LLaVA 不行，而是它的设计目标本来就更偏：

以尽量低的结构复杂度，换取够强的通用多模态能力。

4）部署视角怎么看 LLaVA 路线

从部署角度，LLaVA 路线的优点是：

pipeline 清晰
工程栈成熟
社区支持广
容易接 vLLM、SGLang、Transformers 等推理框架

但你要注意几个参数：

图像分辨率上限
每张图映射出的视觉 token 数
projector 的额外显存占用
多图场景下的 prefill 成本

如果你要做低成本原型或者 API 级图文聊天，LLaVA 路线很值得优先考虑。

四、Qwen-VL 路线：为什么它在中文、多模态对话和复杂任务适配上更受关注？

Qwen-VL 这条线之所以讨论度很高，一个重要原因是它不是单纯追求"能看图"，而是更强调：

图文对话体验
中文场景可用性
复杂任务覆盖
系统级多模态扩展能力

1）Qwen-VL 的吸引力，不只是视觉，而是"语言底座 + 多模态能力"的整体平衡

很多时候，真实使用感不是由视觉前端单独决定的。

用户最终感受到的是：

看图是否准确
追问是否自然
中文解释是否顺
多轮交互是否稳
推理过程是否连贯

Qwen 系列本身在语言能力上就比较强，所以一旦多模态接得稳，整体体验常常会比"视觉还行但语言主干一般"的模型更完整。

2）Qwen-VL 类路线通常更重视多任务覆盖，而不只是一张图的 caption

在很多实际测评里，Qwen-VL 系模型更常被拿去测：

OCR
图表理解
文档问答
中文图片内容解析
多轮多模态对话

这说明它的设计目标，本身就更偏向"实用型通用多模态助手"。

3）Qwen-VL 的工程含义：更容易作为通用产品底座，但也更考验推理资源管理

如果你用 Qwen-VL 这类模型做线上服务，通常需要重点关注：

高分辨率输入时的显存曲线
OCR/文档类图片导致的 token 增长
多轮历史叠加后的上下文长度
图像与文本交替输入时的吞吐衰减

换句话说，它常常更"全能"，但也更容易在生产里把资源吃满。

4）Qwen-VL 更适合哪些场景？

如果你的业务更偏：

中文图文问答
文档和截图理解
需要较强的语言解释能力
希望模型兼顾聊天、OCR 和推理

那它通常比纯 LLaVA 风格路线更有吸引力。

但前提是你愿意接受更复杂的部署优化。

五、MiniCPM-V 路线：为什么它经常出现在"轻量但 surprisingly strong"的讨论里？

MiniCPM-V 很有代表性，因为它体现了一类非常现实的工程目标：

不是一味做大，而是在有限参数和有限资源下，把多模态能力做到尽可能高。

1）MiniCPM-V 的核心价值：更强调效率、紧凑性和端侧友好性

很多团队并不需要一个超大多模态底模。

他们更关心的是：

单卡能不能跑
移动端或边缘设备有没有可能部署
延迟能不能接受
小模型下 OCR 和图文问答还能不能打

MiniCPM-V 之所以受关注，就是因为它在这类约束下，往往能给出不错的结果。

2）轻量模型为什么还能有竞争力？

因为多模态系统的表现，并不只由参数量决定。

如果一个模型在这些地方优化得更好：

视觉 token 压缩更有效
输入分辨率策略更聪明
训练数据分布更贴近目标任务
指令数据质量更高

那它完全可能用更少参数，换来更好的单位成本表现。

3）MiniCPM-V 的典型适用场景

它更适合：

资源受限部署
本地或端侧推理
中小规模图文服务
对每次推理成本很敏感的产品

当然，代价也存在。

在极复杂场景下，比如：

超长文档
大量多图联合推理
高难度跨区域关系理解

轻量路线通常还是会遇到能力上限。

4）部署上该怎么看 MiniCPM-V

如果你重视的是"单位 GPU 预算下尽可能高的可用性"，MiniCPM-V 这条线很值得研究。

你需要重点观察：

在 4bit / 8bit 量化后表现掉不掉
OCR 精度与吞吐的平衡点在哪
在单图、双图、多图场景中的时延变化
在小 batch 和高并发下的稳定性

它不一定是"绝对最强"的路线，但很可能是"最划算"的路线之一。

六、InternVL 一类路线：为什么它们常和高分辨率、多图、文档能力绑在一起？

除了 LLaVA、Qwen-VL、MiniCPM-V，另一个非常值得单独看的方向是 InternVL 这一类更强调视觉能力上限的路线。

这类模型常被讨论的关键词是：

高分辨率理解
多图能力
文档与 OCR
更强视觉 backbone
更复杂输入组织

1）这类路线的核心目标：别太早丢掉视觉细节

很多简单多模态系统的问题在于：

图片一 resize，细节就没了
patch 一粗化，文字就糊了
视觉 token 一压缩，小目标和局部结构就被吞掉了

所以更强调高分辨率和文档能力的路线，会想办法保留更多细节。

典型做法包括：

动态分辨率输入
多 tile 组织
更强视觉编码器
对 OCR / 文档 / chart 做专项训练

2）这类路线的优势：细节任务更稳

如果你测试的是这些任务：

页面级文档问答
小字识别
长图解析
表格与图表读取
多图拼接理解

这类模型通常会比简单单图低分辨率路线更稳。

3）代价也很直接：token、显存、延迟都会更重

这是所有高分辨率路线绕不开的现实。

因为只要你保留更多视觉细节，就几乎一定会带来：

更多视觉 token
更重的 prefill
更高的显存占用
更差的多并发能力

所以这类模型通常更适合：

高价值任务
对精度要求高的企业场景
愿意为图像理解质量支付更多算力成本的系统

而不一定适合那种低价高并发的轻聊天服务。

七、为什么有的模型擅长通用对话，有的模型擅长文档/OCR？

这个问题很关键。

很多人容易误以为：

文档、OCR、图表理解，只是"看图能力更强一点"的结果。

其实不是。

它们在训练和结构上往往就是不同任务。

1）通用对话更依赖语言主干和多模态指令跟随能力

如果任务主要是：

图像描述
开放问答
聊天式交互
多轮追问

那么语言主干质量和多模态指令数据会非常关键。

这类场景里，语言表达自然、逻辑清晰、追问稳定，往往比 OCR 每个字都准更重要。

2）OCR / 文档更依赖高分辨率视觉输入和专项训练

如果任务变成：

识别小字号文字
读取票据、合同、课件
理解表格和复杂排版
对截图中的按钮、字段、位置做判断

那决定结果的关键就变成：

视觉细节是否保住
是否做了 OCR / DocVQA / ChartQA 类训练
是否支持更适合文档的分辨率与输入组织

3）所以"谁更强"本来就是任务相关问题

如果你做的是商品图问答，也许 LLaVA 风格模型已经够用。

如果你做的是中文发票、PPT、论文截图和表格问答，那很多时候更该优先看 Qwen-VL、InternVL 这类更偏复杂图文任务的路线。

如果你做的是端侧助手，那 MiniCPM-V 可能比"大而全"的路线更合适。

这也是为什么多模态选型不能只看一个总榜。

八、从参数视角看：这些模型到底该重点盯哪些配置？

如果你准备部署或微调主流 VLM，我建议重点关注以下参数。

1）图像分辨率

这是最直接影响视觉细节和成本的参数。

你要看：

默认输入分辨率是多少
是否支持动态分辨率
是否支持多 tile
分辨率上升后 token 增长是否线性可控

2）视觉 token 数量

很多论文不会把它讲得特别直白，但工程上必须算。

因为它直接影响：

prefill 时延
显存占用
多图能力
上下文窗口压力

3）projector / connector 规模

这会影响：

视觉信息传输能力
模态对齐质量
微调难度
训练稳定性

如果 connector 太弱，模型容易"看得到大概，看不准细节"。

4）上下文长度

多模态系统的上下文，常常不只是文本窗口。

你要把这些一起算进去：

图像 token
OCR 生成的中间文本
用户历史轮次
模型输出长度

很多线上事故，本质上都是上下文预算没算清楚。

5）量化位宽与推理框架兼容性

比如：

FP16
BF16
INT8
4bit AWQ / GPTQ / GGUF

你要看量化后：

OCR 是否明显掉点
图像细节理解是否恶化
推理框架是否支持视觉模块
KV cache 和多模态前处理是否兼容

VLM 的量化通常比纯文本 LLM 更敏感。

因为视觉误差一旦放大，很容易直接影响最终回答。

九、如果让我按场景给建议，我会怎么选？

这里我给一个工程化的粗分法。

1）如果你要做低门槛通用图文聊天原型

优先看：

LLaVA 路线
社区成熟的轻量多模态模型

原因是：

好接
资料多
推理栈成熟
足够做 demo 和原型

2）如果你要做中文图文助手、截图问答、文档解析

优先看：

Qwen-VL 系
InternVL 一类更偏复杂视觉任务的模型

原因是：

语言和多模态整体平衡更好
对中文和复杂任务通常更友好
更适合真实产品交互

3）如果你要做资源受限部署

优先看：

MiniCPM-V 这类轻量高效路线

原因是：

单位成本更优
更适合本地/边缘部署
更容易在有限 GPU 或端侧资源下落地

4）如果你要做高精度文档、OCR、多图高分辨率任务

优先看：

更强调高分辨率输入和文档能力的路线
能处理 tile / dynamic resolution 的模型

原因是：

这类任务本质上吃视觉细节
简单单图低分辨率模型很容易不稳

换句话说，选型不要问"社区最火的是谁"。

而要问：

你的输入长什么样、任务长什么样、预算长什么样。

十、部署落地时，主流 VLM 最常见的几个坑

1）只看 benchmark，不看真实输入分布

很多模型在公开 benchmark 上很强，但你的业务图片可能是：

手机截图
长网页
Excel 导出图
模糊拍照
带水印压缩图

这时公开分数未必能代表真实效果。

2）只看参数量，不看视觉 token 成本

有时候小模型配高分辨率多图输入，实际成本并不比中模型低。

因为视觉 token 才是吞吐杀手之一。

3）忽略图像预处理的一致性

比如：

resize 方式不同
长宽比拉伸
tile 顺序不一致
图像归一化处理不统一

这些都可能让线上效果波动非常大。

4）把纯文本推理经验直接套到多模态上

纯文本 LLM 里常用的一些优化思路，到了 VLM 上未必直接适用。

因为你还要额外考虑：

视觉前处理耗时
图像 token 注入方式
多模态 cache 行为
量化对视觉模块的影响

所以 VLM 部署一定要单独做 profiling。

十一、最后总结

主流 VLM 模型之间的差别，表面上看是"名字不同、底模不同、参数不同"。

但从工程视角看，真正决定体验的，是下面这几组取舍：

视觉 backbone 强不强
图像分辨率和视觉 token 预算怎么控制
模态桥接模块是轻量优先还是表达优先
训练数据偏通用对话，还是偏 OCR / 文档 / 高分辨率任务
部署目标是大模型服务，还是轻量端侧落地

如果用一句话概括：

LLaVA 更像"结构清晰、工程友好的通用接法"，Qwen-VL 更像"语言与多模态整体平衡更强的通用助手路线"，MiniCPM-V 更像"资源受限条件下追求单位成本效率的路线"，而 InternVL 一类则更偏"把视觉细节和复杂图文任务能力往上顶"。

所以别再笼统地问"谁最强"。

更应该问：

你的任务是通用图文聊天，还是文档/OCR？
你的部署预算是单卡、本地，还是多卡服务？
你最怕的是延迟、显存，还是精度不稳？

这些问题想清楚，模型选型会容易很多。

彻底展开。