模型量化实战：从 AWQ/GPTQ 到 NVIDIA FP8 推理的工程部署与性能调优

本文深度剖析大语言模型推理中的量化技术路线，从 GPTQ、AWQ、SmoothQuant 到 NVIDIA 硬件级 FP8 推理，结合 vLLM 与 TensorRT-LLM 实战部署，给出一套完整的工程方案。

一、为什么量化是 LLM 推理的命门

大语言模型的推理成本主要由两部分决定：计算量和显存带宽。以 Llama-3 70B 为例，其 FP16 权重约 140GB，单张 H100 (80GB) 根本放不下。即使使用两张卡，推理时的 KV Cache 又占据了大部分显存，留给 batch 的空间极其有限。

模型量化的本质是用更少的比特表示模型参数和激活值，从而同时缓解两个瓶颈：

• 显存占用：INT8 是 FP16 的一半，INT4 是四分之一，直接扩大了可运行的模型规模
• 内存带宽：对于 LLM 推理这种 memory-bound 工作负载，每少读 1 bit 数据，就少消耗 1 bit 的时间

但量化从来不是免费的午餐。精度损失、校准开销、算子融合难度、硬件兼容性，都是工程落地时必须权衡的因素。本文将带你从算法原理到生产部署，彻底搞懂 LLM 量化的技术全景。

二、量化基础：从数学到工程

量化的核心数学公式简洁优美：

round(x / scale) + zero_point

其中 scale = (max - min) / (2^b - 1)，zero_point 用于将零点精确映射到整数格点上。对于神经网络权重，通常选择对称量化（zero_point = 0）来简化计算。

在 LLM 场景下，量化策略分为两大类：

• 训练后量化（PTQ）：使用少量校准数据确定 scale/zero_point，无需重新训练，速度快但精度损失较大
• 量化感知训练（QAT）：在训练过程中模拟量化噪声，精度更高但成本巨大（70B 模型 QAT 成本可达数百万美元）

当前工业界主流方案大多是 PTQ，因为 LLM 的 QAT 成本实在太高。

三、主流量化技术深度解析

3.1 GPTQ：One-shot 权重压缩标杆

GPTQ（Generative Pre-trained Transformer Quantization）基于 OBQ（Optimal Brain Quantization）框架，通过逐列量化权重矩阵并利用 Hessian 矩阵估计量化误差。

核心代码思路（伪代码）：

for each column j in weight matrix W:
    # 量化当前列
    W_q[:, j] = round(W[:, j] / scale[j])
    # 计算量化误差并修正剩余列
    error = W[:, j] - W_q[:, j] * scale[j]
    W[:, j+1:] -= error.outer(H_inv[j, j+1:]) / H_inv[j, j]

GPTQ 的核心优势是一次性完成量化，只需要几百 MB 校准数据，几分钟内就能量化一个 70B 模型。但难点在于如何将量化后的权重融合到推理 kernel 中，INT4 矩阵乘法需要专门的 dequantize-fused GEMM。

3.2 AWQ：激活感知的权重量化

AWQ（Activation-aware Weight Quantization）观察到一个关键事实：并非所有权重同等重要。大约 0.1%~1% 的显著权重（salient weights）对模型精度贡献巨大。如果对这些权重不量化（或给予更高位宽），整体精度损失就会大幅降低。

AWQ 通过计算每个通道的激活均值来确定缩放因子：

s_i = mean(|activation_i|) ^ alpha  # alpha 通常在 [0, 1] 之间搜索
W_scaled[:, i] = W[:, i] / s[i]
W_scaled[:, i] = round(W_scaled[:, i] / scale)  # 量化
activation[:, i] = activation[:, i] * s[i]  # 补偿回激活

这种方法让 AWQ 在 4-bit 量化下精度通常优于 GPTQ，尤其是在 per-channel 量化粒度下。缺点是缩放因子的搜索需要一些校准时间。

3.3 SmoothQuant：解决激活值异常值

LLM 权重分布相对均匀，但激活值中存在大量异常值（outliers），导致直接 per-token 激活量化误差极大。SmoothQuant 通过数学等价变换，将激活值的量化难度"平滑"到权重上：

# 原始计算：Y = X @ W
# 等价变换：Y = (X * diag(s)^-1) @ (diag(s) * W) = X_int8 @ W_int8
# 其中 s_j = max(|X_j|) ^ alpha / max(|W_j|) ^ (1 - alpha)

SmoothQuant 的关键洞察是：权重可以承受更大的量化误差（冗余度高），而激活值必须保持高精度。通过 per-channel 平滑因子，激活的异常值被"吸收"到权重中，使 INT8 PTQ 成为可能。

3.4 FP8：硬件级的量化革命

FP8（8-bit Floating Point）是 NVIDIA Hopper 架构（H100/H200）引入的新数据类型，它不是 PTQ 软件方案，而是由硬件原生支持的计算格式。

FP8 有两种格式，各有用途：

• E4M3：1 位符号 + 4 位指数 + 3 位尾数，动态范围更大，适合前向传播中的激活和权重
• E5M2：1 位符号 + 5 位指数 + 2 位尾数，精度稍低但表示范围更大，适合反向传播中的梯度

H100 的 FP8 Tensor Core 提供 3,958 TFLOPS，是 FP16 的两倍。更关键的是，FP8 不需要像 INT4/INT8 那样进行反量化操作——硬件直接以 FP8 精度完成矩阵乘法，精度损失远小于整数量化。

Blackwell B200 更进一步提升，原生支持 FP6 和 FP4 推理：

# Blackwell Tensor Core 性能对比
FP64:   34 TFLOPS
FP32:   1,356 TFLOPS
FP16:   22,500 TFLOPS
FP8:    45,000 TFLOPS
FP4:    90,000 TFLOPS

四、硬件加速平台演进

NVIDIA 的量化和推理加速能力经历了三代演进：

Ada Lovelace（RTX 40 系 / L40S）：首次在消费级 GPU 上支持 FP8 Transformer Engine，但 Tensor Core 规模有限。L40S 的 FP8 算力约 362 TFLOPS。

Hopper（H100 / H200）：H100 SXM5 的 FP8 Tensor Core 算力达到 3,958 TFLOPS，并引入 Transformer Engine——一个运行时框架，可根据层级动态选择 FP8 或 FP16 精度。H200 将显存从 80GB 提升到 141GB，对长上下文推理帮助极大。

Blackwell（B200 / B300）：B200 单卡 FP8 算力达到 45,000 TFLOPS（理论峰值），并且原生支持 FP6 和 FP4。B300 进一步通过统一显存设计实现 288GB HBM3e，单卡即可运行全精度的 405B 模型。

对于推理工程选型，关键逻辑是：如果有 H100/B200 级别卡，优先用 FP8；如果只有 PCIe 卡或 T4 级别，INT4/INT8 PTQ 更实用。

五、生产环境部署实战

5.1 vLLM 部署量化模型

vLLM 对量化模型的支持非常成熟，通过统一的 quantization 参数即可切换不同方案。

AWQ 模型部署：

from vllm import LLM, SamplingParams

llm = LLM(
    model="casperhansen/llama-3-70b-instruct-awq",
    quantization="awq",
    dtype="float16",
    tensor_parallel_size=2,
    max_model_len=8192,
    enforce_eager=False,  # 启用 CUDA Graph
    gpu_memory_utilization=0.9,
)

outputs = llm.generate(
    ["请用 Python 实现一个 LRU 缓存"],
    SamplingParams(temperature=0.7, max_tokens=1024)
)

GPTQ 模型部署：

llm = LLM(
    model="TheBloke/Llama-2-70B-GPTQ",
    quantization="gptq",
    dtype="float16",
    tensor_parallel_size=2,
    max_num_batched_tokens=4096,
    max_num_seqs=32,
)

FP8 模型部署（vLLM v0.4.0+）：

llm = LLM(
    model="neuralmagic/Meta-Llama-3.1-70B-Instruct-FP8",
    quantization="fp8",
    dtype="auto",
    tensor_parallel_size=2,
    # FP8 KV Cache 进一步减少显存
    kv_cache_dtype="fp8_e5m2",
)

vLLM 还支持 FP8 KV Cache（将 KV Cache 从 FP16 压缩到 FP8），这对 KV Cache 占推理显存主导的场景极为关键。以 32K 上下文 70B 模型为例，FP16 KV Cache 约 6.4GB，而 FP8_e5m2 KV Cache 仅 3.2GB，直接释放 50% 显存给 batch 使用。

W8A8 FP8 推理的完整 pipeline 直接启用量化 API 即可。

5.2 TensorRT-LLM 部署 FP8 模型

TensorRT-LLM 的 FP8 支持通过 PyTorch 模型自动转换实现。核心步骤包括：将权重直接加载为 float8_e4m3fn 格式、启用 FP8 GEMM 插件和 FP8 Attention 插件。

权重加载和模型构建的简化流程如下：

import torch
from tensorrt_llm import Module
from tensorrt_llm.layers import Attention, MLP
from tensorrt_llm.quantization import QuantMode
from tensorrt_llm.quantization.layers import WeightOnlyQuantLinear

# 设置 FP8量化模式
quant_mode = QuantMode.from_description(
    quantize_weights=True,
    quantize_activations=True,
    per_token=True,
    per_channel=True,
    use_fp8_block_scaling=True,
    use_int4_weights=False,
    exclude_modules=['lm_head']
)

llm = LLM(
    model="meta-llama/Meta-Llama-3-8B",
    quant_mode=quant_mode,
    dtype="float16",
    max_batch_size=32,
    max_input_len=2048,
    max_output_len=1024,
)

# 构建引擎
engine = llm.build(
    output_dir="./trt_engines/llama3_8b_fp8",
    strong_typing=True,
    profiling_verbosity="detailed",
)

# 推理会话
session = llm.session_from_dir("./trt_engines/llama3_8b_fp8")

outputs = session.generate(
    input_ids, max_new_tokens=256,
    top_k=1, temperature=0.8
)

但原生层迁移工作量大，如果只是追求部署速度，可以用 vLLM 一步到位。

5.3 llama.cpp / GGUF：端侧部署的利器

对于没有高端 GPU 的场景（开发机、MacBook、树莓派），llama.cpp 配合 GGUF 量化格式是最佳选择。

# 将 HF 模型转换为 GGUF 格式（Q4_K_M 量化）
python convert_hf_to_gguf.py \
    ./models/Llama-3-8B-Instruct \
    --outfile llama-3-8b-q4_k_m.gguf \
    --outtype q4_0

# 使用 Q4_K_M 量化（推荐，在质量和速度间取得最佳平衡）
./llama-cli \
    -m llama-3-8b-q4_k_m.gguf \
    -p "Explain transformer architecture" \
    -n 512 -t 8 --temp 0.7

# 量化级别对比：
# Q2_K: 极端压缩，推理快但质量严重下降，仅适合玩具
# Q4_K_M: 推荐默认选项，保留约 95% 原始能力
# Q5_K_M: Q4 到 Q6 的中间档，精度更高
# Q6_K: 接近 FP16 质量，速度损失较小
# Q8_0: 几乎无损，如果你不太在意内存

GGUF 格式的另一大优势是混合量化——可以对不同层使用不同量化级别。通常 attention 层对量化更敏感，适合用 Q6_K；而 FFN 中间层可以用更激进的 Q4_K，节省显存同时控制精度损失。

六、性能基准与选型决策

基于公开基准测试和我们的实际部署经验，不同量化方案在 H100 上的典型表现如下：

模型/配置	精度	吞吐量 (tok/s)	首 Token 延迟 (ms)	相对 FP16 质量
Llama-2-70B FP16 (TP2)	FP16	~850	~250	100% (基线)
Llama-2-70B GPTQ-4bit (TP2)	INT4	~2200	~120	~97%
Llama-2-70B AWQ-4bit (TP2)	INT4	~2400	~110	~98%
Llama-3-70B FP8 (TP2)	FP8	~3200	~90	~99.5%

关键结论：

• 有 H100/B200 时，FP8 是首选：吞吐量最高、精度损失最小、无需校准、无需管理 BitsAndBytes 依赖
• INT4 PTQ 适合显存极其受限的场景：AWQ-4bit 是被验证最稳定的方案
• SmoothQuant INT8 是中间路线：兼容性最好，从 T4 到 H100 都能用
• GGUF Q4_K_M 是端侧的事实标准：Mac Studio 上跑 Llama-3-8B 可达 40+ tok/s

选型决策树：

是否有 Hopper+ GPU？
├── 是 → 优先 FP8（vLLM 部署最省心）
└── 否 → 显存 > 40GB？
         ├── 是 → INT8 PTQ（SmoothQuant）或 AWQ-4bit
         └── 否 → AWQ-4bit 或 GPTQ-4bit
                  端侧设备？→ llama.cpp + GGUF Q4_K_M

七、FP8 部署的三个坑

FP8 虽然美好，但工程落地上有几个容易踩的坑需要注意。

坑 1：不是所有层都适合 FP8

Embedding 层、LayerNorm、最后的 lm_head 对精度敏感，保留 FP16/BF16 至关重要。H100 的 Transformer Engine 会自动跳过这些层的 FP8 转换，但需要确保推理框架正确配置，不要全局强制 FP8。

坑 2：动态反量化开销

FP8 的 GEMM 本质是：FP8 Tensor Core 做乘加后，立即反量化回 FP16 累积。如果 batch 太小，反量化操作的 overhead 占比上升。一般建议 FP8 推理的最小 batch ≥ 8，否则直接使用 FP16 可能更快。实测 vLLM 在 batch=1 时 FP8 反而比 FP16 慢 15%，但 batch=32 时 FP8 快 80%。

坑 3：E4M3 vs E5M2 的选择

推理时前向传播统一用 E4M3（精度更高），训练/微调反向传播用 E5M2（范围更大）。如果框架让你手动选格式，千万别反过来。NVIDIA 的 Transformer Engine 在内部已经是这样做的，但如果用裸 FP8 kernel，这点必须手动保证。

八、未来展望

模型量化的技术仍在快速演进，几个值得关注的趋势：

Microscaling (MX) FP4/FP6：Blackwell 的 Block Scalable 格式，在一个 block（通常 32 个元素）内共享一个 scale，比 per-channel FP4 灵活得多。FP4 推理的精度已经接近 INT8 PTQ，而显存和算力成本减半。这是 NVIDIA 给出的 INT4 替代方案，很可能成为下一代量化主流。

GPTQ/AWQ 的 Variant 军备竞赛：QuIP#、AQLM、SpQR 等学术方案不断涌现，但工业落地仍然被 AWQ/GPTQ 垄断——因为后者的工程生态最好。短期内不会改变。vLLM 和 SGLang 对 AWQ 的 kernel 优化仍在持续，每次 release 吞吐都会提升几个百分点。

KV Cache 量化的全面普及：FP8 KV Cache 已经是 vLLM 的标准配置，INT4 KV Cache 也在路线上。在超长上下文（128K+）场景下，KV Cache 量化带来的显存节省远超权重量化，这将成为标配。

总结

LLM 量化不是一个简单的"精度 vs 速度"选择，而是需要综合考虑硬件平台、访问模式、精度要求的系统工程。对于生产部署：

• 云端 H100 → FP8 W8A8 + FP8 KV Cache
• 云端非 Hopper → AWQ-4bit + 标准 FP16 KV
• 端侧/开发机 → llama.cpp + GGUF Q4_K_M

量化不是一次性工作，而是需要持续跟进硬件迭代和框架更新的工程实践。选择 AWQ 还是 FP8，不只是算法之争，更是算力资源的最优配置问题。