企业官网建设流程全解析

上周有个做工业质检的朋友来找我，说他们那条产线明年要换代，问我 2026 年上线的项目到底该押 YOLO 的哪一代。我问他现在用什么，他说 v5，跑得挺稳，但新来的实习生坚持说 v11 更强、YOLO26 更先进，团队里吵了半个月没结论。这种场景我见得太多了——YOLO 的版本号早就变成了一种社交货币，大家选型的时候盯的是"第几代"，而不是自己的场景到底卡在哪一环。

把 YOLO 从 v5 一路捋到 v11、再到 YOLO26，你会发现版本号从来没连续过，但设计哲学换过三次。每次换路线，上一代积累的调参经验就有一半作废。搞明白这三次交替背后的动因，选型这件事根本不用问别人。下面我按"每一代为什么这么改"的思路把这条线拆开，中间穿插数据标注、格式转换、训练调参、部署导出这些真正卡人的环节，最后给一张能直接对照的选型表。

1. v5 到 v11 这条线：三次设计哲学交替

很多人以为 YOLO 的演进是"每年加一点精度"，其实不是。拉长看，主线是三次哲学层面的替换：锚框从手工设计走向无锚框加动态分配、后处理从依赖 NMS 走向端到端、主干从纯卷积堆叠走向注意力与聚合结构。每一次替换都不是刷点，而是回应了上一代在真实场景里暴露出的结构性缺陷。理解这一点，比记住每个版本涨了几个点重要得多。

1.1 第一次交替：手工锚框 → 无锚框加动态标签分配

早期 v5、v7 用的是 anchor-based 路线：在每个网格上预设几组宽高模板（比如 3 组、9 个先验框），网络预测的是相对这些模板的偏移量。这套做法在 COCO 上没问题，但换到自己的数据集就会立刻遇到两个麻烦。第一，你的目标宽高比分布和 COCO 差得远，得先用 K-means 在自家数据上重新聚类锚框尺寸，也就是 AutoAnchor 那套流程；第二，遇到极端长宽比的目标（细长的裂纹、倾斜的绝缘子）或者极小目标，预设模板覆盖不到，召回率就上不去。

无锚框路线直接预测目标中心点和宽高的分布，把"先验模板"这个人为假设去掉了。配套的动态标签分配（v6 的 SimOTA/ATSS、v8 的 TAL）则更进一步——同一次训练里，正样本的挑选不是固定规则，而是根据当前预测质量和分类置信度动态加权决定。效果是训练早期的正样本更稳，后期又不会把质量差的框算进去。第一次交替的核心，就是把"人拍脑袋定的先验"换成"数据自己说话的分配"。

1.2 第二次交替：必须跑 NMS → 端到端输出

NMS 是 YOLO 的老包袱。一个正常训练好的模型，输出几千个框，得靠 NMS 按置信度排序、再按 IoU 阈值删掉重复框。问题在于：这一步的耗时和输入里的目标数量强相关，密集小目标场景下 NMS 可能吃掉 10% 到 30% 的总推理时间；IoU 阈值和置信度阈值这两个超参对结果影响很大，换个数据集就得重调；更麻烦的是某些推理框架对 NMS 里那套排序和循环算子支持不好，导出之后算子被拆散，速度反而更慢。

v10 用"一致双分配"解决这件事：训练时同时挂一个一对多头和一个一对一头，一对多头负责提供丰富梯度，一对一头负责学出唯一一个最优预测。推理时只留一对一头，直接输出最终框，不需要 NMS。YOLO26 把这条路走得更彻底，原生就是端到端结构。第二次交替的价值不在精度数字，而在于部署链路变短了——少了一个超参敏感的后处理环节，对边缘设备和异构硬件特别友好。

1.3 第三次交替：纯卷积堆叠 → 注意力与聚合结构

注意力机制进 YOLO 这件事，历史上一直不太顺。原因很实在：标准自注意力的计算量和分辨率平方相关，放在高分辨率特征图上直接跑不动；而且把注意力塞进 YOLO 这种短训练周期（几百轮）的框架里，很容易训练不稳定，前几十轮 loss 乱跳。

v11 开始用 C2PSA 这种轻量注意力做局部增强，v12 则直接以注意力为中心来设计主干，用区域注意力和重参数化 ELAN 结构来压住开销、稳住训练。再往后，v13 这类工作引入了超图聚合的思路，试图在整条流水线上做跨层信息再分配。第三次交替解决的是"卷积感受野有限、深层特征稀释"这个老问题，但代价是对训练超参和显存的要求都更高了。

1.4 每次交替都会让上一代的调参经验失效

这点特别值得提醒。v5 时代那套"mosaic 开到最后 10 轮关掉、学习率用 cosine 衰减到 0.01 倍"的经验，到了 v8 之后就只剩一半有效——因为 v8 的标签分配变了，正样本质量在训练后期本来就提升得很快，mosaic 关得早反而伤精度。anchor 相关的所有调参（锚框尺寸、匹配 IoU 阈值）在 v8 之后直接归零。NMS 相关的经验在 YOLO26 上更是完全作废。换版本的时候，先想清楚自己依赖的是哪一批经验，别把上一代的肌肉记忆原样搬过去。

2. 逐代拆解（上）：v5、v6、v7 各自解决了什么问题

这三代现在回头看，v5 是工程化的分水岭，v6 和 v7 是两条完全不同的路线实验。放在一起讲，能看清那个阶段大家在争什么。

2.1 v5 赢在工程化，不在绝对精度

v5 是 2020 年出来的，主干是带 Focus 层（后来换成 6x6 卷积）的 CSPDarknet，颈部用 PANet，头部是耦合头加锚框。单看结构，它不算最有创意的那个。但它真正做成的事是把整套训练和部署流程打包得极其顺手：数据配置文件用 yaml 写清楚就行，训练脚本一个命令跑起来，权重自动下载，训练完自动出 mAP 曲线和混淆矩阵。对绝大多数非算法岗的工程师来说，这是第一次"不用读论文也能训出能用的模型"。

v5 的调参经验里有几条到现在还有用。mosaic 增强对提升小目标召回特别有效，但训练末期一定要关掉，否则模型会习惯拼接图里的目标尺度分布，在真实单图上框不准。letterbox 保持长宽比这个细节看似小，实际直接影响推理时坐标反算的准确性，很多人自己写推理脚本时忘了反算 padding，结果框整体偏移。还有AutoAnchor这个功能，换数据集时先跑一遍重聚类，能省掉不少调锚框的时间。

2.2 v6 的 RepVGG 重参数化与工业诉求

v6 是美团做的，出发点非常工业：推理时延和部署友好度优先。它把主干设计成 RepVGG 风格——训练时用带残差的多分支结构方便优化，推理前把多分支等价融合成单个 3x3 卷积。这样做的好处是训练收敛快、推理结构干净，对算子支持不完整的推理框架特别友好。

头部上 v6 用了高效解耦头，分类和回归分支拆开，各自走几条卷积。这个改动后来被 v8、v11 全部继承，说明方向是对的。v6 的标签分配用的是 ATSS 加 SimOTA 的组合，属于动态分配的早期实践。如果你手上有国产推理芯片或者 DSP 类平台，v6 的那套重参数化结构在算子兼容性上往往比后续版本更省心，这是我实际踩过之后才体会到的。

2.3 v7 的 E-ELAN 与辅助头

v7 是 2022 年 WongKinYiu 那批人做的，核心创新有两个。一个是E-ELAN，在 ELAN 结构基础上扩展基数（cardinality）、打乱合并路径，让不同分支学到的特征更互补，同时不破坏原始梯度路径。另一个是辅助头加引导式标签分配——训练时在中间层挂一个辅助检测头，先让它学出比较粗的预测，再用这个预测去引导主头的正样本选择，形成一种由粗到细的监督。

v7 还提出了针对拼接型结构的模型缩放策略，简单说就是"深度和宽度不能各缩各的，得一起考虑通道拼接"。这套思路在当年把 COCO 上的精度推到了同时期同量级的最优，但代价是结构复杂度上去了，自己改网络的时候很容易把通道对齐关系搞错导致训练直接不收敛。我的建议是，如果你想改 v7 的主干，改完先跑一个极小的子集（比如 200 张图跑 20 轮），确认 loss 能正常下降再上全量数据。

2.4 这三代共同的锚框依赖

v5、v6、v7 里，v6 已经是锚框无关的，但 v5 和 v7 都依赖锚框。这一点在选型时经常被忽略：如果你的数据集里目标尺寸分布很集中（比如全是同一种零件），锚框不是问题；但如果目标尺度跨度极大，从十几像素到上千像素都有，锚框路线的召回率天花板会比无锚框路线低。这不是理论推断，我在一个遥感小目标项目上实测过，同样的数据、同样的训练轮数，切到 v8 之后小目标召回涨了明显一截，当时的第一反应是"数据没变，凭什么"，后来才理解是标签分配机制的差异带来的。

3. 逐代拆解（下）：v8、v9、v10、v11 的关键跃迁

这四代是现在绝大多数人真正在用的，每一代都有明确的技术主线。

3.1 v8：C2f、TAL、DFL 三件事一起上

v8 在 2023 年初发布，把三件事同时定下来了：C2f 模块（在 CSP 基础上增加跨层连接分支，特征复用更充分）、TAL 任务对齐分配（分类和回归的匹配程度一起参与正样本打分）、DFL 分布焦点损失（把框回归从"预测一个确定值"变成"预测一组离散区间的概率分布再求期望"）。

DFL 这个改动特别值得理解。传统回归用 IoU 系列损失直接监督四个坐标值，边界附近的梯度是不够细腻的。DFL 让网络对每个边界学一个分布，然后加权求期望得到最终坐标，等于把"这条边到底在哪"这件事从点估计变成了分布估计。实际效果是框的边界更贴合目标边缘，尤其是遮挡和非刚性形变场景。代价是导出模型时多了一层积分运算，某些推理框架需要额外适配，这是很多人导出 ONNX 之后发现多了几个节点的原因。

3.2 v9：梯度信息瓶颈与 PGI、GELAN

v9 在 2024 年初出现，切入角度挺有意思：它认为深层网络在下采样过程中，原始图像里的细节信息会不断稀释，导致反向传播时梯度携带的监督信号也跟着衰减。针对这个"信息瓶颈"，它提了两个东西——GELAN做特征聚合，PGI 可编程梯度信息在训练时额外挂一条可逆分支来保住信息流，推理时这条分支可以裁掉。

v9 的思路很漂亮，但落到实操上有两点要注意。一是它的可逆分支对显存要求会高一些，小显存卡上训练得把 batch 调小；二是推理结构裁掉分支之后，某些导出路径需要确认融合是否彻底。如果你的场景对精度要求高、又有足够的训练资源，v9 值得试；如果是显存吃紧的边缘项目，其实性价比不一定比 v8 高。

3.3 v10：一致双分配怎么做到免 NMS

v10 的核心就是前面提过的免 NMS。除此之外它还有两个工程性的设计值得说：秩引导的模块设计——发现在网络某个阶段特征冗余度高，就在那里换用部分自注意力模块来提升表达力，其他地方继续用卷积保持速度；以及大核深度卷积的使用，用大卷积核扩大感受野而不显著增加计算量。

免 NMS 带来的直接好处是推理时延变得可预测。带 NMS 的模型，同一张图里目标数从 5 个涨到 200 个，后处理耗时可能翻好几倍，这对有硬实时要求的产线是致命的。切到 v10 之后，时延波动明显收敛。这是我推荐 v10 给实时性敏感项目的唯一理由，精度上它和前代互有胜负。

3.4 v11：C3k2 与 C2PSA，以及 OBB 任务的补齐

v11 是 Ultralytics 在 2024 年下半年推的，官方命名其实叫 YOLO11，不带"v"。结构上把 C2f 换成了C3k2（内部卷积核尺寸可配置的轻量化 CSP 变体），在主干和颈部的末端加了C2PSA做注意力增强。整体在同精度下参数和计算量都比 v8 更低，这是它最实在的价值。

另外一个容易被低估的点是任务覆盖。v11 在同一个框架里把检测、实例分割、姿态估计、分类、旋转框 OBB全打通了，接口统一。如果你做的是遥感或者航拍，目标是任意角度的，OBB 任务直接开箱可用，不用再去找第三方魔改仓库。我做过一个斜向排列的货架识别项目，用 OBB 之后框的贴合度比水平框好太多，后处理里算方向也方便。

4. v12、v13、YOLO26：2026 年该不该跟新版本

4.1 先厘清一件事：这些不是同一条官方线

这里必须说清楚，不然选型会乱。Ultralytics 官方维护的线是 v5（早期）／v8／v11／YOLO26 这一串；v6 是美团、v7 是独立研究者、v9 和 v10 来自不同团队、v12 和 v13 是学术圈的工作。社区习惯用"v+数字"统一叫，但它们的代码库、配置文件格式、训练接口都不一样。跟着 v 数字走，很容易掉进"这个仓库的配置文件在另一个仓库里跑不通"的坑。

4.2 YOLO26 的几个改动点

YOLO26 是 Ultralytics 在 2025 年发布的，面向的方向很明确：边缘和 CPU 部署。几个关键改动：原生端到端免 NMS，导出链路更短；去掉了 DFL 模块，简化回归头，让量化更友好；ProgLoss做渐进式损失平衡，缓解训练早期的梯度冲突；STAL 小目标感知标签分配，专门优化小目标的正样本供给；还有一个叫MuSGD的优化器，借鉴了大模型训练里的一些思路，混合了传统随机梯度下降和更新式优化方法。

对实际项目来说，最值得关注的是"去掉 DFL"和"CPU 推理提速"这两点。去掉 DFL 意味着导出的模型图更干净，做 INT8 量化的精度损失更小，这对没有 GPU 的现场设备是实打实的收益。至于小目标分配策略，如果你的场景里目标像素面积普遍小于 32x32，值得专门测一轮。

4.3 判断要不要跟新版的三条标准

我不建议无脑追新，也不建议死守 v5。用这三条筛一下：

• 现有模型有没有明确的、可量化的短板。如果只是"觉得不够新"，那就不换。精度、时延、显存、部署兼容性，四项里必须有至少一项卡住了业务。
• 你的部署链路能不能吃下新结构。新版本往往引入新算子（注意力、分布式回归、端到端头），如果目标平台的推理框架不支持，改造成本可能超过收益。
• 团队有没有能力复现和改进。v8 之后的版本训练配置项变多，出问题时排查成本更高。没有算法人手的话，选择社区资料最厚的那一代更稳妥。

5. 2026 选型决策：按四个维度打分

5.1 四个维度的具体含义

我把选型拆成四个维度：算力预算（训练和推理分别有什么硬件）、时延约束（是硬实时还是准实时）、任务类型（纯检测还是需要分割、姿态、旋转框、跟踪）、团队基础（有没有算法同学，能不能改代码）。

四个维度里，最容易被高估的是"精度"。实际项目里，一个 mAP 高 2 个点的模型，如果推理时延翻倍或者导出失败，等于零价值。最容易被低估的是"团队基础"——一个能跑通的次优方案，比一个跑不通的最优方案值钱一百倍。

5.2 一张可以对照的决策表

下表是各代的定位参考，精度数字是公开基准上的量级，具体以官方仓库为准，不要拿它当绝对依据：

5.3 三类典型场景的具体建议

产线实时质检。这类场景的第一约束永远是时延稳定性和误报率。我的建议是 v8 或 v10 起步：v8 生态最全、遇到问题好搜；如果产线上单图目标数波动大（比如有的图只有 3 个缺陷、有的有 200 个），直接上 v10 或 YOLO26，免 NMS 带来的时延可预测性比多几个点精度重要。

边缘盒子或国产平台部署。先把导出格式和目标平台的算子支持表核对一遍，再选版本。经验上 v6 的重参数化结构和 YOLO26 的简化回归头在算子兼容性上表现更好。如果平台对注意力算子支持不佳，v11 之后的版本要谨慎。

需要分割、姿态或旋转框。直接选 v11，它在同一个框架里把这些任务都覆盖了，接口一致，切换成本低。自己拿 v8 去拼分割头，踩坑时间够你把 v11 的项目跑完三轮了。

5.4 课程设计和入门练习怎么选

如果你是在做课程设计或者刚入门，答案很明确：v8 或 v11，不要碰 v12、v13。原因有三条。第一，文档和社区问答最厚，报错搜得到；第二，配置文件格式稳定，网上抄的配置能用；第三，训练脚本封装好，一行命令跑起来，能把精力放在数据准备和结果分析上。我见过太多人一上手就选了某个前沿版本，结果卡在环境配置上两周，最后交作业前一天还在装依赖。

6. 数据链路：标注、格式转换与长尾场景

模型选得再好，数据链路做错了照样白搭。这一节讲的全是实操里最容易出问题的环节。

6.1 labelimg 打标之后，那个 txt 里到底是什么

用 labelimg 切到 YOLO 格式导出后，每一张图对应一个同名 txt，每行一个目标，格式是：

类别索引 中心点x 中心点y 宽 高

后面四个值全部是归一化到 0 到 1 之间的相对值，也就是除以了图像宽高。这里有两个高频错误。第一，行尾多一个空格或者用逗号分隔，训练时报解析错误——必须是空格分隔。第二，类别索引从 0 开始，如果 labelimg 的类别列表顺序和你训练配置里的 names 顺序不一致，模型会学到完全错误的标签映射。改完类别列表一定要回头检查一遍所有 txt，这个错误在训练 loss 上是看不出来的，只会表现为精度上不去。

6.2 YOLO 转 COCO 格式的字段对应关系

有些评估工具和部署框架只吃 COCO 格式，转换时要对上这几个字段：YOLO 的归一化中心点宽高，要反算成 COCO 的绝对坐标[x_min, y_min, width, height]；COCO 的category_id通常从 1 开始，而 YOLO 从 0 开始，差一就会全错；image_id必须和 images 列表里的 id 严格对应，不能只是文件名。转换脚本建议自己写一遍而不是直接找现成的，因为每个数据集的目录结构都不一样，现成脚本里的路径假设往往不成立。

6.3 MOT16 转 YOLO 时的那几个坑

做多目标跟踪时经常要把 MOT16 这类跟踪数据集转成 YOLO 检测格式。几个必须处理的点：MOT 标注里的框可能是浮点数且可能超出图像边界，转换时要裁剪到图像范围内；visibility和class字段的过滤规则要明确，行人检测一般只保留 class 为 1 的、且 visibility 高于某个阈值的框；同一帧里可能存在被标记为忽略区域的目标，这些不能进训练集，否则会教模型学错。另外 MOT 是逐帧标注的，抽帧训练时要记得同步抽标注，别只抽图。

6.4 泥石流、滑坡这类长尾场景的数据组织

这类场景的特点极度鲜明：正样本稀少、类内差异极大、背景干扰复杂。我参与过一个类似的项目，两千多张图里真正的灾害样本只有一百多张。这种情况下有几条经验值得分享。

不要做激进的数据增强来"造样本"。旋转、翻转可以，但颜色抖动和随机裁剪要克制，因为灾害区域的颜色和纹理本身就是判别特征，改过头反而引入噪声。负样本要专门收集——把容易误报的场景（比如裸露的岩壁、堆积的建筑废料）单独作为背景图放进去，比单纯堆正样本有效。训练时把 mosaic 的概率调低一些，拼接图会让小范围的灾害特征被稀释。最后，评估指标不能只看 mAP，要单独看召回率和误报率，这类场景漏报的代价远高于误报。

7. 训练与部署：损失函数、显存和导出格式

7.1 从预训练模型到自己的数据集

流程本身不复杂：下载官方预训练权重，改数据配置文件里的路径和类别数，指定模型结构配置，然后跑训练脚本。真正让人翻车的是细节。

预训练权重必须和模型结构完全对应。v8 的权重不能喂给 v11 的模型，哪怕都叫 "n" 尺度。数据配置里的nc（类别数）改了之后，检测头的输出通道要跟着变，框架一般会自动处理，但如果你是自己拼的网络，忘了改这一层，报错信息会非常难懂。另外，训练前一定先用十几张图跑一个 epoch 验证整条链路，确认能读数据、能反算坐标、损失在下降，再上全量。直接拿全量数据开跑然后发现路径写错，浪费的是几小时。

7.2 损失函数三件套：分类、框回归、DFL

当前主流的检测损失是三块相加：分类损失（通常用二值交叉熵或变体）、框回归损失（IoU 系列，CIoU、SIoU 等）、分布焦点损失（v8 之后引入，v26 又去掉）。

理解这三块的作用，调参时才知道该动谁。分类损失负责"这是什么"，如果模型能定位但类别总是混淆，动的是分类损失相关的权重或者检查标签质量。框回归损失负责"框得准不准"，如果框整体偏大偏小，先检查标注质量再看损失权重。DFL 负责边界精细度，如果大目标框得很准但小目标边界发虚，DFL 相关的设置值得关注。

有一个常见误区是把损失权重调来调去。实际上在标注质量过关的前提下，默认权重通常已经接近最优，收益远不如多标 500 张图。我曾经花了两天调损失权重涨了 0.3 个点，后来补了一批难例数据直接涨了 4 个点。

7.3 显存不够时的降级路径

按这个顺序降，别乱来：

1. 降 batch size。最直接，但降到 1 或 2 之后训练会不稳定，此时要同步降学习率。
2. 降输入分辨率。从 640 降到 512 或 416，显存占用按面积比例下降，代价是小目标精度损失明显。
3. 开混合精度。大部分框架支持自动混合精度，显存能省三成左右，精度损失很小，性价比最高。
4. 换更小的模型尺度。从 l 换到 s 甚至 n，这是最后一步，因为精度掉得最多。
5. 梯度累积。用小 batch 模拟大 batch，代价是训练变慢，但训练稳定性保住了。

顺序上我建议先试第 3 条，混合精度是白捡的显存。第 1 条和第 5 条配合用，别单独降 batch。

7.4 导出格式怎么选

导出时最常见的坑是输入尺寸写错。导出脚本里的输入尺寸必须和训练时一致，写成 640x640 结果实际训练是 640x480，导出的模型跑出来框全是偏的。另外导出后一定用同一张测试图分别跑原始模型和导出模型，逐框对比坐标，差异应该在误差范围内，超过几个像素就说明某个算子转换出了问题。

7.5 AMD 显卡、Atlas 与 Windows GUI 集成

AMD 显卡跑 YOLO。现实情况是这条路能走通但不算顺畅。可行的方案是走 ONNX 加厂商的推理运行时，或者用基于 ROCm 的 PyTorch 版本。要注意的是部分自定义算子在 ROCm 上实现不全，导出 ONNX 时可能报错，这时候要么改小算子要么退回标准卷积结构。训练环节在 AMD 卡上比推理更受限，我的建议是训练用云端 GPU，推理部署再考虑本地 AMD 卡。

Atlas 等国产平台部署。核心工作是模型转换加算子适配。步骤一般是：PyTorch 导出 ONNX、用平台工具做模型转换（可能包含量化）、写推理后处理代码、做精度对齐验证。精度对齐这一步千万别省，量化之后 mAP 掉 1 到 3 个点是常见现象，掉太多说明某些层的量化策略需要调整。

Windows GUI 集成。如果你要把 YOLO 塞进一个带界面的 Windows 程序，推荐路径是用 Python 写推理模块，用 PyQt 或类似框架做界面，两者通过信号槽或者队列通信，把推理放在独立线程里避免界面卡死。别在主线程里直接调推理，一帧几百毫秒，用户点按钮会毫无反应。打包成 exe 的时候注意把模型文件和依赖库路径处理好，用相对路径加sys._MEIPASS兼容，否则在别人机器上会找不到模型。

8. 模块缝合与改进：值得动的三处和不该动的三处

8.1 值得动的三处

第一，数据增强管线。这是性价比最高的改动。针对你的场景加一个定制增强（比如针对小目标降低 mosaic 概率、针对旋转目标加特定角度的旋转），往往比改网络结构涨点更快。

第二，损失函数的惩罚项。比如你的目标是细长形状，IoU 系列损失对细长框不敏感，换成对长宽比更敏感的变体通常有收益。

第三，颈部结构。在特征融合部分加一条跨层连接或者换个融合方式，改动量小，风险可控，对多尺度目标的收益比较稳定。

8.2 不该动的三处

第一，主干的核心下采样倍数。改这个会牵动所有特征图尺寸的匹配关系，一改就是一串错误，而且收益通常不明显。

第二，检测头的输出通道数。这是和类别数、DFL 区间数强绑定的，改错直接训不起来，而且报错信息往往指向别处，排查成本极高。

第三，随便往主干里塞注意力模块。注意力不是免费的，加进去之后参数和时延都会涨，而且在短训练周期下很容易不稳定。如果要加，先在小数据上验证 loss 曲线是否平稳，再上全量。

顺带说一句"缝合"这件事的评估标准。很多人改完之后只在验证集上跑一次，看到涨了 0.5 个点就发朋友圈。正确做法是固定随机种子跑三次取平均，对比基线也要跑三次，因为 YOLO 的训练本身有随机性，单次结果的波动经常就有 0.5 个点。

8.3 多目标跟踪的指标怎么拿到

做跟踪的时候，检测指标（mAP）是不够的，还要看跟踪指标：MOTA综合反映漏检、误检和身份切换；IDF1更侧重身份保持的正确性；IDs直接数身份切换次数。拿到这些指标的标准流程是：用检测器逐帧输出检测框，喂给跟踪器（ByteTrack、OC-SORT 之类），输出 MOT 格式的结果文件，再用官方评估脚本对标注算指标。

实操里最容易出问题的是检测结果和跟踪器的输入格式不匹配。跟踪器通常要求[x_min, y_min, w, h, score]的绝对坐标，而 YOLO 输出的是归一化中心点格式，中间少了一步反算就会全乱。另外帧序必须严格对齐，中间有丢帧要显式处理，否则跟踪器的运动模型会算错。

8.4 分割求圆度这类任务的处理技巧

用实例分割求目标圆度，思路是拿到分割掩码之后算面积和周长的比值。公式是4π × 面积 / 周长²，完全圆形为 1，越不规则越接近 0。这里有几个坑。

掩码的边界是像素级的锯齿状，直接算周长会偏大，导致圆度系统性偏低。解决办法是先对掩码做形态学平滑，或者用亚像素的边缘拟合再算周长。另外如果目标有孔洞，面积计算要不要把孔洞减掉，取决于你的业务定义，这一点必须和需求方确认清楚。还有，小目标的掩码只有几十个像素，周长估计的误差占比很大，这类目标的圆度值可信度不高，最好设一个面积下限，低于这个值不输出圆度结论。

9. 我踩过的几个坑

最后分享几个具体到能直接避开的坑。

关于环境配置，我强烈建议用独立的虚拟环境，别在系统 Python 里装。YOLO 各版本对 PyTorch 和 CUDA 的版本要求不一致，混装之后最常见的现象是训练跑起来了但推理报算子不存在。装完之后跑一次官方的验证脚本，确认能加载权重、能推理、能算指标，再动自己的数据。

关于测试图片的选择，很多人习惯拿训练集里的图去测，看到框得准就以为成功了。一定要留一批完全没参与训练的图，而且这批图要覆盖各种光照、角度、遮挡情况。我在一个项目里就是因为测试图全是白天拍的，上线后夜间误报率飙升。

关于一键部署脚本，这类脚本确实能省事，但用之前先看清楚它在系统里装了什么、装到哪。有些脚本会改系统的环境变量、覆盖已有的库版本。生产环境上跑之前，先在干净的容器里验证一遍。

关于模型文件管理，训练过程中会产生一堆权重（last、best、每个 epoch 的），一定要明确定义"哪个是上线版本"。我的做法是只保留 best 和最后一次，其余删掉，并且在文件名里带日期和数据集版本号，避免半年后分不清哪个权重对应哪批数据。

关于插入模块做实验，建议每次只改一处，改完记录配置和结果。同时改三处然后发现精度涨了，你根本不知道是哪一处起的作用，后续也没法复现。

至于具体选哪一代，回到最开始那个朋友的问题。他们产线单图目标数波动大、时延要求硬、团队没有专职算法同学，我给的方案是先在 v8 上把数据和流程跑通，同时并行测一轮 YOLO26 的导出和时延表现，哪个满足产线指标用哪个。选型这件事，先把自己的约束条件写清楚，答案基本就浮出来了。