视觉语言模型技术指南：多图输入、高分辨率理解和长图文场景怎么做？

前一篇我们把主流 VLM 的架构分化讲清楚了。

如果说 LLaVA、Qwen-VL、MiniCPM-V、InternVL 这些模型的差别，决定了它们"适合做什么"，那接下来真正会在业务里把系统拉开差距的，往往不是单张普通图片问答，而是下面这些更难的输入：

多张图片联合理解
超高分辨率图像理解
长截图、长海报、长文档页
表格、票据、论文页面、产品说明书
需要跨图对比、跨区域定位、跨页面总结的任务

很多团队在做 Demo 的时候，拿一张 448×448 的普通图片测试，效果看起来还不错。

但一进入真实场景，问题马上就会暴露：

图片一多，视觉 token 数量迅速膨胀
分辨率一高，显存和延迟明显失控
OCR 细节一密，模型开始漏字、串行、看错局部
需要跨图比较时，模型会把不同图片的信息混在一起
长图切块不合理时，模型明明"看过"，却答不出全局关系

所以这篇文章重点不是泛泛而谈"模型支持多图"。

我更想从工程视角把三件事讲透：

为什么多图和高分辨率会让 VLM 变得昂贵
主流模型到底用哪些办法控制视觉 token 爆炸
真实部署里，多图、长图、高分辨率任务应该怎么设计输入链路和参数

如果你正在做文档理解、GUI Agent、图表分析、巡检识别、票据审核或者多页资料问答，这篇会比只看 benchmark 更实用。

一、先说结论：多图和高分辨率不是"多喂一点图"这么简单，而是在和上下文、显存、延迟抢预算

很多人会把多模态输入想成一句很自然的话：

既然模型能看一张图，那就应该也能看很多张图。

方向没错，但代价远比想象中大。

因为对大多数 VLM 来说，图片最终都会被编码成视觉 token，再和文本 token 一起送进语言模型主干。

这意味着只要图片数量上去、分辨率上去，系统成本就会同步上涨。

成本主要体现在四个地方：

1）视觉 token 数量暴涨

假设视觉编码器使用 ViT 路线，patch size 为 14，那么输入分辨率越高，切出来的 patch 就越多。

一个粗略直觉是：

448×448 比 224×224 的 patch 数量大约多 4 倍
896×896 再往上时，视觉 token 数量会继续平方级增长
如果还是多图输入，成本会继续线性叠加

所以高分辨率和多图叠加，是最容易把推理成本顶爆的组合。

2）LLM 上下文预算被视觉输入吃掉

文本模型不是无限上下文。

即便主干支持长上下文，视觉 token 进入后，仍然会和文本指令、历史对话、检索上下文一起竞争窗口。

结果就是：

图太多时，能留给文本推理的空间变少
多轮对话时，旧图信息可能被截断
RAG + 多图混合场景里，容易出现"图塞进去了，但文字资料塞不下"

3）prefill 延迟明显上升

很多人只盯着 decode 速度，但多模态场景里，prefill 往往更痛。

因为大量视觉 token 会在输入阶段一次性灌入模型，直接拉高首字时间（TTFT）。

典型现象是：

单张图问答还算流畅
多图比较时首响应变慢
文档页数一多，系统像"卡住"了一样

4）图像之间的关系并不会自动学得很好

即便模型支持多图输入，也不代表它天然擅长：

图 1 和图 2 的差异对比
多页文档中的跨页引用
长截图中前后区域的逻辑串联
多张图里相同对象的跟踪与比对

也就是说，多图不是只有算力问题，还有建模与训练问题。

二、为什么高分辨率任务这么难？难点不只是"图更清楚"，而是细节信息和全局信息很难同时保住

高分辨率输入的核心矛盾，可以概括成一句话：

你既想看清局部小字，又想保留整张图的全局结构。

这两件事经常互相打架。

比如在文档理解里：

你需要看清页眉页脚、表格单元格、脚注、公式、小字体
同时还要理解整页版式、段落层级、图表与正文对应关系

如果把整张图直接缩到低分辨率：

全局结构保住了
但局部文字、图例、细小控件会丢失

如果把图切成很多高分辨率局部块：

局部细节保住了
但全局布局关系容易丢

所以高分辨率理解本质上是在做一个平衡：

全局视野：知道整张图在讲什么
局部细节：看得清小字、小图标、小区域
计算成本：不能把 token 和显存无限拉高

这也是为什么很多主流 VLM 会引入动态分辨率、切图、tiling、多尺度编码等策略。

三、主流方案怎么解决：固定分辨率、切图、动态分辨率、多尺度，是四条最常见路线

1）固定分辨率：实现简单，但上限明显

最直接的方法，就是所有图片统一 resize 到固定尺寸，例如 224、336、448、672 之类。

优点很明显：

输入形态稳定
部署简单
显存和吞吐更好预估
适合通用图文问答和普通场景

但问题也很明显：

细小文字和密集表格容易糊掉
长图、海报、流程图常被压坏
文档类任务天花板较低

所以固定分辨率更适合：

通用视觉问答
商品图、自然图像理解
对 OCR 精度要求不高的轻任务

2）切图 / tiling：保细节最直接，但 token 容易爆

另一种做法是把高分辨率图像切成多个 tile，再分别编码。

这样做的好处是：

每个 tile 内细节更清楚
对 OCR、文档、图表、GUI 任务更友好
不必把整图极限压缩到模糊

但代价也很直接：

tile 数量越多，视觉 token 越多
跨 tile 关系更难学
推理延迟显著上升

因此切图不能无脑开。

真正工程上要配套做的是：

tile 数量上限控制
重叠区域控制
tile 排序规则统一
局部 tile 与全局缩略图联合输入

3）动态分辨率：按内容复杂度分配预算

近两年的很多强势多模态模型，都会引入动态分辨率思想。

核心逻辑不是所有图一刀切，而是根据图像内容、长宽比、版式复杂度来决定：

用多少 tile
每个 tile 分辨率多高
是否保留全局图
总视觉 token 上限是多少

这种做法比固定分辨率更灵活，通常也更适合真实业务。

因为现实世界里的图像复杂度差异很大：

一张自然图不需要文档级精细处理
一页发票和一页论文版面复杂度也不一样
一张长截图如果只是聊天记录，和一张仪表盘截图的处理策略也应该不同

4）多尺度编码：同时看全局和局部

还有一条常见思路，是把同一张图的不同尺度一起送入系统。

比如：

一张低分辨率全局图负责布局感知
若干高分辨率局部块负责细节识别

这样能缓解"只看局部就失去全局、只看全局又看不清细节"的问题。

它特别适合：

文档理解
表格与图表分析
GUI 截图理解
地图、海报、长流程图

但这类方法同样要求更强的输入组织和训练数据支持，否则模型容易出现：

知道局部内容，却不会汇总全局
能描述版面，却对具体细节识别不稳

四、多图输入到底该怎么组织？顺序、分组、标识符，比"能不能传多张图"更重要

多图任务最常见的误区，是把几张图直接拼进去，然后问一句：

"帮我比较一下这几张图。"

这样有时能成，但稳定性通常不够。

因为模型不一定知道：

哪张是图 1，哪张是图 2
用户到底要比较什么维度
哪些图是同一对象的不同时间状态
哪些图是同一文档的不同页面

所以多图输入必须做结构化组织。

1）给每张图显式编号

最基础也最有效的做法，就是显式写清楚：

Image A：会前版本
Image B：会后版本
Page 1：目录页
Page 2：正文页
Screenshot 1：登录前
Screenshot 2：登录后

这样可以显著减少模型混图。

2）把任务目标写成可对齐的比较维度

不要只说"比较一下"。

应该尽量拆成：

比较布局差异
比较数值变化
找出新增按钮
对比两页文档结论是否一致
总结三张图里共同出现的问题

模型在多图场景里最怕任务目标模糊。

3）把多图分成"全局组"和"局部组"

对于复杂任务，建议不要一次性把所有图平铺成一个列表。

更好的方式通常是：

先给全局图/整页图
再给关键局部图/放大图
最后在提示词中说明对应关系

这样比单纯"堆图"更稳。

4）控制单次请求中的图片数量

即便模型号称支持很多张图，工程上也不建议一次塞太多。

经验上更稳的做法是：

先做一级筛选
选出候选图
再做二级精读

这和 RAG 很像，本质上也是分层处理，而不是把所有输入一次压进主干。

五、关键参数怎么理解：image resolution、patch size、tile 数、max image tokens 这几个最值得盯

如果你要调多模态系统，我建议重点盯下面几个参数。

1）image resolution

它决定输入图像在进入视觉编码器前会被处理到什么尺寸。

分辨率越高：

局部细节越容易保留
OCR 和小目标识别通常更稳
但计算成本、显存、延迟都更高

实战建议：

通用问答可以先从中等分辨率起步
文档/OCR/GUI 任务再逐步提高
不要默认所有场景都开最高分辨率

2）patch size

patch size 越小，同样分辨率下切出的 patch 越多，细节表达更细，但 token 成本更高。

从工程角度看，它和输入分辨率是乘法关系，而不是独立关系。

所以不能只看"模型支持高分辨率"，还要看视觉编码器的 patch 划分粒度。

3）tile count / dynamic tiles

这是高分辨率任务里最容易失控的参数之一。

tile 越多：

模型越容易看清局部
但延迟、显存、吞吐都会明显恶化

实战上最好给 tile 设置硬上限，并针对不同任务设模板：

普通图片：低 tile 或单图模式
文档页：中等 tile
超长图或复杂图表：高 tile，但要配合限流

4）max image tokens / visual token budget

很多系统最终卡住，不是因为模型"看不懂"，而是因为视觉 token 预算设计失控。

建议把它当成一级系统参数，而不是隐藏细节。

因为它直接影响：

是否能保留足够文本上下文
请求的首字时间
GPU 显存峰值
并发能力

六、部署实战：多图和高分辨率任务，别直接追单模型能力，先把服务链路拆层

从落地经验看，多图/长图/高分辨率任务最稳的方案，往往不是"找一个最强模型一把梭"，而是把链路拆层。

1）先分类，再精读

例如先用轻量策略判断输入属于哪类：

自然图
文档页
表格页
长截图
多图对比任务

然后再决定是否启用高分辨率、多 tile 或多图模式。

这样能节省很多不必要的算力开销。

2）先粗看，再细看

对长图或多页文档，建议分两阶段：

第一阶段：低成本全局扫描，找重点区域
第二阶段：高分辨率局部精读

这比全量高精度处理更接近真实生产需求。

3）图文混合任务里，给文本留预算

很多系统一遇到文档，就把所有页面图片都灌进模型，结果文字说明、规则、检索片段反而塞不进去。

更合理的做法是：

让图像负责版式和视觉证据
让 OCR / 结构化抽取负责高密度文本
让 LLM 负责综合推理和生成

不要让一个模型单独背所有环节。

4）把 OCR 和 VLM 视为互补，而不是替代

在很多文档场景里，我更建议把 VLM 和 OCR 组合使用。

原因很简单：

OCR 擅长高精度文本转写
VLM 擅长图文联合理解、布局推理、跨区域关系解释

如果只用 VLM 硬吃所有文字密集文档，成本高且稳定性未必最好。

比较稳的链路通常是：

OCR 提取文本
版面分析抽取区域结构
VLM 处理难以规则化的图文关系
LLM 汇总生成最终答案

七、最常见的坑：系统不是死在模型不够强，而是死在输入策略不合理

这里总结几个我觉得最常见的坑。

1）所有图片都按最高规格处理

后果就是：

GPU 显存长期高压
并发能力极差
首响应时间难看
成本失控

正确做法是分级输入，不同任务走不同预算模板。

2）长图只切局部，不保留全局图

这样模型可能认得每一块，但不知道整张图的结构关系。

3）只保留全局图，不给局部放大

这样模型知道图在讲什么，但 OCR、小图标、细表格会频繁出错。

4）多图没有编号和任务约束

结果常常是：

回答把图混在一起
比较维度跑偏
跨图引用不稳定

5）把多模态模型当万能 OCR 引擎

VLM 很强，但不是所有高密度文字任务都该直接硬上。

当任务目标是高准确率字段抽取时，传统 OCR + 规则/结构化方法常常更稳、更便宜。

八、怎么选方案：按任务类型决定多图与高分辨率策略，而不是反过来

如果你正在做选型，我建议用下面这个思路。

1）通用图文问答

优先目标：

低延迟
中等成本
足够稳定

建议：

固定分辨率
单图或少量多图
控制视觉 token 预算

2）文档理解 / OCR 增强

优先目标：

保细节
看版面
能跨区域理解

建议：

动态分辨率
全局图 + 局部 tile
OCR 与 VLM 组合

3）多图比较 / 巡检 / GUI Agent

优先目标：

跨图一致性
时序或状态差异识别
明确定位变化点

建议：

图片编号
固定比较维度
分阶段筛选与精读

4）长截图 / 长文档 / 多页报告

优先目标：

保留上下文关系
控制 token 爆炸
提升跨页总结能力

建议：

分页或分段处理
先粗读后精读
不要把所有页面一次塞满上下文

九、最后总结：多图和高分辨率能力，决定的是 VLM 能不能真的进入生产场景

单张普通图片问答，今天已经不是多模态系统最有区分度的能力了。

真正能决定一个 VLM 是否值得落地的，越来越是这些更工程化的问题：

多图输入能不能稳定比较
高分辨率下能不能看清细节又不拖垮成本
长图和文档页能不能同时兼顾全局与局部
视觉 token 预算能不能和文本上下文、延迟、并发一起平衡

所以看一个多模态系统，不要只看它"能不能看图"。

更要看它在复杂输入条件下，是否有一套明确的输入组织、token 预算和服务分层策略。

一句话总结：

多图、高分辨率、长图文场景的本质，不是让模型"看更多"，而是让系统在有限预算下，把真正重要的视觉信息送进去。

下一篇，我们继续往前走，进入很多团队真正会遇到的训练问题：

多模态微调到底怎么做？图文数据怎么配比？vision lr、llm lr、冻结策略这些关键参数该怎么定？