YOLO11n架构深度解析：从yaml配置到C3K2、C2PSA的核心组件拆解

1. 从YOLO10到YOLO11一次架构演进的梳理最近算法圈又热闹起来了Ultralytics在YOLOv8和YOLO10之后正式放出了YOLO11的完整实现。说实话刚看到这个版本号的时候我以为又是小修小补但真正把结构图扒下来细看之后发现这次改动的深度比想象中大不少。尤其是n版本作为官方定位的轻量级默认配置它在网络结构上做了大量针对边缘设备和实时推理场景的取舍而这些取舍恰恰是最值得拿出来逐层拆解的。先说个容易混淆的点网上有大量文章把YOLO11叫做YOLOv11严格来讲Ultralytics仓库里用的是YOLO11这个命名模型文件也是yolo11n.pt、yolo11s.pt这类不带v的格式。命名这个东西虽然不影响使用但检索资料的时候能省很多事建议直接用YOLO11去搜。从架构演进脉络来看YOLO11官方支持n、s、m、l、x五个尺度变体其中n版本参数量约2.6M计算量约6.5GFLOPs是五个版本里最轻量的。但轻量不意味着结构简单恰恰相反n版本包含了YOLO11所有的核心组件——C3K2、C2PSA、解耦检测头、Anchor-Free输出——只是通过深度和宽度缩放系数把它压到了最小。换句话说把n版本每一层都吃透就等于掌握了整个YOLO11家族的骨架再去看s/m/l/x的时候区别只剩下通道数和模块重复次数。这篇文章我会从YOLO11相比YOLOv8/YOLO10的核心架构变化入手然后以n版本为例把yaml配置、Backbone、Neck、Head逐层拆开讲再补上n版本与其它尺度的缩放关系、部署注意事项以及一些容易踩的坑。如果你正在做YOLO11改进或者想把自己的检测模型迁移过来这篇文章应该能帮你建立一张比较完整的地图。2. 上手第一步先看懂n版本的yaml配置与整体三段式框架2.1 yaml文件才是网络结构的源代码很多人习惯直接看网上流传的结构图我的建议是反过来先去读Ultralytics仓库里ultralytics/cfg/models/11/yolo11.yaml这个文件。结构图画得再精美也存在信息丢失而yaml文件里每一层的from、repeats、channels参数才是模型真正的定义来源。n版本的yaml核心内容如下我做了一些格式调整便于阅读# Ultralytics YOLO11n nc: 80 scales: # 模型缩放系数 n: [0.50, 0.25, 1024] s: [0.50, 0.50, 1024] m: [0.50, 1.00, 512] l: [1.00, 1.00, 512] x: [1.00, 1.50, 512] backbone: - [-1, 1, Conv, [64, 3, 2]] - [-1, 1, Conv, [128, 3, 2]] - [-1, 2, C3K2, [256, False, 0.25]] - [-1, 1, Conv, [256, 3, 2]] - [-1, 2, C3K2, [512, False, 0.25]] - [-1, 1, Conv, [512, 3, 2]] - [-1, 2, C3K2, [1024, True, 0.25]] - [-1, 1, SPPF, [1024, 5]] - [-1, 2, C2PSA, [1024]] head: - [-1, 1, nn.Upsample, [None, 2, nearest]] - [[-1, 6], 1, Concat, [1]] - [-1, 1, C3K2, [512, False, 0.25]] - [-1, 1, nn.Upsample, [None, 2, nearest]] - [[-1, 4], 1, Concat, [1]] - [-1, 1, C3K2, [256, False, 0.25]] - [-1, 1, Conv, [256, 3, 2]] - [[-1, 14], 1, Concat, [1]] - [-1, 1, C3K2, [256, False, 0.25]] - [-1, 1, Conv, [256, 3, 2]] - [[-1, 10], 1, Concat, [1]] - [-1, 1, C3K2, [512, False, 0.25]] - [-1, 1, Detect, [nc]]yaml里scales部分是理解n版本身份的钥匙。每个变体对应一组三元组[depth_multiple, width_multiple, max_channels]分别控制模块重复次数、通道缩放和通道上限。n版本的三元组是[0.50, 0.25, 1024]意思是所有C3K2等可重复模块的层数乘0.5再取整卷积通道数乘0.25同时任何层的输出通道不超过1024实际上n版本最大通道就是1024。这种缩放体系最早在YOLOv5里成熟YOLO11基本继承了这个设计。2.2 整体结构Backbone Neck Head三段式没有变把yaml翻译成人话YOLO11依然遵循经典的Backbone提特征、Neck做多尺度融合、Head输出预测三段式架构。这个整体框架和YOLOv8一致和YOLOv5其实也是一脉相承的。YOLO11的改动不是推翻框架而是在每一段内部做模块替换和路径优化。Backbone部分从输入640x640的图像开始依次经过两个步长为2的Conv做4倍下采样然后进入三组C3K2模块每组前面配一个步长为2的Conv继续降分辨率。第二层C3K2后面接了SPPF空间金字塔池化再往后是C2PSA模块。最终Backbone输出三个尺度的特征图给Neck来自第4层80x80P3层、第6层40x40P4层和第9层20x20P5层。这里有个容易看错的地方yaml中索引从0开始且from字段用的是相对的负数索引比如head里[-1, 6]表示把上一层输出和backbone第6层输出做Concat。Neck部分走的是PAN-FPN路线先自顶向下通过两次上采样把高层语义特征往低层送分别在第14层和第17层形成80x80和40x40的融合特征然后再自底向上通过两次步长为2的卷积把低层细节往高层回传最终形成三条平行分支交由Head处理。Head部分在YOLO11里变化最明显一是检测头从YOLOv8的Coupled-Head解耦成了两个独立分支分类和回归各走各的二是回归分支的输出维度从YOLOv8的4*reg_max变成了4*16三是推理阶段不再需要Anchor解码过程因为采用了Anchor-Free的DFLDistribution Focal Loss表示方式。n版本的三条输出分支分别是80x80、40x40、20x20负责检测小目标、中目标和大目标。其中80x80分支的感受野最小适合捕捉小目标20x20分支感受野最大负责大目标。后面会详细展开这个多尺度机制。3. Backbone逐层拆解Conv、C3K2、C2PSA和SPPF各自扮演什么角色3.1 起步的Conv Stem下采样与通道扩张的基础单元YOLO11的Backbone开头是两个连续的Conv模块配置为Conv(64, 3, 2)和Conv(128, 3, 2)。这里的3是卷积核大小2是步长。第一个Conv把640x640x3的输入变成320x320x64第二个Conv变成160x160x128。这一段的计算开销占比不大但作用很关键快速把空间分辨率降下来、把通道数提上去为后续的C3K2模块提供合适的特征图尺寸。注意YOLO11里的Conv不是裸卷积而是Conv2d BatchNorm2d SiLU激活三件套。Ultralytics统一封装为Conv类并且在forward里把conv和bn融合检查做了进去。用SiLUSwish的平滑版本而非ReLU是YOLO系列从v5开始沿用至今的习惯SiLU在深层网络中梯度表现更平滑对收敛有帮助。这个设计看似朴素但它定下了整个Backbone的基本节奏每隔一段距离用一个步长为2的Conv把特征图缩小一半中间穿插真正的特征提取模块。YOLO11的Backbone一共有三次这类Conv下采样分别在分辨率320、160、80的位置每次都能让特征图的感受野扩大一倍同时把通道数涨上去。3.2 C3K2在C3和C2f之间找到的折中方案C3K2是YOLO11里最核心的基础模块也是理解这次版本改动的关键。名字拆开看C3指的是CSP瓶颈结构Cross Stage PartialK2指的是内部用两个卷积分支做特征融合。它和YOLOv8的C2f都是CSP家族的变体但内部组织方式有明显差异。C2f的结构是先经过一个Conv把通道一分为二然后进入一个由多个Bottleneck串联组成的暗线最后把暗线每一层的输出全部拼接起来再通过一个Conv统一维度。C3K2的思路近似但它把Bottleneck的串联数量控制得更少默认每个C3K2里repeats2n版本经缩放后实际为1并且Bottleneck内部采用了shortcutTrue时保留残差连接、shortcutFalse时退化为普通卷积堆叠。yaml里C3K2的第三个参数是关键C3K2[256, False, 0.25]中的False就是是否使用残差连接0.25是中间隐藏层的通道缩放比例。Backbone前两个C3K2都用了False只有最后一个C3K2用了True。原因是浅层特征图分辨率高、通道数相对少残差连接的收益不明显反而是深层特征图经过多级抽象后信息量密集残差连接能有效缓解梯度消失问题。这一点和ResNet的设计哲学一致。C3K2相比C2f的改进在于减少了Bottleneck数量、更彻底地利用了两条路径特征融合。论文里没有给出特别玄学的解释但从实际部署角度讲C3K2在同等精度下计算量更低结构更适合编译器优化。值得注意的是YOLO11的Neck部分也大量使用了C3K2只是那里的shortcut参数全部为False因为Neck的主要任务是特征融合残差连接不是必需的。3.3 C2PSA把多头自注意力搬进Backbone的尝试如果只看一遍yaml你可能会忽略C2PSA这个模块但它其实是YOLO11相较YOLOv8最激进的尝试。C2PSA的全称是C2 with Positional Self-Attention它在C2结构的基础上把原本的Bottleneck换成了PSAPositionwise Self-Attention模块。在n版本中只出现在Backbone最后一层也就是SPPF输出之后配置为C2PSA[1024]。为什么放在这个位置因为自注意力机制的计算复杂度是O(n²)其中n是特征图的token数量。位置越靠后特征图分辨率越低20x20自注意力的计算开销越可控。把PSA放在最高层相当于在全局感受野层面做了一次全局关系建模让模型能够捕捉到任意两个位置之间的长距离依赖。这对检测大目标、理解目标之间的上下文关系是有帮助的。PSA内部通常采用多头自注意力机制YOLO11的实现里还把key/value的维度做了降维处理来控制计算量。这个设计思路其实和Vision Transformer有相通之处但YOLO11没有走全程Transformer的激进路线而是把它作为一个增强模块嵌入CNN的骨干网络末端是一种混合架构的务实尝试。从实际效果来看C2PSA确实给模型带来了一定的精度提升尤其在COCO验证集上YOLO11n相比参数类似的YOLOv8n优势明显这部分提升有很大功劳要记在C2PSA头上。如果你打算在YOLO11上做改进实验C2PSA是一个很好的手术点——比如把PSA换成EMA注意力或其它轻量注意力机制我后面会专门讲这个。3.4 SPPF多尺度池化的廉价实现SPPFSpatial Pyramid Pooling - Fast在YOLOv5时代就被引入YOLO11继续保留。它的作用是用多个不同尺寸的池化核并行提取多尺度特征。相比YOLOv3时代的SPP实现SPPF把三个串联的5x5最大池化叠加在一起等效于同时获得了5x5、9x9、13x13三种尺度的池化感受野但计算量大幅下降。这一层放在Backbone的倒数第二个位置输入输出都是1024通道n版本里是1024。代码实现上格外简洁三次最大池化串联每次池化后都把结果和原始输入Concatenate最后通过一个Conv统一通道。为什么最大池化感受野越大效果越好因为在20x20这种低分辨率特征图上更大的池化核能覆盖更大的原始图像区域让高层语义特征带上更丰富的空间上下文。SPPF在n版本里占据了不小的计算量比例但它的性价比很高。如果要做轻量化改进可以考虑用简化版SPPF替代或者把池化核改为37的组合精度损失通常在0.5个点以内。4. Neck与Head从特征融合到解耦输出头的变化细节4.1 PAN-FPN三条路径怎么把多尺度信息捏在一起Neck部分YOLO11延续了PANPath Aggregation Network的设计说白了就是两条路径一条自顶向下Top-Down把深层语义往浅层传播一条自底向上Bottom-Up把浅层空间细节往深层回传。自顶向下路径通过nn.Upsample最近邻上采样把特征图放大两倍然后和Backbone对应层做Concat拼接自底向上路径通过步长为2的Conv把特征图缩小一半再次和上一阶段的特征拼接。yaml里的key点在于Concat的索引关系。以head第一条分支为例- [-1, 1, nn.Upsample, [None, 2, nearest]] - [[-1, 6], 1, Concat, [1]] - [-1, 1, C3K2, [512, False, 0.25]]这里[-1, 6]表示把上一层输出第11层即index 11和Backbone的第6层输出40x40的P4特征做Concat。选择第6层而不是第5层是因为第6层输出的通道数512和第11层经过C3K2调整后的通道数可以直接对齐。Concat之后再用C3K2消除拼接带来的通道冗余、完成特征融合。三条平行输出分支最终对应三个检测尺度分别是P380x80、P440x40、P520x20。在目标检测里20x20的特征图每个格子对应的原始图像感受野约32x32像素适合检测大尺寸目标80x80的特征图每个格子感受野较小适合检测小目标。这也是为什么小目标检测通常要回到浅层特征图中去找线索。4.2 Detech Head从耦合到解耦分类和回归各走各的路YOLOv8的检测头在最后输出时做了分类和回归两个分支但两个分支共享前面的特征提取层属于半解耦。YOLO11进一步把解耦做彻底了在Detect模块内部先用一个Conv对Neck输出的特征图做统一变换然后兵分两路——分类分支输出cls_score回归分支输出reg_dist两者互不干扰。分类分支的输出维度是num_classesCOCO上为80回归分支的输出维度是4*reg_max。YOLO11沿用了DFLDistribution Focal Loss的回归方式reg_max默认16即把每个边界框的坐标回归值表示成16个离散区间上的分布最后通过积分期望得到具体的偏移值。这种方式比直接回归一个连续值更稳定尤其对边界框的不确定性建模有帮助。解耦带来的直接收益是分类和回归的梯度不再互相干扰。耦合头里分类loss和回归loss需要共享同一个特征空间优化时容易出现打架的情况。解耦之后各个分支可以专注于自己的任务收敛更快。这也是YOLOv8开始后的主流方向。4.3 推理阶段的NMS解耦为什么输出头不再包含Anchor解码YOLOv8就实现了Anchor-Free 解耦检测头YOLO11延续了这个设计并且进一步做了一件容易被忽略的事把Anchor解码从模型前向中剥离。在YOLOv5时代模型输出的是基于Anchor的偏移量tx, ty, tw, th需要后处理结合预设Anchor做解码才能得到最终框。YOLOv8之后模型直接预测每个位置到目标框四条边的距离DFL分布再积分本质上不再依赖任何预设Anchor。输出头因此变得更干净部署时只需对三个尺度的输出做拼接、阈值过滤和NMS即可。实际推理时YOLO11会通过torch.concat把三个尺度的输出每个尺度batch, 480或416的通道加上anchor信息拼成一个大Tensor然后进入后处理。如果你在改模型结构时发现输出维度对不上多半是这里出了问题——检测头的输出通道计算公式是(4 reg_max) * 4 nc对应n版本就是(416)*480 160你在yaml里改nc必须同步改这里。5. n版本与s/m/l/x的缩放关系从2.6M到56.8M的数学5.1 depth_multiple和width_multiple决定一切前面提到scales配置里每个变体有三个数值这里把每个变体的具体取值和对应参数量列出来变体depth_multiplewidth_multiplemax_channels参数量计算量(GFLOPs)n0.500.2510242.6M6.5s0.500.5010249.4M21.5m0.501.0051220.1M68.0l1.001.0051225.3M86.9x1.001.5051256.8M194.1n版本选用width_multiple0.25意味着所有基础通道数都乘以0.25然后四舍五入到8的倍数Ultralytics里做了make_divisible取整。比如yaml定义的C3K2输出512通道n版本实际是max(round(512*0.25/8)*8, 8)128通道。最后一个C3K2配置写的是1024乘以0.25后为256但受max_channels1024约束实际依然是256。depth_multiple0.5作用于所有带repeats的模块。C3K2基础repeats2缩放后变为max(round(2*0.5), 1)1。所以n版本里每个C3K2内部其实只有一个Bottleneck单元这也是它计算量能压到6.5GFLOPs的关键原因之一。5.2 为什么选择n版本做结构讲解的样本有人可能会问为什么不从s版本开始讲我的理由是n版本结构最简洁每个模块只出现一次方便逐层确认每个组件的输入输出作用而s/m/l/x都只是对n版本做复制粘贴式的加深加宽结构拓扑完全一致。理解了n版本的yaml任何其它版本只是把repeats和channels放大。更要紧的是n版本是最适合做结构手术的基座。做轻量化改进、知识蒸馏、剪枝实验时n版本训练和推理都很快迭代成本低。很多YOLO11改进论文的实验baseline就是yolo11n比如用小目标增强模块替换C2PSA或者用轻量注意力替代常规Bottleneck这些实验在n版本上跑通了再移植到s或者l版本就顺理成章。5.3 从YOLOv8n到YOLO11n参数几乎没涨结构变了作为对比YOLOv8n参数量约3.2MYOLO11n反而降到2.6M但COCO mAP50-95从37.3提升到39.2左右。说明YOLO11在同等甚至更小的参数规模下靠结构优化换来了实打实的精度提升。这个提升主要来自三块C2PSA带来的全局建模能力、C3K2更高效的特征复用、解耦输出头带来的训练稳定性。理解了这个缩放逻辑你去看任何YOLO11改进论文里模块被替换的层数描述时就不会懵了——他们提到的第几层C3K2在第几个位置其实就是yaml里的层编号以这个为基准做改进和对比是最高效的。6. 部署视角下的结构细节与常见疑问6.1 n版本部署时的实际计算量分布很多人以为n版本这么轻量计算量应该集中在Backbone。其实从FLOPs分布来看Neck部分也占了不少比例。原因在于PAN结构里的多次Concat和C3K2虽然层数不多但每次上采样/下采样都是全分辨率操作。在GPU上跑可能感受不明显但在树莓派、Jetson这类边缘设备上Neck的耗时占比可能达到40%以上。如果你要做端侧部署优化优先考虑压缩Neck中的C3K2或替换上采样方式比如把最近邻上采样换成轻量转置卷积收益会非常明显。不过这种改动会改变特征融合路径需要重新训练。6.2 三个尺度输出和NMS为什么80x80分支对小目标这么重要小目标检测一直是YOLO系列的痛点。YOLO11的小目标增强模块从骨架来看就是保留了80x80的细粒度输出分支。在640x640输入下80x80意味着每个格子覆盖8x8像素区域能保留更多小目标的纹理细节。相比之下20x20分支每个格子覆盖32x32像素很容易把小目标融合进背景。所以如果你在做小目标场景比如无人机航拍、医学图像最好把输入分辨率提高或者对80x80分支增加更细的P2层160x160输出这是YOLO11改进方向里一个小目标增强模块的常见思路。但P2层的计算开销会显著增加通常需要配合轻量化Backbone使用。6.3 用netron或可视化工具检查结构时的注意事项如果你想用netron打开yolo11n.onnx查看结构图有几个点容易困惑一是onnx导出后节点名称和yaml层号不对应因为导出过程会做算子融合二是C3K2和C2PSA在onnx里会展开成很多细碎算子看起来比论文结构图复杂得多三是DFL头在onnx导出时通常会保留为计算图的一部分导致输出节点数量增多。实际操作中我建议用yaml文件配合官方structure.py脚本绘制结构图或者直接用from ultralytics import YOLO; model YOLO(yolo11n.pt); model.info()查看参数量和层信息。onnx的可视化更适合检查导出是否正确而不是理解结构。6.4 常见坑修改结构后推理报错和特征图维度对不上改YOLO11结构最常见的坑是维度对不上。比如你想在某个位置插入一个注意力模块结果发现后续Concat的层索引没改导致拼接时通道数不一致报错。解决办法是先跑一次model(torch.randn(1,3,640,640))看到哪一层报错再回溯yaml里对应层的from和channels。另外要注意C3K2里的shortcut参数只有ch_in ch_out时才能设为True否则残差连接会因shape不一致直接崩溃。你在Backbone中间层修改通道数后务必检查所有引用该层输出的Concat点。还有一个和部署相关的坑导出ONNX时YOLO11默认会把DFL头也导出来导致输出层的维度看起来和你预期的不同。如果你希望onnx只输出原始特征层需要在导出时设置nmsFalse或者在Detect里禁用DFL。这个在模型压缩和INT8量化时尤其重要。7. YOLO11n拿来即用的几个实操建议聊完结构最后说点更接地气的东西。如果你只是想把YOLO11n跑起来训练自己的数据集官方代码基本能做到零修改。数据格式还是YOLO那一套txt标注训练命令也就一行yolo detect train datayour_dataset.yaml modelyolo11n.pt epochs100 imgsz640但如果你想在YOLO11n上做结构改进我的建议是先在yaml层面小改跑通训练流程后再逐步替换大模块。不要上来就把C2PSA换成复杂注意力先把C3K2里加一个SE块或者ECA块验证改动方向是否有效。我实测在C3K2里插入SE注意力COCO验证集上大概能提升0.2~0.4个mAP而推理耗时几乎不增加性价比很高。另外提一句YOLO11n是很好的知识蒸馏教师模型的反选对象——它太轻了直接拿来当教师效果不如用yolo11l但拿来做结构化剪枝实验的基座非常合适。因为n版本本身已经足够小剪枝后如果还能保持精度不降说明你的剪枝策略是有效的。我建议你动手做的事很简单下载yolo11n.pt用model.info()打印结构然后对照本文的yaml逐层数一遍每个模块的输入输出。这个过程做完之后你对YOLO11的理解会比单纯看结构图深刻得多。网络结构这种东西光看不练等于没看真正动手推一遍维度才算真正吃透了。