单张 3090 能跑哪些视觉模型：8 个 VLM 的显存账，和三个反直觉结论

先说结论

1. 权重能不能放下，是一道除法题：BF16 每十亿参数约 2GB、INT8 约 1GB、4bit 约 0.5GB。24GB 卡要按 vLLM 的默认口径算——gpu_memory_utilization 默认只允许用掉 0.92，所以实际可用预算约 21–22GB。得出两个上限：BF16 约 10B 参数，4bit 约 40B（那时 KV cache 只剩几 GB）。
2. 真正卡住视频任务的不是权重，是 KV cache。36 层 / 8 个 KV 头 / head_dim 128 的 8B 级模型，每 token 要 147KB：1K token 147MB、8K 是 1.18GB、32K 就是 4.72GB。而视频帧转出来的视觉 token 特别多——顺序反了会白折腾一天。
3. 官方模型卡基本不给”建议显存”这个字段。8 个候选模型里只有 1 个写了最低显存要求（NVIDIA 那个写的是 “requires a minimum of 24 GB”），另一个给的是分档目标硬件；其余 6 个什么都没写。所以网上”XX 模型需要 XX GB”的说法，绝大多数是别人自己算的。
4. 模型卡上印的 256K 上下文，在单卡上没有实际意义。按 147KB/token 算，256K token 的 KV cache 要约 38GB——单卡能用的上下文是被显存反推出来的，不是模型卡上那个数。
5. 一个直接可操作的结论：Qwen3-VL-8B 官方同时发了 BF16、FP8、GGUF 多个档位，但 -FP8 权重在 3090 上不可用——vLLM 的兼容表把 FP8(W8A8) 在 Ampere 一列标为不支持。要下就下 BF16 或 GGUF。（注意区分：这里说的是 FP8 权重；KV cache 单独量化成 fp8 是另一回事，那是可用的。）

显存到底怎么算

权重部分：按量化位宽直接乘——BF16/FP16 = 2 字节/参数、INT8 = 1 字节、4bit ≈ 0.5 字节（GGUF 的 K-quant 带额外元数据，实际略大）。依据是 Hugging Face 的 bitsandbytes 文档原话：「Quantizing the model in 8-bit halves the memory-usage」。

KV cache 部分，这是最容易被忽略的一块：

KV bytes/token = 2 × num_hidden_layers × num_key_value_heads × head_dim × dtype_bytes

• 2 是 K 和 V 两份；dtype_bytes 默认 FP16 = 2（开启 kv_cache_dtype="fp8" 后为 1，KV cache 直接减半）。
• 四个结构参数都能从模型仓库的 config.json 读到（num_hidden_layers、num_key_value_heads、head_dim、torch_dtype）。
• 说明：这条是注意力的算术结果，我没有找到哪份官方文档把它写成一行公式；出处是配置字段定义与注意力机制本身。

8 个模型的对照

名单来自一篇社区实测帖（二手来源，见文末口径）。模型身份我逐个在 Hugging Face 上核对过，其中一行的身份没能核实，已在表下单独标注。

两处必须说明的口径：

① 权重列全部是”参数量 × 字节数”的推算值，不是官方数字；唯一例外是 google/gemma-3-12b-it，它用的是官方文件体积 24.4GB（该仓库为门控资源，我拿不到 config.json，因此它的 KV 列是空的）。

② 对照帖里写的是「Gemma 4 12B」，但我在 Hugging Face 上核不到名为 Gemma 4 的仓库，所以这一行暂按 google/gemma-3-12b-it（12.19B，许可证 gemma）处理——这是全表唯一一处模型身份未经核实的行，引用前请自行确认。

另外：KV 列是按公式代入 config.json 算出的推算值；标注”混合注意力”的两个模型，其 layer_types 里只有部分层是全注意力，所以表内是上限值（真实占用更低）。

读法：8B 级可以 BF16 直接跑；12B 是分界线（BF16 权重 24.4GB，已经超过 21–22GB 的可用预算）；27B 以上必须 4bit。

三个反直觉的地方

一、视频任务的瓶颈会从权重转移到 KV cache。 权重是固定的（8B 模型 17.5GB），但 KV cache 随上下文线性长：8K token 1.18GB、32K 就是 4.72GB。视频帧一多，显存就被它吃掉。 顺手记一个开关：vLLM 支持 kv_cache_dtype="fp8" 把 KV cache 直接减半，这是最容易被忽视的一项。

二、”混合注意力”模型的真实占用比纸面低。 Muse-Glimmer-30B 的 sliding_attention 与 full_attention 交替（sliding_window=2048），滑动窗口那部分的缓存有上限、不随上下文增长；Qwen3.8-27B 每 4 层只有 1 层是全注意力。所以表里这两行的 KV 都是上限值，不是实际占用。

三、MoE 省的是算力，不是显存。 InternVL3_5-30B-A3B 是 MoE（128 专家、每 token 激活 8 个），激活参数远小于总参数，但显存要按总参数算——所以它的现实档位还是 4bit。

一句话的可执行结论

• 8B 以下：BF16 直接上，给 KV cache 留 4GB 以上。
• 12B：INT8 或 4bit；BF16 放不下（24.4GB > 可用预算）。
• 27B–31B：只有 4bit 一条路，并且优先选官方给了量化档位的仓库——meta-models/Muse-Glimmer-30B 是唯一一个在模型卡上明说 K-Quant-17GB 能在 24GB 消费级硬件上跑的。
• 别下 FP8 权重（3090 是 Ampere，不支持 W8A8）；但 KV cache 用量化 fp8 是可以的。
• 视频任务先算 KV cache，再算权重。

数据口径（这段很重要）

文中有三种数字，性质完全不同：

• 官方数据：参数量来自 Hugging Face 仓库的文件元数据；上下文长度、许可证、”最低 24GB”来自模型卡原文；”8bit 减半”来自 HF 的 bitsandbytes 文档；”FP8 在 Ampere 不支持”来自 vLLM 官方兼容表；21–22GB 可用预算来自 vLLM 的 gpu_memory_utilization 默认值 0.92。
• 本文推算：所有权重列（除 Gemma 那行）与 KV 列，都是把上面的公式与 config.json 字段代入算出来的，不是官方数字，你可以复算。
• 社区二手：8 个模型的名单来自那篇 Reddit 实测帖；”prompt 长度在 4,334–10,875 token”这一观测值也来自该帖。帖子的速度数据本文没有采用。

这次没核实的

• nvidia/Cosmos-Reason2-2B 的 config.json 需要授权（HTTP 401），KV 列算不出来，留空。
• google/gemma-3-12b-it 是门控仓库，KV 列同样留空；它的模型身份本身也没核实（见上表脚注）。
• 四个 30B 级/27B 级模型的 KV 数据依赖混合注意力结构，我拿到的是上限值。
• 本文没有在本机实测（手上没有 3090）；所有结论是算术结论，速度、吞吐、实际体验都不在范围内。
• 补充候选（Cosmos-Reason2-8B、Qwen3-VL-4B、LLaVA-NeXT-Video-7B） 只抓了元数据、没读模型卡正文，因此没有入表。

参考来源

• Qwen/Qwen3-VL-8B-Instruct——参数量与上下文
• google/gemma-3-12b-it——官方文件体积 23.92GB（表中按 24.4GB 参数推算口径标注）
• meta-models/Muse-Glimmer-30B——64GB / 32GB / 24GB 分档目标硬件
• OpenGVLab/InternVL3_5-30B-A3B——MoE 结构字段
• Hugging Face Transformers：Bitsandbytes 量化文档——「8-bit halves the memory-usage」
• vLLM 量化支持矩阵——FP8(W8A8) 在 Ampere 的支持情况、kv_cache_dtype="fp8"
• vLLM：显存与吞吐调优——省显存的官方手段清单
• vLLM 配置 API 参考——gpu_memory_utilization 默认 0.92