模型部署与推理优化02量化原理与实践INT8 矩阵乘、校准、QAT 与 LLM 量化模型部署做到后期十有八九会遇到同一个坎模型太大、推理太慢、显存吃紧。这时候量化几乎是绕不开的解药。所谓量化就是把 FP32/FP16 的权重和激活值压到 INT8 甚至更低精度用更少的比特存数据、做运算。模型体积能缩小到原来的四分之一左右推理速度在 Intel CPU 上实测最高能拉到 3 到 4 倍在 GPU 上配合 TensorRT 也有肉眼可见的收益。代价是精度会增加一点损失但操作得当掉点控制在 2% 以内完全可行。这篇文章是我在多个落地项目里反复折腾量化之后整理的完整笔记覆盖 INT8 矩阵乘的数学原理、PTQ训练后量化里的校准实操、QAT量化感知训练的落地姿势以及 LLM 时代量化方案的新变化。无论你是刚接触部署的新手还是已经被量化坑过几次的工程师都可以直接把这套方法拿回自己项目里用至少能帮你少走不少弯路。1. 量化到底是件什么事从存储压缩到计算加速的全链路改造1.1 量化前后模型内部发生了什么先绕开公式用最直白的话描述量化原本一个参数用 32 位浮点数保存FP32权重范围大概在 -3.4e38 到 3.4e38 之间精细但浪费。量化就是把这个连续的浮点范围映射到 256 个离散整数上INT8 就是 -128 到 127这个映射过程可以做到几乎无损因为神经网络权重的分布通常非常集中大量数值落在很小的区间里真正用到 3.4e38 这种大数的情况少之又少。以 ResNet-50 为例我做过一次全模型权重分布统计95% 以上的权重绝对值集中在 0.001 到 1.0 这个区间内FP32 提供的巨大动态范围对这部分参数来说完全是浪费。量化做的就是专门针对这个有效范围重新校准刻度。映射完成之后存储上从 4 字节降到 1 字节模型文件直接缩水 75%计算上INT8 乘加运算在 CPU 上走 AVX512 指令集、在 GPU 上走 Tensor Core算力利用率远高于浮点运算。真正让量化能跑得又快又稳的关键在于矩阵乘法这一计算核心的改造。一个典型的 GEMM通用矩阵乘运算是C A × BA 是激活值B 是权重权重可以提前离线量化好激活值却要在推理时动态量化。这引出一个问题两个 INT8 矩阵相乘结果溢出怎么办INT8 乘 INT8 得到 INT16累加 32 次就可能溢出 INT16 范围所以硬件上普遍采用 INT8 乘法 INT32 累加的策略。这个过程涉及一个数学上需要小心推导的公式我放到下一节专门展开。1.2 量化的两类落地方案纯压缩存储还是连同算子一起替换搞清楚量化改了什么还要搞清楚量化发生在哪个阶段这决定了部署后能不能真正提速。如果只做存储层量化比如用torch.save把 FP16 权重转成 INT8 存起来省的是磁盘空间和加载时间但推理时还是要把权重还原成 FP32/FP16 做浮点运算计算速度没有提升。我见过很多新手以为跑完量化脚本就等于优化完推理了结果一测延迟反而变高了就是因为多了反量化这一步。真正的加速量化必须连带算子一起替换也就是让权重保持 INT8 状态直接参与计算同时激活值也量化为 INT8乘加过程完全在整数域完成最后再反量化回浮点输出给下一层。这要求推理引擎支持 INT8 GEMM 算子比如 TensorRT 的IQuantizeLayer、ONNX Runtime 的QLinearMatMul、OpenVINO 的 INT8 内核或者自定义的 C/汇编级算子。计划采用量化优化之前一定要先确认自己的部署推理框架支持哪种量化模式这将直接影响后续方案设计。2. 量化背后的数学从浮点映射到 INT8 矩阵乘2.1 对称量化与非对称量化的取舍量化最核心的数学问题是怎么把浮点实数r映射成整数q。两种主流方案对称量化和非对称量化。对称量化采用最简单的映射方式r S × q其中S是缩放因子scaleq的取值区间是 [-128, 127]INT8。公式上看对称量化把浮点零点映射到整数零点中间不需要额外的偏移。它的优势是计算简单硬件实现起来也省事。问题在于如果权重分布是 [-0.1, 0.2] 这种非对称区间对称量化会用 [-0.2, 0.2] 的范围去覆盖可表示精度直接浪费一半。实测 MobileNet 这类轻量网络的权重经常呈现这种偏斜分布对称量化掉点会更明显。非对称量化多引入一个零点zero pointZ公式变成r S × (q - Z)。能精确覆盖浮点区间的最小值到最大值精度上比对称方案更优。代价是需要同时维护 scale 和 zero point 两个参数计算时多一次减法操作。在 CPU 上处理卷积层时非对称量化反而比对称方案更常见因为卷积核权重分布通常偏斜明显GPU 上 Tensor Core 对矩阵乘计算更喜欢对称形式实际部署中更多采用对称方案。量化类型映射公式适用场景硬件支持情况对称量化r S × q权重分布接近以零为中心的模型GPU Tensor Core、Intel CPUAVX512非对称量化r S × (q - Z)卷积层激活值分布有明显偏置CPU 通用、部分 NPU 不支持2.2 两层 GEMM 的 INT8 推演全流程矩阵乘的量化不是简单地把输入和权重都转成 INT8 然后相乘。要把数学账算清楚必须同时考虑两层变换。设输入激活为X量化为X_int和S_X权重W量化为W_int和S_W输出为Y。浮点矩阵乘是Y X × W将量化后的值代入Y S_X × S_W × (X_int × W_int)现在关键来了X_int和W_int相乘的结果是 INT32 累加和这一步在硬件上执行的是 INT8×INT8INT32 运算S_X × S_W是浮点缩放。最后要得到浮点输出需要把 INT32 的结果乘以S_X × S_W这个标量再反量化到 FP32。所以完整流程是Y_int32 X_int × W_int→Y ≈ S_X × S_W × Y_int32→ 如果需要变成 INT8 输出下一层是量化算子还要再做一次量化。我在 TensorRT 里调试连载模型时发现层与层之间如果频繁执行反量化到 FP32 再重新量化到 INT8精度损失会积累得非常快。解决办法是尽量保持数据在整数域流转把中间结果直接按照下一层的量化参数输出也就是做量化-缩放融合scale fusion。这个技巧在深层的 CNN 模型上尤其重要ResNet-50 的 50 层里每层都做一次浮点中间转换误差叠加起来远超单层误差。2.3 为什么每通道量化经常比每张量量化好用说完了符号再讨论一个关键的实际选择。一组权重矩阵是整体用一个 scale还是每个输出通道各用一个 scale第一直觉往往是统一 scale 省事。但实际情况是卷积核的权重在通道维度上的数值范围差异很大特别是 MobileNet 这类深度可分离卷积逐通道卷积的每个卷积核数值分布差异非常大。统一量化时范围大的通道把 scale 拉大范围小的通道精度就会严重受损。每通道量化per-channel为每个输出通道独立计算 scale 和 zero point存储上多占用几个字节的参数但精度提升显著。我在 MobileNetV2 上实测过per-tensor每张量统一 scale和 per-channel 的精度差距在 ImageNet 上可以达到 2.5% 以上per-channel 几乎无损。好消息是per-channel 在推理引擎上已经是常规操作TensorRT 和 ONNX Runtime 都原生支持部署时不需要额外做复杂的算子适配。激活值那边通常用 per-tensor 就够了因为激活值分布受输入影响逐通道统计激活值需要在推理时额外遍历成本高收益小。业界标准做法是权重 per-channel激活 per-tensor这个配置基本能覆盖绝大多数 CNN 模型的需求。3. PTQ 实操校准算法选型和完整步骤3.1 四种主流校准算法的对比和选型逻辑训练后量化PTQ最大的挑战是权重可以直接算 scale激活值的 scale 却不知道。激活量化范围必须通过跑数据、统计数据分布来估计这个过程叫校准calibration。校准算法的目标就是找到合适的激活量化范围让量化后的信息损失最小。我踩过的坑不少这里直接把我实测后推荐的做法写出来。MinMax 校准最简单直接统计校准集上激活值的最小值和最大值scale 就取这个区间。计算量最小但抗噪声能力弱如果某个批次出现一个大数值的异常激活整体范围会被撑大大量数值挤在很小的区间里精度损失急剧上升。百分位Percentile校准给 MinMax 打了补丁取分布上的某个百分位比如 99.99%把这个点作为范围的边界超出边界的值做截断。这个方法对长尾分布的激活值非常友好是我的默认选择。KL 散度校准也叫熵校准是另一个常用方案把 FP32 激活的直方图和不同量化边界模拟出的 INT8 分布做对比选择 KL 散度最小的边界作为量化范围。问题在于它假设网络层的激活分布接近已知的概率分布实际场景中不总是成立。优点是鲁棒性较好缺点是耗时明显偏长。MSE 校准则是计算不同量化边界下的均方误差取误差最小的值。理论上是目标导向的校准方式但依赖校准集的代表性如果校准集和实际推理数据的分布差异过大效果反而不好。实际操作中的经验校准方法优点缺点推荐场景MinMax速度最快易受异常值影响激活范围极稳定的简单网络Percentile抗噪声、快需要调百分位参数大多数 CNN 模型的首选KL散度理论支撑强校准耗时长、对分布敏感分布形态相对规整的分类模型MSE目标直接、精度可控计算量大对精度极度敏感的小模型需要特别提醒的是校准集不是训练集。校准集应当从真实部署场景分布中抽取包含足够多样的样本但量不需要多——一般 1000 张图就够了我见过有人用 5 万张图做校准纯粹是浪费计算资源。校准本质是统计分布不是训练模型样本覆盖关键模式即可。3.2 使用 ONNX Runtime 完成一次完整 PTQ下面是用 ONNX Runtime 的量化工具跑通一个 CNN 模型 PTQ 的完整过程。我用的是 PyTorch 导出的 ONNX 模型目标是把它量化成 INT8 之后用 ONNX Runtime 部署到 CPU 上。# 步骤 1准备校准数据加载器 # 关键点使用真实数据管线的子集避免用数据增强后的图片做校准 from torch.utils.data import DataLoader from torchvision import datasets, transforms calib_dataset datasets.ImageFolder( root./calib_images, transformtransforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) ) calib_loader DataLoader(calib_dataset, batch_size32, shuffleTrue, num_workers4) # 步骤 2配置量化器参数 from onnxruntime.quantization import QuantType, QuantFormat from onnxruntime.quantization.quant_utils import QuantizationMode # QuantFormat.QDQ 是推荐选择模型内保留 QuantizeLinear/DeQuantizeLinear 节点 # 便于在不同后端间移植也方便后续用图优化工具进一步优化然后指定量化配置from onnxruntime.quantization import quantize_static, QuantType, QuantFormat quant_config { per_channel: True, # 权重使用 per-channel 量化 reduce_range: False, # 是否限制到 [-64, 63]某些老硬件不支持完整 INT8 activation_type: QuantType.QInt8, weight_type: QuantType.QInt8, } quantize_static( model_inputmodel_fp32.onnx, model_outputmodel_int8.onnx, calibration_data_readercalib_loader, # 校准数据读入器 quant_formatQuantFormat.QDQ, per_channelTrue, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, calibrate_methodCalibrationMethod.Percentile, # 这里我选了百分位校准 extra_options{ ActivationSymmetric: True, # 激活值使用对称量化Intel CPU 上效率更高 WeightSymmetric: True, CalibRange: percentile_99.99, } )跑完这段代码model_int8.onnx就是量化后的模型。必须先确认算子确实跑在 INT8 内核上才能获得加速ONNX Runtime 本身不会自动打印每条算子的执行后端需要靠 profiler 确认import onnxruntime as ort sess_options ort.SessionOptions() sess_options.enable_profiling True session ort.InferenceSession(model_int8.onnx, sess_options, providers[CPUExecutionProvider]) # 跑一次推理 output session.run(None, {input: sample_input}) # 从生成的 profiler 文件中检索 QLinearConv 或 MatMulInteger 等算子执行记录如果 profiler 里看到的还是Conv而不是QLinearConv说明模型里有一部分算子没有被量化框架覆盖要么换更新的 ONNX 算子集版本要么手动切分模型单独量化。3.3 PTQ 精度验收的三条铁律PTQ 做完别急着上线精度验收有标准动作盲目上线掉点会让你后期排查成本非常高。第一条刷一遍完整验证集别只跑几十张图感觉差不多就完事。量化误差在小样本上波动非常大20 张图看不出问题换一批图可能掉点 3%。我习惯的做法是把完整验证集跑完记录 top-1/top-5 或 mAP和 FP32 基线对比放行标准一般是分类模型掉点 0.5%检测模型掉点 1.5%。如果超过直接进入后续排查流程想办法优化而不是硬上线。第二条用真实部署的数据分布测试。校准集和线下验证集分布不一致是量化掉点最大的隐藏原因。举一个真实例子在校准集上模型精度只掉了 0.3%但上线后线上数据掉点 5%。后来排查发现校准集是白天户外拍摄的图片而线上实际流量有大量的夜间低光照图片。解决办法是用线上日志里随机抽样一批数据重做校准集。第三条观察异常层的量化误差分布。精度不过关时不要盲目改校准方法或调百分位先用工具输出每一层的 FP32 输出和 INT8 输出之间的均方误差。找到误差最大的那一两层单独优化它们的量化策略。我印象很深的一次一个检测模型的 Neck 部分FPN 融合层误差是整个模型的 60 倍把 Neck 层单独设成 FP16 后整体掉点从 4.2% 降到 0.8%。4. QAT 实测把量化误差练进模型权重里4.1 伪量化节点与直通估计器STE的原理当 PTQ 掉点无法通过调整校准策略控制在可接受范围内时就该上 QAT量化感知训练了。QAT 的本质是在训练阶段就模拟量化误差让模型权重学会容忍量化噪声训练完成后模型的权重天然适应 INT8 表示。实现上QAT 在模型前向传播的权重和激活位置插入伪量化fake quant节点把一个浮点值转成 INT8 再转回浮点前向过程模拟了量化的精度损失反向传播时梯度却直接穿透这些节点跳过量化不可导的取整操作。这个机制称为 STEStraight-Through Estimator。为什么需要 STE取整操作在数学上是不可导的round(x)的梯度几乎处处为 0用标准反向传播训不动。STE 的做法是反向传播时把伪量化节点的梯度当作恒等函数处理梯度直接穿过。这个思路看上去有点蛮干但实践中效果非常好它近似等价于直接把浮点权重的梯度累加到量化后的权重用途上。伪量化节点的实现逻辑可以描述为# 伪量化模拟推理时的 INT8 量化过程 def fake_quantize(x, scale, zero_point, num_bits8): # 量化转成整数域这一步模拟了硬件的取整误差 x_int torch.round(x / scale) zero_point # 限制在可表示范围内 max_val 2 ** (num_bits - 1) - 1 min_val -max_val x_int torch.clamp(x_int, min_val, max_val) # 反量化变回浮点表示但这个浮点值已经带上了量化误差 return (x_int - zero_point) * scale前向过程这么模拟反向后向过程梯度直接跳过取整和 clamp 操作等价于把 x 原样传入梯度计算。PyTorch 的torch.quantization.FakeQuantize和torch.ao.quantization.QuantStub/DeQuantStub就是标准实现。4.2 PyTorch 中跑通 QAT 的完整步骤QAT 流程并不复杂但有几个细节直接决定成败。我给出一个经过验证的完整路径。第一步在 FP32 模型上微调一个 epoch 打底让权重处于合理状态。我用torch.ao.quantization.prepare_qat把模型准备好import torch import torch.ao.quantization as quant # 模型换成量化版结构把要融合的 BatchNorm 提前融合进 Conv model.qconfig quant.get_default_qat_qconfig(fbgemm) # 一定要先 fuse否则 BN 层的量化行为会不匹配 model torch.ao.quantization.fuse_modules(model, [[conv1, bn1, relu1], [conv2, bn2]]) # prepare_qat 会插入伪量化节点模型进入训练模式 quant.prepare_qat(model, inplaceTrue)紧接着的训练阶段有几个容易踩的坑学习率一定要调小。原模型微调用 1e-4QAT 阶段建议降到 1/10 甚至 1/20。伪量化节点引入了额外的噪声学习率大会让权重更新方向变得异常激烈损失很难收敛。我在 ResNet-50 上实测QAT 初始阶段 lr1e-5 起步后期逐步衰减到 1e-6效果最稳。BN 层统计量的处理要格外小心。QAT 训练分为两个阶段先正常训练、更新 BN 统计量再固定 BN 的 running stats、只更新权重。我在实际项目中遇到过一次模型权重收敛正常但量化后精度崩掉 8% 的情况后来查到是训练最后阶段 BN 统计量仍在更新和推理时的量化假设不一致导致的。所以 QAT 结束前的最后 10% 训练步数必须用model.eval()模式下的行为来固定 BN 统计量同时训练权重。第二步训练结束后执行convert把伪量化节点真正转成 INT8 算子model.eval() # 必须先切到eval模式 quant.convert(model, inplaceTrue) # convert后会得到一个只包含量化算子QuantizeLinear/DeQuantizeLinear的模型 # 导出到 ONNX 时用 opset 13 以上确保算子映射完整 torch.onnx.export(model, dummy_input, model_qat.onnx, opset_version13)之后用 ONNX Runtime 加载部署。这里要提醒QAT 必须在训练框架里完成不是部署框架的活不要想着在 ONNX 层面重放 QAT 逻辑。4.3 什么场景必须上 QAT三类避不开的情况QAT 的开销是再次训练一遍模型成本不低。如果 PTQ 能解决完全没必要上。我总结了三类必须 QAT 的场景。第一类模型太脆。小模型MobileNetV2、EfficientNet-Lite 这类轻量骨干本身参数量少、冗余度低量化误差无处消化PTQ 掉点经常超过 3%。通过在训练阶段加入量化噪声模拟权重会主动往对量化更友好的方向偏移掉点能压到 1% 以内。第二类包含对数值范围极度敏感的算子。比如检测模型里的 DCN可变形卷积v2、attention 机制里的 softmax 后特征这些算子对输入数值的微小扰动非常敏感。QAT 训练时让前置网络适应量化的粗糙精度可以显著缓解这种敏感度。第三类目标硬件是 NPU/ASIC 这类固定流程的芯片。这类芯片的量化规则比 GPU/CPU 更严格不支持灵活的 per-channel 或混合精度。在训练阶段严格按照芯片的量化规则做伪量化模拟是保证上板精度唯一可靠的路径。5. LLM 量化的特殊性与主流方案取舍5.1 大模型的激活值异常为什么 LLM 量化比 CNN 更棘手到了 LLM 时代量化策略必须重新思考。CNN 的激活值分布相对稳定用几千张图校准出来的 scale 基本能覆盖真实分布。但 LLM 的激活值中存在明显的离群点outlier——某些特定通道上的激活值能比平均水平大上百倍。这些离群通道通常集中在特定维度上比如大多数 Transformer 模型的第一层和最后的层中。后果是如果量化范围为了覆盖离群点而拉宽 scale正常值的量化精度会严重损失困惑度perplexity直接爆炸。如果把离群点截断掉模型语义能力可能受损回答问题开始语无伦次。一种直观的应对是动态量化dynamic quantization对激活值不做预校准而是在推理时动态统计当前 batch 的激活范围实时计算 scale。LLM 的 activation 分布随输入变化大动态量化精度比静态量化好得多代价是额外的时间开销在长序列生成任务上有明显性能损失。还有一种思路是直接保留混合精度权重做 INT8 量化激活中已知的离群通道继续用 FP16 存储。这对应到 LLM.int8() 这类分解方案。实际操作中torch 生态里的bitsandbytes库可以直接调用这个能力不需要写太多代码就把模型跑起来。5.2 GPTQ、AWQ 与 GGUF三种主流量化方案的定位对比LLM 量化早已不只是校准 转换更合理的框架是把量化本身做成一个优化问题。目前有几种主流的混合精度压缩方案关键词对上了 GPTQ、AWQ、GGUF我在下面展开参数和选择建议。GPTQ基于近似二阶信息的逐层量化是目前很有代表性的方案。它的核心做法是逐层处理权重矩阵对某一行的权重做量化同时用一个近似 Hessian 矩阵来估计量化误差然后对未量化的权重做补偿更新让整体输出误差最小化。效果上在 7B 到 70B 模型上都能做到 4-bit 甚至 3-bit 量化质量损失在可接受范围。它属于训练后量化的一种高级玩法不需要重新训练模型。AWQ激活值感知量化的出发点不同。GPTQ 只考虑权重AWQ 把激活值的分布也纳入考量通过统计激活值中影响大的通道给这些通道的权重更高的保护权重让量化过程重点保护这些通道的精度。实测下来 AWQ 在多数任务上的困惑度损失比 GPTQ 稍微小一点而且量化速度快不少。GGUF 是 llama.cpp 生态独占的格式它更像一种量化模型容器支持从 2-bit 到 8-bit 的各种量化方案如 Q4_K_M、Q5_K_M、Q8_0 等底层量化算法实际上采用了多种经典方案混合。社区的活跃度和模型的直接可用性让它成了在 CPU 上本地跑大模型的事实标准。方案基本思路位数支持优势典型场景GPTQ二阶近似补偿量化误差2/3/4/8-bit低比特下精度保持较好GPU 显存受限时的多数模型部署AWQ按激活通道重要度保护权重4/8-bit量化速度快、困惑度低快速验证、追求训练后最优精度GGUF统一封装的混合量化方案2~8-bit 多种细分档位与 llama.cpp 深度集成CPU 友好的算子本地 CPU 推理、对话机器人、嵌入式设备5.3 实操Transformers 生态里量化和部署的一种顺手路径在实际项目里我通常走两条路径。如果模型要部署到服务端 GPU优先用 GPTQ 或 AWQ 量化加载到 vLLM 或者 TGI 这类推理服务里如果要部署到笔记本/小主机上走 GGUF llama.cpp或 Ollama。下面以 Transformers 生态的例子做演示。在 HFace 生态中用 Transformers 加载一个已经量化好的 AWQ 模型from transformers import AutoModelForCausalLM, AutoTokenizer, AwqConfig # 模型路径换成你用 AWQ 量化工具处理过权重的目录 model_id your/model-awq # AWQ 需要显式声明量化配置否则默认还是会用FP16加载 quantization_config AwqConfig( bits4, group_size128, zero_pointTrue, versiongemm, # 在N卡上用gemm部分Intel/AMD环境可以换gemv ) model AutoModelForCausalLM.from_pretrained( model_id, quantization_configquantization_config, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_id)要提醒的是group_size是一个非常关键的超参数它表示每多少个权重共享一个 scale。group_size 越小量化控制越精确但存储开销也越大group_size128 在精度和体积之间算比较均衡的选择group_size32 的精度更好但显存和带宽开销会明显上升。如果想自己动手做 AWQ 量化官方工具链 awq 提供了脚本quantize_weights.py输入 HF 格式模型直接输出量化权重整个过程不需要标定数据做训练十分钟左右就能跑完。这一步本质上是少量样本级别的校准过程——AWQ 会扫描模型权重和激活分布不需要像 PTQ 那样为每个算子准备专门校准集所以速度快。5.4 KV cache 量化生成式 LLM 推理的一条补充优化线LLM 推理还有一个经常被忽略的显存大户——KV cache键值缓存。生成式模型逐 token 输出时每生成一个新 token都需要把当前 token 对应的 K、V 向量追加到缓存里缓存会随序列长度线性增长。长对话场景中 KV cache 占用的显存甚至能超过模型权重本身。KV cache 量化的逻辑和权重量化完全不同KV cache 是推理过程中动态生成的不经过训练。做 PTQ 式的校准意义不大更常见的是动态量化——在写入缓存时把 FP16 的 K/V 转成 INT8读取时反量化回 FP16 参与 attention 计算。这种做法的精度损失在大多数任务上都可接受但长上下文的翻译或摘要任务上需要多做验证。在 Transformers 生态里设置 KV cache 量化非常直接from transformers import AutoModelForCausalLM, BitsAndBytesConfig model AutoModelForCausalLM.from_pretrained( your/model, quantization_configBitsAndBytesConfig( load_in_8bitTrue, llm_int8_enable_fp32_cpu_offloadFalse, ) ) # 在 generate 函数中加入 kv_cache 量化开关 output model.generate( inputs, use_cacheTrue, cache_implementationquantized, cache_config{n_bits: 8}, )量化 KV cache 后实测 7B 模型的上下文长度能扩展将近一倍在 24GB 显存的环境下测的原来最长支持 8K 上下文量化后能跑到 12K 以上生成速度因为显存带宽瓶颈缓解也有 15% 到 20% 的提升。但如果跑长文档摘要这类对数值精度敏感的任务要重点验证 KV cache 量化后 ROUGE 分数没有明显下降。6. 量化实践中的常见问题与排查实录6.1 掉点严重的几个元凶BN 融合与校准集分布一路写下来把几个最容易踩的坑集中整理成速查表方便大家排查现场问题。现象特征根本原因解决手段FP32 精度高INT8 掉点 5% 以上BatchNorm 没有融合进卷积在导出前先执行 fold BN 操作ONNX Runtime 里检查图中是否还有独立 BN 节点均匀掉点 2% 左右校准集与线上数据分布不一致用线上真实采样的数据子集重新校准百分位调到 99.99%个别层掉点极其严重该层激活分布有离群通道对该层单独做 per-channel 激活量化或者混合精度该层保留 FP16量化后 CPU 推理变慢算子未映射到 INT8 内核做了反量化来回转换检查是否用了支持 QLinearConv/IntegerOps 的 execution provider并查看 profiler 日志BN 融合问题在 QAT 里也暴露过具体表现是训练阶段 loss 很正常一旦 convert 完精度暴跌。解剖后发现的原因是折叠 BN 时把 BN 的均值和方差直接融进了卷积权重如果融合顺序不对卷积的 scale 计算就会出现方向性错误。建议在任何量化流程之前先用fuse_modules把 BN 融合干净很多莫名其妙的精度问题都会因此消失。6.2 一张量化精度诊断表我实测下来的参考值最后给出一个参考精度数据这是我在多个公开模型上的实测结果可以当作自己的排查基准。模型FP32 Top-1PTQ INT8 Top-1QAT INT8 Top-1PTQ 掉点ResNet-5076.15%75.41%75.98%0.74%MobileNetV271.88%69.02%71.45%2.86%EfficientNet-B077.10%73.80%76.60%3.30%YOLOv5s (COCO mAP)37.435.136.92.3从表里能看到模型越小、结构越轻量PTQ 掉点越夸张。MobileNetV2 和 EfficientNet 这类深度可分离卷积为主的模型PTQ 掉点普遍在 2.5% 到 3.5% 这个范围内接近及格边缘。遇到这种模型就别死磕 PTQ 的校准方法了直接上 QAT 才是正解。6.3 量化算子的落盘问题精度挺好但加速为负的常见原因还有一种情况需要单独提出来量化后模型测出来精度确实没怎么掉但推理延迟不降反升。我排查过好几次90% 以上的原因都是量化算子没有真正落到硬件加速内核上。在 CPU 上矩阵乘走没走 INT8 加速要看算子是否能被调度到 oneDNN即 mkl-dnn的 INT8 原语。检查方法ONNX Runtime 打开日志看算子名称是不是QLinearConv或者MatMulInteger如果是Conv和MatMul说明根本没量化成功。在 Intel CPU 上还有一个隐蔽问题受支持的 AVX512 指令集部署。如果推理机的 CPU 是低端型号比如部分嵌入式赛扬它根本不支持 AVX512 的 INT8 指令扩展即使量化成功也会降级走标量路径。这种环境建议直接用reduce_rangeTrue之类的安全量化配置不要强行追求最大精度。在 GPU 上NVIDIA TensorRT 的 INT8 走的是 Tensor Core要求 shape 对齐到 32 的倍数。如果你的模型输入是 224×224 图片卷积的 channel 数不是 32 的倍数比如 ECA-Net 这种在通道数上做过裁剪的模型TensorRT 会静默降级回 FP32 实现。这个排查的难度比较高输出日志里一般不会有警告建议在构建 TensorRT engine 时开启 verbose 去确认kernelName是否落在sm80_xmma系列针对 A100或者类似sm86_xmma针对 3090/3080 等另外留意一些算子的Kernel字段是否带int8标识。写在最后的几点心得前面写了很多原理、流程和踩坑记录到这儿再把个人体会补两句。量化这种优化手段关键不在于把代码跑通而在于对整个链路有精确把握。什么时候用 PTQ、什么时候必须 QAT校准集到底选多少数据per-channel 开不开这些决定不是靠调参试出来的而是建立在你对模型结构、部署硬件和线上数据分布的准确理解之上。我自己在做量化的过程中体会到有三件事性价比最高一是把校准集真正做成线上分布模拟器这是最便宜、最有效的掉点杀手二是学会看 profiler 日志而不是只信直觉很多性能问题一眼就能从算子调度记录里定位三是善用混合精度不要追求全模型 INT8让敏感层留在 FP16整体精度和性能通常能达到最优平衡点。模型量化不是把精度换成速度的单向交易而是一场在精度、体积、延迟之间找平衡的系统工程。整体做完之后建议再回头验证一次真实业务场景里的指标变化数据会告诉你方案是不是真的有效。
模型部署与推理优化：INT8量化原理、PTQ/QAT实操与LLM量化方案
模型部署与推理优化02量化原理与实践INT8 矩阵乘、校准、QAT 与 LLM 量化模型部署做到后期十有八九会遇到同一个坎模型太大、推理太慢、显存吃紧。这时候量化几乎是绕不开的解药。所谓量化就是把 FP32/FP16 的权重和激活值压到 INT8 甚至更低精度用更少的比特存数据、做运算。模型体积能缩小到原来的四分之一左右推理速度在 Intel CPU 上实测最高能拉到 3 到 4 倍在 GPU 上配合 TensorRT 也有肉眼可见的收益。代价是精度会增加一点损失但操作得当掉点控制在 2% 以内完全可行。这篇文章是我在多个落地项目里反复折腾量化之后整理的完整笔记覆盖 INT8 矩阵乘的数学原理、PTQ训练后量化里的校准实操、QAT量化感知训练的落地姿势以及 LLM 时代量化方案的新变化。无论你是刚接触部署的新手还是已经被量化坑过几次的工程师都可以直接把这套方法拿回自己项目里用至少能帮你少走不少弯路。1. 量化到底是件什么事从存储压缩到计算加速的全链路改造1.1 量化前后模型内部发生了什么先绕开公式用最直白的话描述量化原本一个参数用 32 位浮点数保存FP32权重范围大概在 -3.4e38 到 3.4e38 之间精细但浪费。量化就是把这个连续的浮点范围映射到 256 个离散整数上INT8 就是 -128 到 127这个映射过程可以做到几乎无损因为神经网络权重的分布通常非常集中大量数值落在很小的区间里真正用到 3.4e38 这种大数的情况少之又少。以 ResNet-50 为例我做过一次全模型权重分布统计95% 以上的权重绝对值集中在 0.001 到 1.0 这个区间内FP32 提供的巨大动态范围对这部分参数来说完全是浪费。量化做的就是专门针对这个有效范围重新校准刻度。映射完成之后存储上从 4 字节降到 1 字节模型文件直接缩水 75%计算上INT8 乘加运算在 CPU 上走 AVX512 指令集、在 GPU 上走 Tensor Core算力利用率远高于浮点运算。真正让量化能跑得又快又稳的关键在于矩阵乘法这一计算核心的改造。一个典型的 GEMM通用矩阵乘运算是C A × BA 是激活值B 是权重权重可以提前离线量化好激活值却要在推理时动态量化。这引出一个问题两个 INT8 矩阵相乘结果溢出怎么办INT8 乘 INT8 得到 INT16累加 32 次就可能溢出 INT16 范围所以硬件上普遍采用 INT8 乘法 INT32 累加的策略。这个过程涉及一个数学上需要小心推导的公式我放到下一节专门展开。1.2 量化的两类落地方案纯压缩存储还是连同算子一起替换搞清楚量化改了什么还要搞清楚量化发生在哪个阶段这决定了部署后能不能真正提速。如果只做存储层量化比如用torch.save把 FP16 权重转成 INT8 存起来省的是磁盘空间和加载时间但推理时还是要把权重还原成 FP32/FP16 做浮点运算计算速度没有提升。我见过很多新手以为跑完量化脚本就等于优化完推理了结果一测延迟反而变高了就是因为多了反量化这一步。真正的加速量化必须连带算子一起替换也就是让权重保持 INT8 状态直接参与计算同时激活值也量化为 INT8乘加过程完全在整数域完成最后再反量化回浮点输出给下一层。这要求推理引擎支持 INT8 GEMM 算子比如 TensorRT 的IQuantizeLayer、ONNX Runtime 的QLinearMatMul、OpenVINO 的 INT8 内核或者自定义的 C/汇编级算子。计划采用量化优化之前一定要先确认自己的部署推理框架支持哪种量化模式这将直接影响后续方案设计。2. 量化背后的数学从浮点映射到 INT8 矩阵乘2.1 对称量化与非对称量化的取舍量化最核心的数学问题是怎么把浮点实数r映射成整数q。两种主流方案对称量化和非对称量化。对称量化采用最简单的映射方式r S × q其中S是缩放因子scaleq的取值区间是 [-128, 127]INT8。公式上看对称量化把浮点零点映射到整数零点中间不需要额外的偏移。它的优势是计算简单硬件实现起来也省事。问题在于如果权重分布是 [-0.1, 0.2] 这种非对称区间对称量化会用 [-0.2, 0.2] 的范围去覆盖可表示精度直接浪费一半。实测 MobileNet 这类轻量网络的权重经常呈现这种偏斜分布对称量化掉点会更明显。非对称量化多引入一个零点zero pointZ公式变成r S × (q - Z)。能精确覆盖浮点区间的最小值到最大值精度上比对称方案更优。代价是需要同时维护 scale 和 zero point 两个参数计算时多一次减法操作。在 CPU 上处理卷积层时非对称量化反而比对称方案更常见因为卷积核权重分布通常偏斜明显GPU 上 Tensor Core 对矩阵乘计算更喜欢对称形式实际部署中更多采用对称方案。量化类型映射公式适用场景硬件支持情况对称量化r S × q权重分布接近以零为中心的模型GPU Tensor Core、Intel CPUAVX512非对称量化r S × (q - Z)卷积层激活值分布有明显偏置CPU 通用、部分 NPU 不支持2.2 两层 GEMM 的 INT8 推演全流程矩阵乘的量化不是简单地把输入和权重都转成 INT8 然后相乘。要把数学账算清楚必须同时考虑两层变换。设输入激活为X量化为X_int和S_X权重W量化为W_int和S_W输出为Y。浮点矩阵乘是Y X × W将量化后的值代入Y S_X × S_W × (X_int × W_int)现在关键来了X_int和W_int相乘的结果是 INT32 累加和这一步在硬件上执行的是 INT8×INT8INT32 运算S_X × S_W是浮点缩放。最后要得到浮点输出需要把 INT32 的结果乘以S_X × S_W这个标量再反量化到 FP32。所以完整流程是Y_int32 X_int × W_int→Y ≈ S_X × S_W × Y_int32→ 如果需要变成 INT8 输出下一层是量化算子还要再做一次量化。我在 TensorRT 里调试连载模型时发现层与层之间如果频繁执行反量化到 FP32 再重新量化到 INT8精度损失会积累得非常快。解决办法是尽量保持数据在整数域流转把中间结果直接按照下一层的量化参数输出也就是做量化-缩放融合scale fusion。这个技巧在深层的 CNN 模型上尤其重要ResNet-50 的 50 层里每层都做一次浮点中间转换误差叠加起来远超单层误差。2.3 为什么每通道量化经常比每张量量化好用说完了符号再讨论一个关键的实际选择。一组权重矩阵是整体用一个 scale还是每个输出通道各用一个 scale第一直觉往往是统一 scale 省事。但实际情况是卷积核的权重在通道维度上的数值范围差异很大特别是 MobileNet 这类深度可分离卷积逐通道卷积的每个卷积核数值分布差异非常大。统一量化时范围大的通道把 scale 拉大范围小的通道精度就会严重受损。每通道量化per-channel为每个输出通道独立计算 scale 和 zero point存储上多占用几个字节的参数但精度提升显著。我在 MobileNetV2 上实测过per-tensor每张量统一 scale和 per-channel 的精度差距在 ImageNet 上可以达到 2.5% 以上per-channel 几乎无损。好消息是per-channel 在推理引擎上已经是常规操作TensorRT 和 ONNX Runtime 都原生支持部署时不需要额外做复杂的算子适配。激活值那边通常用 per-tensor 就够了因为激活值分布受输入影响逐通道统计激活值需要在推理时额外遍历成本高收益小。业界标准做法是权重 per-channel激活 per-tensor这个配置基本能覆盖绝大多数 CNN 模型的需求。3. PTQ 实操校准算法选型和完整步骤3.1 四种主流校准算法的对比和选型逻辑训练后量化PTQ最大的挑战是权重可以直接算 scale激活值的 scale 却不知道。激活量化范围必须通过跑数据、统计数据分布来估计这个过程叫校准calibration。校准算法的目标就是找到合适的激活量化范围让量化后的信息损失最小。我踩过的坑不少这里直接把我实测后推荐的做法写出来。MinMax 校准最简单直接统计校准集上激活值的最小值和最大值scale 就取这个区间。计算量最小但抗噪声能力弱如果某个批次出现一个大数值的异常激活整体范围会被撑大大量数值挤在很小的区间里精度损失急剧上升。百分位Percentile校准给 MinMax 打了补丁取分布上的某个百分位比如 99.99%把这个点作为范围的边界超出边界的值做截断。这个方法对长尾分布的激活值非常友好是我的默认选择。KL 散度校准也叫熵校准是另一个常用方案把 FP32 激活的直方图和不同量化边界模拟出的 INT8 分布做对比选择 KL 散度最小的边界作为量化范围。问题在于它假设网络层的激活分布接近已知的概率分布实际场景中不总是成立。优点是鲁棒性较好缺点是耗时明显偏长。MSE 校准则是计算不同量化边界下的均方误差取误差最小的值。理论上是目标导向的校准方式但依赖校准集的代表性如果校准集和实际推理数据的分布差异过大效果反而不好。实际操作中的经验校准方法优点缺点推荐场景MinMax速度最快易受异常值影响激活范围极稳定的简单网络Percentile抗噪声、快需要调百分位参数大多数 CNN 模型的首选KL散度理论支撑强校准耗时长、对分布敏感分布形态相对规整的分类模型MSE目标直接、精度可控计算量大对精度极度敏感的小模型需要特别提醒的是校准集不是训练集。校准集应当从真实部署场景分布中抽取包含足够多样的样本但量不需要多——一般 1000 张图就够了我见过有人用 5 万张图做校准纯粹是浪费计算资源。校准本质是统计分布不是训练模型样本覆盖关键模式即可。3.2 使用 ONNX Runtime 完成一次完整 PTQ下面是用 ONNX Runtime 的量化工具跑通一个 CNN 模型 PTQ 的完整过程。我用的是 PyTorch 导出的 ONNX 模型目标是把它量化成 INT8 之后用 ONNX Runtime 部署到 CPU 上。# 步骤 1准备校准数据加载器 # 关键点使用真实数据管线的子集避免用数据增强后的图片做校准 from torch.utils.data import DataLoader from torchvision import datasets, transforms calib_dataset datasets.ImageFolder( root./calib_images, transformtransforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) ) calib_loader DataLoader(calib_dataset, batch_size32, shuffleTrue, num_workers4) # 步骤 2配置量化器参数 from onnxruntime.quantization import QuantType, QuantFormat from onnxruntime.quantization.quant_utils import QuantizationMode # QuantFormat.QDQ 是推荐选择模型内保留 QuantizeLinear/DeQuantizeLinear 节点 # 便于在不同后端间移植也方便后续用图优化工具进一步优化然后指定量化配置from onnxruntime.quantization import quantize_static, QuantType, QuantFormat quant_config { per_channel: True, # 权重使用 per-channel 量化 reduce_range: False, # 是否限制到 [-64, 63]某些老硬件不支持完整 INT8 activation_type: QuantType.QInt8, weight_type: QuantType.QInt8, } quantize_static( model_inputmodel_fp32.onnx, model_outputmodel_int8.onnx, calibration_data_readercalib_loader, # 校准数据读入器 quant_formatQuantFormat.QDQ, per_channelTrue, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, calibrate_methodCalibrationMethod.Percentile, # 这里我选了百分位校准 extra_options{ ActivationSymmetric: True, # 激活值使用对称量化Intel CPU 上效率更高 WeightSymmetric: True, CalibRange: percentile_99.99, } )跑完这段代码model_int8.onnx就是量化后的模型。必须先确认算子确实跑在 INT8 内核上才能获得加速ONNX Runtime 本身不会自动打印每条算子的执行后端需要靠 profiler 确认import onnxruntime as ort sess_options ort.SessionOptions() sess_options.enable_profiling True session ort.InferenceSession(model_int8.onnx, sess_options, providers[CPUExecutionProvider]) # 跑一次推理 output session.run(None, {input: sample_input}) # 从生成的 profiler 文件中检索 QLinearConv 或 MatMulInteger 等算子执行记录如果 profiler 里看到的还是Conv而不是QLinearConv说明模型里有一部分算子没有被量化框架覆盖要么换更新的 ONNX 算子集版本要么手动切分模型单独量化。3.3 PTQ 精度验收的三条铁律PTQ 做完别急着上线精度验收有标准动作盲目上线掉点会让你后期排查成本非常高。第一条刷一遍完整验证集别只跑几十张图感觉差不多就完事。量化误差在小样本上波动非常大20 张图看不出问题换一批图可能掉点 3%。我习惯的做法是把完整验证集跑完记录 top-1/top-5 或 mAP和 FP32 基线对比放行标准一般是分类模型掉点 0.5%检测模型掉点 1.5%。如果超过直接进入后续排查流程想办法优化而不是硬上线。第二条用真实部署的数据分布测试。校准集和线下验证集分布不一致是量化掉点最大的隐藏原因。举一个真实例子在校准集上模型精度只掉了 0.3%但上线后线上数据掉点 5%。后来排查发现校准集是白天户外拍摄的图片而线上实际流量有大量的夜间低光照图片。解决办法是用线上日志里随机抽样一批数据重做校准集。第三条观察异常层的量化误差分布。精度不过关时不要盲目改校准方法或调百分位先用工具输出每一层的 FP32 输出和 INT8 输出之间的均方误差。找到误差最大的那一两层单独优化它们的量化策略。我印象很深的一次一个检测模型的 Neck 部分FPN 融合层误差是整个模型的 60 倍把 Neck 层单独设成 FP16 后整体掉点从 4.2% 降到 0.8%。4. QAT 实测把量化误差练进模型权重里4.1 伪量化节点与直通估计器STE的原理当 PTQ 掉点无法通过调整校准策略控制在可接受范围内时就该上 QAT量化感知训练了。QAT 的本质是在训练阶段就模拟量化误差让模型权重学会容忍量化噪声训练完成后模型的权重天然适应 INT8 表示。实现上QAT 在模型前向传播的权重和激活位置插入伪量化fake quant节点把一个浮点值转成 INT8 再转回浮点前向过程模拟了量化的精度损失反向传播时梯度却直接穿透这些节点跳过量化不可导的取整操作。这个机制称为 STEStraight-Through Estimator。为什么需要 STE取整操作在数学上是不可导的round(x)的梯度几乎处处为 0用标准反向传播训不动。STE 的做法是反向传播时把伪量化节点的梯度当作恒等函数处理梯度直接穿过。这个思路看上去有点蛮干但实践中效果非常好它近似等价于直接把浮点权重的梯度累加到量化后的权重用途上。伪量化节点的实现逻辑可以描述为# 伪量化模拟推理时的 INT8 量化过程 def fake_quantize(x, scale, zero_point, num_bits8): # 量化转成整数域这一步模拟了硬件的取整误差 x_int torch.round(x / scale) zero_point # 限制在可表示范围内 max_val 2 ** (num_bits - 1) - 1 min_val -max_val x_int torch.clamp(x_int, min_val, max_val) # 反量化变回浮点表示但这个浮点值已经带上了量化误差 return (x_int - zero_point) * scale前向过程这么模拟反向后向过程梯度直接跳过取整和 clamp 操作等价于把 x 原样传入梯度计算。PyTorch 的torch.quantization.FakeQuantize和torch.ao.quantization.QuantStub/DeQuantStub就是标准实现。4.2 PyTorch 中跑通 QAT 的完整步骤QAT 流程并不复杂但有几个细节直接决定成败。我给出一个经过验证的完整路径。第一步在 FP32 模型上微调一个 epoch 打底让权重处于合理状态。我用torch.ao.quantization.prepare_qat把模型准备好import torch import torch.ao.quantization as quant # 模型换成量化版结构把要融合的 BatchNorm 提前融合进 Conv model.qconfig quant.get_default_qat_qconfig(fbgemm) # 一定要先 fuse否则 BN 层的量化行为会不匹配 model torch.ao.quantization.fuse_modules(model, [[conv1, bn1, relu1], [conv2, bn2]]) # prepare_qat 会插入伪量化节点模型进入训练模式 quant.prepare_qat(model, inplaceTrue)紧接着的训练阶段有几个容易踩的坑学习率一定要调小。原模型微调用 1e-4QAT 阶段建议降到 1/10 甚至 1/20。伪量化节点引入了额外的噪声学习率大会让权重更新方向变得异常激烈损失很难收敛。我在 ResNet-50 上实测QAT 初始阶段 lr1e-5 起步后期逐步衰减到 1e-6效果最稳。BN 层统计量的处理要格外小心。QAT 训练分为两个阶段先正常训练、更新 BN 统计量再固定 BN 的 running stats、只更新权重。我在实际项目中遇到过一次模型权重收敛正常但量化后精度崩掉 8% 的情况后来查到是训练最后阶段 BN 统计量仍在更新和推理时的量化假设不一致导致的。所以 QAT 结束前的最后 10% 训练步数必须用model.eval()模式下的行为来固定 BN 统计量同时训练权重。第二步训练结束后执行convert把伪量化节点真正转成 INT8 算子model.eval() # 必须先切到eval模式 quant.convert(model, inplaceTrue) # convert后会得到一个只包含量化算子QuantizeLinear/DeQuantizeLinear的模型 # 导出到 ONNX 时用 opset 13 以上确保算子映射完整 torch.onnx.export(model, dummy_input, model_qat.onnx, opset_version13)之后用 ONNX Runtime 加载部署。这里要提醒QAT 必须在训练框架里完成不是部署框架的活不要想着在 ONNX 层面重放 QAT 逻辑。4.3 什么场景必须上 QAT三类避不开的情况QAT 的开销是再次训练一遍模型成本不低。如果 PTQ 能解决完全没必要上。我总结了三类必须 QAT 的场景。第一类模型太脆。小模型MobileNetV2、EfficientNet-Lite 这类轻量骨干本身参数量少、冗余度低量化误差无处消化PTQ 掉点经常超过 3%。通过在训练阶段加入量化噪声模拟权重会主动往对量化更友好的方向偏移掉点能压到 1% 以内。第二类包含对数值范围极度敏感的算子。比如检测模型里的 DCN可变形卷积v2、attention 机制里的 softmax 后特征这些算子对输入数值的微小扰动非常敏感。QAT 训练时让前置网络适应量化的粗糙精度可以显著缓解这种敏感度。第三类目标硬件是 NPU/ASIC 这类固定流程的芯片。这类芯片的量化规则比 GPU/CPU 更严格不支持灵活的 per-channel 或混合精度。在训练阶段严格按照芯片的量化规则做伪量化模拟是保证上板精度唯一可靠的路径。5. LLM 量化的特殊性与主流方案取舍5.1 大模型的激活值异常为什么 LLM 量化比 CNN 更棘手到了 LLM 时代量化策略必须重新思考。CNN 的激活值分布相对稳定用几千张图校准出来的 scale 基本能覆盖真实分布。但 LLM 的激活值中存在明显的离群点outlier——某些特定通道上的激活值能比平均水平大上百倍。这些离群通道通常集中在特定维度上比如大多数 Transformer 模型的第一层和最后的层中。后果是如果量化范围为了覆盖离群点而拉宽 scale正常值的量化精度会严重损失困惑度perplexity直接爆炸。如果把离群点截断掉模型语义能力可能受损回答问题开始语无伦次。一种直观的应对是动态量化dynamic quantization对激活值不做预校准而是在推理时动态统计当前 batch 的激活范围实时计算 scale。LLM 的 activation 分布随输入变化大动态量化精度比静态量化好得多代价是额外的时间开销在长序列生成任务上有明显性能损失。还有一种思路是直接保留混合精度权重做 INT8 量化激活中已知的离群通道继续用 FP16 存储。这对应到 LLM.int8() 这类分解方案。实际操作中torch 生态里的bitsandbytes库可以直接调用这个能力不需要写太多代码就把模型跑起来。5.2 GPTQ、AWQ 与 GGUF三种主流量化方案的定位对比LLM 量化早已不只是校准 转换更合理的框架是把量化本身做成一个优化问题。目前有几种主流的混合精度压缩方案关键词对上了 GPTQ、AWQ、GGUF我在下面展开参数和选择建议。GPTQ基于近似二阶信息的逐层量化是目前很有代表性的方案。它的核心做法是逐层处理权重矩阵对某一行的权重做量化同时用一个近似 Hessian 矩阵来估计量化误差然后对未量化的权重做补偿更新让整体输出误差最小化。效果上在 7B 到 70B 模型上都能做到 4-bit 甚至 3-bit 量化质量损失在可接受范围。它属于训练后量化的一种高级玩法不需要重新训练模型。AWQ激活值感知量化的出发点不同。GPTQ 只考虑权重AWQ 把激活值的分布也纳入考量通过统计激活值中影响大的通道给这些通道的权重更高的保护权重让量化过程重点保护这些通道的精度。实测下来 AWQ 在多数任务上的困惑度损失比 GPTQ 稍微小一点而且量化速度快不少。GGUF 是 llama.cpp 生态独占的格式它更像一种量化模型容器支持从 2-bit 到 8-bit 的各种量化方案如 Q4_K_M、Q5_K_M、Q8_0 等底层量化算法实际上采用了多种经典方案混合。社区的活跃度和模型的直接可用性让它成了在 CPU 上本地跑大模型的事实标准。方案基本思路位数支持优势典型场景GPTQ二阶近似补偿量化误差2/3/4/8-bit低比特下精度保持较好GPU 显存受限时的多数模型部署AWQ按激活通道重要度保护权重4/8-bit量化速度快、困惑度低快速验证、追求训练后最优精度GGUF统一封装的混合量化方案2~8-bit 多种细分档位与 llama.cpp 深度集成CPU 友好的算子本地 CPU 推理、对话机器人、嵌入式设备5.3 实操Transformers 生态里量化和部署的一种顺手路径在实际项目里我通常走两条路径。如果模型要部署到服务端 GPU优先用 GPTQ 或 AWQ 量化加载到 vLLM 或者 TGI 这类推理服务里如果要部署到笔记本/小主机上走 GGUF llama.cpp或 Ollama。下面以 Transformers 生态的例子做演示。在 HFace 生态中用 Transformers 加载一个已经量化好的 AWQ 模型from transformers import AutoModelForCausalLM, AutoTokenizer, AwqConfig # 模型路径换成你用 AWQ 量化工具处理过权重的目录 model_id your/model-awq # AWQ 需要显式声明量化配置否则默认还是会用FP16加载 quantization_config AwqConfig( bits4, group_size128, zero_pointTrue, versiongemm, # 在N卡上用gemm部分Intel/AMD环境可以换gemv ) model AutoModelForCausalLM.from_pretrained( model_id, quantization_configquantization_config, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_id)要提醒的是group_size是一个非常关键的超参数它表示每多少个权重共享一个 scale。group_size 越小量化控制越精确但存储开销也越大group_size128 在精度和体积之间算比较均衡的选择group_size32 的精度更好但显存和带宽开销会明显上升。如果想自己动手做 AWQ 量化官方工具链 awq 提供了脚本quantize_weights.py输入 HF 格式模型直接输出量化权重整个过程不需要标定数据做训练十分钟左右就能跑完。这一步本质上是少量样本级别的校准过程——AWQ 会扫描模型权重和激活分布不需要像 PTQ 那样为每个算子准备专门校准集所以速度快。5.4 KV cache 量化生成式 LLM 推理的一条补充优化线LLM 推理还有一个经常被忽略的显存大户——KV cache键值缓存。生成式模型逐 token 输出时每生成一个新 token都需要把当前 token 对应的 K、V 向量追加到缓存里缓存会随序列长度线性增长。长对话场景中 KV cache 占用的显存甚至能超过模型权重本身。KV cache 量化的逻辑和权重量化完全不同KV cache 是推理过程中动态生成的不经过训练。做 PTQ 式的校准意义不大更常见的是动态量化——在写入缓存时把 FP16 的 K/V 转成 INT8读取时反量化回 FP16 参与 attention 计算。这种做法的精度损失在大多数任务上都可接受但长上下文的翻译或摘要任务上需要多做验证。在 Transformers 生态里设置 KV cache 量化非常直接from transformers import AutoModelForCausalLM, BitsAndBytesConfig model AutoModelForCausalLM.from_pretrained( your/model, quantization_configBitsAndBytesConfig( load_in_8bitTrue, llm_int8_enable_fp32_cpu_offloadFalse, ) ) # 在 generate 函数中加入 kv_cache 量化开关 output model.generate( inputs, use_cacheTrue, cache_implementationquantized, cache_config{n_bits: 8}, )量化 KV cache 后实测 7B 模型的上下文长度能扩展将近一倍在 24GB 显存的环境下测的原来最长支持 8K 上下文量化后能跑到 12K 以上生成速度因为显存带宽瓶颈缓解也有 15% 到 20% 的提升。但如果跑长文档摘要这类对数值精度敏感的任务要重点验证 KV cache 量化后 ROUGE 分数没有明显下降。6. 量化实践中的常见问题与排查实录6.1 掉点严重的几个元凶BN 融合与校准集分布一路写下来把几个最容易踩的坑集中整理成速查表方便大家排查现场问题。现象特征根本原因解决手段FP32 精度高INT8 掉点 5% 以上BatchNorm 没有融合进卷积在导出前先执行 fold BN 操作ONNX Runtime 里检查图中是否还有独立 BN 节点均匀掉点 2% 左右校准集与线上数据分布不一致用线上真实采样的数据子集重新校准百分位调到 99.99%个别层掉点极其严重该层激活分布有离群通道对该层单独做 per-channel 激活量化或者混合精度该层保留 FP16量化后 CPU 推理变慢算子未映射到 INT8 内核做了反量化来回转换检查是否用了支持 QLinearConv/IntegerOps 的 execution provider并查看 profiler 日志BN 融合问题在 QAT 里也暴露过具体表现是训练阶段 loss 很正常一旦 convert 完精度暴跌。解剖后发现的原因是折叠 BN 时把 BN 的均值和方差直接融进了卷积权重如果融合顺序不对卷积的 scale 计算就会出现方向性错误。建议在任何量化流程之前先用fuse_modules把 BN 融合干净很多莫名其妙的精度问题都会因此消失。6.2 一张量化精度诊断表我实测下来的参考值最后给出一个参考精度数据这是我在多个公开模型上的实测结果可以当作自己的排查基准。模型FP32 Top-1PTQ INT8 Top-1QAT INT8 Top-1PTQ 掉点ResNet-5076.15%75.41%75.98%0.74%MobileNetV271.88%69.02%71.45%2.86%EfficientNet-B077.10%73.80%76.60%3.30%YOLOv5s (COCO mAP)37.435.136.92.3从表里能看到模型越小、结构越轻量PTQ 掉点越夸张。MobileNetV2 和 EfficientNet 这类深度可分离卷积为主的模型PTQ 掉点普遍在 2.5% 到 3.5% 这个范围内接近及格边缘。遇到这种模型就别死磕 PTQ 的校准方法了直接上 QAT 才是正解。6.3 量化算子的落盘问题精度挺好但加速为负的常见原因还有一种情况需要单独提出来量化后模型测出来精度确实没怎么掉但推理延迟不降反升。我排查过好几次90% 以上的原因都是量化算子没有真正落到硬件加速内核上。在 CPU 上矩阵乘走没走 INT8 加速要看算子是否能被调度到 oneDNN即 mkl-dnn的 INT8 原语。检查方法ONNX Runtime 打开日志看算子名称是不是QLinearConv或者MatMulInteger如果是Conv和MatMul说明根本没量化成功。在 Intel CPU 上还有一个隐蔽问题受支持的 AVX512 指令集部署。如果推理机的 CPU 是低端型号比如部分嵌入式赛扬它根本不支持 AVX512 的 INT8 指令扩展即使量化成功也会降级走标量路径。这种环境建议直接用reduce_rangeTrue之类的安全量化配置不要强行追求最大精度。在 GPU 上NVIDIA TensorRT 的 INT8 走的是 Tensor Core要求 shape 对齐到 32 的倍数。如果你的模型输入是 224×224 图片卷积的 channel 数不是 32 的倍数比如 ECA-Net 这种在通道数上做过裁剪的模型TensorRT 会静默降级回 FP32 实现。这个排查的难度比较高输出日志里一般不会有警告建议在构建 TensorRT engine 时开启 verbose 去确认kernelName是否落在sm80_xmma系列针对 A100或者类似sm86_xmma针对 3090/3080 等另外留意一些算子的Kernel字段是否带int8标识。写在最后的几点心得前面写了很多原理、流程和踩坑记录到这儿再把个人体会补两句。量化这种优化手段关键不在于把代码跑通而在于对整个链路有精确把握。什么时候用 PTQ、什么时候必须 QAT校准集到底选多少数据per-channel 开不开这些决定不是靠调参试出来的而是建立在你对模型结构、部署硬件和线上数据分布的准确理解之上。我自己在做量化的过程中体会到有三件事性价比最高一是把校准集真正做成线上分布模拟器这是最便宜、最有效的掉点杀手二是学会看 profiler 日志而不是只信直觉很多性能问题一眼就能从算子调度记录里定位三是善用混合精度不要追求全模型 INT8让敏感层留在 FP16整体精度和性能通常能达到最优平衡点。模型量化不是把精度换成速度的单向交易而是一场在精度、体积、延迟之间找平衡的系统工程。整体做完之后建议再回头验证一次真实业务场景里的指标变化数据会告诉你方案是不是真的有效。
