目标检测这个圈子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 Bochkovskiyv5 开始进入 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旷视出了 YOLOXUltralytics 自己迭代到 v8、v11然后社区又冒出 v9、v10、v12。命名虽然乱但技术路线其实在收敛Anchor-Free、解耦头、标签分配策略优化、更强的数据增强、更友好的部署链路。1.2 一张表看清各版本的关键差异光靠文字描述容易记混我整理了一张对照表把每个版本最核心的改动和适用场景列出来。这张表是我自己在选版本时最常回看的建议收藏。版本主导方核心改动骨干网络典型适用场景YOLOv1Redmon单阶段回归7x7 网格自研教学理解原理YOLOv2RedmonAnchor、BN、多尺度训练Darknet-19老项目维护YOLOv3Redmon多尺度预测、残差骨干Darknet-53遥感、工业老项目YOLOv4AlexeyMosaic、CIoU、CSPCSPDarknet-53精度优先的检测YOLOv5UltralyticsPyTorch 工程化、易用工具链CSP Focus快速落地、教学YOLOv6美团重参数化、Anchor-FreeEfficientRep工业部署YOLOv7Alexey 团队E-ELAN、辅助头训练ELAN精度与速度平衡YOLOv8Ultralytics解耦头、C2f、统一框架C2f检测/分割/姿态全场景YOLOv9社区PGI、GELANGELAN精度敏感任务YOLOv10清华无 NMS、一致性双分配多种低延迟推理YOLOv11UltralyticsC3k2、SPPF 优化C3k2通用首选YOLOv12社区注意力机制融合注意力骨干探索性项目需要说明的是这张表里的主导方和核心改动是基于公开资料和常见实践的归纳不同版本的具体实现细节可能因为代码迭代而有出入实际使用时还是要以官方仓库为准。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.0models.experimental里的接口、utils里的函数签名都改过。如果你照着某篇老教程写代码很可能因为版本对不上而报错。我的做法是锁定版本。在requirements.txt里写死yolov57.0这样的版本号不要用pip install yolov5直接装最新版。另外v5 的权重文件.pt和代码版本是绑定的用 v7.0 的代码加载 v5.0 的权重可能会出问题这点在迁移老项目时要特别注意。4. v6 到 v8Anchor-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(formatonnx)一行代码导出 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 的核心创新是PGIProgrammable Gradient Information可编程梯度信息和GELANGeneralized 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 和 v12Ultralytics 的持续迭代与注意力融合v11 是 Ultralytics 在 v8 基础上的迭代主要改动是C3k2 模块和SPPF 优化。C3k2 可以理解为 C2f 的升级版在保持梯度流的同时进一步减少计算量。v11 的定位很明确作为 v8 的平滑升级精度略高、速度略快、API 基本兼容。如果你现在用 v8迁移到 v11 的成本很低。v12 则是社区对注意力机制的探索把注意力模块融入 YOLO 骨干。注意力机制在检测任务上的效果一直有争议它能提升精度但也会增加计算量和部署难度。v12 目前更适合探索性项目生产环境用之前要仔细评估导出和推理的兼容性。5.4 版本选型的实战决策树说了这么多版本实际选的时候怎么定我总结了一个简单的决策逻辑先看部署环境如果目标硬件有成熟的 TensorRT 或 ONNX Runtime 支持优先选 v8 或 v11因为它们的导出最规范。如果是特定芯片如 K210、RK3588先查该芯片的官方示例用的是哪个版本。再看任务类型纯检测任务v8/v11 足够需要分割或姿态v8 的统一框架最省事需要无 NMS 低延迟考虑 v10。最后看精度需求如果 v8 的精度不够再考虑 v9 或 v12但要接受更高的调参成本。永远优先选社区活跃的版本遇到问题能搜到答案比多那零点几个 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( formatonnx, imgsz640, # 输入尺寸必须和训练一致 opset12, # ONNX 算子集版本 simplifyTrue, # 简化计算图 dynamicFalse, # 是否动态 batch/尺寸 halfFalse, # 是否 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_inputyolov8n.onnx, model_outputyolov8n_int8.onnx, calibration_data_readerDataReader(calib_images), quant_formatQuantFormat.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 做出很好效果的团队也见过用最新版本却因为数据标注混乱而失败的案例。选一个够用的版本把精力放在数据和业务上这才是正道。
