回顾整个虎年，堪称 YOLO 内卷元年，各路 YOLO 系列神仙打架，各显神通。一开始大部分用户做项目做实验还是使用的 YOLOv5，然后 YOLOv6、YOLOv7、PP-YOLOE+、DAMO-YOLO、RTMDet 就接踵而至，于是就在自己的数据集逐一尝试，好不容易把这些下饺子式的 YOLO 模型训练完测试完，忙完工作准备回家过年时，YOLOv8 又闪电发布，YOLOv6 又更新了 3.0 版本...用户还得跟进继续训练测试，其实很多时候就是重复工作。

此外换模型训练调参也会引入更多的不确定性，而且往往业务数据集大则几十万张图片，重训成本很高，但训完了新的精度不一定更高，速度指标在特定机器环境上也未必可观，参数量、计算量的变化尤其在边缘设备上也不能忽视。

所以在这样的内卷期，作为开发者的我们应该怎么选择一个适合自己的模型呢？

接下来，我们将就 YOLOv8 的升级点、YOLO 系列模型选型指南、YOLO 系列模型多硬件快速部署几个方面展开讨论，相关问题欢迎大家文末留言。

YOLO 历史回顾

几天前，目标检测经典模型 YOLO 系列再添一个新成员 YOLOv8，这是 Ultralytics 公司继 YOLOv5 之后的又一次重大更新。YOLOv8 一经发布就受到了业界的广泛关注，成为了这几天业界的流量担当。首先带大家快速了解下 YOLO 的发展历史。YOLO（You Only Look Once，你只看一次）是单阶段实时目标检测算法的开山之作，力求做到“又快又准”。2016 年，Joseph Redmon 发布了第一版 YOLO（代码库叫做 darknet），但他本人只更新到 YOLOv3，随后就将 darknet 库交给了 Alexey Bochkovskiy、Chien-Yao Wang 等人，即 YOLOv4 和 YOLOv7 作者团队负责。2020 年，Ultralytics 公司发布了 YOLOv5 代码库，同年百度发布了 PP-YOLO，2021 年旷视发布了 YOLOX，2022 年百度又发布了 PP-YOLOE 及 PP-YOLOE+，随后又有美团、OpenMMLab、阿里达摩院等相继推出了各自的 YOLO 模型版本，就在前几天 Ultralytics 公司又发布了 YOLOv8。同时这些系列模型也在不断更新迭代。由此可见 YOLO 系列模型算法始终保持着极高的迭代更新率，并且每一次更新都会掀起业界的关注热潮。

YOLOv8 升级解读

此次 Ultralytics 从 YOLOv5 到 YOLOv8 的升级，主要包括结构算法、命令行界面、Python API 等，精度上 YOLOv8 相比 YOLOv5 高出一大截，但速度略有下降。

仅看检测方向的话，简单总结下 YOLOv8 在结构算法上相比 YOLOv5 的升级：

• 骨干网络部分

选用梯度流更丰富的 C2f 结构替换了 YOLOv5 中的 C3 结构，为了轻量化也缩减了骨干网络中最大 stage 的 blocks 数，同时不同缩放因子 N/S/M/L/X 的模型不再是共用一套模型参数，M/L/X 大模型还缩减了最后一个 stage 的输出通道数，进一步减少参数量和计算量。

• Neck 部分

同样是 C2f 模块替换 C3 模块，为了轻量化删除了 Neck 结构中 top-down 阶段的两个上采样卷积。

• Head 部分

换成了目前主流的 Decoupled-Head 解耦头结构，将分类分支和定位分支分离，缓解了分类和回归任务的内在冲突。

• 标签分配和 Loss 部分

从 Anchor-Based 换成了 Anchor-Free，采用了 TAL(Task Alignment Learning)动态匹配，并引入了 DFL(Distribution Focal Loss)结合 CIoU Loss 做回归分支的损失函数，使得分类和回归任务之间具有较高的一致性。

• 训练策略

训练的数据增强部分最后 10 epoch 关闭 Mosaic 增强更有利于模型收敛的稳定，同时训练 epoch 数从 300 增大到 500 使得模型训练更充分。

从上面可以看出，YOLOv8 集合了之前提出的诸如 YOLOX、YOLOv6、YOLOv7 和 PPYOLOE 等算法的相关设计，尤其是 Head 标签分配和 Loss 部分以及 PP-YOLOE 非常相似。YOLOv8 集百家所长达到了实时检测界的一个新高度。

就在 YOLOv8 发布的当晚，飞桨 PaddleDetection 团队就支持了 YOLOv8 的推理部署，并正在研发可训练版本中。

• 完整教程文档及模型下载链接

https://github.com/PaddlePaddle/PaddleDetection/blob/release/2.5/docs/feature_models/PaddleYOLO_MODEL.md

• YOLO 系列多硬件部署示例下载链接

https://github.com/PaddlePaddle/FastDeploy/blob/develop/examples/vision/detection/paddledetection

YOLO 系列模型选型指南

为了方便统一 YOLO 系列模型的开发测试基准，以及模型选型，百度飞桨推出了 PaddleYOLO 开源模型库，支持 YOLO 系列模型一键快速切换，并提供对应 ONNX 模型文件，充分满足各类部署需求。

此外 YOLOv5、YOLOv6、YOLOv7 和 YOLOv8 在评估和部署过程中使用了不同的后处理配置，因而可能造成评估结果虚高，而这些模型在 PaddleYOLO 中实现了统一，保证实际部署效果和模型评估指标的一致性，并对这几类模型的代码进行了重构，统一了代码风格，提高了代码易读性。下面的讲解内容也将围绕 PaddleYOLO 相关测试数据进行分析。

总体来说，选择合适的模型，要明确自己项目的要求和标准，精度和速度一般是最重要的两个指标，但还有模型参数量、FLOPs 计算量等也需要考虑。接下来就具体讲一讲这几个关键点。

注：以上 DAMO-YOLO、YOLOv6-3.0 均使用官方数据，其余模型均为 Paddle 复现版本测试数据。

看精度

首先是精度，从上图 YOLO 系列 Benchmark 图可以看出，几乎每个模型的目标都是希望自己的模型折线在坐标轴上是最高的，这也是各个模型的主要竞争点。各家都会训练业界权威的 COCO 数据集去刷高精度，但是迁移到实际业务数据集上时，效果哪个高并不一定，各个模型的泛化能力并不和 COCO 数据集上的精度正相关。COCO 数据集精度差距在 1.0 以内的模型，其实业务数据集上差别不会很大，而且实际业务项目一般也不会只看 mAP 这一个指标，也可能需要关注 AP50、AP75、Recall 等指标。

要想在业务数据集达到较高精度，最重要是一点其实是加载一个较强的预训练(pre-trained)权重。COCO 预训练权重可以极快收敛，精度也会远高于用 ImageNet 预训练权重训的。一个较强的预训练在下游任务中的效果会优于绝大多数的调参和算法优化。

在 2022 年 9 月份，飞桨官方将 PP-YOLOE 模型升级为 PP-YOLOE+，最重要的一点就是提供了 Objects365 大规模数据集的预训练权重，Objects365 数据集含有的数据量可达百万级，在大数据量下的训练可以使模型获得更强大的特征提取能力、更好的泛化能力，在下游任务上的训练可以达到更好的效果。

基于 Objects365 的 PP-YOLOE+预训练模型，将学习率调整为原始的十分之一，在 COCO 数据集上训练的 epoch 数从 300 减少到了只需 80，大大缩短了训练时间的同时，获得了精度上的显著提升。实际业务场景中，在遇到比 COCO 更大规模数据集的情况下，传统的基于 COCO 预训练的模型就显得杯水车薪了，无论训练 200 epoch 还是 80 epoch，模型收敛都会非常慢，而使用 Objects365 预训练模型可以在较少的训练轮次 epoch 数如只 30 个 epoch，就实现快速收敛并且最终精度更高。

此外还有一些自监督或半监督策略可以继续提升检测精度，但是对于开发者来讲，时间资源、硬件资源消耗极大，以及目前的开发体验还不是很友好，需要持续优化。

看速度

速度不像精度很快就能复现证明的，鉴于各大 YOLO 模型发布的测速环境也不同，还是得统一测试环境进行实测。上图是飞桨团队在飞桨框架对齐各大模型精度的基础上，统一在 Tesla T4 上开启 TensorRT 以 FP16 进行的测试。

另外需要注意的是，各大 YOLO 模型发布的速度只是纯模型速度，是去除 NMS(非极大值抑制)的后处理和图片前处理的，实际应用端到端的耗时还是要加上 NMS 后处理和图片前处理的时间，以及将数据从 CPU 拷贝到 GPU/XPU 等加速卡上和将数据从加速卡拷贝到 CPU 的时间。通常 NMS 的参数对速度影响极大，尤其是 score threshold(置信度阈值) 、NMS 的 IoU 阈值、top-k 框数(参与 NMS 的最多框数)以及 max_dets(每张图保留的最多框数) 等参数。

比如最常用的是调 score threshold，一般为了提高 Recall(召回率) 都会设置成 0.001、0.01 之类的，但其实这种置信度范围的低分框对实际应用来说意义不大；如果设置成 0.1、0.2 则会提前过滤掉众多的低分框，这样 NMS 速度和整个端到端部署的速度就会显著上升，代价是掉一些 mAP，但对于结果可视化在视觉效果上其实影响很小。

总之实际应用中都需要自己实践，加上 NMS 等前后处理，不能只看论文中提供的纯模型速度。（具体可见下图"Part4. YOLO 系列模型多硬件快速部署”实测数据）

针对 YOLO 系列模型实际部署过程中遇到的前后处理优化问题、以及不同硬件模型的适配优化加速问题，飞桨团队同样提供了全场景高性能 AI 部署产品 FastDeploy，可以快速在 NVIDIA GPU、Intel CPU、ARM CPU、Jetson、昇腾、昆仑芯、算能、瑞芯微等硬件上实现优化部署，这部分将在下一章节具体介绍。

看参数量、计算量

这方面在学术研究场景中一般不会着重考虑，但是在产业应用场景中就非常重要，需要注意设备的硬件限制。例如堆叠一些模块结构来改造原模型，增加了 2~3 倍参数量提高了一点点 mAP，这是 AI 竞赛常用的“套路”，精度虽然有少许提升，但速度变慢了很多，参数量和 FLOPs 也都变大了很多，对于产业应用来说意义不大，又如一些特殊模块，例如 ConvNeXt，参数量极大但是 FLOPs 很小，虽然可以提升精度，但也会降低速度，参数量也可能受设备容量限制。

在对资源、显存及其敏感的场景，除了选择参数量较小的模型，也需要考虑和压缩工具联合使用。如下图所示，在 YOLO 系列模型上，使用 PaddleSlim 自动压缩工具（ACT）压缩后，可以在尽量保证精度的同时，降低模型大小和显存占用，并且该能力已经在飞桨全场景高性能 AI 部署工具 FastDeploy 中集成，实现一键压缩。

总之，在这 YOLO“内卷时期”要保持平常心，无论新出来什么模型，都需要大致了解下改进点和优劣势后再谨慎选择，针对自己的需求选适合自己的模型。

YOLO 系列模型多硬件快速部署

STEP3 中提到的速度，不仅有 AI 模型端到端的推理速度，也需要考虑到 AI 模型快速产业落地的速度。在真实产业部署落地场景，架构各异的 AI 硬件、不同场景的部署需求、不同操作系统和开发语言，通常使部署落地过程踩坑不断。基于产业落地部署需求，全场景高性能 AI 部署工具 FastDeploy 统一了飞桨的推理引擎和生态推理引擎（包括 Paddle Inference、Paddle Lite、TensorRT、OpenVINO、ONNX Runtime 等多推理后端），并融合高性能的 NLP、CV 加速库，实现了 AI 模型端到端的推理性能优化，并涵盖了包括 YOLOv5、YOLOv8、PP-YOLOE 等在内的 160 多个产业级特色模型。YOLO 系列在 FastDeploy 中的部署全景能力如下表展示：

• 各硬件部署示例下载链接

https://github.com/PaddlePaddle/FastDeploy/tree/develop/examples/vision/detection/paddledetection

注：*表示：FD 目前在该型号硬件上测试。通常同类型硬件上使用的是相同的软件栈，该部署能力可以延伸到同软件架栈的硬件。譬如 RK3588 与 RK3566、RK3568 相同的软件栈。同时，考虑到产业应用实际更关心整体性能，FastDeploy 对 YOLOv8 测试了模型端到端的性能数据。（当然每类硬件都有多款型号，且在具体部署落地中，通常是多 batch、动态 shape 的使用，以下数据仅用于展示端到端推理与 AI 模型推理的区别。）

注：「FD Runtime」包括模型推理、NMS、HostToDevice（H2D）、DeviceToHost（D2H）5 个部分。H2D 是将数据从 cpu 拷贝到 GPU/XPU 等所需要的时间，发生在将预处理数据喂给推理引擎时，D2H 是将数据从 GPU/XPU 等拷贝到 CPU 的时间。「端到端推理速度」在 FD Runtime 的时间上增加的算法前后预处理。

以上就是本次技术解读，最后想给大家留个共同的思考题：在 YOLO 如此“内卷”的时代，目标检测是否有新的、更高效的模型结构以及开发范式呢？ 飞桨在探索，也欢迎大家进行技术交流~