1. 为什么模型上线绕不开量化这道坎做过模型部署的人大概都有类似的经历训练阶段一切顺利指标也好看可一旦要把模型塞进实际的生产环境推理延迟、显存占用、吞吐量这三座大山就压过来了。我最早接触量化是在一个视觉检测项目上当时一个 ResNet 变体在服务器上跑得好好的移植到边缘设备后单帧推理要 200 多毫秒产线节拍根本跟不上。后来把权重和激活都压到 INT8速度直接翻了将近三倍精度只掉了不到一个百分点。从那以后量化就成了我部署流程里的标配环节。这篇内容想聊的就是模型部署与推理优化里的量化这件事核心围绕INT8 矩阵乘、校准、QAT 以及 LLM 量化这几个关键词展开。它解决的核心问题是在尽量不损失精度的前提下把模型的存储和计算从高比特浮点压缩到低比特整数从而降低显存占用、提升推理速度、减少功耗。适合谁看如果你正在做模型部署、推理加速或者手上有大模型想跑在有限的硬件资源上那这篇基本能覆盖你从原理到落地的完整链路。我会尽量把每个环节的“为什么”讲清楚而不是只丢一堆 API 让你照抄。先说清楚一个前提量化不是万能的银弹它本质上是一场精度与效率的权衡。你得先搞清楚自己的瓶颈在哪——是显存不够、是延迟太高、还是功耗受限然后再决定用哪种量化方案。盲目上 INT8 有时候反而会因为反量化开销导致速度不升反降这个坑我后面会细讲。2. 量化到底在做什么从浮点到整数的本质2.1 数值类型的基本盘FP32、FP16、BF16、INT8 的区别要理解量化得先把这几种数值类型摆在一起看。它们最核心的差异在于表示范围和精度而这直接决定了算力需求和硬件支持情况。类型位宽指数位尾数位大致范围典型用途FP3232823±3.4e38训练、高精度推理FP1616510±65504混合精度训练、GPU 推理BF161687±3.4e38训练、大模型推理INT88---128~127量化推理FP16 的尾数有 10 位精度不错但范围窄容易溢出BF16 牺牲了尾数精度换来了和 FP32 一样的指数范围所以在训练大模型时特别受欢迎因为不容易出现梯度溢出。INT8 则是纯整数只有 256 个离散取值它没法直接表示小数所以量化的关键就在于建立一个浮点到整数的映射关系。这里有个很多人忽略的点算力需求不只是看位宽。INT8 的矩阵乘在支持它的硬件上比如带 DP4A 指令的 GPU、或者专门的 NPU能跑到 FP16 的好几倍吞吐因为整数乘加可以打包处理。但如果硬件不支持 INT8 加速那量化带来的可能只是存储上的好处计算上未必快。所以选型前一定要确认目标硬件的指令集支持情况。2.2 量化的数学本质仿射映射量化的核心公式其实很朴素就是一个仿射变换q round(x / scale) zero_point x_float ≈ (q - zero_point) * scale其中scale是缩放因子zero_point是零点偏移。为什么要零点因为浮点的 0 在量化后不一定对应整数的 0为了让浮点零能精确表示这对 ReLU 之后的激活、padding 都很重要需要引入零点偏移。scale的计算方式决定了量化的粒度per-tensor整个张量共用一个 scale简单但精度损失大per-channel每个通道一个 scale常用于权重量化精度明显更好per-group每若干元素一组LLM 量化里常用比如 group_size128我个人的经验是权重量化基本都用 per-channel激活量化用 per-tensor 就够了因为激活的动态范围在推理时相对稳定。这个选择背后是有道理的权重在不同通道间的分布差异很大共用一个 scale 会让某些通道的量化误差特别大而激活经过归一化层之后各通道分布相对接近。2.3 对称量化与非对称量化怎么选对称量化强制 zero_point0映射区间关于原点对称非对称量化则允许零点偏移。两者的取舍很实际对称量化实现简单整数运算时不用额外处理零点速度略快。适合权重这种大致对称分布的张量。非对称量化能更好地拟合非对称分布比如 ReLU 之后的激活全是非负的用非对称量化能充分利用整数范围。实测下来权重用对称、激活用非对称是个比较稳的组合。不过现在很多推理框架会统一处理你只需要在配置里指定就行。需要注意的是非对称量化在计算时要处理零点某些硬件上会引入额外开销如果追求极致速度可以试试全对称方案看精度能不能接受。3. INT8 矩阵乘量化真正提速的关键环节3.1 为什么矩阵乘是量化的主战场模型推理里绝大部分计算量都集中在矩阵乘和卷积上而卷积在实现层面往往也会转成矩阵乘im2col。所以只要把矩阵乘做成 INT8整个模型的推理速度就能有质的提升。这也是为什么各家硬件厂商都在拼命优化 INT8 矩阵乘的原因。INT8 矩阵乘的基本思路是把两个 INT8 矩阵相乘累加结果用 INT32 存储因为 INT8 乘 INT8 最大是 127*127≈16129累加几百次就会溢出 INT16所以必须用 INT32 累加器最后再统一反量化回浮点。这个设计很关键——累加过程保持整数只在最后做一次反量化这样既保证了精度又避免了中间过程的浮点开销。3.2 反量化时机的选择与性能影响这里有个容易被忽视的性能陷阱反量化的位置。有两种常见做法先累加再反量化INT8 矩阵乘得到 INT32 结果然后乘以 scale 得到浮点。这是标准做法效率最高。边累加边反量化每累加一部分就转回浮点。这种做法会频繁触发类型转换性能极差。我踩过的坑就是早期用某个框架时没注意配置结果它默认走了第二种路径速度比 FP32 还慢。后来查了 profiling 才发现瓶颈全在类型转换上。所以你在做性能调优时一定要用 profiler 确认反量化发生在哪一步。另外INT8 矩阵乘对内存布局很敏感。很多硬件要求权重预先做重排比如从 NCHW 转成 NHWC 或者特定的分块布局这样能提升缓存命中率。ONNX Runtime 和 TensorRT 在构建引擎时都会自动做这个优化但如果你自己写 kernel就得手动处理。3.3 硬件指令集对 INT8 的支持差异不同硬件对 INT8 的支持程度差别很大这直接决定了量化的收益NVIDIA GPU从 Turing 架构开始支持 DP4A 指令Ampere 之后有更完整的 INT8 Tensor Core吞吐是 FP16 的两倍。移动端 NPU基本都原生支持 INT8甚至有些只支持 INT8这时候量化不是可选项而是必选项。CPUx86 上有 VNNI 指令集能加速 INT8ARM 上有 dotprod 指令。老 CPU 没有这些指令的话INT8 可能跑不过 FP32。所以量化前先查清楚目标硬件的指令集支持这一步能帮你省下大量无用功。我见过有人在一台老服务器上折腾半天 INT8结果发现 CPU 不支持 VNNI速度毫无变化。4. 校准训练后量化精度的命门4.1 校准在做什么为什么不能省训练后量化PTQ最大的挑战是权重的分布你是知道的训练完就固定了但激活的分布取决于输入数据你没法提前知道。校准就是用一批有代表性的数据跑一遍模型统计每一层激活的取值范围从而确定 scale 和 zero_point。校准数据的质量和数量直接决定量化精度。我的经验是数量上100 到 500 个样本通常够用太少统计不准太多收益递减。质量上校准数据必须和实际推理数据的分布一致。如果你用猫狗图片校准却拿去推理工业缺陷图精度崩了别怪量化。有个真实的教训我之前做一个文本分类模型图省事用了训练集的前 100 条做校准结果上线后发现某些长文本的精度特别差。后来换成按长度分层采样问题就解决了。校准集的代表性比数量重要得多。4.2 主流校准算法对比MinMax、MSE、熵校准校准的核心是选一个合适的截断范围clipping range。因为激活里往往有少数极端值如果直接用 min/max这些离群点会把 scale 拉得很大导致大部分正常值被压缩到很少的整数格子里精度损失严重。校准方法原理优点缺点MinMax直接用最大最小值简单、无偏对离群值敏感MSE最小化量化前后均方误差精度较好计算稍慢熵校准最小化信息熵差异精度最好计算最慢Percentile取百分位截断抗离群值百分位需调参熵校准也叫 KL 散度校准是 TensorRT 的默认方法效果通常最好但需要更多的校准样本和计算时间。MSE 是个不错的折中。如果追求速度MinMax 配合百分位截断也能用。我一般会先用熵校准跑一版看精度如果达标就用如果时间紧用 MSE 也基本够。Percentile 的截断比例是个超参常见取 99.9% 或 99.99%具体得试。4.3 校准实操以 ONNX 量化为例ONNX Runtime 提供了比较成熟的 PTQ 流程我以它为例走一遍。首先准备校准数据读取器import numpy as np from onnxruntime.quantization import CalibrationDataReader class MyCalibReader(CalibrationDataReader): def __init__(self, calib_data): self.data calib_data self.idx 0 def get_next(self): if self.idx len(self.data): return None batch self.data[self.idx] self.idx 1 return {input_name: batch} def rewind(self): self.idx 0然后调用量化接口from onnxruntime.quantization import quantize_static, QuantType, QuantFormat quantize_static( model_inputmodel.onnx, model_outputmodel_int8.onnx, calibration_data_readerMyCalibReader(calib_samples), quant_formatQuantFormat.QDQ, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, per_channelTrue, )这里QuantFormat.QDQ表示用 Quantize-Dequantize 格式插入量化节点兼容性好per_channelTrue开启逐通道权重量化。跑完之后一定要用验证集对比量化前后的精度别直接上线。注意校准数据读取器返回的字典 key 必须和模型输入名完全一致否则会静默失败或者报奇怪的错。我第一次用的时候 key 写错了结果校准根本没生效量化后精度惨不忍睹。5. QAT当 PTQ 精度不够时的终极武器5.1 QAT 的核心思想让模型提前适应量化误差PTQ 简单快捷但有些模型尤其是小模型或者对精度敏感的检测、分割模型量化后精度掉得厉害。这时候就得上量化感知训练QAT。QAT 的思路很巧妙在训练阶段就模拟量化的误差让模型在训练过程中学会补偿这些误差。具体做法是在前向传播里插入伪量化节点fake quantize它做的是“量化再反量化”的操作数值上引入了量化误差但梯度还能正常回传用 STE直通估计器。这样训练出来的模型权重和激活的分布会自然地向量化友好的方向靠拢。QAT 通常能比 PTQ 多挽回一到两个百分点的精度代价是需要额外的训练时间和标注数据。我的判断标准是如果 PTQ 后精度下降在 1% 以内直接用 PTQ超过 1% 且业务无法接受再考虑 QAT。5.2 伪量化节点的插入位置与 STE 原理伪量化节点的插入位置很讲究。标准做法是权重在卷积/全连接层之前插入激活在激活函数之后插入这样能覆盖所有需要量化的张量。STEStraight-Through Estimator是 QAT 能训练的关键——量化函数本身不可导round 操作梯度为 0STE 直接让梯度“穿过”量化节点近似认为量化是恒等映射。这个近似虽然粗糙但实践中效果出奇地好。用 PyTorch 的话可以用torch.quantization或者torch.ao.quantization模块import torch.ao.quantization as tq model.qconfig tq.get_default_qat_qconfig(fbgemm) model_prepared tq.prepare_qat(model, inplaceFalse) # 正常训练若干 epoch for epoch in range(num_epochs): train_one_epoch(model_prepared) # 训练完转成量化模型 model_prepared.eval() model_int8 tq.convert(model_prepared, inplaceFalse)fbgemm是 x86 后端的配置ARM 上用qnnpack。选错后端会导致量化方案不匹配转换时报错。5.3 QAT 训练的几个关键技巧QAT 训练和普通训练有些不一样的地方我总结几条实战经验学习率要调小QAT 是在预训练模型基础上微调学习率通常设为原训练的 1/10 到 1/100否则容易把预训练学到的特征破坏掉。先冻结再解冻可以先用较小的学习率只训练量化参数scale、zero_point稳定后再解冻所有权重一起训。BN 层的处理BatchNorm 在 QAT 里要特别小心通常建议在 QAT 后期冻结 BN 的统计量避免它和量化参数互相干扰。训练轮数不用多一般几个 epoch 就够了太多反而过拟合。我做过一个对比实验同一个检测模型PTQ 后 mAP 掉了 2.3 个点QAT 训练 5 个 epoch 后只掉了 0.4 个点效果还是很明显的。但 QAT 的工程复杂度确实高不少需要把训练流程重新搭一遍。6. LLM 量化大模型时代的特殊挑战6.1 为什么 LLM 量化不能照搬 CNN 那套大语言模型的量化和传统 CNN 有本质区别。CNN 的激活分布相对稳定PTQ 加校准基本能搞定。但 LLM 有几个特点让量化变得棘手激活里存在极端的离群值某些通道的激活值能比其他通道大几十倍这是 LLM 的固有特性。如果按常规 per-tensor 量化这些离群值会把 scale 撑爆导致其他值全被压成 0。参数规模巨大70B 的模型光权重就 140GBFP16量化到 INT8 能省一半到 INT4 能省更多这对显存受限的场景是刚需。对精度敏感LLM 的输出是逐 token 生成的误差会累积量化不当会导致生成质量明显下降甚至胡言乱语。所以 LLM 量化发展出了一套专门的技术路线核心就是如何处理激活离群值。6.2 主流的 LLM 量化方案对比目前业界比较成熟的几套方案我按自己的理解梳理一下方案核心思路权重量化激活量化特点GPTQ逐层误差补偿INT4/INT8不量化权重离线量化推理快AWQ保护重要通道INT4不量化精度好适合小模型SmoothQuant把激活难度迁移到权重INT8INT8实现 W8A8速度提升明显LLM.int8()离群值单独用 FP16 处理INT8INT8混合精度精度稳SmoothQuant 的思路我觉得特别巧妙既然激活有离群值难量化而权重相对好量化那就通过一个数学等价的变换把激活的量化难度“迁移”一部分到权重上。具体是引入一个 per-channel 的缩放因子 s把激活除以 s、权重乘以 s保持矩阵乘结果不变但让两者的动态范围都变得更友好。LLM.int8() 则是另一条路它发现离群值主要集中在少数几个特征维度上于是把这些维度单独拎出来用 FP16 算剩下的用 INT8 算。这种混合精度方案精度很稳但实现复杂速度提升不如纯 INT8。6.3 分组量化与离群值处理实操现在主流的 LLM 量化基本都用分组量化group-wise quantization。就是把权重按每 128 个元素分一组每组独立算 scale。这样每组内部的数值范围更集中量化误差更小。代价是需要存储更多的 scale但相比精度收益这点开销值得。以 GPTQ 为例它的核心是逐层做量化并用 Hessian 矩阵指导权重的舍入方向让量化误差在输出层面最小化。用现成的库跑起来其实不复杂from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actFalse, ) model AutoGPTQForCausalLM.from_pretrained( model_path, quantize_configquantize_config, ) model.quantize(calib_dataset) model.save_quantized(output_path)group_size128是经验值越小精度越好但压缩率越低。desc_act控制是否按激活重要性排序开启后精度略好但推理稍慢。注意LLM 量化的校准集选择比 CNN 更关键。建议用和目标场景接近的文本比如你要做代码生成就用代码数据校准做通用对话就用多样化的对话数据。用错了校准集量化后的模型可能在你关心的任务上表现很差。7. 常见问题与排查技巧实录7.1 量化后精度暴跌怎么排查精度暴跌是最常见也最头疼的问题。我一般按这个顺序排查确认校准数据是否有代表性先换一批更贴近实际分布的校准数据试试这是最高频的原因。检查是否有层不适合量化某些层比如第一层卷积、最后的分类头、LayerNorm对量化特别敏感可以尝试把这些层排除在量化之外保持 FP16。看激活的离群值情况打印每层激活的最大最小值如果某层动态范围异常大考虑用 per-channel 或者混合精度处理。对比逐层误差用工具逐层对比量化前后的输出差异定位到具体是哪一层出的问题。我遇到过一次精度暴跌最后发现是某个自定义算子的量化实现有 bug导致输出全错。所以如果用的是非标准算子一定要重点检查。7.2 量化后速度没提升甚至变慢的原因这个问题的排查思路和精度问题完全不同硬件不支持 INT8 加速前面提过先查指令集。反量化开销过大如果模型里量化层和浮点层频繁交替每次都要做类型转换开销会吃掉收益。尽量让量化区域连续。算子融合没做好ConvBNReLU 这种组合如果能融合成一个量化算子效率会高很多。检查框架是否开启了融合。batch size 太小INT8 的优势在大 batch 下更明显小 batch 时可能被固定开销拖累。7.3 常见问题速查表问题现象可能原因排查方向精度掉超过 3%校准数据不匹配换校准集检查分布精度掉 1-3%离群值影响用 per-channel 或混合精度速度无提升硬件不支持查指令集换硬件速度变慢反量化频繁检查量化区域连续性输出全为 0 或 NaNscale 计算错误检查校准是否生效部分层报错算子不支持量化排除该层或换实现7.4 几条压箱底的实操心得最后分享几条我踩坑总结出来的经验都是文档里不会写的量化前先备份 FP32 模型量化过程有时会修改原模型别问我怎么知道的。小模型慎用激进量化参数量本来就少量化误差占比大INT4 在小模型上经常翻车。端到端测延迟别只看单算子单算子快不代表整体快内存搬运、调度开销都要算进去。保留一个 FP16 兜底版本线上出问题时能快速回滚这个太重要了。量化不是一次性的模型更新、数据分布变化后校准和量化都要重做。量化这件事原理不难难的是工程细节和场景适配。同一个方案在不同模型、不同硬件上的表现可能天差地别所以一定要在自己的实际场景里验证别迷信任何一篇教程的结论包括我这篇。多动手测多对比数据慢慢就能摸出适合自己业务的量化配方了。