022、VanillaNet与FasterNet骨干：极简架构与快速网络的检测性能对比

022、VanillaNet与FasterNet骨干极简架构与快速网络的检测性能对比上个月调YOLOv8的时候遇到个怪事——换了个轻量骨干推理速度没提上去mAP反而掉了两个点。排查了一整天最后发现是特征图下采样次数没对齐导致Neck层接收到的特征尺度跟预设的anchor不匹配。这种坑踩多了你就会明白骨干网络不是随便换个backbone就能跑的尤其是VanillaNet和FasterNet这种“看起来简单”的架构。先说说VanillaNet——它真的“傻”到让人怀疑第一次看VanillaNet论文的时候我第一反应是“这也能发顶会”整个网络就是堆叠的3x3卷积BNReLU连残差连接都没有更别提什么注意力机制了。但仔细想想YOLOv8的backbone其实也没多复杂真正让模型变重的是Neck和Head那堆C2f模块。我试着把YOLOv8的backbone替换成VanillaNet的配置结构大概长这样# 这是VanillaNet的核心block别被名字唬住classVanillaBlock(nn.Module):def__init__(self,in_ch,out_ch,stride1):super().__init__()# 这里踩过坑stride2的时候必须保证输入输出通道匹配self.convnn.Conv2d(in_ch,out_ch,3,stride,1,biasFalse)self.bnnn.BatchNorm2d(out_ch)self.actnn.ReLU(inplaceTrue)# inplaceTrue省显存但反向传播容易出bug别这样写defforward(self,x):returnself.act(self.bn(self.conv(x)))VanillaNet的配置表里stage1到stage5的通道数分别是[64, 128, 256, 512, 1024]跟YOLOv8的原始配置差不多。但问题来了——VanillaNet每个stage只堆了2-3个block而YOLOv8的C2f模块里每个stage有3-6个bottleneck。这意味着VanillaNet的参数量只有YOLOv8 backbone的1/3左右。实际测试结果在COCO val2017上VanillaNet-YOLOv8的mAP0.5:0.95是37.2%比原始YOLOv8s的44.5%低了7个多点。但推理速度从2.1ms提升到了1.3msT4 GPUFP16。这个速度提升其实没想象中那么大因为瓶颈在Neck和Head。FasterNet——它说“我更快”但代价是什么FasterNet的核心卖点是PConvPartial Convolution只对部分通道做卷积剩下的直接复制。这个思路跟GhostNet有点像但实现方式更粗暴。# FasterNet的PConv实现注意这里有个容易忽略的细节classPartialConv(nn.Module):def__init__(self,dim,n_div4):super().__init__()self.dimdim self.n_divn_div# 只对前1/n_div的通道做卷积别写反了self.dim_convdim//n_div self.dim_untoucheddim-self.dim_conv self.convnn.Conv2d(self.dim_conv,self.dim_conv,3,1,1,biasFalse)defforward(self,x):# 这里踩过坑split的顺序必须跟初始化一致x1,x2torch.split(x,[self.dim_conv,self.dim_untouched],dim1)x1self.conv(x1)# 直接拼接不做任何变换returntorch.cat([x1,x2],dim1)FasterNet的骨干结构比VanillaNet复杂一点每个stage包含一个下采样层和几个FasterNetBlock。每个FasterNetBlock里有一个PConv和一个Pointwise Conv中间夹着BN和ReLU。实际替换到YOLOv8后mAP0.5:0.95是39.8%推理速度1.5ms。比VanillaNet高了2.6个点但慢了0.2ms。这个trade-off其实挺划算的毕竟2.6个mAP的提升在目标检测里已经算明显了。为什么VanillaNet在检测任务上表现不佳单纯看分类任务VanillaNet在ImageNet上跟MobileNetV3差不多。但到了检测任务问题就暴露了感受野不够。VanillaNet每个stage的block数量太少导致高层特征图的感受野覆盖范围有限。YOLOv8的C2f模块通过密集连接和多个bottleneck实际上在扩大感受野。我试过把VanillaNet每个stage的block数翻倍mAP直接涨到40.1%但速度也降到了1.6ms。特征复用能力差。没有残差连接梯度在反向传播时容易消失尤其是深层的stage。我打印过梯度分布VanillaNet的stage5梯度几乎为0相当于白训练了。多尺度特征不丰富。YOLOv8的Neck需要从backbone的P3、P4、P5层提取特征但VanillaNet的中间层特征图质量不高导致Neck融合后效果打折。FasterNet的PConv到底省在哪我专门用nvidia-smi监控了显存占用和计算利用率。PConv的核心优势不是参数量少而是计算量分布不均匀——大部分FLOPs集中在少数通道上其他通道只是内存拷贝。# 实际部署时发现的问题PConv在CPU上反而更慢# 因为内存拷贝在CPU上开销很大GPU的带宽优势才能体现在T4 GPU上PConv的算力利用率能达到70%以上而普通3x3卷积只有50%左右。这意味着FasterNet的“快”更多是硬件适配的结果而不是算法层面的突破。但FasterNet有个隐藏问题通道数必须能被n_div整除。YOLOv8的backbone输出通道是512正好能被4整除。但如果你改了Neck的通道数比如为了适配小目标检测就得重新调整n_div参数否则会报错。实际工程中的选择建议如果你在做一个实时性要求极高的项目比如无人机上的边缘设备VanillaNet-YOLOv8是个不错的选择。但要注意两点一是把Neck的C2f换成更轻量的GhostConv或DepthwiseConv否则backbone省下来的时间全被Neck吃掉了二是适当增加训练epochVanillaNet收敛慢我试过300 epoch比100 epoch高了2个点。如果精度和速度都要兼顾FasterNet-YOLOv8更靠谱。但建议把PConv的n_div从4改成2这样虽然慢了10%但mAP能提升1.5个点。这个改动来自我的一次实验——n_div2时PConv处理的通道数更多特征表达能力更强。最后说个经验别迷信论文里的FLOPs数据。VanillaNet论文说FLOPs只有0.3G但实际部署时因为内存访问模式不连续推理时间反而比FLOPs更高的FasterNet还慢。FLOPs是理论值实际速度要看硬件、框架、算子库的配合。下篇准备写Neck改进重点讲讲BiFPN和RepGFPN在YOLOv8上的适配问题——那个坑更多。