YOLO 系列这两年更新快得离谱,快到我经常在评论区看到同一种困惑:“yolo到底第几代了”“最新版本是不是 v11”“我还在用 v5 是不是落伍了”。我自己的项目从 v5 一路用到 v8,最近又把 v11 完整过了一遍,顺手把环境配置、数据集准备、训练调参、模型导出这条链路重新跑通了一次。如果你也在纠结“该从哪个版本入门”“要不要立刻切到 v11”,今天这篇内容应该能帮你在十分钟内把版本脉络和选型逻辑理清楚。
这篇整理按“版本演进 → 选型思路 → 环境搭建 → 数据准备 → 训练优化 → 部署与改进”的顺序展开,不只是罗列特性,更侧重每个版本到底改了什么、为什么这么改,以及你在 2026 年做新项目时,站在哪个版本上起步性价比最高。适合刚接触目标检测的入门者,也适合正在做模型选型、想从老版本迁移的工程师参考。
1. 版本演进:从 YOLOv5 到 YOLOv11 到底改了些什么
1.1 为什么 YOLOv5 至今仍是“经典底子”
YOLOv5 的里程碑意义不只是精度和速度,而是它把“研究代码”变成了“工程工具箱”。2020 年 Ultralytics 团队推出的 v5,本质上是对整个 YOLO 系列做了一次工程化重构:骨干网络用 CSPDarknet53,颈部结构用 PANet 做多尺度特征融合,检测头保留 anchor-based 的方式,同时把 Mosaic 数据增强、自动锚框计算、超参进化等训练技巧一并集成进来。这套组合让普通用户只需要准备好 COCO 格式或 YOLO 格式的数据,跑一条命令行就能完成训练、验证和导出。
真正让 v5 生命力延续到今天的原因,是它的“易用性”和“稳定性”几乎形成了一个生态。网上能找到的教程、第三方改进方案、部署案例大部分都是围绕 v5 展开的,很多公司的历史项目也建立在 v5 基础上。我自己的感觉是,v5 的小模型在资源受限的边缘设备上至今还能打,它的 n/s 系列体积小、推理快,特别是在树莓派、Jetson 这类平台上依然有实用价值。
从结构上看,v5 是 anchor-based 设计的成熟形态,后续版本在检测头上有了明显变化,但很多骨干网络设计的思路仍然能看到 v5 的影子。所以不管你现在用不用 v5,理解它的组成对看懂 v8、v11 都有帮助。
1.2 v6、v7、v8:把检测头重构的三个方向
v6 是美团视觉智能部开源的版本,它的贡献是把检测头换成了 anchor-free 形式,并且引入了解耦检测头——把分类和回归拆成不同分支,减少了两个任务相互干扰的问题。v6 在工程部署上也做了很多针对性优化,比如使用更高效的卷积模块替换原结构,使得模型在工业落地时更容易压缩和加速。
v7 走的是“极致性能”路线。它提出了 E-ELAN 结构,通过扩展、打乱、合并的方式增强特征聚合,并且通过辅助训练头在训练阶段给网络提供更丰富的梯度信号,推理时再把辅助头剪掉。它的设计思路更偏向研究,代码风格没有 v5、v8 那么“傻瓜式”,但对追求精度上限的人来说,v7 一直是值得参考的基线。
v8 是 Ultralytics 在 2023 年推出的正式版本,也是目前最常见的选择。它在 v5 的工程生态上进一步发展,把骨干模块从 C3 升级为 C2f,颈部使用 PAN-FPN 结构,检测头全面转向 anchor-free,同时还提供了检测、实例分割、姿态估计、分类四个任务的统一训练入口。v8 的另一大优势是 API 设计得非常简洁,官方提供的数据集格式、命令行接口和 Python 接口基本做到了“拿来即用”,这也是为什么很多新手教程都在讲 v8。
1.3 v9、v10、v11:从可编程梯度到端到端和注意力
v9 的核心思路是解决深层网络在特征提取过程中的信息丢失问题,为此提出了可编程梯度信息(PGI)机制,配合 GELAN 这种高效网络结构,在训练时能保留更多有效的梯度路径,从而让模型在参数不增加太多的情况下获得更好的精度。如果你想做精度优先的研究,v9 是可以认真读一读源码的版本。
v10 是另一个方向的尝试:实时端到端目标检测。它最大的特点是去掉了传统 YOLO 依赖的 NMS 后处理,采用双标签分配策略,让模型直接输出最终结果。这在高并发或低延迟场景下很有价值,因为省掉 NMS 能降低推理耗时,也避免了 NMS 参数调整带来的麻烦。
v11 是目前 Ultralytics 主线的新主力。它没有推翻 v8 的设计,而是在 v8 的基础上进一步优化了骨干和颈部结构,引入了 C3k2 模块和 C2PSA 注意力模块,强化了网络对关键特征的关注能力。实际使用中,v11 的收敛速度和相同配置下的精度相比 v8 有一定提升,并且在显存占用方面控制得不错。v11 也继承了 v8 那套统一训练接口,从 v8 切到 v11 的成本很低。
1.4 损失函数:YOLO 性能的一半天花板
很多人训练时只盯网络结构,忽略了损失函数的重要性。YOLO 系列的损失函数大致经历了从 IoU 到 GIoU、CIoU、再到各种变体的过程。v5 默认使用 GIoU,也能通过配置切换到 CIoU;v8 和 v11 使用 CIoU 加 DFL 的组合,其中 DFL 负责优化目标框的分布,让边界框回归更准确;v10 的端到端方案则用到了 TAL 标签分配和中辅助的损失策略。
从调参的角度看,损失函数对收敛速度和小目标检测效果的影响非常直接。比如当你发现大目标检测还行、小目标经常漏检时,换用带有尺度感知能力的损失函数,比如 WIoU、Shape-IoU 这类变体,往往比盲目加深网络更有效。这一点在后面讲模型改进时我会再展开。
2. 2026 选型指南:照着场景选版本
2.1 各版本快速对比
| 版本 | 发布时间 | 检测头 | 关键结构 | 后处理 | 生态与特点 | 适合场景 |
|---|---|---|---|---|---|---|
| v5 | 2020 | anchor-based | CSPDarknet53 + PANet | NMS | 文档最多、历史项目多、模型轻量 | 老项目维护、边缘端小模型 |
| v6 | 2021 | anchor-free | EfficientRep + 解耦头 | NMS | 工业落地友好、部署优化 | 部署链路成熟、需要自研结构 |
| v7 | 2022 | anchor-based | E-ELAN + 辅助训练头 | NMS | 研究性、精度上限高 | 精度竞赛、论文基线 |
| v8 | 2023 | anchor-free | C2f + PAN-FPN | NMS | Ultralytics 官方生态、教程最全 | 入门学习、检测/分割/姿态统一任务 |
| v9 | 2023 | anchor-free | GELAN + PGI | NMS | 保持梯度信息的训练策略 | 探索新训练范式、高精度研究 |
| v10 | 2024 | anchor-free | 双标签分配 | 无 NMS | 端到端、低延迟 | 实时检测、高并发场景 |
| v11 | 2024之后 | anchor-free | C3k2 + C2PSA | NMS | 官方新主线、结构更新 | 新项目首选、追求更优精度与速度 |
2.2 入门学习首选 YOLOv8
如果你是第一次接触 YOLO,我的建议是先选 v8,而不是直接上最新版。原因很简单:v8 的资料量最大,遇到任何报错都能搜到解决方案,而且 v8 和 v11 的操作接口几乎一致,学会了 v8 再切 v11 也就是改一行模型名字的事。v8 同时支持检测、实例分割、姿态估计和分类,学习过程中可以顺带了解不同任务的训练差异,性价比很高。
v8 的代码结构也比较规整,适合阅读源码。很多人想搞懂“训练流程到底怎么跑的”,v8 的源码分层清晰,从数据集加载到损失计算都有独立模块,比直接啃 v11 的新结构更友好。先通过 v8 建立整体认知,再去看 v11 的改进点,效率会高很多。
2.3 科研改进和发论文,建议锚定 v5/v8/v11 之一
做算法改进和论文实验时,选一个社区认可度高的基座能省掉大量解释成本。v5、v8、v11 因为出自同一工程生态,代码规范、改动方便,第三方实现和对比实验也最多,审稿人更容易认可。如果你的改进方向是注意力机制、特征融合、损失函数或小目标检测,这三个版本都很合适。
相比之下,v7、v9、v10 的代码风格差异较大,改造成本更高。v9 的 PGI 思路很有价值,适合做训练策略方向的深度研究,但如果只是想“在 YOLO 上做个轻量改进发论文”,v8 或 v11 更高效。v10 的端到端特性适合做部署方向的选题,但作为通用基座,可参考的社区案例相对少一些。
2.4 工业部署和边缘设备,小模型和端到端优先
工业场景最看重稳定性和推理速度,我的建议是优先考虑 v8 的 n/s 系列或 v5 的 n/s 系列,模型体积小、推理延迟低,可以直接导出成 ONNX 或 TensorRT 格式,部署在 CPU、Jetson 或各类边缘盒子上。如果对时延特别敏感,例如要求单帧推理在几毫秒以内,v10 无 NMS 的特性会带来稳定的耗时优势。
实例分割场景可以直接选 v8-seg 或 v11-seg。v11-seg 在分割边界精细度上略有提升,显存占用与 v8-seg 相近,新项目可以直接上 v11-seg。需要注意,如果现有硬件驱动和 CUDA 版本较老,还是先确认 v11 的算子是否兼容,避免因为环境问题卡住上线进度。
2.5 换版本之前先想清楚这四件事
第一,旧代码兼容性。从 v5 切到 v8 或 v11,训练命令虽然都能通过 yolo 指令完成,但自定义数据集加载、回调函数、后处理代码可能会有差异。第二,预训练权重。v8 和 v11 的预训练权重是各自独立的,切换版本后需要重新下载对应权重的模型文件。第三,硬件约束。新版模型虽然往往更高效,但某些注意力模块在部分推理框架上的算子支持还不完善,需要提前验证。第四,NMS 差异。如果是从 v10 这类无 NMS 版本换到需要 NMS 的版本,部署时一定要把后处理环节加上。
3. 环境配置与安装实操
3.1 从零搭一套可用的 YOLO 环境
很多人在配置环境这一步就被劝退了,其实流程足够固定。先把 Anaconda 装好,然后创建一个独立的虚拟环境,避免把系统 Python 环境搞乱。推荐用 Python 3.9 或 3.10,PyTorch 版本根据自己显卡的 CUDA 版本选择。创建一个环境并安装 PyTorch 的命令如下:
conda create -n yolo python=3.10 conda activate yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118CUDA 版本选 cu118 还是 cu121,取决于你本机驱动支持的 CUDA 版本。可以用nvidia-smi查看驱动所支持的 CUDA 版本号,选择对应的 PyTorch 安装命令即可。装完 PyTorch 后,安装 Ultralytics 的库,这个库统一了 v8 和 v11 的使用方式:
pip install ultralytics这样训练环境就搭好了。顺手把 jupyter 或 notebook 装上也行,方便后面做数据探索和结果可视化。如果你喜欢用 PyCharm,直接在项目解释器里选择这个 conda 环境就能正常跑 YOLO。
3.2 没有 N 卡的环境怎么处理
如果你的电脑只有 CPU,或者用的是 AMD 显卡,也别急着放弃。CPU 模式下做推理是完全没有问题的,只是训练会比较慢。测试一张图片的检测效果,直接用 CPU 跑也就在几十毫秒到几百毫秒之间。如果只是学习 API 或做小规模实验,CPU 训练小模型加小尺寸输入也能跑通,只是要有耐心。
AMD 显卡跑 YOLO 的常见做法是把模型导出为 ONNX 格式,再用 ONNX Runtime 的 DirectML 执行提供程序来加速推理,或者使用 OpenVINO 工具套件在 Intel 平台和部分 AMD CPU 上做优化。这样一来,推理阶段就能获得不错的性能提升,不用在原生 PyTorch 训练上折腾驱动兼容问题。简而言之,训练可以用云 GPU 或公司的训练服务器,推理走 ONNX Runtime 是兼容性最好的方案。
yolo export model=yolov8n.pt format=onnx python -c "import onnxruntime as ort; print(ort.get_available_providers())"3.3 装完之后怎么确认环境没问题
环境配置完成后,建议先跑一次最小的预测任务,确认模型文件能自动下载、推理链路能正常工作。在终端里执行:
yolo predict model=yolov8n.pt source=https://ultralytics.com/images/bus.jpg如果没有报错,并且能在当前目录下的runs/detect/predict里看到带检测框的结果图片,说明环境已经通了。第一次运行会下载预训练权重,需要保证网络能访问官方权重地址。下载完成后,后续再跑就会直接读取本地缓存的权重文件,不再重复下载。
4. 数据准备与训练自己的数据集
4.1 从标注到 YOLO 格式的全流程
训练目标检测模型,数据标注是绕不开的一步。常见标注工具有 LabelImg 和 CVAT。LabelImg 适合小规模本地标注,界面简单,安装后选择 YOLO 格式保存,每张图会生成一个同名 txt 文件。CVAT 则适合团队协作和大量数据标注,它支持在线标注,也支持导出 YOLO 格式。
YOLO 格式的 txt 文件每一行表示一个目标,格式是:
class_id x_center y_center width height其中 x_center、y_center、width、height 都是归一化到 0 到 1 之间的浮点数,class_id 从 0 开始。举个例子,假设图片宽度是 640,一个目标的中心点横坐标是 320,宽度是 160,那么 x_center 就是 0.5,width 就是 0.25。
目录结构建议按照 YOLO 官方推荐的方式组织,后面训练时写路径会方便很多:
dataset/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/图片和标签要严格同名,只是扩展名不同。我踩过最大的坑就是图片从某个工具导出时,后缀变成大写.JPG,而标签文件名仍然是小写.jpg,导致训练时标签总是对不上。建议在训练前先写一个小脚本检查所有图片和标签的文件名一致性。
4.2 data.yaml 配置文件和训练命令
数据准备好后,需要写一个 data.yaml 文件告诉 YOLO 去哪里找数据。最简单的写法如下:
path: /path/to/dataset train: images/train val: images/val names: 0: person 1: carpath 是数据集根目录,train 和 val 是相对于根目录的训练集和验证集图片目录,names 是类别名称列表,顺序必须和标注时使用的类别索引一致。训练时直接通过命令行启动:
yolo detect train data=dataset/data.yaml model=yolov8n.pt epochs=100 imgsz=640 batch=16 device=0这里 model=yolov8n.pt 表示加载官方预训练权重继续训练,epochs 是训练轮数,imgsz 是输入图片缩放尺寸,batch 是批次大小,device=0 表示使用第一张显卡。如果是 CPU,device 可以写成 cpu,但训练速度会非常慢。
4.3 训练参数怎么调,为什么这么调
超参数对训练效果的影响很大,我说几个最常用的。
epochs 建议先设成 100 或 150,开启早停机制后,模型连续多轮验证指标不再提升就会自动停止。batch 大小取决于显存大小,显存不够时就调小 batch,或者降低 imgsz。imgsz 默认 640,如果显存不足可以先降到 512,精度会有轻微损失但训练速度更快。optimizer 默认是 auto,YOLO 会自动选择优化器,习惯上也可以用 SGD 或 AdamW。lr0 初始学习率默认是 0.01,从预训练权重微调时一般不用动。
数据增强方面,YOLO 默认开启 Mosaic 增强,它把四张训练图拼接成一张输入,能显著提升模型对遮挡和小目标的泛化能力。但要注意,如果数据集本身比较小,Mosaic 太强反而会让模型学不到稳定特征,这时可以适当关闭或降低 Mosaic 的概率。
4.4 数据集格式转换和多目标跟踪指标
很多公开数据集是 COCO 格式或 MOT 格式,直接用于 YOLO 训练前需要转换。COCO 转 YOLO 格式的常见思路是读取 JSON 注释里的 annotations,把 bbox 的 x、y、w、h 转成中心点加宽高的归一化格式,并按 image_id 分到训练和验证目录。MOT16 这类跟踪数据集转 YOLO 格式则更简单,每帧检测框的坐标文本可以直接整理成 YOLO 格式,只是需要额外处理类别映射和文件夹结构。
多目标跟踪的常用指标包括 MOTA、IDF1 和 HOTA,这些指标不是检测阶段能直接算出来的。你需要先跑完跟踪器,得到每个目标的轨迹序列,再用 py-motmetrics 或 TrackEval 这类工具,把轨迹结果和 ground truth 做对比,才能算出指标。如果对跟踪精度负责,建议直接用 TrackEval 的标准流程,代码可复现性更高。
5. 训练常见问题与排查技巧
5.1 Loss 不降或震荡,先查这五处
训练时 Loss 一直不降或者上下震荡,是新手最容易遇到的问题。我自己的排查顺序是:先看学习率,学习率过大会导致 Loss 震荡,学习率过小则收敛过慢,可以从默认值开始,再按 0.1 倍或 10 倍试探。再看数据集,检查标注框是否有大量超出图片边界的情况,或者类别数量不均衡。接着看分类数,data.yaml 里的 names 数量如果和标注文件中的 class_id 对不上,Loss 会直接异常。然后是数据增强,Mosaic 和 MixUp 在小数据集上可能反而干扰训练。最后看 batch 大小,太小会导致梯度更新方向不稳定,表现为 Loss 曲线噪声大。
完整的训练日志很重要。每轮迭代时的 box_loss、cls_loss、dfl_loss 分别对应边界框损失、分类损失和分布损失。如果 cls_loss 一直不降,多半是类别标签问题;如果 box_loss 降不下去,优先检查标注框质量。
5.2 显存不足和 OOM 的解决办法
训练时最常见报错就是 CUDA out of memory。解决思路从简单到复杂是:降低 batch 到 4 或 8,降低 imgsz 到 512 或 416,关闭一些附加功能,比如关闭缓存图片的操作,用混合精度训练。YOLO 的 AMP 默认开启,能减少大约一半显存占用。实在不够还可以用梯度累积,把一个小 batch 的梯度累积到一定步数再更新参数,模拟大 batch 的效果。
yolo detect train data=dataset/data.yaml model=yolov8n.pt imgsz=512 batch=8 amp=True5.3 mAP 很低或者直接为零,问题往往不在模型
mAP 为 0 的情况,大多数时候是数据格式问题。检查标注文件路径对不对,检查归一化坐标是不是落在 0 到 1 之间,检查类别编号是不是从 0 开始,检查训练集和验证集的图片有没有混用。还有一个很隐蔽的坑:如果图片是灰度图或者带透明通道的 PNG,YOLO 在加载时会自动处理,但一旦文件损坏或截断,验证阶段可能直接跳过整张图,导致指标异常偏低。
mAP 很低但 Loss 正常时,先看验证集图片里有没有大量标注框超出边界,再看类别是否严重不平衡。很多项目只有一两百张图,却设了十几个类别,这种情况下模型学不好很正常,优先增加数据量或合并相似类别。
5.4 其他容易踩的坑
Windows 环境下,数据集路径里尽量不要带中文和空格,否则部分图像库在读取时会报错。使用 LabelImg 时,如果图片本身是 PNG,标注时就要保持 PNG 后缀,不要手工改成 jpg。训练时开启了多进程数据加载,Windows 偶尔会出现 DataLoader worker 崩溃,这时可以把 workers 参数调成 0 或 2 再试。
还有一条经验:每次跑实验前固定随机种子,并把训练参数保存到日志里。否则当你试图复现一个效果不错的结果时,会发现完全想不起来上次是用哪个数据集划分和哪个学习率跑出来的。
6. 推理部署与模型改进扩展
6.1 导出 ONNX 或 TensorRT 的完整流程
训练收敛之后,可以把模型导出成不同格式用于部署。以导出 ONNX 为例:
yolo export model=best.pt format=onnx dynamic=True half=Truedynamic=True 表示允许动态输入尺寸,方便不同分辨率的图片推理;half=True 表示导出 FP16 精度模型,体积更小、速度更快。导出后可以用 onnxruntime 直接加载推理,也可以继续转成 TensorRT engine,在 NVIDIA 显卡上进一步加速。
部署时有两个容易踩的坑。第一个是 NMS。YOLO 原始导出的 ONNX 模型不包含 NMS 后处理,你需要在自己的推理脚本里加上置信度筛选和 NMS 逻辑,或者用支持 NMS 的端到端版本。第二个是输入的预处理方式。训练时图片归一化到 0 到 1,推理时也要保持相同的归一化方式,否则检测效果差别很大。
6.2 给 YOLO 做模块缝合和损失函数改进
很多做算法改进的人喜欢给 YOLO“缝合”一些新模块,比如在骨干网络后面插入注意力机制。以给 v8 加一个简单的通道注意力模块为例,思路是修改模型配置文件,或者直接在源码里把 C2f 模块的输出接一个 SE 模块。更轻量的做法是使用 v11 自带的 C2PSA 结构,它已经内置了空间注意力,能省去额外的自定义代码。
损失函数替换也是常见的改进方向。你可以把默认的 CIoU 替换为 WIoU、Shape-IoU 或 Inner-IoU 等变体。具体做法是在损失函数计算文件里找到 IoU 计算函数,换成对应的新实现,再重新训练。要注意的是,评价指标要保持不变,避免为了可视化好看而换一个计算方式不同的指标。
6.3 从检测到分割、跟踪和 GUI 自动化的扩展
YOLO 的能力边界早就不只是画目标框了。v8-seg 和 v11-seg 可以做实例分割,输出每个目标的像素级掩码。拿到掩码后,可以用 OpenCV 的轮廓提取函数计算目标的圆度、面积等几何信息,这在工业质检场景很常用。
多目标跟踪方面,YOLO 检测结果可以接入 ByteTrack、BoT-SORT 等跟踪算法,实现稳定地跟踪视频中多个目标。还有人会基于 YOLO 做屏幕元素识别,通过检测 GUI 上的按钮或图标位置,再配合自动化工具模拟鼠标键盘操作,实现一定程度的界面自动化。这个方向的关键在于检测坐标到屏幕坐标的映射,以及不同分辨率下的坐标缩放。
以我自己的项目经验来说,v8 和 v11 的差距确实存在,但远没有到“非换不可”的程度。新项目我会直接用 v11,因为它兼顾了更新的结构和更低的迁移成本;历史遗留项目如果在 v5 上跑得很稳,也没有必要为了追新而重写整套部署流程。数据质量永远是训练效果的上限来源,模型结构只是决定你能多接近这个上限。补数据、清标注、调超参,这些基础工作做扎实了,再换版本才有意义。