模型量化实战：INT8/INT4、GPTQ、AWQ与精度-速度权衡

系列：Ai大模型训练教程：从入门到实战落地的系统课程

本篇聚焦：在真实落地场景中，如何把大模型从“能跑”优化到“跑得快、跑得省、精度还可接受”。内容会围绕 INT8/INT4 量化、GPTQ、AWQ 的选择与实操流程，给出可复用的步骤、评测方法和避坑建议。

量化到底在解决什么问题

大模型部署常见瓶颈主要有三类：

1. 显存/内存不足：FP16/BF16 权重体积大，模型越大越难塞进单卡；推理时 KV Cache 也会随上下文增长。
2. 带宽受限：推理时大量时间在“搬运权重”（显存到计算单元），而不是计算；权重越大越慢。
3. 吞吐/延迟压力：业务场景中 QPS、首 token 延迟（TTFT）、每 token 延迟（TPOT）都可能不达标。

量化（Quantization）的核心目标是：

• 用更低位宽（INT8/INT4 等）表示权重（有时也包括激活），从而减少内存占用与带宽压力。
• 结合推理内核（如 GPTQ/AWQ 对应的 kernel）提升吞吐。

但量化必然带来数值误差，因此要做 精度-速度-成本 三者的权衡。

位宽与量化粒度：先把“技术名词”讲清

INT8 vs INT4：差别不只是精度

• INT8（8bit）：通常更稳健，精度下降较小，部署兼容性好。对多数任务影响较小，尤其是指令微调后的模型。
• INT4（4bit）：压缩更狠（权重体积约为 FP16 的 1/4 左右），对显存非常友好，但更容易出现输出质量下降、数学/代码能力退化或生成不稳定。

实践经验：

• 想“稳”，先 INT8；想“塞进显存”，再考虑 INT4。
• 对于 7B/8B 模型，INT4 常用于单卡 8GB/12GB 部署；对 13B/14B，INT4 能显著降低门槛。

量化粒度（Granularity）

粒度越细，通常精度越好，但实现复杂度/开销也更高。

• per-tensor：整个张量共享一个 scale（尺度）；最省事但误差大。
• per-channel：常用于卷积/线性层的输出通道维度；精度更好。
• per-group（group-wise）：把通道切成组（如 group_size=128），每组一个 scale/zero-point；INT4 实战常用，是 GPTQ/AWQ 的典型设置。

对称/非对称量化

• 对称（symmetric）：zero-point=0，计算简单、硬件友好。
• 非对称（asymmetric）：允许 zero-point ≠ 0，能更好覆盖偏移分布，但实现更复杂。

LLM 权重量化里，很多方案会采用对称或近似对称的策略（尤其是 4bit 场景），以便 kernel 优化。

量化路线图：PTQ vs QAT

PTQ（Post-Training Quantization）训练后量化

不重新训练（或只用少量校准数据），对大模型最常用。

• 优点：成本低、速度快，适合部署落地。
• 缺点：极低位宽（如 INT4）时精度可能受损，需要更聪明的方法（GPTQ/AWQ）。

QAT（Quantization-Aware Training）量化感知训练

在训练中模拟量化误差，让模型学会“适应量化”。

• 优点：同位宽下精度往往更好。
• 缺点：训练成本高、工程复杂，且对大模型全量 QAT 很重。

本篇以 PTQ 实战为主：INT8/INT4 + GPTQ/AWQ。

GPTQ：更“数学”的 4bit 权重量化

GPTQ 的思路（用人话解释）

GPTQ（常见实现为 AutoGPTQ / GPTQ-for-LLaMa 等）属于训练后量化，但它不是简单四舍五入：

• 它按层（或按块）量化权重，并用二阶信息（近似 Hessian）来估计“哪些权重误差对输出影响更大”。
• 量化过程中会做误差补偿，使得量化后的层输出尽可能接近原始输出。

因此 GPTQ 常被认为是 INT4 PTQ 的强基线：在相同位宽下，它通常比朴素量化更稳。

什么时候选 GPTQ

• 你需要 4bit，并希望尽量保住通用能力。
• 你能接受量化过程较慢（尤其是大模型），并且愿意准备少量校准数据。
• 你的推理框架/内核对 GPTQ 支持成熟（例如部分 vLLM/ExLlama/AutoGPTQ 生态）。

GPTQ 实操步骤（可复用流程）

1）准备校准数据（Calibration Set）

校准数据不需要标注，关键是覆盖你的真实输入分布。

• 通用聊天模型：抽取 200~2000 条高质量中文/英文对话、指令、百科段落。
• 代码模型：加入代码片段、注释、报错日志。
• 业务模型：加入真实工单/问答（注意脱敏）。

建议：

• 校准长度别太短，尽量包含 512~2048 token 的样本，模拟长上下文下的分布。

2）选择量化配置

常用设置（经验向）：

• bits=4
• group_size=128（或 64）
• desc_act=False/True（某些实现里会影响速度与精度，需实测）

原则：

• group_size 越小通常越准，但速度/存储元数据开销可能上升。

3）执行量化并导出

量化产物通常包含：

• 量化后的权重
• scale/zero-point（或类似量化参数）
• 以及对应推理内核需要的格式

你要确认：

• 导出格式能被你的推理引擎加载（Hugging Face、GGUF、ExLlama 格式各不相同）。

4）快速回归测试（必做）

不要只看困惑度（PPL），还要看任务表现：

• 闭卷问答：准确率是否下降明显
• 指令跟随：是否变“迟钝”或“胡言乱语”
• 数学：是否更容易算错
• 长文总结：是否更容易遗漏关键点

建议准备一个最小评测集（例如 50~200 条），每次量化都跑一遍，保证可对比。

AWQ：更偏工程与分布观测的“激活感知”量化

AWQ 的思路

AWQ（Activation-aware Weight Quantization）强调：

• 仅看权重分布不够，要看激活（activation）如何“使用”这些权重。
• 通过少量校准数据观察激活分布，找出对输出更关键的通道/权重，对它们做“保护”（比如缩放、重参数化），从而让 4bit 更稳。

直观理解：

• GPTQ 更像“解一道最小误差优化题”；
• AWQ 更像“看模型在真实输入下哪些通道最重要，然后尽量别伤到它”。

什么时候选 AWQ

• 你希望 4bit 推理速度更好（很多 AWQ kernel 在实际吞吐上表现不错）。
• 你要做线上高并发服务，吞吐敏感。
• 你希望量化耗时相对可控，且生态支持完善（不少部署框架对 AWQ 较友好）。

AWQ 实操步骤（可复用流程）

1）准备校准数据（同样关键）

AWQ 强依赖“激活观测”，因此校准数据要尽量贴近真实业务。

• 通用：500~2000 条指令/段落
• 垂类：尽量覆盖业务高频意图 + 长尾意图

2）选择关键超参

常见可调项：

• bits=4
• group_size=128
• 校准样本数（越多越稳，但越慢）

如果你的模型出现明显退化，可以尝试：

• 增加校准样本数
• 减小 group_size
• 检查是否有特殊层需要跳过量化（某些实现允许 exclude layers）

3）导出与加载

注意不同框架的 AWQ 模型格式差异（HF 权重目录结构、量化参数命名、kernel 依赖等）。上线前务必做：

• 冷启动加载时间测试
• 并发下显存峰值测试

INT8 实战：别忽略“最稳的性价比选项”

很多团队一上来就追 INT4，结果花很多时间排查精度问题。实际上，INT8 在大量业务里已经足够：

• 精度损失通常更小
• 内核支持广（GPU/CPU/推理卡）
• 调参成本低

INT8 的常见路径

• 权重 INT8（W8）+ 激活保持 FP16/BF16（A16）
• 或权重 INT8 + 激活 INT8（需要更强硬件/内核支持，且更易掉点）

经验建议：

• 若你是第一次做量化上线：优先 W8A16，快速获得收益。

精度-速度权衡：用可量化指标做决策

量化方案选择不要凭感觉，建议建立最小指标体系：

1）速度指标

• TTFT（Time To First Token）：首 token 延迟
• TPOT（Time Per Output Token）：后续每 token 延迟
• 吞吐（tokens/s 或 req/s）：尤其在并发下

2）资源指标

• 峰值显存（max VRAM）
• 常驻显存（steady VRAM）
• CPU 内存占用（尤其是 offload 场景）

3）质量指标

• 离线评测：自建 50~200 条关键用例 + 公共集（如 MMLU/CMMLU 的子集）
• 线上指标：人工抽检 + 业务 KPI（解决率、转人工率、满意度等）

4）推荐决策表（经验向）

• 显存够、追稳：FP16/BF16 或 INT8
• 显存紧、质量仍重要：AWQ 4bit 或 GPTQ 4bit（先各跑一轮你的用例）
• 极限省显存/边缘设备：INT4（可能还要配合更激进的推理优化，如 KV Cache 优化、分页注意力等）

常见坑与排查清单（实战很关键）

坑 1：校准数据“太随意”

症状：量化后模型在特定业务输入下明显变差。

解决：

• 用真实分布数据做校准（脱敏）
• 覆盖长文本与高频意图
• 校准样本数至少几百条起步

坑 2：只看 PPL 不看任务

症状：PPL 差不多，但业务效果明显下降。

解决：

• 建立业务用例集（强建议）
• 对关键用例设定“不可退化阈值”（例如准确率/通过率下降不超过 1~2%）

坑 3：推理内核不匹配导致“量化了但不快”

症状：模型更小了，但 tokens/s 提升不明显。

解决：

• 确认使用了对应的量化 kernel（很多框架需要显式开启）
• 排查瓶颈是否在 KV Cache / 解码策略 / CPU-GPU 数据传输
• 用 profiler 看时间花在哪

坑 4：部分层量化导致输出崩坏

症状：模型出现重复、乱码、极端幻觉。

解决：

• 尝试跳过 embedding、lm_head 或特定敏感层的量化（视实现支持）
• 从 INT8 退一步，再逐步压到 INT4
• 调整 group_size、增加校准数据

一个“从零到上线”的量化落地模板

下面给一个你可以直接套用的项目流程（不绑定具体工具链，但逻辑通用）：

H3 1）确定目标与约束

• 目标：单卡 24GB 跑 13B，吞吐提升 1.5 倍，质量下降不超过 2%
• 约束：必须兼容现有推理服务（如 vLLM / TensorRT-LLM / 自研引擎）

H3 2）准备三套候选

• 方案 A：FP16/BF16（基线）
• 方案 B：INT8（W8A16）
• 方案 C：INT4（AWQ 或 GPTQ，各做一版）

H3 3）统一评测脚本与指标

• 同一批请求、同一并发、同一生成参数（temperature/top_p/max_tokens）
• 记录 TTFT/TPOT/tokens/s/显存峰值
• 记录关键用例通过率

H3 4）做一次“灰度上线”

• 先让 1% 流量走量化模型
• 重点监控：转人工率、投诉率、异常输出比例
• 通过后逐步放量

H3 5）保留回滚与多模型策略

• 高风险请求（如金融合规）可路由到高精度模型
• 低风险/高并发请求用量化模型

这通常比“全量一刀切”更稳。

结语：如何在 GPTQ 与 AWQ 之间做最终选择

如果你只有一句话的选择策略：

• 先 INT8 快速拿收益，再用 AWQ/GPTQ 做 INT4 冲极限。
• AWQ 更偏工程吞吐与线上表现，GPTQ 更偏精度优化与误差补偿；最终以你的业务用例实测为准。

在本系列后续内容里，你可以把量化与 KV Cache 优化、并发调度、推理框架内核选择组合起来，形成一套完整的“低成本高吞吐”落地方案。