AWQ 量化部署复盘：激活感知量化在 13B 模型上的精度-性能实验报告
一、AWQ 的动机：为什么 GPTQ 在 INT4 时掉点这么严重
上一阶段的 GPTQ INT4 量化实验暴露了一个规律性现象：模型规模越小，INT4 量化后的精度退化越显著。在 7B 模型上 INT4 的 HumanEval Pass@1 从 36.8 降至 31.2（-5.6），但在 70B 模型上仅从 52.1 降至 49.8（-2.3）。这说明大模型的权重分布存在更充分的冗余，对精度降低的容忍度更高。
AWQ（Activation-aware Weight Quantization）提出的核心洞察是：并非所有权重对精度等量重要。某些通道的权重在激活值中贡献了不成比例的重要信息，这些通道应该保留更高的精度。AWQ 通过分析校准数据集上的激活值分布，自动识别"显著通道"（Salient Channels）并为其分配更大的缩放因子，从而在总位宽不变的前提下提升精度。
二、AWQ 与 GPTQ 的精度对比：以 13B 模型为样本
使用 Qwen-1.5-14B 模型在 INT4 精度下做了 AWQ 和 GPTQ 的严格对比：
| 评估维度 | FP16 基线 | GPTQ-INT4 | AWQ-INT4 | AWQ 优势 |
|---|---|---|---|---|
| MMLU | 68.2 | 64.8 (-3.4) | 66.7 (-1.5) | +1.9 |
| GSM8K | 58.4 | 52.1 (-6.3) | 56.8 (-1.6) | +4.7 |
| HumanEval | 44.3 | 38.5 (-5.8) | 42.1 (-2.2) | +3.6 |
| MT-Bench | 7.5 | 6.8 (-0.7) | 7.3 (-0.2) | +0.5 |
| 业务测试集 | 91.2 | 86.4 (-4.8) | 89.8 (-1.4) | +3.4 |
在所有维度上 AWQ 均优于 GPTQ，尤其在 GSM8K（数学推理）上的差距达到 +4.7 个百分点——这正是因为数学推理高度依赖某些关键 attention 头的精确计算，AWQ 的显著通道保护机制恰好保护了这些关键计算路径。
# AWQ 量化流程 —— 与 GPTQ 的关键差异在激活值分析环节 from awq import AutoAWQForCausalLM from transformers import AutoTokenizer # 加载模型 model = AutoAWQForCausalLM.from_pretrained( "Qwen/Qwen1.5-14B-Chat", safetensors=True, # 推荐 safetensors 格式，加载更快且安全 ) # 设置 AWQ 量化配置 quant_config = { "zero_point": True, # 启用零点量化（非对称量化），精度略高于对称 "q_group_size": 128, # 分组大小：128 是精度和压缩比的平衡点 "w_bit": 4, # 权重量化位宽 "version": "GEMM", # 使用 GEMM 内核（兼容性好）或 GEMV（小 batch 更快） } # 关键步骤：AWQ 的激活感知通道分析 # 这一阶段会运行校准数据收集每层的激活值分布 model.quantize( tokenizer, quant_config=quant_config, # 校准数据集：128~256 条代表性样本 calib_data="/data/calibration/wikitext-128.jsonl", ) # 保存量化模型（可直接用 vLLM 加载） model.save_quantized("./qwen-14b-awq-int4") # vLLM 启动命令： # vllm serve ./qwen-14b-awq-int4 \ # --quantization awq \ # --max-model-len 8192 \ # --gpu-memory-utilization 0.92三、推理延迟与显存占用的工程数据
在单张 A100-80G 上部署 AWQ-INT4 模型的实测数据：
| 指标 | FP16 | AWQ-INT4 | 变化 |
|---|---|---|---|
| 模型显存占用 | 26GB | 8.2GB | -68% |
| KV Cache 可用空间（剩余） | 24GB | 52GB | +117% |
| 单卡最大并发请求 | 16 | 48 | +200% |
| TTFT（Prompt 512 tokens） | 420ms | 380ms | -10% |
| Token 生成速率 | 45 tok/s | 52 tok/s | +16% |
| batch_size=1 延迟 | 85ms | 72ms | -15% |
| batch_size=32 延迟 | 210ms | 178ms | -15% |
意外的收获是推理延迟反而降低了 10~15%。原因在于显存占用减半后，更大的 KV Cache 池让 Continuous Batching 的合并上限从 16 提升到 48，调度器可以更高效地组成大 batch，摊薄了每次推理的固定开销。
四、AWQ 的边界条件与禁用场景
AWQ 并非在所有场景下都优于 GPTQ：
AWQ 的优势场景：
- 中等规模模型（7B~30B）：精度提升最明显，在 13B 模型上优势最大；
- 对精度敏感的任务：代码生成、数学推理、多步逻辑推断等受益最显著；
- 小 batch 推理：GEMM 内核在小 batch 下性能与 GPTQ 持平或略优。
AWQ 的劣势场景：
- 超大规模模型（>70B）：大模型的权重冗余本身就足够，AWQ 的优势缩小到 0.3~0.5 个百分点；
- 校准数据敏感：如果校准数据集无法代表推理数据的分布，显著通道的识别可能偏差，反而导致精度不如 GPTQ；
- 社区工具链不成熟：截至 2025 年上半年，AWQ 的推理引擎支持仍不如 GPTQ 完善，某些推理框架（如 llama.cpp）对 AWQ 的优化不如 GPTQ。
五、总结
AWQ 量化的工程决策要点：
- 13B~30B 是 AWQ 的甜点区间：在这个参数规模上，AWQ 对 GPTQ 的精度优势超过 3 个百分点，是明显的技术选型分水岭；
- 激活感知的收益与校准数据质量强相关：校准数据集必须覆盖推理数据的分布，推荐至少 128 条样本，覆盖多个任务类型；
- AWQ 的显存-延迟双降是意外收益：量化后的显存释放带来了更大的 batch 空间，间接降低了延迟，这个收益往往被量化评估所忽略；
- 工具链不成熟是当前最大瓶颈：生产环境选型 AWQ 时，需要先确认推理引擎的集成状态。vLLM 和 TGI 的 AWQ 支持已稳定，但 llama.cpp 仍在完善中。
推荐路径：中型模型（13B~30B）+ 高精度要求 + vLLM/TGI 部署 → AWQ-INT4；小型模型（<7B）+ 一般场景 + 跨引擎兼容 → GPTQ-INT8。
