简介面向目标检测模型优化方向的开发者和研究者这份压缩包提供基于 Ultralytics YOLOv8 的完整剪枝实现。包内不仅包含剪枝主脚本还准备了多种网络结构 YAML 配置如 GFPN、RepNCSPELAN、DyHead 等变体、通道重要性可视化工具与实时帧率测试脚本并附有 compress.md 说明文档系统展示了从配置调整、软剪枝/硬剪枝到结构剪枝再到剪枝后 fine-tuning 恢复性能的完整链路。资源共 41 个文件大小 1.47MB以 20 个 pyc 编译文件、10 个 yaml 配置、9 个 py 脚本为主另有 1 个 md 说明与 1 个 zip 包便于二次开发和移植。已有 1512 人学习下载。通过这套源码可以理解超参数选择对模型性能的影响掌握剪枝后微调的训练方法适合希望在边缘设备上部署轻量化 YOLOv8、提升实时推理效率的开发者作为参考。 最近在给一个嵌入式设备的检测项目做优化跑YOLOv8s模型输入640×640在RK3588上推理大概40ms勉强能用但帧率上不去。后面试了YOLOv8n速度上去了mAP掉得又太多卡在中间很难受。最后决定走模型剪枝的路子把YOLOv8s剪到接近nano的体量精度损失控制在1.5个点以内推理速度稳定到25ms左右。这篇文章是把整个思路和关键代码实现梳理一遍重点讲源码层面的剪枝流程、稀疏化训练、通道筛选和重参细节以及剪完之后的微调、增量训练和部署注意事项。如果你想解决“模型在边缘设备上跑不动、精度和速度很难平衡”的问题或者单纯想搞懂YOLOv8剪枝源码是怎么串起来的这篇内容应该能给你省不少时间。1. 为什么要给YOLOv8做剪枝1.1 模型落地时的尴尬处境YOLOv8一共有五个尺寸版本n、s、m、l、x。只看参数量和FLOPs的话s比n大了接近三倍但性能提升并没有成比例地体现出来。实际项目里经常出现这种情况用n太小小目标漏检严重用s或者m边缘设备跑不满帧率剪枝恰恰是这两个版本之间找平衡点的好办法。我这次的目标很明确保持YOLOv8s的检测头结构和整体网络拓扑把backbone和neck里冗余的通道数剪掉让推理速度尽量向nano靠拢同时保住s的精度。相比重新设计网络结构剪枝不需要改动数据流也不需要从零开始训练这对我这种没有大量算力资源的小团队来说是最高效的方式。1.2 剪枝的核心收益在哪里从资源角度看剪枝带来的收益非常直接。相同硬件条件下参数量少了内存带宽占用降低模型加载时间缩短。在CPU、NPU这类边缘设备上通道数直接决定计算密度剪完之后缓存命中率会有明显改善这也是剪枝后推理速度提升的一个重要原因。更关键的是模型体积的缩减。源码里剪枝后会重新生成新的模型权重本质上把一个100MB的模型变成40MB甚至更小。过一次性剪完再结合int8量化最后部署到设备上的模型可能只有原来的五分之一这对存储空间有限的嵌入式设备来说意义很大。1.3 剪枝在技术链路中的定位剪枝通常和量化、蒸馏一起被称为模型轻量化三件套。它们的定位不同蒸馏需要一个强大的教师模型训练成本高量化是在推理阶段降低精度剪枝则是在训练环节就对网络结构做手术把“胖”网络变“瘦”。在YOLOv8的完整优化链条里剪枝通常排在最前面剪完之后再量化精度损失可以被微调阶段部分补偿。如果先量化再剪枝模型精度下降会比较明显。这是我在多个项目里反复验证过的顺序建议你也按这个次序来。2. 剪枝方案选型与源码结构拆解2.1 结构化剪枝和非结构化剪枝怎么选模型剪枝大致分两类非结构化剪枝和结构化剪枝。非结构化剪枝是单独把权重矩阵里接近0的元素置零得到的是稀疏矩阵虽然参数量统计上变小了但实际推理时硬件很难利用这种稀疏性在通用设备上的加速效果并不明显。结构化剪枝则是把整个卷积核或者整个通道直接删掉删完之后网络还是密集的任何推理框架都能直接跑。YOLOv8剪枝源码里最常用的是通道剪枝这属于结构化剪枝的一种。通道剪枝的思路是评估每个通道的重要性把不重要的通道连同对应的卷积核一起移除达到缩小网络宽度的目的。2.2 YOLOv8网络结构对剪枝的影响YOLOv8的主干网络包括backbone的C2f模块、SPPF模块neck部分的C2f和上采样模块以及检测头。C2f模块的Bottleneck结构经过多次残差连接剪枝时如果直接删通道容易破坏残差相加的张量维度这是一个需要特别注意的地方。源仓库里的YOLOv8代码在C2f模块里用了torch.cat把多个Bottleneck输出拼接起来这意味着只要保证分支内部通道数一致剪枝后的重参是可以自动对齐的。真正麻烦的是检测头的输出通道数和类别数绑定这个不能乱动。剪枝时一般只动backbone和neck的通道检测头的输入来自neck的上层特征在重参时需要专门处理通道映射关系。2.3 开源剪枝方案对比与源码选型现在社区里YOLOv8剪枝实现不少大致分三类方案类型代表实现优点缺点基于BN的稀疏化剪枝自实现BN γ缩放原理简单训练器中直接操作需要改训练代码稀疏化训练时间长结构化敏感性分析逐个通道裁剪评估不需要改训练流程每个通道都要推理一次成本极高第三方剪枝框架torch pruning、PaddleSlim封装完整命令简单针对YOLO系需要额外适配我最终选择了基于BN γ因子稀疏化的方案理由有三YOLOv8源码本身就在训练阶段计算BN统计量改动量最小BN的γ缩放经过L1正则化之后会自然趋向0能被当成通道重要性的代理指标最后是方案成本低不需要额外跑敏感度评估一张卡几个小时就能出结果。源码结构大致包含几个模块稀疏化训练脚本、通道重要性统计工具、剪枝执行脚本、模型重参脚本和微调训练脚本。后面会逐个环节讲清楚。3. 核心实现细节稀疏化训练、通道筛选与重参3.1 稀疏化训练的Loss如何修改稀疏化的目标是在原始训练Loss上增加一个BN层γ系数的L1正则项。YOLOv8源码的损失函数在loss.py里正常的训练前向计算完损失之后需要额外遍历模型中的BN层把γ绝对值的加权和加到总Loss里。核心逻辑用伪代码表达就是这样# 在训练循环中加入稀疏化惩罚 def compute_loss_with_sparsity(model, targets, preds, loss_fn, s0.0001): # 原始损失分类、回归、分割等 loss loss_fn(preds, targets) # 稀疏化惩罚项统计所有BN层的gamma绝对值之和 sparsity_loss 0.0 for module in model.modules(): if isinstance(module, torch.nn.BatchNorm2d) and module.weight is not None: sparsity_loss torch.abs(module.weight).sum() loss s * sparsity_loss return loss这里s是稀疏化系数控制惩罚强度。我的经验是YOLOv8s模型上s0.0001比较合适s太大模型精度会崩太小通道趋零效果不明显。实际测试时你可以从1e-5起步每50轮观察一次BNγ分布和mAP曲线如果γ分布迟迟不出现明显双峰再上调系数。稀疏化训练需要在原本的数据集上做最好用完整训练集因为剪枝完成后还需要在相同分布的数据上微调。如果这一步用的是子集后续微调时模型会经历明显的域偏移精度恢复效果会差一截。3.2 BN γ分布的可视化与剪枝比例确定稀疏化训练结束后可以统计模型里所有BN层的γ值分布。正常情况下γ值会呈现明显的双峰分布一部分通道的γ接近0一部分保持较大数值。可以在一个脚本里把γ值提取出来并画直方图同时打印每个BN层被裁剪后剩余通道的数量。判断剪枝比例的时候我是这样做的先设定一个全局阈值比如γ小于0.01的通道删掉统计所有BN层被删通道的比例。如果全局剪枝比例不足30%说明稀疏度不够返回调整稀疏化系数继续训练如果超过了70%说明裁剪太激进需要降低稀疏化系数。对YOLOv8模型我建议把全局剪枝比例控制在40%~60%之间。低于40%基本感觉不到速度提升高于60%的话即便微调也很难保住精度。最终我剪掉了neck部分的通道偏多、backbone偏少因为从实验效果看backbone的通道对特征提取的贡献更集中保留它们能有效防止小目标漏检。3.3 通道裁剪与模型重参的源码实现通道裁剪是整个流程里最容易出bug的环节。每个卷积层都有权重大小[out_channels, in_channels, k, k]要删除一个输出通道需要同时修改当前层和下一层的输入维度。YOLOv8源码的结构比较复杂有C2f、SPPF、Detect等模块需要写一个递归遍历器按模块顺序维护一个remaining_channels字典逐个处理Conv-BN对。处理逻辑大致是# 伪代码遍历模型模块生成剪枝版本 def prune_model(model, prune_ratio): module_name_map collect_bn_modules(model) # 收集所有BN层 for name, bn in module_name_map.items(): gamma bn.weight.data.cpu().numpy() threshold np.percentile(gamma, prune_ratio * 100) mask gamma threshold # 根据mask裁剪当前层输出通道 prune_conv_output_channels(model, name, mask) # 找到下一层裁剪对应输入通道 next_layer find_next_conv_layers(model, name) prune_conv_input_channels(next_layer, mask) return rebuild_model(model) # 生成剪枝后的新模型结构实际处理时有几个特别容易踩坑的点C2f内部有多个Bottleneck分支这些分支的输入输出通道必须保持一致裁剪时要把同一组的BN mask统一处理。上采样层和concat层不会改变通道数但它们的输入来自多个来源如果其中一路通道数变了另外一路也要同步改变不然torch.cat会直接报错。Detect头里的卷积层不能剪因为它的输出通道数和类别数解耦不了。重参的意思是在剪枝后重新构建一个与剩余通道匹配的新模型而不是直接原地修改原来的state_dict。最稳妥的做法是复制原模型的超参数配置遍历每个模块检查有无被裁剪的记录若有则用新的输入输出通道数实例化。新建模型之后把保留的权重拷贝进去这一步最简单有效的办法是逐层用索引取值。4. 剪枝后的微调与增量训练技巧4.1 为什么剪完不能直接部署剪枝之后的模型权重是残缺的需要微调重新拟合数据分布。注意这里说的微调不是普通训练而是用很小的学习率在原始数据集上把精度拉回来。实操中我用的是这种策略前几个epoch先把学习率设成正常训练的0.1倍做一次“预热”让模型适应新的通道结构然后再进入正常微调。如果是自定义数据集10到30个epoch就能看到精度回到原来95%以上的水平。微调时有个技巧把YOLOv8源码里原本的warmup轮次缩短因为权重和梯度分布已经有良好的初始化不需要那么长的预热。同时关闭Mosaic增强或者降低Mosaic概率因为剪枝后的模型对强增强的适应能力比完整模型弱用久了会发现过拟合或者不收敛。4.2 增量训练的正确打开方式增量训练这个词在热度和实际使用中有两层意思一是在已有模型基础上继续训练加入新的数据类别二是模型在部署后需要根据现场数据持续优化。剪枝之后的微调其实就属于第一种但这种增量训练有一个隐患——模型可能会遗忘旧知识被拉向新数据分布。应对办法是回放机制每次增量训练时从旧数据里采样一部分混入新数据集比例控制在3:1到4:1之间。我在做YOLOv8增量训练时会固定一部分原始batch保证模型不会彻底忘掉旧目标形态。这种做法在剪枝后的微调里也很管用因为剪枝本身就改变了权重分布不强制回放旧知识的话精度恢复会更慢。另外一点要注意的是增量训练时的学习率不能太高建议是正常训练的十分之一到五分之一。剪枝后的模型离最优点比较近学习率太大会跳过最优区域后期怎么调都回不来。4.3 微调过程中的Loss曲线观察微调阶段要重点观察三个指标总Loss、box回归Loss和分类Loss。正常情况是三者都下降如果box Loss在降但分类Loss反复震荡说明分类分支对剪枝更敏感可以尝试把分类Loss权重大一些。我在实操中发现YOLOv8的loss.py里分类分支用BCE回归分支用CIoU剪枝对CIoU的影响通常小于BCE。所以微调时可以把分类Loss的权重临时从0.5调高到0.7显著加速分类分支的恢复速度。剪完之后精度如果一次性掉了超过5个点先别急着调超参数回头自查两块一是稀疏化训练阶段的系数是不是太高了γ被压得太狠导致有效通道数远低于预期二是重参阶段有没有误伤了分支结构导致某个跨层连接断裂。这两块是精度暴跌最常见的根源。5. 常见问题与排查技巧实录5.1 通道数对不上、shape不匹配的排查这个问题在剪枝源码调试时出现频率最高报错基本是size mismatch或mat1 and mat2 shapes cannot be multiplied。原因主要是重参时的通道映射没对齐。排查思路遵循三步首先确认每个被裁剪BN层之后跟的是不是标准卷积层如果不是说明模块结构特殊需要单独处理把每个已裁剪层的out_channels和下一层的in_channels打印出来逐一比对发现不一致的位置就是断点YOLOv8的跨层concat需要从数据流方向去找有哪些分支汇聚到同一个concat节点确保所有输入分支的通道数一致。5.2 剪枝后精度恢复慢这个现象我也踩过坑。有一次剪完YOLOv8s微调了20个epochmAP还在原地打转后来发现是微调时的batch size设得太小BN统计量更新不稳定。解决方法是微调阶段至少用32以上的batch size如果显存不够可以关闭一部分增强操作。还有一种情况是学习率调度不对YOLOv8默认用了cosine衰减微调阶段最好从头到尾用固定的低学习率不要再走一个完整的cosine周期模型没有那么多时间振荡。5.3 模型剪完后加速效果不明显剪完参数少了但推理时间变化不大这个问题在GPU上更常见因为显卡的计算并行度本来就高通道数减少的计算收益被并行掩盖了。解决方法是先用NNIE、TensorRT、ONNX Runtime这类推理框架导出再做benchmark不要在PyTorch的Eager模式下判断速度。对于NPU设备还有一个隐蔽的影响因素是通道对齐。很多硬件有通道对齐要求比如必须是4或8的倍数。剪枝后通道数如果成了61、67这种比较尴尬的数字硬件填充的代价反而更大。源码里最好加一个对齐步骤统计剪枝后每层剩余通道数向上取整到8或16的倍数再补一些不重要的通道。5.4 常见问题速查表问题现象可能原因解决办法shape mismatch报错重参时通道映射未对齐打印每层输入输出通道数逐一比对剪完精度崩盘稀疏化系数过大或误剪关键层降低稀疏化系数保护backbone通道微调不收敛batch size过小或学习率过高batch size调到32以上学习率降为正常的0.1倍参数量少了但速度没变PyTorch Eager模式或硬件通道对齐问题导出到推理框架做benchmark补齐通道到对齐粒度BN γ分布不分散稀疏化系数太小逐步调大稀疏化系数并重新训练6. 部署落地与效果实测6.1 面向TensorRT和NCNN的导出流程剪枝重参后的模型要先转成ONNX再转到目标推理框架。YOLOv8源码里自带export.py但剪枝后的模型可能包含一些自定义模块导出前要仔细检查。ONNX导出时最好固定动态维度或者设置好batch size避免后面转TensorRT时出现维度推断问题。TensorRT这边要注意对于剪枝后的模型建议用trtexec重新做一次校准不要直接沿用剪枝前的校准缓存。校准集覆盖类别的丰富度很重要不然量化后精度会掉得很厉害。NCNN部署时直接加载ONNX转出来的.param和.bin即可但要在ncnnoptimize里开启FP16混合精度这样在ARM平台的加速效果更明显。6.2 实测数据与性能对比我拿一个自有数据集做了完整对比检测类别数大约8类。原始YOLOv8s和剪枝后的模型效果对比如下版本参数量(M)模型体积(MB)640×640推理耗时(RK3588)mAP0.5变化YOLOv8s11.222.538ms基准YOLOv8n3.26.519ms-4.1剪枝后YOLOv8s5.811.825ms-1.3剪枝之后比原版s提速约35%参数量减半mAP只掉了1.3个点。虽然速度还达不到nano的水平但精度优势明显可以说达到了项目要求。6.3 落地时的一个细节建议剪枝模型部署到边缘设备后建议在推理代码里开启模型的内存连续操作比如torch.ops.quantized或NPU上的内存映射优化。很多剪枝模型因为通道数不规则内存排列天然是碎片的这会影响缓存读取效率。另外如果检测头有NMS的后处理逻辑可以尝试把NMS阈值稍微调高一点。剪枝之后的置信度分布会比原模型略微集中阈值不变的话可能滤掉了一些原本该保留的低置信度检测框。在实测项目里我将NMS的iou阈值从0.45调整到0.5召回率有小幅回升。7. 个人经验总结前前后后在YOLOv8剪枝源码上折腾了几周最大的感受是这个事情并不复杂但细节特别多。每一条通道的取舍背后都有网络结构的连锁反应一旦重参阶段的某个mask出错整个模型的精度恢复就会变得异常困难。建议第一次做剪枝的话先拿COCO子集或者小数据集跑通全流程确认每个环节输出符合预期之后再上真实业务数据。再分享一个小技巧把剪枝过程中的所有配置记录下来尤其是稀疏化系数、剪枝比例、各层mask的统计结果这些信息在你后续调参时会非常有用。我就是靠着一份比较完善的剪枝日志把第二次、第三次的不同版本快速对齐找到了当前数据集下的最优剪枝策略。模型轻量化本身没有银弹但把流程规范下来之后每一次对网络做“减法”都是在给自己的部署方案争取更多余量。本文还有配套的精品资源点击获取