企业官网建设流程全解析

上周三凌晨两点，我盯着屏幕上第十七次跑出来的验证曲线，脑子里只有一个问题：这套跑了三年的 YOLOv8 产线检测服务，到底要不要迁到 YOLO26。

我手上这套东西最早是 2023 年搭起来的，跑过食堂餐盘识别，跑过五金件表面缺陷，中间还被拉去试过一段时间的泥石流滑坡隐患点巡检。同一套推理服务框架，前后换过四拨权重，踩过的坑能写满半本笔记。所以今年年初看到 YOLO26 的消息时，我第一反应不是兴奋，是头疼——因为对一线的人来说，"新版本"从来不等于"更好的版本"，它只等于"又要重测一遍"。

这篇东西不打算写成论文，也不会给你一个"闭眼上 v26"的结论。我想做的是把 YOLOv8、v10、v11、v12、v26 这五代模型摆到同一张桌子上，从精度、推理链路、导出友好度、训练成本、人力投入五个维度拆开看，然后告诉你在 2026 年这个时间点上，什么样的项目该迁、什么样的项目迁了就是自找麻烦。如果你正准备做一次模型迁移的决策，或者你手里有一批存量 YOLOv8 权重在跑，那这篇大概能帮你省掉至少两周的试错。文里会给出可直接抄的命令、参数对照表和排查清单，小白也能跟着走完一遍。

1. 五代同堂：先理清 YOLO26 到底改了什么

在讨论迁移之前，必须先把版本谱系理清楚。我见过太多团队在这件事上犯低级错误——把不同团队的 YOLO 实现混着聊，最后讨论出来的结论根本对不上号。

1.1 版本谱系与命名乱象

YOLO 这个系列从最早的 v1 到 v3，到后来的 v4、v5，再到 Ultralytics 接手之后做的 v8、v11、v12，以及今年新出的 v26，中间还夹着大量第三方魔改版。命名混乱到什么程度？同一个数字，不同仓库能给完全不同的网络结构。所以我在团队里立了一条规矩：任何性能讨论都必须带上前缀——哪个仓库的哪个权重文件，否则一律不采信。

从工程可维护性的角度，真正值得作为选型候选的，其实只有五条线。

这张表你先记住后处理那一列，因为它是决定你迁移工作量大小的最关键因素，比精度差异重要得多。后面第 2 章会展开讲为什么。

1.2 三个真正影响迁移的改动

YOLO26 的改动清单如果照搬官方说明，能列出十几条，但其中真正会打断你现有流水线的，我数下来只有三条。

第一条是推理阶段彻底去掉 NMS。YOLOv10 已经做过这件事，靠的是一对一分支加一致性双分配。YOLO26 走的是另一条技术路线——把回归分支做简化，让模型本身就输出不重复的框。这件事的意义在于，你的部署脚本里那一大段手写的 NMS 后处理代码，理论上可以直接删掉。对 CPU 端和边缘端来说，NMS 往往是整个推理耗时里最不可控的一块，因为它跟框的数量强相关，画面一复杂耗时就飙。

第二条是去掉 DFL 分布回归模块。YOLOv8 和 v11 的输出头里，每个坐标点不是直接回归一个值，而是回归一组分布再积分回去，这就是 DFL（Distribution Focal Loss）。它的好处是回归精度稳定，坏处是导出之后图上会多出一堆 slice、softmax、conv 之类的算子，在边缘工具链里特别容易碰到不支持的情况。YOLO26 把这块拿掉，导出的计算图会干净很多。

第三条是换掉了优化器，用了 SGD 和 Muon 类方法的混合策略，官方说法是收敛更快。同时标签分配策略也更新了，对小目标的关注度更高。这两条不改变推理链路，但会改变你的训练曲线形状，意味着你原来那套"跑 100 轮看第几轮最好"的经验，可能要重调。

提示：如果一个新版本只改训练侧，迁移风险是可控的；一旦改到推理侧的后处理和输出张量形状，就必须安排完整的回归测试。YOLO26 属于后者。

1.3 改动落到部署链路上的连锁反应

很多人评估迁移只盯着 mAP 那个数字，这是最常见的误判来源。真正要命的是链路上游的那些隐性依赖。

我举个具体例子。假设你现在的服务是这样跑的：预处理做 letterbox 缩放到 640×640，归一化到 0-1，输入模型，拿到 [1, 84, 8400] 这种形状的输出，然后自己写一段解码逻辑，把框坐标还原、做置信度过滤、做 NMS、再做类别筛选。这套代码你写了可能两年，线上跑了几个亿的请求，稳定得像块石头。

现在换成 YOLO26，输出形状大概率变成 [1, 300, 6] 这类固定条数的格式，坐标已经是原图尺度，不需要再乘缩放系数，也不需要 NMS。听起来是好事，但你的整个后处理模块要重写，同时你要重新验证：60 个框和 300 个框对下游业务逻辑有没有影响？原来靠 NMS 阈值压掉的误检，现在靠什么压？如果下游还有一套基于框数量的业务规则，那就要一起改。

还有一层是量化。免 NMS 的端到端模型对量化误差其实更敏感，因为它少了后处理这一层"兜底"。我做过一次对比，同一个检测任务，YOLOv8 在 INT8 量化后掉了大概 1.5 个点，YOLO26 同样量化配置下掉得更多一点，具体幅度跟校准集质量关系很大。所以如果你严重依赖 INT8 部署，迁移前一定要先做量化回归，别等上线了才发现。

2. 迁移决策模型：先算三笔账再动手

我见过太多"因为新版本发布了所以我们要迁移"的决策，最后基本都以半途而废告终。迁移这件事，本质是一次投入产出计算，你至少要把下面三笔账算清楚。

2.1 精度账：你的业务指标到底卡在哪

第一件事是搞清楚你现在到底缺什么。绝大多数项目的真实瓶颈根本不是模型精度。

我做过一个统计，在过去两年接触的十几个视觉项目里，只有两个是真的因为 mAP 不够而卡壳，其余的问题分别是：标注质量差、长尾类别样本太少、光照变化剧烈、推理延迟过高、误检类型集中在某几类特定缺陷。这些问题里，换模型能解决的不到一半。

具体怎么判断？给你一个很土但很有效的办法：把最近一个月的线上误判案例全部捞出来，人工分类，分成"漏检"和"误检"两大类，再往下细分成"小目标漏检""遮挡漏检""相似类误检""背景误检"。然后拿这个分布去对比模型能力。

• 如果是小目标漏检为主，YOLO26 的标签分配策略确实对小目标更友好，值得一试。
• 如果是相似类误检为主，那问题多半在特征区分度，换版本未必有用，加数据或者改类别定义更直接。
• 如果是背景误检，优先看负样本，模型层面的收益通常很小。

这个分类工作大概花你半天时间，但能帮你省掉两周的无效迁移尝试。

2.2 链路账：后处理、算子与工具链

第二笔账是链路改造量。这笔账最好量化，因为它是纯工程成本，可以估得很准。

我给团队用的估算方式是列出所有受影响的模块，然后逐个打分。下面这张表是我们内部用的简化版。

可以看到，后处理那一栏是红色的。如果你的推理服务是纯 Python 写的，改起来还算快；如果是 C++ 或者封装成动态库交给别的团队调用，那沟通成本会比编码成本高得多。

2.3 人力账：标注、调参、运维的隐性成本

第三笔账最容易被忽略，但往往是最大的那笔。

模型换了，你的调参经验就作废了一半。原来知道 lr0 设 0.01 配 batch 16 效果最好，现在优化器变了，这套经验要重新建立。我在 v8 上积累的那套"冻结主干训 10 轮再解冻"的流程，迁到 v26 上试了三次都没跑出同样效果，最后老老实实重新做了一轮学习率扫描，前后花了四天。

运维侧也一样。如果你的团队里只有一两个人熟悉这套服务，那么换模型就意味着这两个人要重新熟悉一套东西，包括新的日志格式、新的性能基线、新的故障模式。这部分成本很难用表格量化，但一定存在。

注意：不要在同一次迭代里同时换模型和换业务逻辑。这两个变量叠在一起，出问题的时候你根本分不清是谁的锅。我吃过这个亏，最后只能全部回滚重来。

2.4 一张决策表，直接对号入座

把上面三笔账合起来，我整理了一个简化决策表。你对号入座就行，不用纠结。

这张表的核心逻辑只有一个：迁移的收益必须大于链路改造成本加学习成本。如果两边打平，就不迁，因为风险是不对称的——迁移失败的代价远大于不迁移。

3. 横评实验：怎么测才不算白测

现在讲横评。这一章我想先说方法论，再说数据，因为方法错了的话，数据全是垃圾。

3.1 评测口径必须先钉死

我做对比实验有一个硬规矩：所有变量只留一个，其余全部锁死。

具体来说，这五项必须在所有版本之间完全一致：

第一是数据集。用同一份数据、同一份划分文件，连随机种子都要固定。我一般会把数据集路径和划分文件哈希值记在实验记录里，防止自己中途手滑换了文件。

第二是输入分辨率。640 就是 640，不要给某个版本偷偷开 1280。有些版本在高分辨率下的表现差异会被分辨率掩盖掉。

第三是评估脚本。全部用同一套验证代码，不要用各版本自带的 val 命令分别跑，因为不同版本的默认评估参数可能有差别，比如有没有算上 max_det 的限制、conf 阈值默认值是多少。

第四是硬件和软件栈。同一台机器、同一个驱动版本、同一个 CUDA 版本、同一个推理框架版本。我试过在不同 CUDA 版本下跑同一个 ONNX 模型，延迟差了将近 8%，这种噪声足以淹没真实差异。

第五是预热和重复次数。第一次推理一定是最慢的，因为要加载权重、分配显存、编译内核。我一般跑 50 次预热再测 200 次，取中位数而不是平均值，因为平均值容易被几个异常值拉偏。

提示：记录实验的时候，把"没做什么"也记下来。比如"本次测试未开启 FP16"、"未使用动态 batch"。这些信息在两个月后复盘时价值极高。

3.2 精度与速度的横向对照

下面这张表是我在自己那台机器上跑出来的量级参考，数据集是自建的工业缺陷集，大概一万两千张图，七个类别，其中有两个类别属于小目标。数值我做了模糊化处理，因为具体小数点后两位没有意义，你要看的是相对关系。

这里有几个点值得展开说。

YOLOv11 相对 v8 的提升是温和的。如果你的 v8 已经调得很好，v11 能给你的可能只有零点几个点的提升。我实话说，这个幅度一般不足以支撑一次完整迁移，除非你本来就要做一次大版本重构，顺手换掉。

YOLOv12 的精度确实更高，但代价很直接：注意力结构在 CPU 上非常吃力，在 GPU 上对 batch 和显存也更敏感。如果你的场景对精度有执念、同时算力充裕，它是个合理选择；但如果你要在边缘设备上跑，基本可以排除。

YOLO26 最突出的地方在 CPU 侧。这个结论跟免 NMS 和去 DFL 的改动是自洽的——少了一层后处理，少了一堆算子，CPU 上省下来的时间非常可观。我实测下来，同一个批次的任务，CPU 推理耗时大概能压到原来的六成多一点，具体数字取决于你的类别数和画面目标密度。

注意：上面这些结论是在"我的数据集、我的硬件、我的超参配置"下得到的。换一个数据集，相对排序可能变化。尤其是小目标占比很高的场景，YOLO26 的标签分配优势会更明显；反之在超大目标为主的场景，差距会缩小。

3.3 后处理与导出形态对照

这一节是整篇里最实用的部分，因为后处理差异直接决定你的部署代码怎么写。

先说 YOLOv8 和 v11 这类带 DFL 的版本。它们的原始输出通常是一个形状类似 [1, 4×16+类别数, 8400] 的张量，你需要先做一次卷积或 reshape 把 DFL 部分积分成坐标，再把 xywh 转成 xyxy，然后乘上缩放比例还原到原图，最后做 NMS。这段代码不少，而且里面有个隐含的坑：回归出来的坐标是相对于特征图网格的偏移量，不同版本的特征图步长排列顺序可能不一致，抄代码的时候如果没对齐，框会整体偏移。

YOLOv10 和 YOLO26 这类免 NMS 版本，输出通常就是 [1, 300, 6] 或者 [1, 300, 4+类别数]，前四列是原图尺度的 xyxy，第五列是置信度，后面是类别分数。省掉了 DFL 积分的步骤，也省掉了 NMS。代码量能砍掉一大半。

导出方面，差异同样明显。

我印象最深的一次踩坑，是把一个 v8 模型往国产边缘加速卡上导，工具链反复报某个 slice 算子不支持，折腾了两天最后靠改图才勉强通过。换成没有 DFL 的结构之后，同样的工具链一次就过了。所以如果你现在正被边缘工具链折磨，这可能是迁 v26 最实在的理由。

3.4 训练收敛与显存开销对照

训练侧的差异主要体现在收敛速度和显存上。

YOLO26 换了优化器之后，我观察到的现象是前期收敛更快，中后期曲线更平。理论上这是好事，但实际用起来有个副作用：原来那套"前 20 轮不动，第 20 到 80 轮提升最快"的经验失效了，模型的性能高原期更早到来，你需要把总轮数往下调，否则后半段纯属浪费电。

显存方面，因为结构简化了，同等 batch 下占用会低一些。但这不意味着你可以无脑把 batch 翻倍，因为优化器换了之后，过大的 batch 容易让收敛变得迟钝，我试过把 batch 从 16 提到 48，最后 mAP 反而低了零点几个点。稳妥的做法是先把 batch 保持原样跑一遍，确认曲线正常，再小幅上调。

另外提醒一句关于warmup 轮数。换优化器之后，warmup 阶段的行为会变。我建议前几次训练把 warmup 轮数调大一点，比如原来的三倍，让模型先稳住再放开，比一上来就用大学习率要安全得多。

4. 迁移实操：从 YOLOv8 平滑换到 YOLO26 的全过程

理论讲完，进入动手部分。这一章我按真实操作顺序写，你可以一步步跟着做。

4.1 环境准备与依赖管理

先说环境。迁移最容易翻车的地方不是模型，是环境。

我强烈建议新建一个独立环境，不要在原来的环境里直接升级。原因是 YOLO 生态的依赖耦合比较紧，尤其是 ONNX、TensorRT、OpenVINO 这几个下游库，版本冲突起来很难查。

conda create -n yolo26 python=3.11 -y conda activate yolo26 pip install -U ultralytics

如果你的机器上有多个 CUDA 版本共存，记得显式指定。我一般会在环境激活之后立刻检查一遍。

python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.version.cuda)"

关于环境搬迁，这里有个坑值得单独说一下。很多人习惯把 conda 环境目录直接复制到另一台机器上，结果发现路径全乱了。正确做法是用导出清单的方式重建。

# 导出时去掉 build 号，避免平台差异导致解析失败 conda env export --no-builds > env.yml # 在目标机器上重建 conda env create -f env.yml

如果环境里有大量 pip 安装的包，还要额外导出一份 pip 清单，因为 conda 的环境导出不一定能完整覆盖 pip 装的包。

提示：装完依赖之后立刻做一次推理冒烟测试，用一张图片跑一下预训练权重。这一步能在三分钟内暴露九成的环境问题，别等到训练跑到一半才发现。

4.2 数据集与标注的兼容处理

好消息是这部分工作量最小。YOLO 系列的文本标注格式基本通用：每行一个目标，格式是"类别索引 中心x 中心y 宽 高"，坐标全部归一化到 0 到 1。

如果你现在的数据是用 LabelImg 或者 VSCode 标注插件打的，导出的时候选 YOLO 格式，直接能用。如果是 CVAT 之类的平台，导出成 YOLO 或者 COCO 再转一下。这里提醒两个容易出错的细节。

第一个是类别索引的映射。不同版本对类别索引的处理逻辑一致，但你的数据配置文件里 names 的顺序必须和标注文件里的索引严格对应。我见过一次事故，就是有人调换了 names 列表里两项的顺序，模型训练正常、验证指标也正常，但上线之后两个类别的结果整体互换，排查了整整一天。

第二个是空标签文件。YOLO 规定纯背景图对应一个空的 txt 文件。有些转换工具会直接不生成这个文件，导致模型完全没见过纯背景样本。如果你的场景背景误检严重，检查这一点可能比换模型更有效。

数据配置文件本身很简单，顺手确认一下路径写法。

path: /data/defect train: images/train val: images/val names: 0: scratch 1: dent 2: stain 3: crack

4.3 训练脚本的改动对照表

迁移到新版本，训练脚本的改动其实很小，主要是模型标识和少量超参。下面这张对照表是我自己改的时候记下来的。

命令行版本大概是这样。

yolo detect train \ model=yolo26s.pt \ data=/data/defect/data.yaml \ epochs=80 \ imgsz=640 \ batch=16 \ device=0 \ warmup_epochs=9 \ close_mosaic=6 \ project=runs/migrate \ name=v26s_baseline

Python 版本更灵活，适合嵌到已有流水线里。

from ultralytics import YOLO model = YOLO("yolo26s.pt") results = model.train( data="/data/defect/data.yaml", epochs=80, imgsz=640, batch=16, device=0, warmup_epochs=9, close_mosaic=6, pretrained=True, seed=42, deterministic=True, )

注意seed和deterministic这两个参数。做版本对比实验的时候一定要开，否则你会被随机性折磨到怀疑人生——同一个配置跑三次能得到三个不同的结论。

4.4 迁移学习策略：全量微调还是冻结主干

这是个高频问题，我给一个实用的判断流程。

如果你的数据集规模在一万张以上，类别数跟预训练权重有较大差异，直接全量微调，不用犹豫。冻结主干在数据量充足时反而会限制模型能力。

如果你的数据集只有一两千张，或者类别跟通用数据集高度相似，那可以试冻结主干先训几十轮，让检测头先适应你的类别分布，再解冻全量微调。这样做的好处是前期不容易过拟合，坏处是总耗时更长。

如果你的数据量极小，比如几百张，那我更建议你先把标注量提上去，再考虑模型策略。几百张图的检测任务，任何模型都很难给你稳定结果。

注意：新版本的标签分配策略对小目标更敏感，这意味着如果你数据里存在大量极小的目标（比如小于 8×8 像素），最好先把 imgsz 提上去，而不是指望标签分配策略把这事解决。分辨率不足的时候，任何分配策略都无能为力。

还有一个经常被忽略的选项是知识蒸馏。如果你已经有一个调得很好的 v8 模型，可以用它作为教师模型去指导 v26 训练，让小模型学到大模型的行为。这条路我试过两次，收益不稳定，一次提升明显，一次几乎没有差别，所以我把它列为备选而不是首选。

4.5 导出 ONNX 与加速引擎的关键参数

训练完就是导出。免 NMS 版本导出时最省心的是后处理不用额外处理，但在导出参数的设置上还是有讲究。

from ultralytics import YOLO model = YOLO("runs/migrate/v26s_baseline/weights/best.pt") # 导出 ONNX model.export( format="onnx", imgsz=640, opset=17, simplify=True, dynamic=False, half=False, ) # 导出 OpenVINO，CPU 场景优先 model.export( format="openvino", imgsz=640, half=False, int8=False, )

几个参数解释一下为什么这么设。

opset=17：这是个比较稳的选择。太低有些算子表达不了，太高部分运行时还不支持。我遇到过 opset 20 导出的模型在某些推理引擎里直接加载失败的情况，退回 17 就好了。

dynamic=False：动态 batch 灵活，但会引入额外的形状计算开销，在某些引擎上还会阻止图优化。如果你的服务 batch 固定，就关掉它。需要动态的话，单独导一份。

simplify=True：做一次图简化，去掉冗余算子。这个开关在边缘部署时尤其重要，能显著降低工具链报"不支持算子"的概率。

half=False：导出时先不要开半精度。我的习惯是先用 FP32 导出、验证精度一致，确认链路没问题之后，再单独做一次 FP16 或 INT8 的量化和对比。把两件事分开做，出问题好定位。

导出之后一定要做一致性验证：拿同一张图，分别用 PyTorch 权重和导出后的模型跑一遍，比对输出。允许有小幅数值误差，但如果框位置整体偏了或者类别全错，说明导出过程有问题。

import numpy as np import onnxruntime as ort sess = ort.InferenceSession("best.onnx") inp = np.random.rand(1, 3, 640, 640).astype(np.float32) out = sess.run(None, {sess.get_inputs()[0].name: inp}) print(out[0].shape) # 通常是 (1, 300, 4+nc)

4.6 推理端对齐与端侧部署注意事项

这是整个迁移里最容易被低估的一步。训练指标好看不代表线上好用，因为预处理和后处理必须严格对齐。

预处理方面，核心是 letterbox 的实现细节。缩放到 640×640 的时候，是保持长宽比补灰边，还是直接拉伸？归一化除以 255 还是 127.5？通道顺序是 RGB 还是 BGR？这三件事只要有一样跟训练时不一致，精度就会掉，而且掉得很隐蔽——不会报错，只是指标悄悄下滑。

后处理方面，免 NMS 版本的坐标已经是原图尺度，你只需要把 letterbox 时候减掉的偏移和缩放比例逆回去。这一步比 NMS 版本简单，但仍然要仔细，因为补边偏移量的符号很容易搞错。

端侧部署还有几条经验。

第一，先测延迟再谈优化。我见过有人上来就折腾 INT8，结果发现瓶颈根本不在计算，而在前处理的内存拷贝。先用 profiler 看一遍各阶段耗时占比，再决定优化方向。

第二，batch 不是越大越好。边缘设备上 batch 增大到一定程度之后，延迟增长是非线性的，因为内存带宽会成为瓶颈。

第三，注意 CPU 侧的线程数配置。免 NMS 版本虽然快，但如果你把线程数设得过高，反而会因为线程调度开销导致延迟抖动。我在一个四核设备上试过，线程数从 4 降到 2，P99 延迟反而更稳。

第四，保留一份 FP32 版本作为对照。量化的版本上线之后如果出现精度投诉，能立刻切回 FP32 定位问题是量化引起的还是模型本身的问题。

提示：把预处理和后处理的关键参数写进配置文件，不要硬编码在代码里。迁移的时候你只需要改配置，不用改代码，出错概率会低很多。

5. 翻车现场：迁移过程中最常见的坑与排查

这一章是我这两年踩坑的汇总，按问题类型分类。如果你正在迁移过程中遇到问题，可以直接跳到对应小节。

5.1 精度掉点类问题排查

精度掉点是迁移后最常见的问题，也是排查起来最费时间的。我的排查顺序是这样的。

先看验证集指标是否也掉了。如果验证集指标正常、线上指标掉了，那问题在部署链路的预处理或后处理。如果验证集就掉了，那是训练侧的问题。

验证集掉了的话，依次检查这几个点。学习率是不是沿用了旧版本的值？新版本换了优化器，旧的学习率很可能不合适。数据增强配置是不是继承了旧版本的？不同版本对增强强度的敏感度不一样。预训练权重是不是加载成功？有些时候权重加载失败会静默降级成随机初始化，训练也能跑，但结果差很多。

线上掉了的话，优先怀疑预处理。我最常用的调试手段是：从训练集里挑一张图，把它经过线上预处理之后的张量保存下来，再跟训练时的预处理结果做逐像素比对。差异超过一定阈值就说明预处理不一致。这个方法非常直观，能省掉大量猜测。

还有一种情况是掉点幅度很小，比如只有零点几个点。这种时候先别急着改模型，跑三次不同种子的训练看看波动范围。如果波动范围本身就覆盖了这个差值，那就说明这个差异不显著，不值得投入。

5.2 导出与推理类问题排查

导出环节的报错通常比较明确，好处理。麻烦的是那种"能导出、能加载、但结果不对"的情况。

典型症状和原因对照：

我自己遇到最多的是第一条和第五条。第一条是因为免 NMS 版本的坐标处理逻辑跟带 NMS 的完全不同，照抄旧代码必错；第五条则是因为输出张量的列含义在不同版本之间有细微差别，最好打印一次原始输出，用肉眼确认列的顺序。

5.3 训练不收敛与显存类问题排查

不收敛的表现通常是损失曲线剧烈震荡，或者损失长期不下降。

先确认数据没问题。这个听着很基础，但实际排查中至少三成的不收敛问题根源在数据：标注文件里有坐标超出 0 到 1 范围的脏数据、有类别索引越界、有空文件被误当成背景样本。

数据没问题的话，看学习率。新优化器对学习率的敏感度可能更高，建议做一个小的学习率扫描，比如取 0.001、0.005、0.01、0.02 四个值，每个跑十几个轮次看趋势，不用跑完整训练。这个方法很快，通常半天就能定下来。

显存溢出的话，处理顺序是：先降 batch，再降 imgsz，最后才考虑改模型规模。因为前两者对精度的影响更可控，而换模型意味着前面的调参全白费。

还有一个容易忽略的点是数据加载的 worker 数量。worker 设太多会导致内存暴涨甚至 OOM，设太少会让 GPU 空闲等待。我一般从 4 开始调，观察 GPU 利用率，如果长期低于 80% 就往上加。

5.4 数据集与标注类问题排查

这类问题在迁移场景里经常被误判成模型问题，因为它是"迁移前就存在、迁移后被放大"的。

最常见的三种：一是类别定义模糊，同一类缺陷不同标注员的标准不一致，模型学不到稳定特征；二是小目标标注框不精确，边界框比实际目标大一圈，导致回归目标本身就带有噪声；三是长尾分布严重，少数类样本只有几十个，任何模型都学不好。

处理这三类问题的投入产出比，远高于换模型。我的建议是，在考虑迁移之前，先做一次标注质量抽检，随机抽 200 张图人工复核。如果发现错误率超过 5%，先把标注修好再说。

5.5 常见问题速查表

把上面几节整理成一张速查表，出问题的时候可以直接对照。

6. 2026 年选型指南：不同场景到底该上哪一代

最后一章给结论。我会按场景分类，你可以直接找跟自己最接近的那一行。

6.1 场景矩阵与推荐组合

快速给一个判断口径：只要你的部署环境在 CPU 或者算子支持受限的加速卡上，v26 的迁移收益最明确；如果你的服务跑在 GPU 上、精度已经够用，那迁移的性价比就很低。

6.2 保守派路线：灰度迁移三步走

如果你的生产环境不能承受任何风险，用这条路线。

第一步，离线并行验证。用同一份测试集，把 v8 和 v26 都跑一遍，输出结果做逐图比对。重点看那些两个模型判断不一致的样本，人工判定谁对。这一步能让你清楚地知道迁移到底带来的是提升还是只是变化。这批"分歧样本"往往还能反过来揭示你数据集里标注模糊的部分。

第二步，影子模式上线。线上同时跑两份模型，只让 v8 的结论生效，v26 的结果只记录不执行。跑一到两周，积累足够的对比数据，确认 v26 在真实流量下没有严重问题。

第三步，灰度切流。先切 5% 流量，观察一周，再切 30%，再全量。每一步都保留快速回滚的能力，回滚时间要控制在分钟级。

这条路线慢，但稳。我一般推荐给已经有稳定用户的项目。

6.3 激进派路线：直接切新版本的条件

如果你满足下面所有条件，可以直接切。

新项目还没有正式上线；或者项目处在重构窗口期，本来就要改推理服务；或者团队只有一两个人，沟通成本低，能快速决策；或者现有模型的痛点已经严重到影响业务，比如延迟压不下来导致用户投诉。

这几个条件同时满足的话，直接切 v26，把旧的 v8 权重留档备查就行。拖得越久，将来迁移的成本越高，因为你的代码会围绕旧模型长出更多依赖。

6.4 我自己的几条经验判断

跑了这么多次迁移，我攒下几条不太适合写进规范、但确实有用的判断。

第一条：任何迁移的收益，在纸面上都会比实际高。官方给的提升数字通常是在最优配置下测出来的，你落地之后能拿到一半就不错了。所以决策的时候把预期收益打个五折再算。

第二条：迁移真正的成本不在模型，在链路。我做过统计，一次完整迁移里，模型相关的工作大概占三成，剩下七成都在数据、部署、验证、监控上。所以评估工作量的时候，别只盯着训练。

第三条：不要为了迁移而迁移。我见过一个团队，折腾了三个月把模型从 v8 换到了当时最新的版本，指标提升了零点四个点，但期间业务需求一个都没做。这种事在技术团队里发生得比想象中多。

最后再分享一个小技巧。做版本对比的时候，我会额外准备一份"极端样本集"——专门挑那些最难的图，比如强逆光、密集重叠、极小目标、罕见缺陷。这批样本数量不多，可能就一两百张，但它们对模型差异的区分度远高于随机采样的测试集。用这批图做快速验证，半小时就能看出两个版本的水平差异，不用等完整评估跑完。

如果你现在正卡在迁移决策这一步，我的建议是先花半天时间，把前面那个"极端样本集"建起来，然后用它跑一次对比。数据出来了，答案往往就清楚了。