最近有朋友跟我吐槽说在边缘设备上部署模型时被精度掉点折磨得够呛。他训练好的MobileNetV3分类模型FP32精度92%直接套PyTorch官方的动态量化或者静态量化PTQ精度直接掉到88%以下完全没法用。这其实是部署落地阶段特别典型的场景模型跑起来了但精度崩了。我给他的建议很简单——上QATQuantization-Aware Training量化感知训练。用PyTorch的QAT流程重新训练几个epoch之后精度基本能拉回到91%以上掉点在1个点以内完全可以接受。这篇文章我就以PyTorch为工具把QAT从原理到实操完整拆一遍包括为什么PTQ会掉点、QAT是怎么把精度救回来的、代码怎么写、有哪些坑我必须提前帮你踩平。内容适合两类人看一类是模型训练完准备部署到边缘设备、但被PTQ精度搞崩的工程师另一类是刚接触量化、想知道QAT和PTQ到底差在哪儿的同学。文章里的代码我全程用PyTorch官方API实现保证你能跑、能复现。1. 先搞清楚量化到底动了模型的什么东西1.1 量化为什么会掉精度量化说白了就是把模型里的FP32浮点数换成INT8整数来存储和计算。一个普通的卷积层权重是FP32输入特征图也是FP32。量化之后权重和激活值都变成INT8的整数再用整数乘加指令去算。FP32能表达的精度范围是非常广的从非常小的数到非常大的数都能表示但INT8只能表达256个离散值。这就好比你用一把厘米刻度的尺子去量一个需要毫米精度的工件肯定会有误差。量化的核心公式很简单q round(clamp((r / scale) zero_point, qmin, qmax))r是原始的浮点数scale是缩放系数zero_point是零点偏移q就是量化后的整数。反量化就是把q还原成浮点r_hat (q - zero_point) * scale这个r_hat和原始r之间存在误差叫做量化误差。量化误差一旦在网络的层层传播中累积起来模型输出的softmax概率分布就可能偏离正确方向精度自然就掉了。1.2 PTQ和QAT的路线差异PTQPost-Training Quantization训练后量化的做法是模型训练完之后拿一小部分校准数据统计每一层激活值的分布范围然后算出scale和zero_point直接把FP32模型转成INT8模型。这个流程快、不用重新训练但它有个先天缺陷——量化误差是在模型已经收敛到FP32最优解之后才引入的网络完全没有机会去适应这个误差。QAT的思路完全不同。它在训练过程中就模拟量化带来的影响前向传播时把权重和激活值都做一遍“伪量化”fake quantize也就是先量化成INT8再反量化回FP32让损失函数在训练时就能感知到量化误差的存在。梯度按照直通估计器STE, Straight-Through Estimator的方式来反向传播。这样模型在反向更新时会主动调整权重分布让量化之后的表现尽量接近原始浮点表现。一句话总结PTQ是“先训练后补偿”QAT是“边训练边适应”。从实测效果来看QAT在轻量级网络MobileNet系列、EfficientNet-lite系列上的提升尤其明显这些模型本身参数冗余少对量化误差更敏感。1.3 QAT在PyTorch里的实现方式PyTorch对QAT的支持经历了好几代API更迭。最早是torch.quantization后来迁到torch.ao.quantizationPyTorch 2.x之后推荐用torch.ao.quantization里的新接口。老接口虽然没有被删但文档已经开始淡化。在动手写代码前先建立两个基本认知QAT不是一个独立的训练脚本它是在正常训练流程里插入“量化模拟”逻辑。QAT训练完的模型不能直接拿去部署还需要经过一步“转换”convert把伪量化节点转成真正的INT8量化算子。我在本文中的示例代码基于PyTorch 2.1及以上版本使用torch.ao.quantization接口读者如果用的是1.x版本部分API命名会略有差异但整体流程一致。2. 环境准备与整体方案设计2.1 环境搭建的几点建议PyTorch的CPU版本和GPU版本都支持QAT但注意一点QAT训练时GPU能加速但convert之后要验证INT8模型的推理速度CPU上更接近真实部署环境。建议开发机上同时装好CPU版和GPU版或者直接用一台带CUDA的机器用CUDA跑训练用CPU跑INT8推理验证。创建虚拟环境的时候我习惯用conda干净、隔离性好conda create -n qat python3.9 conda activate qat pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118上面这条命令装的是CUDA 11.8版本如果你的机器环境不是这个版本去PyTorch官网选一个匹配的安装命令就行。跑示例代码只需要torch和torchvision不需要额外安装其他依赖。我见过不少人在环境上踩坑比如安装的torch版本太老torch.ao.quantization还没有QAT的fuse_eval_model工具或者Python版本太高和torch版本不匹配。我的建议是直接用PyTorch 2.x系列不要用1.12以前的版本QAT的API在1.12之后才逐步稳定。2.2 方案选型一套适合动手复现的任务为了让整个QAT流程清晰可见我这里选一个图像分类任务来演示数据集用CIFAR-10。它只有10个类别、6万张32x32的小图单卡GPU十几分钟就能训完一个epoch非常适合做量化方案验证。模型选择方面我用ResNet-18。它有BatchNorm层、有残差连接结构上有代表性而且QAT能精确覆盖残差分支上的量化处理方式能帮我们理解很多细节。如果你想替换成自己的模型核心流程完全不变。整体方案分四步走先用FP32精度的正常训练脚本训一个精度合格的baseline。在baseline基础上插入QuantStub、DeQuantStub和伪量化节点做成QAT模型。用一个小学习率继续训练几个epoch让模型适应量化误差。convert成INT8静态量化模型验证最终精度和性能。下面按这个方案逐步展开。3. 准备工作训练一个FP32基准模型3.1 基准模型的定义与训练要点很多人一上来就直接做QAT省掉了FP32 baseline这一步这是大忌。没有baseline你根本不知道QAT到底把精度恢复到什么程度。所以第一步老老实实把FP32模型训练好。定义模型时需要预留两个口子输入端口插入QuantStub输出端口插入DeQuantStub。这一步虽然可以等QAT阶段再加但我建议一开始就加上。原因很简单加入这两个模块之后模型结构就固定下来了后续做fuse、做QAT配置都不用再动主干网络。我给出一个可以直接跑的分类任务训练伪代码import torch import torch.nn as nn import torchvision import torchvision.transforms as transforms # 数据预处理 transform_train transforms.Compose([ transforms.RandomCrop(32, padding4), transforms.RandomHorizontalFlip(), transforms.ToTensor(), transforms.Normalize((0.4914, 0.4822, 0.4465), (0.2023, 0.1994, 0.2010)), ]) transform_test transforms.Compose([ transforms.ToTensor(), transforms.Normalize((0.4914, 0.4822, 0.4465), (0.2023, 0.1994, 0.2010)), ]) trainset torchvision.datasets.CIFAR10(root./data, trainTrue, downloadTrue, transformtransform_train) testset torchvision.datasets.CIFAR10(root./data, trainFalse, downloadTrue, transformtransform_test) trainloader torch.utils.data.DataLoader(trainset, batch_size128, shuffleTrue, num_workers4) testloader torch.utils.data.DataLoader(testset, batch_size256, shuffleFalse, num_workers4) # 定义模型在ResNet18的输入和输出处加hook class QuantizableResNet18(nn.Module): def __init__(self, num_classes10): super().__init__() self.quant torch.ao.quantization.QuantStub() self.model torchvision.models.resnet18(weightsNone, num_classesnum_classes) self.dequant torch.ao.quantization.DeQuantStub() def forward(self, x): x self.quant(x) x self.model(x) x self.dequant(x) return x model QuantizableResNet18()训练部分我用标准的交叉熵损失和SGD优化器正则化weight_decay设5e-4训练100个epoch在第30、60、90个epoch把学习率从0.1降到0.01、0.001、0.0001。训练结束后记录FP32在测试集上的准确率。我实测CIFAR-10上Flops并不多单张RTX 3090大概十几分钟就能训完但如果你用CPU时间会翻好几倍建议直接用GPU。3.2 FP32精度与后续量化精度的对比基线FP32 baseline的意义不仅仅是看精度数字更重要的是用来和QAT结果做对照实验。打个比方baseline是92%PTQ之后是87%QAT之后是91%那你就知道QAT多保住了4个点的精度。如果baseline本身就只有85%QAT最多也只能恢复到84%、85%左右它不能凭空创造精度。所以我通常这样定义量化方案是否合格QAT精度与FP32精度差距小于1个百分点说明方案非常成功。差距在1到2个百分点说明可以接受需要进一步调参。差距超过2个百分点说明某些关键环节没做对。用这个标准你就能快速判断自己是否踩了大坑。下面开始进入QAT实操环节每一步我都会写清楚原因。4. PyTorch QAT实操全流程4.1 模型融合ConvBNReLU的合并在做QAT之前第一步要做模型融合fuse把Conv2d、BatchNorm2d、ReLU合并成一个ConvBnReLU模块。为什么要做这一步因为推理部署时Conv和BN是必须合并的BN在推理阶段可以折算进卷积的权重和偏置里变成一个纯卷积算子。如果QAT训练时不先融合训练阶段的数值流和部署阶段的数值流不一致量化模拟就不准确。在PyTorch中用torch.ao.quantization.fuse_modules实现import torch.ao.quantization as tq model.eval() model.fuse_model() # 如果你用了torchvision自带模型可以这样写 # model.model.fuse_model()注意fuse操作必须在model.eval()模式下进行因为BN层的统计量在训练和推理模式下行为不同融合时依赖的是eval模式的running_mean和running_var。模型不同fuse的配置也不同torchvision的resnet系列可以直接调用model.fuse_model()但如果你用的是自定义模型需要自己提供fuse_list比如tq.fuse_modules(model, [[conv1, bn1, relu]], inplaceTrue)4.2 QAT配置Observer与量化参数的设定QAT的精度很大程度上取决于量化配置。PyTorch里用QConfig来定义权重和激活的量化参数用什么observer统计数值范围、按什么粒度量化。我常用的配置如下model.qconfig tq.QConfig( activationtq.FakeQuantize.with_args( observertq.MovingAverageMinMaxObserver, quant_min0, quant_max255, dtypetorch.quint8, qschemetorch.per_tensor_affine ), weighttq.FakeQuantize.with_args( observertq.MinMaxObserver, quant_min-128, quant_max127, dtypetorch.qint8, qschemetorch.per_tensor_symmetric ) )这里面的门道很多我挑三个关键点说。第一激活值用per-tensor非对称量化因为激活值的分布通常不是以0为中心的如果用对称量化一半的量化区间可能浪费在很小的负值上精度损失大。非对称量化用zero_point去补偿偏移对激活更友好。第二权重用per-tensor对称量化因为权重分布大致是以0为中心的对称量化不需要zero_point计算更简单而且int8的-128到127全都能用上。第三observer方面权重用MinMaxObserver简单直接因为权重数值范围稳定激活用MovingAverageMinMaxObserver它会用滑动平均来平滑范围估计避免个别outlier造成范围虚大。关于observer的更细对比见下面这个表Observer统计方式适用场景优点缺点MinMaxObserver记录最小值/最大值权重、分布稳定的激活简单、直观对离群点敏感MovingAverageMinMaxObserver滑动平均更新min/max激活值平滑、稳定需要调smoothing参数PercentileObserver按百分位取范围有长尾分布的激活抗离群点能力强计算复杂度略高4.3 插入QuantStub和DeQuantStub这一步其实在定义模型时已经做好了。QuantStub的职责是当模型处于训练模式时它是恒等映射当模型处于推理模式时它负责把FP32输入转成量化表示。DeQuantStub相反把量化输出转回FP32。这两个模块就像“海关”在两个数值域之间做合法转场。如果你用的是torchvision.models.resnet18(weights...)这类预训练模型它内部没有QuantStub和DeQuantStub你需要自己包一层。我这里建议直接继承nn.Module写一个包装类像上面3.1节那样。对于自定义模型同样的思路在forward的第一行插入self.quant(x)在最后一行插入self.dequant(x)。4.4 prepare_qat把模型切换成训练模式PyTorch提供了prepare_qat方法专门用于QAT阶段。它会把QConfig里指定的FakeQuantize模块插入到模型对应层中并且把模型切换成训练模式。model.train() model tq.prepare_qat(model, inplaceTrue)注意prepare_qat必须在model.train()之后调用。FakeQuantize节点在训练和推理模式下行为不同训练时它会持续更新observer统计的范围推理时则固化范围。如果顺序搞反了你会发现训练时精度正常但convert之后精度崩了因为范围根本没统计好。还有一个细节prepare_qat会保留模型里的BN层统计量更新所以在QAT训练过程中BN层依然会随着训练更新running_mean和running_var这一点和普通的fine-tune是一致的。4.5 QAT训练学习率、epoch数与损失函数QAT不需要从零训练它是在baseline基础上继续微调所以学习率必须小。我用baseline的初始学习率的十分之一甚至二十分之一比如baseline初始学习率0.1QAT阶段就用0.001再配合余弦退火或者StepLR逐步降到0。epoch数建议10到20个。太少模型没有充分适应量化噪声太多可能会在FP32模拟的量化域上过拟合导致convert后反而变差。我一般先在验证集上每训练完一个epoch就测一次模型此时模型还是带FakeQuantize的记录“模拟量化精度”这个值基本就是最终INT8精度的上限。损失函数不用改还是交叉熵。但优化器最好加上weight_decay保持和baseline训练一致的正则化强度。QAT训练关键代码import torch.optim as optim # 优化器小学习率 optimizer optim.SGD(model.parameters(), lr0.001, momentum0.9, weight_decay5e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max10) def train_one_epoch(model, trainloader, criterion, optimizer): model.train() running_loss 0.0 for images, labels in trainloader: images, labels images.cuda(), labels.cuda() optimizer.zero_grad() outputs model(images) loss criterion(outputs, labels) loss.backward() optimizer.step() running_loss loss.item() * images.size(0) return running_loss / len(trainloader.dataset) def evaluate(model, testloader): model.eval() correct 0 total 0 with torch.no_grad(): for images, labels in testloader: images, labels images.cuda(), labels.cuda() outputs model(images) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() return 100.0 * correct / total for epoch in range(10): loss train_one_epoch(model, trainloader, criterion, optimizer) acc evaluate(model, testloader) scheduler.step() print(fEpoch {epoch1}, Loss: {loss:.4f}, QAT模拟精度: {acc:.2f}%)4.6 convert从QAT模型到INT8静态量化模型训练结束后模型还带着FakeQuantize节点这时候必须调用convert把它变成真正的INT8推理模型model.eval() model tq.convert(model, inplaceTrue)convert之后模型里的FakeQuantize会变成真正的量化/反量化节点卷积层的权重会被永久量化成INT8。此时再跑model(images)输入可以是FP32的Tensorquant节点会负责在内部完成量化。有一个非常重要的检查点必须在convert之后重新用测试集评估一次精度。我见过很多人在QAT训练阶段精度看着很好convert之后精度却和训练时明显不一致这说明QAT训练和部署推理之间存在数值流不一致的问题。常见原因就是fuse没做彻底或者FakeQuantize范围没有冻结干净。4.7 完整的QAT流程串起来把上面几个步骤完整地串起来整个QAT pipline如下# 1. 加载FP32 baseline model QuantizableResNet18() checkpoint torch.load(baseline_fp32.pth) model.load_state_dict(checkpoint[model_state_dict]) # 2. 模型融合 model.eval() model.fuse_model() # 3. 配置QConfig model.qconfig tq.QConfig( activationtq.FakeQuantize.with_args( observertq.MovingAverageMinMaxObserver, quant_min0, quant_max255, dtypetorch.quint8, qschemetorch.per_tensor_affine ), weighttq.FakeQuantize.with_args( observertq.MinMaxObserver, quant_min-128, quant_max127, dtypetorch.qint8, qschemetorch.per_tensor_symmetric ) ) # 4. prepare_qat model.train() model tq.prepare_qat(model, inplaceTrue) # 5. QAT训练若干epoch train_loop(model, trainloader, num_epochs10) # 6. 验证模拟量化精度 qat_acc evaluate(model, testloader) # 7. convert为INT8模型 model.eval() model tq.convert(model, inplaceTrue) # 8. 验证INT8推理精度 int8_acc evaluate(model, testloader) print(fQAT模拟精度: {qat_acc:.2f}%, INT8实际精度: {int8_acc:.2f}%)5. 量化参数的作用原理与常见调参方向5.1 量化粒度的权衡per-tensor与per-channel上面的QConfig里权重用的是per-tensor简单直接但在某些模型中per-channel能保住更多精度。per-channel的含义是每个输出通道单独算一个scale和zero_point精度更高但推理时计算开销也更大。在PyTorch中per-channel权重的配置只需要改两行weighttq.FakeQuantize.with_args( observertq.PerChannelMinMaxObserver, quant_min-128, quant_max127, dtypetorch.qint8, qschemetorch.per_channel_symmetric )我什么时候会用per-channel当我发现量化后某一层的权重分布差异极大某些通道数值范围特别小、另一些特别大的时候。这种情况多出现在深度可分离卷积或者注意力机制相关的层里。per-tensor会用一个很大的scale去量化整个权重张量导致数值范围小的通道被严重挤压精度损失大。5.2 数字格式对称量化 vs 非对称量化对称量化不引入zero_point公式简化为q round(clamp(r / scale, qmin, qmax))非对称量化多一个zero_point公式复杂一些但能更好地适应分布偏移。一个常见的经验规则权重用对称量化-128到127因为权重可以预先做预处理而且没有zero_point会让硬件实现更高效。激活用非对称量化0到255因为经过ReLU之后的激活值基本为非负非对称量化可以把整个量化区间集中在0到max范围内精度更好。你看到上面QConfig里activation设的quant_min0、quant_max255其实就是在用ReLU后的分布特性。如果你的网络最后一个激活不是ReLU而是sigmoid或者tanh那就要按实际分布调整范围。5.3 observer的敏感度与校准集PTQ里有个“校准集”calibration dataset的概念就是拿一批有代表性的数据去统计激活值范围。QAT里其实也在做类似的事只是它是在训练过程中持续做不需要单独的校准环节。但有个细节容易忽略FakeQuantize的observer在QAT训练中会不断更新min/max理论上训练结束时的min/max应该收敛到比较稳定的值。如果训练过程中min/max还在剧烈跳动说明模型还没有收敛这时候直接convert量化的范围选择会很差精度必定受影响。解决方法是让QAT训练跑足够多的epoch并且在训练后期可以冻结observer的更新让量化参数稳定下来。PyTorch里可以通过model.apply(tq.disable_observer)或设置observer.enabledFalse来实现。冻结observer之后再多跑几个epoch让权重去适应固定的量化范围这个策略在一些敏感模型上效果很明显。6. 验证与精度损失分析6.1 模拟量化精度 vs 真实INT8精度QAT训练过程中打印的精度是“模拟量化精度”也就是带FakeQuantize节点的模型在FP32数值域上跑出来的精度。这个精度可以理解成一个“预期上限”。convert之后模型真正用INT8的方式计算精度可能会略低于模拟值但理论上差距应该非常小。如果你发现模拟精度和真实INT8精度差很多问题大概率出在模型结构的数值流上。比如某个算子在PyTorch的静态量化中不受支持会被自动落到FP32导致一部分层是INT8、一部分层是FP32这种混合精度下如果关键层落到FP32性能会损失但精度没问题如果关键层量化错了精度就会崩。用torch.ao.quantization提供的调试工具torch.ao.quantization.get_quantized_model_info或者直接打印模型的quantized层分布能快速定位问题。6.2 需要关注的精度指标整体准确率、单类准确率、校准误差不要只看整体准确率。在分类任务里我建议同时统计每个类别的召回率和校准误差calibration error。量化可能会让某个不占优势的类别精度下降特别多但在整体准确率上被平均掉掩盖了。具体做法打印一个混淆矩阵对比FP32和INT8在哪些类别上预测不一致重点看模型输出置信度分布是否偏移。如果INT8模型的平均置信度比FP32低很多说明量化的scale选择偏大数值普遍被压缩了反之如果置信度偏高说明范围偏小很多数值被截断到了边界。6.3 性能指标模型体积压缩与推理加速在CPU上跑INT8静态量化模型实测ResNet-18的推理速度能提升2到3倍模型体积从44.7MB左右降到11.2MB左右这背后就是4倍的压缩比——每个权重从4字节变成1字节。但有个反直觉的现象QAT在GPU上训练时带FakeQuantize的模型比普通模型要慢因为伪量化操作本身有计算开销。这是正常的我们的目标是部署阶段的加速不是训练阶段的加速。所以评估QAT收益一定要用convert之后的INT8模型在同一硬件平台上对比不是在训练阶段比速度。7. 避坑指南与常见问题排查7.1 踩坑实录最让人头疼的5个问题我做QAT踩过的坑按杀伤力排个序坑1精度掉点完全无法恢复。先检查model.eval()和prepare_qat的顺序再检查fuse是否彻底。这两个步骤出错后续全部白做。坑2训练过程正常convert后精度直接崩。大概率是量化参数范围统计不全。解决延长QAT训练时间或者在最后几个epoch冻结observer让范围固定下来。坑3模拟量化和真实INT8精度差距大。重点排查模型里是否有不支持量化的算子比如某些自定义op、GELU、LayerNorm在CPU上的静态量化支持可能不完整。对策是给这些层单独配置qconfigNone让它们保持FP32。坑4BN层在QAT中表现异常。如果QAT训练时BN的running_mean和running_var一直在飘模型精度就会出现忽高忽低的抖动。解决在prepare_qat之前先把BN层设置为eval模式或者使用小学习率让BN统计量变化更平稳。坑5权重分布出现大量离群点。如果你的损失函数里有特别大的梯度或者某些层权重初始化不合适量化时会出现个别超大权重主导scale的情况。解决在QAT训练前检查权重直方图对明显的离群层做weight clipping或单独调整量化配置。7.2 常见问题速查表问题现象常见原因解决方案QAT精度远低于FP32学习率过大模型被量化噪声扰动调低学习率增加训练epochconvert后模型报错模型包含不支持的算子给该层设置qconfigNone保持FP32INT8推理速度提升不明显部分层仍为FP32或batch太小用size较大的batch benchmark检查量化层占比训练时loss震荡严重observer范围未收敛冻结observer后再训练边缘设备部署后精度与PC不一致算子实现差异、混合精度处理不同在目标设备上重新校准或收集更多校准数据7.3 数据分布与初始化等隐藏问题QAT虽然叫“训练”但它不是万能药。如果训练数据本身和部署数据分布差异巨大再好的QAT也救不回来。我建议在QAT之前做一个简单的分布对齐检查把训练集和测试集的特征分布可视化一下如果严重错位先考虑数据问题再考虑量化问题。模型初始化也值得一提。QAT最好从baseline的权重开始而不是从随机初始化开始。随机初始化的模型在QAT里训练不仅收敛慢还容易陷入局部最优因为量化噪声在小权重和随机权重上的干扰更大。8. 模型导出与部署衔接8.1 导出为ONNX的注意事项在边缘设备上部署很多场景走ONNX路线。PyTorch的量化模型导出ONNX时需要同时处理量化和反量化节点。PyTorch 2.x对量化ONNX导出支持已经完善很多但需要注意导出的ONNX模型可能包含QDQQuantize-Dequantize节点这套格式在ONNX Runtime里被完整支持能发挥INT8算子的加速能力。导出代码如下model.eval() dummy_input torch.randn(1, 3, 32, 32) torch.onnx.export( model, dummy_input, resnet18_qat.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}} )opset_version低的话某些量化算子可能不支持建议至少用13以上。如果要用TensorRT部署那需要考虑TensorRT对QDQ节点的解析方式有时候需要在导出时显式指定量化算子类型。8.2 在ONNX Runtime与TensorRT上的精度验证拿到导出的模型不要直接丢到设备上就跑。先在ONNX Runtime上验证精度import onnxruntime as ort import numpy as np sess ort.InferenceSession(resnet18_qat.onnx, providers[CPUExecutionProvider]) input_name sess.get_inputs()[0].name output_name sess.get_outputs()[0].name # 测试集精度重算 correct 0 total 0 for images, labels in testloader: images_np images.numpy() outputs sess.run([output_name], {input_name: images_np})[0] _, predicted torch.max(torch.from_numpy(outputs), 1) total labels.size(0) correct (predicted labels).sum().item() print(fONNX INT8精度: {100 * correct / total:.2f}%)如果ONNX Runtime的精度和PyTorch直接跑INT8模型一致说明导出没有问题。如果精度在这一步突然掉了优先怀疑ONNX算子融合策略去ONNX Runtime的配置里关闭或开启某些优化项对比精度变化。TensorRT上精度验证逻辑类似但需要注意TensorRT的量化算子接受的是QDQ格式导出的ONNX必须带有完整的QDQ节点。8.3 实际部署环境的适配与配置最后到设备上部署还有几个变量要确定输入图像的预处理流程必须和训练时完全一致包括归一化的mean和std。很多掉点案例最后发现是部署代码里忘了做Normalize或者mean/std写错了。此外如果你的设备是FPGA那么per-layer的量化参数导出格式可能和PyTorch默认格式不同通常需要自己写一个导出脚本把每个层的scale、zero_point、权重整数矩阵导出成特定格式。PyTorch提供了model.state_dict()可以拿到量化后的整数权重再用torch.dequantize()可以拿到浮点参照这个在对接FPGA工具链时会很有用。9. 写在最后的几个经验我在实际项目中体会到QAT不是万能的但它是目前把模型精度损失控制在1%以内的最稳妥方案。跑QAT就像是给模型打了一针“量化疫苗”让它提前接触并适应低精度环境的种种不便。帮别人排查量化问题时我发现大多数人失败的原因不在QAT本身而是在它前后一步——要么baseline没训好要么convert之后的部署链路没验证透。只要把这两头打通中间QAT的部分其实很顺。最后给大家一个可以直接抄的经验如果时间紧张优先在QAT训练的后半段冻结observer把训练epoch控制在10个左右学习率用baseline的1/10。这个组合在ResNet和MobileNet系列上表现都非常稳定。按照这套流程走完你的模型大概率能在边缘设备上既跑得快又不掉面子。