1. 为什么放着现成的Ultralytics权重不用非要绕到MMYOLO生态里这是标题后面最核心的问题。很多人一听到“yolov8适配mmyolo”第一反应都是不都是YOLOv8吗训练完的.pt直接导成ONNX不是更省事为什么要多此一举。说实话如果只是做一个快速验证、跑个demo确实没必要绕。但这次适配的目标是把YOLOv8模型落到某无人机厂商AI算力开放平台的能力上而这个平台的工具链和示例工程里大量参照的是OpenMMLab体系的模型定义方式。也就是说官方示例工程的backbone、neck、head的组装逻辑跟MMYOLO前向计算图是同一套结构而Ultralytics家的检测模型是由yaml在运行时动态拼装起来的导出计算图之后模型内部的模块命名、张量流转顺序和平台工具链的静态模型分析器期望的并不完全一致。结果就是直接用Ultralytics转出来的ONNX也能跑但后续每一步都要做额外适配中间层的feature输出、后处理的裁剪点、量化时某些算子会被回退成FP32性能和可控性都会打折扣。把权重切到MMYOLO还有几个实际好处。一是config即结构改网络像改配置一样清晰比如要换检测头、插入注意力、调整neck的feature融合策略直接改config就行不需要去动一大坨训练代码二是MMDetection/MMYOLO生态里有大量已经写好的检测头实现和训练流程工具中期如果要验证多个模型变体在同一个训练/导出流程里做对比会顺畅很多三是社区里围绕MM系列写的部署脚本、ONNX工具链适配案例相对完整遇到算子的坑基本都能搜到相似处理。但这不等于说任何场景都值得绕一圈。如果项目目标是“直接用官方预训练权重加简单后处理跑通即可”不经常改模型结构也不涉及平台工具链的深度定制那我建议直接省掉MMYOLO这一步Ultralytics导出ONNX接平台工具链完全够用。适配本身有成本权重映射、config对齐、算子回归都要时间得先想清楚投入值不值。这里可以给出一个比较务实的判断标准如果后续准备在无人机端侧做小目标优化、加检测头分支、做多尺度融合这类模型结构层面的事情建议从一开始就在MMYOLO里训练和迭代如果只是把现成模型挪到平台上那“绕一圈”的收益很小直接导出反而少踩很多坑。这次之所以选择适配路线是因为业务确实需要把检测头做裁剪、在板端单独做后处理同时还要对比不同neck结构的精度MMYOLO这套以模块组装为核心的生态会省掉大量重复工作。2. 权重搬迁的关键两套框架的state_dict映射与config对齐2.1 两个生态的基础差异要搞清楚Ultralytics的YOLOv8在结构上并不复杂但它的模型是动态构建的用yaml描述层序列运行时通过解析器一层层拼出来。训练产出的.pt文件其实是一个大字典里面除了model.state_dict()还塞了epoch、optimizer、ema权重、anchors各种训练状态。MMYOLO这边不一样模型结构完全由Python config文件声明加载权重时直接读state_dict两者天然就不是一个体系。最直观的差异体现在权重键名上。Ultralytics里卷积层的权重通常是model.0.conv.weight、model.0.bn.weight这种扁平编号MMYOLO里则是backbone.stem.conv.conv.weight、backbone.stem.bn.weight这类带语义的路径。编号映射还好理解麻烦的是有些层在Ultralytics里是合在一起的到MMYOLO里被拆成了两段或者反过来。比如YOLOv8的C2f模块在Ultralytics里表现为一个带有多个子模块的结构在MMYOLO里则是更明确的split、bottleneck堆叠结构组织方式不完全一致。所以不要在“改文件后缀”这个层面去想问题。把.pt改名成.pth在torch.load的时候大概率也能打开但加载到MMYOLO的模型里键名对不上直接报错光是debug键匹配就要浪费大半天。2.2 映射脚本怎么写才能一次过实际做的时候我建议先把两边结构画出来确定层顺序再写映射。YOLOv8的结构主要是主干、neck和检测头三大部分两边都是这个逻辑但路径组织不同。我当时整理了一个粗糙的顺序表Ultralytics的model.0到model.9大体对应主干model.10开始往上采样进入neck最后三个检测头由专门的Detect模块输出。MMYOLO的命名则把prefix分成了backbone、neck、head三段。映射脚本的核心就是写一张从旧key到新key的对应表。实际操作可以这样先加载Ultralytics的ckpt打印所有key再实例化MMYOLO的对应model打印MMYOLO这边的全部key然后逐段匹配。匹配的粒度不一定是整个key因为很多公用的卷积块路径相似可以用一个规则引擎去处理比如旧的model.{i}.{j}根据i的值映射到backbone还是neck再在段内匹配layer index。这里说几个容易忽略的点。第一Ultralytics的ckpt里有model字段和ema字段加载时优先取哪个要看训练配置别无脑取model有些训练流程里ema的精度反而更好第二MobileNet这类替换backbone的变体映射表完全不一样不要复用同一套规则第三映射完成后不是直接用了还要对同一张测试图分别用两个框架forward一遍对比中间层的输出分布漂移超过千分之一就要回头检查映射是不是有错位。还有一个小经验如果只是要验证MMYOLO的yolov8结构能不能训练收敛、精度大概在什么水平其实不用自己转权重。MMYOLO官方提供了YOLOv8的config和基于COCO预训练的权重直接加载那个pth就够了。你自己训出来的权重再转过去更多是为了保住业务数据上的mAP而不是为了跑通demo。2.3 config文件里的几个隐蔽坑MMYOLO的config长而繁琐初看容易懵但它绝大多数字段都有默认值。真正需要对齐的是这几处一是输入尺寸和anchor相关配置。YOLOv8是anchor-freeMMYOLO的head里也要对应配置比如b box_coder的类型、prior_generator的scaling ratio、featmap_strides是否设成8/16/32。如果在config里保留了某些anchor-based的默认参数训练没问题但导出后特征解码逻辑跟Ultralytics不一致板端出来的框位置会有系统性偏移。二是数据预处理pipeline的对齐。Ultralytics默认的BGR/RGB通道顺序、归一化系数、letterbox填充方式和MMYOLO的pipeline不一样。训练期影响不明显部署期就是灾难同样的图两个框架预处理出来的输入差一点点推理结果就会差几个像素甚至漏检。我在适配时专门写了一个小脚本把同一张图分别喂给两个框架对比预处理之后张量的均值和方差直到差值小于1e-6才继续往下走。三是head的回归分支配置。YOLOv8的检测头输出是4个回归量加类别概率DFL这类细节如果MMYOLO版本里没对齐导出后输出维度和语义都会偏。最好的验证办法是加载权重后直接跑一下验证集的mAP看是否跟Ultralytics结果一致。这一步过了权重搬迁才算真正完成后面平台适配才有意义。3. 在AI算力开放平台上跑通模型从pth到可部署engine的完整链路3.1 导出ONNX的版本与动态输入选择权重迁移完成之后下一步是把训练好的模型从Python环境搬进平台工具链。大多数AI算力平台的转换链路是PyTorch模型先转ONNX再由平台SDK转成自己的中间表示最后量化、编成可部署的engine。这一步看着简单其实不少时间都耗在导出的细节上。ONNX导出的第一个选择是opset版本。不要盲目追新。市面上很多工具链对opset的支持是滞后的新版本里某些融合优化反而会让平台解析器解不开算子。我的经验是先用opset 12或13做基准如果遇到算子不支持再逐个排查是哪个节点导致的能不升级就不升级。还有导出时不要打开do_constant_folding的完全模式某些折叠逻辑会把BN层直接融合成conv的bias看起来推理快了但后续量化受保护节点时容易出问题。第二个选择是输入shape要不要动态。平台这边通常是固定分辨率的固定height、width会让中间层的shape全部静态化编译器优化空间大很多动态shape虽然灵活但很多板端工具链对动态维度的支持并不好轻则显存分配策略保守导致性能下降重则某些算子直接不支持。无人机AI算力平台上一般跑640x640居多部分场景会用640x384这种细长分辨率建议把这些固定分辨率直接写进导出配置不做动态维。第三个点是模型里如果带训练时的辅助分支导出前要裁剪干净。只在.train()模式下出现的路由、归一化统计分支导到ONNX里就是冗余子图平台工具链会当成普通算子解析白白增加模型体积。导出前用.eval()且把detach处理好再检查一遍输出节点数量。3.2 算子兼容性排查ONNX能导出不等于平台能解析。我这次适配在平台工具链上遇到的第一个拦路虎就是SiLU激活函数。YOLOv8默认用的SiLU在PyTorch里一个算子就完事但部分平台的底层算子库没有直接的SiLU转换器把x * sigmoid(x)拆成乘法、sigmoid、再加一堆图节点性能明显下降。排查方法不复杂用profiler逐层看耗时发现下采样附近多个层都比预期慢再对比onnx中间IR里的节点类型基本就定位到了。排查算子兼容有一个比较顺的路径。先用平台SDK自带的静态分析工具跑一遍转换日志看有哪些Warning和Error然后盯着日志里标注为“fallback”或“refp”的算子这些是没能直接映射到硬件算子的部分量化时往往也会被跳过或被回退成FP32。逐个去核对这些回退算子是不是都在关键路径上如果关键层有回退优先通过改模型结构绕开比如把SiLU临时换成ReLU做验证看精度影响能不能接受能接受就直接换掉省去后续一堆麻烦。还有一个容易忽略的模型里的nn.Upsample如果用modenearest还好如果用双线性上采样在部分工具链上会翻译成一组分解算子内存带宽占用很高。对无人机航拍类的目标检测任务neck上采样用nearest或换成learned upsample层精度影响通常不大但端侧推理速度能快不少。这个取舍值得在适配前做一轮AB测试。3.3 量化校准不能随便采样板端AI推理基本都要走int8不然帧率不够。量化这一步的坑往往不在工具本身而在校准数据。要先理解校准在干什么int8虽然比fp16快但它需要统计每个激活值的分布范围再用这个范围把float映射到8位整数。校准集选得偏了模型就会在“没见过的分布”上硬压缩掉点惨不忍睹。我在第一次跑量化的时候图省事直接从公开数据集里抽了200张做校准结果模型落地后对航拍视角的检测AP直接掉了5个点后来换成业务采集的航拍样本重新校准掉点马上回到1个点以内。校准集的正确做法是从实际部署环境中采一批代表性样本覆盖不同高度、不同光照、不同目标密度数量在300到500张就足够不要贪多。而且校准集的特征分布要尽量靠近训练集主体数据的分布。比如训练集里白天样本占80%校准集就别搞成50%夜间否则量化参数会被拉偏。平台SDK一般会提供multibatch校准接口分批喂数据并在每个batch之间更新激活范围统计这个过程走完以后还要用验证集跑一遍完整精度评测看mAP掉了多少。掉点在1个点以内属于正常范围超过2个点就要回头检查有没有关键算子被回退成FP32或者校准集分布出了问题。4. 板端实测的调优记录检测头、后处理与精度损失4.1 小目标场景要不要加P2输出无人机视角的检测任务小目标比例很高一个目标可能只占画面的二三十个像素。很多人的第一反应是加P2层让网络在更大特征图上做检测提升小目标召回。这思路没错但放到端侧要考虑代价。P2层意味着backbone需要额外输出一张原始输入1/4分辨率的高分辨率特征图对640x640输入来说就是160x160后续neck还要对这个特征做融合计算量上涨非常明显。我在实测中对比过YOLOv8s加不加P2两个版本加了之后小目标AP50提升了大约4个点但端侧帧率从36fps掉到24fps内存占用也多出几十MB。如果你的业务场景里小目标多到明显影响核心指标加P2是值得的如果小目标只是长尾需求我更建议先保留原有结构通过调整NMS阈值和多尺度推理来顶一顶。另外一个更轻量的做法是调低检测头的stride组合或者只对部分类别做更低的conf阈值这样不需要动网络结构板端计算开销变化很小。在工具链允许的范围内先把这些“软调优”做完再考虑结构性改动。4.2 后处理是留在引擎里还是拿出来自己写这个决策会直接影响后续开发效率。平台SDK一般会在模型转换时把NMS一起封装进去对外表现为一个“带后处理的engine接口”。好处是省心输入图像直接出来目标框坏处是NMS参数固定、中间结果拿不到、想改逻辑只能重新转模型。这次适配我特意把检测头的裸输出回归特征和类别特征暴露出来NMS拿到板端自己在CPU上写。具体做法是在导出ONNX时把Decode和NMS相关子图裁掉engine只保留backbone加neck加head的特征输出然后板端做阈值过滤、候选框解码、非极大值抑制。这么做一开始多写几百行C代码但换来了三个直接收益一是可以自由调conf和IoU阈值不必为参数改动反复重转模型二是可以把某些类别的阈值单独调低比如无人机场景里“人”和“车”往往需要不同的conf阈值原生NMS做不到三是解码逻辑可以在CPU和加速器之间按负载灵活分配避免整条pipeline都被加速器卡住。如果说这个项目有什么值得说的关键经验那就是除非平台自带后处理在性能上已经无可挑剔否则NMS尽量拿出来自己做。模型推理在加速器上花10几毫秒后处理在CPU上通常1到2毫秒就完成这点开销完全可控。4.3 int8量化后AP掉点怎么定位量化后掉点是正常事但不正常的掉点要能快速定位。我总结了一个比较顺的流程先在fp16基线模型上跑一遍完整验证集得到一组mAP量化模型再跑一遍得到另一组mAP把两张表的AP50、AP75、小目标AP分开对比重点看是哪个指标掉得厉害。如果AP50没什么动静AP75掉得夸张基本可以断定是定位回归的精度损失也就是bbox回归分支对数值变化太敏感如果小目标AP掉得很厉害大概率是P2或者低层特征在量化时被压缩得太狠这时候去检查低层算子的量化配置看是否落在回退列表里。还有一个很容易踩的坑量化后的输出分布和fp16不一致导致板端解析结果的置信度阈值不能沿用训练时的设置。很多团队从PC端迁移到板端发现目标检测少了第一反应是模型坏了实际上只要把conf阈值从0.25调低到0.18问题就解决了。这不是模型失效只是int8量化把输出分数整体压扁了一些阈值需要重新适配。所以建议在量化完成后做一次分数分布对比把同一组测试集分别通过fp16模型和int8模型跑收集所有候选框的score分布画直方图对比。如果发现int8模型的分数整体向右或向左偏移说明是整体bias而不是局部失灵调整阈值就能救回来如果分布形状变了比如高分段突然少了一大截那才是网络真正的精度损失需要回到模型结构层面修。5. 适配完成的验证清单与几点复盘5.1 三层验证缺一不可整个适配链路走完验证至少分三层。第一层在Python环境里做把映射后的MMYOLO模型和原Ultralytics模型对同一批图跑推理比较输出张量差异和最终检测框差异确保权重迁移本身没引入误差。第二层在平台工具链环节做把量化前后的模型分别在PC侧模拟推理用同一套验证集算mAP确认量化和算子替换带来的精度损失在可接受范围。第三层在板端实测跑真实的业务视频流检查帧率、内存、时延抖动同时配合标注好的图片验证目标框有没有系统性偏移比如固定偏左上或偏右下这类后处理坐标系错误。这三层里面第一层最容易跳但跳了最致命。权重迁移没做好后面两层都是空中楼阁。第二层容易被当成“反正量化都会掉点”而忽视但量化的掉点如果能从前到后追踪到具体算子其实大多数都能修复。第三层最容易忽略坐标系的前处理对齐问题很多板端推理异常的根因就是图像缩放和letterbox参数在两个框架里不一致。5.2 性能数据要留档适配过程中间会调整很多版本每次改进都要有横向对比数据。这里整理这一次比较有代表性的结果同一平台、640x640输入、单batch模型版本推理耗时帧率AP50小目标AP50备注Ultralytics原始fp1628ms35fps62.321.5PC端基线MMYOLO迁移fp1627ms36fps62.121.4权重迁移后基本持平MMYOLO量化int814ms67fps61.220.2校准集为业务航拍样本去掉P2后int812ms78fps60.817.8小目标损失明显需权衡这张表的价值不在于具体数字而在于它能帮你快速判断每次改动的收益在哪个维度。比如看到量化后整体只掉0.9个点说明校准集选得没问题看到P2移除后小目标掉了近2.5个点说明当前业务对小目标很敏感那就要重新评估计算量换精度的平衡。适配过程中还有一个容易被忽略的数据维度是温度与功耗。无人机平台在飞行过程中功耗预算很紧张同样跑int8引擎在不同负载下的功耗差别不小。建议在做完模型适配后跑一段10分钟以上的连续推理压力测试确认散热和供电稳定。这个数据不要等上了真机去发现提前在实验室模拟就有数。5.3 流程文档化避免下次从头再来适配过程中最花时间的是算子排查和量化校准权重映射反而是相对机械的工作。这次复盘下来我觉得最有价值的产出是两份东西一份是“模型接入检查单”从权重转换、config字段核对、pipeline对齐到导出、转换、量化、板端验证每个环节都列清楚该看什么指标另一份是“算子兼容性记录表”记录哪些算子在这个平台上是安全可用的哪些会被回退哪些结构需要绕开。第二次再接入一个新模型时先是检查单过一遍再对着兼容性记录表提前规避已知问题整体耗时从第一次的三四天压缩到一天以内。如果团队后面要频繁尝试YOLOv8变小目标优化、换neck结构这类改动这套文档化的积累比任何单个模型的适配经验都重要。说实话YOLOv8适配MMYOLO再由某无人机厂商AI算力开放平台落地本身不是一件特别“高深”的事情但它把训练框架、开源模型定义和厂商工具链三套体系的差异都串在一起任何一个环节没对齐最终板端的框就是不对。这次做完以后我个人的一个体会是模型适配的重点不在于“转换”这个动作而在于对模型结构内部每一个模块的去留、每一个算子的取舍都必须亲自验证FP16下的经验和直觉在int8和受限算力平台上经常不再成立。后面如果再接手类似任务我会更早去了解目标平台算子库的边界再做模型层面的设计而不是等训练完了再去转换硬碰。