尧图网页设计 
1. 项目概述为什么我写了这个 Model-Optimizer我最初想搞 Model-Optimizer 这个项目纯粹是被部署流程逼出来的。训练好的模型在 GPU 上跑得丝滑一到 CPU 或边缘设备上就卡成幻灯片显存动不动吃掉几个 GB推理延迟高得没法看。很多团队卡在这一步模型指标再漂亮上不了线就是废纸。Model-Optimizer 的定位很直接——把已经训练好的模型在不明显损失精度的情况下压缩体积、提升推理速度让模型真正落地到生产环境。这个项目适合谁如果你正在做模型上线、边缘设备部署或者只是想让自己训练的模型跑得更快更省资源那这里面的思路和工具链基本可以直接抄作业。项目覆盖模型优化的几个核心技术点量化、剪枝、蒸馏、算子融合以及它们在生产环境里的组合策略。我会按真实做项目的顺序来写把每一步怎么选、怎么做、为什么这么做讲透顺便把踩过的坑也交代清楚。2. 核心技术与方案选型解析2.1 量化把高精度参数压成低精度量化是 Model-Optimizer 里收益最直观的一步。原理很简单训练时模型参数通常用 FP32 存储对应 32 位浮点数能表示极大范围的数值。但网络对参数的精度要求远没有这么苛刻很多任务用 INT8256 个取值甚至 INT4 就能跑得不错。打个比方记账时每一笔金额本来精确到小数点后十位大多数场景保留到整数甚至一位小数就够用账本体积直接降下来。具体到实现量化有两个关键概念scale 和 zero-point。把 FP32 的实数范围映射到 INT8 的整数范围需要一个缩放因子 scale 和一个零点偏移 zero-point公式是q round(r / scale) zero_point反量化则是r (q - zero_point) * scale。映射范围选得好不好直接决定精度损失。Model-Optimizer 里实现了两种量化路线训练后量化PTQPost-Training Quantization模型训练完直接用一小批校准数据统计权重和激活值的分布算出 scale 和 zero-point。实现快不需要重新训练但精度损失不完全可控。量化感知训练QATQuantization-Aware Training在训练过程中模拟量化误差让网络主动适应低精度表示。效果好但要重新训练工程成本高。我的选择逻辑是先跑 PTQ如果精度掉点在可接受范围内比如 top-1 掉点不超过 1%直接采用掉点严重再上 QAT。绝大多数图像分类模型在 PTQ 下都能保住 99% 以上的精度真正需要 QAT 的场景如目标检测、关键点回归占比其实不高。另外还要区分动态量化和静态量化动态量化只量化权重激活在推理时实时计算范围部署简单但加速有限静态量化用校准集提前统计好激活范围推理时省去统计开销性能更好Model-Optimizer 默认走静态量化。2.2 剪枝把不重要的连接干掉量化是改变数值精度剪枝则是直接改结构。训练完成的模型并不是每个参数都重要。某些卷积核的权重接近零对输出的贡献微乎其微剪枝就是找出这类低贡献的结构并删掉。剪枝分结构化剪枝和非结构化剪枝。非结构化剪枝删单个权重模型变稀疏但稀疏矩阵在普通硬件上不会自动加速必须有配套的稀疏计算库。结构化剪枝直接删整个通道或整个卷积核维度是完整的用常规推理引擎就能拿到加速收益。Model-Optimizer 默认走结构化剪枝原因很简单工程上更容易落地。具体实现思路借鉴了经典做法用 BN 层的缩放因子 γ 作为通道重要性的评判依据。训练时给 γ 加一个 L1 正则让它尽量稀疏化之后按阈值把 γ 较小的通道整体剪掉。这个方案的妙处在于不需要额外计算通道敏感性训练过程自己就把重要性排序做出来了。但剪枝比例不能贪。我实测下来ResNet 系列模型剪掉约 30% 的通道微调后能恢复原精度剪到 50% 就得看具体任务了。检测类模型普遍比分类模型更敏感因为空间定位信息分散在更多通道里。剪枝比例最好分档测试不要一上来就定 60%。2.3 蒸馏让大模型教会小模型蒸馏的思路是找一个强大的教师模型指导一个小规模学生模型学习。教师模型输出不能只看最终类别还要看它对各类别的软概率分布这个分布里藏着类别之间的相似关系也就是说教师不仅告诉学生这是什么还告诉学生它像什么、不像什么。学生模型在参数量小很多的前提下能逼近教师的能力。蒸馏超参数里温度 T 最关键。学生模型和教师模型分别把 logits 除以 T再做 softmax得到温度缩放后的软概率计算它们之间的 KL 散度。T 越大软分布越平滑类别间的相似关系越容易被学生学到T 太小就退化成普通硬标签训练。通常 T 取 3 到 8 之间需要调。一个实测数据在 CIFAR-100 上用 ResNet-50 蒸馏 ResNet-18学生模型能比直接训练的 ResNet-18 高出 2 到 3 个点的准确率。推理成本没有变化准确率凭空提高这笔买卖非常划算。蒸馏对模型体积没有直接影响但它是压缩模型时弥补精度的重要手段尤其当剪枝或量化吃掉精度之后。2.4 算子融合减少读写开销最后一项是算子融合。CPU 和 GPU 执行算子时中间结果通常要写回内存或显存下一个算子再读出来这个写读过程非常慢。算子融合就是把多个算子合并成一个计算内核让中间结果尽量留在寄存器或缓存里大幅减少 IO 开销。最常见的融合是 Conv BN ReLU 融合。推理时 BN 的均值和方差可以折算进卷积的权重和偏置里ReLU 可以紧跟卷积一起执行三段式计算变成一段式。Model-Optimizer 里这一块直接复用 ONNX Runtime 的 graph optimization 能力只做配置封装没有自己造轮子。自己写算子融合意义不大成熟引擎在这些编译优化上做得更好。这里有个反直觉的观察小模型上算子融合的边际收益很低因为单个算子本身就很小省下的 IO 不显著。但配上量化加剪枝之后融合的收益会放大——模型主体被压缩后IO 开销占比反而上升融合的价值就凸显出来了。3. 模块设计与实现细节3.1 整体架构设计的思路Model-Optimizer 采用流水线式的处理架构。模型优化不是单个孤立操作而是多个环节叠加。整个流程拆成五个模块每个模块职责单一用配置文件和中间产物串联Loader读入模型统一转成 ONNX 格式。ONNX 是跨框架的中间表示PyTorch、TensorFlow 训练出来的模型都能转进来。Analyzer分析模型结构、参数分布、每层算子耗时占比产出优化前的性能基线。Quantizer执行 PTQ 或 QAT 量化。Pruner执行结构化剪枝返回剪枝后的紧凑模型结构。Exporter把优化后的模型导出成 ONNX 及对应推理引擎的格式同时生成一份精度对比报告。这样拆的好处是每个环节都能单独复用。线上模型延迟高但显存够只跑 Pruner 就行显存爆了但延迟可以忍只跑 Quantizer。没必要每次都全流程走一遍。模块之间通过中间文件衔接意味着每一步都可以停下来检查、回滚、换参数重跑这对调试非常重要。3.2 量化校准的正确姿势PTQ 的核心在于校准数据集的质量。校准集的任务是统计激活值的分布范围统计偏了量化效果就废了。我最早的错误是直接用训练集随机抽一批做校准结果激活分布统计得过于理想上线后精度肉眼可见地往下掉。正确做法从验证集中抽 500 到 1000 张图片覆盖各个类别前向跑一遍并记录各层激活值的分布。校准数据的分布要贴近真实部署场景。训练数据是高清单反图、线上模型吃的是手机随手拍的低质量图那校准结果也是失真的。在做部署前最好先收集一批线上真实样本哪怕只有几百张也比训练集校准可靠得多。量化格式也要注意 per-tensor 和 per-channel 的区别。per-tensor 是整层共用一个 scale 和 zero-point实现简单但对异常值敏感per-channel 是每个输出通道独立计算 scale精度更好代价是推理引擎得支持这种格式。ONNX Runtime 目前对 per-channel 的支持已经很成熟我的项目里全部采用 per-channel。3.3 剪枝后的精度恢复流程结构化剪枝后精度必然下降需要一套恢复流程用原模型权重初始化剪枝后的模型把保留下来的通道权重原样拷贝。用小学习率在训练集上微调一般几十个 epoch 足够不需要从头训练。微调时先把学习率固定在一个很小的值上稳住 10 个 epoch再按 cosine 衰减走完剩余周期。我整理了剪枝恢复的速查表实际项目基本照着跑就行阶段学习率Epoch 数备注预热原模型 lr 的 0.01 倍5防止 loss 冲高微调原模型 lr 的 0.1 倍20 到 40核心恢复阶段收尾cosine 衰减10把精度顶回去剪枝比例不要靠拍脑袋定。我建议分别跑 20%、40%、60% 三档记录每档的掉点情况选掉点还在容忍范围内、体积收益最大的那档。Model-Optimizer 里这块做成了自动化脚本输入模型和几个候选比例自动输出对比报告。3.4 蒸馏的温度与软标签处理蒸馏实现里有两个容易忽略的细节。第一软标签不是直接取教师模型的输出概率而是经过温度缩放后的概率。训练时损失由两部分组成学生软输出和教师软输出之间的 KL 散度加上学生输出和真实硬标签之间的交叉熵。两部分按权重配平我习惯用 0.9 的 soft loss 搭配 0.1 的 hard loss。KL 散度数值天然偏大权重不配平的话 hard loss 直接被淹没学生学不到真实标签的信息。第二蒸馏时教师模型必须设成 eval 模式并且关闭梯度计算。我踩过一回坑忘了关教师模型的梯度显存直接翻倍反向传播还波及了教师模型权重。虽然最后结果没受影响但浪费了一整晚调试时间。正确写法是先把torch.no_grad()包住教师模型的前向计算或者把requires_grad全部置为 False。第三种容易出问题的场景是温度选择。温度太低软分布和硬标签几乎没区别蒸馏白做温度太高软分布过于平滑学生连类别之间的区分度都学不到。调试时可以先固定 T4 试跑 20 个 epoch看 loss 曲线和学生模型在验证集的表现再微调。4. 完整实操流程一步一步跑通4.1 环境准备与依赖安装Model-Optimizer 的核心依赖是 PyTorch、ONNX、ONNX Runtime再加一个稀疏化训练的辅助库。给一份经过验证的环境配置conda create -n model-optim python3.9 conda activate model-optim pip install torch1.13.1 pip install onnx1.13.1 onnxruntime-gpu1.14.0 pip install numpy1.23.5版本兼容性是个大坑。我最早用 PyTorch 2.0 导出 ONNXONNX Runtime 1.13 解析时频繁报奇怪的算子错误后来统一升级到 ONNX Runtime 1.14 才消停。建议尽量用较新的 runtime 版本并且每次换 PyTorch 版本后重新执行一遍完整导出和验证流程。4.2 从 PyTorch 模型导出 ONNX第一道工序是格式转换。Model-Optimizer 里封装了导出工具核心代码不长import torch import onnx def export_onnx(model, dummy_input, save_path): model.eval() torch.onnx.export( model, dummy_input, save_path, export_paramsTrue, opset_version13, do_constant_foldingTrue, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}, output: {0: batch_size}} ) onnx_model onnx.load(save_path) onnx.checker.check_model(onnx_model) print(export done)dummy_input 的尺寸必须和模型真实输入 shape 一致。dynamic_axes 让 batch 维度保持动态上线做批量推理时很实用建议加上。两个高频坑。第一模型里有 Dropout 或 BatchNorm 时导出前必须调用model.eval()否则计算图结构和推理时不一致导出后的模型行为异常。第二模型里用了自定义算子时ONNX 导出会报找不到对应算子要么改模型结构避开要么用torch.onnx.register_custom_op_symbolic手动映射算子。4.3 跑一遍量化并核对精度导出 ONNX 后进入 Quantizer 模块。我用配置驱动方式调用python run_quantize.py --config configs/quant_cfg.yamlquant_cfg.yaml 的关键字段model_path: outputs/model_qat.onnx calib_data: data/calib_imgs calib_num: 500 quant_format: per_channel quant_engine: onnxruntime eval_data: data/val_imgs执行完会生成量化报告内容包括每层量化前后的输出差异、整体精度掉点、模型体积变化。这里有个重要经验不要只看总精度指标要看每层的误差分布。有时候整体精度没掉但某个中间层的输出已经漂得很厉害这种模型上线后对输入分布变化的鲁棒性会变差。我现在有个检查习惯量化后如果某个 block 的激活平均绝对误差超过 3%会对这一层单独跳过量化。ONNX Runtime 支持在量化配置里指定排除某些层这个能力要善用。4.4 剪枝并做精度恢复剪枝放在量化之后做因为先剪枝再量化校准集统计到的激活分布已经是剪枝压缩后的更贴近最终上线模型。剪枝脚本python run_prune.py --config configs/prune_cfg.yamlprune_cfg.yaml 里需要重点关注的参数ratio通道剪枝比例建议从 0.3 到 0.5 起步restore_epochs恢复微调的 epoch 数restore_lr恢复微调学习率剪枝后我用一个比对脚本把原模型和剪枝后模型在同一个验证集上逐条跑比较每条样本的预测置信度差异。如果某些类别的置信度出现异常波动说明这些类别依赖的通道可能被误剪了。这时要降低剪枝阈值或者对特定层放行不剪。一个真实案例处理一个 ReXNet 变体模型60% 比例剪枝后 top-1 掉 4.7%恢复微调 30 个 epoch 后回到只掉 0.8%。模型体积从 14.2MB 压到 4.1MBCPU 推理延迟从 68ms 降到 24ms效果非常理想。4.5 导出并对比收益走到 Exporter 模块工具会输出三个内容优化后的 ONNX 文件、精度对比报告、性能对比表格。性能对比用 ONNX Runtime 自带的 profiling或者用 C 写的推理计时工具。测速要在同一台机器的稳定状态下进行多跑几轮取中位数避免 CPU 频率波动干扰短时任务测速。当时拿到的最终收益数据大致是这样指标优化前优化后收益模型体积14.2 MB4.1 MB减少 71%单帧延迟CPU68 ms24 ms减少 65%显存占用1.8 GB0.9 GB减少 50%Top-1 精度82.4%81.6%掉 0.8%这个精度掉点在业务上完全可以接受换来的收益很实在同一台机器能多跑 2 倍并发推理整体推理成本直接砍半。5. 常见问题与排查技巧实录5.1 量化后模型输出全是 NaN这是量化时最吓人的异常。我遇到过一次排查了三个多小时。现象是模型导出没问题ONNX Runtime 加载量化模型后前几层输出正常到某一层之后全部变成 NaN。排查思路先区分是运行时问题还是模型自身问题。用 ONNX Runtime 跑原始 FP32 模型如果也有 NaN那是模型本身有问题跟量化无关。检查校准数据是否含异常样本。校准集混入带 NaN 像素值的坏图统计出的激活范围也会变成 NaN进而污染 scale 计算。检查某些层的权重是否本身存在极端离群值。个别通道权重最大值比均值大几百倍量化后这些通道会变成离群点导致量化表失准。解决办法很朴素清洗校准数据对权重分布极端异常的层跳过量化。Model-Optimizer 里我加了一层防御逻辑自动检测权重分布中的极端离群点命中就直接跳过该层量化。5.2 剪枝后模型体积没变小结构化剪枝后参数数量确实减少了但导出的 ONNX 文件体积没什么变化。这个问题的根源在于如果只是把通道权重置零而没有真正删除通道文件里存储的数据量一分没少。正确检查方式是看模型的结构定义。剪枝后打印模型的每层输出通道数如果还是原来的数字说明只做了置零操作。修复方法剪枝完成后重新构建一遍模型结构只保留保留下来的通道这一步在工具里对应 compact_model 函数。执行完后ONNX 里对应的权重维度才会真正变小。5.3 蒸馏训练不收敛蒸馏训练出现 loss 振荡不下多数是温度或两个损失的配比出了问题。排查时先把 KL 散度部分单独算出来看一眼量级如果它比交叉熵大十倍以上就要调低 soft loss 的权重否则硬标签信息完全被淹没。另一个容易忽略的坑是维度对齐。教师模型和学生模型输出维度不一致得先给学生补一个对应维度的输出头。如果学生模型参数量太小硬塞给它一个难度过大的任务蒸馏会一直不上不下。这时候与其调参不如直接换大一点的学生模型容量不足是调不回来的。5.4 推理引擎加速不明显模型优化完在 ONNX Runtime 里速度提升却不明显。先别怀疑优化无效优先检查推理引擎配置。这里有个我犯过的低级错误没开图形优化算子融合根本没生效。正确配置如下import onnxruntime as ort sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess ort.InferenceSession(optimized.onnx, sess_options, providers[CPUExecutionProvider])graph_optimization_level 默认是 ORT_ENABLE_BASIC只做基础优化。改成 ORT_ENABLE_ALL 之后算子融合、常量折叠等优化才会真正生效。GPU 推理时还要确保 providers 列表把 CUDAExecutionProvider 放在最前面否则推理库会默默选择 CPU 执行优化效果当然体现不出来。5.5 ONNX 导出报算子不支持这个坑在做新模型时几乎必踩。模型里使用了比较新或者比较小众的算子比如某些注意力机制的变形实现ONNX 导出时直接报不支持。处理路径有三条第一修改模型实现用标准算子组合替代自定义算子这是最治本的方式第二用torch.onnx.register_custom_op_symbolic为自定义算子注册导出规则第三导出时降低 opset 版本有些算子在高版本 opset 才有对应表示但也有模型结构在高版本里反而更好表达。实际操作中我会先试 opset 12 和 13 两个版本都不行再走注册路线。6. 我的实操心得与扩展方向模型优化这件事我做了大半年最大的体会是这不是单点技术问题而是一个系统性工程。量化、剪枝、蒸馏、算子融合每一项单独拿出来都有成熟方案难点在于把它们组合起来并且在真实业务约束下做取舍。举个具体例子同一个模型部署目标是低功耗边缘盒子时我优先做量化加剪枝把体积和计算量压到极致部署目标是高并发 GPU 服务时我优先做量化加算子融合因为 GPU 上结构化剪枝的收益不明显而算子融合能明显提升吞吐。Model-Optimizer 的价值就在这里把每种组合的收益和代价量化出来再辅助做决策。还有一个经验想分享优化过程一定要自动化回归。精度对比、体积对比、延迟对比全部脚本化每次改动后自动跑一遍并输出报告。我最初手动对比时改一个参数就要手动跑一轮评估不仅慢还容易漏掉某些指标的变化。自动化之后整个优化流程才真正可控。最后分享一个小技巧。做量化校准时可以把网络中间层的输出也保存一批作为中间表示指纹。后续如果怀疑某个优化步骤破坏了模型能力直接对比中间层输出就能快速定位问题出现在哪一层。这个习惯帮我省下了大量调试时间。Model-Optimizer 后续计划扩展的方向是自动压缩策略搜索。目前版本还是靠人工指定方案比如剪枝比例、量化位宽。下一步打算用贝叶斯搜索自动挑选最优组合。同时INT4 量化和混合精度量化也在我实验清单里等有稳定结果再单独写一篇展开讲。 模型优化实战：量化、剪枝、蒸馏与算子融合加速部署
1. 项目概述为什么我写了这个 Model-Optimizer我最初想搞 Model-Optimizer 这个项目纯粹是被部署流程逼出来的。训练好的模型在 GPU 上跑得丝滑一到 CPU 或边缘设备上就卡成幻灯片显存动不动吃掉几个 GB推理延迟高得没法看。很多团队卡在这一步模型指标再漂亮上不了线就是废纸。Model-Optimizer 的定位很直接——把已经训练好的模型在不明显损失精度的情况下压缩体积、提升推理速度让模型真正落地到生产环境。这个项目适合谁如果你正在做模型上线、边缘设备部署或者只是想让自己训练的模型跑得更快更省资源那这里面的思路和工具链基本可以直接抄作业。项目覆盖模型优化的几个核心技术点量化、剪枝、蒸馏、算子融合以及它们在生产环境里的组合策略。我会按真实做项目的顺序来写把每一步怎么选、怎么做、为什么这么做讲透顺便把踩过的坑也交代清楚。2. 核心技术与方案选型解析2.1 量化把高精度参数压成低精度量化是 Model-Optimizer 里收益最直观的一步。原理很简单训练时模型参数通常用 FP32 存储对应 32 位浮点数能表示极大范围的数值。但网络对参数的精度要求远没有这么苛刻很多任务用 INT8256 个取值甚至 INT4 就能跑得不错。打个比方记账时每一笔金额本来精确到小数点后十位大多数场景保留到整数甚至一位小数就够用账本体积直接降下来。具体到实现量化有两个关键概念scale 和 zero-point。把 FP32 的实数范围映射到 INT8 的整数范围需要一个缩放因子 scale 和一个零点偏移 zero-point公式是q round(r / scale) zero_point反量化则是r (q - zero_point) * scale。映射范围选得好不好直接决定精度损失。Model-Optimizer 里实现了两种量化路线训练后量化PTQPost-Training Quantization模型训练完直接用一小批校准数据统计权重和激活值的分布算出 scale 和 zero-point。实现快不需要重新训练但精度损失不完全可控。量化感知训练QATQuantization-Aware Training在训练过程中模拟量化误差让网络主动适应低精度表示。效果好但要重新训练工程成本高。我的选择逻辑是先跑 PTQ如果精度掉点在可接受范围内比如 top-1 掉点不超过 1%直接采用掉点严重再上 QAT。绝大多数图像分类模型在 PTQ 下都能保住 99% 以上的精度真正需要 QAT 的场景如目标检测、关键点回归占比其实不高。另外还要区分动态量化和静态量化动态量化只量化权重激活在推理时实时计算范围部署简单但加速有限静态量化用校准集提前统计好激活范围推理时省去统计开销性能更好Model-Optimizer 默认走静态量化。2.2 剪枝把不重要的连接干掉量化是改变数值精度剪枝则是直接改结构。训练完成的模型并不是每个参数都重要。某些卷积核的权重接近零对输出的贡献微乎其微剪枝就是找出这类低贡献的结构并删掉。剪枝分结构化剪枝和非结构化剪枝。非结构化剪枝删单个权重模型变稀疏但稀疏矩阵在普通硬件上不会自动加速必须有配套的稀疏计算库。结构化剪枝直接删整个通道或整个卷积核维度是完整的用常规推理引擎就能拿到加速收益。Model-Optimizer 默认走结构化剪枝原因很简单工程上更容易落地。具体实现思路借鉴了经典做法用 BN 层的缩放因子 γ 作为通道重要性的评判依据。训练时给 γ 加一个 L1 正则让它尽量稀疏化之后按阈值把 γ 较小的通道整体剪掉。这个方案的妙处在于不需要额外计算通道敏感性训练过程自己就把重要性排序做出来了。但剪枝比例不能贪。我实测下来ResNet 系列模型剪掉约 30% 的通道微调后能恢复原精度剪到 50% 就得看具体任务了。检测类模型普遍比分类模型更敏感因为空间定位信息分散在更多通道里。剪枝比例最好分档测试不要一上来就定 60%。2.3 蒸馏让大模型教会小模型蒸馏的思路是找一个强大的教师模型指导一个小规模学生模型学习。教师模型输出不能只看最终类别还要看它对各类别的软概率分布这个分布里藏着类别之间的相似关系也就是说教师不仅告诉学生这是什么还告诉学生它像什么、不像什么。学生模型在参数量小很多的前提下能逼近教师的能力。蒸馏超参数里温度 T 最关键。学生模型和教师模型分别把 logits 除以 T再做 softmax得到温度缩放后的软概率计算它们之间的 KL 散度。T 越大软分布越平滑类别间的相似关系越容易被学生学到T 太小就退化成普通硬标签训练。通常 T 取 3 到 8 之间需要调。一个实测数据在 CIFAR-100 上用 ResNet-50 蒸馏 ResNet-18学生模型能比直接训练的 ResNet-18 高出 2 到 3 个点的准确率。推理成本没有变化准确率凭空提高这笔买卖非常划算。蒸馏对模型体积没有直接影响但它是压缩模型时弥补精度的重要手段尤其当剪枝或量化吃掉精度之后。2.4 算子融合减少读写开销最后一项是算子融合。CPU 和 GPU 执行算子时中间结果通常要写回内存或显存下一个算子再读出来这个写读过程非常慢。算子融合就是把多个算子合并成一个计算内核让中间结果尽量留在寄存器或缓存里大幅减少 IO 开销。最常见的融合是 Conv BN ReLU 融合。推理时 BN 的均值和方差可以折算进卷积的权重和偏置里ReLU 可以紧跟卷积一起执行三段式计算变成一段式。Model-Optimizer 里这一块直接复用 ONNX Runtime 的 graph optimization 能力只做配置封装没有自己造轮子。自己写算子融合意义不大成熟引擎在这些编译优化上做得更好。这里有个反直觉的观察小模型上算子融合的边际收益很低因为单个算子本身就很小省下的 IO 不显著。但配上量化加剪枝之后融合的收益会放大——模型主体被压缩后IO 开销占比反而上升融合的价值就凸显出来了。3. 模块设计与实现细节3.1 整体架构设计的思路Model-Optimizer 采用流水线式的处理架构。模型优化不是单个孤立操作而是多个环节叠加。整个流程拆成五个模块每个模块职责单一用配置文件和中间产物串联Loader读入模型统一转成 ONNX 格式。ONNX 是跨框架的中间表示PyTorch、TensorFlow 训练出来的模型都能转进来。Analyzer分析模型结构、参数分布、每层算子耗时占比产出优化前的性能基线。Quantizer执行 PTQ 或 QAT 量化。Pruner执行结构化剪枝返回剪枝后的紧凑模型结构。Exporter把优化后的模型导出成 ONNX 及对应推理引擎的格式同时生成一份精度对比报告。这样拆的好处是每个环节都能单独复用。线上模型延迟高但显存够只跑 Pruner 就行显存爆了但延迟可以忍只跑 Quantizer。没必要每次都全流程走一遍。模块之间通过中间文件衔接意味着每一步都可以停下来检查、回滚、换参数重跑这对调试非常重要。3.2 量化校准的正确姿势PTQ 的核心在于校准数据集的质量。校准集的任务是统计激活值的分布范围统计偏了量化效果就废了。我最早的错误是直接用训练集随机抽一批做校准结果激活分布统计得过于理想上线后精度肉眼可见地往下掉。正确做法从验证集中抽 500 到 1000 张图片覆盖各个类别前向跑一遍并记录各层激活值的分布。校准数据的分布要贴近真实部署场景。训练数据是高清单反图、线上模型吃的是手机随手拍的低质量图那校准结果也是失真的。在做部署前最好先收集一批线上真实样本哪怕只有几百张也比训练集校准可靠得多。量化格式也要注意 per-tensor 和 per-channel 的区别。per-tensor 是整层共用一个 scale 和 zero-point实现简单但对异常值敏感per-channel 是每个输出通道独立计算 scale精度更好代价是推理引擎得支持这种格式。ONNX Runtime 目前对 per-channel 的支持已经很成熟我的项目里全部采用 per-channel。3.3 剪枝后的精度恢复流程结构化剪枝后精度必然下降需要一套恢复流程用原模型权重初始化剪枝后的模型把保留下来的通道权重原样拷贝。用小学习率在训练集上微调一般几十个 epoch 足够不需要从头训练。微调时先把学习率固定在一个很小的值上稳住 10 个 epoch再按 cosine 衰减走完剩余周期。我整理了剪枝恢复的速查表实际项目基本照着跑就行阶段学习率Epoch 数备注预热原模型 lr 的 0.01 倍5防止 loss 冲高微调原模型 lr 的 0.1 倍20 到 40核心恢复阶段收尾cosine 衰减10把精度顶回去剪枝比例不要靠拍脑袋定。我建议分别跑 20%、40%、60% 三档记录每档的掉点情况选掉点还在容忍范围内、体积收益最大的那档。Model-Optimizer 里这块做成了自动化脚本输入模型和几个候选比例自动输出对比报告。3.4 蒸馏的温度与软标签处理蒸馏实现里有两个容易忽略的细节。第一软标签不是直接取教师模型的输出概率而是经过温度缩放后的概率。训练时损失由两部分组成学生软输出和教师软输出之间的 KL 散度加上学生输出和真实硬标签之间的交叉熵。两部分按权重配平我习惯用 0.9 的 soft loss 搭配 0.1 的 hard loss。KL 散度数值天然偏大权重不配平的话 hard loss 直接被淹没学生学不到真实标签的信息。第二蒸馏时教师模型必须设成 eval 模式并且关闭梯度计算。我踩过一回坑忘了关教师模型的梯度显存直接翻倍反向传播还波及了教师模型权重。虽然最后结果没受影响但浪费了一整晚调试时间。正确写法是先把torch.no_grad()包住教师模型的前向计算或者把requires_grad全部置为 False。第三种容易出问题的场景是温度选择。温度太低软分布和硬标签几乎没区别蒸馏白做温度太高软分布过于平滑学生连类别之间的区分度都学不到。调试时可以先固定 T4 试跑 20 个 epoch看 loss 曲线和学生模型在验证集的表现再微调。4. 完整实操流程一步一步跑通4.1 环境准备与依赖安装Model-Optimizer 的核心依赖是 PyTorch、ONNX、ONNX Runtime再加一个稀疏化训练的辅助库。给一份经过验证的环境配置conda create -n model-optim python3.9 conda activate model-optim pip install torch1.13.1 pip install onnx1.13.1 onnxruntime-gpu1.14.0 pip install numpy1.23.5版本兼容性是个大坑。我最早用 PyTorch 2.0 导出 ONNXONNX Runtime 1.13 解析时频繁报奇怪的算子错误后来统一升级到 ONNX Runtime 1.14 才消停。建议尽量用较新的 runtime 版本并且每次换 PyTorch 版本后重新执行一遍完整导出和验证流程。4.2 从 PyTorch 模型导出 ONNX第一道工序是格式转换。Model-Optimizer 里封装了导出工具核心代码不长import torch import onnx def export_onnx(model, dummy_input, save_path): model.eval() torch.onnx.export( model, dummy_input, save_path, export_paramsTrue, opset_version13, do_constant_foldingTrue, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}, output: {0: batch_size}} ) onnx_model onnx.load(save_path) onnx.checker.check_model(onnx_model) print(export done)dummy_input 的尺寸必须和模型真实输入 shape 一致。dynamic_axes 让 batch 维度保持动态上线做批量推理时很实用建议加上。两个高频坑。第一模型里有 Dropout 或 BatchNorm 时导出前必须调用model.eval()否则计算图结构和推理时不一致导出后的模型行为异常。第二模型里用了自定义算子时ONNX 导出会报找不到对应算子要么改模型结构避开要么用torch.onnx.register_custom_op_symbolic手动映射算子。4.3 跑一遍量化并核对精度导出 ONNX 后进入 Quantizer 模块。我用配置驱动方式调用python run_quantize.py --config configs/quant_cfg.yamlquant_cfg.yaml 的关键字段model_path: outputs/model_qat.onnx calib_data: data/calib_imgs calib_num: 500 quant_format: per_channel quant_engine: onnxruntime eval_data: data/val_imgs执行完会生成量化报告内容包括每层量化前后的输出差异、整体精度掉点、模型体积变化。这里有个重要经验不要只看总精度指标要看每层的误差分布。有时候整体精度没掉但某个中间层的输出已经漂得很厉害这种模型上线后对输入分布变化的鲁棒性会变差。我现在有个检查习惯量化后如果某个 block 的激活平均绝对误差超过 3%会对这一层单独跳过量化。ONNX Runtime 支持在量化配置里指定排除某些层这个能力要善用。4.4 剪枝并做精度恢复剪枝放在量化之后做因为先剪枝再量化校准集统计到的激活分布已经是剪枝压缩后的更贴近最终上线模型。剪枝脚本python run_prune.py --config configs/prune_cfg.yamlprune_cfg.yaml 里需要重点关注的参数ratio通道剪枝比例建议从 0.3 到 0.5 起步restore_epochs恢复微调的 epoch 数restore_lr恢复微调学习率剪枝后我用一个比对脚本把原模型和剪枝后模型在同一个验证集上逐条跑比较每条样本的预测置信度差异。如果某些类别的置信度出现异常波动说明这些类别依赖的通道可能被误剪了。这时要降低剪枝阈值或者对特定层放行不剪。一个真实案例处理一个 ReXNet 变体模型60% 比例剪枝后 top-1 掉 4.7%恢复微调 30 个 epoch 后回到只掉 0.8%。模型体积从 14.2MB 压到 4.1MBCPU 推理延迟从 68ms 降到 24ms效果非常理想。4.5 导出并对比收益走到 Exporter 模块工具会输出三个内容优化后的 ONNX 文件、精度对比报告、性能对比表格。性能对比用 ONNX Runtime 自带的 profiling或者用 C 写的推理计时工具。测速要在同一台机器的稳定状态下进行多跑几轮取中位数避免 CPU 频率波动干扰短时任务测速。当时拿到的最终收益数据大致是这样指标优化前优化后收益模型体积14.2 MB4.1 MB减少 71%单帧延迟CPU68 ms24 ms减少 65%显存占用1.8 GB0.9 GB减少 50%Top-1 精度82.4%81.6%掉 0.8%这个精度掉点在业务上完全可以接受换来的收益很实在同一台机器能多跑 2 倍并发推理整体推理成本直接砍半。5. 常见问题与排查技巧实录5.1 量化后模型输出全是 NaN这是量化时最吓人的异常。我遇到过一次排查了三个多小时。现象是模型导出没问题ONNX Runtime 加载量化模型后前几层输出正常到某一层之后全部变成 NaN。排查思路先区分是运行时问题还是模型自身问题。用 ONNX Runtime 跑原始 FP32 模型如果也有 NaN那是模型本身有问题跟量化无关。检查校准数据是否含异常样本。校准集混入带 NaN 像素值的坏图统计出的激活范围也会变成 NaN进而污染 scale 计算。检查某些层的权重是否本身存在极端离群值。个别通道权重最大值比均值大几百倍量化后这些通道会变成离群点导致量化表失准。解决办法很朴素清洗校准数据对权重分布极端异常的层跳过量化。Model-Optimizer 里我加了一层防御逻辑自动检测权重分布中的极端离群点命中就直接跳过该层量化。5.2 剪枝后模型体积没变小结构化剪枝后参数数量确实减少了但导出的 ONNX 文件体积没什么变化。这个问题的根源在于如果只是把通道权重置零而没有真正删除通道文件里存储的数据量一分没少。正确检查方式是看模型的结构定义。剪枝后打印模型的每层输出通道数如果还是原来的数字说明只做了置零操作。修复方法剪枝完成后重新构建一遍模型结构只保留保留下来的通道这一步在工具里对应 compact_model 函数。执行完后ONNX 里对应的权重维度才会真正变小。5.3 蒸馏训练不收敛蒸馏训练出现 loss 振荡不下多数是温度或两个损失的配比出了问题。排查时先把 KL 散度部分单独算出来看一眼量级如果它比交叉熵大十倍以上就要调低 soft loss 的权重否则硬标签信息完全被淹没。另一个容易忽略的坑是维度对齐。教师模型和学生模型输出维度不一致得先给学生补一个对应维度的输出头。如果学生模型参数量太小硬塞给它一个难度过大的任务蒸馏会一直不上不下。这时候与其调参不如直接换大一点的学生模型容量不足是调不回来的。5.4 推理引擎加速不明显模型优化完在 ONNX Runtime 里速度提升却不明显。先别怀疑优化无效优先检查推理引擎配置。这里有个我犯过的低级错误没开图形优化算子融合根本没生效。正确配置如下import onnxruntime as ort sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess ort.InferenceSession(optimized.onnx, sess_options, providers[CPUExecutionProvider])graph_optimization_level 默认是 ORT_ENABLE_BASIC只做基础优化。改成 ORT_ENABLE_ALL 之后算子融合、常量折叠等优化才会真正生效。GPU 推理时还要确保 providers 列表把 CUDAExecutionProvider 放在最前面否则推理库会默默选择 CPU 执行优化效果当然体现不出来。5.5 ONNX 导出报算子不支持这个坑在做新模型时几乎必踩。模型里使用了比较新或者比较小众的算子比如某些注意力机制的变形实现ONNX 导出时直接报不支持。处理路径有三条第一修改模型实现用标准算子组合替代自定义算子这是最治本的方式第二用torch.onnx.register_custom_op_symbolic为自定义算子注册导出规则第三导出时降低 opset 版本有些算子在高版本 opset 才有对应表示但也有模型结构在高版本里反而更好表达。实际操作中我会先试 opset 12 和 13 两个版本都不行再走注册路线。6. 我的实操心得与扩展方向模型优化这件事我做了大半年最大的体会是这不是单点技术问题而是一个系统性工程。量化、剪枝、蒸馏、算子融合每一项单独拿出来都有成熟方案难点在于把它们组合起来并且在真实业务约束下做取舍。举个具体例子同一个模型部署目标是低功耗边缘盒子时我优先做量化加剪枝把体积和计算量压到极致部署目标是高并发 GPU 服务时我优先做量化加算子融合因为 GPU 上结构化剪枝的收益不明显而算子融合能明显提升吞吐。Model-Optimizer 的价值就在这里把每种组合的收益和代价量化出来再辅助做决策。还有一个经验想分享优化过程一定要自动化回归。精度对比、体积对比、延迟对比全部脚本化每次改动后自动跑一遍并输出报告。我最初手动对比时改一个参数就要手动跑一轮评估不仅慢还容易漏掉某些指标的变化。自动化之后整个优化流程才真正可控。最后分享一个小技巧。做量化校准时可以把网络中间层的输出也保存一批作为中间表示指纹。后续如果怀疑某个优化步骤破坏了模型能力直接对比中间层输出就能快速定位问题出现在哪一层。这个习惯帮我省下了大量调试时间。Model-Optimizer 后续计划扩展的方向是自动压缩策略搜索。目前版本还是靠人工指定方案比如剪枝比例、量化位宽。下一步打算用贝叶斯搜索自动挑选最优组合。同时INT4 量化和混合精度量化也在我实验清单里等有稳定结果再单独写一篇展开讲。