4、剪枝基础：结构化剪枝与非结构化剪枝的定义、优缺点、典型应用
模型剪枝是Edge AI部署中最常用的模型压缩手段之一，其核心思想是移除神经网络中冗余的权重、通道甚至层，从而降低模型的计算量、内存占用和功耗。然而，剪枝并非单一操作，根据移除粒度的不同，业界将其划分为结构化剪枝与非结构化剪枝两大流派。这两种方法在实现原理、硬件友好度、压缩效果以及部署难度上存在显著差异。理解它们的本质区别，是后续学习稀疏化训练、量化感知剪枝以及端侧推理引擎优化的前提。本节将从定义出发，深入剖析两者的优缺点，并结合实际部署场景给出选型建议。
上图展示了两种剪枝策略在决策路径上的根本分歧。非结构化剪枝追求极致的参数压缩，但代价是产生不规则的内存访问模式；结构化剪枝则牺牲部分压缩率，换取对现有硬件计算管线的高度兼容。下面我们逐一展开。
4.1 核心原理：从权重到通道的粒度跃迁
非结构化剪枝（Unstructured Pruning），又称细粒度剪枝，其操作对象是神经网络中的单个权重参数。在训练或微调过程中，通过设定阈值或基于梯度幅度，将绝对值小于阈值的权重直接置为零。例如，一个卷积层包含256×256×3×3的权重矩阵，非结构化剪枝可能将其中40%的权重置零，但这些零值随机散布在矩阵中，不形成连续区域。
结构化剪枝（Structured Pruning），则是在更高维度上操作，包括：
- 通道剪枝（Channel Pruning）：直接删除整个输入或输出通道，对应卷积核的某一维。
- 滤波器剪枝（Filter Pruning）：删除整个卷积滤波器，即输出通道的一个切片。
- 层剪枝（Layer Pruning）：移除冗余的残差块或Transformer层。
从数学本质看，非结构化剪枝产生的是稀疏矩阵，而结构化剪枝产生的是低秩或窄矩阵。前者需要稀疏矩阵乘法库（如cuSPARSE、Intel MKL稀疏接口）才能发挥加速效果，后者则可以直接利用通用的GEMM（通用矩阵乘法）优化。
关键区别：非结构化剪枝改变的是矩阵中“值”的分布，矩阵维度不变；结构化剪枝改变的是矩阵的“形状”，维度直接缩小。这导致两者在硬件利用率和部署难度上产生天壤之别。
4.2 优缺点深度对比：不止是压缩率差异
| 对比维度 | 非结构化剪枝 | 结构化剪枝 |
|---|---|---|
| 压缩率（同精度下） | 高（可达90%以上稀疏度） | 中低（通常30%-60%通道裁剪） |
| 硬件加速效果 | 依赖稀疏硬件，通用CPU/GPU上可能无加速甚至变慢 | 直接减少FLOPs，通用硬件即可获得线性加速 |
| 内存访问模式 | 随机跳跃访问，cache命中率低 | 连续内存访问，保持原有数据布局 |
| 模型体积缩减 | 显著（可通过稀疏编码压缩存储） | 中等（维度变小，但存储格式不变） |
| 训练复杂度 | 需要稀疏掩码管理，训练不稳定 | 需要重训或微调，但收敛相对稳定 |
| 部署工具链 | 需要特殊推理引擎（如OpenSpiel、DeepSparse） | 支持ONNX Runtime、TensorRT、TFLite等主流框架 |
| 典型硬件适配 | 适合带有稀疏加速单元的AI芯片（如某些NPU） | 适合CPU、GPU、DSP、传统NPU |
从上表可以看出，非结构化剪枝在“纸面压缩率”上占优，但实际部署时往往陷入“模型变小了，但跑得更慢了”的尴尬境地。原因在于，现代CPU和GPU的SIMD（单指令多数据）架构是为稠密矩阵设计的，处理稀疏数据时需要额外的索引计算和分支判断，反而增加了开销。
4.3 典型应用场景与选型判断方法
选择哪种剪枝策略，不能只看压缩率指标，而应遵循以下判断流程：
- 第一步：明确部署硬件。如果是自研NPU且硬件设计时已支持2:4稀疏模式（如NVIDIA Ampere架构），则非结构化剪枝可行；如果是通用ARM Cortex-A系列CPU或Mali GPU，则优先考虑结构化剪枝。
- 第二步：评估推理时延要求。若目标时延在10ms以内，结构化剪枝带来的确定性加速更可靠；若仅关注模型体积（如从100MB降到20MB），非结构化剪枝配合权重编码更有效。
- 第三步：检查工具链成熟度。TensorRT对结构化剪枝支持极佳，而PyTorch的torch.nn.utils.prune模块主要提供非结构化剪枝接口，需要额外转换。
- 第四步：考虑微调成本。结构化剪枝后模型精度恢复通常需要完整训练流程；非结构化剪枝可通过稀疏重训练（Sparse Training）在较短时间内恢复。
经验法则：在Edge AI领域，除非你的目标芯片明确支持稀疏计算，否则默认选择结构化剪枝。先通过通道剪枝获得2-3倍加速，再结合量化（INT8）获得额外体积缩减，这是最稳妥的工程路径。
4.4 案例拆解：MobileNetV3在Cortex-M55上的剪枝实战
为了更直观地说明两种剪枝的差异，我们以一个实际部署案例进行拆解。某智能家居产品需要在Cortex-M55内核的MCU上运行MobileNetV3-Small进行关键词唤醒（KWS），内存限制为512KB，推理时延要求低于80ms。
初始状态：MobileNetV3-Small原始模型大小为4.7MB（FP32），在Cortex-M55上直接推理时延为320ms，远超预算。团队首先尝试了非结构化剪枝，使用PyTorch的L1范数剪枝将稀疏度提升至85%，模型体积降至0.7MB，但实际推理时延反而上升到410ms。原因在于CMSIS-NN库不支持稀疏矩阵运算，稀疏权重在内存中仍按稠密格式存储，且增加了大量零值判断分支。
策略调整：团队改用结构化通道剪枝，通过BN层γ系数评估通道重要性，裁剪了最后一个阶段40%的通道，并微调了3个epoch。模型体积降至2.9MB，时延降至180ms。随后叠加INT8量化，体积进一步压缩至0.8MB，时延降至65ms，满足需求。
关键参数与操作步骤：
# 1. 通道重要性评估（基于BN的γ值）
for module in model.modules():
if isinstance(module, nn.BatchNorm2d):
gamma = module.weight.data.abs()
# 按阈值裁剪，保留前60%的通道
threshold = torch.quantile(gamma, 0.4)
mask = gamma > threshold
# 2. 执行通道裁剪（需重建后续层）
pruned_model = prune_channels(model, mask)
# 3. 微调（学习率设为原训练时的1/10）
optimizer = SGD(pruned_model.parameters(), lr=0.001, momentum=0.9)
for epoch in range(3):
train_one_epoch(pruned_model, train_loader, optimizer)
# 4. 导出ONNX并转换为CMSIS-NN格式
torch.onnx.export(pruned_model, dummy_input, "model.onnx")
# 使用STM32Cube.AI工具链转换，启用INT8量化结果对比：
| 方案 | 模型体积 | 推理时延 | 精度损失 |
|---|---|---|---|
| 原始FP32 | 4.7MB | 320ms | 基准 |
| 非结构化剪枝85% | 0.7MB | 410ms | 2.1% |
| 结构化剪枝40%通道 | 2.9MB | 180ms | 1.3% |
| 结构化剪枝+INT8量化 | 0.8MB | 65ms | 1.8% |
复盘经验：非结构化剪枝在MCU上不仅没有加速，反而因内存访问不规则导致性能倒退。结构化剪枝虽然压缩率有限，但每一步都直接转化为时延收益。最终方案通过“结构化剪枝+量化”的组合拳，在满足精度约束的前提下，实现了4.9倍的端到端加速。
风险提示：结构化剪枝并非没有代价。过度裁剪通道会导致模型容量骤降，尤其在MobileNet这类深度可分离卷积网络中，通道间关联性强，裁剪后精度可能急剧下降。建议每次裁剪不超过20%通道，并立即评估验证集精度，若下降超过2%则回退。
4.5 常见误区与总结复盘
在实际项目咨询中，我们发现工程师常陷入以下误区：
- 误区一：盲目追求高稀疏度。90%稀疏度的非结构化模型在论文中很漂亮，但部署时发现硬件不支持，最终只能放弃。建议先确认硬件数据手册中是否包含“Sparse Compute”或“Structured Sparsity”特性。
- 误区二：混淆“体积缩减”与“推理加速”。模型文件变小不等于推理变快。非结构化剪枝后模型体积确实缩小，但推理时仍需加载完整权重矩阵，只是零值不参与乘法运算，而零值判断本身也消耗CPU周期。
- 误区三：忽略剪枝后的微调。无论哪种剪枝，直接剪枝不微调都会导致精度大幅下降。结构化剪枝至少需要3-5个epoch的微调，非结构化剪枝则需要更长的稀疏训练过程。
- 误区四：认为结构化剪枝只能用于CNN。实际上，Transformer架构中的Attention头剪枝、FFN中间维度剪枝也属于结构化剪枝范畴，在Edge端部署BERT等模型时同样适用。
总结：结构化剪枝与非结构化剪枝并非对立关系，而是互补的工程手段。在Edge AI部署中，建议遵循“先结构化、后非结构化”的优先级：先用结构化剪枝获得硬件友好的加速，若仍有体积瓶颈，再对剩余稠密权重进行非结构化稀疏化，并配合稀疏感知训练。这种混合策略往往能在精度、体积和时延之间取得最佳平衡。