ModelVRAM 的估算有多准？预测值与实测值
在 19 条公开实测中，中位绝对误差为 1.2%。KV 缓存公式在 8 条 llama.cpp 日志中有 8 条完全一致；权重的中位误差为 1.5%；整卡总占用偏高 5.6%–8.1%，因为 0.5 GB + 10% 的开销对 llama.cpp 单个请求来说偏保守。
误差汇总
| 比较对象 | 条数 | 中位绝对误差 | 高估 | 低估 | 误差 ≤ 0.5% |
|---|---|---|---|---|---|
| 全部 | 19 | 1.2% | 6 | 4 | 9 |
| KV 缓存 | 8 | 0.0% | 0 | 0 | 8 |
| 权重 | 7 | 1.5% | 2 | 4 | 1 |
| 整卡占用 | 4 | 6.4% | 4 | 0 | 0 |
误差 = （预测 − 实测）÷ 实测，正数表示本站高估。GB 和 GiB 都指 1024³ 字节，MiB 指 1024² 字节，与 llama.cpp 日志相同。
逐条对比
预测值在构建网站时用计算器同一套函数算出：KV 缓存用 kvCacheBytes，权重用 weightBytes，整卡用 estimate（0.5 GB + 10% 开销），单个请求（Gemma 4 26B 那条按日志中的 4 个槽位）。上下文取 llama.cpp 实际分配的缓存单元数（上下文向上取整到 256 的倍数）。
| 模型 | 比较 | 设置 | 预测 | 实测 | 误差 | 原因 | 来源 |
|---|---|---|---|---|---|---|---|
| Mistral Small 3.1 24B | KV 缓存 | Q4_K_M，20,736 个缓存单元，f16 KV koboldcpp 1.88, RTX 4090 24GB | 3,240 MiB | 3,240 MiB CUDA0 KV buffer size = 3240.00 MiB | 0.0% | 普通分组查询注意力：每 token 2 × 40 层 × 8 头 × 128 维 × 2 字节。 | github.com 2025-04-13 |
| Mistral Small 3.1 24B | KV 缓存 | Q4_K_M，57,600 个缓存单元，q4_0 KV koboldcpp 1.88, RTX 4090 24GB | 2,531.3 MiB | 2,531.3 MiB CUDA0 KV buffer size = 2531.25 MiB | 0.0% | q4_0 每 32 个值占 18 字节，即这里按每值 4.5 位计算。 | github.com 2025-04-13 |
| Gemma 2 9B | KV 缓存 | 3,072 token，f16 KV，GTX 1070 llama.cpp（2024 年 10 月）, GTX 1070 8GB | 1,008 MiB | 1,008 MiB CUDA0 KV buffer size = 1008.00 MiB | 0.0% | 比 Gemma 2 的 4,096 token 滑动窗口短，所以每层都保留全部 token。 | github.com 2024-10-28 |
| Llama 3.1 8B | KV 缓存 | Q4_K_M，-c 132000（132,096 个缓存单元），f16 KV llama.cpp b7583, DGX Spark | 16,512 MiB | 16,512 MiB CUDA0 KV buffer size = 16512.00 MiB | 0.0% | 每 token 128 KiB，与公式完全一致。 | github.com 2025-12-30 |
| Llama 3.1 70B | KV 缓存 | Q4_K_L，131,072 token，q4_0 KV llama.cpp b3889 (ROCm), AMD 多卡（ROCm） | 11,520 MiB | 11,520 MiB KV self size = 11520.00 MiB, K (q4_0): 5760.00 MiB, V (q4_0): 5760.00 MiB | 0.0% | 同一公式，每值 4.5 位。 | github.com 2024-10-06 |
| gpt-oss-20b | KV 缓存 | MXFP4，32,768 token，f16 KV llama.cpp b6360, NVIDIA 显卡（CUDA） | 786 MiB | 786 MiB KV buffer size = 768.00 MiB (32,768 cells) + 18.00 MiB (SWA, 768 cells) | 0.0% | 12 个全注意力层一直完全一致。滑动窗口层分到 768 个单元（128 token 窗口加 512 token 批次，再向上取整到 256），我们自 2026-09-29 起按此计算；此前按 128 个单元计算，少算了 15 MiB（1.9%）。 | github.com 2025-09-04 |
| Gemma 4 12B | KV 缓存 | QAT q4_0，4,096 token，q8_0 KV Ollama 0.30.6, RTX 4060 Laptop 8GB | 289 MiB | 289 MiB non-SWA 34.00 MiB (4,096 cells) + SWA 255.00 MiB (1,536 cells), q8_0 | 0.0% | 自 2026-09-29 起完全一致。此前少算了 35%，差在两处：llama.cpp 为 Gemma 4 全局层单独存了一份 V，而我们只算了一份 K；滑动窗口层分到 1,536 个单元（1,024 token 窗口加 512 token 批次），而我们按 1,024 计算。 | github.com 2026-06-07 |
| Gemma 4 26B-A4B | KV 缓存 | Q4_K_M，248,320 token，4 个槽位共享，f16 KV llama.cpp b8648, RTX 4090 24GB | 5,750 MiB | 5,750 MiB non-SWA 4850.00 MiB (248,320 cells) + SWA 900.00 MiB (4,608 cells) | 0.0% | 自 2026-09-29 起完全一致，按一个统一缓存中的 4 个槽位、每个 62,080 个单元计算。此前少算了 54%：全局层正好是我们的两倍；4 个并行槽位让滑动窗口层分到 4 × 1,024 + 512 个单元，而我们按 1,024 计算。 | github.com 2026-04-04 |
| Llama 3.1 8B | 权重 | bartowski Q4_K_M GGUF llama.cpp b7583, DGX Spark | 4,633.2 MiB | 4,689.9 MiB file size = 4.58 GiB (4.89 BPW) | −1.2% | 文件平均每权重 4.89 位，略高于我们用的 4.84 位。 | github.com 2025-12-30 |
| Llama 3.1 70B | 权重 | Q4_K_L GGUF（Q4_K_M 加 Q8_0 嵌入层） llama.cpp b3889 (ROCm), AMD 多卡（ROCm） | 40,707.6 MiB | 41,287.7 MiB model size = 40.32 GiB (4.91 BPW) | −1.4% | 与我们的 Q4_K_M 比较；Q8_0 的嵌入层和输出层多出约 1%。 | github.com 2024-10-06 |
| Mistral Small 3.1 24B | 权重 | openfree Q4_K_M GGUF koboldcpp 1.88, RTX 4090 24GB | 13,600.6 MiB | 13,662.4 MiB CUDA0 model buffer size = 13302.36 MiB + CPU_Mapped 360.00 MiB | −0.5% | 相差不到 0.5%。 | github.com 2025-04-13 |
| gpt-oss-20b | 权重 | gpt-oss-20b-mxfp4.gguf llama.cpp b6360, NVIDIA 显卡（CUDA） | 13,123.8 MiB | 11,540.5 MiB file size = 11.27 GiB (4.63 BPW) | +13.7% | 我们按官方权重计算：MXFP4 专家加 18 亿个 BF16 参数。GGUF 把其中一部分存成了更小的类型，例如 5.79 亿参数的嵌入表是 Q8_0（同一日志里 586.82 MiB 的 CPU 缓冲区）。 | github.com 2025-09-04 |
| gpt-oss-120b | 权重 | openai/gpt-oss-120b，MXFP4 vLLM 0.14.1, H100 80GB | 62,226.1 MiB | 65,925.1 MiB Model loading took 64.38 GiB memory | −5.6% | vLLM 报告的是加载完成后显存的实际占用，比权重文件本身多；我们按权重文件计算。 | github.com 2026-01-27 |
| Gemma 4 26B-A4B | 权重 | ggml-org Q4_K_M GGUF llama.cpp b8648, RTX 4090 24GB | 14,889.3 MiB | 16,005.1 MiB file size = 15.63 GiB (5.32 BPW) | −7.0% | Q4_K_M 会把部分张量保留为更高精度，而这个模型里这部分占比更大：文件平均每权重 5.32 位，我们按 4.84 位计算。 | github.com 2026-04-04 |
| Gemma 4 31B | 权重 | Q5_K_M GGUF llama.cpp b9031, 2 张 NVIDIA 显卡（CUDA） | 21,138 MiB | 20,817.9 MiB file size = 20.33 GiB (5.69 BPW) | +1.5% | 每权重位数基本一致（5.69 对 5.67）；我们的参数量包含视觉编码器，而这个 GGUF 不含。 | github.com 2026-05-06 |
| Mistral Small 3.1 24B | 整卡占用 | Q4_K_M，f16 KV，20,736 个缓存单元，flash attention koboldcpp 1.88, RTX 4090 24GB | 18.59 GB | 17.60 GB 19.2 GB used − 1.6 GB desktop | +5.6% | 权重和缓存都与日志一致；差距来自我们的 0.5 GB + 10% 开销，约为 llama.cpp 单个请求在二者之外实际多用显存的 2–3 倍。 | github.com 2025-04-13 |
| Mistral Small 3.1 24B | 整卡占用 | Q4_K_M，q4_0 KV，20,736 个缓存单元，flash attention koboldcpp 1.88, RTX 4090 24GB | 16.09 GB | 15.20 GB 16.8 GB used − 1.6 GB desktop | +5.8% | 权重和缓存都与日志一致；差距来自我们的 0.5 GB + 10% 开销，约为 llama.cpp 单个请求在二者之外实际多用显存的 2–3 倍。 | github.com 2025-04-13 |
| Mistral Small 3.1 24B | 整卡占用 | Q4_K_M，f16 KV，41,216 个缓存单元，flash attention koboldcpp 1.88, RTX 4090 24GB | 22.03 GB | 20.60 GB 22.2 GB used − 1.6 GB desktop | +6.9% | 权重和缓存都与日志一致；差距来自我们的 0.5 GB + 10% 开销，约为 llama.cpp 单个请求在二者之外实际多用显存的 2–3 倍。 | github.com 2025-04-13 |
| Mistral Small 3.1 24B | 整卡占用 | Q4_K_M，q4_0 KV，57,600 个缓存单元，flash attention koboldcpp 1.88, RTX 4090 24GB | 17.83 GB | 16.50 GB 18.1 GB used − 1.6 GB desktop | +8.1% | 权重和缓存都与日志一致；差距来自我们的 0.5 GB + 10% 开销，约为 llama.cpp 单个请求在二者之外实际多用显存的 2–3 倍。 | github.com 2025-04-13 |
整卡的 4 条是报告者读到的显存占用减去其中 1.6 GB 桌面占用。Mistral Small 3.1 按不含视觉编码器的 235.7 亿参数计算，与报告中的纯文本 GGUF 相同；Gemma 2 9B 的结构取自其 config.json。其余模型用计算器的预设。
图像模型
Qwen-Image-2.1 计算器给出的是区间：精确的文件大小加上实测得出的工作显存。
| GPU | 设置 | 预测区间 | 实测 | 结果 | 来源 |
|---|---|---|---|---|---|
| RTX 3090 24GB | Qwen-Image-2.1：DiT GGUF Q4_K_M + 编码器 INT8 ConvRot + VAE BF16，全部在 GPU 上，1024×1024 ComfyUI | 15.35 GB–17.95 GB | 15.39 GB | 在区间内 | github.com 2026-09-21 |
| Apple M5 Max 48GB | Qwen-Image-2.1：DiT GGUF Q4_K_M；编码器、VAE 和图像尺寸未说明，按 BF16 编码器 + FP32 VAE、全部在统一内存中、1 MP 比较 Unsloth Desktop (macOS) | 23.60 GB–26.20 GB | 42.00 GB | 在区间外（实测更高） | github.com 2026-09-29 |
RTX 3090 24GB：落在区间内，靠近下限。区间本身就参考了这次实测，所以这更像一致性检查，而不是独立验证。
Apple M5 Max 48GB：在区间外：实测远高于预测，即使按最大的编码器和 VAE 计算也是如此。加载后的约 34 GB 接近 DiT 以 BF16 保存时的文件总量（编码器和 VAE 为 BF16 时为十进制 32.4 GB），而不是 Q4_K_M 文件的 22.4 GB，所以这条路径很可能把 DiT 反量化了，而计算器没有考虑这种情况。图像分辨率未知，引擎也尚未确认所用精度；即使把 42 GB 按十进制 GB 理解，也仍远高于区间。
更多实测和 8–16 GB 的低显存组合见 Qwen-Image 2.1 显存计算器。MiniMax H3 的公开实测大多在流式加载权重，显卡占满只说明显卡的容量，无法与估算比较，所以没有列入。
vLLM 的 KV cache 池以 token 计，和这里按字节比较的数据不同，所以放在 vLLM KV cache 计算器的日志对照表里：6 条公开启动日志。
哪里高估，哪里低估
- KV 缓存公式与 llama.cpp 逐字节一致，8/8 条。普通注意力的模型（Llama 3.1、Mistral Small、Gemma 2）在 f16 和 q4_0 下一直一致；Gemma 4 和 gpt-oss 自 2026-09-29 起也一致。
- 整卡总占用偏高 5.6%–8.1%。权重和缓存都对得上，差距全在开销：0.5 GB + 10% 在这里是 1.9–2.5 GB，而 llama.cpp 单个请求在权重和缓存之外实际只多用了 0.7–1.1 GB（计算缓冲区、CUDA 上下文等）。
- 2026-09-29 之前，Gemma 4 的 KV 缓存偏低 35.3% 和 54.3%。我们曾按“全局层的 V 与 K 相同，只存一份”计算，而 llama.cpp 仍然分配了单独的 V（K 经过 RoPE，V 单独做 RMS 归一化）；滑动窗口层还多出一个批次（512 token），并行槽位越多越大。这曾让部分“能放下”的结论偏乐观，现已修正，受影响的模型页、显卡页和“能不能跑”页面都已按新公式重新计算。
- GGUF 文件大小可能差 7.0% 到 +13.7%。按每权重位数估算，对 Llama 和 Mistral 很准，但 Gemma 4 的 Q4_K_M 平均 5.32 位，gpt-oss 的 GGUF 又把嵌入层存成了 Q8_0。有具体文件时，以下载大小为准。
- vLLM 加载后多出 5.6%。它报告的是加载后显存的实际增量，不只是权重文件。
我们打算怎么改
- 为 llama.cpp 单独给出开销：约 1 GB 固定值，而不是 0.5 GB + 10%。目前保留保守的默认值，因为 vLLM 和 CUDA Graph 确实需要更多。
为 Gemma 4 全局层计入单独的 V，并把滑动窗口按“窗口 × 槽位数 + 批次”计算。已于 2026-09-29 完成，全站计算器都已采用。- 对已知的 GGUF 文件直接使用下载大小，并为 Gemma 4 这类模型给出更接近实际的每权重位数。
- 支持 K 和 V 用不同类型（例如
-ctk q8_0 -ctv q4_0），这是计算器目前无法表示的设置。
2026-09-29 修正了 KV 缓存公式：Gemma 4 全局层的 K 和 V 分开计算，滑动窗口层按 llama.cpp 的规则取“窗口 × 槽位数 + 512”并向上取整到 256，但不超过上下文（src/llama-kv-cache-iswa.cpp）。上表的预测值是修正后的公式算出的；修正前 Gemma 4 12B 为 187 MiB，26B 为 2,625 MiB，gpt-oss-20b 为 771 MiB。其余几项还没有做，本页展示的是当前公式的真实表现；改动上线后，这张表会随之在构建时重新计算。
没有收录的报告
2026 年关于 Qwen3.8 27B 在 16 GB 显卡上运行的两篇报告（autodidacts.io，jrell 的 IQ4_XS 混合版）给出了量化、上下文和 KV 类型，但没有显存读数，只说明“能跑”。它们与本站估算不矛盾，但无法算出误差。有 nvidia-smi 读数或 llama.cpp 缓冲区日志的实测，欢迎联系我们（英文）。
提交一条实测
跑过某个模型？在 GitHub 上提交实测（英文表单）：填写模型、文件或量化、引擎和版本、GPU、-c、并行槽位数和 KV 类型，并粘贴原始日志行，例如 llama.cpp 的 KV buffer size、model buffer size，nvidia-smi 读数，或 vLLM 的 KV cache 行。每条都会人工核对，再和构建时的预测一起列入上表。
常见问题
ModelVRAM 的显存计算器有多准？
在 19 条公开实测中，中位绝对误差为 1.2%。KV 缓存公式在 8 条 llama.cpp 日志中有 8 条完全一致；权重的中位误差为 1.5%；整卡总占用偏高 5.6%–8.1%，因为 0.5 GB + 10% 的开销对 llama.cpp 单个请求来说偏保守。
计算器是高估还是低估？
整卡总占用全部高估（+5.6% 到 +8.1%）。低估的情况有：把更多张量保留为高精度的 GGUF 文件（Gemma 4 26B Q4_K_M −7.0%），以及 vLLM 加载 gpt-oss-120b 后的占用（−5.6%）。KV 缓存目前没有低估的条目；2026-09-29 之前，llama.cpp 中 Gemma 4 的 KV 缓存少算了 35.3% 和 54.3%，gpt-oss 滑动窗口层少算了 15 MiB，这两处已在当天修正。
为什么估算值和 nvidia-smi 读数不一样？
nvidia-smi 显示的是整张卡的占用，包括桌面、CUDA 上下文和引擎自己的预留：vLLM 会按 gpu_memory_utilization 占满显存，llama.cpp 会在启动时按完整上下文分配 KV 缓存。本页只比较能对上号的部分：日志里的 KV 缓冲区、模型缓冲区，以及扣除桌面占用后的整卡读数。
这些实测是怎么选的？
只收录公开、带来源链接、设置足够复现的报告（模型、量化文件、上下文、KV 类型、引擎）。所有来源都在 2026-09-29 重新打开核对过。只有设置、没有显存读数的报告没有收录。
来源核对于 。