企业官网建设流程全解析

InternVL2_5-26B-MPO-AWQ 是开源多模态大模型 InternVL2.5-26B-MPO 的 AWQ 4-bit 量化版本，它通过Pixel Shuffle 像素压缩与动态分辨率切片两大机制，让视觉 Token 数量始终可控——这就是本文要拆解的"像素压缩奥秘"。

💡 一句话理解：普通视觉模型"图片越大、Token 越多、算力越爆表"，而 InternVL 通过重排压缩 + 按需切片，把算力开销压到了可以单卡部署的水平。

一、先看全貌：ViT-MLP-LLM 三段式架构

InternVL 系列采用经典的ViT-MLP-LLM范式，本模型的三个核心部件如下：

此外，配置中的quantization_config明确了 AWQ 4-bit 量化（bits: 4、group_size: 128），这正是名称中AWQ的由来——用 4-bit 权重大幅降低显存占用，是"26B 模型跑进单卡"的关键。

📌 想理解每个参数怎么生效，可以对照阅读 modeling_internvl_chat.py、modeling_intern_vit.py 和 modeling_internlm2.py 三个文件。

二、Pixel Shuffle：把 1024 个 Token 压成 256 个

2.1 压缩前后对比

以一张标准的 448×448 图像切片（Tile）为例：

Token 数量直接降到 1/4，而信息并没有被丢弃——每 4 个相邻的空间特征被拼接到一起，变成一个维度更高（3200×4=12800）的 Token。

2.2 原理：纯张量重排，零参数、零损失

核心实现 pixel_shuffle() 只有三次view/permute操作：

先把特征看作 H×W 网格，让相邻的 2×2 块"折叠"到同一位置，特征维数相应 ×4。整个过程只做内存重排，不经过任何可学习参数，因此没有任何信息损失，压缩代价为零。

两个细节值得新手注意：

• scale_factor=0.5由 config.json 中的downsample_ratio控制，"0.5"即空间分辨率减半、Token 数变为 1/4；
• config.json 中ps_version: "v2"表示修正了 v1 版本中高低维度未换回导致的"图像转置"问题（见 modeling_internvl_chat.py#L178-L182）。

压缩发生在 extract_feature() 中：ViT 提取特征 → 去掉 CLS 头 → 像素重排 → 送入 MLP 投影层。

三、num_image_token：每个 Tile 固定 256 个视觉 Token

模型初始化时用一行公式算出每个切片的 Token 数（modeling_internvl_chat.py#L53）：

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

这 256 个 Token 对应文本中的特殊占位符<IMG_CONTEXT>（Token ID 92546，定义见 added_tokens.json）。在 chat() 中，每个图像占位符会被展开成<img>+ 256×N 个<IMG_CONTEXT>+</img>（N 为切片数）。

随后在 forward() 中完成"替换魔法"：把输入序列里所有<IMG_CONTEXT>位置的词向量，直接覆写成 ViT 输出的视觉特征，语言模型就像读"文字"一样读"图像"。

四、动态分辨率：小图少切片、大图按预算切片

4.1 关键配置三件套

4.2 一张图到底消耗多少 Token？

动态分辨率把"图像 Token 预算"变成了可预测的区间：

• 📷小图（如 512×384）：1 片 → 256 个视觉 Token，轻省快速；
• 📷中图（如 1024×768）：2×2 = 4 片 → 1024 个视觉 Token；
• 📷大图（如 2048×1536）：触发 12 片上限 → 3072 个视觉 Token，细节尽收眼底且不会撑爆上下文。

切片数的具体选择由 chat() 的num_patches_list参数控制：外部预处理先按长宽比把图切成 448×448 的 Tile 列表，模型再按"片数 × 256"动态生成占位符。

4.3 use_thumbnail：全局缩略图 + 局部细节双保险

config.json 中use_thumbnail: true表示开启缩略图机制：除了高分辨率切片外，还会先给模型一张整体缩略图，让它先看懂全貌、再聚焦局部。这解决了纯切片方案"只见树木不见森林"的经典缺陷——对表格、长文档、多目标场景尤为关键。

五、为什么这样设计？算力与精度的平衡账

🔍为什么必须压 Token？Transformer 注意力开销与 Token 数呈平方关系。一张大图若不压缩可能产生上万视觉 Token，注意力计算量直接爆炸。Pixel Shuffle 把 Token 数除以 4，两两注意力计算量约除以 16。

为什么动态分辨率比固定分辨率强？固定 448×448 对手机截图是"杀鸡用牛刀"，对 4K 文档又"细节全丢"。动态切片让 Token 开销与实际信息量成正比，配合max_dynamic_patch兜底，既保精度又防 OOM。

AWQ 量化又贡献了什么？4-bit 权重大约把显存压到 16-bit 的 1/4，与 Token 压缩形成"显存 + 算力"双线减负——这正是 AWQ 版本能贴近单卡部署的完整原因。

六、最快上手路径：LMDeploy 两行启动

部署本模型官方推荐 LMDeploy 工具链（详见 README.md 的 Deployment 部分）：

pip install lmdeploy>=0.6.4 lmdeploy serve api_server OpenGVLab/InternVL2_5-26B-MPO-AWQ --server-port 23333

启动后即可使用兼容 OpenAI 的 RESTful 接口发送"图像 + 文本"请求。注意多图片输入会显著增加视觉 Token 数，建议适当调大session_len上下文窗口。

💡 若需要在本地代码中直接调用model.chat(...)，务必传入与切片数一致的num_patches_list，否则占位符数量与实际视觉特征对不上会触发断言报错。

七、新手 FAQ：三个高频疑问

Q1：Pixel Shuffle 压缩会不会丢图像细节？不会"丢"，而是"搬"。4 个邻居 Token 的信息被拼接进同一个 Token 的更高维度里，再由 MLP 投影层整合，是重排而非截断。

Q2：12 片上限不够用怎么办？上限对应单图 3072 个视觉 Token，已覆盖绝大多数文档与图表场景。若确需更高分辨率，可参考 InternVL 家族在max_dynamic_patch上的调参思路，但上下文窗口与显存需要同步放大。

Q3：AWQ 量化会影响视觉理解精度吗？量化只作用于语言模型权重（视觉塔仍以 bfloat16 存储于各pytorch_model-000XX-of-00013.bin分片中），对 MMBench、OCRBench 等评测的影响极小，换来的是约 4 倍的显存节省。

📚本文引用的核心文件

• 配置总览：config.json（downsample_ratio/dynamic_image_size/max_dynamic_patch/ AWQ 量化参数）
• 主模型逻辑：modeling_internvl_chat.py
• 视觉编码器：modeling_intern_vit.py
• 配置类定义：configuration_internvl_chat.py
• 特殊 Token 映射：added_tokens.json
• 项目说明与评测数据：README.md