做模型优化之前，我一直以为“优化”就是调参、换 loss、加正则这些训练阶段的动作。直到有一次，模型在训练集上漂亮得不行，到了部署端却因为体积和延迟被业务方直接打回，我才意识到：训练和部署之间隔着的不是代码，是两套完全不同的评价体系。后来我花了大半年时间搭了一个叫 Model-Optimizer 的小工具，专门解决“拿到一个训练好的权重之后，怎么把它压到能上线”的问题。这篇文章就把我踩过的坑、验证过的方法、以及工程化的取舍，原原本本写出来。
1. Model-Optimizer 只处理“拿到权重之后”的事：定位与边界
1.1 训练阶段优化和部署阶段优化，明明是两个问题
很多人会把模型优化理解成一件事，其实它是两个完全不同的阶段。训练阶段的优化，目标是让 loss 降得更低、指标刷得更高，手段包括改网络结构、调学习率、做数据增强、加正则项；而部署阶段的优化，目标是在尽量不损失精度的前提下，把推理速度提上去、显存压下来、体积缩小。这两个目标很多时候是互相拉扯的，训练时你觉得某个模块加了能涨两个点，部署时却发现这个模块让推理时间翻倍。
Model-Optimizer 的定位非常明确：它不碰训练过程，只接收已经训练好的权重文件，然后输出一个同样可用、但更小更快的模型。这样做的原因很实际——我接触过的很多项目里，训练代码和部署代码根本不在一个团队手里，你拿不到完整的数据管道，更不可能让人家为了部署重训一遍模型。所以工具必须设计成对训练脚本零依赖，给我一个 checkpoint，我就能干活。
1.2 我只碰权重、不碰训练脚本的设计理念
这个设计理念最初被同事吐槽过，说你光有权重没有训练细节，怎么做量化、怎么做蒸馏？但事实证明，这种“黑盒优化”反而逼出了工具的通用性。权重文件里能读到的信息其实够用：网络结构、每一层的参数分布、BN 层的均值和方差，这些都是优化的关键依据。
更重要的是，只面向权重可以让优化流程标准化。Model-Optimizer 的输入是一份模型文件加一份小规模校准数据集，输出是优化后的模型和一份优化报告。我不需要知道你的模型是在 PyTorch 还是 Paddle 里训的，也不需要关心你用了什么花哨的 loss。这种黑盒思路最大的好处是边界清晰，不会陷入“帮你炼丹”的泥潭，也方便后来接进自动化的模型发布流水线。
1.3 量化、剪枝、蒸馏、融合：四把剪刀的分工
模型压缩领域常用手段就那几样，Model-Optimizer 把它们组织成了一条流水线。量化是把 Float32 权重变成 Int8 甚至更低精度，直接砍掉显存占用和访存带宽；剪枝是删除不重要的通道或结构，让计算量直接降下来；蒸馏是用一个大模型当老师，教一个小模型把精度追回来；算子融合则是把多个相邻操作合并成一个，比如把 Conv 后面的 BatchNorm 融进前面的卷积计算里。
四者分工不同，但很多人忽略了它们的先后顺序。量化处理的是数值精度，剪枝处理的是结构大小，蒸馏处理的是精度补偿，融合处理的是计算图冗余。如果顺序不对，会出现量化把剪枝后的模型打崩、或者融合后又重新剪出无效结构这种尴尬情况。Model-Optimizer 里我固定了“先融合、再剪枝、然后量化、最后蒸馏补精度”的顺序，实测下来最稳。
2. 压缩管线从零搭建：四类操作怎么串起来不打架
2.1 量化校准：先从真实部署场景里拿 200 张图
量化这块最容易犯的错误，是随手拿训练集的几百张图做校准。训练集里的数据分布和部署现场的真实输入往往差得很远，尤其在光照、噪声、拍摄角度这些维度上。我见过一个分类模型，用训练集校准做 Int8 量化，精度损失不到 0.3%；换成现场采集的影像做校准，同一套量化参数直接掉了 2 个百分点。
Model-Optimizer 里的量化流程分三步。第一步是准备校准数据集，我建议至少取 200 张能代表线上分布的样本，不需要标注，但要尽量覆盖边界情况；第二步是收集每一层激活值的统计信息，分别记录 Min、Max，还有直方图分布；第三步才是根据这些统计信息计算量化参数。
下面这段代码是 PTQ 校准的一个核心片段，思路是用 DataLoader 跑若干 batch，收集激活分布：
import torch from torch.quantization import observer def collect_activation_stats(model, calib_loader, num_batches=20): model.eval() stats = {} def hook_fn(module, input, output): if isinstance(output, torch.Tensor): # 记录激活张量的全局极值，后续可以用直方图替代 stats[module] = (output.min().item(), output.max().item()) hooks = [] for name, module in model.named_modules(): if isinstance(module, torch.nn.ReLU) or isinstance(module, torch.nn.Conv2d): hooks.append(module.register_forward_hook(hook_fn)) with torch.no_grad(): for i, data in enumerate(calib_loader): if i >= num_batches: break model(data) for h in hooks: h.remove() return stats收集到分布之后，还要注意一个细节：per-tensor和per-channel的量化粒度差异很大。像卷积权重用per-channel量化，精度通常比per-tensor高一截，代价是实现复杂度稍微增加。而激活值因为逐层计算的原因，通常走per-tensor加asymmetric非对称量化就够用。
2.2 敏感层定位：量化后精度崩了，多数不是全局问题
很多人在做完整模型量化之后发现精度崩了，第一反应是怀疑量化算法本身不行，或者急忙换 QAT 重训。但实际上，绝大多数情况是模型里有少数“量化敏感层”，只要这几层保持较高精度，整个模型的精度就还在可控范围内。敏感层通常出现在输出层附近，或者某些 BN 层尺度异常卷积后面。
Model-Optimizer 里我实现了一个自动敏感层定位工具：先把所有层都量化成 Int8，然后逐层或逐块替换回 FP16/FP32，重新跑一遍验证集，观察精度回升幅度。精度回升最多的那几层，就是需要“特殊照顾”的敏感层。
“逐层验证”听起来简单，实际跑起来很花时间。所以我在工程上做了一层优化：先按模块分组，比如把 Backbone 的一组残差块作为一个整体，先按块级别做敏感性扫描；锁定敏感块之后，再进到块内部做细粒度定位。这样扫描轮数从几十轮降到了个位数，而且定位精度足够用。
2.3 结构化剪枝：按通道剪而不是按稀疏点剪
剪枝分为非结构化剪枝和结构化剪枝，两者的区别要掰开揉碎讲清楚。非结构化剪枝是把权重矩阵里绝对值接近零的元素直接置零，形成稀疏矩阵；这种方式压缩率很高，但绝大多数推理框架和硬件并不买账，因为稀疏矩阵的存储和计算需要专门支持，GPU 上的加速收益往往要到很高的稀疏度才显现。结构化剪枝不一样，它直接剪掉整个卷积核或整个通道，比如一个 64 通道的卷积层，剪成 48 通道，输出张量本身就变小了下一层的输入也变小，这种剪枝在任何框架里都能直接变现。
所以我坚持让 Model-Optimizer 只做结构化剪枝。判断一个通道是否重要，常见做法是看它对应卷积核的 L2 范数。范数小说明这个通道学到的特征能量低，删掉它影响相对较小。但这里有个容易被忽略的坑：如果前一层的后面接了 BN，通道的重要性必须结合 BN 的 scale 一起看，不然你会把一些范数小但 scale 很大的通道误删掉。
剪完之后还有一个“收尾动作”：把剪掉的通道从后续所有依赖层里同步移除。动手改过模型的同学都懂，这个传播过程最烦人，因为在 ResNet 这类带 shortcut 的结构里，通道数变了会影响相加操作的对齐。Model-Optimizer 里我用 PyTorch FX 把模型转换成 Graph 之后再剪，同步更新所有相关节点，大大减少了手工改模型的痛苦。
下面给你看一段用 FX 做结构化剪枝的示意代码，关键点在于利用module.named_modules找到 Conv2d，然后用torch.nn.utils.prune做重参数化：
import torch.nn.utils.prune as prune def structured_prune_conv(conv_module, amount=0.3): # 按输出通道计算 L2 范数，作为重要度分数 l2_norm = conv_module.weight.detach().abs().pow(2).sum(dim=(1, 2, 3)) k = int(conv_module.out_channels * amount) prune.ln_structured(conv_module, name="weight", amount=amount, n=2, dim=0) # 返回被保留的通道索引，供后续层传播 keep_idx = torch.where(l2_norm > l2_norm.topk(conv_module.out_channels - k).values.min())[0] return keep_idx.tolist()2.4 蒸馏：软标签温度怎么定，直接看实验曲线
蒸馏在 Model-Optimizer 里的作用，是给剪枝和量化后的模型做“精度回血”。它的思路是拿原始高精度模型当老师，让压缩后的小模型同时学习真实标签和老师模型输出的软标签。软标签的好处在于它携带了类别之间的相似度信息，比如一张图在模型眼里更像“猫”还是更像“狗”，这些信息对提升小模型的泛化能力很有帮助。
蒸馏的关键参数是温度 T。温度越高，软标签的分布越平滑，类别间的精细差异被放大；温度太低，软标签退化成接近 one-hot，蒸馏的作用就淡了。我做过一组对比，同一个剪枝后模型，T=1 时精度最多恢复 0.8%，T=3 时恢复 2.1%，T=7 时反而掉到只恢复 1.2%。这说明温度太高会把软标签变成噪声。我的建议是先用 T=3 起步，观察验证集损失的变化，再在 2~6 之间做一轮小范围搜索，别迷信某个固定值。
蒸馏的训练方式也影响结果。student 模型不要从头训，很多工具默认从随机初始化开始蒸馏，这是错误示范。Model-Optimizer 的做法是先加载剪枝量化后的权重，当成初始权重，再去跟着 teacher 蒸馏。这样做既保留了大模型原有的知识，又能把失真修正回来。
2.5 算子融合：先融合再校准，还是先校准再融合
算子融合的经典案例是 Conv+BN。训练时 BN 对卷积输出做归一化，但推理时 BN 本质上是一组线性变换，完全可以折叠到卷积的 weight 和 bias 里。融合之后少了一次张量读写，对推理速度的提升非常直接，尤其在小模型上更加明显。
关于融合和校准的顺序，我专门做过 AB 对比。如果先做 Int8 校准再做融合，那么校准统计到的激活分布里混合了融合前的中间状态，等真正融合后计算路径变了，统计信息就不完全匹配；如果先融合再校准，统计的就是部署时真实会走的计算路径，量化精度更稳。所以 Model-Optimizer 的管线顺序是“先融合，后校准，最后量化”。
融合动作本身也要小心 weight 的数值范围变化。Conv+BN 融合后，卷积的 weight 数值会变大一些，因为要乘上 BN 的 scale。这个在 Float32 下完全没问题，但如果你在融合之后做 Int8 量化，超大绝对值的权重会挤压有效量化区间，反而带来精度损失。处理办法是把融合放在张量极值统计之前，让量化参数对融合后的真实分布负责。
3. 实测记录：体积、延迟、精度之间的真实拉扯
3.1 一个检测模型的压缩全程：37MB 压到 9.8MB
项目里有一个基于 MobileNet 骨干的目标检测模型，训练后权重 37MB，在边缘设备上的推理延迟是 46ms，显存占用大概 280MB。业务方的要求是模型小于 15MB，延迟低于 25ms，显存尽量别超过 120MB，同时 mAP 下降控制在 0.03 以内。
我把这个模型丢进 Model-Optimizer 走了一遍全流程，结果如下表：
| 阶段 | 模型体积 | 推理延迟 | 显存占用 | mAP |
|---|---|---|---|---|
| 原始模型 | 37MB | 46ms | 280MB | 0.312 |
| 算子融合后 | 36MB | 39ms | 245MB | 0.311 |
| 结构化剪枝 30% 后 | 21MB | 28ms | 165MB | 0.298 |
| Int8 量化后 | 9.8MB | 21ms | 97MB | 0.287 |
| 知识蒸馏回血后 | 9.8MB | 21ms | 97MB | 0.301 |
最直观的感受是，剪枝把体量真正降下来，量化把最后一段性能挖出来，蒸馏把精度损失补回来，三者各干各的活。很多人以为量化是把 37MB 变成个位数兆的主角，但这组数据说明，真正的大头是剪枝。融合在这里贡献不大，但它保证了后续量化时模型的数值路径是最简的，属于看不见的助攻。
3.2 量化精度崩盘的完整排查链路
另外有一次没那么顺利。一个文本分类模型，全模型做 Int8 量化之后，准确率从 91.2% 直接掉到 82.7%。这个跌幅明显不正常，光调量化参数已经救不回来。我决定用 Model-Optimizer 的敏感层扫描功能做一次系统排查，整个过程可以作为“量化崩盘排查”的参考模板。
第一步，先给每个 Transformer 层单独做量化模拟，其他层保持 Float32，跑一遍验证集。结果显示前两层几乎不掉点，中段有 0.5% 左右的损失，但最后一层的全连接层单独量化后掉了 4.8%。第二步，把最后一层单独改回 FP16，做混合精度量化，准确率恢复到了 90.5%。第三步，再去看前一层的输出分布，发现最后一层的输入张量里存在明显的离群点，最大值是第三四分位数的 40 倍左右，这正是经典的量化敏感场景。
最后我给的方案是：把最后一层和它前面的 GELU 层一起保留 FP16，同时给 GELU 输出按绝对值截断，把极端离群点削掉一部分。经过这两步，准确率恢复到了 91.0%，模型体积比全 Int8 多了不到 0.5%，完全可以接受。
这个案例说明，Int8 量化不是一刀切，真正的功力体现在“哪些层该让一步”的判断上。Model-Optimizer 之所以把敏感层定位做成内置能力，就是因为在真实项目里，这种问题根本没法靠猜。
3.3 性能测量口径：FPS、P99 延迟和内存峰值都要看
模型优化做完，性能验收又是一道坎。我在 Model-Optimizer 的测试工具里固定了三个指标：平均延迟、P99 延迟和内存峰值。只看平均延迟会骗人，因为很多设备上模型首次推理会触发显存分配和算子编译，平均延迟会被少部分慢请求拉低或者掩盖抖动。
标准做法是先跑 50 轮 warmup，让框架完成预热，然后再记录后面 200 轮的数据。warmup 这一步很多人忽略，但它的影响不是一般的大。同一个优化后的模型，不 warmup 时测出来的延迟可能比 warmup 后高一倍，尤其在使用 TensorRT 或 GPU 图模式部署时。
测试环境也要固定。CPU 需要锁核数、关超线程，GPU 需要固定频率，不然对比结果没有意义。Model-Optimizer 里我写了一个环境检测脚本，把 CPU 型号、GPU 型号、驱动版本、PyTorch 版本和实测算子 backend 全部记录到报告里，方便复盘时对齐环境。
4. 工具工程化最容易低估的三个决策
4.1 为什么中间表达选了 FX Graph 和 ONNX
写 Model-Optimizer 之前，我一直在用逐模块替换的方式做模型修改，比如手动遍历named_modules()替换 Conv2d。这种办法在简单模型上能跑，但遇到多分支结构和动态控制流就头大。后来我切到 PyTorch 的 FX，把 Python 模型转成一张图，所有算子变成图上的节点，做融合和剪枝就不再是改层级结构，而是改图结构。
选用 ONNX 作为导出端的中间表达，是为了让优化结果不被 PyTorch 运行时绑死。ONNX 本身是一个计算图描述格式，很多推理引擎都能加载它，TensorRT、ONNX Runtime、OpenVINO 都有对应的解析入口。所以 Model-Optimizer 的输出不只是一个 PyTorch 模型文件，还有一个配套的 ONNX 文件和部署 JSON，后者描述了优化过的算子、保留精度的层、以及剪枝索引。
选型时也要注意 FX 的限制。它对动态控制流支持不好，遇到 Python 层的if或者动态 shape 会抛异常。但只要模型不涉及这些，FX 的性价比非常高。如果你手里的模型结构很特殊，FX 走不通，就只能在 ONNX 层面做 graph transform，那是另一套工作量。
4.2 可配置、可复现、报错不甩锅
工具化之后，最重要的不是功能多，而是可配置和可复现。我给 Model-Optimizer 设计了一个 YAML 配置文件，所有优化选项都在里面，包括剪枝比例、量化方式、温度参数、保留敏感层的名单。这样不同模型、不同硬件，只需要切换配置，不需要改代码。
经常有人问，为什么不用参数列表直接传？因为优化一个模型往往要跑十几个实验，不同实验之间的参数差异通常只有一两项，配置文件可以整体留存，方便比较。我在配置里还加了seed字段，固定随机种子后，剪枝时通道选择、蒸馏时的数据打乱都能复现。这看起来是个小事，实际做实验时帮了大忙。
报错处理我也花了心思。Model-Optimizer 在跑优化流程时分为多个阶段，任何阶段失败，都会在报告里标明失败发生在哪个模块、输入什么配置、权重版本是什么，而不会给一个笼统的 stack trace。只有让错误信息精确到“哪一步错了”，工具才真正适合团队协作，而不是只自己一个人用得顺手。
4.3 后续想做的：自动压缩方案搜索和硬件适配
Model-Optimizer 目前的一个明显短板，是压缩方案的取舍得靠人工经验判断。比如某个模型是剪 20% 再量化，还是直接量化不剪枝，不同模型结论不一样。人工试一遍确实能出结果，但遇到新模型、新硬件，效率很低。
所以下一步我想在工具里加入一个自动搜索模块：给定一个目标延迟或目标体积，自动尝试剪枝比例、量化粒度、敏感层保留策略的不同组合，然后用一组评测指标打分，找出当前硬件上最合适的压缩配置。这个思路跟超参搜索类似，只不过搜索空间是压缩策略。
硬件适配也是必须做的。同样一个 Int8 模型，在 GPU 上走 TensorRT，和在一台只支持 Int8 的 FPGA/NPU 设备上，能利用的算力完全不同。Model-Optimizer 应当在配置里感知部署硬件的能力，比如是否支持混合精度算子、是否对某些算子做了特殊加速，再决定优化策略。这一步短期不一定能覆盖很多设备，但至少要在工具里预留好接口。
4.4 跑完这些优化流程后，我更愿意强调的几件事
用 Model-Optimizer 做了大半年优化，我最大的感受是：模型压缩不是纯粹的数学题，也不是纯粹的工程题，而是两者的黏合。算法上要为每层参数的分布做分析，工程上又要为不同推理引擎留好后路。只重理论的人容易把压缩方案设计得“好看但跑不快”，只重工程的人又容易陷入用上线测方案的死循环里。最好的状态是先有一点量化感知、有一点图优化意识，再用工具把重复劳动省下来。
另一个体会是：永远保留一条“回滚路径”。优化前的原始模型一定要留好，优化后的模型也要记录每个阶段的产物，包括融合后版本、剪枝后版本、量化后版本。这样上线后如果发现某个指标异常，可以一步步缩小问题范围。Model-Optimizer 的所有中间产物都会带上阶段标记和 Git 哈希，确保任何时候都能回溯到对应代码版本。
对我个人来说，这项目最大的收获不是模型变小了、延迟变快了，而是让我接受了一个道理：好的工具不是替你做决定，而是把决定背后的代价展示得足够清楚。减掉哪些通道、量化哪些层、保留多少精度，这些选择从来不是白拿的，每一次体积下降都对应着一部分精度妥协。工具的价值，就是把这种妥协从“看不见的黑盒”变成“看得见的报告”。这个思路，以后做任何涉及资源取舍的工具，我都觉得适用。
