多模态大模型部署硬件要求：显存、带宽与选型实战

上周有个做电商售后系统的朋友来找我，说要把 Qwen2.5-VL 接进工单系统，让我帮忙看看机器够不够用——他手上是两台 RTX 4090 的工作站。我问了句"你们日均图片调用量多少、截图平均分辨率多大"，他愣了三秒，回我一句"这个还要看？"

要看。而且比你想的重要得多。

纯文本模型的显存估算，社区里已经有很成熟的公式，参数乘个系数就八九不离十。但多模态大模型部署硬件要求完全是另一套逻辑：同一张图，用 336×336 的单图模式还是 AnyRes 切分，视觉 token 能差出 5 倍；一张 1080p 的界面截图塞进动态分辨率的视觉编码器，随手就是一千多个 token，而这些 token 全都要进 KV Cache。

核心结论摘要：多模态大模型的显存开销 = 模型权重 + 视觉编码器 + 视觉 token 膨胀后的 KV Cache。7B 级模型单卡 24GB 用 INT4 能跑通，但并发一上来就 OOM；72B 级建议 4×A100 80G 起步。真正的瓶颈往往不是显存容量，而是 HBM 带宽和图片预处理的 CPU 开销。

一、多模态为什么比纯文本更吃硬件？

先把账算清楚，多模态模型比同参数量的纯文本模型，多出来的开销主要在三个地方。

视觉编码器的权重。这块经常被忽略。LLaVA 系列用的 ViT-L/14 大约 0.3B 参数，Qwen2.5-VL 系列的视觉塔在 0.6B 上下，还能接受。但 InternVL2-76B 用的是 InternViT-6B——单视觉塔就 6B 参数，FP16 下光它自己就吃掉 12GB 显存（数据来源：InternVL2 技术报告，arXiv:2404.16821，2024 年 4 月）。我第一次看到这个数字时确实有点惊讶。

视觉 token 的膨胀效应。这才是真正的大头。LLaVA-1.5 的 336×336 输入，patch size 14，算下来是 576 个视觉 token，还行。但 LLaVA-NeXT 引入 AnyRes 之后，一张高清图会被切成 5 个 crop，token 数直接飙到 2880。Qwen2.5-VL 走的是原生动态分辨率路线，我实际测过一张 1280×720 的网页截图，在 28×28 的 patch 粒度下大约产生 1196 个视觉 token——这还只是一张图。

图片预处理。解码、resize、归一化，这些操作在 CPU 上跑。单条请求没感觉，并发到 20 以上时，Python 的 GIL 会让它变成实打实的瓶颈，表现为 TTFT（首 token 延迟）抖得厉害。

二、显存怎么算：一套能手推的公式

别依赖各种"显存计算器"网页，它们对多模态的支持基本都不准。手算其实很简单。

模型权重

| 参数量 | FP16/BF16 | INT8 | INT4 (AWQ/GPTQ) | |---|---|---|---| | 7B | ~14 GB | ~7 GB | ~4.5 GB | | 13B | ~26 GB | ~13 GB | ~8 GB | | 32B | ~64 GB | ~32 GB | ~19 GB | | 72B | ~144 GB | ~72 GB | ~40 GB |

注意 INT4 不是简单除以 4，量化 scale、zero point 和部分未量化的层（比如 embedding、lm_head）会额外占 10%~15%。

KV Cache

公式是：

KV 字节数 = 2 × 层数 × KV头数 × head_dim × 序列长度 × 并发数 × 数据类型字节数

以 Qwen2.5-VL-7B 为例，28 层、4 个 KV 头、head_dim 128、BF16 存储：

2 × 28 × 4 × 128 × 2 = 57,344 字节 ≈ 56 KB / token

看着不多？乘一下就知道了。8192 上下文、32 路并发：

56 KB × 8192 × 32 ≈ 14.3 GB

再加上 4.5GB 权重、约 1.4GB 的视觉编码器（FP16）、激活值预留，24GB 卡基本就贴着天花板跑了。vLLM 的 PagedAttention 能通过分页和前缀复用把这个数字压下来一些（来源：PagedAttention 论文，SOSP 2023），但那是优化，不是免单。

三、多模态大模型部署硬件要求的三个隐形门槛

显存容量只是入场券。下面这三条，才是我见过最多团队翻车的地方。

带宽决定解码速度

大模型解码阶段是典型的 memory-bound，每生成一个 token 都要把权重完整读一遍。这时候决定吞吐的就是显存带宽，不是算力。

| 型号 | 显存 | 带宽 | 卡间互联 | |---|---|---|---| | RTX 4090 | 24GB GDDR6X | 1008 GB/s | 无 NVLink，P2P 被驱动禁用 | | RTX 5090 | 32GB GDDR7 | 1792 GB/s | 同上有阉割 | | L40S | 48GB GDDR6 | 864 GB/s | 支持 PCIe P2P | | A100 80G SXM | 80GB HBM2e | 2039 GB/s | NVLink 600 GB/s | | H100 SXM | 80GB HBM3 | 3350 GB/s | NVLink 900 GB/s |

数据来源：NVIDIA 官方数据中心 GPU 规格页（2024 年更新）。H100 的带宽是 4090 的 3.3 倍——这就是为什么同样跑 7B 模型，H100 上的 token/s 能甩开消费卡一大截。

多卡互联的坑

坦白讲，用两张 4090 做张量并行是很多人的第一反应，也是我最不推荐的做法。NVIDIA 在 GeForce 驱动的较新版本里封掉了 P2P 访问，两卡通信要绕道主机内存，NCCL 走 SHM 通道，tensor parallel 的收益被通信开销吃掉大半。有这钱不如直接买一张 L40S 或者二手的 A100。

并发下的预处理压力

vLLM 从 0.6.0 版本开始正式支持 Qwen2-VL 系列（来源：vLLM 官方文档 Changelog，2024 年 9 月）。但要注意，图片的多模态预处理默认跑在 CPU 上。生产环境记得调 `--mm-processor-cache-gb` 和限制输入分辨率，否则 CPU 会先于 GPU 跪掉。

四、三种典型场景的配置清单

场景 A：个人开发 / 创业验证（预算 2 万内）

一台 RTX 4090 24GB 或 5090 32GB 的机器，跑 Qwen2.5-VL-7B 的 AWQ INT4 版本，并发控制在 4 路以内，上下文压到 8K。做原型验证完全够用，我自己的测试环境就是这么配的。

场景 B：中小规模生产（日请求 1 万~10 万）

单张 L40S 48GB 或 A100 40G，用 vLLM 起服务：

启动 Qwen2.5-VL-7B 的 OpenAI 兼容推理服务

--quantization 只量化 LLM 主干，视觉塔保持 FP16，避免 OCR 精度崩掉

--limit-mm-per-prompt 限制单请求图片数，防止视觉 token 撑爆 KV Cache

vllm serve Qwen/Qwen2.5-VL-7B-Instruct \ --quantization awq_marlin \ --max-model-len 16384 \ --gpu-memory-utilization 0.90 \ --limit-mm-per-prompt image=4 \ --port 8000

`--gpu-memory-utilization 0.90` 是留给 KV Cache 的余量，别设成 0.98，不然 PagedAttention 没有分页空间，反而更容易 OOM。

场景 C：高并发企业部署（72B 级）

4×A100 80G 或 2×H100 起步，走张量并行。这时候要重点看 NVLink 拓扑，PCIe 版本的 A100 在 4 卡并行下带宽会明显掉。MLPerf Inference v4.1 的结果显示，同等卡数下 NVLink 版本的吞吐优势在 70B 级模型上能到 30% 以上（来源：MLPerf Inference v4.1 结果，2024 年 8 月）。

五、我在三个项目里踩过的坑

说点文档里不会写的。

第一个坑：把视觉塔一起量化了。 早期为了省显存，我把 Qwen2-VL 的 ViT 也用 AWQ 压到 INT4，结果 OCR 场景下的文字识别错误率肉眼可见地上升，尤其是小字号的中文。后来把视觉塔单独保留 FP16，显存多花 1.4GB，准确率就回来了。视觉特征对量化的敏感度，明显高于语言主干。

第二个坑：低估了长上下文和图片叠加的杀伤力。 有个项目是合同审阅，一次要喂 8 页扫描件。8 张 A4 在动态分辨率下大约 6000 个视觉 token，虽然没超过 16K 上下文，但 KV Cache 实际占用比我预估的高了 40%——因为我没算上图片连续推理时的中间激活。这个只有压测才能发现，纸上算不出来。

第三个坑：图片预处理线程抢 CPU。 我们线上机器是 16 核，GPU 利用率一直在 60% 上下晃，怎么调 batch 都上不去。最后发现瓶颈在 CPU：图片解码 + resize 吃满了 12 个核。把预处理分辨率上限从 2048 降到 1280，GPU 利用率立刻到 90%。多模态部署的成本模型里，CPU 和 GPU 是要一起算的，这是我踩过最贵的一课。

如果你正准备把多模态能力接进 Agent 智能体 做自动化流程，或者要把图文结果写进 向量数据库 做 RAG 检索增强，上面这些数字建议先过一遍再下单。

关键要点速览

• 多模态显存 = 权重 + 视觉塔 + 视觉 token 膨胀后的 KV Cache，视觉塔别忽略，InternViT-6B 这类大视觉塔单独就要 12GB。
• KV Cache 手算公式：`2 × 层数 × KV头数 × head_dim × 序列长度 × 并发 × 字节数`，7B 模型约 56 KB/token，32 路并发 8K 上下文就是 14GB。
• 解码吞吐看带宽不看算力，H100 的 3350 GB/s 是 4090 的 3.3 倍；多卡场景下 4090 没有 NVLink，张量并行基本不划算。
• 视觉编码器建议保持 FP16，跟 LLM 主干分开量化，OCR 场景尤其明显。
• 图片预处理跑在 CPU 上，高并发下它会比 GPU 先成为瓶颈，记得限制输入分辨率上限。

多模态推理的硬件门槛，2025 年这一年降得很快。7B 级模型在单张消费卡上跑出可用效果已经不是什么难事，真正的分水岭在并发和长上下文。往后看，MoE 架构