Quantization量化
把模型参数的数值精度降下来(比如 FP16 降到 INT4),换更小的体积和更快的速度
量化(Quantization)是把模型权重(有时还包括激活值)从高精度浮点数转成低精度表示的过程,比如从 16 位浮点降到 8 位或 4 位整数。目的很直接:模型变小、显存占用下降、推理变快。
为什么能这么干
神经网络对参数精度的容忍度出乎意料地高。权重数值的微小偏差,在成千上万次运算的平均效应下,对最终输出的影响远小于直觉预期。这给了压缩空间——但空间是有限的,压过头模型会明显变笨。
一个粗略的换算:一个 70 亿参数的模型,FP16 大约需要 14GB 显存,量化到 INT4 大约降到 4GB 上下。这就是消费级显卡能跑本地大模型的直接原因。
常见精度档位
- FP16 / BF16:训练和高精度推理的常用格式,通常被视作质量基线。
- INT8 / FP8:精度损失通常很小,是服务端推理性价比很高的一档。
- INT4:体积和显存下降最明显,质量有可感知的损失但很多场景可接受。本地部署最常见的一档。
- 更低(3 位、2 位):损失开始显著,一般只在特定研究或极端受限场景使用。
两条技术路线
- 训练后量化(PTQ):模型训完直接转格式,可能用少量校准数据确定缩放系数。成本极低,几分钟到几小时,是绝大多数场景的选择。
- 量化感知训练(QAT):训练过程中就模拟低精度的影响,让模型主动适应。质量更好,但要重新训练,成本高得多。
损失会掉在哪里
量化的损失分布很不均匀,这是最容易踩坑的地方:
- 日常对话、摘要、改写几乎察觉不出差别。
- 数学、代码、长链条推理掉得最明显——这些任务对每一步的精确性敏感,误差会累积。
- 长上下文下的表现衰减通常比短上下文更严重。
- 小模型比大模型更不耐量化。同样降到 4 位,70 亿参数的模型损失比几百亿参数的明显。
所以评估量化模型,不能只跑几句闲聊看"感觉还行",要在你的真实任务上跑评测集对比。
实践建议
- 优先选官方或社区已验证的量化版本,而不是自己随手转一个。校准数据和方法对结果影响很大。
- 服务端先试 INT8/FP8,通常损失可忽略而收益实在;INT4 留给显存确实吃紧的场景。
- 本地部署看清格式。GGUF 等格式内部还分很多量化档,同一个模型不同档位差别很大。
- 量化解决显存和速度,不解决能力。一个量化后的大模型和一个未量化的小模型,该选哪个要实测,没有普适答案。
常见误解
"量化会让模型变笨"——说得太粗。在合适的档位和任务上损失可以忽略;但在推理密集型任务上确实会掉。结论必须来自你自己的评测。
什么时候会用到
本地部署、端侧推理、降低 GPU 成本时的必备手段。
例句
- 这卡显存不够,得用 INT4 的版本,聊天场景基本感觉不出差别。
- 量化后代码和数学掉得最明显,闲聊测不出来,得跑真实任务。
- 别自己随手转一个,用官方或社区验证过的量化版本。
别混淆
别拿闲聊几句就判断量化「没损失」。损失集中在数学、代码和长推理上,要在真实任务的评测集上比。