最早那会儿，YOLO 还不叫 YOLO，论文标题是You Only Look Once: Unified, Real-Time Object Detection。看到 "Unified" 这个词，就觉得这东西有点意思——它把目标检测里那些割裂的步骤全揉在一起了。后来这几年，YOLO 从一个学术论文里的算法，硬生生长成了一个庞大的工程生态：从 v1 到 v8，再到 v9、v10，还有各种变体和官方之外的分支，几乎每个做视觉、做边缘计算、做自动化的人手里都有一份自己熟悉的 YOLO 版本。这篇文章我就站在一个常年用 YOLO 做落地项目的人的角度，把历代版本怎么演进的、每个版本动了什么核心模块、牺牲了什么又换来了什么，系统地梳理一遍。顺便把部署环境、导出 ONNX、损失函数那点事也扯清楚，给想入门或者正在做技术选型的朋友一份能直接用的参考。
如果你是刚接触目标检测，或者想从训练到部署完整走通一套流程，这篇文章就是给你准备的。如果你是老手，也可以看看我对 v4 到 v8 这段工程化竞争期的拆解，有些细节可能你已经忘了，但它们恰恰是 YOLO 能活到今天的关键。
1. 从 v1 到 v3：单阶段检测路线的奠基时代
1.1 YOLOv1：把检测问题彻底变成回归问题
YOLOv1 的核心思想用一句话说就是：把整张图喂进网络，一次前向传播同时输出所有目标的类别和位置。它把输入图像划分成 S×S 的网格（论文里是 7×7），每个网格负责预测固定数量的边界框和类别概率。相比当时的 R-CNN 系列需要 region proposal + 分类 + 后处理一堆流程，YOLO 的快是降维打击式的。
但它的问题也很明显：每个网格只能预测有限数量的框，靠得近的小目标基本认不出来；边界框定位精度也糙，因为直接回归坐标，没有 anchor 的先验约束。还有，原版 v1 用的网络结构其实就是 GoogLeNet 的改造，没有残差连接，训练时挺容易过拟合。所以 v1 在 VOC 上的 mAP 并不算高，但它的意义在于证明了“检测可以是一个端到端的回归问题”，这条路线后来被整个行业反复验证。
我印象最深的一点是 YOLOv1 对“上下文”的利用。它把整张图都看了一遍，所以背景误检大幅度减少；分类错误率也比两阶段方法低。这个特性在视频监控这类场景里特别值钱——背景干净一点，误报就少一点。
1.2 YOLOv2：Anchor 机制与全卷积化的第一次进化
v2 解决的问题很明确：召回率和定位精度。作者借鉴了 Faster R-CNN 的 anchor 思想，但用了自己的 K-means 聚类方法在训练集上统计边界框的宽高先验。这个操作后来成了 YOLO 系列最经典的一步——聚类得到的 5 组 anchor 宽高，是针对数据集自适应出来的，比人工拍脑袋设计的 anchor 合理得多。
v2 还把 backbone 换成了自己设计的 Darknet-19，加入了 Batch Normalization。BN 对训练收敛的帮助是革命性的，基本上每个卷积层后面接一个 BN，就能把收敛速度提上去，还附带一点正则效果。同时 v2 引入了 passthrough 层把浅层特征拼到深层来提升小目标检测能力，并且支持多尺度训练——每迭代几次就换一种输入分辨率。这种“网络自己适应分辨率”的思路，让同一个模型可以在速度和精度之间灵活切换。
如果你现在去翻源码还会发现，v2 已经做了 anchor 的坐标编码，用 t_x、t_y、t_w、t_h 配合 sigmoid 来预测相对网格的偏移。这套编码方式直到今天还在用，只是细节上不断调整。
1.3 YOLOv3：多尺度预测与现代骨架的分水岭
v3 几乎奠定了现代 YOLO 的骨架布局：Darknet-53 加上特征金字塔（FPN）结构，输出 3 个尺度的特征图，分别负责大、中、小目标。每个尺度上使用 3 组 anchor，一共 9 组。这一代开始，YOLO 不再是“快但不准”的代名词，在小目标和密集场景下的表现开始接近两阶段方法。
我记得当年把 v3 跑起来的感觉：COCO 上 57.9% 的 AP（不区分大小目标时综合看）已经不是玩具水平，而速度依然能到 30+ FPS 甚至更快。v3 使用的 logistic 回归替代 softmax 来做类别预测，这样同一个目标可以输出多标签结果，这让它在那些“一个目标同时属于多个类别”的复杂场景里也更灵活。
v3 的另一个容易被忽略的贡献是它对“误检”的控制。得益于多尺度预测和更大的感受野，模型对遮挡、截断目标的鲁棒性明显提高。到今天还有不少老项目直接用 v3 的权重做迁移学习，因为它的底层特征提取能力非常稳定，作为预训练模型其实很划算。
2. v4 到 v7：工程化竞赛与两条技术路线的分化
2.1 YOLOv4：Bag of Freebies 的集大成者
v4 严格来说是 Alexey Bochkovskiy 在 Darknet 框架上继续搞出来的，但它从 v3 到 v4 的跨越是巨大的。首先是 backbone 换成了 CSPDarknet53——CSP 结构把特征图分成两部分，一部分走密集连接，一部分走主干，这样既减少计算量又能缓解梯度信息重复的问题。然后是 neck 部分引入了 SPP 和 PANet：SPP 用多尺度池化扩大感受野，PANet 在 FPN 基础上增加了一条自底向上的路径增强，让底层位置信息也传递得更充分。
激活函数这块，v4 把 Mish 用在了 backbone 上，精度确实涨了，但推理速度也相应地慢了。还有训练技巧那一堆：Mosaic 数据增强、CmBN、SAT 自对抗训练、CIoU 损失函数。这已经不是在改网络结构，而是在“训练策略”这个维度上做文章。所以论文里专门用了 Bag of Freebies 这词——“免费午餐”，不用改结构就能提点。
我那时候在 1080Ti 上跑 v4，速度和精度平衡得很舒服，尤其是针对小目标的训练，Mosaic 增强让模型看到了大量裁剪拼接出来的“假小目标”，泛化能力明显变好。
2.2 YOLOv5：工业落地最广的版本，没有之一
虽然 YOLOv5 一直有“名字争议”，但说它是 YOLO 家族里对工业界影响最大的一个版本毫不为过。Ultralytics 团队没有发表正式论文，直接把仓库开源出来，配套了极其完善的工程工具：数据集格式自动转换、超参数进化、自动 anchor 计算、TensorRT/ONNX 导出一条龙。
v5 的模型实际结构是 Focus 模块加 CSP 加 SPPF，配合自适应 anchor。最关键的是它的代码设计哲学——每个组件都可以通过 yaml 配置文件替换，换 backbone、换 neck、换 head，全都不需要改源代码。这种“模型即配置”的思路，让团队里非算法背景的工程师也能快速调整模型结构，这在当时的开源项目里非常罕见。
如果你问我现在哪个版本最适合快速落地，我还是会推荐 YOLOv5。不是因为它的指标最高，而是它的坑最少：网上资料多、部署生态成熟、Pytorch 权重转 ONNX 转 TensorRT 的路径已经被踩烂了。而且 v5 的 n/s/m/l/x 五档规模让你从边缘盒子到服务器都能选到合适的体量。
2.3 v6 与 v7：自研结构的分岔路口
YOLOv6 来自美团，走的是工业部署导向路线，引入了解耦检测头（Decoupled Head）和 Anchor-Free 策略，并且在训练时用了蒸馏策略。当时被最多人拿来对比的，是它在同体量下比 v5 有更高的 mAP 且推理延迟更低。尤其是解耦头——把分类和回归任务分开到不同分支，因为这两个任务对特征的关注点其实不太一样，共享一个检测头会互相干扰。这个设计后来成了 v8 等后续版本的标配。
YOLOv7 则是 Alexey 在 Darknet 路线上的延续，核心是 E-ELAN 结构、重参数化卷积和辅助训练头。E-ELAN 通过控制梯度路径的长度让网络在加深的同时不发生梯度退化；重参数化卷积则是训练时用多分支结构提升表达能力，推理时又合并成单分支来提速。v7 在实时性要求极高的场景里一直很有竞争力，而且它对硬件适配做得很细，直接在边缘设备上跑也不吃力。
站在当时的角度看，v6 和 v7 几乎是同期出现的，一个在 Pytorch 体系里卷工程，一个在 Darknet 体系里卷结构设计。它们一起把 YOLO 推上了“实时目标检测天花板”的宝座，但也为后面 v8 的大一统埋下了伏笔。
3. v8、v9、v10 与生态化：Anchor-Free、端到端与多任务扩展
3.1 YOLOv8：现代 YOLO 的标准形态
YOLOv8 还是 Ultralytics 出的，但它不再只是修补 v5，而是直接重构了整个训练和推理流程。结构上最明显的两个变化：一是彻底 Anchor-Free，用中心点加宽高回归代替预定义 anchor；二是检测头换成了解耦结构，分类分支和回归分支分开输出，配合 TaskAlignedAssigner 做标签分配。
v8 还顺便把 YOLO 的训练生态推向了统一平台：detection、segmentation、classification、pose estimation 全都在同一个仓库里能用同一套 pip 命令跑起来。你只要pip install ultralytics，然后通过简单的 CLI 就能训练自己的模型。这种“全家桶”模式对刚入手的人来说简直友好到不行，但对想要深挖底层原理的人反而有点黑盒化倾向。
我自己用 v8 的体验是：默认参数下训练就很稳，尤其是用了自动混合精度（AMP）之后，显存占用直接砍半，训练速度翻倍。v8 在相同体量下的精度比 v5 高出一截，尤其在中等目标上，AP 提升明显。缺点呢，推理时如果开启 NMS，小目标密集场景下偶尔会把两个相邻目标合并掉一个，需要适当调低置信度阈值或者用更大输入尺寸来缓解。
3.2 v9 与 v10：信息瓶颈的破解和端到端的追求
YOLOv9 提出了一个很有意思的理论问题：深度网络在传递信息时存在信息瓶颈，前向传播过程中会丢失细粒度信息。它的解法是 PGI（可编程梯度信息），让网络能够保留完整的信息用于梯度回传，配合 GELAN 轻量级结构在精度和速度之间找平衡。v9 论文里的对比实验显示，在参数更少的情况下能达到比 v8 更高的 AP，这在理论层面确实很有分量。
YOLOv10 走的是另一条路：端到端检测。它去掉了 NMS，通过双标签分配策略（one-to-many + one-to-one）在训练时就学会自己挑出最佳预测框，推理时只需要一个简单的阈值筛选。这直接解决了 NMS 在边缘设备上带来的额外开销和不稳定性。如果你做的是高帧率实时推理，v10 的“无 NMS”设计能省下肉眼可见的延迟。
这两个版本的出现，说明 YOLO 已经不再是单纯刷精度指标的竞赛，而是在往“更深入地理解检测这个任务本身”的方向走。对普通使用者来说，v9 和 v10 的 API 基本都兼容 ultralytics 生态，迁移成本不高。
3.3 实例分割与多任务 YOLO：一个模型干多件事
YOLOv5 时代就有 YOLOv5-seg，v8 更是把分割直接内置成了官方能力。实例分割版的多了一个 mask 分支，输出分辨率通常是原图的 1/4，经过上采样得到每个目标实例的掩码。这个功能对很多场景是刚需：比如智慧交通里既要框住车辆，还要区分车道占用区域；比如工业质检里要精确圈出缺陷形状而不能只是一个框。
YOLO 做实例分割在速度上的优势非常大，一个模型同时输出检测框和掩码，端到端的延迟比 Mask R-CNN 低一个量级。精度上当然还有差距，尤其是边界轮廓的细节，但如果业务只需要粗略的像素级区域，YOLO-seg 完全够用。我自己在 AGX Orin 上跑过 v8-seg，输入 640×640，TensorRT FP16 下能达到 20ms 级别，这在很多嵌入式项目里已经是可用的水平了。
多任务扩展还不止分割，姿态估计版本的 YOLOv8-pose 也是同一个仓库里的东西，一个网络输出 keypoint 坐标和置信度。你可以一套代码同时做检测、分割、姿态，这在做视频分析、行为识别这类综合项目时价值极高——不用维护三个模型了。
4. YOLO 损失函数演进：边界框、置信度与分类的平衡术
4.1 边界框回归损失：从 IoU 到 CIoU 再到 Distribution Focal Loss
最早的 v1 用的是简单的 SSE（sum of squared error）直接回归坐标，这样会有两个问题：坐标值和 IoU 之间不是完全单调关系；不同尺度的框对误差的贡献不平衡。v2、v3 开始使用 IoU 系损失，IoU 直接对“框得准不准”建模，梯度更合理。但 IoU 损失在框完全不重叠时梯度为零，于是又出现了 GIoU 把最小外接矩形补进去，解决了训练初期的梯度消失问题。
真正让 YOLO 系列全面起飞的是 CIoU：在 IoU 损失的基础上加入了中心点距离和宽高比的惩罚项。CIoU 能够同时让预测框在中心点、宽高两方面都向目标框靠拢，训练过程稳定收敛。v8 之后官方默认回归损失换成了 Distribution Focal Loss（DFL），它把边界框的输出当作一个离散分布去学习，而不是直接回归一个值，这能让模型对边界位置的不确定性有更细的刻画。代价是实现复杂度变高了，但精度的提升在 COCO 这类数据集上是实打实的。
4.2 置信度与分类损失：正负样本的博弈
YOLO 系列传统的置信度损失用的是 BCE，也就是把“框里是否有目标”当作一个二分类问题。早期版本的置信度是“框内目标的概率”乘以“该目标与真值的 IoU”，这样就逼迫网络在“有信心”和“框得准”之间同时优化。后来 anchor-free 版本不再需要预测置信度中的 IoU 部分，因为中心点本身就代表目标存在的位置，所以损失函数的设计重心转移到“怎么区分正负样本”上。
这里最容易踩的坑是正负样本极度不平衡。一张图上往往只有几十个正样本，而潜在负样本成千上万个。各版本应对策略各不相同：有的用 focal loss 压低易分类负样本的损失权重；有的在标签分配阶段先用中心距离约束筛选候选框，减少负样本数量。我见过很多新手在自定义数据集上损失半天降不下去，十有八九是标签分配或者 anchor 尺寸没配对。
4.3 多任务损失权重：你真的调对了吗
YOLO 的最终损失一般是三块加权求和：分类损失 + 回归损失 +（如果有的话）关键点或分割损失。版本越新，这个权重越不太需要手工调：v8 用 TaskAlignedAssigner 做了自适应分配，v10 用双标签让两个分支各司其职。但如果你发现训练出的模型“检出框都不准”或者“置信度虚高”，那大概率还是需要在训练策略层面调，而不是直接加大某个损失权重。
我自己习惯的做法是：先用官方默认权重跑 50 个 epoch，观察三类损失各自的下降曲线；如果回归损失下降很慢，就尝试把回归损失权重提高 25%；如果分类损失很早就降到了 0.01 以下而回归还在慢慢磨，那多半是正样本太少，应该回头看看数据标注。损失权重只是在相同训练设置下的微调手段，它救不了标注质量的锅。
5. 从 PyCharm 到 AGX Orin：环境搭建、导出与部署落地
5.1 PyCharm 里装 YOLO 最顺的一条路
很多人最开始是在 PyCharm 里捣鼓 YOLO 的。最省心的路径其实不是去源码编译，而是直接用官方预构建包。以当前版本为例，建一个虚拟环境后执行pip install ultralytics，它会自动带上 torch、torchvision 以及 opencv-python 等核心依赖。然后下载权重文件放到工作目录，写个小脚本就能跑推理。
这里有几个非常具体的坑：一是 PyCharm 的 interpreter 一定要指向虚拟环境里的 python，别全局装；二是 Windows 上如果提示缺少 DLL，多半是 torch 的 CUDA 版本和驱动不匹配，需要重新安装对应 CUDA 版本的 torch；三是不建议在项目里直接改依赖库源码，尤其是模型中utils/loss.py这类文件，改完一升级就全丢了。要改逻辑就自己写子类或者 fork 仓库。
推理脚本本身很简单，加载模型后传入图像路径即可，结果是一个包含 boxes、masks、keypoints 等结构的列表。新手最容易忽略的是“输入尺寸”和“置信度阈值”这两个参数：同样的模型在输入 640 和输入 1280 下的表现完全不是一回事，前者快但小目标易漏检，后者慢但精度高。建议根据你的目标尺寸分布来做选择，而不是一直用默认值。
5.2 导出 ONNX 模型：格式转换其实很讲究
导出 ONNX 这一步几乎每个做部署的人都要经历。命令很简单：yolo export model=yolov8n.pt format=onnx opset=12，但导出后的模型直接拿去和 PyTorch 模型比精度，经常会发现有小幅下降。原因多半是输入尺寸不同、opset 版本导致部分算子实现有差异，或者动态轴设置导致 batch 和 height/width 在导出时被固定。
我的建议是导出时明确固定输入尺寸：yolo export model=best.pt format=onnx imgsz=640 dynamic=False simplify=True。simplify 选项会使用 onnx-simplifier 去掉一些冗余算子，对后续转 TensorRT 非常有用。如果你要跨设备部署，还要把 dynamic=False 固定住，否则某些推理引擎对动态 shape 支持不友好，推理速度会大打折扣。
完事之后建议用 onnxruntime 跑一遍同一张测试图，对比 PyTorch 输出。如果两边的检测框数量、置信度差异很小，基本可以认为导出成功；如果框差得明显，优先检查预处理是否一致——尤其是归一化是除以 255 还是除以标准差、BGR 还是 RGB，这些细节最容易出问题。
5.3 一键部署脚本：AGX Orin 上搭 YOLO 的真实体验
在 AGX Orin 上搭环境，比在台式机上要小心得多。Orin 用的是 ARM 架构的 JetPack 系统，很多面向 x86 的预编译包装不了，必须从源码构建。我踩过最大的坑是 torch 和 torchvision 的版本要严格对应 JetPack 自带 CUDA 的版本，错一个版本都可能出现 “CUDA driver version is insufficient” 的报错。
我的建议是把整个部署流程写成 shell 脚本：先安装 JetPack 兼容的 PyTorch，再装 torchvision，然后拉取你要的 YOLO 仓库或直接 pip 装 ultralytics。接着安装 TensorRT 相关的 Python 绑定，最后把 export 好的 engine 文件拷贝到目标板。这样在干净环境里跑一遍脚本就能搞定，不用每次手工敲命令。
Orin 上跑 YOLO 的体感是：v8n 在 FP16 TensorRT 下能做到个位数毫秒级，v8s 大概 15ms 到 25ms 之间。如果你的业务需要更高的帧率，可以尝试在导出时把输入尺寸压到 416 或者 480，精度损失通常可以接受。千万别在 Orin 上用原生 PyTorch 模型直接推理，那样既慢又浪费板子的算力。
6. 真实场景里的 YOLO：从矿泉水瓶检测到智慧交通多模态系统
6.1 边缘设备上的常见玩法：D435i 测距、AGX Orin 推理
深度相机加 YOLO 的组合在机器人、自动化领域很常见。以 Intel RealSense D435i 为例，它输出的彩色图送给 YOLO 做检测，深度图则用于计算目标距离。具体做法是：先用 YOLO 拿到目标框的中心像素坐标，然后取深度图对应位置的深度值。注意这里有个坑：深度图与彩色图的分辨率和视角不一致，必须先做对齐（align）操作，否则测出来的距离会偏。
还有一种更稳的做法是取目标框内所有有效深度值的中位数或者 25% 分位数，因为框的中心像素可能会落在目标内部的空洞或反射区上，噪声很大。我在实际项目中就是取框内有效深度值的中位数来测距，稳定性和误差表现都远好于单点法。
AGX Orin 这类边缘设备跑 YOLO 的价值在于低功耗和低延迟同时满足。你可以在片内同时跑检测模型、跟踪器和深度的后处理逻辑，整个系统做到端到端 30 FPS 以上。这种部署方式现在已经在工业巡检、仓储 AGV、智能交通等场景里大量落地。
6.2 垂直行业案例盘点：专注度、卡路里、肺结节与智慧交通
单纯说说这些热词背后的思路。学生专注度检测用 YOLOv8 先框出每个学生的头部和上身，然后结合头部姿态估计和眼部状态做分析，这里关键是头部框的稳定跟踪不能断，否则很容易误判“人在不在位”而不是“是否专注”。矿泉水瓶这类单一类别目标检测相对简单，重点在于标注的一致性和场景亮度变化的鲁棒性，数据里一定要多放不同光照条件、不同遮挡程度的样本。
食物卡路里检测的核心不在于识别“这是汉堡”，而在于“这是多大的汉堡”。用 YOLO 框出食物区域后，还要计算像素面积并借助深度或参考物来估算实际物理尺寸，再查表计算卡路里。这个场景里，检测的稳定性直接影响后续估算的误差，如果框抖动，卡路里数字也会跟着上下跳，体验就崩了。
肺结节检测算是医疗方向的探索，YOLO 的优势是速度快、适合大范围筛查初筛。但医疗场景对假阴性的容忍度极低，所以并不能直接拿默认权重上线，需要结合医生标注的 CT 切片、调整锚框尺寸和损失权重，并配合大量数据增强。这里更务实的做法是把 YOLO 当作候选区域生成器，后面再接一个分类网络做二次确认，精度才可能达到临床参考价值。
智慧交通事故检测是典型的“多模态综合系统”：YOLO 做车辆、行人、摩托车和事故特征的检测，另一路多模态 AI 分析结合时序信息判断碰撞、追尾等事件。YOLO 负责“看到什么”，时序分析负责“发生了什么”。这两个能力分开做都不难，但合在一起的时候要注意“检测框的连续一致性”——同一个车辆在相邻帧里如果 ID 跳变，事件逻辑就会被带偏，所以往往需要在 YOLO 上游或者下游加一个跟踪器（比如 ByteTrack、BoT-SORT）来维护轨迹。
6.3 数据集的坑与标注质量的土办法
训练 YOLO 绕不开数据集。网上现成的数据集（COCO、VOC 之类）很干净，但你的场景只要稍微偏一点，迁移效果就会断崖式下跌。我经历过的最典型的例子是：训练集里全是白天路况，一到黄昏就疯狂漏检。后来查下来，不是模型的问题，是训练数据里黄昏样本太少，模型根本没见过那种光线下物体的特征。
标注质量这块，土办法检查非常有效：把标注框在图像上画出来，随机抽 100 张，自己挨个看。如果发现有框比目标大一圈、漏标、类别标签打错的，直接返回去让标注人员修改。还有一个很少被提到的小技巧：统计所有标注框的宽高比和面积分布，和模型的 anchor 先验做对比。如果标注框普遍窄长，而默认 anchor 是接近方形的，那训练效果一定不会好。
数据增强层面，Mosaic 是历届 YOLO 里效果最明显的增强策略，它把四张图随机裁剪拼接成一张，极大地丰富了上下文。但有一个反向的坑：如果你的任务全是拉伸变形的目标、隧道、顶视摄像头这类特殊角度，Mosaic 带来的拼接会让目标形变失真实，反而有害。这种时候我会关掉 Mosaic 或者只保留很小的概率，用更传统的 HSV 扰动和随机翻转来增强。
这些年用下来，我最大的体会是 YOLO 系列早已不是一个“算法”了，它变成了一套完整的问题解决框架。每个版本改动的不只是网络结构，更是对“检测任务本质”的一次重新理解。从 v1 直白大胆的端到端，到 v3 的多尺度融合，再到 v8 之后 Anchor-Free 与生态化，这一连串演进背后其实都是同一个诉求：让目标检测更简单、更可靠、更容易被工程化。如果你现在还在纠结选哪个版本，我的建议很直接——如果你刚入门，用 v8 官方实现就够了；如果你的项目对推理延迟极度敏感且上传统硬件，可以考虑 v5 或者 v7；如果你的团队已经有成熟工程链路，v9 和 v10 的创新点很值得引入尝试。最后分享一个小技巧：不管用哪个版本，都先跑通官方预训练权重在你的目标设备上的推理和导出一条龙，再开始碰自定义训练。环境先通了，剩下的都是数据和时间问题。
