量化详解:Q4 与 Q8 到底差多少?

更新于 2026-08-04 · 核实于 2026-08-04

量化让一个「需要 140GB」的模型能跑在 700 美元的显卡上。代价是什么?这篇文章讲清楚。

量化在做什么

模型的权重以数字形式存储。FP16 每个权重占 16 bit;量化把它们重新打包成 8、6、5、4、3 甚至 2 bit,并通过巧妙的分组(K 系量化)让最重要的权重保留更高精度。文件变小了,代价是损失一点保真度。

实测数字(Llama-3.1-8B GGUF)

量化档	文件体积	相对 FP16	质量评价
FP16	约 16.1 GB	100%	基准
Q8_0	8.5 GB	53%	几乎所有场景都无法区分
Q6_K	6.6 GB	41%	「显存有富余就选它」
Q5_K_M	5.7 GB	35%	优秀,困难任务有轻微损失
Q4_K_M	4.9 GB	30%	默认档——体积与质量的最佳平衡
Q3_K_M	4.0 GB	25%	可感知的劣化,仅应急
Q2_K	3.2 GB	20%	只能拿来玩,不能干活

怎么选

1. 从 Q4_K_M 开始。 它是社区默认档是有原因的:省约 70% 显存,盲测中大多数人在对话里无法稳定区分它和 FP16。
2. 显存富余就升到 Q6_K 或 Q8_0。 显卡轻松装得下 Q8 就用——尤其是数学、长依赖链代码、工具调用 Agent 这类小误差会累积的场景。
3. 只有在放不下时才降到 Q4 以下——并且宁可选小模型的 Q4,也不要大模型的 Q3/Q2。量化得当的 8B 胜过被压残的 13B。

KV 缓存这个变量

量化权重只是一半的故事。KV 缓存(模型对你对话内容的工作记忆)默认是 fp16,长上下文下可能超过权重本身。部分运行时支持 q8 KV 缓存,能把这部分占用减半且质量损失极小。上下文吃紧时,开 q8 KV 往往比降权重精度更划算——详见 KV 缓存指南。

速度加成

低精度不只是更小,还更快。Token 生成的瓶颈是显存带宽:每个 token 读 4.9GB 当然比读 8.5GB 快。同样的硬件上,Q4_K_M 的生成速度大约比 Q8_0 高 25–35%。

常见问题

来源

• 实测 GGUF 文件体积(bartowski,Hugging Face)
• llama.cpp 量化文档