19. 多模态模型的 Visual Token 数怎么算？为什么图像在推理成本里占比这么大？

简单回答

VLM（视觉语言模型）的图像不是"加几个 token"那么简单——一张普通分辨率图（比如 1024×1024）经过 vision encoder 之后通常会产生几百到几千个 visual token，再通过 projector 注入到 LLM 的输入序列里和文本 token 拼在一起。这意味着一次图像问答的实际 input token 数远比看上去多——一张图等价的 token 数可能是一段长文本。再加上 dynamic resolution 等策略让高分辨率图变成几千 token，多图场景轻松破万。这是为什么 VLM 的推理成本、KV Cache 占用、TTFT 都比纯文本模型高一大截，也是 Q-Former、Resampler 这类压缩方案存在的工程动机。

详细解释

Visual Token 是怎么产生的

一张图进入 VLM 的过程大致是这样：

第一步是 vision encoder（典型的 ViT 架构）把图像切成 patch（比如 14×14 像素一个 patch），每个 patch 被编码成一个向量。一张 224×224 的图按 14×14 切就是 16×16=256 个 patch token。一张 448×448 就是 32×32=1024 个 token。token 数和图像分辨率的平方成正比。

第二步是 projector（本专题第 17 篇讲的 MLP / Q-Former / Resampler）把 vision encoder 输出的 token 数和维度对齐到 LLM 的输入空间。这里有三种主流做法：

• MLP / Linear projector：保留全部 vision token，只做维度对齐。token 数不变，比如 ViT 输出 256 个就给 LLM 注入 256 个。LLaVA 早期版本就是这样。
• Q-Former：用一组可学习的 query token（比如 32 或 64 个）通过 cross-attention 聚合 vision encoder 输出。token 数被压缩到固定的 query 数。BLIP-2 是代表。
• Resampler / Perceiver Resampler：和 Q-Former 类似，用 attention 机制把任意数量的 vision token 重采样到固定数量。Flamingo 用的就是这个。

第三步是 LLM 把这些 visual token 当成 input sequence 的一部分，和文本 token 拼接后正常做 self-attention。从 LLM 视角看 visual token 和文本 token 没区别，都是 d 维向量。

真实场景的 token 数量级

让我们看几个具体的数字：

LLaVA-1.5（基础设定）：CLIP-ViT-L/14-336，输入 336×336，patch size 14，得到 24×24 = 576 个 visual token。每张图 576 token。

LLaVA-1.6（高分辨率版本）：用 dynamic resolution 把图切成多块（最多 4 块）+ 一张缩略图，最多 5×576 ≈ 2880 token 一张图。

Qwen-VL / Qwen2-VL：原生支持任意分辨率。一张 1024×1024 的图按 14×14 切就是 73×73 ≈ 5329 个 patch token，Qwen2-VL 用 2×2 merge 后是 1332 token。一张 4K 大图可以飙到一万多 token。

GPT-4V / Claude 3.5 Sonnet（公开估算）：一张高分辨率图大约 1500-2500 token。OpenAI 文档明确说"一张高清图等价 1105 + N×170 个 token"。

多图场景：长文档分析、多页 PDF、视频抽帧——8 张高分辨率图就是 1.5-2 万 token。视频每秒 1 帧抽 60 帧就是几万到十几万 token。

对比一下：纯文本输入"一篇 2000 字的中文文档"大约 3000 个 token。一张 4K 图就能等价好几篇 2000 字的文档。这是 VLM 推理成本的来源。

为什么这影响这么大

Prefill 时间：Prefill 复杂度 O(n²)，n 是序列总长度。把 visual token 算进去后 n 急剧增大，一张高清图的 Prefill 时间可能比同等问题的纯文本版本长几倍到十几倍。TTFT 直接受拖累。

KV Cache 显存：visual token 在 LLM 里和文本 token 一样要算 KV Cache 并存下来。一张图占 1500 token 的 KV Cache 可能就是几十 MB（取决于模型大小）。多图场景或者多轮带图对话下 KV Cache 占用会迅速膨胀，影响 batch size 和并发。

Decode 速度：Decode 阶段每生成一个 token 都要和全部历史 token（包括 visual token）做 attention，序列长导致每步耗时增加。TBT 也受影响。

计费成本：商业 API 按 token 计费时图像 token 是真金白银。GPT-4V 一张高清图大约几分钱，比同样 input 量的纯文本稍贵（因为 output 占比小）。多图应用成本会显著超出纯文本预估。

工程上怎么优化

针对这个问题主流的优化手段有几类：

Resampler/Q-Former 压缩：从架构层面就把 visual token 数压到固定值（比如 64、256），不管原图分辨率多高。代价是细节信息可能丢失，对 OCR、小物体识别这类需要细节的任务效果会下降。Flamingo、BLIP-2 都走这条路。

Dynamic Resolution + Token Merging：根据图像内容自适应分配 token。简单图（一张照片整体）少给 token，复杂图（密集文本、多物体）多给 token。Qwen-VL 系列做了 2×2 merge 把相邻 patch 合并，token 数减半。

视觉相关层稀疏化：观察到很多 visual token 在 LLM 浅层之后注意力权重很低，深层可以丢弃一部分。FastV、VTW 等方法在推理时动态丢 visual token，最高能丢 50% 不显著影响效果。

视觉 KV Cache 量化：visual token 的 KV 用更激进的量化（INT4 甚至 INT2），文本 token 保持高精度。这是因为 visual KV 在生成过程中通常贡献相对小，量化损失可承受。

视觉缓存复用：同一张图被多次问答时，vision encoder 的输出和 visual token 的 KV 都可以缓存（类似 Prompt Caching 的扩展）。Anthropic 的 Prompt Caching 已经支持图像缓存。

设计 VLM 应用时的经验法则

工程上选模型和设计应用时几个直觉：

• 任务对图像细节的依赖度决定 token 数。OCR、文档理解需要高分辨率（多 token）；图像描述、风格判断低分辨率就够（少 token）。
• 多图场景永远比单图贵得多，能不能用文本摘要替代部分图像？比如把"对比两张图的差异"换成"先描述每张图，再用文字对比"，把视觉问题转成文本问题。
• 视频场景最严苛——一定要做关键帧抽取、帧合并、或者用专门的视频压缩模型，不能逐帧塞 LLM。
• 商业 API 用图像时要监控实际 input token 数，很多调用会比预估高几倍。
• 自部署 VLM 时 batch size 要降——同样显存能容纳的并发数比纯文本模型少。

面试时可以这样答

VLM 的图像不是"加几个 token"那么简单。一张图经过 vision encoder 切成 patch token——224×224 切 14×14 patch 是 256 个 token，1024×1024 是几千个，4K 大图能到一万多。这些 visual token 经过 projector 维度对齐后和文本 token 拼接送给 LLM 做 self-attention，对 LLM 来说和文本 token 没区别。

真实场景的数量级很大。LLaVA-1.5 一张图 576 token，1.6 用 dynamic resolution 后最多近 3000 token。Qwen2-VL 一张 1024 图压缩后 1332 token。GPT-4V 高清图等价 1105+170N。8 张高清图的多图场景就是 1.5-2 万 token。视频抽帧更夸张。

影响是全方位的。Prefill 是 O(n²)，序列长 Prefill 时间几倍到十几倍。KV Cache 显存膨胀影响 batch size 和并发。Decode 每步 attention 序列长，TBT 受拖累。商业 API 按 token 计费多图场景成本可能远超预估。

工程优化主要几类。Resampler/Q-Former 把 token 数压到固定值（64/256），但细节信息会损失。Dynamic Resolution + Token Merging（Qwen-VL 的 2×2 merge）按内容自适应。FastV 这类方法在 LLM 深层动态丢弃低注意力的 visual token，能丢 50% 不显著影响效果。视觉 KV 用更激进的量化也是常见做法。

设计应用时的经验是看任务对细节的依赖度选模型，多图场景能不能用文本摘要替代部分图像，视频要关键帧抽取不能逐帧塞，商业 API 要监控实际 token 数避免成本失控。

常见追问

1. Q-Former 把 token 压缩到 64 个，OCR 这类细节任务上具体损失多少？怎么量化？
2. FastV 在 LLM 哪一层开始丢 visual token？怎么决定丢哪些？
3. 视频场景的关键帧抽取算法有哪些？纯视觉的 vs 模型自适应的差别是什么？