上一篇（第 9 篇）把量化这件事在 GGUF 体系里讲完了：K-quant 档位怎么读、Q4_K_M 怎么选、CPU 与消费级显卡上怎么跑。但如果你的推理引擎是 vLLM 或 SGLang——第 5、6、7 篇那条服务端路线——会发现那套 GGUF 档位表完全用不上：服务端 GPU 推理用的是另一套量化体系，主角是 GPTQ、AWQ 和 FP8。
这两套体系为什么不能混用、三种格式各自的原理直觉、预量化模型去哪找、真要自己动手怎么做、手里的卡该选哪种，本篇一次讲完。本文基于 2026 年 10 月的 vLLM v0.32.0 与当前 HuggingFace 生态，全文按"体系分野 → 三种格式原理 → 预量化识别 → 动手量化 → 选型速查"组织。
1、两套量化体系分野
先说结论：GGUF 与 GPTQ/AWQ/FP8 的分界线是推理内核，不是文件后缀。llama.cpp 系（llama.cpp、Ollama）的量化内核为 GGUF 的张量布局手写——K-quant 的超块结构、分块缩放，都是这套体系私有的内存排布。vLLM、SGLang、transformers 这条 PyTorch 路线的内核（包括 Marlin 这类重写的高效 INT4 矩阵乘）认的是 safetensors 目录里按 group 分组打包的权重。文件格式只是外壳，二进制布局对不上，对方的内核就没法解码。
| 维度 | GGUF 体系 | GPTQ/AWQ/FP8 体系 |
|---|---|---|
| 主战场 | CPU、消费级 GPU、边缘设备 | 数据中心 GPU、大显存服务端 |
| 常用引擎 | llama.cpp、Ollama、LM Studio | vLLM、SGLang、transformers |
| 文件形态 | 单文件 .gguf，自包含 |
safetensors 分片加 config.json |
| 档位密度 | Q2 到 Q8 几十档，体积导向 | INT4、INT8、FP8 少而精，吞吐导向 |
| 并发能力 | 单流优先，多路并发弱 | 连续批处理，高并发吞吐 |
由此得出两条实用推论。第一，vLLM 对 GGUF 只有架构覆盖有限的实验性支持，llama.cpp 则完全不认 GPTQ/AWQ 的 safetensors 目录；跨体系没有转换工具，也不该有——两边打包布局不同，正确做法是回到 FP16 原版权重，按目标体系重新量化。第二，两套体系的源头相同：所有量化版本都从原版权重生成，同一个模型家族通常两边都有成品。所以真正的决策顺序是先选引擎，再选格式，而不是反过来。
2、GPTQ 量化原理
GPTQ（Generative Pre-trained Transformer Quantization）是 2022 年底提出的后训练量化算法，思想源自 OBQ（Optimal Brain Quantization），论文见 arXiv 2210.17323。它要解决的问题很具体：把一层权重从 16 bit 压到 4 bit，怎么让这层输出的变化最小。
朴素做法是四舍五入，每个权重独立取最近的 4 bit 值。这对单看权重是"最优"的，但层的输出是权重矩阵乘输入，各权重的误差会组合放大。GPTQ 的处理分三步：逐层进行，每次只量化一个 Transformer 层，先用几百条校准数据收集该层的输入激活 X；再用 Hessian 矩阵 H = 2XXᵀ 给误差加权，它刻画了哪个方向上的输出误差最要命；最后逐列量化权重，每量化完一列，就把这列造成的输出误差按 Hessian 权重补偿到尚未量化的列上，边量化边纠偏。
打个比方：像做一套填空题，朴素做法是每空独立蒙一个最可能的答案，GPTQ 则是每填一空就检查整体偏差，把这一空的错误分摊给后面还没填的空去补救，最终整卷得分最高。工程收益同样直接：整个过程不需要重训，一块 GPU 上几十分钟就能得到精度接近重训量化的 INT4 模型，量化产物按 group size（常用 128）分组携带缩放系数。这让它成了社区发布 4 bit 模型的主力算法之一。
3、AWQ 激活感知量化
AWQ（Activation-aware Weight Quantization）出自 MIT Han Lab，论文见 arXiv 2306.00978。它的出发点与 GPTQ 不同：不追着输出误差补偿，而是先承认一个事实——不是所有权重通道同等重要，而重要与否不看权重大小，看激活分布。
原理直觉是：如果某个输入通道的激活值经常很大，这条通道上权重的量化误差就会被大激活放大，传导进输出。AWQ 用校准数据统计激活，找出约 1% 的显著通道，给它们的权重乘上 per-channel 缩放系数再量化——数学上等价于把重要通道的量程拉满——量化后再在激活侧把缩放除回来。注意它不是混合精度：所有权重都是纯 INT4，只是缩放策略不同，因此推理内核无需处理两种精度，速度不受拖累。
与 GPTQ 的定性对比如下。
| 维度 | GPTQ | AWQ |
|---|---|---|
| 核心思想 | 逐层最小化输出误差 | 保护激活显著的 1% 通道 |
| 量化耗时 | 逐列迭代补偿，较慢 | 搜索缩放因子，较快 |
| 精度特点 | 依赖校准数据质量 | 对校准数据不敏感，更稳 |
| 推理速度 | 两边都有 Marlin 内核，实际差距小 | 同左 |
实际选型里两者差距没有想象中大：同样 4 bit、同样 group size 128，困惑度差距通常在小数点后第三位。社区经验是长文本与指令跟随场景 AWQ 略稳，但更实际的决定因素往往是这个模型家族官方发布了哪种预量化版本——有 AWQ 用 AWQ，有 GPTQ 用 GPTQ。
4、FP8 硬件原生量化
GPTQ 和 AWQ 都是 4 bit 仅权重量化，FP8 走的是另一条路：8 bit 浮点，权重常用 E4M3 格式（4 位指数、3 位尾数）。它与 INT8 的本质区别是带指数位，动态范围能覆盖 BF16 的大部分，因此量化几乎无损，困惑度变化通常在千分位，常被当作"免费午餐"。
FP8 的第二个特点是硬件原生。FP8 Tensor Core 从 Hopper（H100，compute capability 9.0）和 Ada（RTX 4090、L40S，8.9）这一代开始才有，Blackwell（B200、RTX 5090）进一步下探到 FP4；Ampere（A100、3090）没有 FP8 计算单元，vLLM 在这些卡上不能启用 FP8。4090 有个细节：它具备 FP8 算力但没有 Hopper 的 Transformer Engine，吞吐收益不如 H100 那么满，可用性没有问题。
第三个特点是动态。GPTQ 与 AWQ 是后训练量化，离线做完就固定；FP8 在 vLLM 里可以运行时在线完成：--quantization fp8 让 vLLM 加载 BF16 原版权重时按通道量化权重、按 token 实时量化激活，全程不需要校准数据。第 6 篇已演示过这条命令，这里只强调定位：在 H100 及更新的卡上，FP8 是默认推荐，4 bit 只在显存极度紧张时才需要考虑。
5、预量化模型查找与加载
生产上最省事的路永远是直接用现成的预量化版本。去 HuggingFace 搜模型名加 AWQ 或 GPTQ 后缀，优先选模型官方仓库（如通义官方的 Qwen3-8B-AWQ），其次是有活跃记录的社区发布者。识别一个仓库是不是服务端量化版，看两样东西。先看文件列表：
Qwen3-8B-AWQ/
├── config.json
├── generation_config.json
├── tokenizer.json
├── tokenizer_config.json
├── model.safetensors.index.json
├── model-00001-of-00002.safetensors
└── model-00002-of-00002.safetensors
全是 safetensors 分片加配置文件、没有任何 .gguf，就是 PyTorch 系的量化仓库。再看决定性证据——config.json 里的 quantization_config 字段：
"quantization_config": {
"bits": 4,
"group_size": 128,
"quant_method": "awq",
"version": "gemm",
"zero_point": true
}
quant_method 为 awq 即 AWQ 版；gptq 同理，还多一个 desc_act（按激活降序量化）开关。这个字段就是 vLLM 的识别依据：第 6 篇讲过，vllm serve 读到它会自动选择对应内核，无需任何参数；需要强制指定时可显式传 --quantization awq、gptq 或 awq_marlin（Ampere 卡上值得指定的 Marlin 内核）。SGLang 的识别行为一致，预量化模型两边通用，完整支持矩阵见官方 量化文档。
显存账直接记结论：8B 模型 BF16 权重约 16 GB，FP8 与 GPTQ-Int8 约 8～9 GB，AWQ/GPTQ INT4 约 6 GB。同一张 24 GB 卡，BF16 塞下权重后 KV cache 所剩无几，INT4 则宽裕得多——这是服务端量化的真正意义，比省磁盘重要得多。
6、自己动手做量化
现成版本覆盖不到时才轮到自己量化。动手前先了解工具现状：AutoAWQ 已官方废弃（仓库公告停止维护，最后验证组合停在 Torch 2.6.0 与 Transformers 4.51.3），AutoGPTQ 也在 2025 年 4 月归档。别再照旧教程安装这两个包，当前的接班人是 llm-compressor 与 GPTQModel。
6.1、llm-compressor
llm-compressor 是 vLLM 项目下的官方压缩库，一个包覆盖 GPTQ、AWQ、FP8 与 NVFP4 的 one-shot 量化——一遍校准数据完成压缩，无需重训。以把 Qwen3-8B 压成 INT4 为例，先 pip install llmcompressor，量化脚本核心十几行，AWQ 负责算缩放、GPTQ 负责量化，两个 modifier 串成一个 recipe：
from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer
from llmcompressor import oneshot
from llmcompressor.modifiers import AWQModifier, GPTQModifier
model_id = "Qwen/Qwen3-8B"
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype="auto")
tokenizer = AutoTokenizer.from_pretrained(model_id)
ds = load_dataset("HuggingFaceH4/ultrachat_200k",
split="train_sft").select(range(512))
recipe = [
AWQModifier(), # 统计激活分布，确定通道缩放
GPTQModifier(scheme="W4A16", targets="Linear", ignore=["lm_head"]),
]
oneshot(model=model, tokenizer=tokenizer, dataset=ds, recipe=recipe)
model.save_pretrained("Qwen3-8B-int4") # 自动写入 quantization_config
解读四个关键点。校准数据 512 条够用，通用语料（如 ultrachat）即可，换业务域内文本（客服对话、代码）效果更好；ignore=["lm_head"] 是惯例，输出头对精度敏感且参数量小，保留 16 bit；save_pretrained 落盘时自动把 quantization_config 写进 config.json，下游 vLLM 零参数识别；想离线做 FP8 静态版，把 recipe 换成 Float8Modifier 即可，官方仓库 examples 目录有现成模板。
产物用一条命令验证服务：
vllm serve ./Qwen3-8B-int4 --served-model-name qwen3-8b-int4
输出正常、显存占用对得上账，量化闭环完成。
6.2、GPTQModel
如果只需要 GPTQ 一种格式，GPTQModel 是 AutoGPTQ 的社区续作，由 ModelCloud 维护，API 习惯与 AutoGPTQ 一脉相承，更新活跃。两条路线怎么选：部署目标是 vLLM/SGLang、未来可能要 FP8 或 NVFP4，选 llm-compressor；只想快速出 GPTQ、或要复用旧 AutoGPTQ 脚本，选 GPTQModel。
提醒：老教程里
autoawq、auto_gptq的安装命令如今装到的是停止维护的包。量化脚本报错时，先怀疑工具链版本，再怀疑量化参数。
7、选型决策速查
把全文结论压成一张决策表，按卡代对号入座。
| 硬件 | 推荐格式 | 理由 |
|---|---|---|
| CPU、无独显、老笔记本 | GGUF（第 9 篇） | 另一套体系，llama.cpp 主场 |
| 消费级到 Ampere（3090、A10、A100） | AWQ 或 GPTQ INT4 | 无 FP8 单元，4 bit 换显存与吞吐 |
| Ada（4090、L40S） | 中小模型 FP8，大模型 INT4 | FP8 可用，但 24 GB 显存是硬约束 |
| Hopper 及更新（H100、H200、B200） | FP8 优先 | 原生单元，几乎无损，吞吐更高 |
与第 9 篇的 GGUF 档位做一次跨体系对照：Q4_K_M（约 4.8 bpw）对应服务端 AWQ/GPTQ INT4（group 128 下约 4.5 bpw），同为"4 bit 档"，精度大体同档，GGUF 因混合精度打包通常体积略小，但差距不影响选型；GGUF 的 Q8_0 与 FP8 同为 8 bit，前者是整型思路、后者是浮点，FP8 精度显著更好。两边的档位哲学要体会：GGUF 给了几十档让你抠体积，服务端只给三四种，因为它的优化目标是并发吞吐，不是"塞进 8 GB 显存"。
一句话收拢：引擎决定体系，卡代决定格式，预量化优先于自己动手。
8、总结
本篇补全了量化地图的服务端半边：GGUF 与 GPTQ/AWQ/FP8 因内核布局而分野，跨体系只能回原版重新量化；GPTQ 用 Hessian 加权的逐列补偿把 INT4 的输出误差压到最小；AWQ 保护激活显著的 1% 通道，换来对校准数据更稳的精度；FP8 靠 Hopper 与 Ada 起的硬件原生单元在运行时动态量化，几乎无损；工具链上 AutoAWQ 与 AutoGPTQ 已谢幕，llm-compressor 与 GPTQModel 是当前答案。与第 9 篇合起来，本地与服务端的量化选型就都闭环了。
练习：在 vLLM 上分别部署同一家族的 FP16 与 AWQ 版（如 Qwen3-8B 与 Qwen3-8B-AWQ），用第 6 篇的压测脚本记录并发 1 与 16 两档的首 token 延迟和吞吐，量化带来的显存与吞吐收益会非常直观；手里有 H100 的话再加一组 --quantization fp8 做三方对照。对于正在规划服务端部署的读者，建议按第 7 节的表定格式、再去找预量化版本，自己动手永远排在最后。
