多模态为什么更费显存
视觉语言模型在文本模型之外多了一整套视觉通路：视觉编码器本身的权重与中间激活、图片预处理缓冲区，以及图片被切成若干视觉 token 后进入上下文所占用的缓存。关键在于视觉 token 数量随分辨率和切图策略增长，一张高分辨率图可能折算成上千个 token，多图请求叠加后等效长度会迅速超过纯文本场景的估算。
基本信息
| 额外开销 | 视觉编码器权重与激活、预处理缓冲、视觉 token 的缓存 |
|---|---|
| 折算方式 | 把视觉 token 按等效文本 token 计入上下文长度 |
| 影响因素 | 输入分辨率、切图策略、图片数量 |
| 并发影响 | 缓存随并发线性增长，多图请求放大更明显 |
| 估算要求 | 按文本加图片的总 token 计算，不能只算文本部分 |
典型使用场景
- 票据与表单识别：高分辨率扫描件折算出的 token 数远高于普通图片
- 多图对比：一次送入多张图做差异分析，视觉 token 叠加后占用可观
- 视频抽帧理解：抽取的帧数越多，等效长度越大，需要提前估算
- 图文混排问答：长文本加图片的组合，两类占用互相叠加
- 批量图像处理：离线任务并发较高时，视觉编码器激活的峰值需要专门评估
折算与验证
折算与验证
单图 token 数 = 取决于分辨率与切图策略（以模型说明为准）
视觉 token 缓存成本 = 视觉 token 数 × 每 token 字节数（与文本同公式）
总预算 = 文本 token 开销 + 视觉 token 开销 + 视觉编码器权重与激活
实测步骤：
1 用单图请求记录显存水位
2 逐步增加图片数量与分辨率，观察水位增量
3 用目标并发跑一遍，确认峰值不超过安全水位显存构成
| 组成部分 | 随什么增长 | 注意点 |
|---|---|---|
| 视觉编码器权重 | 固定，由模型决定 | 与文本权重一起常驻，估算别遗漏 |
| 视觉激活 | 随图片分辨率与批大小增长 | 高分辨率单图也可能产生明显峰值 |
| 视觉 token 缓存 | 随图片数量与等效长度增长 | 多图请求叠加后增长很快 |
| 预处理缓冲 | 随并发与图像大小增长 | 解码与缩放过程会占用临时内存 |
| 文本部分 | 随对话与提示长度增长 | 与视觉占用相加才是总量 |
多图请求要把视觉 token 计入窗口：并发评估应按「文本 + 图」的总 token 计算，按纯文本公式估出的并发上限会明显偏高。
限制单请求图片数量与分辨率是有效的成本控制手段：超出业务需要的分辨率不会带来等比例的识别收益，却会成倍增加缓存占用。