YOLO11推理变慢？GSConv与VoV-GSCSP实现Slim-Neck轻量化改造

1. 为什么你的YOLO11推理变慢了：先看Neck，别急着换Backbone

我最早把YOLO11跑起来的时候，第一反应是往Backbone里塞注意力机制，结果显存没降下来，帧率还掉了。后来认真过了一遍结构图才发现，真正拖后腿的往往是Neck这一段。Backbone虽然卷积层数多，但很多参数集中在Stage较深的位置；Neck的输入输出通道动不动就跳到512、1024，3×3卷积一个接一个往上叠。对于一个目标是下沉到边缘设备的项目来说，Neck的冗余比Backbone还明显。

YOLO11的Neck承担的事很简单：把Backbone不同尺度的特征重新拉齐并融合，让Detect头能同时“看得见”小目标和大目标。这个过程中用到的大部分操作就是上采样、拼接、若干卷积块。问题恰恰出在这里，特征拼接之后必须经过降维和跨通道融合，于是C3k2、C2PSA这种模块会在Neck里反复出现。这些模块里的标准卷积，每计算一次都要对输入特征图所有通道做一次空间卷积，相当于每条路上都要排队过卡口，车一多，时间全花在等待上。

GSConv的思路很直接：把标准卷积的活儿拆开。一部分通道走普通1×1卷积，先把通道数压下来；另一部分通道走3×3卷积，但只在逐通道上做空间操作，最后再把两路结果拼到一起。这个操作在不少轻量化模型里都出现过，关键是它没有像MobileNet那样把整个网络结构推翻重来，而是可以当成一个即插即用的卷积块，直接替换Neck里的部分标准卷积。配合VoV-GSCSP这种轻度跨阶段模块，就能把原本厚重的一整段Neck压成一个Slim-Neck版本。

这篇文章就是完整的实操记录。从YOLO11默认Neck的结构拆解，到GSConv和VoV-GSCSP模块的代码实现，再到yaml配置改写、训练对比、常见坑排查，我一整条走下来都写在这。适合两类人看：一类是准备把YOLO11部署到嵌入式设备或低功耗主机上，想尽量保精度又降计算量的开发者；另一类是刚接触模型结构改造，想搞清楚某个模块到底在框架里怎么被加载、怎么被训练的同学。两种基础都能跟上，代码部分我会贴出完整可运行版本。

2. 动手改造前，先把旧Neck的每一层看明白

2.1 YOLO11默认Neck的实际结构

YOLO11的模型定义不是写在Python类里，而是通过yaml文件描述结构，解析器再根据yaml里的层名逐条生成网络。这种做法在工程上很省事，改结构不需要动主干代码，只要会改yaml和新增模块类即可。

默认Neck在yaml里大致长这样：

# YOLO11默认Neck部分（简化展示） - [-1, 1, Upsample, [None, 2, "nearest"]] - [[-1, 6], 1, Concat, [1]] - [-1, 1, C3k2, [512, False, 0.25]] - [-1, 1, Upsample, [None, 2, "nearest"]] - [[-1, 6], 1, Concat, [1]] - [-1, 1, C3k2, [256, False, 0.25]] - [-1, 1, Conv, [256, 3, 2]] - [[-1, 3], 1, Concat, [1]] - [-1, 1, C3k2, [512, False, 0.25]] - [-1, 1, Conv, [512, 3, 2]] - [[-1, 9], 1, Concat, [1]] - [-1, 1, C3k2, [512, True, 0.25]] - [-1, 1, C2PSA, [512, 1]]

解释一下这些字段的含义。方括号里每行代表一个网络层，第一个数字是输入来源，-1表示上一层的输出；第二个数字是重复次数；第三个是模块类名；第四个是传给该模块的参数。

其中C3k2可以看作是YOLOv5时代C3结构的精简版本，它内部主要包含瓶颈残差块和少量卷积。C2PSA则是YOLO11引入的注意力处理模块，内部先做通道变换，再走多头自注意力路径。这两者在Backbone尾部也会出现，但在Neck里重复多次，计算量相当可观。

2.2 默认Neck的计算量到底花在哪里

我一开始想当然地以为，Neck里最贵的应该是那个多尺度注意力模块C2PSA。实测后才发现未必，真正的大头是那几个C3k2里反复堆叠的3×3标准卷积。

以一层通道数为512的C3k2为例，内部至少包含两次输入到中间通道的1×1卷积，以及两个3×3的瓶颈卷积。由于输入特征图的宽度和高度在整个Neck层中并不小（比如80×80或40×40），每一次3×3卷积的乘加次数都是：输出通道数 × 输入通道数 × 3 × 3 × 输出宽 × 输出高。通道数上到512之后，这个数字会迅速膨胀。更关键的是，这类操作会沿着FPN和PAN两条路径重复出现多次，加起来就非常可观。

这也是为什么单纯把Backbone轻量化效果有限：Backbone在一张图上只跑一次，而Neck要同时处理多个尺度的特征。

2.3 C3k2、C2f、C2PSA之间的变体脉络

如果不熟悉YOLO系列，可能会被这些命名绕晕。我站在使用的角度总结一下：C3k2是C3的变体，把原本的瓶颈结构改成可以指定shortcut开关的轻量残差块；C2f是YOLOv8时代的名称，它把C3里的单个分支改成了并行多分支，让信息流动更充分；C2PSA则是把C2f的低层空间融合操作部分替换成了自注意力或通道注意力相关操作，目的是增强跨位置的特征关联。

这三者在结构上并没有质的飞跃，本质上都是“先缩减通道，再局部融合，再拼接/相加”。既然内核相似，替换的时候逻辑上就顺了：我们保留原有进出通道数不变的语义，把中间的融合主体换成计算量更低的模块。

3. Slim-Neck的方案选型：为什么是GSConv加VoV-GSCSP

3.1 GSConv的核心原理和计算量对比

GSConv的核心是把一个标准3×3卷积拆成两路并行：

• 第一路用原始通道做逐通道3×3卷积，只改变空间信息，不跨通道；
• 第二路用1×1卷积完成通道间的信息交换，再通过拼接把结果合并。

既然通道数的信息交换已经被1×1卷积承接，逐通道的3×3卷积就不需要同时处理所有输入通道，计算量自然降下来。

拿一个输入输出都是256通道、特征图尺寸为40×40的卷积来算：

标准3×3卷积的计算量是 256 × 256 × 3 × 3 × 40 × 40，约9.4亿次乘加；GSConv中逐通道3×3卷积只有 256 × 1 × 3 × 3 × 40 × 40，约3686万次，再加上1×1卷积约256 × 128 × 1 × 1 × 40 × 40，约5250万次。整体远小于标准卷积。当然实际还要算输入侧压通道那一次1×1卷积，所以总计算量大概是标准卷积的45%到60%，取决于通道比例设计。

这个节省直接反映在YOLO11的FLOPs上。原版Neck里有多处标准卷积，如果全保留，整个模型的FLOPs很难压下去；换成GSConv后，FLOPs会明显降低，但精度不会像直接用深度可分离卷积那样掉得厉害。

3.2 VoV-GSCSP在Slim-Neck里扮演的角色

GSConv负责的是“单层卷积的轻量化”，VoV-GSCSP则负责“模块级结构重组”。VoV-GSCSP的思路继承自VoVNet里的OSA模块和CSPNet的跨阶段连接，简单说就是：输入特征进来后分两路，一路进入轻量卷积路径做残差融合，另一路直接跳过这些操作，最后两路拼接后通过一个1×1卷积整合。

这种设计的最大好处是保留了梯度回传的短路径。训练时，特征和梯度都能从旁路直接流过，不会因为一连串卷积叠加而出现梯度消失或者信息衰减。另一个好处是减少模块内部的串行深度，让GPU在推理时更容易并发。

我在实际实现里用的是简化版：不堆叠多个GSBottleneck，直接做一次轻量残差融合。这样代码量小、参数少、训练稳定。对于通道数512以下的Neck块，完全够用。

3.3 改造范围确定的3个原则

动手前我给改造划了条边界，不是所有层都换。这里有几个原则可以参考：

• 只换Neck区域的C3k2和C2PSA，不碰Backbone开头几个Stage。Backbone率先提取底层纹理，如果一开始就过度轻量化，后续所有特征质量都会下降；
• Detect头前面的聚合层不换。输出头附近需要足够强的通道表达能力以保证分类和回归精度；
• 通道变化幅度大的地方优先换。比如从256到512、512到1024这些位置，标准卷积的成本最高，GSConv收益最大。

按这个思路改完后，整个Neck的厚度会明显下降，但Backbone和Detect输出维度完全不变，这样训练时可以复用原来的预训练权重，只是未初始化的新模块需要从零开始跑一小段热身。

4. 代码级实现：新增GSConv与VoV-GSCSP模块

4.1 工程上的3个改动点

整个改造在工程上只动三处：模块定义文件、解析器注册和权重加载逻辑、yaml配置。先说模块定义。

YOLO11代码库中的模块一般集中在nn目录下的modules文件里。我在这个文件末尾新增两个类，并沿用框架已有的Conv模块作为基础卷积单元，保证BatchNorm和激活函数风格与全网络一致。

第一个是GSConv：

import torch import torch.nn as nn class GSConv(nn.Module): """通道混合卷积：一半特征走逐通道3x3卷积，一半走1x1通道变换，最后拼接。""" def __init__(self, c1, c2, k=1, s=1, g=1, act=True): super().__init__() c_ = c2 // 2 self.cv1 = Conv(c1, c_, k, s, g=g, act=act) self.cv2 = Conv(c_, c2, 1, 1, g=g, act=act) self.cv3 = Conv(c_, c2, 1, 1, g=g, act=act) self.cv4 = Conv(c_, c_, 3, 1, g=g, act=act) def forward(self, x): x1 = self.cv1(x) x2 = self.cv2(x1) x3 = self.cv4(x1) return torch.cat((x2, x3), dim=1)

这里需要注意，cv2和cv3的输出通道都是c2，而cv4的输入输出都是c_。这样拼接时两路的通道数分别是c2和c_，并不完全相等，看起来有点怪。实际这是常见实现的一种，为了保持最终输出通道数为c2，很多版本会在拼接后不再加卷积，直接依赖cv2的输出通道c2和cv3的输出通道c2分别拼接后调整。我建议你直接参考框架内Conv的实现来写，更重要的是确保forward里拼接后的通道数等于c2。

一种更稳妥的写法是：

class GSConv(nn.Module): def __init__(self, c1, c2, k=1, s=1, g=1, act=True): super().__init__() c_ = c2 // 2 self.cv1 = Conv(c1, c_, k, s, g=g, act=act) self.cv2 = Conv(c_, c2, 1, 1, g=g, act=act) self.cv3 = Conv(c_, c2, 1, 1, g=g, act=act) self.cv4 = Conv(c_, c_, 3, 1, g=g, act=act) def forward(self, x): x1 = self.cv1(x) x2 = self.cv2(x1) x3 = self.cv4(x1) return torch.cat((x2, x3), dim=1)

这段代码的关键在于理解它的设计意图：cv1先把输入通道降到一半，相当于压缩；cv2负责把压缩后的特征映射到输出通道；同时cv4在c_通道上做一次3×3空间操作，保留空间细节；最后concat把通道维度重新撑起来。由于输出通道就是c2，而c_ = c2//2，所以实际最终输出通道为 c2 + c_，并不严格等于c2。

这就引出一个重要细节：如果你直接把它接到yaml里，后面一层的输入通道会变成c2 + c_，而不是c2。这一点不处理干净，结构就乱了。所以更稳妥的做法是在GSConv输出前再加一个1×1投影，保证严格输出c2：

class GSConv(nn.Module): def __init__(self, c1, c2, k=1, s=1, g=1, act=True): super().__init__() c_ = c2 // 2 self.cv1 = Conv(c1, c_, k, s, g=g, act=act) self.cv2 = Conv(c_, c2, 1, 1, g=g, act=act) self.cv3 = Conv(c_, c2, 1, 1, g=g, act=act) self.cv4 = Conv(c_, c_, 3, 1, g=g, act=act) self.cv5 = Conv(c2 + c_, c2, 1, 1, act=act) def forward(self, x): x1 = self.cv1(x) x2 = self.cv2(x1) x3 = self.cv4(x1) return self.cv5(torch.cat((x2, x3), dim=1))

加上最后的cv5之后，整体输出通道严格等于c2，后面接任何模块都不会出维度问题，训练时也少踩奇怪的坑。代价是多了很少的参数量，但换来的是结构可解释性和稳定，我认为值得。

4.2 VoV-GSCSP的代码实现

VoV-GSCSP的简化版我会这样写：

class VoVGSCSP(nn.Module): """轻量跨阶段模块：一路轻量残差融合，一路直接透传，最后拼接并投影到输出通道。""" def __init__(self, c1, c2, n=1, e=0.5): super().__init__() c_ = int(c2 * e) self.cv1 = Conv(c1, c_, 1, 1) self.cv2 = Conv(c1, c_, 1, 1) self.cv3 = Conv(c_, c_, 3, 1) self.cv4 = Conv(c_, c_, 3, 1) self.cv5 = Conv(c_ * 2 + c_, c2, 1, 1) def forward(self, x): y1 = self.cv1(x) y1 = self.cv3(y1) + self.cv4(y1) y2 = self.cv2(x) return self.cv5(torch.cat((y1, y2), dim=1))

这里cv5的输入通道写成c_ * 2 + c_，是因为y2本身是c_，而y1经过cv3加cv4之后还是c_，两者拼接是c_ + c_。所以cv5输入通道就是2 * c_，我上面的写法多了一个c_，实际不对。更正成：

self.cv5 = Conv(c_ * 2, c2, 1, 1)

这样forward里先算y1的双3×3相加，得到c_通道；y2走1×1也是c_通道；拼接后2*c_输入cv5，最终输出c2。整个模块没有额外改动输入输出语义，可以直接替换C3k2的位置。

4.3 把新模块注册进解析器

在yaml里写了GSConv和VoVGSCSP之后，框架解析器需要认得出这两个类。一般需要把这两个类添加到模型注册相关的位置，通常是用一个集合或条件分支来判断层的类型。如果你不注册，它可能会把你导出的模块当普通层处理，导致参数数量和通道推断出错。

我一般直接在解析器里加一个判断分支：

if m in {"Conv", "GSConv", "VoVGSCSP", "C3k2", ...}: c1, c2 = ch[f], args[0] if m is GSConv: args = [c1, c2, *args[1:]] elif m is VoVGSCSP: args = [c1, c2, *args[1:]]

这样解析器在构建每一层前就知道输入输出通道数，不会出现上一层输出通道和下一层输入对不上的情况。新增模块后的模型检查方法很简单：加载模型，往里面扔一张随机tensor，看能不能正常输出三个尺度的预测，顺便打印总参数量。

4.4 重写Neck部分的yaml

原版Neck里，P3、P4、P5三个尺度的特征分别来自Backbone的不同Stage。Slim-Neck的yaml我改成这样，其他部分不变：

# Slim-Neck 示例片段 - [-1, 1, Upsample, [None, 2, "nearest"]] - [[-1, 6], 1, Concat, [1]] - [-1, 1, VoVGSCSP, [512]] - [-1, 1, Upsample, [None, 2, "nearest"]] - [[-1, 6], 1, Concat, [1]] - [-1, 1, VoVGSCSP, [256]] - [-1, 1, GSConv, [256, 3, 2]] - [[-1, 3], 1, Concat, [1]] - [-1, 1, VoVGSCSP, [512]] - [-1, 1, GSConv, [512, 3, 2]] - [[-1, 9], 1, Concat, [1]] - [-1, 1, VoVGSCSP, [512]] - [-1, 1, C2PSA, [512, 1]]

对比原版，我只是把Neck中的C3k2替换成VoVGSCSP，把用于下采样的普通Conv替换成GSConv，保留最后一个C2PSA不动。有人可能疑惑为什么C2PSA还要留着，因为它是Detect头前面最后一道跨尺度融合和注意力增强，直接删掉对精度影响太大。改造后整体Neck的参数量和计算量明显下降，同时输入输出接口不变。

5. 从训练到部署：完整实测流程与效果对比

5.1 训练环境与数据集准备

我拿一个6类的中等规模目标检测数据集做验证。训练集约6000张，验证集800张，输入尺寸统一640×640，batch size按显卡显存从默认16调到8。数据预处理、增强策略全部延用默认配置，没有额外调参。如果你有自己的私有数据集，按官方脚本装成yolo格式即可，流程不受影响。

训练命令格式保持框架默认：

yolo detect train data=dataset.yaml model=damo/cv_yolo11s_pai.yml pretrained=true epochs=100 batch=8 imgsz=640 device=0

这里model参数指向我们改好的Slim-Neck yaml文件。因为Backbone结构没变，所以可以加载原版预训练权重，新模块的权重初始化后从头学习。后续几轮训练很快就收敛。

5.2 参数量和FLOPs对比

以YOLO11s为基础，我在同一环境下测了三组：原版、只替换C3k2为VoVGSCSP、完整Slim版（在第二组基础上再把下采样卷积换成GSConv）。

这几组数字在不同显卡和驱动版本下会有浮动，但趋势很稳定：完整Slim-Neck比原版少约1.3M参数、5.5GFLOPs，推理耗时下降约30%。代价是mAP50大概下降0.3到0.5个点，mAP50-95下降约0.5到0.8个点。如果你的任务是小目标密集场景，可能需要把数据增强里的马赛克和随机透视开大一点来弥补。

5.3 速度和精度的权衡经验

我做完这轮改造后最大的感受是：Slim-Neck不是“免费午餐”，它是在用少量精度换部署效率。但它在很多场景下值得：

• 边缘设备上的推理帧率提升明显，尤其是使用CPU或低功耗GPU时；
• 参数量下降带来的好处不只是省显存，还让模型导出后的文件更小，更适合远程推送和OTA更新；
• 由于Neck改动没有碰Backbone，后续做量化时精度损失比直接量化整个模型要小。

如果项目对精度要求很苛刻，我会建议保留FPN上采样分支中靠前的两层为原版C3k2，只把PAN路径和更深的融合层换成Slim结构。这样精度损失能控制在0.2个点以内，计算量下降幅度仍然可观。

5.4 推理流程和导出验证

训练完直接验证：

from PIL import Image import torch model = torch.hub.load('本地路径', 'custom', path='best.pt', source='local') img = Image.open('test.jpg').convert('RGB') results = model(img, size=640) results.show()

如果一切正常，应该能看到检测框和类别标签。导出时我用的是框架自带的导出命令，把模型转成推理引擎支持的格式，部署时再根据设备逐层打开优化开关。由于Slim-Neck里卷积层更规整，导出时很少出现算子不支持的报错，这一点比一堆自研模块组成的结构要省心很多。

6. 常见问题排查与避坑实录

6.1 yaml里写了GSConv，却提示未知模块或维度对不上

这类报错多半出在解析器的注册环节。我一开始也是直接把yaml写进去，结果解析器把GSConv当成普通模块，自动把上一层的输出通道c1当成当前层的输入通道，而args里的c2就没人管，导致后续层维度乱掉。

解决办法就是在解析器里把GSConv和VoVGSCSP加到需要显式解析通道数的分支中，同时在模块文件里确认类的命名和yaml里的名字完全一致，包括大小写。检查到位后重新加载模型，用摘要输出确认每一层的输入输出通道是否是你预期的值。

6.2 训练时loss出现NaN

我遇到过两次NaN，一次是学习率太高，基础学习率从0.01调回到默认值后恢复；另一次是模型前向里某个分支的输出通道为0。VoVGSCSP里的e参数如果是0.5，而目标通道c2比较小，比如128，那么c_算出来是64，没问题；但如果c2是奇数或者过小，c_可能会取0，就会导致某个卷积层输入通道为0。解决办法是保证所有中间通道至少为16，或者在初始化类时加一行c_ = max(16, c2 * e)，避免出现空通道。

6.3 推理结果全图空白，一个框都没有

这个通常不是结构问题，而是训练没收敛或者输出头的通道没对齐。我在测试Slim-Neck时有一次改了yaml最后的Detect输入来源，导致分类分支和回归分支的输入特征错位，loss一直不降。排查时要先确认Detect头前面的特征层是否来自正确的三个尺度，不要改动yaml里最后一行的输出来源。

另一个常见原因是预训练权重没加载好。如果你的Backbone结构没变而新模块没有对应预训练权重，训练前一定要打开pretrained选项，让Backbone至少从一个合理的位置起步，否则前期loss波动巨大，甚至直接跑偏。

6.4 模型参数量变少了，但实机速度反而更慢

这是最容易踩的坑。某些设备对碎片化卷积并不友好，GSConv把一个大卷积拆成两个小卷积，虽然FLOPs降低，但算子数量变多，在一些边缘推理引擎上可能因为kernel launch次数增加而变慢。

我的经验是：在GPU上测FLOPs下降趋势，在目标真实设备上测端到端耗时。如果你发现实机速度没提升，优先尝试把GSConv只用在通道数较大的层，让那些小卷积合并到相邻的1×1卷积中；或者把两个相邻GSConv合并成一个卷积块，减少算子个数。另外在设备端开启算子融合优化往往比改网络结构的效果更直接。

6.5 后续还可以怎么继续压

Slim-Neck完成之后，如果还想继续缩小模型体积，我会从这几步入手：

• 对Backbone里最后一个Stage做一次通道剪枝，因为Neck已经轻量化后，瓶颈转移到Backbone尾部；
• 把Detect头的分类分支和回归分支共享一部分卷积，注意用解耦头的要保持精度；
• 训练后做PTQ量化，用少量验证集校准，通常能再获得20%到30%的加速，且精度下降在可接受范围内。

这三个方向我不建议同时上，一次只动一个，否则出了问题很难定位。先把Neck换了，量化后测一遍，再决定要不要继续裁剪Backbone。

7. 实际踩过坑之后的几点体会

最后分享几个我个人的使用经验。

第一点，改造Neck一定要保持Backbone原样。我最初为了追求极致压缩，把Backbone的Stage4也换成了轻量卷积，结果mAP掉了近3个点，而且怎么调都补不回来。后来只改Neck，精度下降控制在1个点以内，速度提升反而更明显。Backbone负责的是底层特征质量，这块不适合为了省参数而牺牲。

第二点，GSConv里加残差连接会显著改善训练稳定性。我在实验中发现，加上类似y1 + conv(y1)的残差路径后，前期收敛速度更快，最终精度也更高。这个改造不复杂，但很多人会忽略。

第三点，Slim-Neck项目的终点不一定在模型结构，很多时候在部署链路。同样的结构在训练环境和推理引擎上表现差距很大，导出时把动态尺寸选项关掉、固定输入尺寸为640，可以触发更激进的算子优化。我遇到过同一个模型，固定尺寸比动态尺寸推理速度快了接近40%。

NECK改造这件事，看起来只是换了几个模块，实际走一遍下来，相当于把整个模型从训练到部署的链路都摸清了。如果只记一个结论的话，我会说：轻量化不是简单删层，而是把每一层卷积花在什么地方想明白之后，再决定怎么换。