多模态大模型推理为什么更慢？如何优化视觉 Token、缓存和批处理？

简化版

多模态推理比纯文本多出媒体预处理 + 视觉编码 + 连接器计算，而且视觉 token 会加长 LLM Prefill、占用 KV Cache——一张高分辨率图就可能有几千视觉 token，比文字问题长得多。优化要分段下手：图像解码/缩放、视觉塔吞吐、视觉 token 压缩、相同媒体的特征缓存、按”总 token 而非请求数”动态批处理。核心心法是减少重复视觉计算 + 控制有效视觉 token + 按真实 token 负载调度。

详细版

一次请求延迟粗分为：媒体加载/预处理 → 视觉编码 → 连接投影 → LLM Prefill → 自回归 Decode。高分辨率、多图、视频主要推高前四项；输出越长则 Decode 占比越高。

视觉特征缓存适合完全相同且处理配置一致的媒体，缓存键必须含文件内容哈希 + 视觉模型版本 + 分辨率 + 切块参数。视觉 token 池化/重采样/剪枝能降 LLM 成本，但要按 OCR、计数、空间任务验证信息损失。

完整版教学

记忆钩子：多模态题先看视觉信号如何变成 token，再看连接器如何对齐语言空间，最后看推理成本和幻觉风险。

一、延迟到底来自哪：分阶段拆解

纯文本请求只有 Prefill + Decode；多模态在前面多挂了一长串：

[下载/读取] → [解码/颜色转换] → [缩放/切块] → [视觉编码器]
   → [连接器投影] → [视觉token + 文本token 一起 Prefill] → [逐token Decode]
      ↑___________ 多模态新增的开销 ___________↑

关键认知：只看总耗时无法定位瓶颈，必须分别记录各阶段时长、视觉块数、视觉 token 数、文本 token 数。比如首 token 慢，可能是视觉塔慢、也可能是视觉 token 太多导致 Prefill 长——要拆开才知道优化哪。

二、视觉 token：多模态推理的头号成本

视觉 token 从两个方向推高成本：

加长 Prefill：注意力和 FFN 随总序列长度增长（注意力还是 O(N²)）；
占用 KV Cache：生成时每层都要缓存视觉前缀的 K、V。

一张高分辨率图 4000 视觉 token + 50 文字 token：
  → Prefill 要处理 4050 个位置，视觉占了 98%
  → KV Cache 也主要被视觉 token 占据

易错点：不同架构开销不同——是否缓存所有视觉前缀、是否用独立 Cross-Attention（Flamingo 那种视觉不占主序列），决定了具体成本，不能用一个固定公式套所有模型。优化时可降输入分辨率、限块数、池化、选任务相关 token，但不能只追求压缩率（要测细节任务是否退化）。

三、缓存策略：别重复跑视觉塔

一个高频优化点：同一张图在多轮对话里被反复提问时，不必每轮都重跑视觉编码器：

多轮对话，同一张图：
  第1轮：跑视觉塔 → 缓存视觉编码器输出（或投影后的视觉 token）
  第2-N轮：直接复用缓存，跳过视觉塔

缓存要点（易错）：

缓存键必须含内容哈希——相同 URL 不保证内容不变，用文件内容哈希才安全；
还要含模型版本、预处理版本、分辨率、切块参数，任一变化就失效；
若连接器不依赖文本，可缓存投影后的视觉 token（省得更多）；
需租户隔离、有效期、敏感数据策略（视觉特征也可能泄露隐私）。

四、批处理与调度：按 token 而非请求数

多模态的图片尺寸、块数不同 → 视觉序列长度变化很大。如果按「请求数」硬凑批次，会出问题：

一批 8 个请求：7 个是短问题，1 个是长视频（上万视觉 token）
  按请求数凑批 → 那 1 个长视频拖慢整批（木桶效应）
正确做法：按"预计总视觉 token + 文本 token"分桶，限制单请求最大预算

此外视觉塔和 LLM 的最优 batch 大小可能不同，可用分阶段队列/流水线（视觉塔一个队列、LLM 一个队列），但要考虑中间特征占用和排队延迟。

五、质量与线上保护

每种压缩策略都要同时测性能和质量：首 token 延迟、吞吐、峰值显存、缓存命中率，以及 OCR、细粒度识别、空间关系、幻觉。平均准确率变化小，也可能掩盖文档类任务的大幅退化——要分场景看。

线上还要防御异常媒体：限制文件大小、像素、帧数、时长、图片数量、输出长度，防止一个超大文件耗尽资源；处理不可信文件时隔离解码器和媒体库（防解码漏洞），日志里不保存原始敏感图像。

六、常见误区与追问

误区：多模态慢主要慢在 Decode。 高分辨率/多图/视频主要慢在前四段（预处理+视觉塔+连接+更长 Prefill）。
误区：视觉 token 压得越狠越好。 过度压缩会让 OCR/计数/空间任务大幅退化，要测质量。
误区：相同 URL 就能复用缓存。 URL 内容可能变，必须用内容哈希做缓存键。
追问：视觉 token 怎么推高成本？ 加长 Prefill（O(N²) 注意力）+ 占 KV Cache，高分辨率时占绝大部分。
追问：多轮同图怎么优化？ 缓存视觉编码器输出/投影后 token，跳过重复视觉塔计算。
追问：为什么按请求数批处理不好？ 一个长视频会拖慢整批，应按总 token 分桶 + 限单请求预算。
追问：线上防护措施？ 限文件大小/像素/帧数/时长/图数/输出长度，隔离解码器，日志脱敏。

七、加强记忆

多模态推理慢记「预处理 + 视觉塔 + 更长 Prefill + Decode 的总和」，头号成本是视觉 token（加长 O(N²) Prefill + 占 KV Cache，高分辨率图可达几千 token）。优化三招钉死：① 减少重复视觉计算（多轮同图缓存视觉塔输出，缓存键用内容哈希+模型/预处理版本）、② 控制有效视觉 token（降分辨率/限块数/池化/剪枝，但测细节退化）、③ 按总 token 而非请求数分桶调度（防长视频拖慢整批）。别忘线上防护：限媒体规格、隔离解码器、日志脱敏。

简化版

详细版