NNI剪枝与量化实战：模型部署中的压缩优化指南

1. 模型训练完成之后，部署为什么还会卡壳

做部署优化的朋友应该都有过这种体验：模型在训练机上跑得好好的，精度看着也满意，一旦换到推理环境，显存、延迟、带宽全部开始“抗议”。这其实不是模型的代码出了问题，而是我们训练阶段默认的资源条件太宽裕了，上线之后要面对的约束完全是另一回事。一提模型部署里的NNI剪枝和量化，很多人的第一反应是“又要踩一堆坑了”，但它确实是我在模型压缩路上用得比较顺手的工具组合之一，值得认真拆开讲一讲。

先说清楚部署现场最常见的三座大山。第一是显存，服务端单卡显存是固定的，模型参数越多、中间激活越大，能塞进去的batch就越小，直接影响吞吐；第二是延迟，推理延迟不只是算力问题，更常见的是访存瓶颈，参数越多，要从显存里搬的数据就越多；第三是带宽，尤其是端侧场景，模型文件太大意味着下载慢、更新成本高，用户根本等不起。训练时没人关心这些，但上线那一刻全部变成硬指标。

剪枝和量化之所以经常被放在一起提，是因为它们俩解决的是不同维度的冗余。剪枝去掉的是结构上的冗余，把不太重要的连接、通道、卷积核删掉；量化去掉的是数值表示上的冗余，把32位浮点换成8位甚至更低的整数来存和算。一个模型往往既结构臃肿，又数值表示过度精细，所以这两步往往要配合起来用。

我为什么专门拿NNI出来说？因为它不是某个单一压缩算法，而是一个把剪枝、量化、蒸馏、敏感度分析都打包好的工具链。你不需要自己维护剪枝mask、逐层处理scale和zero-point这些容易出错的底层逻辑，只要告诉它“我打算剪哪类层、剪多少比例、量化到几位”，它就能把流程跑起来。对于想快速验证压缩方案的团队来说，这个抽象层能省掉大量重复造轮子的时间。当然，工具再方便，你也得知道它内部在做什么，否则出了精度问题根本无从排查，后面所有章节都围绕这个主线展开。

2. NNI剪枝原理拆解：哪些参数可以被安全移除

2.1 非结构化剪枝与结构化剪枝：先想清楚部署端吃哪一套

剪枝最根本的分叉点在于：你剪完之后的模型，底层推理引擎到底认不认。非结构化剪枝会把权重张量里绝对值很小的单个参数直接置零，得到的是一个高度稀疏的权重矩阵。这种方案的优点是剪枝粒度细、精度损失通常更小，缺点是通用硬件和推理引擎很难直接受益——稀疏矩阵要真正变快，往往需要专门的稀疏推理库去跳过零值计算，否则模型文件看着小了，跑起来还是原来的速度。

结构化剪枝则是把整个卷积核、整个通道、或者整层输出直接删掉。比如一个卷积层的输出通道数从128变成96，那它下游所有层的输入通道也随之改变，张量形状是实实在在变小了。对于ONNX Runtime、TensorRT这类部署后端来说，这种形状上的缩小是天然友好的，模型文件变小，访存变少，计算量也直接下降。所以我的建议是：除非你确定目标后端有成熟的稀疏加速方案，否则做部署优化一律优先选结构化剪枝。

NNI里这两类都有对应实现。LevelPruner按权重绝对值大小做非结构化置零，通常适合做baseline或者学术对比；面向落地，我更常用L1FilterPruner、FPGMPruner这类结构化剪枝器。选型逻辑后面单独说。

2.2 NNI常见剪枝器与我的选型习惯

NNI的剪枝器有很多，但核心思想都绕不开“怎么判断一个参数不重要”。我按自己的使用频率整理了一张对照表：

L1FilterPruner的逻辑很好理解：一个卷积核的L1范数小，说明这个filter整体数值偏小，对输出的贡献大概率也偏弱，删掉它对模型影响最小。它的速度快、效果好，所以是我默认的第一选择。

FPGMPruner我多说一句。它不去看单个卷积核范数大小，而是找滤波器之间的“几何中位数”。如果一个filter和其他filter在特征空间里靠得特别近，说明它携带的信息高度冗余，即使它本身范数不小，也可以安全移除。这个思路在有些L1/L2失效的场景里反而更稳，尤其是当剪枝比例比较高的时候。

另外，SlimPruner是另一条路：它是给BN层的γ加L1正则，训练过程中很多通道的γ会被压到接近0，剪枝时直接删掉γ接近0的通道。优点是可以自动发现冗余通道，缺点是你必须从头做稀疏训练，没法在现成模型上直接套用。如果项目允许重新训练，可以试；如果想快速压缩一个已经训好的模型，我更建议走L1FilterPruner或FPGMPruner路线。

2.3 剪枝比例怎么配：敏感度分析先行，别搞一刀切

很多新手最容易犯的错，是给所有卷积层统一设置一个sparsity，比如每层都剪40%。但不同层对剪枝的耐受度差异非常大。有的层删掉一半通道精度几乎不动，有的层动几个通道精度就崩。神经网络里的“冗余”分布是不均匀的，就像家里用电，有些回路负载很轻，有些回路一动就跳闸。

NNI提供了敏感度分析模块，可以对每个卷积层逐一扫描不同剪枝比例，记录验证集精度的变化曲线。我的习惯是先跑一遍这个分析，生成一张逐层的“精度-稀疏度”表，然后在精度掉点不太明显的范围内，给每层单独指定sparsity。这样一来，本来只能全局剪30%的模型，可能在大部分层上能剪到50%，只有少数敏感层少剪甚至不剪。

除了逐层分析，还有两个层我一般会直接放进豁免名单：第一层卷积和最后的预测头。第一层直接接触原始输入，它的输出特征会被所有下游层复用，剪坏了对全局伤害特别大；最后的分类层负责把特征映射到具体的类别语义，它一旦损失信息，精度掉得也很快。在config_list里用exclude_op_names或者按层名匹配把它们排除掉，省心得多。

3. NNI量化原理与两种落地路径：PTQ和QAT

3.1 低比特量化的本质：把浮点数装进更小的整数盒子

量化这个词听起来很神秘，本质其实特别朴素：用一个有限整数集合去近似原来的浮点分布。一个浮点数的32位里，并不是每一位都对最终结果有同等价值，高位决定数量级，低位大多是无关紧要的细节。8位整数虽然只提供了256个档位，但如果映射范围选得好，完全可以把绝大多数关键信息保留下来。

映射过程需要两个参数：scale（缩放因子）和zero_point（零点偏移）。scale决定一个整数单位代表多大的浮点范围，zero_point确保浮点里的0在整数域里落在正确的位置，避免补零操作出现偏移误差。按映射方式，又分成对称量化和非对称量化：对称量化把正负范围对齐到零点两侧，数学简单、硬件友好，但负半轴可能浪费一些档位；非对称量化允许零点是任意整数，能更充分地利用256个档位，代价是计算时多一步偏移修正。

还有一个特别容易被忽略的概念：per-tensor量化与per-channel量化。不同输出通道的权重分布范围可能有几倍差距，如果整个张量共用一个scale，小范围通道的量化精度会被大范围通道拖累。所以权重我基本都配成per-channel，每个输出通道单独算scale；激活值则更常使用per-tensor，因为硬件对激活的per-channel支持少，而且激活分布相对规整。

3.2 PTQ与QAT：要不要重新训练，是这两条路的分水岭

NNI把量化实现分成两条主线：PTQ（训练后量化）和QAT（量化感知训练）。它们不是同一件事，选错路径轻则多花几天时间，重则精度反复上不去。

PTQ最明显的优势是快。你不需要重新训练模型，只需要准备一小批校准数据，让模型正常跑几次前向，统计出每一层激活值的分布范围，再根据统计结果计算scale和zero_point，然后把权重直接转成整数。整个过程从配置到完成，通常几十分钟就能搞定，精度损失在多数任务上也能控制在可接受范围内。缺点是它完全没给模型“适应”低比特表示的机会，如果原模型数值分布很刁钻，PTQ的精度可能一下子就掉出接受线。

QAT的思路正好反过来：在训练过程中把“量化误差”模拟进去，让网络在优化时就意识到自己将来会以低比特形式推理，主动调整参数分布来抵抗量化带来的扰动。NNI的QAT_Quantizer会在模型里插入伪量化节点，前向时把张量“假装”量化一遍再反量化回去，反向时用直通估计器近似梯度，让训练正常更新参数。效果通常比PTQ更稳，但代价是你需要重跑一遍训练或微调流程，时间成本明显更高。

我的选择标准很简单：模型不是特别敏感、后端要求又不苛刻时，先上PTQ看结果；如果精度差了0.5个点以上，再切换成QAT做精调。用表格对比会更直观：

3.3 量化配置常见参数与BN折戟点

NNI的量化配置本质上是一个config_list，常见参数围绕quant_types、quant_bits、op_types展开。举例来说，你可以指定只量化Conv2d和Linear层的weight与input，并把精度都设在8位；也可以激进一点把weight压到4位，但激活通常保持在8位以上，否则精度劣化非常快。

还有一个部署老手都知道的细节：量化之前必须处理BN层。BN在训练时是对每个通道做归一化，它的running_mean和running_variance会直接影响激活值的分布范围。如果不把BN层“折叠”进卷积层，量化时统计到的激活范围会带上BN的随机波动，导致scale选得很不靠谱。更麻烦的是，BN在推理时本质上是一连串额外的乘加操作，保留它对性能也是负优化。NNI系列工具在量化流程里通常会处理BN折叠问题，但你自己心里要清楚这件事的存在，否则看到某些层量化效果异常时会摸不着头脑。

4. 完整跑通：剪枝、量化、导出的一次实操记录

4.1 先定一个模拟项目X：基准模型与部署目标

不考虑具体场景谈压缩都是耍流氓。我习惯用一个虚拟的模拟项目X来做演示：假设你有一个图像分类服务，模型是一个带残差块的卷积网络，在公开分类数据集上训练到验证集精度约90.8%。训练环境下一切正常，但部署目标要求模型文件不超过10MB，单张图片推理延迟要压到8毫秒以内，同时显存占用不能超过200MB。这个指标单独看都不算离谱，但合在一起，不做压缩基本不可能满足。

我把这个项目叫模拟项目X，就是为了强调：具体数字不重要，你要掌握的是判断链路。不同模型、不同硬件、不同部署后端，压缩后的收益曲线差别很大，但方法和步骤是通用的。

在动手之前，我会先记录三个基线数字：模型文件大小、单次推理延迟、显存峰值。这三个数字是后续所有操作的对照基准，没有它们，你根本无法判断剪枝到底有没有生效。训练精度也要留好，因为压缩的目标不是“精度完全不变”，而是“精度损失在业务可接受范围内”。

4.2 剪枝实操：配置、执行与微调

基于上面的判断，我选择先做结构化通道剪枝。以NNI常见版本为例，示意代码如下：

import torch from nni.compression.pytorch.pruning import L1FilterPruner # 先定义好要剪哪些层、剪多少 config_list = [ { "op_types": ["Conv2d"], # 只针对所有Conv2d层 "sparsity": 0.35, # 默认剪35%的通道 "exclude_op_names": [ # 豁免敏感层 "input_conv", # 第一层卷积保留 "final_fc", # 最后的预测头保留 ], } ] pruner = L1FilterPruner(model, config_list) model = pruner.compress() # 进入微调阶段，让剩余参数重新适应 for epoch in range(10): train_one_epoch(model) validate(model) # 如果是迭代剪枝场景，每个epoch之后可能需要更新mask # pruner.update_epoch(epoch) torch.save(model.state_dict(), "pruned_model.pth")

这里要说明两点。第一，不同NNI版本的API命名和调用方式会有差异，我上面写的只是常见2.x版本的风格，具体以你使用的官方文档为准，核心思路是一样的。第二，剪枝完成后千万不要直接就拿去部署，mask把通道删了，但剩下的参数还没有收敛到新的最优状态，至少要跑几个epoch的微调，把精度拉回来一些。

微调结束之后，我惯用的做法是再拿验证集做一次完整评估，记录剪枝后的模型文件大小、延迟和显存。如果精度已经回到了可接受范围内，就继续进入量化环节；如果精度掉得太多，回到敏感度分析那张表，把剪得最狠的那几层再放松一点。

4.3 量化实操：先用PTQ快速验证，再用QAT精调

量化环节我一般分两步走。第一步用PTQ快速看上限，第二步如果精度不达标，再切到QAT。

PTQ的示意流程是这样：准备150到500张和线上分布接近的校准图片，让模型正常前向推理，统计每一层激活值的min和max范围，然后计算出scale和zero_point。NNI里PTQ_Quantizer封装了大部分流程，你需要负责的主要是校准数据loader。

QAT的示意配置如下：

from nni.compression.pytorch.quantization import QAT_Quantizer qat_config = [ { "quant_types": ["weight", "input"], "quant_bits": {"weight": 8, "input": 8}, "op_types": ["Conv2d", "Linear"], "quant_strategy": "symmetric", "per_channel": True, # 权重按通道量化 } ] qat_quantizer = QAT_Quantizer(model, qat_config) model = qat_quantizer.prepare() # 在压缩后的模型基础上做几轮量化感知微调 for epoch in range(5): train_one_epoch(model) validate(model) # 导出量化后的模型和量化参数 qat_quantizer.export_model( model_path="qat_model.pth", calibration_path="qat_calibration.json", )

我比较推荐在做完剪枝和微调之后，先原地接一层QAT，而不是在原始模型上直接QAT。原因后面会细说，简单讲就是剪枝已经把模型结构调整过了，量化感知训练应该基于这个调整后的结构去适应，顺序错了会产生额外的精度损耗。

4.4 导出并验证：模型体积、延迟、显存一个都不能少

量化训练完成后，模型导出是个容易出错的地方。如果你需要ONNX格式，可以用torch.onnx.export导出，但要注意导出的到底是模拟量化模型还是真正的整数模型。模拟量化模型里还是浮点运算，只不过数值经过伪量化节点模拟了误差；要获得真正的int8收益，还需要把QDQ节点转换成后端能识别的int8格式，或者在支持QDQ优化的引擎里直接执行。

我习惯在验证阶段做一张对比表，把每次改动后的数字放一起看。以下是一组我模拟项目X里的示例数据，用来展示趋势，不代表每个项目都这样：

这个模拟结果说明，剪枝和量化叠加之后，体积和延迟都有了明显下降，精度损失在一个可接受的范围内。但我要提醒一句：延迟和显存数字必须用你实际部署用的推理后端去测，不能只看PyTorch里的计时。PyTorch的Eager模式没有做太多算子融合优化，数值可能和实际部署环境差非常多。

5. 我在实操中踩过的坑和修复思路

5.1 BN层在剪枝和量化里都是不稳定因素

我印象最深的坑就是剪枝之后完全不微调，直接拿模型去验证，精度掉得一塌糊涂。后来排查发现一个关键问题：剪掉通道后，剩下的BN统计量还是旧值，running_mean和running_variance对应的是原来完整的通道集，这个错位会让每一层输出的分布都发生偏移。正确做法是剪枝之后至少让模型跑几轮微调，哪怕学习率设得很低，也能让BN统计量慢慢校正回来。

量化阶段同样要警惕BN。如果BN不折叠紧贴进卷积层，量化时scale的统计就会跟着BN的数值波动走，出来的量化参数可能非常不稳定。特别是用PTQ的时候，校准过程中BN状态和推理状态不一致，统计出来的激活分布会带着“训练味”，上线推理时反而不准。处理方法是确保导出部署前网络里没有“游离”的BN层，该fold的fold，该合并的合并。

5.2 敏感层手动豁免比调稀疏度更管用

最开始我习惯图省事，一个sparsity配到底。剪完之后发现精度掉得最多的往往就是那几个我压根没想到的层——第一层、残差连接出口、最后的分类器。这些位置的共同点是都有“汇聚”作用：第一层把原始输入转换到特征空间，最后的分类层把特征压成类别概率，任何信息损失都会被放大。

后来我改成在config_list里直接排除这些层，效果立竿见影。不是说它们完全不能剪，而是除非你的模型冗余度真的很高，否则保护它们比多剪几个通道划算得多。如果敏感度分析工具能给出每层的耐受曲线，优先看哪些层的曲线“掉得晚”，那些层才是真正可以放手去剪的地方。

5.3 模型文件变小，不代表运行时显存真的降了

这是另一个容易误判的点。剪枝后如果权重存储成稀疏格式，文件体积确实可以大幅下降；但如果推理引擎没有真正利用稀疏性，计算时还是会按稠密矩阵去跑，显存和延迟都纹丝不动。结构化剪枝虽然直接改张量形状，通常能带来真实收益，但如果剪枝比例太低（比如只剪10%到15%），后端可能连底层算子的执行分支都不会切到更快的那条。

所以我不太信“磁盘文件小了多少”这个指标，更看部署环境里用profiler量出来的真实显存和端到端延迟。有时候模型文件小了50%，线上延迟只降了5%，这种情况说明瓶颈可能不在参数存储而在算子调度或访存模式上，需要回到结构设计去解决。

5.4 校准集选不好，量化精度容易出现“假健康”

PTQ的校准环节看起来只是让模型在数据上跑一遍，但校准集选错了，后患无穷。我见过有人直接用训练集去做校准，量化完在训练集上测精度觉得没问题，结果上线之后在线数据一进来，精度立刻下滑。这不是玄学，是校准分布和线上分布不一致的必然结果。

正确的校准集应该尽量贴近线上真实输入：如果线上是摄像头拍的图，就准备摄像头拍的图；如果线上有大量低光照样本，校准集就不能全是明亮清晰的图。数量上通常200到500张足够，多了浪费计算时间，少了统计不出稳定的分布。另外，激活值里如果出现极端离群点，min/max的统计方式会把量化范围撑得很大，普通数值区间的精度就被牺牲掉了。碰到这种情况，我一般换成基于百分位的范围统计，把最极端的那0.1%的离群点忽略掉，整体量化精度反而更高。

5.5 先剪后量还是先量后剪：我坚持先剪后量

在剪枝和量化的顺序上，我踩过一次反向操作的坑。先做量化再做剪枝，剪枝过程对梯度噪声更敏感，量化引入的误差就像放大器一样，会把剪枝判断干扰得到处是毛刺。而且量化感知训练本身已经让模型适应了低比特表示，这时候再剪掉结构，相当于在一个“已经适应某种数值环境”的模型上再动外科手术，两部分损失可能会互相叠加，不是相加而是放大。

先剪枝后量化则顺得多：剪枝先把结构冗余清掉，微调恢复精度；量化再在已经精简的结构上做数值压缩，模型有了前一步微调的缓冲，对低比特的适应能力也更好。如果是QAT流程，我会把它放在剪枝微调完成之后，当作最后一轮“适应性训练”，这样每一步的变量都是独立的，出了问题也容易定位。

6. 压缩不是部署前一天才做的事

6.1 把压缩纳入模型迭代的常规环节

我越来越倾向于一个观点：剪枝和量化不应是上线前临时抱佛脚的补救措施，而应该是模型迭代的一等公民。如果你每个版本训练完之后都立刻跑一遍敏感度分析和压缩验证，时间长了，你会积累出一套属于自己模型的“压缩画像”——哪几层冗余高，哪几层碰不得，量化后精度掉多少是可预期的。有了这套画像，后续每次迭代几乎都能预判出压缩后的效果，不用再临时慌了手脚。

当然，要做到这一步，前提是流程足够自动化。这也是NNI这类工具的价值所在：它把剪枝、量化、敏感度分析这些环节封装成可重复执行的流程，你完全可以把它嵌进自己的模型训练流水线里，而不是每次都在交互式环境里手动敲。

6.2 最后分享一个我常用的验证习惯

我最后想分享一个看起来很小、但帮过我很多次的习惯：压缩前后永远做三件事。每次动手之前记录baseline的精度、模型体积、端到端延迟；每次改动只控制一个变量，要么只剪枝、要么只量化，绝不两个动作同时上；每次对比都在同一个验证集上做，并且把压缩后模型和原始模型的输出在错误样本上逐类对比，看损失集中在哪些类别上。大多数情况下，你会发现精度损失不是均匀分布的，而是集中在一两个特定类别上——这个信息能直接指导你下一步应该放松哪一层，而不是盲目地全局降低压缩力度。

回头再看，NNI剪枝和量化不是什么魔术，它只是把压缩这件事从手工作坊变成了流水线作业。真正决定压缩效果的，仍然是你对模型结构的理解：哪些层冗余、哪些层敏感、数值分布长什么样。工具负责把想法落地，而你负责想清楚在哪里下刀。最后还得接受一个现实——没有哪种压缩是完全没有代价的，剪枝和量化本质上是用一点精度换体积、延迟和显存，关键是找到代价最小、收益最大的那几刀。