27B 模型量化档位怎么选：Q4 不是万能解，16GB 显卡跑不动

一句话总结：27B 模型跑 Q4_K_M 要 16.1 GB 显存（8K 上下文），比大多数人以为的高。16GB 显卡差 1.4GB 跑不动，24GB 才是 Q4 的入门线，Q5 在 24GB 上只剩 2.8GB 余量。选档位不该看"哪个最省"，该看"你的卡在哪一档还有余量开上下文"。

上周有人问我：16G 的卡能不能跑 27B 的 Q4。

我说能。他跑了一下，爆显存。

后来我算了才发现，我自己也记错了。27B 的 Q4_K_M 加上 8K 上下文的 KV cache，总共 16.1 GB。16GB 的卡实际可用大约 14.7GB（要留 8% 给驱动和运行时），差 1.4GB。

Q4 是给 24GB 卡准备的，不是给 16GB 的。

这件事值得写清楚，因为网上传的"16G 能跑 27B"基本都省略了上下文长度，或者用的是更激进的量化。

一、量化档位与显存怎么匹配：先看这张矩阵

图 1：绿色能跑，黄色勉强，红色跑不动。红圈那格是最容易踩的坑

这张表是按"权重 + KV cache"算的，上下文统一 8K。

先说口径。权重部分用的是常见 GGUF 档位的有效位宽（含缩放因子的开销），不是标称位数：

KV cache 按 64 层、GQA 8 个 KV 头、head_dim 128、FP16 存的假设算，8K 上下文是 2.0 GB。

这里有个细节容易忽略：KV cache 的大小由架构决定，不由量化档位决定。 你把权重量化到 4 bit，KV 还是 FP16（除非单独做 KV 量化）。所以档位越低，权重省得越多，但 KV 那部分一分不省。

二、16G 到 80G：四种显存档位的实际情况

把矩阵翻译成人话。

16GB 卡（4080、4060Ti 16G、M 系列统一内存 16G）

Q3_K_M 勉强（14.3 GB，可用 14.7 GB，余量 0.4 GB），Q4_K_M 跑不动（差 1.4 GB）。

想在 16G 上跑 27B，只有两个选择：降到 Q3，或者把上下文压到 2K。

压到 2K 的话 Q4 是 14.1 + 0.5 = 14.6 GB，刚好卡在可用线下面——但一点余量都没有，跑起来随时可能 OOM。

24GB 卡（4090、3090、7900XTX）

Q4_K_M 能跑，剩 5.9 GB。这 5.9 GB 就是你能开多少上下文的预算：

Q4_K_M 权重 14.1 GB + 24G 卡可用 22.1 GB
剩 8.0 GB 给 KV -> 约 32,503 token

32K 上下文是 24GB 卡上的实际甜点。 想上 128K，KV 要 32 GB，整机显存得 46 GB 以上。

Q5_K_M 在 24G 上只剩 2.8 GB，上下文只能开到 8K 左右。Q6_K 直接跑不动。

48GB 卡（A6000、双 3090）

Q4 到 Q8 全能跑，Q6 有 21 GB 余量。这个档位是为长上下文准备的，128K 上下文的 Q4 是 46.1 GB，刚好卡进来。

80GB（H100、A100 80G）

唯一能跑 FP16 的档位。52.3 GB 加余量，还能留出不少给批量推理。

三、Q4_K_M 为什么成了默认答案，又为什么不对

Q4_K_M 被推荐得多，有它的道理：

体积和质量的比例最划算。 从 FP16 压到 Q4，体积降到 28%，而大多数任务上的质量损失在可接受范围。再往下压到 Q3，质量会明显掉。

几乎所有推理框架都支持。 llama.cpp、Ollama、LM Studio 的默认档位都是它。

但"默认"不等于"适合你"。两种情况要改：

卡在 16GB 以下，Q4 就是跑不动。 这时候不是硬上 Q4，是换更小的模型，或者接受 Q3 的质量损失。

需要长上下文，Q4 的余量不够。 24GB 卡上 Q4 的 5.9 GB 余量只够 32K。要 128K，要么换 Q3（权重省 1.8 GB，还是不够），要么上更大显存的卡。量化换不来长上下文，只有显存能。

四、量化档位与质量：你愿意付多少

我这篇只算了显存，没算质量。原因很简单：质量损失没有通用答案，跟你做的事强相关。

大概的规律是这样（定性，非实测）：

• Q8 到 FP16：差别极小，除非做数值敏感的任务
• Q6 到 Q8：多数任务感知不到
• Q5 到 Q6：代码生成、数学推理这类任务开始有差异
• Q4 到 Q5：明显的分界，Q4 在长链推理上会掉
• Q3 及以下：能用，但别指望它做复杂推理

所以合理的选法是反过来的：先确定你的任务需要哪一档质量，再看这张卡能不能装下。

要跑代码 Agent，Q5 起步。要做摘要和分类，Q4 够。要在 16G 上跑，Q3 加更小的模型可能比 27B 的 Q4 更划算。

五、KV cache 量化：一个被低估的省法

前面说 KV cache 不随权重量化变小。但其实 KV 也可以量化。

8K 上下文的 KV 是 2 GB（FP16）。如果 KV 量化到 8 bit，变 1 GB；4 bit 变 0.5 GB。

对 24GB 卡跑 32K 上下文来说：FP16 KV 要 8 GB，8 bit KV 只要 4 GB，4 bit 只要 2 GB。

这意味着 24GB 卡跑 Q4 + 4bit KV，上下文能从 32K 拉到 128K 附近。

代价是精度。KV 量化对长上下文的影响比权重量化更敏感，因为它直接影响注意力权重的计算。具体损失多少，跟模型和任务都有关，得自己测。

站内之前算过8GB 显存跑 128K 的方案，那条路走的是卸载（把 KV 放到内存），和这里是两条不同的路：一个用空间换，一个用精度换。

还有一篇算27B 配 262K 上下文的内存账，结论和这篇一致：长上下文的瓶颈永远是 KV，不是权重。

六、27B 量化选型常见问题

同一个档位，为什么不同模型的体积不一样？

GGUF 的有效位宽是平均值，实际取决于张量类型分布。embedding 层和输出层通常量化得更保守，attention 层可以更激进。所以 27B 的 Q4 在不同模型上会差几百 MB。

Q4_K_M 和 Q4_K_S 差多少？

M 是 medium，S 是小。同档位下 S 更小（约少 5%），质量略低。资源紧张时选 S。

显存够了但速度很慢，为什么？

显存够只代表装得下，不代表跑得快。如果部分层被卸载到内存，速度会掉一个数量级。用 nvidia-smi 看显存占用是不是接近满，接近满说明有卸载。

能不能混着来，重要的层用高精度？

可以，GGUF 支持按张量指定类型。但手动配很麻烦，收益也不大，一般不建议折腾。

Apple Silicon 的统一内存怎么算？

可以按同样逻辑算，但要注意 macOS 会限制 GPU 可用内存（默认约为总内存的 75%）。32GB 的 Mac 实际能用的显存约 24GB。

七、边界

这是计算，不是实测。 所有数字按公式推的，没有真机跑过。实际占用会因为有卸载、框架开销、CUDA context 而偏高，通常高 0.5 到 1 GB。

KV 的假设可能和你的模型不符。 我按 64 层、8 个 KV 头算。如果你的模型用 MHA（每个 head 都有独立 KV），KV 会大 4 到 8 倍，整套数字要重算。

质量那部分是定性判断，没有 benchmark 支撑。 我说"Q4 在长链推理上会掉"是基于普遍经验，不同模型差异很大。真要选档位，正确做法是拿你自己的任务跑一遍对比。

"能跑"的标准我定得偏保守。 留了 15% 余量。有人会把余量压到 5%，那样 16G 卡确实能挤进 Q4——代价是一开长上下文就崩。

档位名称各家不完全统一。 这里用的是 llama.cpp 的 GGUF 命名，其他框架的 Q4 可能不是同一个东西。

参考资料

• llama.cpp 量化文档
• Hugging Face - GGUF 模型格式说明
• vLLM - 量化支持列表