模型量化入门：INT8、INT4、GPTQ 与 AWQ

学习目标

读完这篇文章后，你应该能：

理解量化为什么几乎总是部署阶段的重要选项。
区分 INT8、INT4、GPTQ、AWQ 各自更适合解决什么问题。
判断量化节省的是权重、激活还是缓存，以及副作用在哪里。
面对一个具体模型时，给出“先不先量化、量到几 bit、用哪条路线”的基本判断。

这篇教程不是底层数值分析课，而是面向工程实践的第一性原理导览。

为什么量化会成为部署里绕不过去的话题

大模型部署的成本主要来自三类资源：

模型权重占用
KV Cache 占用
计算和访存带宽

当模型很大、并发很多、上下文很长时，单纯使用 FP16 或 BF16 往往意味着：

显存不够
单机承载并发有限
成本过高

量化的核心思路，就是用更少的 bit 表示数值，从而降低存储和访存压力。直观上可以理解为：

FP16：每个数 16 bit
INT8：每个数 8 bit
INT4：每个数 4 bit

bit 数越低，越省空间；但 bit 数越低，信息损失风险也越大。所以量化从来不是“免费午餐”，而是资源与精度之间的折中。

先分清：你到底在量化什么

讨论量化时，最容易混淆的是对象。实际上，量化可以发生在不同部分：

权重量化：把模型参数压缩成低比特
激活量化：把中间激活值也压低比特
KV Cache 量化：把推理缓存以更低精度存储

实际部署里最常见、风险相对可控的是权重量化，因为：

权重静态不变，便于离线校准
工程链路更成熟
收益非常直接

激活和 KV Cache 的量化同样重要，但对稳定性和运行时支持要求更高。

这里最容易混的两件事，其实可以拆开看：一是“量化对象是谁”，二是“量化发生在训练后还是训练中”。

  <rect x="34" y="76" width="912" height="174" rx="24" fill="#f9fafb" stroke="#e5e7eb" />
  <text x="58" y="108" font-size="20" font-weight="700">一、量化对象</text>

  <g>
    <rect x="58" y="126" width="250" height="104" rx="18" fill="#e8f1ff" stroke="#98b7e1" />
    <text x="183" y="156" text-anchor="middle" font-size="20" font-weight="700">权重量化</text>
    <text x="183" y="181" text-anchor="middle" font-size="13" fill="#4b5563">最常见、最稳妥的第一步</text>
    <text x="183" y="202" text-anchor="middle" font-size="13" fill="#4b5563">主要收益：模型更容易装进显存</text>
  </g>

  <g>
    <rect x="364" y="126" width="250" height="104" rx="18" fill="#eef6e8" stroke="#a8c48e" />
    <text x="489" y="156" text-anchor="middle" font-size="20" font-weight="700">激活量化</text>
    <text x="489" y="181" text-anchor="middle" font-size="13" fill="#4b5563">进一步压缩运行时张量</text>
    <text x="489" y="202" text-anchor="middle" font-size="13" fill="#4b5563">风险：动态分布更难校准</text>
  </g>

  <g>
    <rect x="670" y="126" width="250" height="104" rx="18" fill="#fff4dc" stroke="#e2c36f" />
    <text x="795" y="156" text-anchor="middle" font-size="20" font-weight="700">KV Cache 量化</text>
    <text x="795" y="181" text-anchor="middle" font-size="13" fill="#4b5563">面向长上下文与高并发瓶颈</text>
    <text x="795" y="202" text-anchor="middle" font-size="13" fill="#4b5563">风险：decode 稳定性与实现支持</text>
  </g>

  <rect x="34" y="278" width="912" height="112" rx="24" fill="#f6f9ff" stroke="#d7e2f1" />
  <text x="58" y="310" font-size="20" font-weight="700">二、量化路线</text>

  <g>
    <rect x="88" y="328" width="276" height="42" rx="14" fill="#e8f1ff" stroke="#98b7e1" />
    <text x="226" y="354" text-anchor="middle" font-size="18" font-weight="700">PTQ：模型训练完以后再量化</text>
  </g>
  <g>
    <rect x="614" y="328" width="276" height="42" rx="14" fill="#eef6e8" stroke="#a8c48e" />
    <text x="752" y="354" text-anchor="middle" font-size="18" font-weight="700">QAT：训练时就模拟量化误差</text>
  </g>

  <line x1="364" y1="349" x2="614" y2="349" stroke="#5b6b7f" stroke-width="3" marker-end="url(#quant-arrow)" />
  <text x="489" y="336" text-anchor="middle" font-size="13" fill="#64748b">训练成本更高，但潜在精度更稳</text>
</g>

工程上通常先用 PTQ 解决“装不装得下”和“吞吐能不能接受”，再决定是否值得为更高精度引入 QAT。

INT8 是很多团队的第一站

INT8 量化之所以普及，很大程度上是因为它在“压缩收益”和“精度可接受性”之间比较平衡。

它的优势包括：

相比 FP16，理论上权重占用减半
数值损失通常相对可控
框架和硬件支持相对成熟

它的局限也很明确：

对一些极大模型来说，INT8 仍然不够省
某些对精度很敏感的任务可能仍有退化
如果硬件或推理框架支持不佳，速度收益不一定显著

所以 INT8 常常是“稳妥路线”，但不是资源最省路线。

INT4 为什么吸引人

INT4 的诱惑非常大，因为它比 INT8 还能再节省一半空间。对 7B、14B、32B 这类模型来说，能不能压到 4-bit，往往直接决定它是否能在特定设备上跑起来。

但 4-bit 的难点也更明显：

可表示范围更小
某些层对误差更敏感
不恰当的量化策略容易让回答明显变差

因此，INT4 通常更依赖精细的后训练量化方法，而不是简单粗暴地统一缩放。

后训练量化和量化感知训练有什么区别

这两个词很容易一起出现：

后训练量化（PTQ）

模型先训练好，再做量化。优点是成本低、部署方便，不需要重新训练底座模型。

量化感知训练（QAT）

训练过程中就模拟量化误差，让模型逐步适应低比特表示。优点是潜在精度更好，缺点是实现复杂、训练成本更高。

在 LLM 场景里，很多团队优先接触到的是 PTQ，因为它更适合开源模型部署与快速验证。

GPTQ 在解决什么问题

GPTQ 可以粗略理解为一种面向大模型权重的后训练量化方法。它的核心吸引力在于：

重点关注量化后对输出误差的影响
通过逐层近似修正，尽量减少性能损失
特别适合把大模型压到 4-bit 附近

工程上你可以这样理解 GPTQ：

它不是只看“怎么压缩”
而是在问“压缩后误差怎么尽量不伤输出”

所以 GPTQ 往往适合“我想把模型压得比较狠，同时还希望保住主要能力”的场景。

AWQ 为什么也很常见

AWQ（Activation-aware Weight Quantization）这个名字已经点出了它的思路：量化时会考虑激活分布对重要权重的影响。

它的实践价值在于：

对关键通道更谨慎
在很多模型上表现出不错的精度保持能力
在部署社区里工具链逐渐成熟

如果把它和 GPTQ 粗略对比，可以这样记：

GPTQ：偏“误差补偿与逐层近似”
AWQ：偏“结合激活信息，保护关键权重”

真实选择时，不要把它们当成绝对优劣，而是看：

你的模型类型是否有成熟支持
你的推理框架是否直接兼容
你的任务是否对精度特别敏感

量化并不只影响“能不能放下”，还影响“跑得顺不顺”

很多人只从显存角度理解量化，但它还会影响：

访存压力
吞吐
加载速度
单机并发能力

不过也要注意：低比特不必然意味着更快。如果硬件内核、推理框架、算子实现没有充分优化，你可能会看到：

显存省了
速度却没有明显提升

所以部署评估时，至少要同时看三件事：

内存占用
tokens/s
任务精度

一个最小实验路线

如果你想自己动手做第一轮量化实验，可以用下面这个顺序：

先跑一份 FP16 或 BF16 基线。
再试 INT8，观察显存和质量变化。
如果目标是更大压缩比，再试 GPTQ 或 AWQ 的 4-bit 版本。
用同一批评测样本，比较延迟、吞吐和回答质量。

这个顺序的好处是：你始终知道“退化是从哪一步开始发生的”。

一个最小代码示例

如果只是快速验证 8-bit/4-bit 加载路线，可以先从 bitsandbytes 风格的方式入手：

from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

model_name = "Qwen/Qwen2.5-7B-Instruct"

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype="bfloat16",
)

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    quantization_config=bnb_config,
    device_map="auto",
)

这类方式的价值在于“上手快”，适合先验证模型能否以低比特稳定运行。若你要做面向生产的高吞吐部署，通常还需要进一步结合具体推理框架，例如 vLLM 或 TGI。

量化与 LoRA、QLoRA 的关系

量化不只用于推理，也常与微调结合。最典型的例子就是 QLoRA：

底座模型以低比特加载
训练时仍通过 LoRA 学少量适配参数
以更低显存完成 SFT

所以量化并不只是“部署结束动作”，也能成为训练阶段的资源解法。如果你想把这部分打通，可以结合阅读 LoRA 微调实战。

什么时候不该急着量化

虽然量化很有吸引力，但下面几种情况要谨慎：

你连 FP16 基线都没有建立。
任务非常依赖细粒度数值精度，例如复杂推理、代码生成或小差异分类。
你的推理框架对某条量化路线支持不成熟。
你当前瓶颈根本不在权重，而在 KV Cache、I/O 或请求调度。

量化是强工具，但前提是你知道自己在解决什么瓶颈。

常见误区

1. 把低 bit 等同于一定更快

如果内核不匹配、算子不成熟，量化后的速度可能没有你想象的大。

2. 只看 benchmark，不看真实业务样本

某些模型在公开基准上损失不大，但在你的垂直任务里可能明显掉质。

3. 忽略量化对象

权重量化、激活量化、缓存量化不是一回事，收益和风险都不同。

4. 没有建立回滚路径

量化上线后若出现质量问题，应该能快速切回高精度版本，否则排障成本会很高。

练习与思考题

为什么说量化既是“存储问题”，也是“访存问题”？
在什么情况下 INT8 会比 INT4 更值得优先尝试？
GPTQ 和 AWQ 的共同目标是什么，它们各自强调了什么？
如果你的部署瓶颈主要来自 KV Cache，而不是权重，占优策略会发生什么变化？

先修知识