YOLOv11主干替换实战：PVTv2 Transformer如何提升小目标检测精度

做目标检测模型调优的同行应该都有这种感觉：YOLOv11在通用场景里当基线非常顺手，速度快、部署友好、改造成本也低，但真到了小目标密集、目标重叠、背景复杂的数据集上，它的漏检率和定位偏差往往会突然变得扎眼。我排查过不少项目，最后发现问题常常不在检测头或者损失函数，而在主干网络给出的特征表示不够强。原生的卷积主干在局部感受野上占便宜，但很难把“远处的上下文”和“眼前的细节”在同一个层级里统一起来，这种先天限制不是靠后接几个模块就能完全补回来的。

所以这次实验的思路非常直接：把YOLOv11的主干网络整体换成金字塔结构的Transformer主干，具体选用PVTv2，利用它的多阶段特征输出和全局-局部结合的表达能力，把检测头的输入质量拉高。这篇内容我会拆开讲清楚：PVTv2到底好在哪、替换主干时哪些对齐细节最容易被忽略、训练要避哪些坑，以及消融实验怎么设计才不会被审稿人或同事挑毛病。

1. 这个改进要解决什么问题

1.1 YOLOv11原生主干的瓶颈

YOLOv11的架构虽然已经做了不少工程优化，但本质上还是CNN偏好的特征提取范式。CNN卷积核的感受野受限，即便深层堆叠卷积理论上能覆盖更大区域，实际训练时网络很难真的把远距离依赖学得干净。尤其对小目标来说，一个目标可能只有十几个有效像素，单独依靠局部特征做分类，很容易被背景噪声带偏；这时候如果缺少全局上下文来帮助判断“这个东西处在什么环境、周围有什么参照物”，漏检几乎是必然的。

我之前在某个行人密集场景的项目里，试过在检测头上加注意力、改损失函数、换NMS策略，涨点都很有限。最后把某个层级的特征图可视化出来才发现，主干对重叠行人区域的响应重叠太严重，特征区分度不够。这就不是说回归头能解决的问题了，必须从特征源头下手。

1.2 为什么选PVTv2而不是其他Transformer主干

市面上能做主干替换的Transformer模型其实不少，但很多模型替换起来都挺痛苦。纯ViT输出的是单尺度序列，要拿来做目标检测，得自己设计reshape、上采样、多尺度分支，工作量大且特征对齐容易出问题。SWin Transformer虽然也是金字塔结构，但是窗口注意力机制在小窗口边界处的信息交互相对受限，融合全局信息时总有点隔靴搔痒。

PVTv2的优势在于，它本身就是按金字塔思路设计的，多个阶段分别输出不同分辨率的特征图，天然适合对接YOLO体系的P3、P4、P5多尺度检测头。同时它在全局注意力部分做了效率优化，不像原始Transformer那样动不动就显存爆炸，算是精度和训练成本之间的一个平衡点。

1.3 这个改进适合谁、不适合谁

做学术实验、投论文、参加榜单评测的同学，需要刷AP的，可以重点参考；项目里检测目标偏向小目标、密集遮挡场景的，这个替换很有机会带来稳定收益。但如果你做的是移动端或者推理延时要求极高的场景，PVTv2即便是tiny版本也有代价，建议先评估算力，别盲目上。

2. PVTv2主干的原理拆解

2.1 金字塔结构在PVTv2里是怎么工作的

PVTv2的金字塔结构可以理解成“越深越抽象、越深分辨率越低”。以640×640输入为例，它通常会有四个阶段，各阶段输出的特征图步长分别是4、8、16、32左右，对应不同粒度的特征。浅层阶段保留边缘、纹理和局部细节，深层阶段提炼语义和类别信息，这种设计和YOLO原本预期的多尺度特征是同一个逻辑。

真正关键的是，PVTv2的每个阶段内部会做一次特征序列化，也就是把二维特征图展平成一堆patch token，再交给Transformer块处理。但和纯ViT不同，它在不同阶段会动态调整token数量和解耦方式，既维持了金字塔，又控制了计算量。这就像一个大楼的分层停车场，每层停的车尺寸不同，但楼层之间有升降通道，信息可以流通。

2.2 重叠补丁嵌入、线性SRA与卷积前馈网络

要理解PVTv2为什么适合替代YOLOv11的主干，得拆开看它的三个核心模块。

这几个模块的关系很像个组合拳：重叠补丁嵌入负责把原始图像切成信息连续的小块，线性空间缩减注意力负责在全局范围内找到哪些位置值得多关注，卷积前馈网络再对注意力结果做局部精修。全局注意力看得远，局部卷积扣得细，两个信息流叠在一起，特征表达自然比单纯堆卷积丰富。

2.3 这种组合为什么能涨点

从信息流的角度来分析，检测任务最怕两种情况：一是只看局部陷入噪声，二是只看全局丢失细节。PVTv2的设计恰好把两者拧在一起。比如在一个街景图里检测远处的小行人，全局注意力可以捕捉到道路、斑马线等上下文线索，帮助网络判断“这里大概率有人行区域”，而局部卷积又能保留行人的轮廓纹理，不至于模糊成一团。

换到YOLOv11里，主干能力变强，neck后面接到的特征质量就会明显提升，检测头在回归和分类时拿到的输入更“干净”，涨点就是水到渠成的事。不过这里要提醒一句：这种提升不是白来的，训练难度、显存占用和收敛速度都会变，需要配套的调参策略。

3. 替换YOLOv11主干的实操设计

3.1 整体替换流程

我建议按下面这个顺序来改，避免一开始就把网络结构搞乱：

1. 先把原版YOLOv11跑通一个基线，记录mAP和训练成本，后面对比才有参照。
2. 修改模型构建文件，把backbone部分从原来的CNN主干改成PVTv2，其余neck和head部分暂时不动。
3. 确认输入尺寸，明确需要从PVTv2拿哪几个阶段的特征，通常是stride为8、16、32的三级特征。
4. 对每一级特征做1×1卷积投影，把通道数对齐到neck期望的输入通道。
5. 先加载预训练权重做小规模调试，确认前向、反向、loss曲线都正常后再扩大训练。

这里的第4步最容易被忽略。很多人替换主干后直接报维度错，或者训练跑起来但AP完全不对，基本都出在特征通道和分辨率对齐这个环节。

3.2 特征层对齐的原则和坑

YOLOv6、YOLOv8、YOLOv11这类模型，neck输入端一般会接收三个尺度的特征图，通常对应步长8、16、32，也就是P3、P4、P5。PVTv2的四个阶段输出步长大致为4、8、16、32，所以最简单的方案是跳过stage1，只取后三个阶段来对接。

但这里有个细节容易翻车：不同版本PVTv2的stage输出通道数各不相同，你不能假设固定值，必须跑到代码里打印出来，然后再用1×1卷积投影。如果忘记做投影，neck模块的通道参数就会对不上；如果用了步长不匹配的特征，则会导致不同层的语义层级混乱，检测头会“信息串味”。

提示：特征对齐不只是通道数对齐，还要看感受野和步长语义是否一致。宁可多做一个投影卷积，也不要图省事直接拼接。

3.3 主干接口改造的最小实现

我给出一个最小改造逻辑，方便你在自己的工程里快速定位修改点：

class YOLOWithPVT(nn.Module): def __init__(self, pvt_cfg, neck_cfg, head_cfg): super().__init__() # 构建PVTv2主干，只保留stage2、stage3、stage4输出 self.backbone = build_pvtv2(pvt_cfg, return_layers=[2, 3, 4]) self.stage2 = nn.Conv2d(pvt_cfg.out_channels[0], neck_cfg.in_channels[0], 1) self.stage3 = nn.Conv2d(pvt_cfg.out_channels[1], neck_cfg.in_channels[1], 1) self.stage4 = nn.Conv2d(pvt_cfg.out_channels[2], neck_cfg.in_channels[2], 1) self.neck = build_neck(neck_cfg) self.head = build_head(head_cfg) def forward(self, x): feat2, feat3, feat4 = self.backbone(x) feat2 = self.stage2(feat2) feat3 = self.stage3(feat3) feat4 = self.stage4(feat4) feats = self.neck([feat2, feat3, feat4]) return self.head(feats)

这段代码只是一个集成示例，不代表完整可直接训练的实现。实际工程里你还要处理初始化方式、BN层同步、checkpoint、推理脚本等。核心思路是：主干替换后，把neck和head的接口稳定住，再逐步调整细节。

3.4 预训练权重与迁移策略

直接随机初始化PVTv2后丢进检测任务里训练，我试过一次，收敛极其痛苦。Transformer不像CNN那么“容易带”，它需要更长的预热和更强的正则。正确做法是：

• 下载ImageNet预训练的PVTv2权重，作为backbone初始化。
• 加载时用strict=False，只加载主干部分，忽略neck和head的缺失键。
• 对新增的通道投影层，用Kaiming初始化。
• 训练初期可以把backbone冻结一两轮，让neck和head先适应当前特征分布，再统一解冻微调。

这个策略看起来慢，实际上比“一把梭”科学得多。

4. 训练策略与关键参数

4.1 一份可参考的训练配置

不同显卡、不同数据集的参数肯定要调，但可以先给一份我常用的启动配置：

如果GPU资源紧张，可以把输入尺寸从640降到512，或使用梯度累积来模拟大batch，而不是硬扛OOM。BatchSize过小时BN统计噪声会变大，Swish、Ghost这些轻量模块的稳定性也会受影响，得注意。

4.2 提升训练稳定性的技巧

Transformer主干训练时最容易遇到两类问题：一类是训练开始阶段loss震荡，另一类是后期掉点。两个问题都可以通过分阶段训练缓解。

第一阶段先冻结backbone，只训练neck和head，让检测头先学会基础输出；第二阶段把backbone解冻，用更小的学习率做全模型微调；第三阶段再开启ema和multi-scale训练，逐步逼近最佳性能。这个过程可以配合梯度裁剪，梯度模长超过5.0的时候截断，避免异常loss把权重带飞。

还有一个很容易忽略的点：混合精度。PVTv2的计算量比较大，开启AMP能显著提高训练速度，但要注意某些算子可能不支持低精度，建议用自动类型转换接口做逐算子适配，别一次性全开再等报错。

4.3 消融实验设计模板

做改进方案，尤其如果目标是投论文，消融实验几乎是躲不掉的。建议按下面这张表来设计：

上面数据仅供参考，实际效果依数据集浮动。关键是形成明显的递进逻辑，每一步改动都能对应到mAP变化和原因解释，这也是防审稿人追问的必备功课。

5. 踩坑实录与问题排查

5.1 一上Transformer主干显存就爆

这是最常见的开局问题。解决办法按优先级来：先调小batch，再降输入分辨率，还不行就开梯度检查点。有人可能会直接放弃，但梯度检查点其实是性价比很高的手段，虽然前向会重复计算一次，但能让显存占用大幅下降。再到方舟日志里看具体哪一层的显存峰值高，如果是自注意力模块，就尝试把attention的窗口做局部化处理，虽然多少会影响全局建模，但比直接用不了要强。

5.2 训练初期loss震荡严重

如果你发现batch loss前几十轮像过山车，大概率是head还没热身，backbone已经带着一个预训练分布直接灌进来了。这时的正确操作不是调大学习率，而是调小学习率，并且延长warmup轮数。我的习惯是把warmup从3轮拉长到10轮，同时冻结backbone。等head输出的loss不再大幅跳变，再解冻backbone微调，震荡会明显减弱。

另外还要检查数据增强强度。太强的马赛克增强加在Transformer主干上，有时会导致收敛不稳，建议在早期阶段把增强强度减弱，后期再逐步加回去。

5.3 换完主干AP反而倒退

如果实验做完发现AP比原版还低，先别急着怀疑方案，大概率是下面几个坑之一：

• 特征层步长选错了，比如把stage2、3、4当P3、P4、P5用，但实际步长语义不匹配。
• 预训练权重没加载对，纯随机初始化的Transformer主干很难单独训好。
• 训练轮数不够，Transformer特征需要一个更长的适应周期，短线训练容易吃亏。
• 通道投影模块忘记加，或者直接用不匹配的通道硬拼接，导致neck信息失衡。

排查方法也很简单：把同一张测试图分别用原版和替换版模型输出特征热力图，对比看目标位置有没有被正确激活。如果热力图响应区域明显偏掉，基本就是对齐问题；如果响应区域正确但分类置信度低，那大概率是训练策略问题。

6. 关于后续扩展的一点个人经验

这次主干替换的研究进展还算顺利，但我想强调的是，真正让方案涨点的往往不是Transformer模块本身，而是替换之后所有配套环节是否足够干净。我在实际操作里的体会是，特征对齐做得越干净，训练策略越保守，最后涨点越痛快。反倒是那些一上来就想杂糅各种注意力的方案，往往改到后面连问题在哪儿都说不清。

另一个有价值的扩展方向是轻量化改造：在PVTv2-tiny基础上，把neck中的冗余卷积砍掉，或者引入更轻的跨尺度融合模块，可以在精度不掉太多的情况下把推理速度拉回来。我手头已经跑出了一组结果，等后续稳定一点再单独分享。如果你们也在做YOLO主干替换，建议先从一个可控的小任务开始，把流程跑顺再上大实验，这是最快验证思路的方式。