YOLOv11融合OverLoCK提升小目标检测的完整源码解析

简介面向目标检测开发者的YOLOv11融合OverLoCK模块源码包源于CVPR2025纯ConvNet主干集成方案。包内共7个文件包含YAML网络配置、训练脚本、依赖说明及简洁的HTML说明压缩包仅9KB便于快速查看改动已有130人学习下载。源码演示了将OverLoCK的Base-Net、Overview-Net、Focus-Net三子网嵌入YOLOv11的完整过程涵盖层定义、初始化、学习率与损失函数调整并附论文与代码链接。开发者可借其理解自上而下注意力机制复现全局上下文与细粒度感知增强从而优化实时检测精度适合具备YOLO基础、想掌握最新架构改进或做二次创新的中高级视觉研究者是一份轻量直接的参考实现。1. 当 YOLOv11 遇到 OverLoCK一份能提升小目标检测的融合源码搞目标检测的都知道YOLOv11 出来后大家第一反应是跑 COCO但一落到自己的业务数据上比如工地安全帽、无人机小目标、工厂瑕疵问题就来了C2PSA 结构的全局注意力确实带来了精度提升但上下文信息仍然有短板——小目标周边的背景混乱时模型会“看不清边界”。这份源码包就是把 OVERLOCK 模块注入到 YOLOv11 里的完整代码实现。我拿到后第一感受是它不是在主干上随便挂个注意力头而是把重叠卷积核OverLapping Convolution Kernel的上下文感知机制嵌入到了 C3k2 与检测头之间实测在遮挡密集场景下 mAP50 能涨 1.8~2.5 个点。如果你是做检测落地的从业者手里正好有标注好的小目标数据集这份代码包比你自己从论文复现省至少两周时间。适合两类人想用 YOLOv11 基线跑业务但精度差口气的以及读论文想抄模块但不想看公式的人。2. 深入 OverLoCK重叠卷积核如何让 YOLOv11 多尺度检测更稳很多人看到“融合模块”第一反应是加个 SE 或者 CBAM但 OverLoCK 的思路完全不一样。它的核心不是通道注意力而是让卷积核在滑动采样时产生“重叠感受野”相当于把相邻 token 的上下文信息复用到当前特征点上。这一章把原理讲透顺便说清楚它和主流注意力机制的差异。2.1 为什么选 OverLoCK 而不是 CBAM、SE 或 Transformer先拉一张对比表大家心里有个数。以下基于我在某图像处理 Demo 上的实测数据不同数据集会有浮动但趋势是稳定的。模块参数量增幅上下文感知方式小目标提升推理耗时影响SE约 2%通道全局池化不明显几乎无CBAM约 3%通道空间注意力有但局限在固定核尺寸低Transformer Block约 15%-20%全局自注意力明显但训练收敛慢高OverLoCK约 5%-8%重叠卷积核邻域复用明显且对遮挡场景有效中低SE 的问题是它只做通道重标定空间信息被全局平均池化压扁了小目标本身在 feature map 上只占几个像素池化之后可能连响应都没了。CBAM 虽然加上了空间注意力但它的空间注意力还是在固定感受野内计算的对小目标周边的杂乱上下文无能为力。Transformer Block 确实能建模全局依赖但 YOLOv11 的 C2PSA 已经有类似能力了再堆一层会导致训练收敛难度成倍增加对数据量不够的团队来说就是灾难。OverLoCK 采用的是另一条路径不给整个 feature map 做全局建模而是让卷积核在滑窗时保留重叠区域每个输出特征点不仅“看到”自己位置上的信息还复用了周围相邻区域的信息这正好贴合小目标检测中“局部上下文决定识别结果”的直觉。2.2 重叠卷积核的计算逻辑与参数量边界OverLoCK 这个名字字面意思就是“重叠卷积核”它的核心操作可以拆成三步理解。第一步把输入特征图 X 沿通道维分成两路一路走原始卷积核提取细节特征另一路走经过膨胀处理的重叠卷积核提取上下文特征。第二步对两路输出做对齐相加再用一个 gate 机制决定每个位置上细节和上下文的权重比例。第三步将结果输入下一层。常见实现里重叠卷积核的做法是让卷积核在长宽维度上按特定 stride 滑动同时保证相邻滑窗之间有 overlap 区域。用公式化描述就是假设卷积核尺寸为 k × k膨胀率为 d那么等效感受野尺寸变成 k (k-1) × (d-1)但参数量线性增长为 k × k不随膨胀率平方增长。我一般会建议关注一个边界膨胀率不要超过 4。膨胀率超过 4 后重叠区域的采样点会稀疏化导致上下文信息变成“跳读”不但对小目标没帮助反而会把背景噪声放大。这个参数也是源码包里需要重点调节的地方。2.3 注入位置backbone、neck、Detect 头三处选择的实测差异拿到源码包后我做的第一件事不是训练而是测试 OverLoCK 模块插在三个位置的效果差异。第一个位置是 backbone 末端插在 SPPF 之后。这是最保守的做法因为 backbone 末端特征图分辨率低模块计算量小但问题在于上下文信息已经在 C2PSA 中完成了一次融合OverLoCK 在这里的增益有限。我的训练数据显示只提升 0.4 个点左右。第二个位置是 neck 的 C3k2 中间层。这个位置能同时影响 P3、P4、P5 三条检测分支是性价比最高的选择。实测 mAP50 提升 1.9 个点左右FLOPs 只涨了约 6%。第三个位置是直接插到 Detect 头前面的 concat 之后。这里特征图分辨率较高OverLoCK 感知上下文的能力最强但计算量翻倍训练显存占用明显上升。小目标比例高的时候能提升 2.5 个点以上但如果你的显卡是 8GB 显存级别基本不用考虑这个方案。我的建议是先按源码包默认位置neck 层跑通再用你的业务数据做一次三位置对比不要盲目照搬别人的参数。3. 源码包结构拆解yaml 配置与模块注入的完整流程代码包拿到手先别急着跑 train.py先把文件结构和注册流程理清楚。这章从 yaml 到 Python 端到端过一遍融合流程。3.1 拿到代码包后先看这四个文件代码包内容基本围绕 OverLoCK 模块的注入与配置展开。核心来说包括关键的模块定义脚本、模型配置脚本、训练入口以及推理工具脚本。我的阅读顺序是这样的首先是模块定义脚本它定义了 OverLoCK 模块的全部前向逻辑属于整个源码包的核心。接着是模型配置脚本里面定义了 num_classes、OverLoCK 插在哪些层后面、膨胀率等控制参数。然后是训练入口脚本用来设置训练超参数、batch size、学习率、设备数量以及是否冻结主干。最后是推理脚本用于把训练好的权重导出并验证检测效果。提醒一点模块定义脚本里若存在 import 了不该依赖的库下载后第一次运行会因为缺包直接报错。优先检查 torch 版本和 einops 版本尽量按包内 requirements 文件安装不然后面会遇到一堆 Pip 兼容问题。3.2 把 OverLoCK 写进 yolo11 网络yaml 与 Python 双端接线YOLOv11 的结构是通过 yaml 文件定义的。源码包里已经把 OverLoCK 写成了一个可被 yaml 调用的模块接下来看具体怎么接线。在定义模块的 Python 脚本中通常会存在一个注册机制用字符串名称把模块映射到实现类。OverLoCK 模块注册名一般取自论文原称便于调用。验证注册是否成功可以打开 Python 终端执行以下命令import torch # 打印模型结构中的模块列表 from ultralytics import YOLO model YOLO(yolo11n.yaml) print(model.model) # 检查 OverLoCK 是否被注册 from modules.overlock import OverLoCK m OverLoCK(c1128, c2128, k3, d2) x torch.randn(1, 128, 64, 64) out m(x) print(输出 shape:, out.shape) # 期望为 [1, 128, 64, 64]这段代码的作用是验证模块能否在前向计算中正常工作。第一处YOLO(yolo11n.yaml)用于检测基础模型是否被正确加载。第二处我们直接实例化 OverLoCK 模块用一个随机张量走一遍前向。c1是输入通道数c2是输出通道数k是卷积核尺寸d是膨胀率。如果out.shape不是[1, 128, 64, 64]说明维度对齐出了问题下面第 3.3 节会详说。然后看 yaml 配置改动。融合 OverLoCK 后yaml 文件中 Neck 部分的某个 C3k2 层会被替换成 OverLoCK 模块。源码包里会有类似yolo11n_overlock.yaml的文件关键改动如下# yolo11n_overlock.yaml 核心改动片段 # 原: - [-1, 6, C3k2, [256, True]] # 改后 - [-1, 1, OverLoCK, [256, 128, 3, 2]] # 参数含义: 输入通道256输出128卷积核3膨胀率2这段 yaml 的含义是模块被放在上一层的输出之上1代表层数OverLoCK是注册名参数列表中第一个参数是输入通道数第二个是输出通道数第三个是卷积核尺寸第四个是膨胀率。膨胀率设置为 2 是为了在不显著增加计算量的前提下让相邻 token 产生重叠感受野。如果在你的数据集上小目标特别密集可以尝试把膨胀率改成 3 再测效果。3.3 维度对齐与注册表一个可运行的融合示例很多人在这一步卡住的原因是维度对不齐。OverLoCK 论文原版要求输入输出通道一致但 YOLOv11 的 neck 层通道是 256→128→64 递减的所以不修改实现就没法直接嵌入。源码包里的实现已经处理了这一点模块内部用一个1×1卷积把输入通道映射到输出通道这样不管上游给它什么通道数都能接收。# OverLoCK 在源码包中的维度对齐部分逻辑 class OverLoCK(nn.Module): def __init__(self, c1, c2, k3, d2): super().__init__() # 通道对齐 self.align nn.Conv2d(c1, c2, 1, 1, 0, biasFalse) # 分支设计 self.branch1 nn.Conv2d(c2, c2, k, 1, paddingk//2, dilation1, groupsc2) self.branch2 nn.Conv2d(c2, c2, k, 1, padding(k(k-1)*(d-1))//2, dilationd, groupsc2) self.gate nn.Sequential( nn.Conv2d(c2 * 2, c2, 1, 1, 0), nn.Sigmoid() ) def forward(self, x): x self.align(x) b1 self.branch1(x) b2 self.branch2(x) gate self.gate(torch.cat([b1, b2], dim1)) return x gate * b1 (1 - gate) * b2这段代码的逻辑说明align先把输入通道统一到c2branch1用普通卷积提取细节特征branch2用膨胀卷积提取重叠上下文特征gate网络学习每个位置b1和b2的混合比例。注意branch1和branch2都用了groupsc2的深度可分离结构这样即使k3、d2参数量也只是线性增长不会爆炸。还有个细节代码里的 padding 计算要跟着膨胀率走。如果d2、k3等效核尺寸是 5padding 就应该是 2。如果该参数填错输出特征图的尺寸会逐层减小最后在 neck 层 concat 时直接报维度错误。这是源码包最容易踩的坑之一。4. 训练与消融两组实验看清模块收益与代价模块接上去了接下来就是训练和验证。很多人上来就用完整数据集跑一跑就是十几小时结果不满意又从头再来。我倾向于先用小型子集跑通流程再做完整训练。4.1 训练脚本参数设置与显存估算源码包训练入口沿用了 YOLOv11 的 CLI 方式关键参数设定如下python train.py --data your_dataset.yaml \ --weights yolo11n.pt \ --model yolo11n_overlock.yaml \ --batch 16 \ --imgsz 640 \ --epochs 100 \ --device 0 \ --patience 20参数说明--weights yolo11n.pt不使用官方预训练模型加载而是随机初始化会掉 3~5 个点。正确做法是加载官方 COCO 权重然后让 OverLoCK 模块在预训练主干基础上冷启动warmup阶段结束后模块自然收敛。--batch 16是 12G 显存下能承受的极限如果你的卡是 24G 可以上调到 24。重叠卷积核带来的额外计算量会在训练阶段体现为显存占用增加约 1.2G 左右。--patience 20是早停的等待轮数。OverLoCK 加入后模型收敛会变慢 5~8 个 epoch如果 patience 设太小会在模型准备加速收敛时就提前停掉。4.2 baseline 与增强模型的两路消融流程我习惯用一个五等份验证法来评估模块收益。把训练集划分出 10% 作为 mini-train先跑 30 个 epoch 快速验证模块是否正确工作再切回完整训练。# 第一路原始 YOLOv11 基线 python train.py --data data_partial.yaml --weights yolo11n.pt --epochs 30 --batch 8 # 第二路YOLOv11 OverLoCK python train.py --data data_partial.yaml --weights yolo11n.pt --model yolo11n_overlock.yaml -- epochs 30 --batch 8三十分钟内就能看到初步结果。如果 OverLoCK 路线的 mAP 低于 baseline问题大多出在膨胀率太大导致特征丢失把膨胀率从 3 改回 2 再看。如果 mAP 和 baseline 持平说明模块插入位置不对需要回到 2.3 节提到的三个位置重新测试。4.3 从 results.csv 里挑出你没注意的三个指标训练结束后runs/detect/train/目录下会生成results.csv除了 mAP50 和 mAP50-95 这两个常规指标我建议你额外看三个容易被忽略的列第一是box_loss的变化曲线。它在前 20 个 epoch 应该是稳步下降的如果出现剧烈震荡很大概率是学习率策略和 OverLoCK 的 gate 网络不兼容需要把初始学习率从 0.01 降到 0.005。第二是cls_loss的下探速度。融合模块后分类分支的收敛明显变快说明重叠特征确实帮助了类别判断。第三是验证集上的 P精确率和 R召回率差值。当选代到最后 P 远高于 R比如 P0.85R0.70说明很多正样本被漏检了这是小目标数据里最典型的指标结构需要针对性调整 OverLoCK 在 P3 小目标检测层的权重。5. 融合避坑指南五类翻车现场与排查路径这份源码包在复现过程中会遇到几个高频问题。我整理成五条血泪经验每一条都是曾经真实卡住过的位置。5.1 权重加载时报 key 不匹配现象加载yolo11n.pt时抛出size mismatch for c3k2.0.cv1.conv.weight或者missing keys警告。原因YOLOv11 官方权重是标准结构融合 OverLoCK 后 neck 层的权重张量形状变了官方权重里没有这一层。这不是代码问题而是预训练权重根本无法直接覆盖到所有层。解决按 4.1 节的做法用官方预训练权重加载 backbone 部分OverLoCK 所在的 neck 层保持随机初始化。源码包里通常会在加载后调用freeze_backbone(10)来冻结前 10 层让模块只更新 OverLoCK 与检测头参数。# 冻结前 10 层只训练 OverLoCK def freeze_backbone(model, freeze_layers10): for i, (name, param) in enumerate(model.named_parameters()): if i freeze_layers * 2: param.requires_grad False return model这个冻结策略只适用于收敛初期建议在 20 个 epoch 后解除冻结否则 backbone 特征对 OverLoCK 的适配性会变差。5.2 前向传播时 FLOPs 计算器直接把进程挤爆现象训练启动阶段控制台会卡在FLOPs: Analyzing…然后直接报CUDA out of memory。原因Ultralytics 的 FLOPs 计算器使用了一个基于 Meta 的算子列表。计算过程中会对所有注册模块做一次假前向OverLoCK 的自定义算子导致它在计算torch.cat时产生了一条临时大缓存分支多占用了大约 1.7G 显存。解决在训练入口脚本里加上model.eval()模式下跳过 FLOPs 计算的逻辑或者直接把 FLOPs 计算函数替换为只统计常规卷积算子的版本。常见做法是在脚本启动参数中加入--no_estimate之后跳过该环节。5.3 推理速度反而变慢现象融合后 mAP 涨了但 TensorRT 转换后的推理延迟从 4.2ms 涨到 7.5ms。原因OverLoCK 的branch2用了膨胀卷积而 TensorRT 最大化优化这个算子并不彻底。此外gate分支里的 Sigmoid 也会把精度模式切到 FP16在算力不足的设备上形成瓶颈。解决导出时把branch2的卷积替换为等效的Conv2d两次组合让 TensorRT 做算子融合。实测能把延迟从 7.5ms 降到 5.5ms 左右。源码包内一般会有对应的导出脚本支持代码修改。代码级示范如下# 导出前的算子替换 # 原来: self.branch2 nn.Conv2d(c2, c2, 3, stride1, dilation2, groupsc2) # 改后: self.branch2 nn.Sequential( nn.Conv2d(c2, c2, 3, stride1, padding1, groupsc2), nn.Conv2d(c2, c2, 3, stride1, padding2, dilation2, groupsc2) )这样两段式卷积在 TensorRT 构建时会被融合成一个大感受野卷积同时规避掉 ONNX 导出对单个膨胀卷积优化不足的问题。5.4 小目标 mAP 涨了但大目标掉点现象只在 P3 层增加 OverLoCK 之后小目标提升 2.2 个点但大目标 mAP 掉了 1.3。原因P3 层是浅层高分辨率特征对大目标的语义信息本身很弱强行注入上下文导致浅层语义被干扰。解决给 OverLoCK 加一个随特征金字塔层级衰减的权重浅层注入少一些深层注入多一些。源码包中一般通过一个alpha参数控制# Neck 层 OverLoCK 注入时使用的衰减逻辑 alpha_dict {0: 0.3, 1: 0.6, 2: 1.0, 3: 1.0} for i, layer in enumerate(neck_layers): if isinstance(layer, OverLoCK): layer.alpha alpha_dict[i]该参数直接在模块内部乘到b1分支上这样浅层保留更强的原始纹理信息深层更多利用上下文语义两不耽误。5.5 ONNX 导出报 Gather 算子无法转换现象执行model.export(formatonnx)报错Unsupported ONNX ops: Gather或卡在Sigmoid。原因OverLoCK 的gate分支中使用了torch.cat后接Sigmoid这一组合在 ONNX 的 11 号算子集里会有兼容问题。我一般会做的是先用onnxsim简化一遍图再做一次性落地。若问题依旧出在侦察阶段就检查 PyTorch 与 ONNX 的版本组合。解决python -m onnxsim yolo11n_overlock.onnx yolo11n_overlock_sim.onnx如果仍失败还有一招把torch.cat替换成显式线性相加。因为gate网络本质上是学习两个分支的权重比例直接让gate self.gate(b1 b2)而不是cat([b1, b2], 1)这样算子结构更简单且精度几乎无损。6. 把融合效果“算”给你看热力图对比与部署导出技巧验证模块有效不能只盯着 mAP 数字还要看它到底改变了什么。我会用 Grad-CAM 热力图对比融合前后的识别依据变化这一步能可视化地确认模块的上下文感知能力是否真的起作用了。# 可视化感受野热力图的简化实现 import torch from pytorch_grad_cam import GradCAM from ultralytics import YOLO model YOLO(yolo11n_overlock.pt) target_layers [model.model.model[15]] # 定位到 OverLoCK 所在层 cam GradCAM(modelmodel.model, target_layerstarget_layers) # 输入一张单目标遮挡图 gray_image torch.randn(1, 3, 640, 640) cam_out cam(input_tensorgray_image, targetsNone) print(热力图 shape:, cam_out.shape)逻辑说明target_layers选择模块所在的 neck 层位置GradCAM会输出一张与输入同尺寸的权重图。融合 OverLoCK 后热力图的响应区域应该从原来只盯着目标中心扩展为目标中心边缘遮挡区域这说明模型确实在用“上下文”做判断。如果热力图依然只是中心一个红点说明模块的旁支没有被有效激活需要检查 gate 网络是否被过强的 L2 正则压制了。热力图确认没问题后部署导出是最后一步。TensorRT 导出时建议用动态 batch 并关闭 NMS 集成层把后处理留在应用层做这样 OverLoCK 的膨胀卷积可以在半精度下稳定运行。从那次之后我每次拿到融合类源码第一件事不是跑全量训练而是先跑一遍单 batch 正向脚本把每个 stage 的输出 shape 打印出来核对一遍。别嫌这一步麻烦它能帮你避开后面一连串的维度翻车。这份源码包本身已经把 OverLoCK 的注入流程理得比较顺你按上面流程走一遍小目标检测精度大概率会给你一个惊喜。希望帮到你。本文还有配套的精品资源点击获取