显存 / 内存计算器
精确计算任意模型 × 量化 × 上下文长度的内存需求
选择模型,查看是否能在你的硬件上运行
KV 缓存类型
f16 是 llama.cpp 和 Ollama 的默认值。
在上方选择模型和量化格式以查看内存估算
按模型规模速查
本索引每个规模档位的计算结果,按各模型的基准量化(官方原生版本,否则 Q4_K_M)、batch 1 计算 —— 与上面的计算器是同一套算法,写成表格,不用它也能直接看。32K 一列只统计原生上下文窗口达到 32K 的模型。最后一列是 4K 上下文下能从容装下该档位全部模型的最小显卡。
| 规模档位 | 模型数 | 4K 上下文 | 32K 上下文 | 能装下整个档位 |
|---|---|---|---|---|
| ≤3B | 10 | 0.4–4.1 GB | 0.7–15.6 GB | Mac M1 8G |
| 7B | 15 | 3.0–6.8 GB | 3.2–10.9 GB | RTX 4060 (8 GB) |
| 14B | 11 | 7.3–10.2 GB | 10.4–15.9 GB | RTX 3060 12G |
| 32B | 21 | 12.8–30.4 GB | 13.5–31.6 GB | A100 40G |
| 70B+ | 14 | 46.1–428.7 GB | 55.7–436.4 GB | 没有单卡能装下 —— 需拆分或卸载 |
这个估算是怎么算出来的
三项相加。模型权重 = 参数量 × bpw ÷ 8,再加 2%,用于覆盖多数量化器保持较高精度的 embedding 与 norm 张量。KV 缓存 = 2(K 和 V)× 层数 × kv_heads × head_dim × 上下文 × batch × 每个值的字节数:默认 fp16 缓存为 2 字节;选择量化缓存时按 ggml 的块大小计算 —— q8_0 每 32 个值占 34 字节,q4_0 占 18 字节。激活缓冲取前两项之和的 10%,对应推理运行时每次前向分配的临时张量。单位:所有数字都以二进制 GB(GiB,1024³ 字节)计算并显示,但标注为 "GB" —— 与显卡厂商和 nvidia-smi 标注显存的方式一致。工具内部不存在两种单位之间的换算。选中索引内的模型时,计算器使用该模型自身实测的 bpw,而不是通用档位表 —— 两者可能相差很大:GPT-OSS 权重多为原生 MXFP4,其 Q8_0 实际是 5.10 bpw 而非 8.5。
为什么上下文长度比你以为的更关键
选定量化档位后权重就固定了,KV 缓存不会。它随上下文长度和 batch 线性增长,在长上下文模型上甚至会超过权重本身。决定这条曲线陡峭程度的是分组查询注意力(GQA):kv_heads 往往远小于注意力头数。Llama 3.1 8B 有 32 个注意力头,但只有 8 个 KV 头,因此缓存只有多头注意力的四分之一。两个体量相同的模型可能有完全不同的显存曲线 —— 所以本计算器从每个模型真实的 config 读取 layers、kvHeads、headDim,而不是假定一个通用形状。
与实测差多少
Llama 3.1 8B 在 Q4_K_M 下估算为 4.62 GB,而 bartowski 的实际文件为 4.58 GiB —— 足以据此决定买哪张卡。但它仍然是估算。不同运行时的预留差异很大:llama.cpp 的计算缓冲随 batch 与上下文增长,vLLM 会按固定比例预占显存(--gpu-memory-utilization,本站生成的命令默认 0.85),而 CUDA 本身在任何权重加载前就要占掉几百 MB 上下文。裁决颜色已经把这些考虑进去 —— 绿色表示估算占用不超过显存的 88%,琥珀色到 105%,因此绿色结果本身就留有余量。
常见问题
- 这个数字包含系统和显示占用吗?
- 不包含。它估算的是模型自身的需求。如果这张卡同时在驱动显示器,比较前请先扣掉约 0.5–1.5 GB —— 这也是绿色阈值定在 88% 而非 100% 的原因之一。
- 为什么同一个量化档位在不同模型上体积不同?
- 因为 bpw 是一套混合方案的平均值。
Q4_K_M会把部分张量保持在更高精度,具体比例取决于架构 —— 大部分参数位于专家层的 MoE 模型,量化结果与稠密模型不同。如果索引里的模型实际提供了该档位,计算器会用它的实测值而非通用值。 - 显示琥珀色的模型能跑吗?
- 通常可以,办法是降低上下文、减小 batch,或量化 KV 缓存 —— 三者都直接压缩缓存。选好你的显卡后,计算器会直接给出保持绿色的最长上下文和保持琥珀色的最长上下文。如果短上下文下仍是琥珀色,那说明问题出在权重本身,需要换更低的量化档位;「全部量化档位」表会告诉你哪一档装得下。
- 模型比我的显卡还大怎么办?
- 有两种办法,计算器两种都会算。加一张卡:llama.cpp 默认按层拆分,每张卡放一段层及其 KV 缓存,所以显存可以相加——Llama 3.3 70B 在 Q4_K_M、8K 上下文时为 47.5 GB,一张 RTX 3090 装不下,两张勉强装下。各卡轮流处理每个 token,所以第二张卡换来的是空间,不是速度。溢出到系统内存:llama.cpp 和 Ollama 会把放得下的整层留在 GPU 上,其余交给 CPU。单张 RTX 3090 大约能放下 80 层中的 38 层,约 25 GB 放在系统内存,而内存那一半决定速度——双通道 DDR5-5600 下上限约 4 tok/s。混合专家模型可以用
--n-cpu-moe只搬走专家权重,速度损失通常小得多。 - 要不要量化 KV 缓存?
- 长上下文下,这是最便宜的省显存手段。Llama 3.1 8B 在 Q4_K_M、32K 上下文时,默认 fp16 缓存为 9.49 GB,q8_0 为 7.42 GB,q4_0 为 6.32 GB —— 权重不变,变的只是缓存。llama.cpp 用
-ctk q8_0 -ctv q8_0;量化 V 缓存需要 Flash Attention,-fa auto会自动开启,强制关闭则会报错。Ollama 在开启 Flash Attention 后设置OLLAMA_KV_CACHE_TYPE=q8_0。按 Ollama 官方文档的说法,q8_0 通常察觉不到差别,q4_0 有小到中等的精度损失、长上下文时更明显;本站没有实测过两者。 - 反向模式有什么不同?
- 正向模式回答「这个模型能装进我的卡吗」。反向模式从显卡出发,列出索引中所有能装下的「模型 × 量化档位」组合,可按质量、速度或占用排序。两者使用同一套按模型的实测数据,因此结论一致。
- 这些数字是实测还是估算?
- 显存数字是计算得出,不是实测。模型索引中每个量化档位的
vramGB与速度值都带有可信度标记 —— 实测、估算或社区数据;基准页面记录了实测数据背后的硬件与框架版本。