GPU 显存计算器(本地大模型)
7B 模型用 4 位量化,权重约 3.3 GiB;Llama 3.1 8B 级别的模型每 8,192 token 上下文还会多出约 1 GiB 的 KV 缓存。
使用方法
- 选择一个模型预设,参数量、层数、KV 头数和头维度会自动填入。想自己填,就选"自定义",再输入模型 config.json 里的数值。
- 设置权重的量化位数(Q4 填 4,FP16 填 16)和 KV 缓存精度。
- 输入上下文长度(token 数)和批大小,也就是同时处理的序列数。
- 查看总量,以及权重、KV 缓存、额外开销的拆分。表格会显示它能放进哪些常见显存的显卡。
计算方法
权重显存 = 参数量 × 位数 ÷ 8 字节。70 亿参数的模型用 4 位,是 7,000,000,000 × 0.5 = 3.5 GB,即 3.26 GiB。16 位则是 14 GB,与 Hugging Face 指南"Optimizing LLMs for Speed and Memory"里 bfloat16 下每十亿参数约 2 GB 的经验值一致。
KV 缓存 = 2 × 层数 × KV 头数 × 头维度 × 上下文长度 × 批大小 × 每个值的字节数。2 代表键和值。Hugging Face 博客"Unlocking Longer Generation with Key-Value Cache Quantization"给出了 16 位数值下每个 token 的算法:2 × 2 × 层数 × KV 头数 × 头维度。
额外开销按"权重加 KV 缓存"的百分比输入,用来代替 CUDA 上下文、激活缓冲区和显存碎片。默认的 10% 是假设值,不是实测值。
所有结果都以 GiB 为单位(1 GiB = 1,073,741,824 字节)。显卡厂商把 24 GiB 的卡标成"24 GB",所以适配表直接用总量与 8、12、16、24、48、80 比较。这只是估算,实际占用会随框架(llama.cpp、vLLM、Ollama、Transformers)、内核和缓存分配方式而变化。
显存被什么占用
主要有两项。权重在模型和量化确定后就固定了。KV 缓存则随上下文里的每个 token、批里的每条序列增长,所以上下文一长或并发用户变多,原本放得下的模型会突然放不下。
采用分组查询注意力(GQA)的模型,KV 头比注意力头少,缓存能缩小好几倍。因此 KV 头数比注意力头数更重要。请在模型的 config.json 里查看 num_key_value_heads。
每十亿参数的权重大小
| 每个权重的位数 | 每 10 亿参数的 GiB | 示例:8B 模型 |
|---|---|---|
| 16 (FP16 / BF16) | 1.86 | 14.90 GiB |
| 8 (INT8 / Q8) | 0.93 | 7.45 GiB |
| 6 (Q6) | 0.70 | 5.59 GiB |
| 5 (Q5) | 0.58 | 4.66 GiB |
| 4 (Q4) | 0.47 | 3.73 GiB |
| 3 (Q3) | 0.35 | 2.79 GiB |
| 2 (Q2) | 0.23 | 1.86 GiB |
预设数据来源
- 各仓库的 config.json:huggingface.co/Qwen/Qwen2.5-{7B,14B,32B,72B}, huggingface.co/Qwen/Qwen3-{8B,32B}, huggingface.co/mistralai/Mistral-7B-v0.3, huggingface.co/mistralai/Mistral-Nemo-Base-2407, huggingface.co/microsoft/phi-4。
- Llama 3.1 8B 和 70B:Meta 的 config.json 在 Hugging Face 上需要申请授权,因此数值取自 Meta 论文"The Llama 3 Herd of Models"(arXiv 2407.21783)的表 3。Gemma 2 9B 和 27B:取自 Google 报告"Gemma 2"(arXiv 2408.00118)的表 1。
- 参数量是 Hugging Face API 为每个仓库显示的 safetensors 总数。config.json 里没有 head_dim 时,使用 hidden_size ÷ 注意力头数。
常见问题
7B 模型 4 位量化需要多少显存?
仅权重就约 3.3 GiB。Llama 3.1 8B 级别的模型在 8,192 token 上下文下,KV 缓存再加约 1 GiB,算上额外开销大约 5 GiB。8 GB 的显卡能跑,还有余量加长上下文。
24 GB 的显卡能跑 32B 模型吗?
4 位量化可以。Qwen2.5 32B 约有 327.6 亿参数,权重约 15.3 GiB。在 8,192 token 上下文下,KV 缓存是 2 GiB,加上 10% 的额外开销,总量约 19 GiB。
实际占用为什么和估算不一样?
各框架的额外开销不同。vLLM 会预先把大部分显存划给 KV 缓存,空间不足时抢占请求;llama.cpp 一开始就按完整上下文分配缓存;GGUF 的 K-quant 还要额外存储缩放值,所以实际位数比标称的高。遇到显存不足,可以调高位数或额外开销。
混合专家(MoE)模型能用吗?
权重仍要全部放进显存,所以要填总参数量,不是激活参数量。KV 缓存只取决于注意力层,所以使用 config 里的层数和 KV 头数。这里的预设都是稠密模型。
Gemma 2 用了滑动窗口,估算值会更低吗?
Gemma 2 交替使用窗口为 4,096 token 的局部层和全局层。本工具对所有层都按完整上下文计算,所以上下文超过窗口时,对 Gemma 2 给出的是上限。