训练跑得好好的模型到了上线阶段突然发现体积太大、推理太慢内存也扛不住——这个问题我猜做算法落地的人都遇到过。尤其是在边缘设备、移动端、嵌入式场景模型优化不是锦上添花而是能不能上线的硬门槛。我最近把散落各处的优化脚本整合成了一个统一工具链名字就叫 Model-Optimizer。这篇文章把我从框架选型、量化剪枝蒸馏的落地细节、到踩坑排查的完整过程记录下来希望能给正在做模型压缩和加速方向的朋友一些直接能用的参考。整个工具链的设计初衷很简单让模型从 PyTorch 训练产物变成能在端侧高效运行的推理产物过程中尽量少掉点精度少踩坑最好一次配置就能复用。文章里我会把整套方案的模块划分、核心参数怎么填、每一步为什么要这么做讲清楚适合有一定训练基础、但刚开始接触模型优化与部署的工程师阅读。1. 先把问题想清楚模型优化到底在优化什么1.1 训练好的模型不等于能部署的模型很多人一开始会把模型优化简单理解成换个推理框架比如把 PyTorch 模型转成 ONNX再转成 TensorRT 或者 NCNN。但真正做过一轮就会发现转换只是最后一步效果好不好取决于前面做了多少优化工作。一个典型的例子用 ResNet50 做图像分类FP32 权重大约 98MB在服务器 GPU 上跑推理没什么压力。但放到一台只有 2GB 内存的工控机或者手机端模型加载就要占掉几十上百 MB前处理加推理一帧要几百毫秒完全达不到实时要求。这时候要做的事情是把模型变小、把推理变快、把内存占用压下来同时尽量不损失精度——这三件事就是模型优化的核心目标。所以在设计 Model-Optimizer 的时候我给自己定了几条原则。第一所有优化操作必须可回滚、可对比不能优化完就完了得知道每个环节对精度和速度的影响。第二流程必须可配置化不同模型、不同硬件只是参数不同而不是重新写一套脚本。第三每一步都要有量化指标压缩率、加速比、精度损失算得明明白白。1.2 Model-Optimizer 的定位不是某个算法的实现而是一条流水线工具链的名字虽然叫 Model-Optimizer但它不是某一种优化算法而是一条模型后处理流水线。输入是一个训练好的模型权重文件目前主要支持 PyTorch 格式输出是经过量化、剪枝、蒸馏、图优化之后的端侧推理模型同时还输出一份优化报告。整个流水线分了四个阶段先做诊断分析看看模型的参数量、计算量、每层耗时分布找出哪里是胖子再做结构优化包括通道剪枝和层融合然后做精度补偿用蒸馏或者量化感知训练把损失的精度拉回来最后做异构导出针对不同的推理后端生成对应格式。之所以把优化和导出分开是因为优化本身和硬件无关但导出格式和硬件强相关。同一个优化好的模型在 ARM CPU 上可以导成 NCNN在 NVIDIA GPU 上可以导成 TensorRT在手机端可以导成 TFLite。分开之后优化逻辑只需要写一遍导出逻辑按后端扩展就行。2. 方案选型为什么我没有重复造轮子2.1 框架选择的纠结过程动手之前最大的纠结是用现成框架还是自己攒一套。当时调研了 Intel 的 Neural Compressor、NVIDIA 的 TensorRT、微软的 Olive还有华为的 MindSpore Lite 工具链。这些框架功能都很强但都有一个共性问题它们是各自生态的全家桶如果要同时支持多种后端、多种优化策略的自由组合配置成本和学习成本都很高。我最后的选择是底层算法尽量调用成熟库上层调度全部自己写。比如量化校准用的 PyTorch 自带量化接口和 ONNX Runtime 的量化工具剪枝逻辑基于 torch.nn.utils.prune 做二次开发蒸馏损失部分自己实现调度脚本和配置系统全部自己写。这样做的好处是每个环节都可以单独替换坏处是需要自己处理各库之间的接口差异但整体下来利大于弊。关于蒸馏还有个容易忽略的细节很多人以为蒸馏只是把大模型的 logits 拿过来硬训小模型但实际上教师模型和学生的预处理流程必须完全一致。如果教师网络用了不同的归一化参数或者输入尺寸学生的输入分布就对不上蒸馏效果会大打折扣。这一点我在工具链里专门做了输入流水线的统一校验避免这种隐性错误。2.2 模块划分与配置系统Model-Optimizer 的代码结构分成五个模块analyzer负责模型诊断和 FLOPs 分析pruner负责剪枝策略quantizer负责量化和校准distiller负责蒸馏训练exporter负责导出各类后端格式。所有模块通过一个 YAML 配置文件串联。配置文件是整个工具链的核心。我采用的方法是流水线式配置也就是把每一步优化定义成一个 stage每个 stage 有自己的参数。比如pipeline: - stage: analyze - stage: prune ratio: 0.3 method: channel_l1 skip_layers: [layer1, layer2] - stage: quantize method: ptq calib_samples: 512 per_channel: true - stage: export backend: onnx opset: 13这样做的好处是不同项目的差异全部收敛在配置文件里代码层面几乎不用改。我接过的项目里有图像分类、目标检测、语义分割几种模型换模型的时候只改配置和数据集加载代码就行优化逻辑完全复用。这个配置系统也是我踩坑踩出来的。最早的时候我把优化参数硬编码在脚本里每来一个新项目就拷一份脚本改一改后来脚本越来越多改一处忘了另一处出了不少问题。改成配置驱动之后每个项目的优化参数有据可查出了问题先看配置排错效率高了很多。3. 核心优化技术的落地细节3.1 量化最容易上手也最容易翻车量化是模型压缩里性价比最高的手段FP32 的权重从每参数 4 字节压缩到 INT8 的 1 字节模型体积直接缩小到原来的四分之一推理速度在某些硬件上还能再快 2 到 4 倍。但量化也是最容易翻车的环节尤其是对精度敏感的模型。我主要用的是后训练量化PTQ和量化感知训练QAT两条路线。PTQ 的流程是用一部分训练集或者验证集的数据做校准统计每层激活值的分布然后确定每个 tensor 的 scale 和 zero point。关键问题在于校准数据集的选择——如果用错了数据统计出来的分布是偏的量化后的精度就会暴跌。校准数据要够杂。我的做法是从多个类别的样本里均匀抽样覆盖不同光照、不同目标大小、不同背景的场景数量一般取 256 到 1024 张图。太少统计不准太多校准时间长而且收益会饱和。校准用的是验证集还是训练集我的经验是验证集就好因为验证集代表模型实际要面对的数据分布而且可以避免过拟合校准集。量化还有一个很容易忽略的坑per-channel 和 per-tensor 的差别。per-tensor 量化是整个 tensor 用一个 scale实现简单但精度损失大per-channel 是每个卷积核一个 scale精度高但某些硬件不支持。在 Model-Optimizer 里我默认启用 per-channel然后在导出阶段再根据后端能力做回退检查。关于量化后的推理速度我得提醒一句INT8 模型在 CPU 上有对应的硬件指令优化比如 ARM 平台的 DotProd 指令、x86 平台的 AVX512 VNNI只有在这些指令能被编译器识别的情况下才有加速效果。如果你把 INT8 模型跑在纯浮点模拟的环境里速度可能不升反降。所以量化前先确认目标硬件有没有 INT8 加速能力否则白忙一场。3.2 剪枝从非结构化到结构化量化压的是数值位宽剪枝压的是参数数量。剪枝的思路很直观把不重要的权重置成零或者把不重要的卷积核删掉。但这里有个层级问题非结构化剪枝是把单个权重置零造成了稀疏矩阵虽然从理论上说参数量少了但常规硬件上稀疏矩阵的存储和计算效率并不高除非底层专门做了稀疏加速。所以我在工具链里默认做结构化剪枝也就是剪掉整个卷积核或者整个通道。判断哪些通道不重要的常见方法是用 L1 范数——权重绝对值之和越小的通道对输出的贡献通常越小剪掉之后对精度影响最小。还有一种方法是基于 BN 层的 scale 因子做剪枝训练时给 BN 的 scale 加稀疏正则化训练完把 scale 小的通道剪掉。剪枝比例怎么定这是新手最容易拍脑袋的地方。我的做法是分层剪枝而不是全局一刀切。先做模型分析看每层的 FLOPs 占比和冗余程度敏感层少剪冗余层多剪。剪完一层评估一层如果精度掉得太多就回退重剪。这里面有个关键操作通道剪枝会改变后续层的输入通道数所以剪完卷积层之后紧接着的 BN 层和下一层卷积的输入维度也要同步调整。这个连锁反应很容易出 bug我在工具链里封装了一个结构重组的模块专门处理剪枝后的维度对齐。剪枝的效果跟网络本身的结构有关系。MobileNet 这类轻量网络本身冗余就少再剪就容易伤精度ResNet 和 VGG 这类大网络冗余多一般能剪到 30% 到 50% 而不明显掉点。所以我在配置里保留了按层指定剪枝比例的能力遇到敏感层就把比例调小甚至跳过。3.3 蒸馏精度补偿的最后手段蒸馏的作用是让一个小模型去模仿大模型的行为。普通的训练只学真值的 one-hot 标签而蒸馏会去学大模型的 logits 分布。logits 里包含了类别之间的相似性信息比如猫和老虎的 logits 比猫和汽车的 logits 更接近这些信息是 one-hot 标签里没有的。蒸馏的损失函数通常是学生和教师 logits 之间的 KL 散度加上学生和真值之间的交叉熵用两个超参数控制权重。这里有点讲究KL 散度部分在计算之前logits 要除以一个温度系数 T把分布软化让类别之间的细微差别放大学生才好学。T 太大分布太平滑目标不清晰T 太小等于退化成了硬标签训练。我的经验是图像分类任务 T 取 3 到 8检测类任务因为 logits 语义更复杂通常取更小的值。蒸馏训练的另一个细节是教师模型的 BN 统计量要和训练时保持一致不能开着训练模式去跑模型否则 BN 统计量会被当前的 batch 数据带偏。很多人在蒸馏时忘了调 model.eval()导致教师输出的 logits 分布不稳定学生训练震荡。这个问题我在实际项目中遇到过好几次排查半天才发现是 BN 模式的问题。3.4 图优化与算子融合图优化是很多人会忽略的一层。ONNX 模型导出之后计算图里有很多冗余结构比如 BN 层可以被融合进卷积层相邻的 reshape/transpose 可以合并常量折叠可以提前算掉。这些优化看起来不起眼但叠起来效果很明显。在 Model-Optimizer 里我引入 ONNX Runtime 的 graph optimization 能力同时自己写了几条常见的 pattern rewrite 规则。BN 融合是最典型的推理阶段 BN 的均值和方差是固定的所以 BN 的线性变换可以完全折算到卷积的权重和偏置里。一个 ResNet50 有大量 BN 层全部融合之后计算图会变得清爽很多推理时省掉的中间计算量不可小觑。融合操作的顺序也有讲究先做剪枝再做 BN 融合再量化。如果顺序反了剪枝的时候 BN 已经被融合剪完之后的维度调整反而更复杂。批次化的流程一定要想清楚依赖关系否则中途会有各种意想不到的维度错误。4. 实操过程与关键步骤4.1 环境准备与目录结构直接说我目前推荐的环境组合Python 3.8 以上PyTorch 1.12 以上ONNX 1.13 以上ONNX Runtime 1.14 以上。量化校准依赖 PyTorch 的torch.quantization导出依赖 ONNX后端转换按需装 NCNN 的转换工具或者 TensorRT 的 Python API。项目目录我习惯这样组织model-optimizer/ ├── configs/ │ └── resnet50_cpu.yaml ├── scripts/ │ ├── run_pipeline.py │ └── compare_accuracy.py ├── core/ │ ├── analyzer.py │ ├── pruner.py │ ├── quantizer.py │ ├── distiller.py │ └── exporter.py └── outputs/ ├── optimized/ └── reports/srun_pipeline.py是总入口读配置、按 stage 顺序执行、每步记录日志和中间模型。值得单独说一句的是每个 stage 处理完最好保存一个中间产物这样如果后面的步骤出了问题不用从头再来一遍。我的设计是 stage 之间通过磁盘文件传递模型每个文件带stage名称和参数哈希作为后缀方便追溯。4.2 量化配置模板下面是我常用的 PTQ 配置模板注释里写了每个参数的含义和选值依据stage: quantize method: ptq qconfig: backend: fbgemm # x86 CPU 用 fbgemmARM 上用 qnnpack per_channel: true calib_samples: 512 calib_dataloader: configs/calib_loader.py quantized_ops: conv: true matmul: true relu: true关于 backend 选项很多人分不清。fbgemm 是 Facebook 的 GEMM 库针对 x86 平台优化qnnpack 是移动端优先的量化执行后端。选错 backend 有时候不会报错但量化模型跑出来的结果和预期差很多。我一般在配置里指定目标硬件平台再由工具链自动选 backend避免手工配错。校准过程中有个细节校准要用能产生统计意义的 batch size比如 32 或者 64太小的话 batch-normalization 的统计量校准得不准。校准数据预处理必须和训练时一致包括缩放系数、均值方差、通道顺序差一点都会影响量化尺度。4.3 剪枝与蒸馏接入方式剪枝模块的接口我设计成三行代码from core.pruner import ChannelPruner pruner ChannelPruner(model, ratio0.3, methodl1) pruned_model pruner.prune(exclude_layers[layer4.2.conv3])exclude_layers是重要参数。最后一层卷积之前的信息最关键如果一剪把高层特征也剪没分类头的输入信息不足精度必掉。我习惯把最后几个 stage 的通道剪枝比例设置为普通层的一半或者干脆跳过。蒸馏模块用标准 KL 散度加交叉熵的写法import torch.nn.functional as F def distill_loss(student_logits, teacher_logits, labels, T4.0, alpha0.5): soft_student F.log_softmax(student_logits / T, dim1) soft_teacher F.softmax(teacher_logits / T, dim1) kd_loss F.kl_div(soft_student, soft_teacher, reductionbatchmean) * (T * T) ce_loss F.cross_entropy(student_logits, labels) return alpha * kd_loss (1 - alpha) * ce_loss注意 KL 散度和 T 的关系logits 除以 T 之后梯度要乘回 T 的平方去补偿否则温度项对梯度的影响会失真。这一幕是我从一篇蒸馏论文里学到的如果忘了乘T*T温度调高以后训练会不稳loss 下降变慢。蒸馏训练的效率问题也要提前规划。教师模型每个 batch 都要 forward 一次计算量翻倍。为了避免重复前向实践中可以把教师的 logits 先离线保存成文件训练的时候直接读文件省掉一半的计算资源。我在工具链里做了teacher_logits_cache选项实测能把蒸馏训练时间缩减 40% 以上。4.4 端侧导出与回填验证优化的最后一步是导出。导出要解决两个问题模型格式转换和模型正确性对齐。格式转换的例子是把 PyTorch 模型先转 ONNX再转 NCNNpython -m torch.onnx.export --model student.onnx --opsets 13 ./tools/onnx2ncnn student.onnx student.param student.binONNX 转换的时候有个细节模型的动态轴要显式声明。比如输入图像的 batch 维度和长宽维度在推理时可能变化如果不声明 dynamic axesONNX 会固定成训练时的尺寸部署时一旦输入尺寸变了直接报错。正确性对齐是导出之后必须做的一步。我的方法是准备一组固定的测试输入分别跑优化前模型和导出后模型逐层对比输出。这里有个量化模型特有的问题INT8 推理在 CPU 上有浮点累加和定点累加的微小差异对比时不能要求每个输出 bit 都一致而应该看最终预测类别是否一致或者用相对误差阈值判断。我遇到过一个典型问题ONNX 转 NCNN 之后模型输出和原始模型相差一个微小但足以引起误判的偏移排查后发现是 NCNN 的 reduce mean 算子和 ONNX 的实现精度不同导致的。这类问题没办法靠改参数解决只能在导出后加上一个微调层或者改用其他等价算子重写计算逻辑。所以无论用什么工具链导出后的端到端验证是绝对省略不了的。5. 常见问题与排查实录5.1 量化后精度暴跌怎么办精度暴跌的原因一般是三种校准数据不合适、量化方式太粗糙、敏感层被过度压缩。排查的思路是先确认校准数据的代表性换成更大更杂的校准集试试如果精度还没回来就把 per-tensor 改成 per-channel再不行就针对敏感层做混合精度也就是那些对数值变化特别敏感的层保留 FP32其余层用 INT8。我之前有个语义分割模型量化后 mIoU 从 0.82 掉到 0.76试了很多办法都没用最后用混合精度把前面几个下采样层保留 FP32精度恢复到了 0.80体积只多了不到 10%。敏感层怎么找可以先量化全部层再逐层回滚看哪一层回滚对精度提升最大这一层就是敏感层。这种方法虽然要多跑几次推理但定位很准。5.2 剪枝后推理速度没变化这个问题经常让人抓狂参数确实少了但推理时间几乎没变。原因通常在于剪枝后的网络结构没有真正变瘦——通道数变了但计算图里的算子还是原来的实现或者剪出的稀疏结构没有在目标硬件上获得加速。我的排查顺序是先看剪枝后模型的 FLOPs 是否真的下降了再看导出的计算图里通道数是否同步变化最后用性能分析工具看每层耗时。如果前面都没问题但速度没变那大概率是底层库没有针对剪枝后的非标准形状做内核优化。解决办法是直接改用更轻的骨干网络或者做深度压缩剪枝加蒸馏一起上而不是指望硬件自动适配。5.3 蒸馏温度怎么选温度太低和太高都不行。我之前在检测模型上用 T10 做了实验学生模型一直不收敛loss 震荡很厉害。后来降到 4 就好了。T 的经验选择要看任务的 logits 分布重叠度分类任务如果类别多且相似度高T 可以大一点如果类别差异很大T 取小一点更合适。调 T 的务实办法是先固定 T4 跑一个小 epoch观察 KL loss 是否平滑下降如果 KL loss 波动大说明 T 太大降一半再试如果 KL loss 很小但最终精度不够说明 T 太小信息量不足。另外 alpha 权重也值得注意我一般从 0.5 开始如果学生模型自身的表示能力偏弱就把 alpha 调高让教师的主导权更大一点。5.4 算子不支持导致导出失败导出阶段的报错大部分集中在算子兼容性上。PyTorch 里很多算子 ONNX 不支持或者不同版本的 ONNX opset 支持情况不同。比较常见的坑是torch.where、torch.topk、以及一些自定义的插值算子。我的处理办法是先用 ONNX 的check_model接口做静态检查然后准备一个小输入跑一遍看哪一层导出失败。如果还是不行就回到 PyTorch 把这部分逻辑重构成 ONNX 支持的等价操作。有时候重写算子反而能带来性能提升——比如把动态 shape 的 op 改成固定 shape 的 pad 加 slice虽然看起来不优雅但导出更稳端侧推理更快。还有一类问题是 PyTorch 版本差异导致的导出行为变化。同一个模型在 1.12 能导出在 2.0 可能导出出奇怪的图结构。我的建议是项目锁定 PyTorch 版本不要随意升级export 结果和推理结果的变化都在可控范围内。6. 一些实用心得做了一个多月的 Model-Optimizer最大的体会是模型优化不是一次性操作而是循环迭代。每次优化完都要把精度和速度数据记录下来形成一个优化日志下次调参的时候才有依据。没有数据对比的优化就是盲调这个坑我踩了很多次。另一个建议是把优化流程的每一步都做成可重复执行。不要手动复制模型文件、手动改参数、手动跑脚本全部流程尽量用命令行或者配置文件驱动。表面上看起来多花了时间但当你同时要处理五六个模型、每个模型有不同的剪枝比例和量化配置时可重复执行带来的收益是巨大的。最后优化前一定要先明确目标硬件。在 CPU 上优化的策略和在 GPU 上完全不一样GPU 上剪枝可能收益很小而 FP16 混合精度反而更有效CPU 或者移动端则要把量化和通道剪枝当成主力手段。工具链做得再好脱离目标硬件谈优化都是纸上谈兵。现在 Model-Optimizer 已经沉淀成了我这边部署项目的标配流程后续如果有机会再把自动化超参搜索和更多后端的支持补上。 模型优化实战：量化剪枝与知识蒸馏的端侧部署工具链
训练跑得好好的模型到了上线阶段突然发现体积太大、推理太慢内存也扛不住——这个问题我猜做算法落地的人都遇到过。尤其是在边缘设备、移动端、嵌入式场景模型优化不是锦上添花而是能不能上线的硬门槛。我最近把散落各处的优化脚本整合成了一个统一工具链名字就叫 Model-Optimizer。这篇文章把我从框架选型、量化剪枝蒸馏的落地细节、到踩坑排查的完整过程记录下来希望能给正在做模型压缩和加速方向的朋友一些直接能用的参考。整个工具链的设计初衷很简单让模型从 PyTorch 训练产物变成能在端侧高效运行的推理产物过程中尽量少掉点精度少踩坑最好一次配置就能复用。文章里我会把整套方案的模块划分、核心参数怎么填、每一步为什么要这么做讲清楚适合有一定训练基础、但刚开始接触模型优化与部署的工程师阅读。1. 先把问题想清楚模型优化到底在优化什么1.1 训练好的模型不等于能部署的模型很多人一开始会把模型优化简单理解成换个推理框架比如把 PyTorch 模型转成 ONNX再转成 TensorRT 或者 NCNN。但真正做过一轮就会发现转换只是最后一步效果好不好取决于前面做了多少优化工作。一个典型的例子用 ResNet50 做图像分类FP32 权重大约 98MB在服务器 GPU 上跑推理没什么压力。但放到一台只有 2GB 内存的工控机或者手机端模型加载就要占掉几十上百 MB前处理加推理一帧要几百毫秒完全达不到实时要求。这时候要做的事情是把模型变小、把推理变快、把内存占用压下来同时尽量不损失精度——这三件事就是模型优化的核心目标。所以在设计 Model-Optimizer 的时候我给自己定了几条原则。第一所有优化操作必须可回滚、可对比不能优化完就完了得知道每个环节对精度和速度的影响。第二流程必须可配置化不同模型、不同硬件只是参数不同而不是重新写一套脚本。第三每一步都要有量化指标压缩率、加速比、精度损失算得明明白白。1.2 Model-Optimizer 的定位不是某个算法的实现而是一条流水线工具链的名字虽然叫 Model-Optimizer但它不是某一种优化算法而是一条模型后处理流水线。输入是一个训练好的模型权重文件目前主要支持 PyTorch 格式输出是经过量化、剪枝、蒸馏、图优化之后的端侧推理模型同时还输出一份优化报告。整个流水线分了四个阶段先做诊断分析看看模型的参数量、计算量、每层耗时分布找出哪里是胖子再做结构优化包括通道剪枝和层融合然后做精度补偿用蒸馏或者量化感知训练把损失的精度拉回来最后做异构导出针对不同的推理后端生成对应格式。之所以把优化和导出分开是因为优化本身和硬件无关但导出格式和硬件强相关。同一个优化好的模型在 ARM CPU 上可以导成 NCNN在 NVIDIA GPU 上可以导成 TensorRT在手机端可以导成 TFLite。分开之后优化逻辑只需要写一遍导出逻辑按后端扩展就行。2. 方案选型为什么我没有重复造轮子2.1 框架选择的纠结过程动手之前最大的纠结是用现成框架还是自己攒一套。当时调研了 Intel 的 Neural Compressor、NVIDIA 的 TensorRT、微软的 Olive还有华为的 MindSpore Lite 工具链。这些框架功能都很强但都有一个共性问题它们是各自生态的全家桶如果要同时支持多种后端、多种优化策略的自由组合配置成本和学习成本都很高。我最后的选择是底层算法尽量调用成熟库上层调度全部自己写。比如量化校准用的 PyTorch 自带量化接口和 ONNX Runtime 的量化工具剪枝逻辑基于 torch.nn.utils.prune 做二次开发蒸馏损失部分自己实现调度脚本和配置系统全部自己写。这样做的好处是每个环节都可以单独替换坏处是需要自己处理各库之间的接口差异但整体下来利大于弊。关于蒸馏还有个容易忽略的细节很多人以为蒸馏只是把大模型的 logits 拿过来硬训小模型但实际上教师模型和学生的预处理流程必须完全一致。如果教师网络用了不同的归一化参数或者输入尺寸学生的输入分布就对不上蒸馏效果会大打折扣。这一点我在工具链里专门做了输入流水线的统一校验避免这种隐性错误。2.2 模块划分与配置系统Model-Optimizer 的代码结构分成五个模块analyzer负责模型诊断和 FLOPs 分析pruner负责剪枝策略quantizer负责量化和校准distiller负责蒸馏训练exporter负责导出各类后端格式。所有模块通过一个 YAML 配置文件串联。配置文件是整个工具链的核心。我采用的方法是流水线式配置也就是把每一步优化定义成一个 stage每个 stage 有自己的参数。比如pipeline: - stage: analyze - stage: prune ratio: 0.3 method: channel_l1 skip_layers: [layer1, layer2] - stage: quantize method: ptq calib_samples: 512 per_channel: true - stage: export backend: onnx opset: 13这样做的好处是不同项目的差异全部收敛在配置文件里代码层面几乎不用改。我接过的项目里有图像分类、目标检测、语义分割几种模型换模型的时候只改配置和数据集加载代码就行优化逻辑完全复用。这个配置系统也是我踩坑踩出来的。最早的时候我把优化参数硬编码在脚本里每来一个新项目就拷一份脚本改一改后来脚本越来越多改一处忘了另一处出了不少问题。改成配置驱动之后每个项目的优化参数有据可查出了问题先看配置排错效率高了很多。3. 核心优化技术的落地细节3.1 量化最容易上手也最容易翻车量化是模型压缩里性价比最高的手段FP32 的权重从每参数 4 字节压缩到 INT8 的 1 字节模型体积直接缩小到原来的四分之一推理速度在某些硬件上还能再快 2 到 4 倍。但量化也是最容易翻车的环节尤其是对精度敏感的模型。我主要用的是后训练量化PTQ和量化感知训练QAT两条路线。PTQ 的流程是用一部分训练集或者验证集的数据做校准统计每层激活值的分布然后确定每个 tensor 的 scale 和 zero point。关键问题在于校准数据集的选择——如果用错了数据统计出来的分布是偏的量化后的精度就会暴跌。校准数据要够杂。我的做法是从多个类别的样本里均匀抽样覆盖不同光照、不同目标大小、不同背景的场景数量一般取 256 到 1024 张图。太少统计不准太多校准时间长而且收益会饱和。校准用的是验证集还是训练集我的经验是验证集就好因为验证集代表模型实际要面对的数据分布而且可以避免过拟合校准集。量化还有一个很容易忽略的坑per-channel 和 per-tensor 的差别。per-tensor 量化是整个 tensor 用一个 scale实现简单但精度损失大per-channel 是每个卷积核一个 scale精度高但某些硬件不支持。在 Model-Optimizer 里我默认启用 per-channel然后在导出阶段再根据后端能力做回退检查。关于量化后的推理速度我得提醒一句INT8 模型在 CPU 上有对应的硬件指令优化比如 ARM 平台的 DotProd 指令、x86 平台的 AVX512 VNNI只有在这些指令能被编译器识别的情况下才有加速效果。如果你把 INT8 模型跑在纯浮点模拟的环境里速度可能不升反降。所以量化前先确认目标硬件有没有 INT8 加速能力否则白忙一场。3.2 剪枝从非结构化到结构化量化压的是数值位宽剪枝压的是参数数量。剪枝的思路很直观把不重要的权重置成零或者把不重要的卷积核删掉。但这里有个层级问题非结构化剪枝是把单个权重置零造成了稀疏矩阵虽然从理论上说参数量少了但常规硬件上稀疏矩阵的存储和计算效率并不高除非底层专门做了稀疏加速。所以我在工具链里默认做结构化剪枝也就是剪掉整个卷积核或者整个通道。判断哪些通道不重要的常见方法是用 L1 范数——权重绝对值之和越小的通道对输出的贡献通常越小剪掉之后对精度影响最小。还有一种方法是基于 BN 层的 scale 因子做剪枝训练时给 BN 的 scale 加稀疏正则化训练完把 scale 小的通道剪掉。剪枝比例怎么定这是新手最容易拍脑袋的地方。我的做法是分层剪枝而不是全局一刀切。先做模型分析看每层的 FLOPs 占比和冗余程度敏感层少剪冗余层多剪。剪完一层评估一层如果精度掉得太多就回退重剪。这里面有个关键操作通道剪枝会改变后续层的输入通道数所以剪完卷积层之后紧接着的 BN 层和下一层卷积的输入维度也要同步调整。这个连锁反应很容易出 bug我在工具链里封装了一个结构重组的模块专门处理剪枝后的维度对齐。剪枝的效果跟网络本身的结构有关系。MobileNet 这类轻量网络本身冗余就少再剪就容易伤精度ResNet 和 VGG 这类大网络冗余多一般能剪到 30% 到 50% 而不明显掉点。所以我在配置里保留了按层指定剪枝比例的能力遇到敏感层就把比例调小甚至跳过。3.3 蒸馏精度补偿的最后手段蒸馏的作用是让一个小模型去模仿大模型的行为。普通的训练只学真值的 one-hot 标签而蒸馏会去学大模型的 logits 分布。logits 里包含了类别之间的相似性信息比如猫和老虎的 logits 比猫和汽车的 logits 更接近这些信息是 one-hot 标签里没有的。蒸馏的损失函数通常是学生和教师 logits 之间的 KL 散度加上学生和真值之间的交叉熵用两个超参数控制权重。这里有点讲究KL 散度部分在计算之前logits 要除以一个温度系数 T把分布软化让类别之间的细微差别放大学生才好学。T 太大分布太平滑目标不清晰T 太小等于退化成了硬标签训练。我的经验是图像分类任务 T 取 3 到 8检测类任务因为 logits 语义更复杂通常取更小的值。蒸馏训练的另一个细节是教师模型的 BN 统计量要和训练时保持一致不能开着训练模式去跑模型否则 BN 统计量会被当前的 batch 数据带偏。很多人在蒸馏时忘了调 model.eval()导致教师输出的 logits 分布不稳定学生训练震荡。这个问题我在实际项目中遇到过好几次排查半天才发现是 BN 模式的问题。3.4 图优化与算子融合图优化是很多人会忽略的一层。ONNX 模型导出之后计算图里有很多冗余结构比如 BN 层可以被融合进卷积层相邻的 reshape/transpose 可以合并常量折叠可以提前算掉。这些优化看起来不起眼但叠起来效果很明显。在 Model-Optimizer 里我引入 ONNX Runtime 的 graph optimization 能力同时自己写了几条常见的 pattern rewrite 规则。BN 融合是最典型的推理阶段 BN 的均值和方差是固定的所以 BN 的线性变换可以完全折算到卷积的权重和偏置里。一个 ResNet50 有大量 BN 层全部融合之后计算图会变得清爽很多推理时省掉的中间计算量不可小觑。融合操作的顺序也有讲究先做剪枝再做 BN 融合再量化。如果顺序反了剪枝的时候 BN 已经被融合剪完之后的维度调整反而更复杂。批次化的流程一定要想清楚依赖关系否则中途会有各种意想不到的维度错误。4. 实操过程与关键步骤4.1 环境准备与目录结构直接说我目前推荐的环境组合Python 3.8 以上PyTorch 1.12 以上ONNX 1.13 以上ONNX Runtime 1.14 以上。量化校准依赖 PyTorch 的torch.quantization导出依赖 ONNX后端转换按需装 NCNN 的转换工具或者 TensorRT 的 Python API。项目目录我习惯这样组织model-optimizer/ ├── configs/ │ └── resnet50_cpu.yaml ├── scripts/ │ ├── run_pipeline.py │ └── compare_accuracy.py ├── core/ │ ├── analyzer.py │ ├── pruner.py │ ├── quantizer.py │ ├── distiller.py │ └── exporter.py └── outputs/ ├── optimized/ └── reports/srun_pipeline.py是总入口读配置、按 stage 顺序执行、每步记录日志和中间模型。值得单独说一句的是每个 stage 处理完最好保存一个中间产物这样如果后面的步骤出了问题不用从头再来一遍。我的设计是 stage 之间通过磁盘文件传递模型每个文件带stage名称和参数哈希作为后缀方便追溯。4.2 量化配置模板下面是我常用的 PTQ 配置模板注释里写了每个参数的含义和选值依据stage: quantize method: ptq qconfig: backend: fbgemm # x86 CPU 用 fbgemmARM 上用 qnnpack per_channel: true calib_samples: 512 calib_dataloader: configs/calib_loader.py quantized_ops: conv: true matmul: true relu: true关于 backend 选项很多人分不清。fbgemm 是 Facebook 的 GEMM 库针对 x86 平台优化qnnpack 是移动端优先的量化执行后端。选错 backend 有时候不会报错但量化模型跑出来的结果和预期差很多。我一般在配置里指定目标硬件平台再由工具链自动选 backend避免手工配错。校准过程中有个细节校准要用能产生统计意义的 batch size比如 32 或者 64太小的话 batch-normalization 的统计量校准得不准。校准数据预处理必须和训练时一致包括缩放系数、均值方差、通道顺序差一点都会影响量化尺度。4.3 剪枝与蒸馏接入方式剪枝模块的接口我设计成三行代码from core.pruner import ChannelPruner pruner ChannelPruner(model, ratio0.3, methodl1) pruned_model pruner.prune(exclude_layers[layer4.2.conv3])exclude_layers是重要参数。最后一层卷积之前的信息最关键如果一剪把高层特征也剪没分类头的输入信息不足精度必掉。我习惯把最后几个 stage 的通道剪枝比例设置为普通层的一半或者干脆跳过。蒸馏模块用标准 KL 散度加交叉熵的写法import torch.nn.functional as F def distill_loss(student_logits, teacher_logits, labels, T4.0, alpha0.5): soft_student F.log_softmax(student_logits / T, dim1) soft_teacher F.softmax(teacher_logits / T, dim1) kd_loss F.kl_div(soft_student, soft_teacher, reductionbatchmean) * (T * T) ce_loss F.cross_entropy(student_logits, labels) return alpha * kd_loss (1 - alpha) * ce_loss注意 KL 散度和 T 的关系logits 除以 T 之后梯度要乘回 T 的平方去补偿否则温度项对梯度的影响会失真。这一幕是我从一篇蒸馏论文里学到的如果忘了乘T*T温度调高以后训练会不稳loss 下降变慢。蒸馏训练的效率问题也要提前规划。教师模型每个 batch 都要 forward 一次计算量翻倍。为了避免重复前向实践中可以把教师的 logits 先离线保存成文件训练的时候直接读文件省掉一半的计算资源。我在工具链里做了teacher_logits_cache选项实测能把蒸馏训练时间缩减 40% 以上。4.4 端侧导出与回填验证优化的最后一步是导出。导出要解决两个问题模型格式转换和模型正确性对齐。格式转换的例子是把 PyTorch 模型先转 ONNX再转 NCNNpython -m torch.onnx.export --model student.onnx --opsets 13 ./tools/onnx2ncnn student.onnx student.param student.binONNX 转换的时候有个细节模型的动态轴要显式声明。比如输入图像的 batch 维度和长宽维度在推理时可能变化如果不声明 dynamic axesONNX 会固定成训练时的尺寸部署时一旦输入尺寸变了直接报错。正确性对齐是导出之后必须做的一步。我的方法是准备一组固定的测试输入分别跑优化前模型和导出后模型逐层对比输出。这里有个量化模型特有的问题INT8 推理在 CPU 上有浮点累加和定点累加的微小差异对比时不能要求每个输出 bit 都一致而应该看最终预测类别是否一致或者用相对误差阈值判断。我遇到过一个典型问题ONNX 转 NCNN 之后模型输出和原始模型相差一个微小但足以引起误判的偏移排查后发现是 NCNN 的 reduce mean 算子和 ONNX 的实现精度不同导致的。这类问题没办法靠改参数解决只能在导出后加上一个微调层或者改用其他等价算子重写计算逻辑。所以无论用什么工具链导出后的端到端验证是绝对省略不了的。5. 常见问题与排查实录5.1 量化后精度暴跌怎么办精度暴跌的原因一般是三种校准数据不合适、量化方式太粗糙、敏感层被过度压缩。排查的思路是先确认校准数据的代表性换成更大更杂的校准集试试如果精度还没回来就把 per-tensor 改成 per-channel再不行就针对敏感层做混合精度也就是那些对数值变化特别敏感的层保留 FP32其余层用 INT8。我之前有个语义分割模型量化后 mIoU 从 0.82 掉到 0.76试了很多办法都没用最后用混合精度把前面几个下采样层保留 FP32精度恢复到了 0.80体积只多了不到 10%。敏感层怎么找可以先量化全部层再逐层回滚看哪一层回滚对精度提升最大这一层就是敏感层。这种方法虽然要多跑几次推理但定位很准。5.2 剪枝后推理速度没变化这个问题经常让人抓狂参数确实少了但推理时间几乎没变。原因通常在于剪枝后的网络结构没有真正变瘦——通道数变了但计算图里的算子还是原来的实现或者剪出的稀疏结构没有在目标硬件上获得加速。我的排查顺序是先看剪枝后模型的 FLOPs 是否真的下降了再看导出的计算图里通道数是否同步变化最后用性能分析工具看每层耗时。如果前面都没问题但速度没变那大概率是底层库没有针对剪枝后的非标准形状做内核优化。解决办法是直接改用更轻的骨干网络或者做深度压缩剪枝加蒸馏一起上而不是指望硬件自动适配。5.3 蒸馏温度怎么选温度太低和太高都不行。我之前在检测模型上用 T10 做了实验学生模型一直不收敛loss 震荡很厉害。后来降到 4 就好了。T 的经验选择要看任务的 logits 分布重叠度分类任务如果类别多且相似度高T 可以大一点如果类别差异很大T 取小一点更合适。调 T 的务实办法是先固定 T4 跑一个小 epoch观察 KL loss 是否平滑下降如果 KL loss 波动大说明 T 太大降一半再试如果 KL loss 很小但最终精度不够说明 T 太小信息量不足。另外 alpha 权重也值得注意我一般从 0.5 开始如果学生模型自身的表示能力偏弱就把 alpha 调高让教师的主导权更大一点。5.4 算子不支持导致导出失败导出阶段的报错大部分集中在算子兼容性上。PyTorch 里很多算子 ONNX 不支持或者不同版本的 ONNX opset 支持情况不同。比较常见的坑是torch.where、torch.topk、以及一些自定义的插值算子。我的处理办法是先用 ONNX 的check_model接口做静态检查然后准备一个小输入跑一遍看哪一层导出失败。如果还是不行就回到 PyTorch 把这部分逻辑重构成 ONNX 支持的等价操作。有时候重写算子反而能带来性能提升——比如把动态 shape 的 op 改成固定 shape 的 pad 加 slice虽然看起来不优雅但导出更稳端侧推理更快。还有一类问题是 PyTorch 版本差异导致的导出行为变化。同一个模型在 1.12 能导出在 2.0 可能导出出奇怪的图结构。我的建议是项目锁定 PyTorch 版本不要随意升级export 结果和推理结果的变化都在可控范围内。6. 一些实用心得做了一个多月的 Model-Optimizer最大的体会是模型优化不是一次性操作而是循环迭代。每次优化完都要把精度和速度数据记录下来形成一个优化日志下次调参的时候才有依据。没有数据对比的优化就是盲调这个坑我踩了很多次。另一个建议是把优化流程的每一步都做成可重复执行。不要手动复制模型文件、手动改参数、手动跑脚本全部流程尽量用命令行或者配置文件驱动。表面上看起来多花了时间但当你同时要处理五六个模型、每个模型有不同的剪枝比例和量化配置时可重复执行带来的收益是巨大的。最后优化前一定要先明确目标硬件。在 CPU 上优化的策略和在 GPU 上完全不一样GPU 上剪枝可能收益很小而 FP16 混合精度反而更有效CPU 或者移动端则要把量化和通道剪枝当成主力手段。工具链做得再好脱离目标硬件谈优化都是纸上谈兵。现在 Model-Optimizer 已经沉淀成了我这边部署项目的标配流程后续如果有机会再把自动化超参搜索和更多后端的支持补上。