1. 为什么模型推理的性能瓶颈最后都会落到矩阵乘上先从一个实战场景说起。我两年前接了一个边缘设备部署项目模型不大ResNet50 级别FP32 下测推理延迟大约 38ms。客户要求压到 12ms 以内当时第一反应是换轻量网络但精度指标卡得死。后来真正解决问题的是三件事模型结构微调、算子融合、以及把整网切到 INT8 量化。其中收益最大、踩坑最多的就是 INT8。这三年里我从 TensorRT 到 ONNX Runtime再到自己用 PyTorch 写量化训练把量化这条链路基本走了一遍今天这一篇就把核心原理和实操经验一次性讲透。先说一个关键认知深度模型推理的计算量大头几乎全在卷积核矩阵乘和全连接层矩阵乘上。Transformer 结构更夸张Self-Attention 里的 QKV 变换、注意力得分计算、输出投影全部是矩阵乘。所以推理引擎优化的核心思路就是把矩阵乘的时间压下来。INT8 量化为什么能提速因为它直接把每个元素从 4 字节FP32压到 1 字节内存带宽占用降低到四分之一同时利用硬件专门为低精度矩阵乘设计的计算单元比如 Tensor Core实现吞吐翻倍。注意这里的提速一部分来自更少的 IO 搬运一部分来自更快的乘加单元而不是简单的数据变小所以跑得快。另外一个常被忽略的点FP16、BF16、INT8、FP8 的选择直接影响算力下限。以主流 GPU 为例FP32 的算力通常是个基准值FP16 和 BF16 可以做到 2 倍INT8 通常可以做到 4 倍甚至更高FP8 在部分新卡上有接近 2 倍于 FP16 的吞吐。如果你的部署目标是移动端 NPU很多芯片直接不支持 FP16只支持 INT8那就不是加不加速的问题是不量化没法跑的问题。做量化之前需要认清一个现实INT8 量化不是简单地调低精度而是把浮点数值重新编码成一个定点整数范围再配合 scale 和 zero point 还原出近似值。这个近似的大小决定了你模型精度掉多少。如何让这个过程尽量无损、如何在不同硬件上做校准、如何让训练感知到量化误差这些就是本文要拆解的核心内容。2. 量化编码机制拆解对称量化、非对称量化与矩阵乘的实现路径2.1 从浮点到定点数域映射的基本数学量化的目标是把 FP32 张量映射到 INT8 的 [-128, 127] 范围也有 [0, 255] 的无符号情况。最通用的公式r S * (q - Z)其中 r 是原始浮点值q 是量化后的整数值S 是缩放因子scaleZ 是零点偏移zero point。反过来的量化公式q clip(round(r / S) Z, q_min, q_max)这里的 S 可以理解为一个刻度尺的精度Z 表示浮点零点对应的整数位置。二者合在一起就构成了浮点域到定点域的双射映射关系只是映射前后有精度损失。对称量化会强制 Z0也就是让浮点零精确对应整数零这样工程实现上最省事非对称量化则保留 Z可以在低位宽下更好地覆盖非对称分布的数据。我实际项目中的经验对于激活值尤其是经过 ReLU 的输出都是非负值非对称量化的精度损失通常更小。对于权重由于模型学到的权重分布通常接近以零为中心的对称分布用对称量化即可。用通俗类比来说明你用一个长度为 256CM 的尺子量一组身高数据如果所有人都在 150CM 到 200CM 之间那么把尺子零点对准 150CM 显然比从 0CM 开始量要精确得多——这就是非对称量化的意义。2.2 INT8 矩阵乘的融合计算流程假设两个 INT8 矩阵 A 和 B 相乘得到 INT32 累加结果常规步骤是对 A 的反量化A_fp S_A * (A_int - Z_A)对 B 的反量化B_fp S_B * (B_int - Z_B)矩阵乘得到 FP32 结果 C_fp A_fp * B_fp对 C_fp 重新量化成 INT8上面的流程确实是可行的但每一步都做反量化在算子层面会非常慢。工程上高效的实现是利用数学结合律把 scale 提出来C_fp S_A * S_B * (A_int - Z_A) * (B_int - Z_B)先算整数矩阵乘 D (A_int - Z_A) * (B_int - Z_B)此时整数乘法器的输出位宽需要变大通常把 INT8 乘 INT8 的乘积累加到 INT32这个非定型加宽是硬件设计时就考虑好的不会额外增加太多成本。然后只做一次浮点缩放 C_fp D * (S_A * S_B)再做一次量化输出。这个先乘加、后缩放的路径是整个 INT8 推理优化的核心。TensorRT 和 ONNX Runtime 的量化算子都是这么设计的。在这个过程里最怕的是累加溢出。INT32 的最大值是约 21 亿如果输入张量的量化数值恰好是绝对值很大的极端值且矩阵维度很大累加是有可能溢出的。实际模型基本不会走到这一步但我在调试自研推理引擎时确实遇到过因为量化参数设置不当导致的输出整片是 127的异常最后排查下来是 scale 设得太小导致原始浮点值大量超出映射范围所有激活都被 clip 到最大值上。所以量化参数第一个原则是尽可能覆盖数据的真实动态范围宁让边缘有少量 clip也不能让整体分辨率被拉垮太多。2.3 缩放因子与零点位置的确定逻辑常规做法是遍历样本统计张量的最大值和最小值然后按公式计算S (max_val - min_val) / (q_max - q_min) Z round(q_min - min_val / S)但是直接取 min/max 有一个严重弊端受离群点影响很大。模型里经常出现个别异常大的激活值例如某个 token 的少数维度数值远高于其他位置如果用 min/max 法scale 会被拉大导致绝大多数正常值的量化分辨率被浪费。后面校准部分我会专门展开讲 KL 散度、百分位等方法这里先记住一个结论min/max 只适合权重量化不适合激活量化。3. 校准方法论如何用校准数据集找到最优量化参数3.1 校准的本质收集真实的激活分布量化参数不能凭空算必须用真实数据样本喂到模型里做一次前向推理在各个层间把激活值收集起来这个过程叫校准。校准数据和训练数据尽量不要重合但领域要一致。我见过有人直接用训练集里抽几百张做校准这在图片分类上效果还行但换到目标检测或分割时问题就大了因为模型对背景区域和细小目标的激活响应差异非常大校准集如果不包含这类样本量化参数就会偏。校准样本的数量也有讲究。太多会导致校准时间极长太少则统计不稳定。TensorRT 官方做法是每个类别至少选一张总样本量通常在 500 到 1000 之间。我的实践是先从验证集均匀抽 200~500 张如果量化掉点明显再按类别分布补样本大多数场景都能解决。ONNX Runtime 的静态量化默认配置也类似。3.2 各种校准算法的适用场景与取舍业内用得比较多的校准算法有这么几种Min-Max适合权重计算简单但抗离群点能力差。Percentile取 99.99% 或 99.999% 分位点作为最大值去掉极端离群点简单但阈值选择需要经验。KL 散度熵校准TensorRT 早期主推的方法通过不断截断候选阈值计算截断前后分布的 KL 散度选择信息损失最小的阈值点。它核心优点是能在动态范围覆盖和分辨率之间自动找平衡。MSE 均方误差法遍历候选 scale让量化前后的数据 MSE 最小更精细但速度略慢。实际操作时我用过一段时间的经验法则卷积网络用 KL 校准普遍稳Transformer/注意力网络由于激活分布具有长尾特性Percentile 加 MSE 组合会更好一些。但这不是绝对最终还是要以实际精度指标说话。量化是一个工程问题不是纯数学问题一切以端到端效果为准。3.3 校准过程中的常见坑第一个坑是 BatchNorm 层折叠fold和量化顺序的问题。很多权重在 BN 层之后的分布已经发生偏移BN 参数必须提前融合进卷积权重再做校准否则量化参数统计的是错误分布。TensorRT 默认会做自动化融合但如果你用 PyTorch 自定义导出 ONNX需要特别注意这个顺序。我的建议是任何静态量化流程的第一步都是先把模型里的 BN 融合掉再导出再用融合后的模型做校准。第二个坑是校准数据的前处理必须与训练保持一致。归一化系数、图像缩放尺寸、均值方差归一化顺序差一个像素都可能让激活分布整体偏移。我曾经排查过一个问题校准集用 PIL 转 RGB推理时用 OpenCV 转 BGR结果几乎每个卷积层的激活分布都变了量化掉点 3 个点以上一开始完全没想到是这个原因。第三个坑也是很多入门者会忽略的校准过程会依赖前置层的量化误差。校准是逐层进行的但量化误差会累积。INT8 量化后的模型前面层输出已经是有损的后面层的校准统计也来自这些有损的激活所以在精度敏感的场景下要么用逐层贪心校准让前面层尽量误差最小化要么直接上 QAT量化感知训练。这也是为什么静态量化PTQ能做到 2~3 个点以内的掉点但如果任务本身对细节极度敏感PTQ 就不太够了就得考虑后面要讲的 QAT。4. 量化感知训练QAT让网络自己去适应量化的扰动4.1 模拟量化的核心机制QAT 的思路不是把模型训练成能承受掉精度而是把量化误差当作一种噪声注入来训练让权重在训练过程中就适应量化后的数值表示。实现上QAT 会在网络中插入模拟量化节点FakeQuantize正向传播时执行对权重和激活执行量化到 INT8 的流程。紧接着反量化回浮点继续参与计算。从数值上看网络计算用的还是浮点但数值精度已经被限制在 INT8 能表达的范围内。反向传播时梯度需要穿过这个不可导的量化函数直接做法是使用直通估计器STEStraight Through Estimator)即反向时把量化函数的梯度近似为恒等映射。这个近似会带来一定的梯度失配但只要学习率设置得当训练过程通常还是能收敛的。4.2 一个完整可复现的 PyTorch QAT 流程下面是我常用的一套落地流程基于 PyTorch 自带量化 API可以直接在代码里跑通import torch import torch.nn as nn from torch.quantization import QuantStub, DeQuantStub, default_qconfig, prepare_qat, convert class QATNet(nn.Module): def __init__(self, backbone): super().__init__() self.quant QuantStub() self.backbone backbone self.dequant DeQuantStub() def forward(self, x): x self.quant(x) x self.backbone(x) x self.dequant(x) return x model QATNet(model) model.qconfig default_qconfig # 初学者可以先走默认配置 model prepare_qat(model) optimizer torch.optim.Adam(model.parameters(), lr1e-4) # 按常规方式继续训练若干个 epoch # 训练结束后转为推理模式 model.eval() model.cpu() model convert(model)执行prepare_qat时模型内部的可量化算子会被替换成带 FakeQuantize 的版本。训练启动前建议先做 1~2 个 epoch 的 warmup用很小的学习率让模型先适应量化后的权重分布。设定的学习率一般比普通训练要低一个数量级因为量化带来的噪声近似于增加扰动学习率过大会导致振荡。4.3 QAT 的精度监控与调试思路QAT 不是一跑就万事大吉需要随时监控量化前后的精度差异。我的做法是每训练完一个 epoch把 FakeQuantize 的统计信息打印出来包括 scale 和零点观察它们是否收敛同时跑一遍验证集。如果发现量化版本精度的波动来回横跳优先检查是不是 BN 层的均值和方差统计没有更新到位。另一个常见问题是权重波动。QAT 过程中权重会被 FakeQuantize 强制到量化网格上这等价于给权重加了震荡噪声如果模型本身已经收敛到很陡的极小值这种震荡可能导致精度持续下降。解决办法是把震荡的权重冻结也叫权重量化固定即训练前先计算好权重的 scale 和 zero pointQAT 过程中不再更新它们只更新激活的量化参数——这在部分硬件上能显著提升稳定性。4.4 什么情况下必须上 QAT我给出的判断标准是静态量化掉点超过 3 个点且无法通过校准数据集调整挽回模型里有对噪声敏感的层比如 sigmoid 或者 softmax 前的高维特征任务对细小目标的检出非常敏感例如医学影像分割、缺陷检测目标硬件本身对量化误差的容错较低比如某些 NPU 没有溢出自处理能力。在这些情况下QAT 基本是唯一能保住精度的路径。但 QAT 也有代价训练时间增加、需要重放训练数据、调参周期变长。所以我的建议是先做 PTQ用校准集快速评估掉点幅度再决定是否有必要进入 QAT而不是一上来就用 QAT。5. LLM 量化为什么大语言模型的量化更难以及主流做法5.1 LLM 量化的难点与普通 CNN 的本质差异很多在中型 CNN 上效果好到掉点几乎为 0 的量化方案一旦搬到 LLM 上就会崩原因是两者激活分布有本质差异。CNN 的激活分布通常集中在零附近形状类似正态或拉普拉斯分布而 LLM 的激活分布表现出明显的长尾特征一些 token 在特定维度会产生远超普通分布的极大值。如果只按 min/max 方法量化激活这些离群点会直接拖垮整体精度。更麻烦的是LLM 推理时的激活是逐 token 动态产生的无法事先静态校准好。经典 CNN 部署中的静态激活量化在 LLM 场景不适用因为权重可以固定但激活分布十分敏感且变化极大。所以 LLM 常采用动态量化或混合精度方案权重用 INT4/INT8 静态量化省显存激活在推理时动态确定 scale。5.2 三套主流量化方案解读GPTQ、AWQ与SmoothQuant先说 GPTQ。它本质是逐层或逐列的权重量化方法核心思路是量化某一层的权重时用 Hessian 矩阵衡量每个权重的重要性优先保证重要权重不被过度截断再通过误差补偿更新剩余权重。它在低比特INT4/INT3下效果很好因此主流开源模型量化后的版本大多基于 GPTQ。实操时候最常见的问题是校准集过于单一会导致量化模型对特定领域 prompt 掉点明显建议校准文本尽量覆盖多领域。再看 AWQActivation-aware Weight Quantization。它不依赖反向传播或重建而是根据激活值统计找出显著权重通道对这些通道的量化尺度做放大scale up再配合逐层搜索减小误差。AWQ 的优势是速度快、稳定性高几乎不需要校准样本。我实测同为一个 7B 模型在 4-bit 权重下AWQ 的推理精度通常能比 GPTQ 略高一点点但显存占用两者相当。还有 SmoothQuant它针对的是激活难量化、权重易量化的问题。核心做法是把激活里的量化难度转移到权重侧对激活的每个通道除以一个平滑因子对权重对应的通道乘上同一个因子。通过这个变换原本尖峰明显的激活分布被压平量化误差大幅下降而权重侧因为有更强的冗余度多承受一点缩放也不会伤筋动骨。这个方法在日常部署中我用得很多尤其当模型里有较多动态激活时SmoothQuant 几乎是无损量化激活的唯一选择。5.3 KV Cache 量化与显存优化思路LLM 推理还有一个专门耗时耗显存的部分KV Cache。随着序列长度增加它在显存中占比越来越大尤其长上下文场景下甚至超过模型权重本身。KV Cache 量化的核心是对缓存下来的 Key 和 Value 矩阵做低精度存储常见做法是 INT8 甚至 INT4 量化推理时再反量化回浮点参与注意力计算。这部分我有两个实用经验其一Key 的量化要谨慎Key 直接参与注意力得分计算量化误差会放大到 softmax 结果上建议对 Key 用更高精度如 FP8 或 INT8 动态量化而 Value 的容错通常更大可以考虑更激进的 4-bit 压缩。其二结合 PagedAttention 这类显存管理方案时KV Cache 的量化需要额外考虑跨 page 的连续性否则反量化时的内存寻址会变得异常麻烦。5.4 部署 LLM 量化模型时容易被忽略的问题第一INT4 权重在 GPU 上并不能直接用标准 INT4 矩阵乘来加速实际部署时往往会先反量化回 FP16/BF16 做计算此时省下来的是显存带宽而不是算力吞吐。所以如果你的目标是单卡推理吞吐更快INT4 未必比 BF16 有帮助如果你的目标是装进显存更小的机器那 INT4 就是必须的。第二某些量化格式在 CPU 和 GPU 上的输出会不一样。我在 x86 上跑 GGUF 量化版模型时和 GPU 上 TensorRT-LLM 加载同样的量化权重结果有小幅差异这类差异来自不同的反量化算法和算子融合策略。跨平台部署时要接受这种细微的不一致除非你用完全相同的推理引擎和协议否则不要试图逐 bit 对齐。6. 量化参数的极端边界一次性理清 FP32、FP16、BF16、INT8、FP8 与算力关系部署新手经常把各种精度混为一谈这里一次性讲透。FP32 就是单精度浮点1 bit 符号位、8 bit 指数、23 bit 尾数FP16 是半精度指数位减少到 5 bit、尾数位减少到 10 bit动态范围明显缩小训练时容易溢出BF16 是 Brain Floating Point指数位和 FP32 一样是 8 bit尾数只有 7 bit它保留了大动态范围但牺牲了精度所以深度学习训练中尤其适合大数值范围场景。INT8 是定点数没有指数位只能表示 256 个刻度但它精度均匀计算单元密度远高于浮点单元。FP8 是近几年的新格式包含 E4M3 和 E5M2 两种子格式在部分新一代 GPU 上算力可以达到 FP16 的两倍左右同时精度比 INT8 更容易处理非均匀分布的数据。算力需求这条线上我的经验排序大约是同硬件下FP16 约等于两倍 FP32 峰值INT8 约等于四倍 FP32 峰值FP8 在支持的硬件上接近 INT8 水平。但实际推理速度还受内存带宽瓶颈制约这是为什么量化在带宽受限场景如 LLM 大权重流式读取能获得接近线性收益的原因。7. 量化落地时的全流程极简清单与踩坑复盘最后整理一份我每次做量化部署都会走一遍的流程清单先用预训练模型做 FP32 推理记录精度基线和性能基线这是所有后续对比的锚点。导出去 BN 的模型或者融合 BN 的 ONNX保精度。准备校准集领域匹配、数据均衡、前处理完全一致数量 200~500 条起步。尝试静态量化PTQ评估 INT8 掉点情况。若掉点在 1~2 个点以内直接可用。若掉点明显先排查校准集和预处理再尝试百分位/MSE 校准还是不行就进入 QAT。QAT 阶段从预训练权重出发使用小学习率先 warmup再训练 1~2 个 epoch冻结权重量化参数后继续训练。部署阶段验证输出一致性注意 CPU/GPU/NPU 之间的细微差异。性能分析分别测显存占用、延迟和吞吐不要只看一个指标。在踩坑复盘里我最想强调的还是校准集的预处理一致性。因为这个坑伪装性很强表面上看量化参数统计没问题实际每个激活层的分布都偏移了。其次就是 QAT 的收敛性如果你发现训练 loss 正常下降但量化精度始终上不去请立刻检查是不是 BN 的统计均值没有被正确冻结或更新——我因为这个原因浪费过整整两天。8. 写在最后的实操体会量化这条路说到底是在精度、速度和工程复杂度之间做权衡。没有一套方案能通吃所有模型关键还是要建立先量化评估、再针对瓶颈优化的思维习惯。从我个人的经验来看能把 FP32 模型跑到 1ms 以内的设备换到 INT8 往往能压到 0.3ms 左右但前提是对齐好校准集、选对量化位置、仔细验证每个层的输出范围。最后再分享一个小技巧如果你的量化模型总是出现整体输出偏亮或偏暗之类的系统性偏差去检查一下零点位置的舍入方式——四舍五入和向下取整的实现差异在极端情况下足以造成一个不可忽略的偏移。这个细节网上很少有人提起但在深夜部署现场它可能比调一整天校准算法更管用。