Day25 | 模型量化横评 GPTQ vs AWQ vs GGUF vs INT8——同一个 Qwen3-8B 压四遍，谁还活着

苦猿的大模型日记 · Day25 · 模型量化横评 GPTQ vs AWQ vs GGUF vs INT8-帮普通人把AI学进简历系列

前言：模型量化，跟压 mp3 是同一件事

你听过 320kbps 和 128kbps 的 mp3 吗？

大多数人听不出差别。但文件大小，差了一倍多。

模型量化干的就是这件事。

把一个 fp16 的 Qwen3-8B------大约 16G 显存------压成 4bit，只要 5G。推理质量掉一点点，但你看不出来，部署成本砍掉一大半。

听起来很美，对吧？

直到我第一次真去压一个模型，连环踩坑------

照着某篇博客装 AutoAWQ，pip install 完一启动，README 顶部弹出红框 deprecated
换 AutoGPTQ，量化跑到一半 transformers 报 dtype 不兼容，搜了一圈发现这库 2024 年 3 月起就停止维护了
改用 llama.cpp，编译半小时才编出来
跑通后想升级 vLLM 一起用，发现 AutoAWQ / AutoGPTQ 这两个老库产出的格式跟最新版 vLLM 对不上

我当时脑子嗡的一下。

量化方法不是一个"技术选型"那么简单------它是在选一条生态路线。选错了，库废弃了，你的模型跟着一起报废。

今天我就把同一只 Qwen3-8B 用四种方法各压一遍------

INT8（bitsandbytes）
GPTQ INT4
AWQ INT4
GGUF Q4_K_M

告诉你哪种还活着、哪种半死、哪种你根本不该碰。

读完你能------

看懂四种方法各自压什么、用什么算法
拿到真实的显存 / 速度 / 质量 / 生态数据
知道你的硬件和部署目标，到底该选哪一种

PART 01：四种方法到底差在哪------一句话讲透

先把最容易混的两个概念剥开。

bitsandbytes 的 NF4 是训练侧量化，不是推理侧量化。

很多人第一次踩这个坑------QLoRA 微调时写的 BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_quant_type="nf4")------这里的 NF4 是训练侧量化 ，目的是省显存做梯度反传，不是把模型压成 4bit 拿去上线。

注意，bnb 的 INT8（LLM.int8()，Dettmers et al., NeurIPS 2022, arXiv 2208.07339）是推理量化 没错，但它的产物是运行时量化------模型权重本身没变，加载到 GPU 那一刻才动态量化。这跟 GPTQ/AWQ 那种"预先把权重压成 4bit 文件"不是一回事。

训练用 NF4，推理用 GPTQ/AWQ/GGUF（或 bnb INT8 在 transformers 里直接跑）------记住这条，能避开 80% 的量化误区。

下面把四个推理量化的核心思路讲清。

INT8（bitsandbytes，LLM.int8()）：最老最稳最通用

把权重按 block 缩放到 int8，激活值用 FP16 保留------这是 LLM.int8() 论文的核心做法，论文定位就是"无性能损失的 175B 模型推理"。

算法简单、几乎不可能装不上。但有两个工程特点要注意------

产物是运行时量化：权重本身没变，加载到 GPU 那一刻才动态量化，所以磁盘上的模型还是 fp16
vLLM 兼容性参差：vLLM 较新版本（2024 末起）已经支持 bnb INT8/INT4 模型，但跟 GPTQ/AWQ 比起步晚、kernel 优化也少，生产部署首选仍是 GPTQ/AWQ

GPTQ：用 Hessian 矩阵做二阶误差补偿

论文：Frantar et al., GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers , ICLR 2023, arXiv 2210.17323。

核心思路一句话------逐层量化，每量化一列权重，就用剩下没量化的权重去补偿这一列的误差。

数学上靠逆 Hessian 矩阵做最小二乘补偿。

类比一下：你在改一份大文档，每改一段，就用后续段落里的素材去把这段漏掉的内容补上------保证最终整体误差最小。

需要一小批（128 条左右）校准文本让模型"看到"激活值。

优势：精度高，GPTQ 论文 Table 5 显示在 OPT-175B 这种大模型上 INT4 之后 PPL 退化极小（接近 FP16）。

劣势：量化过程慢（要算 Hessian），需要校准集；在小模型上退化比 AWQ 大（详见下面 AWQ 段）。

AWQ：靠激活值找"重要通道"

论文：Lin et al., AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration , MLSys 2024 Best Paper, arXiv 2306.00978。

核心思路------观察哪些通道的激活值大（也就是"重要通道"），量化前对这些通道做按通道缩放，让重要权重保精度。

不像 GPTQ 那样算 Hessian，只看激活值统计，所以更快。

论文给的精度优势（OPT-6.7B INT4-g128 量化后 PPL 退化）：

AWQ 约 +0.5-0.6
GPTQ +2.3-4.9

但注意------这是英文 PPL benchmark 的数字。中文 / 指令跟随任务上，GPTQ 和 AWQ 的差距远小于这个数字。

GGUF：一个文件容器，不是一个算法

GGUF 是 llama.cpp 的二进制格式，前身叫 GGML，2023 年 8 月 PR #2348 合并后改名，由 Georgi Gerganov 维护。

它本身不是一个量化算法，是一个文件容器------里面塞的是 K-quants（Q4_K_M、Q5_K_M、Q6_K 等）。

核心优势有四条：

单文件分发------权重 + tokenizer + config 全打一个文件里
CPU 推理 + GPU offload 混合 -------ngl N 控制把多少层放到 GPU
Apple Silicon 一等公民------Metal 加速原生支持
mmap 快速加载------大模型秒级启动

被低估的一点：GGUF 不只是给 CPU 用的 。-ngl 999 全 offload 到 GPU，纯 GPU 跑 GGUF 也很常见。

四件套对照表（关键收藏卡）

维度	INT8 (bnb)	GPTQ	AWQ	GGUF (Q4_K_M)
算法核心	块缩放	逆 Hessian 二阶补偿	激活感知 per-channel scale	K-quants（改进版分组量化）
量化速度	快	慢	中	中
INT4 精度损失	中-大	小	最小（论文宣称）	小-中
主要部署目标	训练 / 研究	服务化（vLLM）	服务化（vLLM/TensorRT）	CPU / 边缘 / 混合
生态活跃度	高（bnb 持续维护）	库停滞	库已废弃	极高（llama.cpp 活跃）

PART 02：实验设置------锁定变量，让结果可比

老规矩------横评的可信度，全靠锁定变量。

固定项：

base：Qwen3-8B
校准数据：随机抽 128 条 Alpaca-zh
评测 prompt：10 条（指令跟随 + 知识问答 + 数学 + 代码各几条）
硬件：单卡（我用 4090 24G），CPU 推理用本机

变量项：只有量化算法和容器格式。

四条路：

INT8：bitsandbytes load_in_8bit=True
GPTQ：用 GPTQModel 量化到 INT4（别再用 AutoGPTQ，下面 PART 04 讲为啥）
AWQ：用 llm-compressor（vLLM 官方继任者）或 AutoAWQ（已废弃但仍能跑）量化到 INT4
GGUF：用 llama.cpp 的 convert_hf_to_gguf.py + quantize 工具压成 Q4_K_M

四套加载代码并排：

复制代码

# INT8 (bnb)
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-8B",
    load_in_8bit=True,
    device_map="auto",
)

# GPTQ INT4（用 GPTQModel 推荐）
from gptqmodel import GPTQModel
model = GPTQModel.from_quantized(
    "Qwen/Qwen3-8B-GPTQ-Int4",
    device="cuda:0",
)

# AWQ INT4
from awq import AutoAWQForCausalLM
model = AutoAWQForCausalLM.from_quantized(
    "Qwen/Qwen3-8B-AWQ",
    device="cuda:0",
)

# GGUF Q4_K_M（用 llama.cpp 的 python binding）
from llama_cpp import Llama
llm = Llama(
    model_path="qwen3-8b-q4_k_m.gguf",
    n_gpu_layers=-1,  # 全部 offload 到 GPU
)

两个最容易踩的工程坑：

坑 1：AutoAWQ 装不上 / 一启动就 deprecated warning

不是你的问题。AutoAWQ 在 2025 年 5 月已经被官方宣布废弃 ，官方继任者是 vLLM 项目下的 llm-compressor （vLLM 文档原话："adopted by the vLLM project in llm-compressor"）。注意，GPTQModel 不是 AutoAWQ 的继任者------它是 AutoGPTQ 的继任者，两个库的接棒关系别混了。

坑 2：bnb 加载的 INT8/INT4 模型，老版本 vLLM 报错 `unrecognized quantization`

vLLM 较新版本（2024 末起）已经支持 bnb INT8/INT4，但老版本的 vLLM 不认 bnb 的运行时量化------它要的是预先量化好的 GPTQ/AWQ 模型文件。如果你被这个报错卡住，要么升级 vLLM，要么改走 GPTQ/AWQ 路线。

PART 03：显存 / 速度 / 质量------四件套头对头数据

先说一句 ：下面三张表的具体数字会随你的硬件、prompt 长度、batch 大小波动。我给的是实测观察区间 和论文 / 官方数字，不是绝对值。

显存对比（Qwen3-8B，fp16 baseline 约 16G）

方法	模型加载显存	推理峰值显存	能否在 4090 24G 跑
FP16 baseline	~16G	~20-22G	极限
INT8 (bnb)	~9-10G	~12-14G	舒服
GPTQ INT4	~5-6G	~8-10G	非常舒服
AWQ INT4	~5-6G	~8-10G	非常舒服
GGUF Q4_K_M（纯 GPU）	~5-6G	~8-10G	非常舒服
GGUF Q4_K_M（CPU）	~0G GPU	系统 RAM 6-8G	任何机器

反直觉点 ：GGUF 在 CPU 模式下显存占用 0G ------你 4090 都不用，老笔记本都能跑 Qwen3-8B。

推理速度对比（同样 prompt，输出 256 tokens）

vLLM 上 GPTQ 和 AWQ 速度接近，配 Marlin kernel 后甚至比 fp16 还快------4bit 显存带宽友好
bnb INT8/INT4 在 transformers 里跑比较慢------动态量化开销摆在那，生产推理首选仍是 GPTQ/AWQ 这种预先量化方案
GGUF 纯 GPU 模式速度与 vLLM GPTQ 接近；CPU 模式慢 5-20 倍，但能跑

一句话心法：

部署用 vLLM + GPTQ/AWQ，本地玩用 GGUF------bnb INT8 不是首选推理方案。

质量对比（关键反差点）

AWQ 论文宣称 OPT-6.7B INT4 量化后 PPL 退化 +0.5-0.6，GPTQ 是 +2.3-4.9------但论文用的是英文 PPL benchmark。

中文 + 指令跟随任务上------

GPTQ 和 AWQ 的差距远小于论文数字
GGUF Q4_K_M 与 GPTQ INT4 质量接近（K-quants 是改进算法，比老 Q4_0 精度好不少）
INT4 vs INT8 的质量差距远小于显存差距------大多数人不需要 INT8

还有一个反直觉点------

质量退化最大的不是量化本身，而是"量化 + 微调叠加"。已经 GPTQ 量化过的模型，再上 LoRA 微调，精度损失会被放大。

LoRA 微调请用 QLoRA 的 NF4 流程（动态量化 + LoRA），别在量化模型上再训。

PART 04：生态存活度------这才是 Day25 真正的反差点

前面三章是技术对比。这一章才是这篇文真正想讲的------选量化方法不是选算法，是选生态。

我把四个库的"存活状态"列一下------

bitsandbytes ：高活。官方持续维护，8bit / 4bit 量化的"瑞士军刀"，NF4 训练侧（QLoRA）无可替代，INT8 推理也可用但 kernel 优化不如 GPTQ/AWQ。

AutoGPTQ ：自 2024 年 3 月起停止维护 （最后版本 0.7.1，官方 discussion #758 明确写 "effectively stopped forward development"）。但社区博客大量老教程还在教你装 AutoGPTQ------照着装能跑，但是个死人库。

AutoAWQ ：2025 年 5 月官方宣布 deprecated。README 顶部直接贴废弃公告。

GPTQModel ：AutoGPTQ 的继任者 ，活跃维护，同一个库同时支持 GPTQ 和 AWQ 两种量化算法。

llm-compressor ：AutoAWQ 的官方继任者，vLLM 项目下的量化工具链，跟 vLLM 部署深度协同。

注意这两个继任关系别混------GPTQModel 接 AutoGPTQ，llm-compressor 接 AutoAWQ，不是一回事。

llama.cpp / GGUF ：极活。Georgi Gerganov 团队 + 全社区贡献，每周都有 PR 合入。

判断标准：

新项目别再装 AutoGPTQ（→ 用 GPTQModel ）；别再装 AutoAWQ（→ 用 llm-compressor）
除非你要复现某个老教程，否则没必要碰那两个死库

面试被问"你用过哪些量化方法"的三层答案：

表层：GPTQ / AWQ / GGUF / INT8 各自压什么、用什么算法
工程层：AutoGPTQ / AutoAWQ 已停滞或废弃，新项目用 GPTQModel / llm-compressor；bnb NF4 是训练侧、INT8 是推理侧但 kernel 不如 GPTQ/AWQ
选型层 ：看硬件 + 部署目标 + 生态存活度，不是看论文 PPL

第三层才是真正区分"用过量化"和"懂量化"的分界线。

PART 05：选型决策树------什么硬件该用谁

直接上决策树。

个人电脑 / Mac / 没有好显卡 → GGUF Q4_K_M，没别的选。

4090 24G 单卡 + vLLM 部署 → GPTQ INT4 或 AWQ INT4，二选一。质量差距小于生态差距，看你顺手哪个。

A100 80G 多卡 + vLLM 部署 → GPTQ 或 AWQ INT4，吞吐量优先选 AWQ（Marlin kernel 优化更好）。

H100 / H200 + vLLM → 直接上 FP8 。vLLM 0.5+ 原生支持，需要 Hopper 架构原生硬件。在这个级别的硬件上，INT4 反而是历史包袱。

Blackwell B200 + vLLM → NVFP4。NVIDIA 官方说法是 FP4 "接近 FP8" 的精度（社区实测退化很小），正在吃掉 INT4 的地盘。

边缘设备 / 树莓派 / 手机 → GGUF Q4_0 或 Q3_K_M。llama.cpp 是唯一选项。

训练侧量化（QLoRA 微调） → bnb NF4。这跟推理量化是两个世界------NF4 是动态的，为反向传播服务，不是把模型压成静态 4bit。

一个反直觉点

INT4 在消费卡 / 边缘端仍是主力。FP8 / FP4 只在 Hopper / Blackwell 及更新硬件上才有意义。

你的 4090 跑 FP8 实际收益有限------4090（Ada Lovelace）硬件层面是支持 FP8 的（第四代 Tensor Core，E4M3/E5M2），但 NVIDIA 的 Transformer Engine 对 Ada 架构的优化远不如 Hopper，跑 FP8 不一定比 INT4 快多少。FP8 的甜点区在 Hopper 起。

很多人看到 "FP8 取代 INT8" 的说法就以为 FP8 是新时代答案，那是 H100 起步的事，跟你没关系。

一个心法

先选部署目标（CPU / GPU / 服务化 / 边缘），再选量化方法。别反过来。

90% 的个人部署场景，GGUF Q4_K_M 是最稳的答案------

对硬件最宽容（CPU 也行，GPU 也行，Mac 也行）
单文件好分发
社区最活跃

PART 06：崩盘点对照表（关键收藏卡）

症状	大概率原因	该动什么
vLLM 启动报 `unrecognized quantization`	老版本 vLLM 不认 bnb 的运行时量化模型	升级 vLLM 到新版（2024 末起已支持 bnb），或改用 GPTQ/AWQ 预量化模型
AutoAWQ 安装报错 / 到处 warning	库已 deprecated（2025-05 起），继任者是 vLLM 项目的 llm-compressor	改用 llm-compressor，或直接走 GPTQModel 路线
AutoGPTQ 量化过程卡死	AutoGPTQ 自 2024-03 起停止维护，跟新 torch/transformers 不兼容	换 GPTQModel（AutoGPTQ 的官方继任者）
GPTQModel 报 dtype 冲突	校准数据 dtype 与模型 dtype 不匹配	`calibration_data = calibration_data.to(model.dtype)`
GGUF 模型在 vLLM 里跑不动	vLLM 对 GGUF 支持有限（实验性）	改用 llama.cpp / llama-cpp-python 部署 GGUF
GGUF CPU 推理速度极慢	没开 `-ngl` GPU offload	`n_gpu_layers=-1` 全 offload
量化模型在长 prompt 下输出乱码	INT4 在长 context 下精度退化更严重	升级到 INT8 / Q5_K_M，或减少 context length
量化模型 LoRA 微调后效果反而变差	"量化 + 微调"放大精度损失	用 QLoRA NF4 流程，别在量化模型上再训
同一个 Q4_K_M 模型不同机器速度差很多	CPU 指令集差异（AVX2/AVX512/NEON）	编译 llama.cpp 时开对应指令集

结尾：量化方法不会过时，但量化库会

回到开头那个 mp3 的类比。

320kbps 和 128kbps 的差别你听不出来------但有一件事 mp3 不会发生、量化却会发生------

你用来压 mp3 的那个软件，可能已经停止维护了。

我见过太多人------

论文 PPL 比来比去，比了三天
最后选了 AutoAWQ，装上去才发现库已经废弃
想换 AutoGPTQ，发现也停更了
又去搜新方案，搜到 GPTQModel------一周过去了

论文里 PPL 差距 0.5%，你部署到生产里看不出来。

库废弃了你的模型直接报废------这才是真正的精度损失。

量化方法不会过时，但量化库会------你选的不是算法，是生态。

下次你纠结选哪个量化方法的时候，先去 GitHub 看看这个库最近一次 commit 是什么时候。比看论文 PPL 重要得多。

互动时间：你部署模型时选哪个量化方法？踩过哪些库废弃的坑？评论区聊聊。

> 下一篇，量化讲完了，我们聊聊怎么知道你的微调真的变好了------评测这件事，比训练更难。关注「苦猿」，别走丢。

--- END ---

苦猿 · 帮普通人把 AI 学进简历