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 的版本,聊天场景基本感觉不出差别。
  • 量化后代码和数学掉得最明显,闲聊测不出来,得跑真实任务。
  • 别自己随手转一个,用官方或社区验证过的量化版本。

别混淆

别拿闲聊几句就判断量化「没损失」。损失集中在数学、代码和长推理上,要在真实任务的评测集上比。

相关词