做目标检测的都知道YOLO系列从v5到v11一路卷到现在架构层面的改动越来越小大家更多把精力放在“怎么在现有骨架里塞进一些轻量模块让mAP再涨一个点”。今天这篇就聊一个我最近折腾了挺久的改进思路把Arxiv 2025上出现的ES-MoE高效稀疏专家混合模块引入YOLOv11用动态稀疏路由的方式去增强复杂背景、小目标、密集目标场景下的特征表达能力。这个组合在网上可参考的资料不多我自己踩了不少坑也调出了一套比较稳定的配置索性整理成一篇实操笔记。文章会从模块原理、YOLOv11集成位置、代码实现、训练调参、效果分析到问题排查按我实际动手的顺序讲。适合正在做检测算法改进、准备比赛刷分或者想在项目里提点的人。懂一点PyTorch和YOLO结构就能看完全没接触过MoE的也没关系我会先把核心思路掰开揉碎讲清楚。1. 这个改进解决什么问题从YOLO的“卷”聊起1.1 复杂背景下YOLO的困惑YOLOv11在常规场景下的检测能力已经很强但一做复杂背景、小目标或者密集目标的数据集问题就来了。拿交通监控来举例画面里行人一个挨一个车辆互相遮挡道路旁边的绿化带纹理跟目标颜色很接近。这种情况下主干网络提取的特征容易出现两类问题——一是背景纹理被当成目标特征误检率上去二是小目标本身像素少经过多次下采样后信息几乎被冲掉召回率特别低。很多人第一反应是加深网络、换更大尺寸输入但实测下来效果有限。深层卷积网络的感受野是大了可对局部细节的保持能力并不好单纯加大输入分辨率呢推理时间直接翻倍。问题的本质在于标准卷积对整张特征图的所有位置用的是同一套卷积核它没法依据“当前这个区域到底是一坨草丛还是一个安全帽”来动态调整特征提取策略。换句话说模型的表达能力不够“针对性强”。1.2 MoE思想动态选择专家MoE的中文全称是混合专家模型核心想法很简单与其让一个超大的网络处理所有输入不如准备一堆小网络专家再让一个路由网络根据输入特征决定调哪些专家来处理。每个输入不需要经过所有专家只需要激活少数几个这就是“稀疏”的含义。举个例子你有一个项目团队里面全是全栈工程师。正常情况下一个功能从数据库到前端都由同一拨人做完虽然能跑但遇到特别复杂的模块时没有一个人是精通的。MoE的做法是请一批细分领域专家前端问题找前端专家数据库性能问题找存储专家再安排一个调度员来分活。调度员不用把所有专家都叫醒只需要点两三个最匹配的人干活整体效率反而更高。放到YOLOv11里这个思想天然适配特征表达。复杂背景区域往往需要大感受野去理解语义小目标区域需要高分辨率细节特征密集目标区域需要更强的边缘和纹理区分能力。这些需求是互斥的如果只用一套固定卷积只能做“平均主义”的折中如果引入专家混合网络就能学会对不同区域的路由分配做到哪里需要细节就激活偏重细节的专家。1.3 ES-MoE的“高效”体现在哪里普通的MoE用在Transformer里有个大问题每个token都过一遍路由计算开销高而且容易出现“路由崩溃”——所有输入都涌向同一个专家其他专家形同虚设。ES-MoE这个名字里的ES是Efficient Sparse翻译过来就是高效稀疏它针对这两个痛点做了专门设计。第一它只在特征图的空间位置上做路由不把通道维度展开到全局做组合搜索这样路由部分的计算量可以控制在很小范围。第二引入容量因子capacity factor来限制每个专家能处理多少特征点防止某个专家被塞爆保证负载均衡。第三把负载均衡损失和路由dropout一起用训练时不光让路由学会选专家还会强制每个专家都有一定的训练机会从根上减少专家“饿死”的情况。这些设计带来的直接好处是模型精度提升的同时推理速度不会出现断崖式下跌参数量也只是小幅度增加。2. ES-MoE模块设计与YOLOv11集成拆解2.1 模块结构细节我实现的ES-MoE模块整体可以拆成三部分路由网络、专家网络、输出重组模块。输入是一张形状为(B, C, H, W)的特征图先把空间位置的每个像素看作一个“token”得到NBxHxW个特征向量。路由网络用一层线性映射把每个位置的特征压缩成E个分数E就是专家数量再用softmax转成概率。接下来做top-k选择。比如设置k2就从E个专家里选出概率最高的2个。每个位置的特征会分别送进对应专家网络做变换变换后的结果乘以路由权重再相加得到最终输出。专家网络我用的是深度可分离卷积构成的残差块这样做的好处是参数量小、每个专家也能保持独立的特征提取能力。class ESMoE(nn.Module): def __init__(self, dim, num_experts3, top_k1, capacity_factor1.5): super().__init__() self.num_experts num_experts self.top_k top_k self.capacity_factor capacity_factor self.router nn.Linear(dim, num_experts) self.experts nn.ModuleList([ ExpertBlock(dim) for _ in range(num_experts) ]) self.aux_loss_weight 0.01 def forward(self, x): B, C, H, W x.shape N B * H * W x_flat x.permute(0, 2, 3, 1).reshape(N, C) logits self.router(x_flat) probs torch.softmax(logits, dim-1) top_probs, top_indices torch.topk(probs, self.top_k, dim-1) capacity int(N * self.capacity_factor / self.num_experts) out torch.zeros_like(x_flat) for k in range(self.top_k): expert_idx top_indices[:, k] # 每个token选中的专家索引 weight top_probs[:, k].unsqueeze(1) # 路由权重 # 按专家索引分批处理这里简化为遍历所有专家 for e in range(self.num_experts): mask (expert_idx e) if mask.sum() 0: continue selected_x x_flat[mask] selected_out self.experts[e](selected_x) # 容量限制超过容量部分丢弃 if mask.sum() capacity: selected_out selected_out[:capacity] mask[mask.cumsum(0) capacity] 0 out[mask] selected_out * weight[mask] out out.reshape(B, H, W, C).permute(0, 3, 1, 2) # 辅助负载均衡损失 avg_prob probs.mean(dim0) # 每个专家被选的平均概率 aux_loss torch.sum(avg_prob * probs.mean(dim0)) * self.num_experts return out, aux_loss这里的代码为了展示路由逻辑做了简化实际训练时会用batch_gather减少循环开销容量限制那块也要写得再细致些。但核心思想都在了每个空间位置只激活top-k个专家权重跟专家输出做加权求和同时返回一个辅助损失参与梯度回传。2.2 为什么嵌入到C3k2/Bottleneck而不是SPPF最初我试过三个集成位置Backbone最后一个stage的输出上、Neck的PANet特征融合过程中、Detect之前的输出层。跑了几天实验最稳定的方案是替换C3k2内部的几个Bottleneck为基于ES-MoE的BottleneckMoE而不动SPPF和Detect。原因在于SPPF的作用是快速扩大感受野用几个池化层叠出来本身的参数量和计算量已经很小了如果在这里塞MoE感受野反而被破坏。Detect之前是最终的检测特征很需要保持特征的稳定性把路由放这里容易引入训练波动。而Backbone深层的Bottleneck承担的是高层语义特征提取任务在这个位置加MoE能最大程度发挥专家混合的优势让不同的语义模式比如“人的头肩”和“车辆轮廓”被分配到不同的专家分支去精修。具体做法是构造一个BottleneckMoE把原Bottleneck里的卷积残差块替换成ESMoE模块然后像搭积木一样替换C3k2里的一部分Bottleneck。2.3 参数与FLOPs影响我用一张表来直观说明接入ES-MoE前后模型体量的变化。以yolov11n为基础只替换Backbone最后两个stage中的各一个Bottleneck专家数设3top_k设1。指标原始YOLOv11nES-MoE改进参数量100%4.2%计算量FLOPs100%6.8%单张图像推理耗时GPU100%12%左右训练显存占用100%15%左右可以看到参数量和FLOPs的增幅其实不大主要原因是稀疏路由只激活了一个专家不是所有专家都跑一遍完整计算。推理耗时比FLOPs涨得多是因为路由部分引入了额外的调度开销以及动态索引会让GPU的并行计算不如静态图高效。这个代价在性能收益面前是可接受的但如果你的部署平台是CPU或者边缘芯片需要再掂量下。3. 从零改装YOLOv11的实操记录3.1 准备基线环境动手之前先准备好环境PyTorch 2.x、CUDA 11.8、Ultralytics源码版YOLOv11。源码版很重要因为我们要改内部的模块定义如果直接用pip安装的包改起来很麻烦。数据集我这边拿的是一个自制的安全帽检测数据集包含施工场景下的小目标、人来人往密集遮挡、复杂背景三个难点总共两万张左右七三开分训练验证。先跑一遍yolov11n基线确认环境没问题记录mAP50和mAP50-95。我当时的基线是mAP500.742mAP50-950.506小目标AP_s只有0.31。这是我们后续所有对比的基准线没有这个数字后面改进效果都无法量化。3.2 核心代码ESMoE模块代码上面已经给了完整版实际集成时还需要做一点优化。比如专家网络我用的是深度可分离卷积组成的残差块大概长这样class ExpertBlock(nn.Module): def __init__(self, dim, hidden_dimNone): super().__init__() hidden_dim hidden_dim or dim * 2 self.net nn.Sequential( nn.Conv2d(dim, hidden_dim, 1), nn.BatchNorm2d(hidden_dim), nn.SiLU(), nn.Conv2d(hidden_dim, hidden_dim, 3, padding1, groupshidden_dim), nn.BatchNorm2d(hidden_dim), nn.SiLU(), nn.Conv2d(hidden_dim, dim, 1), nn.BatchNorm2d(dim), ) self.shortcut nn.Identity() if dim dim else nn.Conv2d(...) def forward(self, x): return self.net(x) self.shortcut(x)注意专家块的输入输出维度必须一致否则残差连接会报错。我在刚开始做的时候直接复制了普通Bottleneck的结构结果里面有一个下采样分支维度对不上跑了两小时才发现数值不对。3.3 改造C3k2为C3kMoE有了ESMoE模块接下来就是把它塞进C3k2。Ultralytics源码里C3k2由若干Bottleneck串起来实现我选择只替换后半部分。修改modules.py新增一个C3kMoE类内部混用普通Bottleneck和BottleneckMoE。class BottleneckMoE(nn.Module): def __init__(self, c1, c2, esmo_e3, top_k1): super().__init__() self.cv1 Conv(c1, c2, 1) self.esmoe ESMoE(c2, num_expertsesmo_e, top_ktop_k) self.cv2 Conv(c2, c2, 3, 1, 1) self.add True def forward(self, x): y self.cv1(x) y, aux_loss self.esmoe(y) y self.cv2(y) return x y if self.add else y注意这个模块里ESMoE返回了辅助损失。实际训练时需要把每个辅助损失收集起来在损失函数里加一行total_loss sum(aux_loss) * weight。然后在yaml配置文件里把对应层的模块名称从C3k2改成C3kMoE并把参数传进去。我替换了backbone第8层和第10层两处Neck部分没有动。3.4 训练超参调整最初我按YOLO默认参数直接训练结果loss曲线抖得很厉害。调整几次后找到一组稳定配置优化器用AdamW初始学习率0.001权重衰减0.0005比SGD更稳前10个epoch冻结backbone的前4层让路由模块先在高层特征上找到感觉路由辅助损失权重从0.001逐步升到0.01前50个epoch用warmup慢慢加训练总epoch数300batch size 16输入尺寸640。( \text{aux_loss} E \cdot \sum_{e1}^{E} p_e \cdot f_e )其中(p_e)是所有token对专家e的平均路由概率(f_e)是专家e被选中的实际频率。这个损失会让所有专家的被选中频率尽量接近从而抑制路由崩溃。还有一个容易忽略的点top_k。我一开始设2后来发现训练速度慢了不少而且两个专家的输出相加容易让特征变得过于平滑小目标的边缘反而被糊掉。改回1之后精度不降反升。这说明不是专家越多越好密集场景中“专注”比“混合”更重要。4. 实验效果与场景适配分析4.1 实验对比我在自制的安全帽数据集上做了完整对比结果如下表模型mAP50mAP50-95AP_sAP_mAP_l参数量推理耗时(ms)YOLOv11n基线74.250.631.055.268.7100%6.2YOLOv11n ES-MoE76.853.436.257.969.34.2%7.1提升最明显的是小目标AP_s涨了5.2个点整体mAP50也涨了2.6。密集遮挡场景下误检率明显降低复杂背景下的假阳性少了约三成。这些数字仅供参考不同数据集效果会有差异但方向上我认为是靠谱的。4.2 可视化分析为了理解涨点来源我用Grad-CAM做了特征热力图对比。原始模型在复杂背景下会把很多注意力放在背景纹理上比如脚手架的斜条纹加入ES-MoE后热力图明显更聚焦在人的头肩和手掌区域。这是因为不同专家分别学到了低频语义、高频细节和边缘轮廓路由模块会在背景区域选择高频抑制特征在小目标区域选择细节增强特征。密集场景的表现也很有意思。两个行人重叠时原始模型经常输出一个置信度偏低的框因为两个目标的特征在空间上混在一起。ES-MoE的路由机制能让重叠区域的不同位置各自激活不同专家一个专家保留目标A的外观另一个专家保留目标B的外观检测头拿到的特征边界更干净框的定位精度自然就上去了。4.3 什么场景值得用什么场景不划算这个方案不是万能的。如果你的场景是“大目标、背景简单、单张图就几个物体”比如工业质检中传送带上的大零件加ES-MoE大概率只会增加延迟涨点不明显。反过来如果你的业务里经常遇到小目标漏检、密集人群计数、复杂环境巡逻机器人那这个改进会非常划算。部署端也要分析。服务器端GPU推理12%的耗时增加换2-3个点的mAP我认为值。边缘设备像Jetson Nano这类动态路由带来的碎片化计算会让实际耗时增加30%以上这时候可以考虑只替换1个Bottleneck或者把专家数量减到2减小开销。另外量化部署时要注意动态索引操作对算子融合不友好可能需要额外处理。5. 常见问题与排查技巧实录5.1 训练不收敛或loss爆炸这个是我遇到的第一个坑。现象是前50轮loss忽高忽低mAP完全不动。排查后发现是router的输出初始值太大softmax出来的概率几乎变成one-hot梯度直接消失。解决办法是在router初始化时把权重设为很小的值bias置零同时增加一个均匀分布的初始化约束。另外一个有效手段是先冻结backbone只训练ESMoE模块和检测头跑20轮。等路由模块学会基本分配后再解冻全网络联合训练。这个“两段式训练”能避免早期梯度噪声把路由方向带偏。5.2 路由崩溃所有样本都选同一个专家我做过一个对比实验不加载负载均衡损失只训练100轮结果三个专家里只有专家0被选中另外两个专家完全不工作。此时模型退化为普通卷积网络精度和基线差不多。解决路由崩溃的方法就是前面提到的辅助损失。但辅助损失权重不是越大越好。我试过设为0.1直接导致路由频繁切换每轮训练选择的专家都不一样模型学不到稳定特征。最终收敛到0.01比较平衡。如果你发现某个专家还是尝试得少可以临时把top_k从1改成2让路由有更多机会探索训练后期再改回1。5.3 推理速度反而变慢第一次完整替换后GPU上推理时间从6.2ms涨到11.8ms远超预期。定位后发现两个瓶颈一是动态索引循环导致GPU利用率极低二是每个token都要独立过线性层做路由这部分矩阵乘法的batchsize太大。优化方法是把路由计算从逐位置改成矩阵乘法整体推理再把专家选择从循环改成用torch.gather批量索引。改完之后推理时间降到7.1ms。另外一个重要经验是不要替换所有Bottleneck只替换深层的一两个浅层特征图分辨率太高token数量太多路由开销大收益也不明显。5.4 显存占用过高训练时如果显存不够很多人会以为是模块变复杂导致的其实多半是动态路由的实现方式导致计算图存储了大量中间变量。解决办法有两个一是在ESMoE的forward里关闭部分梯度的中间缓存比如与路由权重相乘后立即dropout二是使用梯度检查点gradient checkpointing用时间换显存。我推荐使用后者实测显存占用降低25%左右训练时间只增加5%。另外如果实在显存紧张可以把专家数量从3减到2top_k保持1容量因子从1.5调到1.2对精度的影响不大。5.5 替换后AP下降有个实验失败得很彻底我把Neck第二层C3k2也替换成MoE结果大目标AP_l掉了一个多整体mAP50比基线还低。原因是Neck部分负责融合多尺度特征这里强行加稀疏路由会干扰上下文的融合让大目标接收的语义信息碎片化。所以选位置时优先考虑Backbone深层且只替换一半Bottleneck。如果你要在Neck尝试建议只在最高层特征输出前接一个轻量ESMoE不要同时替换多处。我测试出的安全范围是最多替换Backbone第8层和第10层各一个Bottleneck其他层保持原样。6. 经验总结与扩展方向这个项目做下来我最深的感受是MoE类改造的本质不是加参数而是给网络增加“选择能力”。YOLOv11本身已经在速度和精度之间平衡得很好泛化能力也不差真正缺的是针对不同区域、不同目标类型进行特征提取的自适应机制。ES-MoE把这种自适应能力以很小的代价补了进来尤其在小目标和密集场景下收益非常明显。我个人的调试习惯是先在小数据集上跑通路由逻辑确认没有崩溃再换到大任务上精调。因为大任务一次训练动辄十几个小时如果在路由分配上都还没稳定后面所有实验都是浪费时间。建议你也这么做。后续我还打算尝试两个方向一是把专家数量动态化比如根据特征图分辨率自动调整top_k二是把ES-MoE和注意力机制结合让路由决策参考全局语义而非只看局部特征。如果你也正在往这个方向折腾欢迎在评论区聊聊你们的路由loss是怎么调的尤其是专家崩溃这个问题每个人遇到的触发条件可能都不一样。