InternVL3_5-4B-MPO动态高分辨率原理解析：dynamic_preprocess图像切片为何选448与12块上限-育师

【免费下载链接】InternVL3_5-4B-MPO

项目地址：https://ai.gitcode.com/OpenGVLab/InternVL3_5-4B-MPO

InternVL3_5-4B-MPO 是 InternVL3.5 系列的 4B 多模态大模型，其核心能力之一是动态高分辨率（Dynamic High Resolution）策略：dynamic_preprocess函数会把任意图片按比例切成若干 448×448 的小图（tile），上限 12 块，让模型"看得清"细节。本文用最直白的方式讲透两个关键参数背后的工程取舍：为什么是 448，为什么最多 12 块。

一、先建立全局：一张图是如何变成 Token 的？

InternVL3_5-4B-MPO 采用经典的ViT → MLP → LLM三段式架构（modeling_internvl_chat.py）：

原始图片 ──> dynamic_preprocess 切片 ──> N 个 448×448 tile ──> 每个 tile 过 InternViT ──> 1024 个 patch 特征 ──> Pixel Shuffle 4倍压缩 ──> 256 个视觉 token ──> 拼接进文本序列 ──> Qwen3-4B 生成回答

三个关键数字（均可在 config.json 中找到）：

参数	值	位置	含义
`force_image_size`	448	config.json	每个 tile 的边长（像素）
`max_dynamic_patch`	12	config.json	单张图片最多切 12 块
`downsample_ratio`	0.5	config.json	Pixel Shuffle 压缩比例，决定 token 数

📌 核心换算公式写在 modeling_internvl_chat.py：

num_image_token = (448 // 14)² × (0.5)² = 32² × 0.25 = 256

每个 448×448 的 tile，最终只占用 LLM 上下文里的 256 个 token——这是理解"为什么 448 / 为什么 12 块"的钥匙。

二、为什么切片尺寸是 448？📐

2.1 必须能被 patch_size 整除

Vision Encoder 的patch_size是 14（config.json）。ViT 靠卷积把图片切成 14×14 的小块，所以 tile 边长必须是 14 的整数倍，否则边缘像素会被浪费或产生错位：

448 ÷ 14 = 32✅ → 每张 tile 恰好是32×32 = 1024 个 patch
若是 440 或 450，则无法整除，num_patches计算（modeling_intern_vit.py）会直接报错

2.2 32 是 Pixel Shuffle 的"甜点"

ViT 输出 1024 个特征后，要经过 Pixel Shuffle 压缩 4 倍再进 LLM。scale_factor=0.5意味着空间维度各减半：32×32 → 16×16 = 256。

32 是偶数，完美支持减半操作；
256 是个漂亮的 2 的幂，对显存对齐和批处理非常友好。

如果选更大的 560（40×40 patch），每块 tile 就要 400 token，单图 token 成本立刻膨胀 56%。

2.3 448 是视觉编码器的"原生训练分辨率"

vision_config.image_size本身就是 448（config.json）。InternViT 的位置编码在 448 分辨率下训练，推理时直接喂 448×448 的 tile，位置编码完全对齐、零插值损失——细节保真度最大化。

🧮 对比一下：单块 448² ≈ 20 万像素，相当于把手机照片切成"每块约 20 万像素"的拼图，再让模型逐块细读。

三、切几块？dynamic_preprocess 的决策逻辑 🧩

函数实现见 README.md，逻辑只有三步：

第 1 步：穷举候选比例。枚举所有i×j ≤ 12的整数对，得到 28 种候选宽高比（1×1、1×2、…、4×3、6×2、12×1）：

target_ratios = set((i, j) for n in range(min_num, max_num + 1) for i in range(1, n + 1) for j in range(1, n + 1) if i * j <= max_num)

第 2 步：选最接近原图比例的方案。find_closest_aspect_ratio 计算原图宽高比与各候选的差值，取差值最小者；若平局，则选总像素面积更大的方案（多切一点细节）。

第 3 步：缩放 + 网格切割。把整图 resize 到i×448 × j×448，再按 448 网格切出 i×j 张 tile。

原图形态	选中比例	切片数	送入 LLM 的 token
正方形头像	1×1	1	256
16:9 宽屏截图	3×2	6	1536
2:1 超宽横幅	12×1 或 6×2	12	3072
A4 文档长图	1×4 或 2×4	4~8	1024~2048

📎 注意min_dynamic_patch=1（config.json）：小图不会被强行切碎，保持 1 块，省算力。

附赠的"缩略图"：use_thumbnail

当切片数大于 1 时，load_image 会额外把整图压缩成一张 448×448 的全景图一起送入（use_thumbnail=True，config.json）。

细看 tile → 负责 OCR、小字、局部细节；
缩略图 → 负责全局构图、主体位置等"鸟瞰"信息。

两者互补，这正是动态高分辨率策略在文档类任务上表现出色的关键。

四、为什么上限是 12 块？🧮

max_dynamic_patch=12不是拍脑袋，而是一道关于token 预算 × 上下文窗口 × 显存的算术题：

① Token 预算封顶，上下文才装得下

切片数	视觉 token（含缩略图）	占 32K 上下文比例
1 块	256	<1%
6 块	1536	≈5%
12 块	3072 + 256 = 3328	≈10%

InternVL3.5 的 SFT 上下文窗口是 32K token。12 块封顶后，单图视觉占比控制在 10% 左右，仍能留出空间给多轮对话、多图输入和 Thinking 模式的长推理链。

② 总像素预算恒定于 ~240 万像素

12 × 448² ≈241 万像素，约等于一张 1552×1552 的方形高清图。也就是说：无论图片原本多宽多窄，模型"投入"的视觉信息量几乎恒定——横图多切列、竖图多切行、方图少切块，细节总量不变，形状自适应。

③ 显存与推理速度

注意力计算复杂度随序列长度平方增长。12 块意味着 ViT 侧要跑 12 次前向（每次 1025 token），再进 LLM 做约 3.3K 的 prefill——对单张 A100 部署 4B 模型（README 明确指出 ≤30B 可单卡运行）是舒适区间；若放开到 24 块，prefill 时间近乎翻倍，而边际收益递减。

④ 12 是"够用"的甜点位

28 种候选比例恰好覆盖 1:12 到 12:1 的全部常见宽高比（照片、截图、文档、横幅、手机长图）。超过 12 块后，能新增的比例组合越来越少，而 OCR 等任务的精度曲线在此后基本走平。

五、想微调？这几个参数可以动 ⚙️

参数	默认值	调大效果	代价
`max_num`/`max_dynamic_patch`	12	超大图保留更多细节	token 与显存线性上涨
`min_num`/`min_dynamic_patch`	1	小图也被强制放大细看	纯小图白烧算力
`image_size`（`force_image_size`）	448	单块更高清	每块 token 数平方级增长
`use_thumbnail`	True	全局信息更完整	每图 +256 token

调用示例（摘自 README.md）：

pixel_values = load_image('./examples/image1.jpg', input_size=448, # 对应 force_image_size max_num=12).to(torch.bfloat16).cuda()

💡 实用建议：OCR/文档场景保持max_num=12；日常闲聊类图片可降到 4~6 提速；显存紧张的小卡部署则从调小max_num入手，性价比最高。

六、总结：两个数字背后的统一设计哲学

问题	答案	一句话解释
为什么是 448？	14×32，整除 patch 且是 ViT 原生训练分辨率	切得整齐、位置编码零损失、Pixel Shuffle 刚好压到 256 token
为什么上限 12 块？	12×256≈3.3K token，总像素恒定约 240 万	上下文装得下、单卡跑得动、比例覆盖全、收益不再涨

dynamic_preprocess的本质是一台**"视觉信息定量配给机"**：不管输入什么形状的图，都换算成等量的 256-token 小块，形状交给比例，总量交给 12。理解了这个设计，你就理解了 InternVL 系列高分辨率能力的全部秘密。🎯