YOLO 这个名字现在已经被用得有点泛滥了，你在搜索引擎里敲进去，前面几条可能不是算法，而是某款服务器型号、某个软件版本号，甚至某台打印机。真到要干活的时候，问题反而变得很朴素：我手上这个项目，到底该用 v5 还是 v11？换新版本能带来多少收益，值不值得把已经跑通的流水线推倒重来？我自己从 v5 时代就开始在业务里用 YOLO，中间经历过 v6、v7 的过渡期，也完整跟过 ultralytics 从 v8 到 v11 的迭代，踩过的坑从"训练到一半显存爆了"到"导出 TensorRT 之后精度掉三个点"都有。这篇东西就是把这些年攒下来的判断逻辑摊开讲：v5 到 v11 每一代到底改了什么、损失函数和标签分配是怎么一步步演化的、2026 年这个时间点该怎么选型、以及一套能直接抄作业的训练和部署流程。适合已经跑过一两个检测项目、准备做技术选型的人，也适合刚入门想少走弯路的朋友。
1. 先把版本谱系捋清楚，不然选型全是瞎猜
1.1 三个团队在共用 YOLO 这个名字
很多人以为 YOLO 是一个连续的、官方维护的版本序列，v5 之后是 v6，v6 之后是 v7，一路往上排。实际情况完全不是这样。YOLO 这个名字从 Joseph Redmon 的 v1 到 v3 之后，主线就断过一次，后面的版本是不同团队各自维护、各自命名的产物。v4 是 Alexey Bochkovskiy 那边的工作，v5 是 ultralytics 这家公司的产品，v6 是美团视觉团队发的，v7 又回到了 Alexey 那条线，v8 再次是 ultralytics，v9 是美团，v10 是清华团队，v11 又回到 ultralytics。
这意味着一个很现实的问题：版本号大小和性能强弱之间没有严格的对应关系。v6 在发布时点上的精度是超过 v5 的，v7 在特定场景下又能压过 v6，但这些比较都是限定在特定数据集、特定硬件、特定训练轮数下做的。你如果拿 v5 和 v11 直接比 mAP，那是可以比的，因为它们是同一个团队、同一套训练范式下的前后代；但拿 v6 和 v11 比，变量就太多了。
我在实际选型时会先做一个区分：ultralytics 系的版本（v5、v8、v11，以及后续的 v12 等）看成一条连续的产品线，它们的 API、数据格式、训练配置、部署工具链是一脉相承的，迁移成本低；其他团队的版本（v6、v7、v9、v10）看成独立的技术方案，它们的价值更多体现在论文里的结构创新，你要用就得自己啃代码、自己接部署链路。
这个区分对选型的影响非常大。如果你是团队里唯一负责算法的人，手上还要兼顾部署和运维，那 ultralytics 这条线的工程效率优势会远大于那零点几个点的 mAP 差距。反过来，如果你是在做论文复现或者追求极限精度，那 v9、v10 的结构设计值得深挖。
另外一个容易被忽略的点是命名混乱带来的沟通成本。我在项目评审里听过太多次"我们用最新的 YOLO 就行"，结果落地时发现有人说的是 v8，有人以为 v11 就是 YOLOv8 的小版本。所以我现在写方案文档，第一句话一定是把版本号、来源团队、权重文件名三件事同时写清楚，比如"ultralytics YOLO11m，权重 yolo11m.pt"，绝不简写成"YOLO 最新版"。
1.2 v5 到 v11 关键分水岭速览
在展开讲每一代之前，先给一张我平时用来跟非算法同事沟通的对照表。这张表不是精确的性能排行，而是帮你快速定位"哪一代是分水岭"。
| 版本 | 主要来源 | 核心变化 | 是否分水岭 |
|---|---|---|---|
| v5 | ultralytics | CSPDarknet + PANet + Anchor-based，工程化封装做到极致 | 是，定义了后来的使用范式 |
| v6 | 美团 | RepVGG 风格重参数化主干，Anchor-free 方向 | 部分，结构思路被后续吸收 |
| v7 | Alexey 线 | E-ELAN、辅助训练头、模型缩放策略 | 部分，训练技巧影响深远 |
| v8 | ultralytics | C2f 结构、解耦头、DFL、TaskAlignedAssigner、多任务统一 API | 是，最大的一次范式切换 |
| v9 | 美团 | PGI 可编程梯度信息 + GELAN | 否，但梯度思路值得看 |
| v10 | 清华 | NMS-free 的一致双分配、秩引导块设计 | 是，端到端方向的开端 |
| v11 | ultralytics | C3k2、C2PSA 注意力、头部轻量化、多任务全面增强 | 是，v8 之后的稳定收敛点 |
看这张表你会发现一件事：v5 和 v8 是两个真正的转折点，v11 是 v8 路线上的精修和收敛。这就是为什么现在讨论选型，绝大多数场景的答案会落在 v8 和 v11 之间，v5 只在特定遗留项目里还有存在价值。
2. 逐代拆解：每一代到底动了哪里
2.1 YOLOv5：把工程体验做到极致的一代
v5 最大的贡献其实不是网络结构，而是它把目标检测的训练流程做成了一个开箱即用的产品。在这之前，你要跑一个检测模型，得自己写数据加载、自己接增强、自己搭训练循环、自己处理多尺度推理。v5 用一套 YAML 配置 + 一个 train.py，把这些全包了。
结构上 v5 是典型的 Anchor-based 三段式：CSPDarknet 主干提取特征，SPPF 做多尺度池化融合，PANet 做自顶向下加自底向上的双向特征聚合，最后接三个尺度的检测头。它用的是锚框机制，也就是说网络预测的是相对锚框的偏移量，而不是直接回归框的宽高。锚框这个东西在老版本里是个绕不开的坎，你需要根据自己数据集的目标尺寸分布重新聚类锚框，否则召回率会很难看。v5 里内置了 AutoAnchor 功能，训练前会自动跑一遍 K-means 聚类来调整锚框尺寸，这是很实用的一步。
v5 在数据增强上也是堆料式的，Mosaic 四图拼接、MixUp、随机缩放裁剪、HSV 色彩抖动，一套组合拳下来对小数据集非常友好。我记得当时用一千多张工业缺陷图训 v5s，加完这些增强之后 mAP 直接比不加高了七八个点，这在数据量不足的场景里几乎是救命的功能。
但 v5 也有明显的历史包袱。它的检测头是耦合的，分类和回归共享前面的卷积特征，这对两个任务的优化目标其实是有冲突的；它的标签分配是静态的，靠宽高比阈值和中心点距离来匹配正样本，对小目标和密集目标不太友好；再加上锚框机制本身带来的超参敏感，v5 在复杂场景下确实开始吃力了。
现在还有人在用 v5，我一般会问两个问题：你的项目是不是已经稳定运行、不打算重构？你的部署链路是不是深度绑定了 v5 的某些输出格式？如果两个都是，那就别动，能跑就是最好的；只要有一个是否定的，迁移到 v8 或 v11 的收益是实打实的。
2.2 v6 和 v7：被夹在中间但贡献不小的两代
v6 是美团团队在 2022 年放出来的，主打的是重参数化主干。它借鉴了 RepVGG 的思路，训练时用多分支结构提升表达能力，推理时把多分支等价融合成单路卷积，这样训练精度高、推理速度还不受影响。这个思路后来被很多轻量化模型吸收。v6 还全面转向了 Anchor-free，去掉了锚框那一套超参。
v7 是 Alexey 那条线在 2022 年的作品，比较有意思的是辅助训练头的设计。简单说就是在中间层额外接一个检测头参与训练，让浅层特征也能拿到梯度信号，但推理的时候这个辅助头直接丢掉，不增加任何计算量。这个技巧本质上是一种深监督，对训练收敛很有帮助。v7 还系统性地讨论了模型缩放的问题，也就是当你要把模型做大做小时，深度、宽度、分辨率三个维度应该按什么比例扩，扩错了会导致参数量和计算量不成比例地增长。
这两代都没有成为长期主流，但它们贡献的结构和训练技巧，在后来的模型里到处能看到影子。我的建议是：你不需要用 v6、v7 做项目，但值得花一两个小时读一下它们的核心设计。看懂了辅助头和重参数化，你对后来版本的很多设计会有更直觉的理解，而不是当成黑盒。
2.3 YOLOv8：整个范式的切换点
v8 是 ultralytics 在 2023 年放出来的，它做的最重要的一件事是把 YOLO 从"一个检测模型"变成了"一个多任务框架"。检测、实例分割、姿态估计、图像分类、旋转框检测，全部共用同一套 API 和同一个预训练主干，你只要换个权重文件名就能切换任务。这个变化对实际项目的影响比任何精度提升都大，因为很多时候你做完检测，业务方下一句就是"能不能把框里的东西抠出来"，以前这意味着换一套代码库重来，现在只要把-seg权重换上。
结构上 v8 有三处核心改动，每一处都值得说清楚。
第一处是C2f 模块替代 C3。C3 是三个卷积并联再拼接，C2f 则是在跨层连接的基础上做了更密集的分支合并，梯度流更丰富，同等参数量下表达能力更强。你可以把它理解成把"并联"改成了"并联再串并联"，信息通路更多。
第二处是解耦头。分类和回归各自走一条独立的卷积分支，不再共享特征。这个改动逻辑很好理解：分类关心的是"这是什么"，回归关心的是"它在哪、多大"，两者的特征需求本来就不一样，强行共享会互相牵制。实测下来解耦头对定位精度的提升是肉眼可见的。
第三处，也是最有技术含量的一处，是TaskAlignedAssigner + DFL 的组合。前者负责决定"哪些预测框算正样本"，后者负责让框回归更精细。
2.4 TaskAlignedAssigner 和 DFL：v8 精度提升的真正来源
先讲 TaskAlignedAssigner，我一般叫它 TAL。传统的标签分配要么纯靠 IoU 阈值（ATSS 那套），要么纯靠中心点距离，TAL 的思路是把分类得分和定位 IoU 乘起来，用一个综合的对齐度指标来决定正样本。
具体做法是这样：对于一个真实框，网络会预测出一堆候选框，TAL 会计算每个候选框的分类得分 s 和它与真实框的 IoU 值 u，然后算一个对齐度 t = s^α × u^β，取这个值最高的前 k 个候选作为正样本。这个设计的精妙之处在于，它同时兼顾了"分类准"和"定位准"两个维度，避免了那种分类得分很高但框歪到天上去的预测被当成正样本。
为什么要这么做？你想想，如果标签分配只看 IoU，那么一个分类完全学错但恰好位置对的框也会被当成正样本，网络就会收到一个矛盾的监督信号，"你要把它当成这个类别"。TAL 用乘法把两个维度耦合起来，让监督信号更干净，训练更稳定，收敛也更快。我在小数据集上对比过，同样的配置下 TAL 比静态分配的收敛速度快了大概三成轮次。
再讲DFL，分布式焦点损失。传统框回归是直接预测一个数值，比如框的左边界距离中心点 32.7 个像素。DFL 换了个思路，它把每个边界位置离散成一组区间（默认 16 个 bin），让网络预测一个概率分布，然后用期望值来还原实际距离。
这个改动听起来绕，但好处很实在：它把回归问题变成了分类问题的形式，避免了直接回归在边界附近的不稳定性。直接回归一个连续值的时候，网络对难样本的梯度很容易爆炸；而预测分布有天然的数值上界，梯度更可控。而且它隐含地提供了不确定性信息，分布越尖锐说明网络越确定，越平坦说明越犹豫。这在后处理里可以拿来做置信度过滤的辅助信号。
2.5 v9 和 v10：两条不同的破局路线
v9 来自美团，核心是PGI（可编程梯度信息）和 GELAN。PGI 想解决的问题是：深层网络训练时，浅层特征的信息会在层层传递中被稀释。它的做法是在主干里插一些可编程的分支，把浅层的信息直接"搬运"到需要的地方，而不是只靠反向传播慢慢调。GELAN 则是把 ELAN 和 CSP 的思路做了整合，让不同深度的特征融合更充分。
v9 的思路很有启发性，但它的工程生态相对薄弱，你要用基本上得自己魔改代码，预训练权重和部署工具的完善度都不如 ultralytics 那条线。我一般是把它当参考文献看，不当生产工具用。
v10 来自清华，主打NMS-free。这个点值得单独拎出来说，因为它牵扯到端到端检测的根本问题。
传统检测模型的输出是一大堆重叠的框，必须靠 NMS（非极大值抑制）来去重。NMS 有两个毛病：一是它是个超参敏感的后处理，iou 阈值调不好要么框太多要么把挨得近的目标误删；二是它很难做成端到端的可微流程，部署到某些硬件上会成为性能瓶颈。
v10 的做法是在训练时同时使用一对多的分配（一个真实框匹配多个预测）和一对一的分配（一个真实框只匹配一个预测），两者共享主干和部分检测头。推理时只用一对一的那个分支，这样输出天然就是去重后的结果，完全不需要 NMS。这个"一致双分配"的设计是端到端检测的一个漂亮解法。
不过要注意，NMS-free 在部署上是双刃剑。好处是流程简洁、延迟稳定，坏处是它把去重的压力转移到了网络内部，密集场景下的精度可能不如"NMS 调得很好的传统方案"。我实测过，在人群密集的监控场景里，传统方案加精细调参的 NMS，精度还是能略胜一筹。所以 NMS-free 更适合对延迟稳定性要求高、目标密度中等的场景。
2.6 YOLOv11：v8 路线上的精修
v11 是 ultralytics 在 2024 年放出的，它的定位很清楚：不推翻 v8 的范式，只做结构上的精修和效率优化。
主干上最大的改动是C3k2 模块。它其实是 C2f 的一个变体，通过参数控制内部卷积核的大小和分支数量，在浅层用较小的核、深层用较大的核，让参数量和感受野更匹配。另一个是C2PSA，它在主干末端引入了注意力机制，用的是类似 PSA（位置敏感注意力）的设计，通过多头注意力和空间注意力来强化关键区域的特征。
这里我要多说一句注意力的取舍。加注意力确实能提升精度，但它对部署不友好，因为很多边缘推理框架对注意力算子的支持不完善，导出 ONNX 之后可能被拆成一堆小算子，实际推理速度比理论值慢很多。v11 的聪明之处在于它把注意力只放在主干最末端，也就是分辨率最低的那一层，这一层的特征图尺寸最小，注意力带来的计算开销可控，对整体速度的影响就小。我实测下来 v11m 在 TensorRT 上的耗时和 v8m 基本持平，但 mAP 高了大概一到两个点。
v11 还有一个容易被忽略的改动是检测头的轻量化，部分卷积换成了深度可分离卷积，参数少了一些。官方给的数据是同等精度级别下参数比 v8 少两成左右，这对显存紧张的场景是有意义的。
另外 v11 在多任务上做了全面增强。姿态估计的关键点精度、分割的掩码质量、旋转框的回归稳定性都有提升，还新增了一些方向相关的任务支持。如果你的项目是检测加姿态这种组合需求，v11 相比 v8 的优势会比单纯的检测任务更明显。
2.7 各版本对比速查表
我把平时做选型时用的对比表放在这里。注意这张表里的精度是相对值，不是绝对值，因为具体数字强依赖于你的数据集和训练配置。
| 维度 | v5 | v8 | v9 | v10 | v11 |
|---|---|---|---|---|---|
| 锚框机制 | Anchor-based | Anchor-free | Anchor-free | Anchor-free | Anchor-free |
| 标签分配 | 静态 | TAL | TAL 变体 | 一致双分配 | TAL |
| 是否需要 NMS | 是 | 是 | 是 | 否 | 是 |
| 多任务支持 | 仅检测 | 全面 | 部分 | 检测为主 | 全面增强 |
| API 成熟度 | 高（老） | 很高 | 低 | 中 | 很高 |
| 部署工具链 | 完善 | 完善 | 需自建 | 需自建 | 完善 |
| 单阶段模型精度 | 基准 | 高 | 高 | 高 | 最高 |
| 迁移成本 | - | 中 | 高 | 高 | 低（从 v8） |
| 许可证 | AGPL-3.0 | AGPL-3.0 | GPL-3.0 | AGPL-3.0 | AGPL-3.0 |
这张表里有个坑要专门提醒：许可证。ultralytics 系的权重和代码是 AGPL-3.0，这个协议对商业闭源分发是有约束的。如果你的产品要交付给客户且不开放源码，需要走商业授权。这一点在做选型时必须提前跟法务确认，别等模型都训好了才发现协议有问题。其他团队的版本大多是 GPL 系，约束类似。
3. 核心机制：损失函数和结构演进的内在逻辑
3.1 损失函数从 IoU 家族演变到 DFL
讲损失函数之前，先把检测任务的损失拆成三块：分类损失、定位损失、置信度损失。v5 时代这三块是 BCE（二值交叉熵）做分类、BCE 做置信度、CIoU 做定位。v8 之后置信度损失被合并进分类分支（因为 Anchor-free 没有独立的 objectness），定位损失换成了 CIoU 加 DFL 的组合。
定位损失的历史就是 IoU 家族的进化史。最早的 IoU Loss 直接用交并比，问题是两个框完全不相交的时候梯度为零，网络学不动。GIoU 引入了最小外接矩形来补上这个洞，让不相交的时候也有梯度方向。DIoU 进一步加入了中心点距离项，让框收敛得更快。CIoU 再加一个宽高比一致性项，让框的形状也能对齐。
这几个损失我实际用下来的感受是：在正常数据集上，IoU 到 CIoU 的差距没有论文里写得那么夸张，可能就零点几个点。但在目标尺度差异很大、或者有很多长条形目标的场景里，CIoU 的宽高比项确实有用。我做过一个输电线异物检测的项目，目标又细又长，用 GIoU 的时候框总是学不圆，换 CIoU 之后明显改善。
DFL 的作用前面讲过了，它是把连续回归变成分布预测。这里补充一个实操细节：DFL 默认的 bin 数量是 16，也就是每个边界位置用 16 个离散值来表示。这个数字不是随便定的，它其实有个约束——bin 数量必须是 4 的倍数，因为回归头输出通道的分配有这个要求。你要改的话建议在 8 到 32 之间调，太小了分辨率不够，太大了参数量上去了收益递减。我一般不改，默认 16 在绝大多数场景够用。
在自定义损失的时候还有个容易忽略的点：各项损失的权重配比。ultralytics 默认的分类权重是 0.5、定位权重是 7.5、DFL 权重是 1.5。这个配比是大量实验调出来的，你不建议轻易动。我见过有人为了提升定位精度把定位权重调到 20，结果分类崩了，因为梯度被定位项主导，分类分支基本学不到东西。真要调，一次动一个，幅度别超过 50%。
3.2 标签分配决定了模型的上限
我经常跟人说一句话：检测模型的精度上限，很大程度上是标签分配决定的，不是网络结构决定的。结构决定了特征提取能力，但分配决定了网络到底在学什么。
静态分配的思路是"规则说了算"：IoU 超过 0.5 就算正样本，宽高比在一定范围内才算，中心点必须落在某个区域内。这套规则在人手设计的时代够用，但它的阈值是全局的，对大小目标一视同仁，这就导致小目标经常匹配不到足够的正样本。
动态分配的思路是"网络自己说了算"：每一轮训练都根据当前的预测结果重新计算哪些候选算正样本。TAL 是其中的代表，用分类得分和 IoU 的乘积来排序。后来还有更复杂的方案，比如用最优传输理论来做一对一分配（v10 用的一致双分配就属于这一类）。
这个演进带来的实际收益是什么？我给你个具体例子。我做过一个光伏板缺陷检测，缺陷尺度从几个像素到几百个像素都有。用 v5 的静态分配，小缺陷的召回率一直在 60% 上下打转；换到 v8 的 TAL 之后，同样数据集、同样增强，小缺陷召回率提到了 78%。结构参数其实没变多少，变的就是分配策略。
所以如果你现在的模型在小目标或者密集目标上表现很差，优先考虑换版本或者调分配相关参数，而不是去堆网络结构。这是很多人踩过的弯路。
3.3 结构演进的底层逻辑：梯度流和感受野
从 CSP 到 C2f 再到 C3k2，表面上看起来是模块名字在变，底层其实在优化同一件事：梯度流的丰富度。
CSP 的核心思路是把特征图分成两半，一半走卷积，一半直接连过去，最后拼起来。这样做的目的是让梯度有短路路径可以走，缓解深层网络的梯度消失。C2f 在此基础上把"两半"变成了更有层次的分支结构，让不同分支承担不同深度的特征提取。C3k2 又加入了卷积核尺寸的可配置性。
为什么梯度流这么重要？你可以把网络想象成一个长长的传话游戏，信息从第一层传到第一百层，中间任何一层传歪了，后面的全歪。短路连接相当于给每几层配一个"直接汇报通道"，让底层的信息可以绕过中间层直达高层。信息通路的数量越多，网络能学到的东西越丰富。
另一个维度是感受野。检测任务里，你需要同时看到"局部细节"（判断这是什么）和"全局上下文"（判断它在什么环境里）。感受野太小就只能看到局部，太大就丢失细节。C3k2 通过让不同深度的层用不同尺寸的卷积核，其实是在做感受野的动态分配。
v11 的 C2PSA 注意力则是另一个思路：不是扩大感受野，而是让网络学会"看哪里"。注意力会计算每个空间位置的重要性权重，把计算资源集中在有意义的区域上。对于背景占大头的图像（比如航拍、监控），这个机制收益明显。
3.4 NMS-free 到底值不值得
这个问题我被问过很多次。我的回答是先看你部署在什么硬件上。
如果你部署在 GPU 上，NMS 可以用 CUDA 加速，耗时占比通常不到 5%，那 NMS-free 带来的收益就很有限，反而要承担精度可能下降的风险。如果你部署在 CPU 或者某些 NPU 上，NMS 是纯串行操作，耗时占比可能到 20% 甚至更高，那 NMS-free 的价值就大了。
还有一个场景是多路视频流。比如你要同时处理 16 路摄像头，这时候每路的后处理开销累加起来很可观，而且 NMS 的耗时会随着框的数量波动，导致整体帧率不稳定。这种情况下 NMS-free 的稳定性优势很关键，因为它把延迟变成了一个固定的前向计算时间。
我自己的经验是：优先用传统方案加优化过的 NMS，因为生态成熟、调参经验多；只有在延迟稳定性成为硬指标，或者硬件对 NMS 支持极差的时候，才切到 NMS-free 方案。别为了尝鲜去用，那是给自己找麻烦。
4. 面向落地的选型指南
4.1 选型的五个判断维度
选型不是选最强的，是选最合适的。我一般按这五个维度过一遍。
| 维度 | 关键问题 | 影响 |
|---|---|---|
| 任务类型 | 只做检测，还是要分割/姿态/旋转框 | 决定能否用统一 API |
| 精度需求 | 业务能接受的漏检率、误检率是多少 | 决定模型规模 |
| 延迟约束 | 端到端要在多少毫秒内完成 | 决定模型规模和部署格式 |
| 硬件平台 | GPU、CPU、边缘芯片、国产化平台 | 决定导出格式和算子兼容性 |
| 团队能力 | 有没有人能啃论文改代码 | 决定能否用非 ultralytics 系 |
这五个维度里，硬件平台是最容易被低估的一个。我见过太多方案在服务器上跑得好好的，一上边缘设备就出问题，因为注意力算子或者某些自定义算子不支持，导出的时候被工具链拒绝，或者虽然导出了但走了 fallback 路径，速度慢十倍。
所以我的建议是：在训练之前就把目标硬件确定下来，并且先用一个预训练权重跑通导出和推理的完整链路。别等模型训完了才发现部署不了，那时候返工成本极高。
4.2 不同场景的推荐组合
我把常见的几类场景整理成下面这张对照表，都是我实际做过或深度参与过的项目类型。
| 场景 | 推荐版本 | 推荐规模 | 理由 |
|---|---|---|---|
| 服务器端离线批处理 | v11 | m 或 l | 精度优先，算力充足 |
| 实时视频流（GPU） | v8 或 v11 | s 或 m | 速度精度平衡，生态成熟 |
| 边缘盒子（低功耗） | v8n 或 v11n | n | 参数量小，导出兼容性好 |
| 移动端 App | v8n | n | 量化工具链成熟 |
| 老旧遗留系统维护 | 保持 v5 | s 或 m | 能跑就别动 |
| 密集小目标（航拍等） | v11 | m 或 l，大输入尺寸 | C2PSA 对背景抑制有帮助 |
| 需要分割掩码 | v8-seg 或 v11-seg | s 或 m | 统一 API，切换成本低 |
| 极端低延迟要求 | v10 | s | NMS-free 延迟稳定 |
这里我特别想说一下输入尺寸这个参数。很多人只调模型规模，忽略输入分辨率，其实后者的影响往往更大。把输入从 640 提到 1280，小目标召回率的提升可能比换一个大两号的模型还明显，代价是计算量涨四倍。如果你的瓶颈是小目标，优先考虑提分辨率，然后才考虑换模型。
但分辨率不是想提就能提的。它受显存约束，因为显存占用大致和分辨率的平方成正比。640 到 1280 是四倍，batch size 就得相应减小，否则直接爆显存。这个权衡在做方案时必须算清楚。
4.3 硬件适配的实操细节
NVIDIA GPU是最省心的路径。导出 ONNX 再用 TensorRT 转 engine，开 FP16 精度无损的情况下速度能提升两到三倍。注意 TensorRT 的 engine 是和显卡型号、驱动版本、TensorRT 版本绑定的，换机器必须重新生成，这一点在交付的时候要在文档里写清楚，否则客户那边跑不起来会来找你。
CPU 部署首推 OpenVINO。它对 Intel 的 CPU 和核显优化很好，支持 INT8 量化，实测在 i7 上 v8n 能跑到 30 FPS 以上，够很多场景用了。导出的坑在于动态 shape，OpenVINO 对动态输入的支持不如 ONNX 完善，建议导出时指定固定的 batch 和输入尺寸。
国产化平台和 ARM 边缘设备，常见的选择是 NCNN、RKNN、昇腾的 CANN 工具链。这些工具链对注意力和自定义算子的支持普遍不完善，所以我一般会建议在这些平台上用 v8 而不是 v11，因为 v8 的结构更"传统"，算子更标准，导出成功率更高。如果非要用 v11，一定要先在目标平台上跑一遍完整的导入测试。
AMD 显卡是很多人关心的点。Linux 下可以用 ROCm 版的 PyTorch 做训练，Windows 下训练支持比较有限，通常是训练在 NVIDIA 或者云端做，推理用 DirectML 或者 ONNX Runtime 跑。这条路径是可行的，但踩坑概率明显高于 NVIDIA，建议预留调试时间。
4.4 许可证和合规这条线不能省
前面提过一次，这里再强调一下。ultralytics 从 v5 开始的所有版本都是 AGPL-3.0 协议。这个协议的核心约束是：如果你把基于它的软件作为网络服务提供，或者分发修改后的版本，你必须开源你的完整代码。
这在企业内部使用是完全没问题的，因为不涉及分发。但如果你做的是商业产品交付，或者做 SaaS 服务，就要仔细评估。ultralytics 提供商业授权，费用按项目规模算，具体要去官方渠道问。
替代路线也有：用其他协议更宽松的检测模型，或者从零自己实现一套训练框架（工作量很大）。我的经验是，在项目立项阶段就把这件事确认清楚，别做到一半才发现要重写，那才是真的坑。
5. 从零训一个自己的数据集：完整流程
5.1 环境搭建和版本对齐
环境这块我踩过的坑比技术本身还多，所以先说结论：用虚拟环境，锁死版本号，别用最新版。
Python 建议 3.9 到 3.11，3.12 之后的某些版本和 PyTorch 的兼容性有问题。PyTorch 建议用 2.0 以上的稳定版，和 CUDA 版本对应。ultralytics 直接 pip 装，但要注意它会自动拉一堆依赖，可能和你的环境冲突，所以务必在虚拟环境里做。
conda create -n yolo11 python=3.10 -y conda activate yolo11 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install ultralytics装完之后验证一下：
yolo checks这个命令会打印出你的环境信息，包括 PyTorch 版本、CUDA 是否可用、GPU 型号。如果 CUDA 显示不可用而你有显卡，八成是驱动版本不匹配，用nvidia-smi看一下驱动支持的 CUDA 版本，然后装对应的 torch。
还有一个坑是多版本共存。如果你之前装过 v8 的包，再装 v11 可能会覆盖或者冲突。建议每个项目单独一个环境，别图省事共用一个。
5.2 数据标注和格式转换
YOLO 的标注格式很简单，每张图对应一个 txt 文件，每行一个目标，格式是：
类别索引 中心点x 中心点y 宽度 高度这四个坐标都是归一化到 0 到 1的值，是相对于图像宽高的比例。比如一个框的中心在图像中心，宽高各占图像一半，那就是0 0.5 0.5 0.5 0.5。
这里有个新手最容易犯的错：把像素坐标直接写进去。我看到过好几次这样的情况，训练的时候 loss 一直不降，查了半天发现标注文件里写的是0 320 240 100 80这种像素值。所以标注完之后一定要抽查几个文件，确认数值都在 0 到 1 之间。
标注工具我常用的有几个。labelImg 最经典，操作简单，输出格式可以选 YOLO 格式，适合小规模数据集。CVAT 功能更强，支持多人协作、视频标注、自动标注，适合中大规模。Roboflow 是线上平台，能直接做增强和格式转换，但要注意数据上传的合规问题，敏感数据别往上传。
如果你手上是 COCO 格式的标注，需要转成 YOLO 格式，可以写个脚本：
import json import os from PIL import Image def coco2yolo(coco_json, img_dir, out_dir): os.makedirs(out_dir, exist_ok=True) with open(coco_json, 'r') as f: data = json.load(f) cats = {c['id']: i for i, c in enumerate(data['categories'])} images = {img['id']: img for img in data['images']} anns = {} for ann in data['annotations']: anns.setdefault(ann['image_id'], []).append(ann) for img_id, img_info in images.items(): w, h = img_info['width'], img_info['height'] fname = os.path.splitext(img_info['file_name'])[0] + '.txt' lines = [] for ann in anns.get(img_id, []): x, y, bw, bh = ann['bbox'] cx = (x + bw / 2) / w cy = (y + bh / 2) / h lines.append(f"{cats[ann['category_id']]} {cx:.6f} {cy:.6f} {bw/w:.6f} {bh/h:.6f}") with open(os.path.join(out_dir, fname), 'w') as f: f.write('\n'.join(lines)) coco2yolo('instances.json', 'images', 'labels')注意 COCO 的 bbox 格式是[左上角x, 左上角y, 宽, 高]，是像素值，转换的时候要做归一化。这个脚本我用了好多次，直接改改路径就能跑。
5.3 数据集的目录结构和配置文件
标准结构是这样的：
dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml注意images 和 labels 的目录结构必须完全镜像，图片路径是images/train/a.jpg，标注就必须是labels/train/a.txt。ultralytics 在加载的时候会做路径替换，替换规则是找路径里的最后一个images字符串换成labels，然后扩展名换成 txt。如果你的目录名里有别的 "images" 字样，可能会替换错位置，这是个隐蔽的坑。
data.yaml 是最关键的配置文件：
path: /abs/path/to/dataset train: images/train val: images/val names: 0: person 1: helmet 2: vest几个细节：path建议写绝对路径，避免相对路径带来的混乱。names的索引必须从 0 开始连续，不能跳号。如果你的类别名里有中文或者特殊字符，建议改成英文，因为我遇到过某些环境下 YAML 解析中文出问题的情况。
5.4 训练参数怎么定
我用 v11 做例子，一条基础训练命令：
yolo detect train \ model=yolo11m.pt \ data=dataset/data.yaml \ epochs=200 \ imgsz=640 \ batch=16 \ lr0=0.01 \ lrf=0.01 \ cos_lr=True \ warmup_epochs=3 \ patience=50 \ device=0 \ project=runs/train \ name=exp01我把几个关键参数的解释和我的经验值列一下。
epochs：这个要和数据集规模一起看。数据集大（几万张）的时候 100 到 300 轮就够；数据集小（几千张）的时候需要更多轮，但要注意过拟合。我一般先跑 100 轮看曲线，如果验证 loss 还在降就继续加。
batch：受显存约束。经验值是在保证不 OOM 的前提下尽量大，因为大 batch 的梯度更稳，BatchNorm 的统计也更准。但如果 batch 太大，泛化会变差，一般不建议超过 64。
lr0 和 lrf：初始学习率和最终学习率系数。lrf=0.01表示最终学习率是初始值的 1%。学习率太大会震荡不收敛，太小会收敛慢。我的经验是：从头训用 0.01，微调预训练模型用 0.001 到 0.005。
cos_lr：用余弦退火的学习率调度。相比阶梯式下降，余弦更平滑，通常在后期能拿到更好的精度。我基本都开着。
patience：早停耐心值。验证指标连续这么多轮没提升就停。设太小会提前停，设太大浪费时间。50 是个比较稳的值。
warmup_epochs：预热轮数。前几轮用很小的学习率慢慢升上去，避免一开始就把预训练权重破坏掉。用预训练权重时建议开，从零训可以设 0。
还有一个参数容易被忽略是close_mosaic。Mosaic 增强在训练后期是有害的，因为它的图像拼接会让目标尺寸分布失真。ultralytics 默认在最后 10 轮关闭 Mosaic，这个设置我一般不动。如果你发现训到后期指标突然跳变，可以看看是不是这个引起的。
5.5 训练监控和结果解读
训练启动之后，结果会保存在runs/train/exp01/下。最重要的几个文件：
results.csv：每个 epoch 的所有指标results.png：指标曲线图confusion_matrix.png：混淆矩阵weights/best.pt：验证集上最好的权重weights/last.pt：最后一个 epoch 的权重
看曲线的时候我一般关注这几件事。box_loss 和 cls_loss 是不是单调下降，如果震荡很厉害说明学习率偏大。验证集的 mAP 是不是还在涨，如果很久不涨了说明该停了。训练和验证的 gap 大不大，如果训练指标远高于验证，说明过拟合了，要加增强或者减模型。
有一次我训一个缺陷检测模型，训练 mAP 到 0.95 了，验证才 0.6。查了半天发现是数据泄漏，同一个产品的多张图片被分到了训练集和验证集。所以划分数据集的时候一定要按产品、按时间段或者按场景来分，别随机分，否则同一个目标的多张近似图片会跨集，导致指标虚高。
5.6 导出和部署的完整链路
训练完之后导出：
# 通用 ONNX yolo export model=runs/train/exp01/weights/best.pt format=onnx opset=12 simplify=True # TensorRT（需要 GPU） yolo export model=best.pt format=engine half=True device=0 # OpenVINO yolo export model=best.pt format=openvino half=True # NCNN yolo export model=best.pt format=ncnn几个坑点必须说。
opset 版本：默认可能是 17 或者更高，但很多推理框架只支持到 11 或 12。我一般显式指定 12，兼容性最好。如果目标平台很老，可能要降到 11。
dynamic 参数：默认导出是固定的 shape。如果你需要动态 batch 或者动态分辨率，要加dynamic=True。但注意动态 shape 在 TensorRT 上会降低优化空间，速度可能不如固定 shape。我一般导出两个版本，一个固定一个动态，按场景选用。
simplify：这个参数会用 onnx-simplifier 优化计算图，去掉冗余算子，通常能提升推理速度。但偶尔会引入 bug，如果你发现导出后精度掉了，先试试关掉它。
half 精度：FP16 导出能提速，但要注意溢出问题。分类分支在 FP16 下一般没问题，但如果你的模型有特别大或者特别小的数值，可能会溢出成 NaN。判断方法是导出后跑几张测试图，对比 FP32 和 FP16 的输出，如果差异超过 1% 就别用 FP16。
精度对齐验证：这是我强烈建议做的一步。导出之后，用同一批测试图分别跑 PyTorch 原模型和导出模型，对比输出的框坐标和置信度。差异应该在小数点后两位内。如果差异大，说明转换过程有问题，要逐步排查 opset、simplify、精度设置。
6. 踩坑记录与排查速查
6.1 训练阶段问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| loss 一直是 nan | 学习率太大、数据有脏样本、FP16 溢出 | 降 lr、开 AMP 检查、抽查标注 |
| loss 不降 | 标注格式错、类别索引错、数据路径错 | 可视化验证一批数据 |
| 显存 OOM | batch 太大、输入尺寸太大、模型太大 | 降 batch、开梯度累积 |
| 训练慢 | 数据加载瓶颈、没用 GPU、num_workers 太小 | 检查 GPU 利用率，调 workers |
| 验证 mAP 虚高 | 数据泄漏、类别不均衡 | 重新划分数据集、看混淆矩阵 |
| 小目标效果差 | 输入分辨率低、分配策略不适应 | 提 imgsz、检查正样本数 |
这里重点说一下"loss 不降"这个最常见的现象。我的排查顺序是固定的：先可视化几张训练图带标注，确认标注框位置对不对；再看 data.yaml 的 names 和标注文件里的类别索引能不能对上；然后确认图片路径和标注路径的镜像关系有没有错。这三个查完，九成的问题都能定位。
可视化这个动作极其重要，我见过太多人跳过这一步直接训练，然后花几天时间调参，最后发现是标注错了。ultralytics 提供了可视化脚本，或者你自己用 OpenCV 画一下也就十几行代码的事。
关于梯度累积，补充一下用法。如果你的显存只够跑 batch=4，但你想模拟 batch=16 的效果，可以设nbs=64配合小 batch，框架会自动做梯度累积。注意这个参数和 batch 是配合使用的，具体行为在不同版本里略有差异，建议看当前版本的文档确认。
6.2 部署阶段问题速查表
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| 导出报错不支持某算子 | 用了注意力或自定义算子 | 换 v8、降低 opset、手动替换算子 |
| 推理结果全空 | 预处理不一致（归一化、通道顺序） | 对齐 letterbox 和归一化参数 |
| 框位置偏移 | 输入尺寸处理不一致 | 检查 letterbox 的填充和还原逻辑 |
| TensorRT 速度没提升 | batch 太小、没用 FP16、被 fallback | 增大 batch、开 half、看 verbose 日志 |
| 换机器跑不了 engine | engine 和硬件绑定 | 每台机器重新生成 |
| 多线程推理崩 | 模型实例没做线程隔离 | 每个线程独立实例或加锁 |
预处理不一致是部署阶段第一大坑，没有之一。训练时框架会做 letterbox（保持宽高比的缩放加填充），推理时你自己写的代码如果直接 resize，坐标就全错了。letterbox 的逻辑是：先算出缩放比例，把图缩放到目标尺寸内，剩下的部分用灰色填充，然后在还原坐标的时候减去填充量再除以缩放比例。这个逻辑不难，但细节多，建议直接抄官方源码里的实现，别自己造。
还有一个坑是通道顺序和归一化。PyTorch 训练时用的是 RGB、0 到 1 归一化。如果你用 OpenCV 读图，默认是 BGR、0 到 255。忘了转换的话，模型的输出会完全乱掉，表现为检测出一堆莫名其妙的东西。这个错误特别隐蔽，因为程序不报错，就是结果不对。
6.3 几个只有踩过才知道的心得
第一个心得是先跑通全链路再做优化。我现在的习惯是：拿到新项目，先用官方预训练权重跑一遍推理，确认环境没问题；再用少量数据（几百张）训 10 轮，确认训练链路没问题；再导出到目标平台，确认部署链路没问题。这三步走完，才开始正式训练和调优。这个流程看起来很慢，但能避免"训了三天发现部署不了"这种灾难。
第二个心得是版本升级要留回退路径。从 v8 升到 v11 的时候，别直接把老代码删了。新老版本并行跑一段时间，对比指标，确认新版本确实更好再切换。数据格式虽然兼容，但某些参数名和行为是变了的，比如某些增强的默认值、某些损失项的系数。这些差异在文档里可能没写清楚，只能靠实测对比发现。
第三个心得是关注 hard example 而不是平均值。mAP 是一个平均指标，它会掩盖掉那些少数但重要的失败案例。我每次训完都会把验证集里置信度低、或者预测错的样本挑出来看，往往能发现数据标注的系统性问题。有一次我发现模型总是把戴深色安全帽的人漏掉，查数据才发现这类样本在整个数据集里只有十几张。补标了一批之后指标直接上去了。
第四个心得是推理耗时要在目标硬件上测，别信理论值。论文里的 FPS 是在特定 GPU 上、特定 batch、特定精度下测的，和你的实际场景差得远。我在一个边缘设备上实测过，理论 FLOPs 差不多的两个模型，实际推理速度差了三倍，原因是其中一个模型的算子被工具链拆得稀碎，走了很多 fallback。所以 FLOPs 只能用来做粗略筛选，最终决策必须靠实机实测。
第五个心得是数据集的质量比算法的先进程度更能决定成败。我做过一个对比，同样的 v8m，标注精细的数据集比标注粗糙的数据集 mAP 高了十个百分点以上，而换成 v11l 只能再提升一个点。所以如果你的项目效果不好，先别急着换模型，先回头看看数据。
最后分享一个我自己的小工具习惯。我会在项目目录下放一个check.py，功能很单一：随机抽 20 张训练图，把标注框画上去，再跑一遍模型推理把预测框画上去，两个结果并排显示。每次训完模型我都先跑这个脚本看一眼。它能在一分钟内告诉你模型到底学到了什么、漏了什么、多检了什么。这个习惯帮我省下的时间，比任何调参技巧都多。
