> GGUF 显存计算器：下载前先算清楚▋

ggml_backend_cuda_buffer_type_alloc_buffer: failed to allocate 3412 MiB。文件下载得好好的，显卡从一开始就装不下——而能预判这一点的算术，一张收据背面都写得下。常见的流程是反着来的：先点下载，盯着进度条，让显存不足的报错替你做算术。今天这个工具拒绝的就是这个顺序。GGUF 显存计算器上线了：输入参数量、量化等级和上下文长度，输出权重、KV 缓存以及常见显卡的逐档判定；也可以反过来，从显存预算推出装得下的最高量化。全部在你的浏览器里运行，什么都不上传。它加入了 本地跑 LLM 这个集群的枢纽页。

它有两种模式，因为问题有两种问法：

• "这个模型要多少显存？"——输入参数量、量化、上下文、架构；输出明细和 6 到 96 GB 的逐档判定表。
• "我的显存能装下什么？"——输入预算、模型大小、上下文；输出 Q2_K 到 F16 每个量化各自的判定。

一个 GGUF 模型需要多少显存？

永远是同样三块：

显存 ≈ 权重 + KV 缓存 + 开销
权重    = 参数量 × 每权重比特数 / 8
KV 缓存 = 2 × 层数 × kv_dim × 上下文 × 2 字节   (f16)
开销    ≈ 0.7 GB CUDA/运行时 + ~5% 计算缓冲

算一个最常见的例子：8B 模型，Q4_K_M，32k 上下文。权重：8 × 4.85 / 8 = 4.85 GB。KV 缓存：2 × 32 层 × 1024 kv-dim × 2 字节 = 每 token 128 KB × 32,768 = 4.0 GB。加上开销：总计约 9.8 GB——人人嘴里"8 GB 卡能跑"的 Q4 8B，上下文一拉长就超出 8 GB 卡 23%。从来不是量化的错，是上下文。这个故障模式有一篇单独的现场笔记，因为 offload 时它连系统内存一起吃。

我的显卡能装下哪个量化版本？

模式 2 存在的理由是：人们真正手里的问题是反过来的——显卡固定，模型在心里。7B、4096 上下文、8 GB 预算，算出来就是这样：

量化	权重	总计（估）	判定
Q4_K_M	4.24 GB	~5.7 GB	装得下，有余量
Q6_K	5.77 GB	~7.3 GB	勉强
Q8_0	7.44 GB	~9.0 GB	部分卸载到 CPU，慢得多

一屏，论坛上吵了多年的"Q4 还是 Q8"就归结成你的硬件给出的答案，而不是隔壁网友的。

这些数字从哪里来

每权重比特数表来自 llama.cpp 的 ggml 量化格式——Hugging Face 上那些文件就是按同样的数字压出来的：

量化	bpw	量化	bpw
Q2_K	3.35	Q5_K_M	5.69
Q3_K_M	3.91	Q6_K	6.59
IQ4_XS	4.25	Q8_0	8.50
Q4_K_M	4.85	F16	16.0

KV 缓存那一半用的是各个模型家族的公开几何结构。分组查询注意力（GQA）是全部关键：Llama-3 一类的 8B 是 8 个 KV 头 × 128 维 × 32 层，即每 token 128 KB——而没有 GQA 的 Llama 2 13B 每 token 要烧 640 KB，多五倍，还是上一代的模型。架构下拉框覆盖四种常见形态，再加一个自定义模式，能读 config.json 就能填。

文件大小告诉你的只是会下载什么。它从来没告诉过你跑不跑得起来。

估算故意忽略的东西

三样，故意的。MoE 路由：推理只碰被激活的专家，但这个工具按全部权重计价，所以 MoE 的总数会偏高。混合量化：Q4_K_M 本身就是各张量的平均值，真实文件会落在表格值上下几个百分点。还有 CUDA 侧的填充随后端版本变化——固定的 0.7 GB 是个中间值，不是物理常数。当一个决定值好几百 MB 的时候，跳过估算，直接用 llama.cpp 的 gguf_dump.py 读文件头——读头的计算器干的就是这件事。这个工具坚持只做算术：三个输入你能手算复核，判定结果你可以跟它争。

工具在 github.com/mrsaynothing/gguf-vram-calculator——一个 HTML 文件，零依赖，零构建。它和本地跑 GGUF 指南、llama.cpp vs Ollama、本地编程模型精选放在一起，服务端那一面见vLLM 能读 GGUF 吗。

如果判定和你的加载时间对不上，带着模型、量化和上下文去仓库开个 issue——这张表应该经得起真实硬件的检验，对不上的每一行都该修。