1. YOLO 与 OpenCV 生态概览
各位同学，欢迎来到这门实战课。我是你们的老朋友，一个在计算机视觉领域摸爬滚打多年的工程师。今天咱们不聊虚的，直接切入正题——YOLO 和 OpenCV 这对黄金搭档。
你想想看，做目标检测，YOLO 几乎是绕不开的选择。而 OpenCV 的 DNN 模块，又是部署 YOLO 最轻便、最省心的方式之一。这门课的第一章，咱们先把地基打牢。我会带你梳理 YOLO 从 v3 到 v8 的进化史，聊聊 OpenCV DNN 模块到底能干什么，最后再讲清楚那几个让你头疼的性能指标——FPS、延迟、吞吐量。
嗯，别急，咱们一个一个来。
1.1 YOLO 发展史：从 v3 到 v8
YOLO 的故事，说白了就是一部「实时检测」的进化史。我最早接触 YOLO 是在 v2 时代，那时候它还是个「快但不太准」的小伙子。真正让它封神的，是 v3。
核心观点：YOLO 每一代都在做同一件事——在「速度」和「精度」之间找到更优的平衡点。
YOLOv3：里程碑式的分水岭
v3 引入了 Darknet-53 骨干网络和 FPN（特征金字塔） 结构。它解决了小目标检测的痛点。我记得当时在项目中用 v3 检测行人，效果比 v2 好了不止一个档次。它的多尺度预测机制，至今仍是很多模型的灵感来源。
YOLOv4 & v5：工程化的胜利
v4 是 Alexey Bochkovskiy 的杰作，它把各种 trick（如 Mosaic 数据增强、CIoU 损失）打包在一起，性能直接拉满。而 v5 是 Ultralytics 推出的，虽然名字有争议，但它的工程化水平极高——训练简单、导出方便、部署友好。我个人习惯用 v5 做快速原型验证，真的太省事了。
YOLOv6 & v7：工业界的硬仗
v6 是美团开源的，主打工业场景，对部署做了极致优化。v7 则引入了 E-ELAN 和辅助头训练，在精度上又压了一头。我在做边缘端部署时，v7 的 tiny 版本表现相当亮眼。
YOLOv8：集大成者
v8 是 Ultralytics 的最新力作。它把检测、分割、分类、姿态估计全整合到一个框架里。说白了，v8 不只是一个模型，它是一个完整的视觉工具链。它的 Anchor-Free 设计让后处理更简单，推理速度也更快。
| 版本 | 核心创新 | 我的评价 |
|---|---|---|
| v3 | Darknet-53 + FPN | 经典永流传，小目标检测的基石 |
| v4 | Trick 集大成者 | 学术与工程的完美结合 |
| v5 | 工程化标杆 | 我最常用的快速验证工具 |
| v6 | 工业部署优化 | 美团出品，边缘端友好 |
| v7 | E-ELAN + 辅助头 | 精度怪兽，tiny 版很香 |
| v8 | Anchor-Free + 多任务 | 一站式解决方案，未来趋势 |
1.2 OpenCV DNN 模块介绍
聊完模型，咱们说说部署工具。OpenCV 的 DNN 模块，是我个人最推荐的推理后端之一。为什么？因为它 零依赖、跨平台、开箱即用。
你不需要装 PyTorch、TensorFlow 这些庞然大物。只要一个 OpenCV，就能跑 YOLO。我在嵌入式设备上部署时，经常用这个模块，省去了很多环境配置的麻烦。
避坑指南：OpenCV DNN 模块默认使用 CPU 推理。如果你想用 GPU 加速，需要编译带 CUDA 支持的 OpenCV。我曾经在这上面踩过坑，编译时少了一个 flag，结果 GPU 死活不工作。嗯，后面我会专门讲怎么编译。
DNN 模块支持读取多种格式的模型：
- .cfg + .weights：Darknet 原生格式，YOLOv3/v4 常用
- .onnx：开放神经网络交换格式，v5/v6/v7/v8 首选
- .pb：TensorFlow 格式
- .caffemodel：Caffe 格式
它的核心 API 就几个：readNet()、blobFromImage()、forward()。简单到令人发指。但简单不代表简陋，它的底层优化做得相当不错。
1.3 推理加速的核心指标
做部署，最怕的就是「模型跑不起来」或者「跑起来太慢」。衡量推理性能，有三个核心指标你必须刻在脑子里。
FPS（每秒帧数）
FPS 就是 1 秒内能处理多少张图片。比如 30 FPS，意味着每张图片耗时约 33 毫秒。这个指标最直观，也是大家最常挂在嘴边的。
但要注意，FPS 是平均值。如果某几帧特别慢，用户会感觉到卡顿。所以光看 FPS 不够，还得看延迟。
延迟（Latency）
延迟是 单张图片从输入到输出所花的时间。它通常用毫秒（ms）表示。在实时系统中，延迟比 FPS 更重要。比如自动驾驶，你更关心「这一帧花了多久」，而不是「平均每秒能跑多少帧」。
我遇到过一种情况：模型平均 FPS 很高，但偶尔有一帧延迟飙到 200ms。这在视频监控里是致命的，会直接导致丢帧。所以，我习惯同时监控 P99 延迟（99% 的请求都在这个时间内完成）。
吞吐量（Throughput）
吞吐量是 单位时间内能处理的任务数量。在服务器端部署时，这个指标很关键。比如一个 GPU 同时处理 8 路视频流，吞吐量就是 8 路 × 30 FPS = 240 张/秒。
吞吐量和 FPS 有点像，但侧重点不同。FPS 看单路，吞吐量看整体。做多路并发时，吞吐量才是你的瓶颈。
| 指标 | 定义 | 适用场景 |
|---|---|---|
| FPS | 每秒处理帧数 | 单路视频流、实时检测 |
| 延迟 | 单帧处理耗时 | 自动驾驶、工业控制 |
| 吞吐量 | 单位时间处理总量 | 服务器端、多路并发 |
注意：这三个指标是相互制约的。你追求低延迟，可能就要牺牲吞吐量。你追求高 FPS，可能就要接受更高的延迟。没有完美的配置，只有最适合你场景的配置。
1.4 本章知识体系总览
为了让你对本章内容有个整体印象，我画了一张结构图。它把 YOLO 发展史、OpenCV DNN 模块、性能指标串在了一起。你可以把它当作一张「地图」，后面每学一章，都可以回来对照一下。
这张图把本章的三个核心模块串起来了。左边是模型演进，中间是部署工具，右边是衡量标准。后面每一章，都会围绕这三个维度展开。