企业官网建设流程全解析

目标检测这个圈子，YOLO 系列几乎是绕不开的一座山。不管你是刚入门想跑通第一个检测 Demo，还是已经在产线上部署过好几个视觉项目，大概率都经历过这样的场景：打开搜索引擎输入"YOLO"，结果跳出来 v3、v5、v8、v11、v12、YOLOE、YOLO-World 一大堆版本，每个都说自己又快又准，文档风格还各不相同，光是把这些版本的关系理清楚就得花掉大半天。我自己从最早拿 YOLOv3 跑遥感数据集，到后来在边缘设备上折腾 ONNX 量化部署，中间踩过的版本坑、配置坑、导出坑数不胜数。这篇就把 YOLO 历代版本从头到尾捋一遍，重点讲清楚每个版本到底改了什么、为什么这么改、什么场景该选哪个版本，以及从训练到 ONNX 导出再到端侧部署这条链路上最容易翻车的地方。内容偏实战，适合已经有一点深度学习基础、准备把 YOLO 真正用起来的同学，也适合想系统回顾一下 YOLO 演进脉络的老手。

1. 先把 YOLO 的版本谱系理清楚，别被命名搞晕

YOLO 的版本命名是整个领域里最混乱的事情之一，没有之一。你看到的 v1 到 v3 是同一个作者 Joseph Redmon 主导的，v4 换成了 Alexey Bochkovskiy，v5 开始进入 Ultralytics 的天下，然后 v6、v7、v8、v9、v10、v11、v12 各有各的来路，中间还夹杂着 YOLOX、YOLOR、YOLOv5-Lite、PP-YOLO 这些"分支流派"。如果不先把这棵家谱树画出来，后面看论文和代码会一直处于一种"这俩到底啥关系"的困惑里。

1.1 三个时代：学术原教旨、工程化转折、平台化统一

我把 YOLO 的演进分成三个阶段来看，这样理解起来最省事。

第一个阶段是学术原教旨时代，对应 YOLOv1 到 YOLOv3。这个阶段的核心特征是"一个人或一个小团队在推着算法往前走"，论文写得很扎实，创新点清晰，但工程配套几乎没有。YOLOv1 在 2016 年提出的时候，最大的贡献是把目标检测从"两阶段"（先出候选框再分类）直接拉成了"单阶段回归"，一张图过一次网络就同时输出框和类别，速度直接起飞。YOLOv2 引入了 Anchor Box 和 Batch Normalization，把精度拉了上来。YOLOv3 则是这个时代的巅峰，用了 Darknet-53 骨干、多尺度预测、独立的逻辑回归分类，直到今天还有大量老项目跑在 v3 上。

第二个阶段是工程化转折时代，从 YOLOv4 到 YOLOv5。v4 是 Alexey 在 Darknet 框架下做的集大成者，把当时能用的训练技巧（Mosaic 增强、CIoU 损失、CSP 结构等）几乎全塞了进去，论文更像一篇"目标检测技巧大全"。而 v5 是真正的分水岭——Ultralytics 用 PyTorch 重写，配套了极其顺手的训练脚本、数据配置、模型导出工具链，把 YOLO 从"论文复现"变成了"开箱即用"。很多人对 YOLO 的好感就是从 v5 开始的，因为train.py一跑就能出结果，这在 v3 时代是不可想象的。

第三个阶段是平台化统一时代，从 YOLOv6 往后一直到现在的 v11、v12。这个阶段的特征是各家大厂和团队都在做自己的 YOLO 变体，美团出了 YOLOv6，旷视出了 YOLOX，Ultralytics 自己迭代到 v8、v11，然后社区又冒出 v9、v10、v12。命名虽然乱，但技术路线其实在收敛：Anchor-Free、解耦头、标签分配策略优化、更强的数据增强、更友好的部署链路。

1.2 一张表看清各版本的关键差异

光靠文字描述容易记混，我整理了一张对照表，把每个版本最核心的改动和适用场景列出来。这张表是我自己在选版本时最常回看的，建议收藏。

需要说明的是，这张表里的"主导方"和"核心改动"是基于公开资料和常见实践的归纳，不同版本的具体实现细节可能因为代码迭代而有出入，实际使用时还是要以官方仓库为准。

1.3 为什么版本命名这么乱，以及怎么不被带偏

命名混乱的根源在于"YOLO"这个名字本身没有被商标或标准组织保护，谁都可以拿来用。Ultralytics 在 v5 之后其实是想把版本号统一起来的，但社区里其他团队也在发自己的版本，于是就出现了 v6 有两个不同来源、v7 和 v8 时间线交错的情况。

我的建议是：不要纠结版本号，要看三个东西——骨干结构、标签分配策略、部署友好度。骨干决定了特征提取能力，标签分配决定了训练收敛质量，部署友好度决定了你能不能顺利导出 ONNX 并在目标硬件上跑起来。这三个维度想清楚了，版本号只是个代号而已。比如你要在 AGX Orin 上部署，那重点看的是这个版本导出 ONNX 后算子是否被 TensorRT 支持，而不是它叫 v8 还是 v11。

2. 从 v1 到 v3：单阶段检测是怎么被"发明"出来的

理解 YOLO 的早期版本，重点不是记住每个版本的 mAP 数字，而是理解它解决了什么问题、留下了什么坑。这段历史对今天做模型选型依然有参考价值，因为很多"为什么现在要这么设计"的答案，都藏在早期版本的缺陷里。

2.1 YOLOv1 的暴力美学与它的致命短板

YOLOv1 的核心思想非常直接：把输入图像切成 SxS 的网格（论文里是 7x7），每个网格负责预测中心落在它里面的目标。每个网格输出 B 个边界框（含坐标和置信度）加上 C 个类别概率，整张图一次前向就出结果。这个设计在 2016 年是颠覆性的，因为当时的主流是 R-CNN 那一套"先提候选再分类"的两阶段流程，速度慢得没法做实时。

但 v1 的短板也很明显。首先是定位精度差，尤其是小目标和密集目标，因为一个网格只能预测有限个框，两个目标中心落在同一个网格就废了。其次是对非常规比例目标不友好，因为框的尺寸是直接回归的，没有 Anchor 做先验。第三是损失函数设计粗糙，坐标损失、置信度损失、分类损失直接加权求和，权重还得手工调。

我当年拿 v1 跑过一个鸟类目标检测的数据集，结果就是大鸟还行，一群小鸟挤在一起基本全漏。这个体验让我第一次意识到：单阶段检测的精度问题，本质上是"如何让网络学会把哪些框分配给哪个目标"的问题，而这个问题直到后来的标签分配策略才真正被系统解决。

2.2 YOLOv2 引入 Anchor 和 BN，精度开始追上来

v2 的改进可以概括为"把当时能用的技巧都加上"。最重要的两个是Anchor Box和Batch Normalization。Anchor 的思路是预先定义一组不同尺寸和比例的参考框，网络不直接回归绝对坐标，而是回归相对于 Anchor 的偏移量。这一下子解决了 v1 对目标尺寸敏感的问题，因为不同尺度的目标可以由不同 Anchor 来负责。

Batch Normalization 的加入则让训练稳定了很多，可以放心用更大的学习率，收敛也更快。v2 还做了多尺度训练，就是每隔几个 batch 换一次输入分辨率，让模型对不同尺度的输入更鲁棒。骨干网络换成了 Darknet-19，比 v1 的定制网络更深也更快。

实测下来，v2 相比 v1 在 COCO 上的 mAP 提升非常明显，而且速度没有明显下降。但 v2 依然有个问题：小目标检测还是弱。原因是它只用了一个尺度的特征图做预测，高层的语义信息强但空间分辨率低，小目标在高层特征图上几乎就剩几个像素了。

2.3 YOLOv3 的多尺度预测，为什么至今还有人在用

v3 是早期 YOLO 的集大成者，也是我认为"最值得新手拿来理解检测原理"的版本。它的三个关键设计是：Darknet-53 骨干、多尺度预测、独立逻辑回归分类。

多尺度预测是 v3 最核心的贡献。它在三个不同尺度的特征图上分别做预测，浅层特征图分辨率高、感受野小，负责小目标；深层特征图分辨率低、感受野大，负责大目标。这个设计直接解决了 v2 小目标弱的问题。具体来说，v3 在 13x13、26x26、52x52 三个尺度上预测，每个尺度分配 3 个 Anchor，总共 9 个 Anchor，通过 K-means 聚类得到。

独立逻辑回归分类则是把 Softmax 换成了多个独立的 Sigmoid，这样每个类别独立判断，支持多标签场景（比如一个目标同时属于"人"和"骑手"）。这个改动看起来小，但对实际场景很重要，因为现实里的目标经常有重叠类别。

v3 的损失函数也比前两代清晰很多，坐标用 MSE、置信度和分类用交叉熵，各部分权重相对好调。直到今天，我还能在一些工业质检和遥感项目里看到 v3 的身影，原因就是它结构简单、权重好找、部署链路成熟。如果你要做一个对精度要求不是极致、但要求稳定可控的检测任务，v3 依然是个靠谱的选择。

3. v4 到 v5：工程化浪潮把 YOLO 推向了大众

从 v4 开始，YOLO 的演进逻辑变了。不再是"发明一个新结构"，而是"把已有的技巧系统化地组合起来，并解决工程落地问题"。这个转变对使用者的影响是巨大的——你不再需要自己复现论文，而是可以直接用现成的工具链。

3.1 YOLOv4 的"技巧大礼包"到底值不值得学

v4 的论文我读了很多遍，最大的感受是：它更像一篇综述加实验报告，而不是提出某个单一创新。它把当时目标检测领域能用的技巧几乎全试了一遍，然后挑出有效的组合。这些技巧包括：

• Mosaic 数据增强：把四张图拼成一张训练，变相增大 batch size 和场景多样性
• CIoU 损失：在 IoU 基础上加入中心点距离和长宽比惩罚，让框回归更准
• CSP 结构：跨阶段部分连接，减少计算量同时保持精度
• SAT 自对抗训练：在输入上加扰动提升鲁棒性
• Mish 激活函数：比 ReLU 更平滑，梯度更友好

这些技巧里，Mosaic 和 CIoU 是真正被后续版本广泛继承的，几乎成了标配。Mosaic 的好处是让模型在训练时见到更多"目标被截断、目标大小不一、背景复杂"的情况，泛化能力明显提升。CIoU 则解决了单纯 IoU 在框不重叠时梯度消失的问题。

但 v4 也有它的历史局限。它是在 Darknet 框架下实现的，配置全靠.cfg文件，改个参数要翻半天。而且 Darknet 的生态相对封闭，和 PyTorch 生态的互操作性差。所以 v4 虽然精度不错，但在工程落地上的体验远不如后来的 v5。

3.2 YOLOv5 凭什么成为最流行的版本

v5 的成功，技术只占一半，另一半是工程体验。Ultralytics 把整个流程做成了"配置即用"：数据用 YAML 描述，模型用 YAML 描述，训练、验证、推理、导出各一个脚本，命令行参数清晰。你不需要懂太多底层实现，就能跑通一个完整的检测流程。

v5 的几个关键设计值得单独说：

Focus 层：在输入端做切片操作，把 4x4x3 的输入变成 2x2x12，减少计算量。虽然后来 v8 把它换成了普通卷积（因为 Focus 在某些硬件上不友好），但在 v5 时代这是个亮点。

自适应 Anchor：训练开始时自动用 K-means 在数据集上聚类 Anchor，不用手工设。这个对新手太友好了，因为 Anchor 设不好是新手最常见的翻车点之一。

丰富的模型尺寸：n/s/m/l/x 五个尺寸，从移动端到服务器端全覆盖。你要在树莓派上跑就用 n，要在服务器上追精度就用 x，选择非常直观。

导出工具链：export.py支持导出 ONNX、TensorRT、CoreML、TFLite 等格式，一条命令搞定。这个对部署太重要了，我在 AGX Orin 上部署时，v5 的 ONNX 导出几乎没遇到过算子不支持的问题。

我个人的经验是，如果你现在要开始一个新项目，又不想在框架选型上花太多时间，v5 依然是个稳妥的起点。它的社区资源极其丰富，遇到问题基本都能搜到答案。

3.3 v5 的坑：版本迭代带来的兼容性问题

v5 有个容易被忽略的坑：不同小版本之间的 API 不兼容。Ultralytics 在 v5 时期迭代非常快，从 v5.0 到 v6.0 再到 v7.0，models.experimental里的接口、utils里的函数签名都改过。如果你照着某篇老教程写代码，很可能因为版本对不上而报错。

我的做法是：锁定版本。在requirements.txt里写死yolov5==7.0这样的版本号，不要用pip install yolov5直接装最新版。另外，v5 的权重文件（.pt）和代码版本是绑定的，用 v7.0 的代码加载 v5.0 的权重可能会出问题，这点在迁移老项目时要特别注意。

4. v6 到 v8：Anchor-Free 与解耦头成为主流

从 v6 开始，YOLO 的技术路线发生了两个根本性变化：从 Anchor-Based 转向 Anchor-Free，以及从耦合头转向解耦头。这两个变化不是某个版本的专利，而是整个系列在这个阶段的共同演进方向。

4.1 Anchor-Free 到底解决了什么问题

Anchor-Based 的方法需要预先定义一堆 Anchor，然后让网络去回归相对于 Anchor 的偏移。这套方法有效，但有几个麻烦：Anchor 的尺寸和比例需要针对数据集调，调不好精度就上不去；Anchor 数量多导致正负样本极度不平衡；后处理时还要做 NMS，密集场景下 NMS 容易误删。

Anchor-Free 的思路是：不预设 Anchor，直接预测目标中心点和尺寸，或者预测到边界的距离。这样就不需要调 Anchor 了，正负样本的定义也更直接。YOLOX 是早期把 Anchor-Free 做成功的代表，它用了 SimOTA 标签分配策略，根据预测质量和中心先验动态分配正样本，效果很好。

v6 和 v8 都采用了 Anchor-Free，但具体实现不同。v6 用的是 EfficientRep 骨干加解耦头，v8 用的是 C2f 骨干加解耦头。Anchor-Free 带来的直接好处是：超参数更少、训练更稳定、对小目标和密集目标更友好。我在学生专注度检测这类需要检测人脸和姿态的任务上，明显感觉 v8 比 v5 更容易调。

4.2 解耦头为什么能提升精度

在早期的 YOLO 里，分类和回归是共享同一个卷积头的。也就是说，同一组特征既用来判断"这是什么"，又用来判断"框在哪"。这两个任务的关注点其实不一样：分类更关注语义信息，回归更关注位置信息。共享头会让两个任务互相干扰。

解耦头就是把分类和回归分成两个独立的分支，各自用几层卷积处理，最后再合并输出。这个改动在 v6、v7、v8 里都出现了，实测对精度有稳定提升，代价是参数量和计算量略微增加。

v8 的解耦头设计比较典型：分类分支和回归分支各自经过两层卷积，然后分别输出类别分数和框坐标。配合 C2f 骨干（CSP 结构的改进版，梯度流更丰富），v8 在精度和速度上达到了很好的平衡。

4.3 v8 的统一框架：检测、分割、姿态一把梭

v8 最大的工程贡献是统一了多个视觉任务的接口。在 v8 里，检测、实例分割、姿态估计、分类都用同一套训练和推理框架，只是模型配置和输出头不同。这意味着你学会了 v8 的检测流程，迁移到分割任务上几乎零成本。

这对实际项目太重要了。比如你做一个智慧交通检测分析系统，可能既需要检测车辆（检测任务），又需要分割出车道线（分割任务），还要估计行人姿态（姿态任务）。在 v5 时代，你得分别找三个不同的仓库；在 v8 时代，一个YOLO('yolov8n-seg.pt')就搞定了。

v8 的导出链路也很成熟，model.export(format='onnx')一行代码导出 ONNX，支持动态 batch 和动态尺寸。我在做 ONNX 转 KMODEL（嘉楠 K210 等芯片）或者 RKNN 时，v8 导出的 ONNX 通常比 v5 更干净，算子更规范。

5. v9 到 v12：精度竞赛与新范式的探索

v8 之后，YOLO 的演进进入了一个"百花齐放"的阶段。Ultralytics 自己出了 v11，社区出了 v9、v10、v12，每个版本都在某个维度上做了探索。这个阶段选版本，不能只看 mAP，还要看你的部署环境和任务特点。

5.1 v9 的 PGI 和 GELAN：可编程梯度信息是什么

v9 的核心创新是PGI（Programmable Gradient Information，可编程梯度信息）和GELAN（Generalized Efficient Layer Aggregation Network）。PGI 的思路是解决深层网络在反向传播时梯度信息丢失的问题，通过辅助监督分支把更完整的梯度信息传回去。GELAN 则是一种更灵活的特征聚合结构，可以根据任务需求组合不同的计算块。

从实测角度看，v9 在精度上确实有提升，尤其是在小目标密集的场景。但它的工程生态不如 v8 和 v11 成熟，导出和部署的资料相对少。如果你的任务对精度极度敏感，又愿意花时间调，v9 值得一试；如果追求快速落地，还是优先考虑 v8 或 v11。

5.2 v10 的无 NMS 设计：端到端检测的尝试

v10 最吸引眼球的是无 NMS。传统检测器输出一堆框后，要用 NMS 去掉重叠的冗余框，这个后处理在密集场景下耗时且容易误删。v10 通过一致性双分配策略，让网络直接输出最终结果，不需要 NMS。

这个设计在理论上很美，实际用起来要看场景。如果你的场景目标稀疏，NMS 本来就不慢，无 NMS 的优势不明显；如果是密集场景（比如人群检测），无 NMS 能省下可观的延迟。但 v10 的部署链路相对复杂，因为无 NMS 意味着输出格式和传统检测器不同，后处理代码要重写。

5.3 v11 和 v12：Ultralytics 的持续迭代与注意力融合

v11 是 Ultralytics 在 v8 基础上的迭代，主要改动是C3k2 模块和SPPF 优化。C3k2 可以理解为 C2f 的升级版，在保持梯度流的同时进一步减少计算量。v11 的定位很明确：作为 v8 的平滑升级，精度略高、速度略快、API 基本兼容。如果你现在用 v8，迁移到 v11 的成本很低。

v12 则是社区对注意力机制的探索，把注意力模块融入 YOLO 骨干。注意力机制在检测任务上的效果一直有争议：它能提升精度，但也会增加计算量和部署难度。v12 目前更适合探索性项目，生产环境用之前要仔细评估导出和推理的兼容性。

5.4 版本选型的实战决策树

说了这么多版本，实际选的时候怎么定？我总结了一个简单的决策逻辑：

1. 先看部署环境：如果目标硬件有成熟的 TensorRT 或 ONNX Runtime 支持，优先选 v8 或 v11，因为它们的导出最规范。如果是特定芯片（如 K210、RK3588），先查该芯片的官方示例用的是哪个版本。
2. 再看任务类型：纯检测任务，v8/v11 足够；需要分割或姿态，v8 的统一框架最省事；需要无 NMS 低延迟，考虑 v10。
3. 最后看精度需求：如果 v8 的精度不够，再考虑 v9 或 v12，但要接受更高的调参成本。
4. 永远优先选社区活跃的版本：遇到问题能搜到答案，比多那零点几个 mAP 重要得多。

6. 训练到部署的完整链路：ONNX 导出与量化实战

版本选好只是第一步，真正决定项目成败的是从训练到部署这条链路。这一节我把自己踩过的坑和验证过的流程整理出来，重点讲 ONNX 导出和 INT8 量化。

6.1 训练阶段的几个关键配置

不管你用哪个版本，训练阶段有几个配置是共通的，设不好后面全白搭。

数据集的 YAML 配置：路径、类别数、类别名这三样必须对。我见过太多人因为nc（类别数）写错导致训练不报错但结果全乱的情况。建议训练前先用一小部分数据跑 1 个 epoch，确认 loss 正常下降再上全量。

输入尺寸：训练尺寸和推理尺寸最好一致。如果你训练用 640，推理用 320，精度会掉得厉害。如果部署时算力有限，训练时就用小尺寸，或者用多尺度训练让模型适应。

Batch size 和学习率：这两个是联动的。batch size 翻倍，学习率通常也要相应调整。如果显存不够只能用小 batch，可以用梯度累积模拟大 batch。

预训练权重：除非你的数据集和 COCO 差异极大，否则一定要用预训练权重。从零训练不仅慢，而且在小数据集上很容易过拟合。

6.2 ONNX 导出的参数怎么设

ONNX 导出是部署链路上最关键的一步，参数设错后面全崩。以 Ultralytics 的导出为例，核心参数有这几个：

from ultralytics import YOLO model = YOLO('yolov8n.pt') model.export( format='onnx', imgsz=640, # 输入尺寸，必须和训练一致 opset=12, # ONNX 算子集版本 simplify=True, # 简化计算图 dynamic=False, # 是否动态 batch/尺寸 half=False, # 是否 FP16 )

opset 版本：这是最容易踩坑的地方。opset 太高，目标推理引擎可能不支持；太低，某些算子表达不了。我的经验是 opset 11 到 13 之间最稳，TensorRT 和 ONNX Runtime 都支持得好。如果你要转 RKNN 或 KMODEL，先查芯片文档推荐的 opset。

dynamic 参数：如果设成 True，导出的模型支持动态 batch 和动态输入尺寸，灵活但可能影响推理引擎的优化。如果部署时 batch 和尺寸固定，设成 False 能让推理引擎做更激进的优化，速度更快。

simplify：开启后会调用 onnx-simplifier 简化计算图，去掉冗余算子。这个强烈建议开启，能减少很多部署时的算子兼容问题。

导出后一定要用onnxruntime跑一遍，对比 PyTorch 和 ONNX 的输出差异。如果差异很大，说明导出有问题，常见原因是 opset 不匹配或某些自定义算子没被正确转换。

6.3 INT8 量化的收益与精度损失控制

INT8 量化是把 FP32 的权重和激活值映射到 8 位整数，能大幅减少模型体积和推理延迟，在边缘设备上几乎是必选项。但量化会带来精度损失，控制不好可能掉好几个点。

量化的核心是校准。你需要准备一批有代表性的校准数据（通常几百张图），让量化工具统计激活值的分布，确定量化参数。校准数据的选择很关键：必须覆盖实际部署时可能遇到的各种场景，否则量化后的模型在边缘 case 上会崩。

以 ONNX Runtime 的量化为例，流程大致是：

from onnxruntime.quantization import quantize_static, CalibrationDataReader # 准备校准数据读取器 class DataReader(CalibrationDataReader): def __init__(self, calibration_images): self.images = calibration_images self.index = 0 def get_next(self): if self.index >= len(self.images): return None img = preprocess(self.images[self.index]) self.index += 1 return {'images': img} quantize_static( model_input='yolov8n.onnx', model_output='yolov8n_int8.onnx', calibration_data_reader=DataReader(calib_images), quant_format=QuantFormat.QDQ, )

量化后必须重新评估精度。如果掉点严重，可以尝试：增加校准数据量、改用 QDQ 格式（对某些硬件更友好）、对敏感层（如检测头）保持 FP16。

6.4 端侧部署的常见坑

在 AGX Orin、RK3588 这类边缘设备上部署 YOLO，有几个坑几乎人人都会踩。

算子不支持：某些 YOLO 版本用的算子（如特定的激活函数、特殊的 reshape）在目标推理引擎里没有实现。解决办法是导出时用simplify，或者手动替换不支持的算子。我在 AGX Orin 上遇到过 SiLU 激活在旧版 TensorRT 上不支持的情况，换成 ReLU 后解决。

内存对齐：边缘设备的 NPU 通常对输入输出的内存布局有要求，比如必须是 NHWC 而不是 NCHW。导出 ONNX 时要注意，必要时在推理前做 transpose。

后处理耗时：很多人只关注模型推理时间，忽略了后处理（NMS、坐标还原）的耗时。在密集场景下，NMS 可能比推理还慢。这时候可以考虑 v10 的无 NMS 设计，或者用 GPU 加速的 NMS。

精度对齐：PyTorch 上跑得好好的模型，部署到端侧后精度掉了，最常见的原因是预处理不一致。比如 PyTorch 用的是 RGB、归一化到 0-1，端侧用的是 BGR、0-255，结果肯定不对。部署前一定要把预处理和后处理的每个步骤对齐。

7. 几个真实场景下的版本选择与踩坑记录

理论讲完了，说几个我自己做过的场景，看看不同需求下版本是怎么选的，以及踩了什么坑。

7.1 遥感目标检测：为什么最后选了 v8 而不是 v3

遥感图像的特点是目标小、密集、方向任意。我一开始用的是 v3，因为老项目都是 v3，权重好找。但 v3 在小目标上确实吃力，尤其是飞机、车辆这类小目标，漏检率很高。

后来换到 v8，主要看中两点：一是 Anchor-Free 对小目标更友好，二是 v8 支持更大的输入尺寸（可以到 1280），小目标在特征图上的像素更多。实测下来，同样数据集上 v8 比 v3 的 mAP 高了将近 10 个点。

但 v8 也有坑。遥感图像的目标方向任意，而 YOLO 默认的框是水平矩形，对旋转目标的定位不准。后来我加了旋转框的支持（用 v8 的 OBB 模式），效果才真正上来。所以选版本时，除了看通用能力，还要看它是否支持你的特殊需求。

7.2 学生专注度检测：v8 的姿态估计怎么用

学生专注度检测需要判断学生的头部朝向、眼睛开合等，本质上是姿态估计加分类。v8 的姿态模型（yolov8n-pose.pt）直接输出人体关键点，我再根据关键点计算头部朝向和眼睛状态。

这个场景的坑在于遮挡。教室里学生互相遮挡严重，姿态模型经常漏检关键点。我的解决办法是：先用检测模型框出所有人，再对每个人单独跑姿态估计，而不是直接在全图上跑姿态。这样虽然慢一点，但准确率高很多。

另外，专注度判断不能只看单帧，要结合时序。我用了一个简单的滑动窗口，统计最近 N 帧的关键点变化，判断学生是在看黑板还是在低头。这部分逻辑用 Python 写就行，不需要额外的模型。

7.3 智慧交通检测：多模态分析的工程整合

智慧交通检测分析系统是我做过最复杂的项目，涉及车辆检测、车牌识别、事故判断多个模块。检测部分用的是 v8，因为它的导出链路最成熟，能顺利转到 TensorRT 在边缘盒子上跑。

这个项目的核心挑战不是检测本身，而是多模块的工程整合。检测模型输出车辆框后，要裁剪出来送给车牌识别模型，识别结果再和事故判断逻辑结合。整个链路的延迟要控制在实时范围内，所以每个模块都要优化。

我的经验是：检测模型选最成熟的版本，把精力留给业务逻辑。检测本身已经是个很成熟的问题了，没必要在版本上追求最新。v8 在这个项目里表现很稳，导出 ONNX 后转 TensorRT，在 AGX Orin 上单帧推理不到 20ms，完全够用。

7.4 矿泉水瓶检测这种小任务，杀鸡别用牛刀

最后说个反例。有次帮朋友做一个矿泉水瓶检测的小任务，数据集就几百张图，场景也简单。我一开始想用 v8x 追精度，结果训练慢、部署重，完全没必要。后来换成 v8n，精度只掉了不到 1 个点，但速度快了好几倍，部署也轻松。

这个经历让我明白：版本和模型尺寸的选择要匹配任务复杂度。小任务用小模型，大任务才上大模型。很多人一上来就选最大的模型，结果训练慢、部署难，收益还不明显。先用小模型跑通流程，确认精度不够再往上加，这才是正确的顺序。

8. 给不同阶段使用者的版本建议

写了这么多，最后按使用者的阶段给点具体建议，方便你对号入座。

如果你是刚入门，想理解目标检测的原理，建议从 YOLOv3 或 YOLOv5 入手。v3 结构清晰，适合读代码理解检测流程；v5 工程友好，适合快速跑通第一个项目。不要一上来就碰 v9、v12 这些新版本，它们的复杂度会让你迷失在细节里。

如果你要做实际项目，优先选 v8 或 v11。这两个版本的生态最成熟，文档全、社区活跃、导出链路稳定。遇到问题基本都能搜到答案，这对项目进度太重要了。v8 和 v11 的 API 基本兼容，从 v8 迁移到 v11 成本很低。

如果你在边缘设备上部署，先查目标硬件的官方示例用的是哪个版本，跟着官方走最省事。如果官方没有明确推荐，v8 的 ONNX 导出通常兼容性最好。导出时注意 opset 版本、dynamic 参数和 simplify 选项，量化时做好校准数据的准备。

如果你追求极致精度，可以试试 v9 或 v12，但要接受更高的调参成本和更少的社区支持。而且要先确认你的部署环境能支持这些版本的算子，否则精度再高也落不了地。

如果你要做分割或姿态任务，直接用 v8 的统一框架，不要分别找不同的仓库。v8 的-seg和-pose模型开箱即用，省下的时间可以用来优化业务逻辑。

版本只是工具，真正决定项目成败的是数据质量、问题定义和工程细节。我见过用 v5 做出很好效果的团队，也见过用最新版本却因为数据标注混乱而失败的案例。选一个够用的版本，把精力放在数据和业务上，这才是正道。