尧图网页设计 
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念很多人会把它和“训练优化器”比如 SGD、AdamW搞混。其实它俩完全不是一回事。训练优化器管的是“怎么更新权重”而 Model-Optimizer 管的是“怎么让训练好的模型跑得更小、更快、更省”。你可以把它理解成模型出厂前的“瘦身提速流水线”量化、剪枝、蒸馏、算子融合、图优化这些活儿都归它管。我最早接触这类工具是在一个边缘设备部署项目上。当时手里有一个 300MB 左右的视觉模型推理延迟在目标芯片上高达 400ms根本没法满足实时性要求。试过手动改网络结构、手动写量化脚本折腾了两周效果都不理想。后来换成系统化的 Model-Optimizer 流程量化加剪枝一套组合拳下来模型压到 60MB延迟降到 90ms精度只掉了 0.8 个百分点。从那以后我就意识到模型优化不是“调参玄学”而是一套有章法、可复现的工程流程。这篇文章适合三类人看一是刚做完模型训练、准备部署上线的算法工程师二是需要在有限算力上跑大模型的嵌入式或移动端开发者三是对推理性能有硬指标要求、想系统了解优化手段的技术负责人。我会把整个优化链路拆开讲包括每一步为什么这么做、参数怎么算、坑在哪里尽量让你看完就能在自己的项目里复现。2. 整体优化思路与方案选型拆解2.1 为什么不能只做量化也不能只做剪枝很多人一上来就问“量化是不是就够了”我的回答通常是看你的瓶颈在哪。如果瓶颈是显存占用和带宽量化收益最直接如果瓶颈是算力FLOPs剪枝和蒸馏更有效如果瓶颈是算子调度开销那图优化和算子融合才是关键。我做过一组对比实验在同一个 ResNet-50 模型上分别只做量化、只做剪枝、以及两者结合结果差异非常明显优化策略模型大小推理延迟Top-1 精度原始模型98MB120ms76.1%仅 INT8 量化25MB65ms75.6%仅结构化剪枝 30%69MB88ms75.2%量化剪枝18MB48ms74.8%可以看到量化对体积和延迟的收益最大剪枝对 FLOPs 的削减更明显但单独用都有天花板。组合使用才能把收益叠加起来。这也是 Model-Optimizer 这类工具存在的意义——它把多种优化技术串成一条流水线而不是让你手动一个个试。2.2 优化顺序为什么不能随便调这里有个非常关键的工程经验优化顺序错了效果可能直接归零。我踩过的最大的坑就是先剪枝再量化结果量化时校准数据分布完全变了精度崩了 5 个点。正确的顺序通常是先做图优化和算子融合再做剪枝然后做蒸馏如果需要最后做量化。原因在于图优化和算子融合不改变权重数值放在最前面最安全剪枝会改变权重分布如果先量化再剪枝量化时的 scale 就不准了量化放在最后是因为它需要基于最终的权重分布做校准校准数据才能反映真实推理时的数值范围。注意如果你的部署目标支持动态量化比如某些推理引擎的 PTQ 流程顺序可以稍微灵活但“量化最后做”这个原则基本不会错。2.3 工具选型自研脚本还是用现成框架我见过不少团队一开始想自己写量化脚本觉得“不就是把 float 转成 int8 嘛”。结果写到一半发现要处理 per-channel scale、要处理 bias 校正、要处理特殊算子回退最后代码量比模型本身还大。现成的 Model-Optimizer 类工具比如基于 PyTorch 的量化工具链、ONNX Runtime 的优化器、TensorRT 的构建流程已经把这些问题封装好了。我的建议是除非你有非常特殊的算子或硬件需求否则优先用成熟工具链。自研只适合两种情况一是目标硬件有专属指令集现成工具不支持二是你需要对优化过程做极细粒度的控制比如逐层指定不同的量化策略。3. 核心细节解析与实操要点3.1 量化PTQ 和 QAT 到底怎么选量化分两条路训练后量化PTQ和量化感知训练QAT。PTQ 快几分钟就能跑完适合快速验证QAT 慢需要重新训练几个 epoch但精度保持更好。我的经验法则是如果 PTQ 后精度掉点在 1% 以内直接用 PTQ如果掉点超过 2%再考虑 QAT。大部分视觉模型在 INT8 PTQ 下掉点都在 0.5% 到 1.5% 之间PTQ 基本够用。但 NLP 模型尤其是 Transformer 类PTQ 掉点可能很严重这时候 QAT 几乎是必选项。PTQ 的核心是校准Calibration。校准数据的选取非常关键我一般会从验证集里随机抽 500 到 1000 个样本确保覆盖所有类别。校准方法常用的是最小化 KL 散度或最小化 MSE前者对激活值分布更敏感后者对权重量化更友好。实测下来KL 散度在大多数 CNN 上表现更稳。# 以 PyTorch 为例PTQ 校准的典型流程 import torch from torch.quantization import get_default_qconfig, prepare, convert model.eval() model.qconfig get_default_qconfig(fbgemm) # 服务器端用 fbgemm移动端用 qnnpack model_prepared prepare(model) # 校准用代表性数据跑一遍不更新权重 with torch.no_grad(): for data, _ in calib_loader: model_prepared(data) model_quantized convert(model_prepared)这段代码看起来简单但有几个隐藏坑点prepare之后模型会插入观察器Observer这些观察器会记录激活值的 min/maxconvert时会把 float 算子替换成量化算子。如果你在prepare和convert之间做了任何改变模型结构的操作量化会直接失败。3.2 剪枝结构化 vs 非结构化别选错了剪枝分结构化剪枝和非结构化剪枝。非结构化剪枝是把单个权重置零理论上压缩率高但实际部署时如果没有稀疏计算库支持速度根本不会提升因为 GPU 还是按稠密矩阵算。结构化剪枝是直接砍掉整个通道或整个层虽然压缩率低一些但部署时是实打实的加速。我一般推荐如果目标硬件没有稀疏计算加速能力直接上结构化剪枝。非结构化剪枝只适合研究场景或者有专门稀疏推理引擎的情况。结构化剪枝的关键是“剪多少”。剪多了精度崩剪少了没效果。我的做法是逐层敏感度分析对每一层分别尝试剪 10%、20%、30%看精度变化然后给每层分配不同的剪枝率。对精度敏感的层少剪对精度不敏感的层多剪。# 简单的逐层敏感度分析伪代码 for layer in model.layers: for ratio in [0.1, 0.2, 0.3]: pruned_model prune_layer(model, layer, ratio) acc evaluate(pruned_model) print(f{layer.name} ratio{ratio} acc{acc})这个分析跑起来比较慢但一次跑完能省下后面反复试错的时间。我通常会在小规模数据上先跑一遍快速筛掉明显不行的配置。3.3 蒸馏什么时候值得做蒸馏是用一个大模型教师指导一个小模型学生训练。它的收益在于你可以用一个更小的模型达到接近大模型的精度。但蒸馏的代价是需要重新训练而且需要教师模型的输出 logits。我的判断标准是如果剪枝和量化后精度仍然不达标且你有充足的训练资源和时间再考虑蒸馏。蒸馏不是万能药它更适合“模型结构本身就有冗余”的场景。如果你的模型已经很小了蒸馏收益很有限。蒸馏的温度参数 T 很关键。T 越大软标签分布越平滑学生模型能学到的“暗知识”越多。但 T 太大也会导致梯度消失。我一般从 T4 开始试配合 alpha0.7软标签损失权重和 0.3硬标签损失权重。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装我以 PyTorch 生态为例因为它的量化工具链最成熟。基础环境需要 PyTorch 1.12 以上ONNX 1.12 以上以及 onnxruntime 或 TensorRT取决于部署目标。pip install torch torchvision pip install onnx onnxruntime pip install onnxsim # 用于简化 ONNX 图如果你要部署到 NVIDIA GPU还需要装 TensorRT。TensorRT 的版本要和 CUDA 版本匹配这个坑我踩过好几次——版本不匹配时编译能过但推理时直接报错。提示建议用 conda 建一个独立环境因为量化工具链对版本非常敏感。我试过在同一个环境里同时装 PyTorch 1.10 和 1.13 的量化工具结果 import 直接冲突。4.2 第一步导出 ONNX 并做图优化不管后面用什么推理引擎先把模型导出成 ONNX 是个好习惯。ONNX 是一个中间表示方便你做图级别的优化也方便跨框架部署。import torch.onnx dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}} )导出后用 onnxsim 做一次图简化把冗余的算子比如连续的 Reshape、Transpose合并掉。这一步通常能减少 5% 到 10% 的推理时间而且不损失精度。onnxsim model.onnx model_sim.onnx4.3 第二步量化校准与模型转换如果你用 ONNX Runtime 做部署量化可以直接在 ONNX 层面做。ONNX Runtime 提供了quantize_static接口支持 INT8 量化。from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(CalibrationDataReader): def __init__(self, calib_data): self.data calib_data self.iter iter(self.data) def get_next(self): return next(self.iter, None) quantize_static( model_inputmodel_sim.onnx, model_outputmodel_quant.onnx, calibration_data_readerDataReader(calib_loader), quant_formatQuantFormat.QDQ, # QDQ 格式兼容性更好 per_channelTrue # 逐通道量化精度更高 )这里per_channelTrue是个关键参数。逐通道量化会给每个通道单独算 scale比逐张量量化精度高不少但模型体积会稍微大一点。实测下来逐通道量化在 CNN 上精度能提升 0.3% 到 0.8%体积只增加不到 1%。4.4 第三步剪枝与微调剪枝通常要在训练框架里做因为需要重新训练来恢复精度。以 PyTorch 为例可以用torch.nn.utils.prune做非结构化剪枝或者手动做结构化剪枝。import torch.nn.utils.prune as prune # 对卷积层做 L1 非结构化剪枝 for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d): prune.l1_unstructured(module, nameweight, amount0.3) # 剪枝后需要微调几个 epoch 恢复精度 optimizer torch.optim.SGD(model.parameters(), lr0.001, momentum0.9) for epoch in range(5): train_one_epoch(model, train_loader, optimizer) evaluate(model, val_loader)微调的学习率要设小一点我一般用原始训练学习率的十分之一。微调 epoch 数不用太多3 到 5 个 epoch 通常就够了。如果微调后精度还是上不来说明剪枝率太高了需要回调。4.5 第四步推理引擎构建与性能测试最后一步是把优化后的模型放到目标推理引擎上跑。如果目标是 NVIDIA GPU用 TensorRT如果是 CPU用 ONNX Runtime 或 OpenVINO如果是移动端用 TFLite 或 NCNN。TensorRT 的构建流程比较重需要指定最大 batch size、最大工作空间大小、精度模式等参数。我一般会先跑一次 FP16 模式看看精度和速度再跑 INT8 模式对比。import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(model_quant.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_flag(trt.BuilderFlag.INT8) config.set_flag(trt.BuilderFlag.FP16) config.max_workspace_size 1 30 # 1GB engine builder.build_engine(network, config)构建完成后一定要做精度对齐测试用同一批输入分别跑原始模型和优化后模型对比输出差异。我一般要求最大绝对误差小于 0.01否则就要检查量化校准是不是有问题。5. 常见问题与排查技巧实录5.1 量化后精度掉太多怎么办这是最常见的问题。排查思路按优先级来第一检查校准数据。校准数据太少或者分布不均衡会导致 scale 估计不准。我一般要求校准集至少覆盖每个类别 10 个样本。第二检查是否有敏感层。某些层比如第一层卷积、最后一层全连接对量化特别敏感。可以尝试把这些层保持 FP16 或 FP32只量化中间层。ONNX Runtime 和 TensorRT 都支持混合精度量化。第三尝试逐通道量化。如果之前用的是逐张量量化改成逐通道通常能挽回 0.5% 左右的精度。第四如果以上都不行上 QAT。QAT 通过在训练时模拟量化误差让模型自己适应量化精度保持最好但需要重新训练。5.2 剪枝后模型速度没提升这个问题通常是因为用了非结构化剪枝但推理引擎不支持稀疏计算。解决办法有两个一是改用结构化剪枝直接砍通道二是换一个支持稀疏推理的引擎比如某些专门做稀疏加速的推理库。还有一个可能原因是剪枝后模型虽然参数少了但内存访问模式变差了导致实际延迟没降。这种情况在 GPU 上比较少见但在 CPU 上偶尔会遇到。解决办法是做一次内存布局优化或者换用更紧凑的数据格式。5.3 优化后模型在不同设备上表现不一致这是部署阶段最头疼的问题。同一个 ONNX 模型在服务器 CPU 上跑得好好的到了移动端就崩了。原因通常是算子支持不一致某些量化算子在移动端推理引擎里没有实现或者实现方式和服务器端不同。我的做法是在目标设备上做完整的精度和性能测试不要只在开发机上验证。如果发现某个算子不支持可以用 ONNX Runtime 的算子回退功能把不支持的算子退回 FP32。虽然会损失一点性能但至少能跑通。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉 3%校准数据不足或分布偏差检查校准集类别覆盖增加校准样本改用逐通道量化剪枝后速度无提升非结构化剪枝无稀疏加速检查推理引擎是否支持稀疏改用结构化剪枝模型转换失败算子不支持或版本不匹配查看转换日志中的算子名回退算子到 FP32 或升级工具版本推理结果与原始模型差异大量化 scale 估计错误对比中间层输出重新校准检查 per-channel 设置移动端崩溃算子不支持或内存不足查看设备日志减少 batch size回退不支持算子5.5 几个我踩过的坑第一个坑在prepare和convert之间做了模型结构修改。PyTorch 的量化流程要求这两步之间不能动模型结构否则观察器记录的统计信息会失效。我有一次在中间加了一个 ReLU结果量化后输出全是零。第二个坑校准数据用了训练集而不是验证集。训练集里有过拟合的样本分布和推理时不一致导致 scale 偏大或偏小。后来我固定用验证集的一个子集做校准问题就没了。第三个坑TensorRT 的 INT8 校准用了默认的熵校准。默认校准在某些模型上效果不好后来换成 min-max 校准精度提升了 1.2%。校准方法的选择要根据模型特点来没有绝对的最优解。第四个坑忽略了推理引擎的预热。第一次推理通常比后续推理慢很多因为要加载 kernel、分配内存。做性能测试时一定要先跑 10 到 20 次预热再取平均值。我有一次没预热测出来的延迟比实际高了 3 倍差点误判优化无效。6. 优化效果评估与迭代策略6.1 怎么定义“优化达标”优化不是越极致越好而是要满足业务指标。我一般会定三个硬指标模型体积、推理延迟、精度下限。比如“模型小于 50MB延迟小于 100ms精度不低于原始模型的 99%”。这三个指标定下来优化目标就清晰了。如果三个指标不能同时满足就要做取舍。我的优先级是精度下限 延迟 体积。因为精度不达标模型根本不能用延迟不达标用户体验差体积不达标最多是存储成本高一点。6.2 迭代优化的节奏我通常分三轮迭代第一轮快速验证。用 PTQ 加轻度剪枝跑一遍看指标差距。这一轮通常一两天就能完成。第二轮精细调优。根据第一轮的结果调整剪枝率、量化策略、校准方法。这一轮可能需要一周。第三轮极限压榨。如果前两轮还不达标上 QAT 和蒸馏或者换更激进的优化策略。这一轮时间最长但收益也最大。每一轮结束后都要做完整的精度和性能测试记录数据方便对比。我习惯用一个表格记录每轮的配置和结果这样后面回溯的时候一目了然。6.3 一个真实的优化案例最后分享一个我最近做的项目。目标是在一块算力有限的边缘芯片上部署一个目标检测模型。原始模型是 YOLOv5s体积 28MB延迟 200msmAP 0.38。第一轮PTQ INT8 量化体积降到 7MB延迟降到 110msmAP 掉到 0.35。精度不达标。第二轮分析发现是检测头对量化敏感把检测头保持 FP16其余层 INT8。体积 9MB延迟 120msmAP 回到 0.37。还是差一点。第三轮对主干网络做 20% 结构化剪枝然后微调 5 个 epoch再做混合精度量化。最终体积 6MB延迟 95msmAP 0.375。达标。这个案例说明单一优化手段往往不够组合拳才能达到最优效果。而且每一轮都要有明确的排查方向不能盲目试。提示优化过程中一定要保留每一轮的模型和配置方便回滚。我有一次优化到第三轮发现效果不如第二轮但第二轮的模型没保存只能重跑浪费了两天时间。6.4 后续可以扩展的方向如果你已经跑通了基本的量化加剪枝流程可以进一步尝试几个方向一是自动化搜索最优剪枝率用强化学习或遗传算法来搜二是针对特定硬件做算子定制比如把某些算子融合成硬件专属指令三是把优化流程集成到 CI/CD 里每次模型更新自动跑一遍优化和测试。我个人在实际操作中的体会是模型优化这件事工具只占三成经验占七成。同样的工具不同的人用效果可能差一倍。关键是要理解每一步背后的原理知道什么情况下该用什么策略而不是盲目套模板。踩过的坑越多判断越准。 模型优化器实战：量化剪枝蒸馏全流程与部署调优
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念很多人会把它和“训练优化器”比如 SGD、AdamW搞混。其实它俩完全不是一回事。训练优化器管的是“怎么更新权重”而 Model-Optimizer 管的是“怎么让训练好的模型跑得更小、更快、更省”。你可以把它理解成模型出厂前的“瘦身提速流水线”量化、剪枝、蒸馏、算子融合、图优化这些活儿都归它管。我最早接触这类工具是在一个边缘设备部署项目上。当时手里有一个 300MB 左右的视觉模型推理延迟在目标芯片上高达 400ms根本没法满足实时性要求。试过手动改网络结构、手动写量化脚本折腾了两周效果都不理想。后来换成系统化的 Model-Optimizer 流程量化加剪枝一套组合拳下来模型压到 60MB延迟降到 90ms精度只掉了 0.8 个百分点。从那以后我就意识到模型优化不是“调参玄学”而是一套有章法、可复现的工程流程。这篇文章适合三类人看一是刚做完模型训练、准备部署上线的算法工程师二是需要在有限算力上跑大模型的嵌入式或移动端开发者三是对推理性能有硬指标要求、想系统了解优化手段的技术负责人。我会把整个优化链路拆开讲包括每一步为什么这么做、参数怎么算、坑在哪里尽量让你看完就能在自己的项目里复现。2. 整体优化思路与方案选型拆解2.1 为什么不能只做量化也不能只做剪枝很多人一上来就问“量化是不是就够了”我的回答通常是看你的瓶颈在哪。如果瓶颈是显存占用和带宽量化收益最直接如果瓶颈是算力FLOPs剪枝和蒸馏更有效如果瓶颈是算子调度开销那图优化和算子融合才是关键。我做过一组对比实验在同一个 ResNet-50 模型上分别只做量化、只做剪枝、以及两者结合结果差异非常明显优化策略模型大小推理延迟Top-1 精度原始模型98MB120ms76.1%仅 INT8 量化25MB65ms75.6%仅结构化剪枝 30%69MB88ms75.2%量化剪枝18MB48ms74.8%可以看到量化对体积和延迟的收益最大剪枝对 FLOPs 的削减更明显但单独用都有天花板。组合使用才能把收益叠加起来。这也是 Model-Optimizer 这类工具存在的意义——它把多种优化技术串成一条流水线而不是让你手动一个个试。2.2 优化顺序为什么不能随便调这里有个非常关键的工程经验优化顺序错了效果可能直接归零。我踩过的最大的坑就是先剪枝再量化结果量化时校准数据分布完全变了精度崩了 5 个点。正确的顺序通常是先做图优化和算子融合再做剪枝然后做蒸馏如果需要最后做量化。原因在于图优化和算子融合不改变权重数值放在最前面最安全剪枝会改变权重分布如果先量化再剪枝量化时的 scale 就不准了量化放在最后是因为它需要基于最终的权重分布做校准校准数据才能反映真实推理时的数值范围。注意如果你的部署目标支持动态量化比如某些推理引擎的 PTQ 流程顺序可以稍微灵活但“量化最后做”这个原则基本不会错。2.3 工具选型自研脚本还是用现成框架我见过不少团队一开始想自己写量化脚本觉得“不就是把 float 转成 int8 嘛”。结果写到一半发现要处理 per-channel scale、要处理 bias 校正、要处理特殊算子回退最后代码量比模型本身还大。现成的 Model-Optimizer 类工具比如基于 PyTorch 的量化工具链、ONNX Runtime 的优化器、TensorRT 的构建流程已经把这些问题封装好了。我的建议是除非你有非常特殊的算子或硬件需求否则优先用成熟工具链。自研只适合两种情况一是目标硬件有专属指令集现成工具不支持二是你需要对优化过程做极细粒度的控制比如逐层指定不同的量化策略。3. 核心细节解析与实操要点3.1 量化PTQ 和 QAT 到底怎么选量化分两条路训练后量化PTQ和量化感知训练QAT。PTQ 快几分钟就能跑完适合快速验证QAT 慢需要重新训练几个 epoch但精度保持更好。我的经验法则是如果 PTQ 后精度掉点在 1% 以内直接用 PTQ如果掉点超过 2%再考虑 QAT。大部分视觉模型在 INT8 PTQ 下掉点都在 0.5% 到 1.5% 之间PTQ 基本够用。但 NLP 模型尤其是 Transformer 类PTQ 掉点可能很严重这时候 QAT 几乎是必选项。PTQ 的核心是校准Calibration。校准数据的选取非常关键我一般会从验证集里随机抽 500 到 1000 个样本确保覆盖所有类别。校准方法常用的是最小化 KL 散度或最小化 MSE前者对激活值分布更敏感后者对权重量化更友好。实测下来KL 散度在大多数 CNN 上表现更稳。# 以 PyTorch 为例PTQ 校准的典型流程 import torch from torch.quantization import get_default_qconfig, prepare, convert model.eval() model.qconfig get_default_qconfig(fbgemm) # 服务器端用 fbgemm移动端用 qnnpack model_prepared prepare(model) # 校准用代表性数据跑一遍不更新权重 with torch.no_grad(): for data, _ in calib_loader: model_prepared(data) model_quantized convert(model_prepared)这段代码看起来简单但有几个隐藏坑点prepare之后模型会插入观察器Observer这些观察器会记录激活值的 min/maxconvert时会把 float 算子替换成量化算子。如果你在prepare和convert之间做了任何改变模型结构的操作量化会直接失败。3.2 剪枝结构化 vs 非结构化别选错了剪枝分结构化剪枝和非结构化剪枝。非结构化剪枝是把单个权重置零理论上压缩率高但实际部署时如果没有稀疏计算库支持速度根本不会提升因为 GPU 还是按稠密矩阵算。结构化剪枝是直接砍掉整个通道或整个层虽然压缩率低一些但部署时是实打实的加速。我一般推荐如果目标硬件没有稀疏计算加速能力直接上结构化剪枝。非结构化剪枝只适合研究场景或者有专门稀疏推理引擎的情况。结构化剪枝的关键是“剪多少”。剪多了精度崩剪少了没效果。我的做法是逐层敏感度分析对每一层分别尝试剪 10%、20%、30%看精度变化然后给每层分配不同的剪枝率。对精度敏感的层少剪对精度不敏感的层多剪。# 简单的逐层敏感度分析伪代码 for layer in model.layers: for ratio in [0.1, 0.2, 0.3]: pruned_model prune_layer(model, layer, ratio) acc evaluate(pruned_model) print(f{layer.name} ratio{ratio} acc{acc})这个分析跑起来比较慢但一次跑完能省下后面反复试错的时间。我通常会在小规模数据上先跑一遍快速筛掉明显不行的配置。3.3 蒸馏什么时候值得做蒸馏是用一个大模型教师指导一个小模型学生训练。它的收益在于你可以用一个更小的模型达到接近大模型的精度。但蒸馏的代价是需要重新训练而且需要教师模型的输出 logits。我的判断标准是如果剪枝和量化后精度仍然不达标且你有充足的训练资源和时间再考虑蒸馏。蒸馏不是万能药它更适合“模型结构本身就有冗余”的场景。如果你的模型已经很小了蒸馏收益很有限。蒸馏的温度参数 T 很关键。T 越大软标签分布越平滑学生模型能学到的“暗知识”越多。但 T 太大也会导致梯度消失。我一般从 T4 开始试配合 alpha0.7软标签损失权重和 0.3硬标签损失权重。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装我以 PyTorch 生态为例因为它的量化工具链最成熟。基础环境需要 PyTorch 1.12 以上ONNX 1.12 以上以及 onnxruntime 或 TensorRT取决于部署目标。pip install torch torchvision pip install onnx onnxruntime pip install onnxsim # 用于简化 ONNX 图如果你要部署到 NVIDIA GPU还需要装 TensorRT。TensorRT 的版本要和 CUDA 版本匹配这个坑我踩过好几次——版本不匹配时编译能过但推理时直接报错。提示建议用 conda 建一个独立环境因为量化工具链对版本非常敏感。我试过在同一个环境里同时装 PyTorch 1.10 和 1.13 的量化工具结果 import 直接冲突。4.2 第一步导出 ONNX 并做图优化不管后面用什么推理引擎先把模型导出成 ONNX 是个好习惯。ONNX 是一个中间表示方便你做图级别的优化也方便跨框架部署。import torch.onnx dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}} )导出后用 onnxsim 做一次图简化把冗余的算子比如连续的 Reshape、Transpose合并掉。这一步通常能减少 5% 到 10% 的推理时间而且不损失精度。onnxsim model.onnx model_sim.onnx4.3 第二步量化校准与模型转换如果你用 ONNX Runtime 做部署量化可以直接在 ONNX 层面做。ONNX Runtime 提供了quantize_static接口支持 INT8 量化。from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(CalibrationDataReader): def __init__(self, calib_data): self.data calib_data self.iter iter(self.data) def get_next(self): return next(self.iter, None) quantize_static( model_inputmodel_sim.onnx, model_outputmodel_quant.onnx, calibration_data_readerDataReader(calib_loader), quant_formatQuantFormat.QDQ, # QDQ 格式兼容性更好 per_channelTrue # 逐通道量化精度更高 )这里per_channelTrue是个关键参数。逐通道量化会给每个通道单独算 scale比逐张量量化精度高不少但模型体积会稍微大一点。实测下来逐通道量化在 CNN 上精度能提升 0.3% 到 0.8%体积只增加不到 1%。4.4 第三步剪枝与微调剪枝通常要在训练框架里做因为需要重新训练来恢复精度。以 PyTorch 为例可以用torch.nn.utils.prune做非结构化剪枝或者手动做结构化剪枝。import torch.nn.utils.prune as prune # 对卷积层做 L1 非结构化剪枝 for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d): prune.l1_unstructured(module, nameweight, amount0.3) # 剪枝后需要微调几个 epoch 恢复精度 optimizer torch.optim.SGD(model.parameters(), lr0.001, momentum0.9) for epoch in range(5): train_one_epoch(model, train_loader, optimizer) evaluate(model, val_loader)微调的学习率要设小一点我一般用原始训练学习率的十分之一。微调 epoch 数不用太多3 到 5 个 epoch 通常就够了。如果微调后精度还是上不来说明剪枝率太高了需要回调。4.5 第四步推理引擎构建与性能测试最后一步是把优化后的模型放到目标推理引擎上跑。如果目标是 NVIDIA GPU用 TensorRT如果是 CPU用 ONNX Runtime 或 OpenVINO如果是移动端用 TFLite 或 NCNN。TensorRT 的构建流程比较重需要指定最大 batch size、最大工作空间大小、精度模式等参数。我一般会先跑一次 FP16 模式看看精度和速度再跑 INT8 模式对比。import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(model_quant.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_flag(trt.BuilderFlag.INT8) config.set_flag(trt.BuilderFlag.FP16) config.max_workspace_size 1 30 # 1GB engine builder.build_engine(network, config)构建完成后一定要做精度对齐测试用同一批输入分别跑原始模型和优化后模型对比输出差异。我一般要求最大绝对误差小于 0.01否则就要检查量化校准是不是有问题。5. 常见问题与排查技巧实录5.1 量化后精度掉太多怎么办这是最常见的问题。排查思路按优先级来第一检查校准数据。校准数据太少或者分布不均衡会导致 scale 估计不准。我一般要求校准集至少覆盖每个类别 10 个样本。第二检查是否有敏感层。某些层比如第一层卷积、最后一层全连接对量化特别敏感。可以尝试把这些层保持 FP16 或 FP32只量化中间层。ONNX Runtime 和 TensorRT 都支持混合精度量化。第三尝试逐通道量化。如果之前用的是逐张量量化改成逐通道通常能挽回 0.5% 左右的精度。第四如果以上都不行上 QAT。QAT 通过在训练时模拟量化误差让模型自己适应量化精度保持最好但需要重新训练。5.2 剪枝后模型速度没提升这个问题通常是因为用了非结构化剪枝但推理引擎不支持稀疏计算。解决办法有两个一是改用结构化剪枝直接砍通道二是换一个支持稀疏推理的引擎比如某些专门做稀疏加速的推理库。还有一个可能原因是剪枝后模型虽然参数少了但内存访问模式变差了导致实际延迟没降。这种情况在 GPU 上比较少见但在 CPU 上偶尔会遇到。解决办法是做一次内存布局优化或者换用更紧凑的数据格式。5.3 优化后模型在不同设备上表现不一致这是部署阶段最头疼的问题。同一个 ONNX 模型在服务器 CPU 上跑得好好的到了移动端就崩了。原因通常是算子支持不一致某些量化算子在移动端推理引擎里没有实现或者实现方式和服务器端不同。我的做法是在目标设备上做完整的精度和性能测试不要只在开发机上验证。如果发现某个算子不支持可以用 ONNX Runtime 的算子回退功能把不支持的算子退回 FP32。虽然会损失一点性能但至少能跑通。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉 3%校准数据不足或分布偏差检查校准集类别覆盖增加校准样本改用逐通道量化剪枝后速度无提升非结构化剪枝无稀疏加速检查推理引擎是否支持稀疏改用结构化剪枝模型转换失败算子不支持或版本不匹配查看转换日志中的算子名回退算子到 FP32 或升级工具版本推理结果与原始模型差异大量化 scale 估计错误对比中间层输出重新校准检查 per-channel 设置移动端崩溃算子不支持或内存不足查看设备日志减少 batch size回退不支持算子5.5 几个我踩过的坑第一个坑在prepare和convert之间做了模型结构修改。PyTorch 的量化流程要求这两步之间不能动模型结构否则观察器记录的统计信息会失效。我有一次在中间加了一个 ReLU结果量化后输出全是零。第二个坑校准数据用了训练集而不是验证集。训练集里有过拟合的样本分布和推理时不一致导致 scale 偏大或偏小。后来我固定用验证集的一个子集做校准问题就没了。第三个坑TensorRT 的 INT8 校准用了默认的熵校准。默认校准在某些模型上效果不好后来换成 min-max 校准精度提升了 1.2%。校准方法的选择要根据模型特点来没有绝对的最优解。第四个坑忽略了推理引擎的预热。第一次推理通常比后续推理慢很多因为要加载 kernel、分配内存。做性能测试时一定要先跑 10 到 20 次预热再取平均值。我有一次没预热测出来的延迟比实际高了 3 倍差点误判优化无效。6. 优化效果评估与迭代策略6.1 怎么定义“优化达标”优化不是越极致越好而是要满足业务指标。我一般会定三个硬指标模型体积、推理延迟、精度下限。比如“模型小于 50MB延迟小于 100ms精度不低于原始模型的 99%”。这三个指标定下来优化目标就清晰了。如果三个指标不能同时满足就要做取舍。我的优先级是精度下限 延迟 体积。因为精度不达标模型根本不能用延迟不达标用户体验差体积不达标最多是存储成本高一点。6.2 迭代优化的节奏我通常分三轮迭代第一轮快速验证。用 PTQ 加轻度剪枝跑一遍看指标差距。这一轮通常一两天就能完成。第二轮精细调优。根据第一轮的结果调整剪枝率、量化策略、校准方法。这一轮可能需要一周。第三轮极限压榨。如果前两轮还不达标上 QAT 和蒸馏或者换更激进的优化策略。这一轮时间最长但收益也最大。每一轮结束后都要做完整的精度和性能测试记录数据方便对比。我习惯用一个表格记录每轮的配置和结果这样后面回溯的时候一目了然。6.3 一个真实的优化案例最后分享一个我最近做的项目。目标是在一块算力有限的边缘芯片上部署一个目标检测模型。原始模型是 YOLOv5s体积 28MB延迟 200msmAP 0.38。第一轮PTQ INT8 量化体积降到 7MB延迟降到 110msmAP 掉到 0.35。精度不达标。第二轮分析发现是检测头对量化敏感把检测头保持 FP16其余层 INT8。体积 9MB延迟 120msmAP 回到 0.37。还是差一点。第三轮对主干网络做 20% 结构化剪枝然后微调 5 个 epoch再做混合精度量化。最终体积 6MB延迟 95msmAP 0.375。达标。这个案例说明单一优化手段往往不够组合拳才能达到最优效果。而且每一轮都要有明确的排查方向不能盲目试。提示优化过程中一定要保留每一轮的模型和配置方便回滚。我有一次优化到第三轮发现效果不如第二轮但第二轮的模型没保存只能重跑浪费了两天时间。6.4 后续可以扩展的方向如果你已经跑通了基本的量化加剪枝流程可以进一步尝试几个方向一是自动化搜索最优剪枝率用强化学习或遗传算法来搜二是针对特定硬件做算子定制比如把某些算子融合成硬件专属指令三是把优化流程集成到 CI/CD 里每次模型更新自动跑一遍优化和测试。我个人在实际操作中的体会是模型优化这件事工具只占三成经验占七成。同样的工具不同的人用效果可能差一倍。关键是要理解每一步背后的原理知道什么情况下该用什么策略而不是盲目套模板。踩过的坑越多判断越准。