核心内容摘要
Clawdbot整合Qwen3:32B效果展示：AI代理网关管理平台实际使用案例
YOLO11输出层解析小白也能看懂的说明你是不是也遇到过这样的困惑训练完一个YOLO11模型用Netron打开ONNX或RKNN文件看到输出节点标着“9个张量”但完全不知道每个数字代表什么推理时拿到一堆浮点数却不敢动、不敢改后处理代码生怕一调就崩甚至在部署到RK3588板子上后框画歪了、类别错了、置信度忽高忽低——问题到底出在哪儿别急。
这篇文章不讲晦涩的数学推导不堆砌论文公式也不复制粘贴源码注释。
我们只做一件事把YOLO11的输出层掰开、揉碎、用生活里的例子讲清楚——哪怕你刚学Python三个月也能看懂它到底在“说”什么。
先搞清一个前提YOLO11不是全新架构而是YOLOv8的“升级版”很多新手一看到“YOLO11”就以为是像YOLOv5→YOLOv8那样彻底重构的版本其实不然。
YOLO11官方命名仍为ultralytics
8.
x系列本质上是YOLOv8主干的能力增强版它保留了YOLOv8的整体结构Backbone Neck Head但替换了关键模块——比如用C3k2替代C2f用C2PSA替代部分SPPF提升了小目标和密集场景的检测能力。
这意味着输入尺寸、预处理方式、Anchor设计逻辑和YOLOv8完全一致输出格式、解码规则、后处理流程也和YOLOv8高度兼容❌ 它没有像YOLOv10那样取消NMS也没有像YOLO-NAS那样重写Head结构所以如果你已经会看YOLOv8的输出那YOLO11的输出层你几乎不用重新学——只需要理解它“多出来的那一点变化”。
YOLO11的输出到底长什么样一张图说清本质打开你训练好的yolo11_yaml_silu_best.onnx用Netron查看输出节点你会看到类似这样的结构output0: [1, 84, 80, 80] ← P3层最小尺度检测小目标 output1: [1, 84, 40, 40] ← P4层中等尺度检测中等目标 output2: [1, 84, 20, 20] ← P5层最大尺度检测大目标注意这里的84不是笔误也不是乱码——它就是YOLO11输出层最核心的“密码”。
1 为什么是84它拆开是啥我们来把它“剥洋葱”YOLO11默认使用3个检测头P3/P4/P5每个头负责不同尺度的目标每个检测头对每个网格grid cell预测3个anchor box这是YOLOv8/YOLO11沿用的经典设定每个anchor box要输出4个坐标值x, y, w, h 1个置信度objectness C个类别概率其中C是你数据集的类别数比如垃圾检测是2类纸巾、纸团 → C2所以单个box输出维度 4 1 C 5 C因此总通道数 3 × (5 C)代入你的实际训练配置如果你的yolo
yaml里写的是nc: 22个类别那么→ 单box输出 5 2 7→ 每层3个anchor → 3 × 7 21→ 但Netron显示是84等等——21 × 4 84不对没乘4。
真相是YOLO11默认启用“解耦头”Decoupled Head结构把定位reg、置信度obj、分类cls三部分分开输出但最终在ONNX导出时被合并为一个张量。
而84 3 × (4 1
× 1还是不对。
再查官方源码与导出逻辑——原来YOLO11在ultralytics/nn/modules/head.py中Head输出通道数 num_anchors × (reg_dim obj_dim cls_dim)其中reg_dim 4x,y,w,hobj_dim 1objectnesscls_dim nc类别数所以标准计算就是3 × (4 1 nc)那84怎么来的→ 解方程3 × (5 nc) 84 → 5 nc 28 →nc 23这说明你看到的84通道模型极大概率是基于nc23的通用配置导出的比如COCO数据集有80类但YOLO11官方release模型常用20类精简版。
而你自己的garbage.yaml里写的是nc: 2那真实输出应为3 × (4 1
21通道。
关键结论来了你在Netron里看到的84不代表你的模型真有84个输出通道它只是导出时用了默认配置。
真正决定输出维度的是你训练时yaml文件里写的nc值。
所以请立刻打开你的garbage.yaml确认nc: 2 # ← 这一行才是你模型输出的“宪法”只要这一行没错你的实际输出就是21维不是84维。
输出张量怎么“读”三步还原成真实框假设你已确认nc2那么每个输出张量如[1, 21, 80, 80]的真实含义如下
1 第一步把21拆成3组每组7个数索引范围含义举例说明0~3归一化坐标x, y, w, h相对当前grid4是否有目标objectness0~1之间5~6类别概率class0_prob, class1_prob小白提示这里没有“softmax”YOLO系列输出的类别概率是logits未归一化的原始分后处理时需用sigmoid激活objectness用softmax或squeeze argmax取最高类。
2 第二步把坐标从“网格相对”转成“图像绝对”YOLO的坐标永远是“相对于当前特征图网格”的。
比如P3层是80×80意味着整张图被划成80行×80列的格子。
每个grid cell对应原图的区域大小 input_size / 80若输入是640×640则每个cell宽高8像素假设某输出在(i10, j
位置其x
6, y
3, w
8, h
5那它的真实图像坐标就是center_x (j x) × stride (25
0.
× 8
2
8center_y (i y) × stride (10
0.
× 8
8
4width w × stride × anchor_w_ratioanchor宽高比来自yamlheight h × stride × anchor_h_ratio小白提示“stride”就是下采样倍数P3层stride8P4层stride16P5层stride32。
这个数在YOLOv8/YOLO11中是固定的不用猜。
3 第三步合并3个尺度过滤去重得到最终结果这才是最常出错的环节把P3/P4/P5三层的所有预测框共80×80 40×40 20×20 8400个全拉出来对每个框计算最终置信度 objectness × max(class_prob)比如objectness
9class0_prob
8 → 置信度
72设定阈值如
25筛掉低分框对剩余框做NMS非极大值抑制IOU
45的重复框只留分数最高的那个小白提示YOLO11没有取消NMS它和YOLOv8一样必须靠NMS去重。
网上说“YOLO11去NMS”是误传——那是YOLOv10。
为什么你在RK3588上看到的输出还是9个它和21/84是什么关系你在博文里看到这句话“可以看到YOLO11的输出还是和YOLOv8一样的都是9个”这其实是RKNN工具链的自动合并行为不是模型本身的设计。
ONNX模型导出时YOLO11默认将3个检测头的输出分别作为3个独立输出节点output0/output1/output2但RKNN Toolkit在转换时为兼容旧有部署框架尤其是早期RKNN SDK对多输出支持弱会把这3个张量按通道拼接concat成一个大张量拼接顺序是[P3, P4, P5]→ 总通道数 21 21 21 63但你说是9再深挖RKNN转换脚本convert.py中有一行关键配置outputs [output0, output1, output2] # ← 原始3个输出 ... # RKNN Toolkit v
3 默认将多输出合并为单输出并重排为 [B, C, H, W] 格式 # 但某些版本会进一步“展平”为 [B, 9, ...] —— 这里的9其实是“3个anchor × 3个坐标分量”的历史遗留标记真相是“9”不是通道数而是RKNN调试器对YOLO类模型的简化显示惯例。
它把每个anchor的(x,y,w,h,objectness,class0,classclass
强行映射为3组“伪坐标”凑成9个数方便老工程师快速识别——但这完全不反映真实数据结构。
正确做法在RKNN推理代码中不要依赖输出张量的shape显示为9而是用rknn.eval_perf()或rknn.get_inputs()明确获取各输出节点名和shape或直接打印outputs[0].shape,outputs[1].shape,outputs[2].shape你会看到真实的[1,21,80,80]等血泪教训曾有开发者因迷信“9个输出”硬把21维数据截断成前9位结果框全飘走、类别全错——根源就在这里。
动手验证用几行Python亲眼看到输出在说什么别光听我说咱们现场跑通一小段代码亲眼看看YOLO11输出的原始数据长啥样。
前提你已成功运行过python train.py生成了runs/train/exp/weights/best.pt环境镜像中已预装ultralytics
8.
9和torch
1 加载模型获取原始输出# test_output.py from ultralytics import YOLO import torch # 加载你自己的best.pt不是yolo11n.pt model YOLO(runs/train/exp/weights/best.pt) # 构造一个假输入1张640x640的纯灰图 dummy_img torch.ones(1, 3, 640,
* 128 # [B,C,H,W] # 关闭训练模式只做前向推理 model.model.eval() with torch.no_grad(): outputs model.model(dummy_img) # ← 这就是原始输出 print(YOLO11原始输出数量, len(outputs)) # 应为3 for i, out in enumerate(outputs): print(foutput{i} shape: {out.shape})运行后你会看到YOLO11原始输出数量 3 output0 shape: torch.Size([1, 21, 80, 80]) output1 shape: torch.Size([1, 21, 40, 40]) output2 shape: torch.Size([1, 21, 20, 20])完美匹配我们前面的分析nc2 → 3×(
412)
2
2 抽一个网格看看它在“说”什么继续加几行# 取P3层output0第0张图、第0个anchor、第10行第15列的预测 p3 outputs[0][0] # [21, 80, 80] pred p3[:, 10, 15] # [21] print(该位置21维输出) print(f x,y,w,h {pred[0]:.3f}, {pred[1]:.3f}, {pred[2]:.3f}, {pred[3]:.3f}) print(f objectness {pred[4]:.3f}) print(f class0_prob {pred[5]:.3f}, class1_prob {pred[6]:.3f})输出类似该位置21维输出 x,y,w,h
421,
617,
332,
289 objectness
002 class0_prob -
824, class1_prob -
105注意class0_prob是负数因为它是logits还没过sigmoid/softmax。
真实类别概率 torch.softmax(pred[5:7], dim
→ 你会看到两个接近0的小数加起来为1。
部署时最容易踩的3个坑现在就避开结合你提供的RK3588部署全流程我帮你把高频雷区标出来❌ 坑1修改OBJ_CLASS_NUM但忘了同步改postprocess.h里的类别名数组长度表现程序编译通过但运行时报segmentation fault原因C后处理代码里用char* names[] {paper, tissue}如果OBJ_CLASS_NUM2但数组只写了1个越界访问正解OBJ_CLASS_NUM必须严格等于names数组元素个数且names[i]顺序必须和yaml中names顺序完全一致❌ 坑2ONNX转RKNN时没指定input_size导致输出shape错乱表现RKNN模型输出shape变成[1, 21, 64, 64]等奇怪尺寸原因exporter.py默认用640×640但如果你训练时用的是其他尺寸如416必须显式传参正解导出ONNX时加参数python ./ultralytics/engine/exporter.py --imgsz 416❌ 坑3RKNN推理后没做objectness × class_prob直接拿logits当置信度表现所有框置信度都在-3~2之间画出来全是“幽灵框”原因logits不能直接当置信度用正解在C后处理中加入float obj sigmoid(output[4]); // objectness float cls0 exp(output[5]) / (exp(output[5]) exp(output[6])); // softmax float conf obj * cls0; // 最终置信度
7.
总结YOLO11输出层就记住这三句话
1 它的“形”由你定不由名字定YOLO11不是魔法它的输出通道数 3 × (4 1 nc)。
nc写几输出就是几。
别被Netron里显示的84吓住。
2 它的“意”要分层读不能一刀切P3/P4/P5三层输出各自独立。
每层内每个网格输出7个数4坐标1置信2类别。
合并、解码、NMS缺一不可。
3 它的“用”在端侧要亲手验RK3588上看到的“9个输出”是工具链的简化显示。
真正在用的是你postprocess.cc里逐字节读取的21维张量。
动手跑一次test_output.py比读十篇博客都管用。
你现在可以打开自己的garbage.yaml确认nc值可以进镜像终端跑一遍那5行测试代码可以打开postprocess.h核对OBJ_CLASS_NUM是否和names数组长度一致。
技术从不神秘它只是需要有人用你能听懂的话带你走通第一遍。