1. 为什么模型优化器值得单独拿出来聊做深度学习的人都有一个共同的痛点模型越训越大显存越来越不够用推理延迟越来越高部署成本压不下来。你可能会说那就换更小的模型呗。但现实情况往往是精度掉一点业务方就不干了速度慢一点用户就跑了。所以真正要解决的问题不是“换模型”而是“在尽量不损失精度的前提下让模型跑得更快、更小、更省资源”。这就是Model-Optimizer这个方向存在的意义。它不是一个具体的库或者框架而是一类工具和方法的统称涵盖了量化、剪枝、蒸馏、算子融合、图优化等一系列让模型“瘦身提速”的技术手段。你可以把它理解成模型训练完成之后的“精加工车间”——原始模型是一块毛坯经过优化器的处理变成一件既轻便又锋利的成品。我接触这个方向差不多有几年了从最早手动写量化脚本到后来用各种开源工具链踩过的坑可以说数不胜数。这篇文章我会把 Model-Optimizer 涉及的核心技术点、实操流程、工具选型思路、以及那些文档里不会写的避坑经验全部摊开来聊。不管你是刚入门想了解模型优化到底在做什么还是已经有一定经验想找一套可复现的方案应该都能从里面找到有用的东西。2. 模型优化器的核心技术版图2.1 量化把浮点数变成整数最直接的提速手段量化是模型优化里最常被提到的技术没有之一。它的核心思想很朴素神经网络里的权重和激活值默认是 FP3232位浮点数每个数占4个字节。但如果我把它们换成 INT88位整数每个数只占1个字节模型体积直接缩小到原来的四分之一内存带宽需求也同步下降推理速度自然就上去了。但事情没这么简单。FP32 能表示的数值范围大约是 (10^{-38}) 到 (10^{38})精度可以到小数点后很多位。INT8 只能表示 -128 到 127 之间的整数。你直接把 FP32 的权重截断成 INT8精度必然崩。所以量化的关键在于找到一个合理的映射关系把浮点数的分布“压缩”到整数空间里同时尽量保留原始信息的区分度。常见的量化方案分两大类训练后量化PTQPost-Training Quantization模型训练完之后拿一批校准数据跑一遍统计每层激活值的分布范围然后计算出量化参数scale 和 zero_point。整个过程不需要重新训练几分钟到几十分钟就能搞定。适合快速验证和部署场景。量化感知训练QATQuantization-Aware Training在训练过程中就模拟量化的误差让模型自己去适应这种精度损失。训练完之后再导出量化模型精度通常比 PTQ 好不少但需要完整的训练流程和标注数据。我个人的经验是对于大部分视觉模型比如 ResNet、YOLO 系列PTQ 用 INT8 量化之后精度损失通常在 1% 以内完全可以用。但对于 Transformer 类模型尤其是层数深、注意力机制复杂的PTQ 有时候会掉好几个点这时候就得上 QAT 或者混合精度量化。2.2 剪枝去掉冗余的连接和通道剪枝的思路也很直观神经网络里有很多参数其实是“冗余”的对最终输出的贡献极小。把这些冗余部分去掉模型自然就变小了。剪枝分两种粒度非结构化剪枝把单个权重置零不管它属于哪个通道或哪个卷积核。这种剪枝粒度最细理论上能去掉最多的参数但问题是稀疏矩阵在通用硬件上并不一定能加速除非你有专门的稀疏计算库或者硬件支持。结构化剪枝直接砍掉整个通道、整个注意力头、甚至整个层。这种剪枝对硬件友好因为剪完之后还是一个稠密矩阵推理引擎不需要特殊处理就能加速。但粒度粗可能会误伤一些有用的信息。实际操作中结构化剪枝更常见。流程一般是先训练一个完整的模型然后根据某种重要性指标比如权重的 L1/L2 范数、BN 层的缩放因子、梯度信息等给每个通道打分把分数低的通道剪掉然后对剪枝后的模型做微调恢复精度。这个过程可以迭代多轮逐步压缩。2.3 知识蒸馏让小模型学会大模型的本事蒸馏的思路和前两者不太一样。它不是直接压缩原模型而是训练一个小的“学生模型”去模仿大的“教师模型”的行为。学生模型不仅学习真实的标签还学习教师模型输出的软标签soft label也就是每个类别的概率分布。为什么软标签有用举个例子一张猫的图片真实标签是“猫”。但教师模型可能会输出猫 0.85狗 0.10狐狸 0.05。这个分布告诉学生模型“这张图虽然主要是猫但和狗、狐狸也有点像”。这种信息比单纯的 one-hot 标签丰富得多能帮助学生模型学到更好的决策边界。蒸馏的关键在于设计损失函数。通常包括两部分一部分是学生模型输出和真实标签的交叉熵损失另一部分是学生模型和教师模型输出之间的 KL 散度。两者的权重需要调温度参数也需要调。温度越高软标签的分布越平滑学生能学到的“暗知识”越多但太高了也会引入噪声。2.4 算子融合与图优化不改变数值只改变计算方式前面三种方法都在改变模型的数值内容而算子融合和图优化改变的是计算图的组织方式。比如卷积层后面跟一个 BN 层再跟一个 ReLU推理的时候其实可以把 BN 的参数吸收到卷积的权重里变成一个卷积加一个 ReLU减少一次内存读写和一次计算。这就是最经典的 Conv-BN 融合。图优化还包括常量折叠、死代码消除、内存复用等等。这些优化不损失任何精度属于“白捡”的加速。大部分推理引擎TensorRT、ONNX Runtime、TVM 等都会自动做这些优化但如果你自己导出模型的时候格式不对引擎可能识别不出来白白浪费了优化机会。3. 工具选型不同场景该用什么3.1 训练框架原生工具如果你用的是 PyTorch那最顺手的就是torch.quantization和torch.fx。PyTorch 从 1.3 开始就内置了量化支持Eager 模式和 FX Graph 模式都有。FX Graph 模式更适合复杂的模型因为它能对计算图做更彻底的分析和改写。TensorFlow 这边有 TensorFlow Model Optimization Toolkit支持量化和剪枝和 TFLite 配合得很好。如果你最终部署目标是移动端这条路比较顺。原生工具的好处是和训练框架无缝集成不需要额外的格式转换。缺点是优化能力相对有限尤其是图优化层面不如专门的推理引擎做得深。3.2 专用推理引擎TensorRT 是 NVIDIA 家的推理引擎对自家 GPU 的优化做到了极致。它支持 FP16、INT8 量化有强大的图优化和 kernel 自动调优能力。缺点是只支持 NVIDIA 硬件而且模型转换过程中如果遇到不支持的算子需要自己写 plugin。ONNX Runtime 是微软主导的跨平台推理引擎支持 CPU、GPU 和各种边缘设备。它的量化工具链比较成熟支持 PTQ 和 QAT而且和 ONNX 格式天然兼容。如果你需要跨平台部署ONNX Runtime 是比较稳妥的选择。OpenVINO 是 Intel 家的针对自家 CPU、集成显卡和 VPU 做了深度优化。如果你部署在 Intel 平台上OpenVINO 的量化工具POTPost-training Optimization Tool非常好用支持多种量化算法。3.3 自动化优化平台最近两年出现了一些自动化模型优化平台比如 Neural CompressorIntel 开源、NNCFOpenVINO 的神经网络压缩框架等。它们的思路是你只需要提供模型和校准数据平台自动搜索最优的量化策略、剪枝比例、蒸馏方案甚至能做多目标优化同时考虑精度、延迟、模型大小。这类工具适合不想深入底层细节、只想快速拿到优化结果的团队。但缺点是灵活性差一些遇到特殊模型结构可能不支持。4. 实操流程从原始模型到优化部署4.1 第一步建立基线别急着优化很多人一上来就开始量化、剪枝结果优化完了发现精度掉了也不知道是哪个环节出的问题。正确的做法是先建立一个完整的基线原始模型在目标硬件上的精度、延迟、内存占用、模型大小全部记录下来。延迟测试要注意不能只测一次要跑足够多的次数至少100次取平均值和P99。第一次推理通常包含初始化和预热开销要排除掉。Batch size 也要明确batch1 和 batch32 的优化策略可能完全不同。精度测试要用完整的验证集不能只跑几张图看看效果。有些量化误差是累积的单张图看不出来跑完整个数据集才会暴露。4.2 第二步选择合适的优化组合不是所有模型都需要全套优化。根据你的实际瓶颈来选瓶颈类型首选方案次选方案注意事项模型太大存不下INT8 量化剪枝量化量化后精度损失需验证推理太慢延迟高算子融合FP16INT8 量化FP16 通常无损优先尝试内存带宽不够INT8 量化结构化剪枝量化对带宽敏感场景效果显著算力有限边缘设备蒸馏量化剪枝量化蒸馏需要重新训练周期长精度不达标QAT混合精度量化QAT 需要完整训练流程我一般建议的顺序是先做算子融合和图优化无损然后试 FP16几乎无损再试 PTQ INT8可能有损最后才考虑剪枝和蒸馏需要微调或重训。4.3 第三步量化实操细节以 PyTorch 的 PTQ 为例完整流程大致如下import torch import torch.quantization as tq # 1. 加载原始模型 model MyModel() model.load_state_dict(torch.load(model.pth)) model.eval() # 2. 指定量化配置 model.qconfig tq.get_default_qconfig(fbgemm) # x86 CPU # model.qconfig tq.get_default_qconfig(qnnpack) # ARM # 3. 插入观察器 model_prepared tq.prepare(model, inplaceFalse) # 4. 用校准数据跑一遍 with torch.no_grad(): for data in calib_loader: model_prepared(data) # 5. 转换为量化模型 model_quantized tq.convert(model_prepared, inplaceFalse) # 6. 保存 torch.save(model_quantized.state_dict(), model_quantized.pth)这段代码看起来简单但里面有几个关键点qconfig 的选择fbgemm适合 x86 CPUqnnpack适合 ARM。选错了不会报错但性能会很差。校准数据的数量和分布一般用 100-500 张图就够了但必须和实际推理数据的分布一致。如果你用猫狗图片校准然后去推理医学影像量化参数肯定不对。哪些层被量化了不是所有层都适合量化。比如第一层卷积和最后一层全连接通常对精度影响较大可以考虑跳过。PyTorch 允许你通过qconfig单独设置某些层的量化策略。4.4 第四步验证与回归测试优化完的模型必须做完整的回归测试。除了精度指标Top-1、Top-5、mAP 等还要测逐层输出对比用同一批输入对比原始模型和优化模型每一层的输出差异。如果某一层差异突然变大说明那层的量化参数有问题。边界 case 测试全黑图、全白图、极端光照、小目标、遮挡目标这些容易暴露量化误差的场景都要覆盖。长时间稳定性测试有些量化误差在单次推理中不明显但连续跑几个小时可能会累积。尤其是涉及状态更新的模型如 RNN、视频跟踪一定要做长稳测试。5. 踩坑实录与排查技巧5.1 量化后精度暴跌怎么定位问题这是最常见的问题。我的排查顺序是确认校准数据是否正确检查数据预处理是否和训练时一致。归一化参数、通道顺序、尺寸缩放任何一个不一致都会导致量化参数偏差。逐层对比输出用 PyTorch 的 hook 机制把原始模型和量化模型每一层的输出都存下来计算余弦相似度或 MSE。找到差异最大的那层重点分析。检查是否有不支持量化的算子有些自定义算子或者特殊结构如动态 shape 的注意力可能没有被正确量化导致前后层量化参数不匹配。尝试混合精度把敏感层保持 FP32其他层用 INT8。PyTorch 支持通过qconfig_dict精细控制。5.2 剪枝后模型反而变慢了结构化剪枝理论上应该加速但实际中经常遇到剪枝后速度没变甚至变慢的情况。原因通常有两个剪枝后的通道数不是硬件友好的倍数比如 GPU 的 Tensor Core 对 8 的倍数通道数优化最好你剪成 33 个通道反而比 64 个通道还慢。所以剪枝时通常会把通道数对齐到 8 或 16 的倍数。推理引擎没有真正利用稀疏性如果你做的是非结构化剪枝但推理引擎不支持稀疏计算那剪了等于白剪甚至因为要处理稀疏格式而更慢。5.3 蒸馏训练不收敛蒸馏的损失函数是真实标签损失和蒸馏损失的加权和。如果权重没调好学生模型可能完全学不到教师的知识。我的经验是初始阶段蒸馏损失权重大一些比如 0.7-0.9让学生先模仿教师。后期逐渐降低蒸馏损失权重增加真实标签损失权重让学生回归真实任务。温度参数从高到低退火先学全局分布再学细节。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉超过3%校准数据分布不对对比校准集和验证集分布重新采样校准数据量化后推理速度没提升算子未真正量化打印量化模型结构检查 qconfig 和算子支持剪枝后模型无法加载剪枝后结构不匹配对比剪枝前后 state_dict重新导出完整模型蒸馏学生模型不收敛损失权重或温度不当监控两个损失的变化调整权重和温度退火策略ONNX 导出失败不支持的算子查看导出报错信息替换算子或自定义导出TensorRT 转换失败动态 shape 或自定义层查看转换日志固定 shape 或写 plugin6. 一些不太文档化的经验6.1 量化不是越激进越好INT8 是主流但 INT4 甚至二值化网络在某些场景也能用。不过我要说的是量化位宽每降一半精度风险是指数级上升的。INT8 到 INT4精度可能掉 5-10 个点而且不是所有硬件都支持 INT4 加速。除非你的场景对模型大小极度敏感比如单片机部署否则 INT8 是性价比最高的选择。6.2 优化是一个迭代过程不是一锤子买卖我见过很多团队花两周做了一轮量化精度掉了两个点就放弃了。其实模型优化很少能一次到位。通常需要量化→验证→调整→再量化反复几轮才能找到最优配置。每一轮可能只需要改一两个参数但效果差异很大。6.3 别忘了推理引擎本身的优化模型优化只是整个推理链路的一环。推理引擎的配置线程数、内存池大小、batch 策略对最终性能影响也很大。有时候模型优化了半天提升了 20%结果推理引擎配置调一下又提升了 30%。所以优化模型的同时也要花时间调推理引擎的参数。6.4 保留完整的优化日志每次优化实验都要记录用了什么方法、什么参数、精度变化、速度变化、模型大小变化。这些日志在后期排查问题和向团队汇报时非常有用。我一般用 CSV 或者简单的表格记录字段包括实验编号、优化方法、关键参数、精度、延迟、模型大小、备注。6.5 硬件和软件版本要锁死模型优化对硬件和软件版本非常敏感。同样的量化脚本在 PyTorch 1.10 和 1.13 上跑出来的结果可能不一样。TensorRT 8.2 和 8.5 的优化策略也有差异。所以一旦找到一组能工作的配置就把所有版本号记下来不要轻易升级。7. 一个完整的优化案例拆解假设我们有一个 ResNet-50 的图像分类模型部署在 NVIDIA T4 GPU 上要求延迟低于 10ms精度下降不超过 1%。基线测试FP32 模型batch1延迟 15msTop-1 精度 76.5%。第一轮优化FP16。TensorRT 直接支持 FP16不需要校准数据。转换后延迟降到 8ms精度 76.5%无损。已经满足延迟要求了。第二轮优化INT8 PTQ。用 500 张训练集图片做校准TensorRT 的 INT8 量化。延迟降到 5ms精度 75.8%掉了 0.7 个点。在可接受范围内。第三轮优化混合精度。发现第一层和最后一层对精度影响大保持 FP16中间层用 INT8。延迟 5.5ms精度 76.3%。精度恢复了不少延迟只增加了 0.5ms。最终方案混合精度量化延迟 5.5ms精度 76.3%满足所有要求。这个案例里我们没有用剪枝和蒸馏因为量化和 FP16 已经足够了。实际项目中应该优先尝试简单、无损的方法只有在不够用的时候才上复杂方案。8. 模型优化器的未来方向从最近的一些研究和工业实践来看模型优化正在往几个方向走自动化用强化学习或贝叶斯优化自动搜索最优的量化策略、剪枝比例、蒸馏配置减少人工调参。硬件协同针对特定硬件如 NPU、DSP设计专用的优化方案而不是通用的量化剪枝。大模型优化随着 LLM 的普及如何在保持生成质量的前提下压缩大模型成了新的热点。目前主流方案是量化GPTQ、AWQ 蒸馏 稀疏化。训练时优化不只是推理优化训练过程中的显存优化、通信优化、混合精度训练也是 Model-Optimizer 的一部分。我在实际项目中的体会是模型优化没有银弹也没有一套放之四海而皆准的方案。每个模型、每个硬件、每个业务场景都需要单独调优。但只要你理解了量化、剪枝、蒸馏、图优化这几个核心工具的原理和适用场景再结合系统的实验方法就能找到适合自己项目的优化路径。最重要的是别怕试错每一次失败的实验都会让你对模型的理解更深一层。
深度学习模型优化器实战：量化、剪枝、蒸馏与图优化全解析
1. 为什么模型优化器值得单独拿出来聊做深度学习的人都有一个共同的痛点模型越训越大显存越来越不够用推理延迟越来越高部署成本压不下来。你可能会说那就换更小的模型呗。但现实情况往往是精度掉一点业务方就不干了速度慢一点用户就跑了。所以真正要解决的问题不是“换模型”而是“在尽量不损失精度的前提下让模型跑得更快、更小、更省资源”。这就是Model-Optimizer这个方向存在的意义。它不是一个具体的库或者框架而是一类工具和方法的统称涵盖了量化、剪枝、蒸馏、算子融合、图优化等一系列让模型“瘦身提速”的技术手段。你可以把它理解成模型训练完成之后的“精加工车间”——原始模型是一块毛坯经过优化器的处理变成一件既轻便又锋利的成品。我接触这个方向差不多有几年了从最早手动写量化脚本到后来用各种开源工具链踩过的坑可以说数不胜数。这篇文章我会把 Model-Optimizer 涉及的核心技术点、实操流程、工具选型思路、以及那些文档里不会写的避坑经验全部摊开来聊。不管你是刚入门想了解模型优化到底在做什么还是已经有一定经验想找一套可复现的方案应该都能从里面找到有用的东西。2. 模型优化器的核心技术版图2.1 量化把浮点数变成整数最直接的提速手段量化是模型优化里最常被提到的技术没有之一。它的核心思想很朴素神经网络里的权重和激活值默认是 FP3232位浮点数每个数占4个字节。但如果我把它们换成 INT88位整数每个数只占1个字节模型体积直接缩小到原来的四分之一内存带宽需求也同步下降推理速度自然就上去了。但事情没这么简单。FP32 能表示的数值范围大约是 (10^{-38}) 到 (10^{38})精度可以到小数点后很多位。INT8 只能表示 -128 到 127 之间的整数。你直接把 FP32 的权重截断成 INT8精度必然崩。所以量化的关键在于找到一个合理的映射关系把浮点数的分布“压缩”到整数空间里同时尽量保留原始信息的区分度。常见的量化方案分两大类训练后量化PTQPost-Training Quantization模型训练完之后拿一批校准数据跑一遍统计每层激活值的分布范围然后计算出量化参数scale 和 zero_point。整个过程不需要重新训练几分钟到几十分钟就能搞定。适合快速验证和部署场景。量化感知训练QATQuantization-Aware Training在训练过程中就模拟量化的误差让模型自己去适应这种精度损失。训练完之后再导出量化模型精度通常比 PTQ 好不少但需要完整的训练流程和标注数据。我个人的经验是对于大部分视觉模型比如 ResNet、YOLO 系列PTQ 用 INT8 量化之后精度损失通常在 1% 以内完全可以用。但对于 Transformer 类模型尤其是层数深、注意力机制复杂的PTQ 有时候会掉好几个点这时候就得上 QAT 或者混合精度量化。2.2 剪枝去掉冗余的连接和通道剪枝的思路也很直观神经网络里有很多参数其实是“冗余”的对最终输出的贡献极小。把这些冗余部分去掉模型自然就变小了。剪枝分两种粒度非结构化剪枝把单个权重置零不管它属于哪个通道或哪个卷积核。这种剪枝粒度最细理论上能去掉最多的参数但问题是稀疏矩阵在通用硬件上并不一定能加速除非你有专门的稀疏计算库或者硬件支持。结构化剪枝直接砍掉整个通道、整个注意力头、甚至整个层。这种剪枝对硬件友好因为剪完之后还是一个稠密矩阵推理引擎不需要特殊处理就能加速。但粒度粗可能会误伤一些有用的信息。实际操作中结构化剪枝更常见。流程一般是先训练一个完整的模型然后根据某种重要性指标比如权重的 L1/L2 范数、BN 层的缩放因子、梯度信息等给每个通道打分把分数低的通道剪掉然后对剪枝后的模型做微调恢复精度。这个过程可以迭代多轮逐步压缩。2.3 知识蒸馏让小模型学会大模型的本事蒸馏的思路和前两者不太一样。它不是直接压缩原模型而是训练一个小的“学生模型”去模仿大的“教师模型”的行为。学生模型不仅学习真实的标签还学习教师模型输出的软标签soft label也就是每个类别的概率分布。为什么软标签有用举个例子一张猫的图片真实标签是“猫”。但教师模型可能会输出猫 0.85狗 0.10狐狸 0.05。这个分布告诉学生模型“这张图虽然主要是猫但和狗、狐狸也有点像”。这种信息比单纯的 one-hot 标签丰富得多能帮助学生模型学到更好的决策边界。蒸馏的关键在于设计损失函数。通常包括两部分一部分是学生模型输出和真实标签的交叉熵损失另一部分是学生模型和教师模型输出之间的 KL 散度。两者的权重需要调温度参数也需要调。温度越高软标签的分布越平滑学生能学到的“暗知识”越多但太高了也会引入噪声。2.4 算子融合与图优化不改变数值只改变计算方式前面三种方法都在改变模型的数值内容而算子融合和图优化改变的是计算图的组织方式。比如卷积层后面跟一个 BN 层再跟一个 ReLU推理的时候其实可以把 BN 的参数吸收到卷积的权重里变成一个卷积加一个 ReLU减少一次内存读写和一次计算。这就是最经典的 Conv-BN 融合。图优化还包括常量折叠、死代码消除、内存复用等等。这些优化不损失任何精度属于“白捡”的加速。大部分推理引擎TensorRT、ONNX Runtime、TVM 等都会自动做这些优化但如果你自己导出模型的时候格式不对引擎可能识别不出来白白浪费了优化机会。3. 工具选型不同场景该用什么3.1 训练框架原生工具如果你用的是 PyTorch那最顺手的就是torch.quantization和torch.fx。PyTorch 从 1.3 开始就内置了量化支持Eager 模式和 FX Graph 模式都有。FX Graph 模式更适合复杂的模型因为它能对计算图做更彻底的分析和改写。TensorFlow 这边有 TensorFlow Model Optimization Toolkit支持量化和剪枝和 TFLite 配合得很好。如果你最终部署目标是移动端这条路比较顺。原生工具的好处是和训练框架无缝集成不需要额外的格式转换。缺点是优化能力相对有限尤其是图优化层面不如专门的推理引擎做得深。3.2 专用推理引擎TensorRT 是 NVIDIA 家的推理引擎对自家 GPU 的优化做到了极致。它支持 FP16、INT8 量化有强大的图优化和 kernel 自动调优能力。缺点是只支持 NVIDIA 硬件而且模型转换过程中如果遇到不支持的算子需要自己写 plugin。ONNX Runtime 是微软主导的跨平台推理引擎支持 CPU、GPU 和各种边缘设备。它的量化工具链比较成熟支持 PTQ 和 QAT而且和 ONNX 格式天然兼容。如果你需要跨平台部署ONNX Runtime 是比较稳妥的选择。OpenVINO 是 Intel 家的针对自家 CPU、集成显卡和 VPU 做了深度优化。如果你部署在 Intel 平台上OpenVINO 的量化工具POTPost-training Optimization Tool非常好用支持多种量化算法。3.3 自动化优化平台最近两年出现了一些自动化模型优化平台比如 Neural CompressorIntel 开源、NNCFOpenVINO 的神经网络压缩框架等。它们的思路是你只需要提供模型和校准数据平台自动搜索最优的量化策略、剪枝比例、蒸馏方案甚至能做多目标优化同时考虑精度、延迟、模型大小。这类工具适合不想深入底层细节、只想快速拿到优化结果的团队。但缺点是灵活性差一些遇到特殊模型结构可能不支持。4. 实操流程从原始模型到优化部署4.1 第一步建立基线别急着优化很多人一上来就开始量化、剪枝结果优化完了发现精度掉了也不知道是哪个环节出的问题。正确的做法是先建立一个完整的基线原始模型在目标硬件上的精度、延迟、内存占用、模型大小全部记录下来。延迟测试要注意不能只测一次要跑足够多的次数至少100次取平均值和P99。第一次推理通常包含初始化和预热开销要排除掉。Batch size 也要明确batch1 和 batch32 的优化策略可能完全不同。精度测试要用完整的验证集不能只跑几张图看看效果。有些量化误差是累积的单张图看不出来跑完整个数据集才会暴露。4.2 第二步选择合适的优化组合不是所有模型都需要全套优化。根据你的实际瓶颈来选瓶颈类型首选方案次选方案注意事项模型太大存不下INT8 量化剪枝量化量化后精度损失需验证推理太慢延迟高算子融合FP16INT8 量化FP16 通常无损优先尝试内存带宽不够INT8 量化结构化剪枝量化对带宽敏感场景效果显著算力有限边缘设备蒸馏量化剪枝量化蒸馏需要重新训练周期长精度不达标QAT混合精度量化QAT 需要完整训练流程我一般建议的顺序是先做算子融合和图优化无损然后试 FP16几乎无损再试 PTQ INT8可能有损最后才考虑剪枝和蒸馏需要微调或重训。4.3 第三步量化实操细节以 PyTorch 的 PTQ 为例完整流程大致如下import torch import torch.quantization as tq # 1. 加载原始模型 model MyModel() model.load_state_dict(torch.load(model.pth)) model.eval() # 2. 指定量化配置 model.qconfig tq.get_default_qconfig(fbgemm) # x86 CPU # model.qconfig tq.get_default_qconfig(qnnpack) # ARM # 3. 插入观察器 model_prepared tq.prepare(model, inplaceFalse) # 4. 用校准数据跑一遍 with torch.no_grad(): for data in calib_loader: model_prepared(data) # 5. 转换为量化模型 model_quantized tq.convert(model_prepared, inplaceFalse) # 6. 保存 torch.save(model_quantized.state_dict(), model_quantized.pth)这段代码看起来简单但里面有几个关键点qconfig 的选择fbgemm适合 x86 CPUqnnpack适合 ARM。选错了不会报错但性能会很差。校准数据的数量和分布一般用 100-500 张图就够了但必须和实际推理数据的分布一致。如果你用猫狗图片校准然后去推理医学影像量化参数肯定不对。哪些层被量化了不是所有层都适合量化。比如第一层卷积和最后一层全连接通常对精度影响较大可以考虑跳过。PyTorch 允许你通过qconfig单独设置某些层的量化策略。4.4 第四步验证与回归测试优化完的模型必须做完整的回归测试。除了精度指标Top-1、Top-5、mAP 等还要测逐层输出对比用同一批输入对比原始模型和优化模型每一层的输出差异。如果某一层差异突然变大说明那层的量化参数有问题。边界 case 测试全黑图、全白图、极端光照、小目标、遮挡目标这些容易暴露量化误差的场景都要覆盖。长时间稳定性测试有些量化误差在单次推理中不明显但连续跑几个小时可能会累积。尤其是涉及状态更新的模型如 RNN、视频跟踪一定要做长稳测试。5. 踩坑实录与排查技巧5.1 量化后精度暴跌怎么定位问题这是最常见的问题。我的排查顺序是确认校准数据是否正确检查数据预处理是否和训练时一致。归一化参数、通道顺序、尺寸缩放任何一个不一致都会导致量化参数偏差。逐层对比输出用 PyTorch 的 hook 机制把原始模型和量化模型每一层的输出都存下来计算余弦相似度或 MSE。找到差异最大的那层重点分析。检查是否有不支持量化的算子有些自定义算子或者特殊结构如动态 shape 的注意力可能没有被正确量化导致前后层量化参数不匹配。尝试混合精度把敏感层保持 FP32其他层用 INT8。PyTorch 支持通过qconfig_dict精细控制。5.2 剪枝后模型反而变慢了结构化剪枝理论上应该加速但实际中经常遇到剪枝后速度没变甚至变慢的情况。原因通常有两个剪枝后的通道数不是硬件友好的倍数比如 GPU 的 Tensor Core 对 8 的倍数通道数优化最好你剪成 33 个通道反而比 64 个通道还慢。所以剪枝时通常会把通道数对齐到 8 或 16 的倍数。推理引擎没有真正利用稀疏性如果你做的是非结构化剪枝但推理引擎不支持稀疏计算那剪了等于白剪甚至因为要处理稀疏格式而更慢。5.3 蒸馏训练不收敛蒸馏的损失函数是真实标签损失和蒸馏损失的加权和。如果权重没调好学生模型可能完全学不到教师的知识。我的经验是初始阶段蒸馏损失权重大一些比如 0.7-0.9让学生先模仿教师。后期逐渐降低蒸馏损失权重增加真实标签损失权重让学生回归真实任务。温度参数从高到低退火先学全局分布再学细节。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉超过3%校准数据分布不对对比校准集和验证集分布重新采样校准数据量化后推理速度没提升算子未真正量化打印量化模型结构检查 qconfig 和算子支持剪枝后模型无法加载剪枝后结构不匹配对比剪枝前后 state_dict重新导出完整模型蒸馏学生模型不收敛损失权重或温度不当监控两个损失的变化调整权重和温度退火策略ONNX 导出失败不支持的算子查看导出报错信息替换算子或自定义导出TensorRT 转换失败动态 shape 或自定义层查看转换日志固定 shape 或写 plugin6. 一些不太文档化的经验6.1 量化不是越激进越好INT8 是主流但 INT4 甚至二值化网络在某些场景也能用。不过我要说的是量化位宽每降一半精度风险是指数级上升的。INT8 到 INT4精度可能掉 5-10 个点而且不是所有硬件都支持 INT4 加速。除非你的场景对模型大小极度敏感比如单片机部署否则 INT8 是性价比最高的选择。6.2 优化是一个迭代过程不是一锤子买卖我见过很多团队花两周做了一轮量化精度掉了两个点就放弃了。其实模型优化很少能一次到位。通常需要量化→验证→调整→再量化反复几轮才能找到最优配置。每一轮可能只需要改一两个参数但效果差异很大。6.3 别忘了推理引擎本身的优化模型优化只是整个推理链路的一环。推理引擎的配置线程数、内存池大小、batch 策略对最终性能影响也很大。有时候模型优化了半天提升了 20%结果推理引擎配置调一下又提升了 30%。所以优化模型的同时也要花时间调推理引擎的参数。6.4 保留完整的优化日志每次优化实验都要记录用了什么方法、什么参数、精度变化、速度变化、模型大小变化。这些日志在后期排查问题和向团队汇报时非常有用。我一般用 CSV 或者简单的表格记录字段包括实验编号、优化方法、关键参数、精度、延迟、模型大小、备注。6.5 硬件和软件版本要锁死模型优化对硬件和软件版本非常敏感。同样的量化脚本在 PyTorch 1.10 和 1.13 上跑出来的结果可能不一样。TensorRT 8.2 和 8.5 的优化策略也有差异。所以一旦找到一组能工作的配置就把所有版本号记下来不要轻易升级。7. 一个完整的优化案例拆解假设我们有一个 ResNet-50 的图像分类模型部署在 NVIDIA T4 GPU 上要求延迟低于 10ms精度下降不超过 1%。基线测试FP32 模型batch1延迟 15msTop-1 精度 76.5%。第一轮优化FP16。TensorRT 直接支持 FP16不需要校准数据。转换后延迟降到 8ms精度 76.5%无损。已经满足延迟要求了。第二轮优化INT8 PTQ。用 500 张训练集图片做校准TensorRT 的 INT8 量化。延迟降到 5ms精度 75.8%掉了 0.7 个点。在可接受范围内。第三轮优化混合精度。发现第一层和最后一层对精度影响大保持 FP16中间层用 INT8。延迟 5.5ms精度 76.3%。精度恢复了不少延迟只增加了 0.5ms。最终方案混合精度量化延迟 5.5ms精度 76.3%满足所有要求。这个案例里我们没有用剪枝和蒸馏因为量化和 FP16 已经足够了。实际项目中应该优先尝试简单、无损的方法只有在不够用的时候才上复杂方案。8. 模型优化器的未来方向从最近的一些研究和工业实践来看模型优化正在往几个方向走自动化用强化学习或贝叶斯优化自动搜索最优的量化策略、剪枝比例、蒸馏配置减少人工调参。硬件协同针对特定硬件如 NPU、DSP设计专用的优化方案而不是通用的量化剪枝。大模型优化随着 LLM 的普及如何在保持生成质量的前提下压缩大模型成了新的热点。目前主流方案是量化GPTQ、AWQ 蒸馏 稀疏化。训练时优化不只是推理优化训练过程中的显存优化、通信优化、混合精度训练也是 Model-Optimizer 的一部分。我在实际项目中的体会是模型优化没有银弹也没有一套放之四海而皆准的方案。每个模型、每个硬件、每个业务场景都需要单独调优。但只要你理解了量化、剪枝、蒸馏、图优化这几个核心工具的原理和适用场景再结合系统的实验方法就能找到适合自己项目的优化路径。最重要的是别怕试错每一次失败的实验都会让你对模型的理解更深一层。
