简介面向目标检测研究者与算法工程师的YOLOv11与视觉大模型知识分享PDF文档系统梳理YOLO系列从v1到v11的演进脉络对比两阶段与单阶段检测框架的精度与速度权衡并解析FPN多尺度特征融合、骨干网络与特征金字塔等核心模块设计。资源压缩包共1个PDF文件大小仅1.47MB便于下载后离线阅读与快速查阅。目前已有46人学习。内容包括模块化、轻量化、激活函数选择、正则化等网络结构设计原则并结合多尺度检测机制与损失函数构建方法帮助读者理解YOLOv11相对视觉大模型在速度与准确性上的竞争力适合快速掌握目标检测技术要点与模型演进设计原理的开发者参考。1. YOLOv11 与视觉大模型为什么实时检测不直接交给大模型拿到一个产线质检或安防巡检需求时我第一个想到的检测方案不会是视觉大模型而是 YOLOv11。原因很直接产线上要的是每帧几十毫秒出结果而视觉大模型虽然能看懂开放词汇、能做文本交互但它慢、贵、推理还不稳定。YOLOv11 在这种实时场景里依然是工业落地的默认选项。真正能落地的组合是视觉大模型离线负责标注、过滤、知识蒸馏YOLOv11 在线负责实时推理。这篇文章就顺着环境配置、小目标改进、大模型辅助、Jetson 部署这条链路把每一步的做法和踩过的坑拆给你。2. 跑通第一张推理图环境配置、权重选择与保存推理结果的三种写法2.1 先让环境不翻车最小依赖组合与快速验证YOLOv11 的环境配置门槛比上一代低不少因为官方把训练、推理、导出全部收进了 ultralytics 这一个包里。常见做法是先建一个干净的虚拟环境再装依赖避免和系统里其他项目的包打架。# 建一个干净环境Python 版本选 3.10 比较稳 conda create -n yolo11 python3.10 -y conda activate yolo11 # ultralytics 会自动拉取 torch 和 torchvision pip install ultralytics # 验证环境是否可用 yolo version这里有两个容易踩的细节。第一个是pip install ultralytics会自动装一份默认的 PyTorchCPU 版。如果你机器上有 GPU 且提前装好了 CUDA 版 torch建议先装你要的 torch 和 torchvision再执行pip install ultralytics --no-deps跳过依赖避免把 GPU 版覆盖掉。第二个是在 JetPack 板子上不要直接用 pip 拉 torch后面第 5 章会专门说。yolo version能打印出版本号说明环境已经通了。第一次调用YOLO(yolo11n.pt)时程序会自动下载权重如果网络不稳定建议先手动下载好 .pt 文件放到脚本同目录再加载本地路径。2.2 权重怎么选从 n 到 x 的取舍YOLOv11 官方权重按宽度和深度分成五个档位命名规则和上一代一致。我第一次跑项目时直接上了最大的 x 版结果一张图推理要 200 多毫秒产线要求 50 毫秒以内直接被否。后来才发现大部分项目的核心瓶颈不在精度而在延迟、显存和带宽。权重模型规模推理速度直观适用场景yolo11n最小最快Jetson、边缘盒子、快速验证流程yolo11s小快实时监控、产线质检yolo11m中中精度优先的中小型 GPU 服务器yolo11l/x大慢离线分析、复杂场景学术实验我的建议是如果是第一次跑通流程直接用yolo11n.pt等整套代码跑通了再根据实际帧率余量换大模型。别一上来就追求高精度先把链路打通后面换权重只是改一行字符串的事。2.3 保存推理结果的三种写法save、plot 与 json 导出推理本身非常简单一行predict就能出结果。真正讲究的是结果保存方式因为后续不管是接目标跟踪还是接视觉大模型做二次过滤都需要拿到结构化的框数据而不是一张画好的图片。from ultralytics import YOLO model YOLO(yolo11n.pt) results model.predict( sourcetest.jpg, # 单张图传文件夹路径就是批量预测 conf0.25, # 置信度阈值低于它的目标会被剔除 iou0.45, # NMS 的 IoU 阈值两个框重叠超过它会被合并 imgsz640, # 推理尺寸640 是速度和精度的平衡点 devicecpu, # 有 GPU 写 0没有就写 cpu saveTrue, # 最省事的保存方式自动存到 runs/detect/predictX )这段代码里最容易忽略的是conf和iou两个参数。conf0.25的意思是置信度低于 0.25 的框直接丢弃如果你想做可视化分析可以把阈值降到 0.1看看到底漏了多少目标。iou0.45控制重叠框的合并强度小目标密集场景建议降到 0.3避免近邻目标被当成一个框。saveTrue会把带标注的图片自动存到runs/detect/predictX这是最不需要动脑的写法。但如果你要在脚本里继续处理结果更常用的是下面这两种# 写法一用 r.plot() 拿原始数组自己控制保存 import cv2 for i, r in enumerate(results): img_bgr r.plot() # 返回 BGR 的 numpy 数组 cv2.imwrite(fplot_{i}.jpg, img_bgr) # 用 cv2 保存不要用 PIL boxes r.boxes.xyxy.cpu().numpy() # [x1, y1, x2, y2] scores r.boxes.conf.cpu().numpy() # 每个框的置信度 classes r.boxes.cls.cpu().numpy().astype(int)用r.plot()而不是r.save()原因是plot()返回的是 numpy 数组你可以先做拼接、加遮挡、叠加统计信息再统一保存。有一个细节必须强调r.plot()返回的是 BGR 格式用cv2.imwrite保存没问题如果换成 PIL 的Image.save颜色会泛蓝这个问题我在第 5 章的避坑记录里详细说。# 写法二导出成 json给上游业务系统用 import json def results_to_json(results, path): out [] for r in results: boxes r.boxes.xyxy.cpu().numpy() confs r.boxes.conf.cpu().numpy() clss r.boxes.cls.cpu().numpy().astype(int) names r.names for box, conf, c in zip(boxes, confs, clss): out.append({ class: names[c], conf: float(conf), box: [float(v) for v in box], }) with open(path, w, encodingutf-8) as f: json.dump(out, f, ensure_asciiFalse, indent2)这段代码在做工业项目时非常常用。检测结果最终要落到业务系统里json 格式比图片文件更容易被上游消费。注意box里的坐标是像素坐标如果你的业务系统要画到 GIS 地图或原始大图上记得先确认坐标原点和缩放比例不要直接拿原始坐标去匹配不同分辨率的图像。3. 小目标为何翻车YOLOv11 网络结构拆解与 P2 检测层改进路线3.1 backbone 与 neckC3k2、SPPF 和特征金字塔在做什么YOLOv11 的网络结构依然延续 backbone、neck、head 三段式设计但内部模块做了明显调整。backbone 负责逐层下采样提取特征核心组件是卷积块和 C3k2 模块。C3k2 可以理解为 C3 的改进版它把标准 Bottleneck 替换成了两个更小的卷积核分支让相同计算量下能提取更丰富的特征。相比上一代 C3C3k2 在同等参数下的梯度流动更顺畅训练时收敛更稳。在 backbone 末端还有一个 SPPF 模块它通过三个串联的最大池化把不同感受野的特征拼接起来。SPPF 的作用是让模型在最后一层能同时看到局部细节和大范围上下文对检测尺度差异比较大的场景很关键。neck 部分依旧是特征金字塔结构负责把高层的语义特征和浅层的纹理特征融合。YOLOv11 的 head 改成了 anchor-free 设计每个位置直接预测目标的中心点和宽高省掉了预设 anchor 的调参成本实现上也简化了很多。但结构升级带来一个容易被忽视的问题模型默认的输出特征图只有三层分别对应原图下采样 8 倍、16 倍和 32 倍。如果一个目标在原始图上只有 12x12 像素经过 32 倍下采样后它在最后一层特征图上连 1 个像素都不到几乎不可能被检测到。这是小目标翻车最根本的结构原因。3.2 小目标检测有多难下采样倍数、NMS 与标注质量的三重打击做个简单换算输入 640x640 的图检测层分别输出 80x80、40x40、20x20 的特征图。20x20 那一层的每个格子对应原图 32 个像素。换句话说小于 32x32 的目标在这个层上几乎没有响应。航拍场景里的车辆、产线上的小零件、监控里的远处行人都属于这一类。小目标翻车的第二重打击来自 NMS。小目标框之间的 IoU 对位置偏移极度敏感一个 10x10 的框只要偏移 2 个像素IoU 就掉到 0.6 以下导致相邻目标很容易被合并或漏检。第三重打击是数据标注质量。小目标在标注时本来就容易产生 1~2 个像素的偏差这个偏差对普通目标无所谓但对小目标来说直接改变了目标的中心点和宽高比例模型学到的边界很模糊。我在处理航拍数据时第一步不是改模型而是先统计目标尺寸分布。用脚本跑一遍所有标注框看看有多少框的宽度小于 16 像素。如果这类目标占比超过 20%任何结构优化都救不回来必须先把图像切成 patch 或者提高输入分辨率。这属于数据层面的前置工程很多人忽略。3.3 改进路线P2 层、注意力模块与训练参数调整YOLOv11 的小目标改进最直接有效的是增加一个 P2 检测层。P2 层对应下采样 4 倍的特征图分辨率和目标细节都保留得更好。常见做法是以 yolo11 的配置文件为基础复制出一份自定义 yaml在 backbone 里额外引出浅层特征再在 head 里加一条融合分支。# 复制 ultralytics/cfg/models/11/yolo11.yaml 后修改 # 下面只是结构示意具体层索引以你复制的 yaml 为准 backbone: - [-1, 1, Conv, 64, 3, 2] # 0-P11/2 下采样 - [-1, 1, Conv, 128, 3, 2] # 1-P21/4 下采样小目标主要靠这里 # 后续层保持默认只额外记录 P2 层的输出索引 head: # 在 head 最前面增加一条分支把 P2 特征接进来 - [-1, 1, Conv, 256, 3] - [-1, 1, nn.Upsample, [None, 2, nearest]] - [[-1, 8], 1, Concat, [1]] # 8 是 P2 层在 backbone 中的索引改完 yaml 之后训练命令和标准流程一样yolo detect train \ datavisdrone.yaml \ modelyolo11n_custom.yaml \ epochs150 \ imgsz960 \ batch16 \ device0这里三个参数要特别注意。第一个是imgsz小目标场景建议直接提到 960 甚至 1280输入分辨率翻倍小目标在特征图上的像素面积增加一倍效果比任何模块改进都明显。第二个是epochs加了 P2 层后模型参数量变大训练周期太少学不出来150 是个相对安全的起点。第三个是学习率自定义结构后默认学习率可能偏高第一次训练建议把 lr0 从默认值调低一点比如 0.005 起步。除了 P2 层另一个常见改进是在 neck 里插入注意力模块。类似 HCANet 这类把通道注意力和空间注意力并联的思路可以作为一个即插即用模块加在特征融合的位置。通道注意力解决“只看哪个通道重要”的问题空间注意力解决“看图中哪个位置重要”的问题对小目标提升比较明显。我的经验是这类涨点有随机性换数据集后不一定复现所以一定要用第 6 章的回归测试方法验证效果别单看一两张图就下结论。4. 让视觉大模型给 YOLOv11 打工伪标签、CLIP 过滤与知识蒸馏4.1 视觉大模型能解决什么封闭类别与标注成本YOLOv11 是一个封闭词汇检测器训练时标签就固定死了。新加一个品类就要重新标注几百上千张图还要处理类别不均衡和标注噪声。视觉大模型这时候的价值不是替代 YOLOv11 做实时检测而是在离线环节把数据准备工作做得更自动化。比如 Grounding DINO 这类开放词汇检测模型只要你给它一句文本描述它就能在图片里找到对应目标。CLIP 这样的图文对齐模型可以判断一个裁剪区域和一段文本的匹配程度。这些能力用来生成伪标签、过滤误检、给候选框做精细分类都非常合适。但它们的推理速度和稳定性都不适合产线实时场景所以我的做法是把它们放进离线流程让它们产出的数据来训练 YOLOv11 或者校正 YOLOv11 的输出。4.2 用 Grounding DINO 生成伪标签并转成 YOLO 格式用 Grounding DINO 生成伪标签的思路很简单把类别名写进提示词在训练图上跑一遍把输出的框整理成 YOLO 需要的 txt 格式。这样能把人工标注量砍掉大半前期至少能有一批弱标签数据把模型先训起来。from transformers import AutoProcessor, AutoModelForZeroShotObjectDetection prompts [a bolt, a nut, a washer] processor AutoProcessor.from_pretrained(IDEA-Research/grounding-dino-base) model AutoModelForZeroShotObjectDetection.from_pretrained(IDEA-Research/grounding-dino-base) inputs processor(imagesimg, textprompts, return_tensorspt) outputs model(**inputs) # 把输出框整理成 YOLO 格式的归一化坐标并写文件 # 注意 grounding dino 输出的是 [cx, cy, w, h]需要确认是否已经是归一化的落地时有几个细节必须处理。第一Grounding DINO 输出的框格式和 YOLO 不同写 txt 前要做坐标换算转换错误的话训练直接崩。第二提示词不能太抽象尽量用具体的视觉描述比如“一个银色的圆头螺栓”比“螺栓”效果好得多。第三伪标签不能全信至少要抽 20% 的图人工复核一遍这个比例我一般不会降。伪标签的价值在于把标注工作量从“画框”变成“改框”。画框要一笔一笔来改框只需要拖动一个偏了几像素的矩形效率差距很大。等 YOLOv11 用这批数据训出第一版模型后你再回头用这个模型辅助标注下一轮数据整个数据飞轮就转起来了。4.3 用 CLIP 做候选框过滤帮 YOLOv11 赶走误检YOLOv11 在复杂背景下经常把纹理相似的背景区域当成目标尤其是产线上反光金属和深色零件。这时候与其反复调置信度阈值不如把候选框裁剪下来交给 CLIP 做一次文本语义判断。from PIL import Image from transformers import CLIPProcessor, CLIPModel clip_model CLIPModel.from_pretrained(openai/clip-vit-base-patch32) clip_processor CLIPProcessor.from_pretrained(openai/clip-vit-base-patch32) def clip_refine(crop, candidates): inputs clip_processor( textcandidates, imagescrop, return_tensorspt, ) probs clip_model(**inputs).logits_per_image.softmax(dim1) best_idx probs.argmax().item() return candidates[best_idx], probs[0, best_idx].item()candidates是类似[a bolt, a nut, a washer, background]这样的文本列表。把 YOLOv11 的候选框裁剪成小图后送进 CLIP如果它判断成 background 或者置信度低于某个阈值直接丢掉。这个方案在类别容易混淆的场景特别有效比如螺丝和垫片外观差距不明显纯靠视觉特征很容易分错但加一句文本约束后准确率提升很明显。这个做法的代价是速度。CLIP 对单个裁剪区域判断一次大约要几十毫秒只能做离线抽检或者低帧率场景。如果你要实时处理建议把逻辑改成YOLOv11 每帧正常检测CLIP 只对低置信度区间的输出做复核置信度高于 0.85 的框直接放行这样能把 CLIP 的判断量降到极低。4.4 知识蒸馏把大模型的理解压缩进实时模型知识蒸馏的基本思路是把一个大模型当老师把 YOLOv11 当学生。老师输出的中间特征或类别分布包含着比硬标签更丰富的信息比如不同类别之间的相似关系、模糊目标的概率分布。学生学这些东西比只学 one-hot 标签更容易泛化。具体实现上我把老师模型的输出 logits 离线跑一遍存到磁盘缓存里训练时再加载避免每轮训练都过一遍大模型。蒸馏损失一般用 KL 散度配合原始的检测损失一起优化。这里有个实用的小技巧前几个 epoch 只让学生模型学蒸馏损失让输出分布先贴近老师后面再逐渐加大检测损失的权重收敛会更快。不过要提醒一点蒸馏在大模型和目标检测之间收益不像分类任务那么稳定。对小目标来说老师模型如果在小目标上本身就表现差蒸馏不仅没帮助反而把错误知识传给了学生。做蒸馏前先确认老师在你要检测的场景上是真的强。5. Jetson Nano 部署与目标跟踪TensorRT 导出、精度掉点与避坑记录5.1 Jetson Nano 的算力边界哪些 YOLOv11 权重能跑Jetson Nano 的定位是低功耗边缘设备4GB 版官方算力大约 472 GFLOPS跟主流服务器显卡相比差着两个数量级。在这个板子上跑 YOLOv11我的结论是yolo11n 有余量yolo11s 勉强能跑再往上就不建议了。如果你要跑更重的模型直接换 Jetson Orin不是所有问题都能靠优化解决。部署的第一步是确认 JetPack 版本然后装对应版本的 PyTorch。这里有个常见的坑在 Jetson 上直接pip install torch拉下来的是 x86 版包装完导入就报 Illegal instruction。正确做法是去 NVIDIA 官方提供的 JetPack wheel 列表里找对应小版本的 torch 文件。5.2 从 .pt 到 .engineTensorRT 导出两条路径TensorRT 是 NVIDIA 在 Jetson 上能跑出最高帧率的推理引擎。导出 .engine 文件常见有两条路径我通常先试官方接口直接导出失败或改参数不灵活时再用 trtexec 手动转。model YOLO(yolo11n.pt) # 路径一直接导出 TensorRT engine model.export( formatengine, imgsz640, halfTrue, # 开启 FP16几乎能提一倍帧率 dynamicFalse, # Jetson 上务必关闭动态尺寸 )# 路径二先在 PC 上导出 onnx拷贝到板子后用 trtexec 转 engine # 在 PC 上执行 model.export(formatonnx, imgsz640, dynamicFalse) # 在 Jetson 上执行 trtexec --onnxyolo11n.onnx --saveEngineyolo11n.engine --fp16 --batch1我对你的建议是优先用路径二。trtexec会把每一步的层构建时间、显存占用和推理延迟打印出来出问题好排查。dynamicFalse这个参数是我特别要强调的Jetson 上如果用动态尺寸转出来的 engine 在运行时经常报 shape mismatch。如果一定要支持多分辨率最稳妥的办法是把几种分辨率各自转一个 engine运行时按输入尺寸切换。5.3 目标跟踪track 接口、ByteTrack 与 ID 稳定YOLOv11 官方接口直接带了跟踪能力model.track()底层接的是 ByteTrack 或 BoT-SORT。ByteTrack 在低帧率视频上表现更稳BoT-SORT 在遮挡场景下有额外处理。这两者都是追踪器配置用不同 yaml 文件切换。model YOLO(yolo11n.engine) # 加载导出的 engine results model.track( sourcecam.mp4, persistTrue, # 关键参数跨帧保持 ID 不丢 trackerbytetrack.yaml, conf0.3, iou0.5, imgsz640, )persistTrue是整个跟踪最关键的参数。缺了它tracker 不会记住上一帧的目标 ID每一帧都把目标当新目标处理ID 反复跳变下游的计数、轨迹绘制全部失效。另一个容易忽略的是 tracker 配置文件里的max_age参数它控制目标丢失后最多保留多久的轨迹。目标被遮挡几帧后重现max_age太小会导致 ID 直接换新太大又会在丢失时间过长时误连接两个目标。我一般根据场景的遮挡时长把 max_age 设在 30 到 60 之间。5.4 避坑记录四个反复出现的部署问题坑一onnx 转 engine 报 shape mismatch。现象是在 Jetson 上用 trtexec 转模型加载时提示输入尺寸不匹配。 原因是导出的 onnx 带了动态维度而 trtexec 默认按固定 batch 处理。 解决方式是在导出 onnx 时设置dynamicFalse或者在 trtexec 命令里用--minShapes、--optShapes、--maxShapes显式指定固定尺寸。坑二FP16 推理出现大量偏移框和错检。现象是模型在 PC 上 FP16 效果正常到 Jetson 上出现乱框。 原因是个别层的激活值在 FP16 下溢出常见于小目标分支和上采样层。 解决方式是先关闭half选项导出 FP32 engine 做对照实验。如果 FP32 正常但掉帧明显可以考虑混合精度让 ultralytics 导出 engine 后用 trtexec 的层精度覆写接口把指定层的精度单独设回 FP32。坑三保存推理结果图片泛蓝。现象是用 Python 保存r.plot()的结果后整张图色调偏蓝。 原因是r.plot()返回的是 BGR 数组用 PIL 保存时按 RGB 解释导致通道错位。 解决方式是统一用cv2.imwrite保存或在使用 PIL 前手动转换cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。这个错位问题在 JetPack 自带的 OpenCV 版本上更容易触发因为不同版本的像素格式默认值有差异。坑四视频跟踪 ID 频繁跳变轨迹断断续续。现象是model.track()跑出来的视频里同一个人的 ID 从 1 跳到 8 又跳回 1。 原因通常是推理帧率太低目标在两帧之间的位移过大追踪器无法关联到同一目标。 解决方式是把输入尺寸从 640 降到 480关闭可视化绘制减少 CPU 开销或者把视频帧率降到 10 FPS 再做跟踪。如果是嵌入式环境跑跟踪我建议关闭画框功能只保存跟踪状态因为绘图在 JetPack 上效率不高会额外吃掉大量 CPU。6. 用批量回归测试验证改进mAP、FPS 与随机种子的三层把关做任何修改之后都不能只看几张图的视觉效果来下结论。这也是我在处理 YOLOv11 时养成的习惯把改动前后的模型放到同一份验证集上批量对比让数字说话。from ultralytics import YOLO for weight in [yolo11n.pt, runs/train/exp2/weights/best.pt]: model YOLO(weight) metrics model.val( datavisdrone.yaml, imgsz960, splitval, # 统一用验证集别用训练集 ) print(weight) print(mAP50-95:, metrics.box.map) print(mAP50:, metrics.box.map50)对比时重点看三个数字mAP50-95、mAP50 和小目标类别的 AP。mAP50-95 是主指标但它对小目标不敏感小目标场景单独看小类别的 AP 会更直观。另一个容易漏掉的是训练随机性。PyTorch 的随机种子不固定两次训练同一份数据可能差 0.5 个点所以对比实验务必固定seed0否则你辛苦调的参数可能只是运气。要确认改动是否真的有效最稳妥的做法是同配置跑两轮取平均。最后还是要说一句看 FPS 的教训PC 上跑的 FPS 不代表 Jetson 上的 FPS。你在服务器上测出的 120 FPS 在板子上可能只有 15一切部署指标都要以目标硬件实测为准。我自己就有过先斩后奏的翻车经历把 PC 上的耗时当宣传数据报上去现场一测直接被打脸。从那以后我把导出 engine、固定输入尺寸、跑板子实测这三步列成了必经流程这个习惯帮我避掉了不少麻烦。希望这篇能帮到你少踩一些同样的坑。本文还有配套的精品资源点击获取
简介面向目标检测研究者与算法工程师的YOLOv11与视觉大模型知识分享PDF文档系统梳理YOLO系列从v1到v11的演进脉络对比两阶段与单阶段检测框架的精度与速度权衡并解析FPN多尺度特征融合、骨干网络与特征金字塔等核心模块设计。资源压缩包共1个PDF文件大小仅1.47MB便于下载后离线阅读与快速查阅。目前已有46人学习。内容包括模块化、轻量化、激活函数选择、正则化等网络结构设计原则并结合多尺度检测机制与损失函数构建方法帮助读者理解YOLOv11相对视觉大模型在速度与准确性上的竞争力适合快速掌握目标检测技术要点与模型演进设计原理的开发者参考。1. YOLOv11 与视觉大模型为什么实时检测不直接交给大模型拿到一个产线质检或安防巡检需求时我第一个想到的检测方案不会是视觉大模型而是 YOLOv11。原因很直接产线上要的是每帧几十毫秒出结果而视觉大模型虽然能看懂开放词汇、能做文本交互但它慢、贵、推理还不稳定。YOLOv11 在这种实时场景里依然是工业落地的默认选项。真正能落地的组合是视觉大模型离线负责标注、过滤、知识蒸馏YOLOv11 在线负责实时推理。这篇文章就顺着环境配置、小目标改进、大模型辅助、Jetson 部署这条链路把每一步的做法和踩过的坑拆给你。2. 跑通第一张推理图环境配置、权重选择与保存推理结果的三种写法2.1 先让环境不翻车最小依赖组合与快速验证YOLOv11 的环境配置门槛比上一代低不少因为官方把训练、推理、导出全部收进了 ultralytics 这一个包里。常见做法是先建一个干净的虚拟环境再装依赖避免和系统里其他项目的包打架。# 建一个干净环境Python 版本选 3.10 比较稳 conda create -n yolo11 python3.10 -y conda activate yolo11 # ultralytics 会自动拉取 torch 和 torchvision pip install ultralytics # 验证环境是否可用 yolo version这里有两个容易踩的细节。第一个是pip install ultralytics会自动装一份默认的 PyTorchCPU 版。如果你机器上有 GPU 且提前装好了 CUDA 版 torch建议先装你要的 torch 和 torchvision再执行pip install ultralytics --no-deps跳过依赖避免把 GPU 版覆盖掉。第二个是在 JetPack 板子上不要直接用 pip 拉 torch后面第 5 章会专门说。yolo version能打印出版本号说明环境已经通了。第一次调用YOLO(yolo11n.pt)时程序会自动下载权重如果网络不稳定建议先手动下载好 .pt 文件放到脚本同目录再加载本地路径。2.2 权重怎么选从 n 到 x 的取舍YOLOv11 官方权重按宽度和深度分成五个档位命名规则和上一代一致。我第一次跑项目时直接上了最大的 x 版结果一张图推理要 200 多毫秒产线要求 50 毫秒以内直接被否。后来才发现大部分项目的核心瓶颈不在精度而在延迟、显存和带宽。权重模型规模推理速度直观适用场景yolo11n最小最快Jetson、边缘盒子、快速验证流程yolo11s小快实时监控、产线质检yolo11m中中精度优先的中小型 GPU 服务器yolo11l/x大慢离线分析、复杂场景学术实验我的建议是如果是第一次跑通流程直接用yolo11n.pt等整套代码跑通了再根据实际帧率余量换大模型。别一上来就追求高精度先把链路打通后面换权重只是改一行字符串的事。2.3 保存推理结果的三种写法save、plot 与 json 导出推理本身非常简单一行predict就能出结果。真正讲究的是结果保存方式因为后续不管是接目标跟踪还是接视觉大模型做二次过滤都需要拿到结构化的框数据而不是一张画好的图片。from ultralytics import YOLO model YOLO(yolo11n.pt) results model.predict( sourcetest.jpg, # 单张图传文件夹路径就是批量预测 conf0.25, # 置信度阈值低于它的目标会被剔除 iou0.45, # NMS 的 IoU 阈值两个框重叠超过它会被合并 imgsz640, # 推理尺寸640 是速度和精度的平衡点 devicecpu, # 有 GPU 写 0没有就写 cpu saveTrue, # 最省事的保存方式自动存到 runs/detect/predictX )这段代码里最容易忽略的是conf和iou两个参数。conf0.25的意思是置信度低于 0.25 的框直接丢弃如果你想做可视化分析可以把阈值降到 0.1看看到底漏了多少目标。iou0.45控制重叠框的合并强度小目标密集场景建议降到 0.3避免近邻目标被当成一个框。saveTrue会把带标注的图片自动存到runs/detect/predictX这是最不需要动脑的写法。但如果你要在脚本里继续处理结果更常用的是下面这两种# 写法一用 r.plot() 拿原始数组自己控制保存 import cv2 for i, r in enumerate(results): img_bgr r.plot() # 返回 BGR 的 numpy 数组 cv2.imwrite(fplot_{i}.jpg, img_bgr) # 用 cv2 保存不要用 PIL boxes r.boxes.xyxy.cpu().numpy() # [x1, y1, x2, y2] scores r.boxes.conf.cpu().numpy() # 每个框的置信度 classes r.boxes.cls.cpu().numpy().astype(int)用r.plot()而不是r.save()原因是plot()返回的是 numpy 数组你可以先做拼接、加遮挡、叠加统计信息再统一保存。有一个细节必须强调r.plot()返回的是 BGR 格式用cv2.imwrite保存没问题如果换成 PIL 的Image.save颜色会泛蓝这个问题我在第 5 章的避坑记录里详细说。# 写法二导出成 json给上游业务系统用 import json def results_to_json(results, path): out [] for r in results: boxes r.boxes.xyxy.cpu().numpy() confs r.boxes.conf.cpu().numpy() clss r.boxes.cls.cpu().numpy().astype(int) names r.names for box, conf, c in zip(boxes, confs, clss): out.append({ class: names[c], conf: float(conf), box: [float(v) for v in box], }) with open(path, w, encodingutf-8) as f: json.dump(out, f, ensure_asciiFalse, indent2)这段代码在做工业项目时非常常用。检测结果最终要落到业务系统里json 格式比图片文件更容易被上游消费。注意box里的坐标是像素坐标如果你的业务系统要画到 GIS 地图或原始大图上记得先确认坐标原点和缩放比例不要直接拿原始坐标去匹配不同分辨率的图像。3. 小目标为何翻车YOLOv11 网络结构拆解与 P2 检测层改进路线3.1 backbone 与 neckC3k2、SPPF 和特征金字塔在做什么YOLOv11 的网络结构依然延续 backbone、neck、head 三段式设计但内部模块做了明显调整。backbone 负责逐层下采样提取特征核心组件是卷积块和 C3k2 模块。C3k2 可以理解为 C3 的改进版它把标准 Bottleneck 替换成了两个更小的卷积核分支让相同计算量下能提取更丰富的特征。相比上一代 C3C3k2 在同等参数下的梯度流动更顺畅训练时收敛更稳。在 backbone 末端还有一个 SPPF 模块它通过三个串联的最大池化把不同感受野的特征拼接起来。SPPF 的作用是让模型在最后一层能同时看到局部细节和大范围上下文对检测尺度差异比较大的场景很关键。neck 部分依旧是特征金字塔结构负责把高层的语义特征和浅层的纹理特征融合。YOLOv11 的 head 改成了 anchor-free 设计每个位置直接预测目标的中心点和宽高省掉了预设 anchor 的调参成本实现上也简化了很多。但结构升级带来一个容易被忽视的问题模型默认的输出特征图只有三层分别对应原图下采样 8 倍、16 倍和 32 倍。如果一个目标在原始图上只有 12x12 像素经过 32 倍下采样后它在最后一层特征图上连 1 个像素都不到几乎不可能被检测到。这是小目标翻车最根本的结构原因。3.2 小目标检测有多难下采样倍数、NMS 与标注质量的三重打击做个简单换算输入 640x640 的图检测层分别输出 80x80、40x40、20x20 的特征图。20x20 那一层的每个格子对应原图 32 个像素。换句话说小于 32x32 的目标在这个层上几乎没有响应。航拍场景里的车辆、产线上的小零件、监控里的远处行人都属于这一类。小目标翻车的第二重打击来自 NMS。小目标框之间的 IoU 对位置偏移极度敏感一个 10x10 的框只要偏移 2 个像素IoU 就掉到 0.6 以下导致相邻目标很容易被合并或漏检。第三重打击是数据标注质量。小目标在标注时本来就容易产生 1~2 个像素的偏差这个偏差对普通目标无所谓但对小目标来说直接改变了目标的中心点和宽高比例模型学到的边界很模糊。我在处理航拍数据时第一步不是改模型而是先统计目标尺寸分布。用脚本跑一遍所有标注框看看有多少框的宽度小于 16 像素。如果这类目标占比超过 20%任何结构优化都救不回来必须先把图像切成 patch 或者提高输入分辨率。这属于数据层面的前置工程很多人忽略。3.3 改进路线P2 层、注意力模块与训练参数调整YOLOv11 的小目标改进最直接有效的是增加一个 P2 检测层。P2 层对应下采样 4 倍的特征图分辨率和目标细节都保留得更好。常见做法是以 yolo11 的配置文件为基础复制出一份自定义 yaml在 backbone 里额外引出浅层特征再在 head 里加一条融合分支。# 复制 ultralytics/cfg/models/11/yolo11.yaml 后修改 # 下面只是结构示意具体层索引以你复制的 yaml 为准 backbone: - [-1, 1, Conv, 64, 3, 2] # 0-P11/2 下采样 - [-1, 1, Conv, 128, 3, 2] # 1-P21/4 下采样小目标主要靠这里 # 后续层保持默认只额外记录 P2 层的输出索引 head: # 在 head 最前面增加一条分支把 P2 特征接进来 - [-1, 1, Conv, 256, 3] - [-1, 1, nn.Upsample, [None, 2, nearest]] - [[-1, 8], 1, Concat, [1]] # 8 是 P2 层在 backbone 中的索引改完 yaml 之后训练命令和标准流程一样yolo detect train \ datavisdrone.yaml \ modelyolo11n_custom.yaml \ epochs150 \ imgsz960 \ batch16 \ device0这里三个参数要特别注意。第一个是imgsz小目标场景建议直接提到 960 甚至 1280输入分辨率翻倍小目标在特征图上的像素面积增加一倍效果比任何模块改进都明显。第二个是epochs加了 P2 层后模型参数量变大训练周期太少学不出来150 是个相对安全的起点。第三个是学习率自定义结构后默认学习率可能偏高第一次训练建议把 lr0 从默认值调低一点比如 0.005 起步。除了 P2 层另一个常见改进是在 neck 里插入注意力模块。类似 HCANet 这类把通道注意力和空间注意力并联的思路可以作为一个即插即用模块加在特征融合的位置。通道注意力解决“只看哪个通道重要”的问题空间注意力解决“看图中哪个位置重要”的问题对小目标提升比较明显。我的经验是这类涨点有随机性换数据集后不一定复现所以一定要用第 6 章的回归测试方法验证效果别单看一两张图就下结论。4. 让视觉大模型给 YOLOv11 打工伪标签、CLIP 过滤与知识蒸馏4.1 视觉大模型能解决什么封闭类别与标注成本YOLOv11 是一个封闭词汇检测器训练时标签就固定死了。新加一个品类就要重新标注几百上千张图还要处理类别不均衡和标注噪声。视觉大模型这时候的价值不是替代 YOLOv11 做实时检测而是在离线环节把数据准备工作做得更自动化。比如 Grounding DINO 这类开放词汇检测模型只要你给它一句文本描述它就能在图片里找到对应目标。CLIP 这样的图文对齐模型可以判断一个裁剪区域和一段文本的匹配程度。这些能力用来生成伪标签、过滤误检、给候选框做精细分类都非常合适。但它们的推理速度和稳定性都不适合产线实时场景所以我的做法是把它们放进离线流程让它们产出的数据来训练 YOLOv11 或者校正 YOLOv11 的输出。4.2 用 Grounding DINO 生成伪标签并转成 YOLO 格式用 Grounding DINO 生成伪标签的思路很简单把类别名写进提示词在训练图上跑一遍把输出的框整理成 YOLO 需要的 txt 格式。这样能把人工标注量砍掉大半前期至少能有一批弱标签数据把模型先训起来。from transformers import AutoProcessor, AutoModelForZeroShotObjectDetection prompts [a bolt, a nut, a washer] processor AutoProcessor.from_pretrained(IDEA-Research/grounding-dino-base) model AutoModelForZeroShotObjectDetection.from_pretrained(IDEA-Research/grounding-dino-base) inputs processor(imagesimg, textprompts, return_tensorspt) outputs model(**inputs) # 把输出框整理成 YOLO 格式的归一化坐标并写文件 # 注意 grounding dino 输出的是 [cx, cy, w, h]需要确认是否已经是归一化的落地时有几个细节必须处理。第一Grounding DINO 输出的框格式和 YOLO 不同写 txt 前要做坐标换算转换错误的话训练直接崩。第二提示词不能太抽象尽量用具体的视觉描述比如“一个银色的圆头螺栓”比“螺栓”效果好得多。第三伪标签不能全信至少要抽 20% 的图人工复核一遍这个比例我一般不会降。伪标签的价值在于把标注工作量从“画框”变成“改框”。画框要一笔一笔来改框只需要拖动一个偏了几像素的矩形效率差距很大。等 YOLOv11 用这批数据训出第一版模型后你再回头用这个模型辅助标注下一轮数据整个数据飞轮就转起来了。4.3 用 CLIP 做候选框过滤帮 YOLOv11 赶走误检YOLOv11 在复杂背景下经常把纹理相似的背景区域当成目标尤其是产线上反光金属和深色零件。这时候与其反复调置信度阈值不如把候选框裁剪下来交给 CLIP 做一次文本语义判断。from PIL import Image from transformers import CLIPProcessor, CLIPModel clip_model CLIPModel.from_pretrained(openai/clip-vit-base-patch32) clip_processor CLIPProcessor.from_pretrained(openai/clip-vit-base-patch32) def clip_refine(crop, candidates): inputs clip_processor( textcandidates, imagescrop, return_tensorspt, ) probs clip_model(**inputs).logits_per_image.softmax(dim1) best_idx probs.argmax().item() return candidates[best_idx], probs[0, best_idx].item()candidates是类似[a bolt, a nut, a washer, background]这样的文本列表。把 YOLOv11 的候选框裁剪成小图后送进 CLIP如果它判断成 background 或者置信度低于某个阈值直接丢掉。这个方案在类别容易混淆的场景特别有效比如螺丝和垫片外观差距不明显纯靠视觉特征很容易分错但加一句文本约束后准确率提升很明显。这个做法的代价是速度。CLIP 对单个裁剪区域判断一次大约要几十毫秒只能做离线抽检或者低帧率场景。如果你要实时处理建议把逻辑改成YOLOv11 每帧正常检测CLIP 只对低置信度区间的输出做复核置信度高于 0.85 的框直接放行这样能把 CLIP 的判断量降到极低。4.4 知识蒸馏把大模型的理解压缩进实时模型知识蒸馏的基本思路是把一个大模型当老师把 YOLOv11 当学生。老师输出的中间特征或类别分布包含着比硬标签更丰富的信息比如不同类别之间的相似关系、模糊目标的概率分布。学生学这些东西比只学 one-hot 标签更容易泛化。具体实现上我把老师模型的输出 logits 离线跑一遍存到磁盘缓存里训练时再加载避免每轮训练都过一遍大模型。蒸馏损失一般用 KL 散度配合原始的检测损失一起优化。这里有个实用的小技巧前几个 epoch 只让学生模型学蒸馏损失让输出分布先贴近老师后面再逐渐加大检测损失的权重收敛会更快。不过要提醒一点蒸馏在大模型和目标检测之间收益不像分类任务那么稳定。对小目标来说老师模型如果在小目标上本身就表现差蒸馏不仅没帮助反而把错误知识传给了学生。做蒸馏前先确认老师在你要检测的场景上是真的强。5. Jetson Nano 部署与目标跟踪TensorRT 导出、精度掉点与避坑记录5.1 Jetson Nano 的算力边界哪些 YOLOv11 权重能跑Jetson Nano 的定位是低功耗边缘设备4GB 版官方算力大约 472 GFLOPS跟主流服务器显卡相比差着两个数量级。在这个板子上跑 YOLOv11我的结论是yolo11n 有余量yolo11s 勉强能跑再往上就不建议了。如果你要跑更重的模型直接换 Jetson Orin不是所有问题都能靠优化解决。部署的第一步是确认 JetPack 版本然后装对应版本的 PyTorch。这里有个常见的坑在 Jetson 上直接pip install torch拉下来的是 x86 版包装完导入就报 Illegal instruction。正确做法是去 NVIDIA 官方提供的 JetPack wheel 列表里找对应小版本的 torch 文件。5.2 从 .pt 到 .engineTensorRT 导出两条路径TensorRT 是 NVIDIA 在 Jetson 上能跑出最高帧率的推理引擎。导出 .engine 文件常见有两条路径我通常先试官方接口直接导出失败或改参数不灵活时再用 trtexec 手动转。model YOLO(yolo11n.pt) # 路径一直接导出 TensorRT engine model.export( formatengine, imgsz640, halfTrue, # 开启 FP16几乎能提一倍帧率 dynamicFalse, # Jetson 上务必关闭动态尺寸 )# 路径二先在 PC 上导出 onnx拷贝到板子后用 trtexec 转 engine # 在 PC 上执行 model.export(formatonnx, imgsz640, dynamicFalse) # 在 Jetson 上执行 trtexec --onnxyolo11n.onnx --saveEngineyolo11n.engine --fp16 --batch1我对你的建议是优先用路径二。trtexec会把每一步的层构建时间、显存占用和推理延迟打印出来出问题好排查。dynamicFalse这个参数是我特别要强调的Jetson 上如果用动态尺寸转出来的 engine 在运行时经常报 shape mismatch。如果一定要支持多分辨率最稳妥的办法是把几种分辨率各自转一个 engine运行时按输入尺寸切换。5.3 目标跟踪track 接口、ByteTrack 与 ID 稳定YOLOv11 官方接口直接带了跟踪能力model.track()底层接的是 ByteTrack 或 BoT-SORT。ByteTrack 在低帧率视频上表现更稳BoT-SORT 在遮挡场景下有额外处理。这两者都是追踪器配置用不同 yaml 文件切换。model YOLO(yolo11n.engine) # 加载导出的 engine results model.track( sourcecam.mp4, persistTrue, # 关键参数跨帧保持 ID 不丢 trackerbytetrack.yaml, conf0.3, iou0.5, imgsz640, )persistTrue是整个跟踪最关键的参数。缺了它tracker 不会记住上一帧的目标 ID每一帧都把目标当新目标处理ID 反复跳变下游的计数、轨迹绘制全部失效。另一个容易忽略的是 tracker 配置文件里的max_age参数它控制目标丢失后最多保留多久的轨迹。目标被遮挡几帧后重现max_age太小会导致 ID 直接换新太大又会在丢失时间过长时误连接两个目标。我一般根据场景的遮挡时长把 max_age 设在 30 到 60 之间。5.4 避坑记录四个反复出现的部署问题坑一onnx 转 engine 报 shape mismatch。现象是在 Jetson 上用 trtexec 转模型加载时提示输入尺寸不匹配。 原因是导出的 onnx 带了动态维度而 trtexec 默认按固定 batch 处理。 解决方式是在导出 onnx 时设置dynamicFalse或者在 trtexec 命令里用--minShapes、--optShapes、--maxShapes显式指定固定尺寸。坑二FP16 推理出现大量偏移框和错检。现象是模型在 PC 上 FP16 效果正常到 Jetson 上出现乱框。 原因是个别层的激活值在 FP16 下溢出常见于小目标分支和上采样层。 解决方式是先关闭half选项导出 FP32 engine 做对照实验。如果 FP32 正常但掉帧明显可以考虑混合精度让 ultralytics 导出 engine 后用 trtexec 的层精度覆写接口把指定层的精度单独设回 FP32。坑三保存推理结果图片泛蓝。现象是用 Python 保存r.plot()的结果后整张图色调偏蓝。 原因是r.plot()返回的是 BGR 数组用 PIL 保存时按 RGB 解释导致通道错位。 解决方式是统一用cv2.imwrite保存或在使用 PIL 前手动转换cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。这个错位问题在 JetPack 自带的 OpenCV 版本上更容易触发因为不同版本的像素格式默认值有差异。坑四视频跟踪 ID 频繁跳变轨迹断断续续。现象是model.track()跑出来的视频里同一个人的 ID 从 1 跳到 8 又跳回 1。 原因通常是推理帧率太低目标在两帧之间的位移过大追踪器无法关联到同一目标。 解决方式是把输入尺寸从 640 降到 480关闭可视化绘制减少 CPU 开销或者把视频帧率降到 10 FPS 再做跟踪。如果是嵌入式环境跑跟踪我建议关闭画框功能只保存跟踪状态因为绘图在 JetPack 上效率不高会额外吃掉大量 CPU。6. 用批量回归测试验证改进mAP、FPS 与随机种子的三层把关做任何修改之后都不能只看几张图的视觉效果来下结论。这也是我在处理 YOLOv11 时养成的习惯把改动前后的模型放到同一份验证集上批量对比让数字说话。from ultralytics import YOLO for weight in [yolo11n.pt, runs/train/exp2/weights/best.pt]: model YOLO(weight) metrics model.val( datavisdrone.yaml, imgsz960, splitval, # 统一用验证集别用训练集 ) print(weight) print(mAP50-95:, metrics.box.map) print(mAP50:, metrics.box.map50)对比时重点看三个数字mAP50-95、mAP50 和小目标类别的 AP。mAP50-95 是主指标但它对小目标不敏感小目标场景单独看小类别的 AP 会更直观。另一个容易漏掉的是训练随机性。PyTorch 的随机种子不固定两次训练同一份数据可能差 0.5 个点所以对比实验务必固定seed0否则你辛苦调的参数可能只是运气。要确认改动是否真的有效最稳妥的做法是同配置跑两轮取平均。最后还是要说一句看 FPS 的教训PC 上跑的 FPS 不代表 Jetson 上的 FPS。你在服务器上测出的 120 FPS 在板子上可能只有 15一切部署指标都要以目标硬件实测为准。我自己就有过先斩后奏的翻车经历把 PC 上的耗时当宣传数据报上去现场一测直接被打脸。从那以后我把导出 engine、固定输入尺寸、跑板子实测这三步列成了必经流程这个习惯帮我避掉了不少麻烦。希望这篇能帮到你少踩一些同样的坑。本文还有配套的精品资源点击获取
