YOLOv8+MMYOLO无人机目标检测：从云端训练到端侧部署全流程实战

一开始接这个活儿的时候，我以为是给无人机换个目标检测模型，跑个demo就完事。真正动手才发现，难点根本不在模型本身，而在于“YOLOv8训练得好好的，到了MMYOLO框架里就水土不服，再部署到某行业级无人机上，问题一个接一个”。如果你正在做无人机视觉、边缘端识别的项目，或者想把YOLOv8这套重量级组合迁移到实际算力平台上跑，那这篇文章能帮你省掉起码两个月的踩坑时间。

这个项目做的事情一句话总结：在某个AI算力开放平台上，把YOLOv8完整适配到MMYOLO框架中，完成航拍场景数据集的训练、模型转换、端侧推理，最终在无人机上实现实时目标检测，比如识别车辆、船只、人员和建筑物。

1. 项目背景与现实痛点拆解

1.1 为什么要在算力开放平台上做模型适配

以前做无人机视觉，流程很传统：本地攒一台双卡机器，装好深度学习环境，训练完模型直接打包到机载盒子里跑。听起来流畅，实际操作起来痛点极其明显。算力不够时要去借服务器，环境不一致时要花整整一周重新配置各种依赖库，跑完了模型和训练数据散落在各种移动硬盘里，版本管理基本靠自觉，复现结果全看运气。

AI算力开放平台解决的正是这些问题。它的逻辑是：所有训练节点提供统一的容器环境，GPU资源按需申请，模型版本和数据集都托管在平台上。训练任务提交后，你可以随时查看资源使用率和训练曲线，甚至可以在平台上直接做模型评估和转换。这次项目之所以选择在某AI算力开放平台上做，核心原因有三个：

第一，训练资源弹性足够。航拍数据集样本量不算大，但输入分辨率高，单张图动辄三四千像素，训练时需要大batch和高分辨率，对显存请求很夸张。平台可以按需分配多卡节点，不用受限于单机的物理资源。

第二，调试环境统一。MMYOLO这个框架依赖OpenMMLab全家桶，在不同机器上安装经常会遇到各种兼容性冲突。平台提供的开发镜像直接把环境锁死，杜绝了“在我机器上明明能跑”这种问题。

第三，模型和转换产物统一管理。训练好的权重、导出的ONNX文件、量化后的引擎文件全部放平台上的对象存储里，团队内共享和后续部署拿取都很方便。

1.2 为什么选择YOLOv8和MMYOLO这套组合

先说说选型思路。YOLOv8是目前目标检测里综合性价比最高的模型之一，它有C2f结构、解耦头和无锚框设计，检测精度和推理速度的平衡点很理想。但YOLOv8的原生实现默认用Python推理，想部署到嵌入式平台上，中间有一大堆适配工作要做。而MMYOLO是OpenMMLab系列里的YOLO工具包，虽然也支持YOLOv8，但它的价值在于：把整个训练、验证、蒸馏、部署流程完全统一到一套配置体系里，同时提供了与OpenMMLab生态里其他工具链的对接能力。

选MMYOLO还有一个现实原因：项目需要对比多个模型的检测效果。MMYOLO里既有YOLOv5、YOLOv6、YOLOX，也有YOLOv8，而且支持在同一个配置体系下切换backbone和head。我们可以用同一份数据集、同一套训练流程快速做多模型对比，这在原生YOLOv8实现里是很麻烦的。

适配过程中最核心的工作是把YOLOv8的网络结构、训练策略、数据增强方式迁移到MMYOLO的配置文件中，并且确保训练目标完全对齐。很多人以为只要有yml配置文件就能跑，实际上里面的anchor设置、loss权重、数据增强参数都会直接影响最终精度，这些细节正是本文要展开讲的重点。

2. 整体方案设计与技术选型

2.1 端-云-端总体架构

先画一张整体蓝图，让心里有底。整个系统分三部分：云侧训练、端侧推理、中间转换链路。

云侧训练基于AI算力开放平台，核心是模型训练与评估单元，使用MMYOLO框架、PyTorch环境，数据源是航拍采集的原始视频帧以及公开的遥感数据集，经过清洗和标注后存储为COCO格式的标注文件。在平台上提交训练任务，产出的是训练权重文件和训练日志，还有可视化的指标曲线。训练达到预期后，将权重文件导出为部署格式。

中间转换链路是最容易被忽略但最关键的环节。一个模型从训练框架到端侧框架，通常要经过“权重转ONNX、ONNX转端侧引擎、端侧引擎再适配推理框架”三个步骤。每一步都有算子兼容风险，比如YOLOv8的解耦头和DFL结构在转换时容易出问题。这部分我们会在后文详细展开。

端侧推理单元部署在某行业级无人机的机载计算模块上。无人机通过SDK获取摄像头实时视频流，将视频帧送入推理模块，推理结果叠加检测框之后，用于实时图传或自主飞行决策。根据无人机型号的不同，机载算力可能是一个自带GPU的计算模块，也可能是一个独立的AI计算盒子，功耗一般在15W到55W之间。

2.2 算力平台选型与资源评估

选算力平台不能只看GPU型号。对于目标检测任务，还要关心几个关键指标：显存大小、CPU核数、内存带宽、容器镜像是否包含我们需要的版本依赖。

这次项目在训练阶段申请了两类资源。第一类是开发调试使用的交互式开发节点，分配的资源大概为8核CPU、32GB内存、单张24GB显存GPU，主要用于数据集分析、模型脚本调试和小规模试跑。第二类是正式训练节点，分配为推理资源4卡并行，每卡48GB显存。因为YOLOv8训练航拍高分辨率图片时，batch size大一些会显著提升训练稳定性。

做个资源估算让大家有个具体感知。假设训练集有2万张图片，输入尺寸设定为1280x1280，单张图预处理后大约占3MB显存（主要是输入张量和中间特征图）。在单卡batch size为16的情况下，模型权重、优化器状态、中间激活加在一起，大约需要35GB左右显存。这也是为什么必须有足够大显存的多卡节点才能高效训练，单纯堆CPU根本不现实。

实际训练过程中，我们使用了4卡分布式训练，每卡batch size设为12，总batch大小为48，初始学习率设为0.0025。整个训练过程跑了大概200个epoch，单轮epoch耗时约8分钟，训练总共用了约26小时。对比在本地两台2080Ti上训练同等规模数据，时间至少压缩了四倍。

注意：算力平台的资源调度策略通常不会让你长期独占节点，所以训练任务建议写成脚本一次性提交，中间避免频繁交互式调试。平台支持断点续训，但断点保存的间隔要设置合理，我习惯每5个epoch保存一次checkpoint，避免意外中断后损失太多训练进度。

3. YOLOv8在MMYOLO中的适配实操

3.1 MMYOLO对YOLOv8的支持情况与配置准备

MMYOLO正式支持YOLOv8是从2023年某个版本开始的，但它的支持方式和原生YOLOv8实现有一些底层差异。原生ultralytics版本里，数据加载、增强、模型定义和训练器都是高度集成的，你只要在命令行里指定data.yaml和model.yaml就能跑。而MMYOLO的config系统把所有模块拆散，需要通过配置文件手动组装数据管线、模型结构、优化器、学习率调度器、Hook等组件。

上手的第一步是安装MMYOLO。准备好pytorch环境后，用mim命令安装mmcv、mmengine、mmyolo这几个核心库，再安装mmdet和mmtrack作为依赖。在AI算力开放平台上，官方镜像通常已经预装大部分依赖，我们自己只需要用pip或者mim安装对应版本。注意版本之间是有对应关系的，建议安装时直接按照官方文档的版本对照表来，否则会遇到一些很隐蔽的运行时错误。

环境准备完，重点来了：创建一个自己的YOLOv8训练配置。MMYOLO的config文件通常包含八个核心模块，分别负责基础配置、模型配置、训练流水线配置、数据配置、优化器配置、训练策略配置、默认Hook配置和日志配置。官方提供了现成的yolov8_s/m/l/x系列配置模板，但如果直接用它训练自己的数据集，效果通常会打折扣，必须根据数据集特点修改关键参数。

3.2 数据集准备与标注格式转换

航拍数据集和普通地面视角数据集有非常大的差异。地面视角的目标通常比较大、比较清晰，目标之间的尺度差异相对小；航拍俯瞰视角下，目标小、密度高、朝向任意、遮挡严重、背景纹理丰富。这些差异直接决定了数据准备和增强策略的走向，不能简单套用COCO预训练模型直接微调航拍数据。

这次项目的数据来源：一部分是某公司提供的某园区及周边区域的无人机视频录像，另一部分使用公开的航拍目标检测数据集中的可用子集。原始数据是视频帧，我们按照固定间隔抽帧，共得到约2.8万张原始图片。人工标注耗时巨大，正好可以利用已有的半自动标注工具，先让预训练模型生成伪标签，再进行人工修正。这里不建议全部手工标注，成本太高，且航拍小目标人工标注的漏检率也很高。

MMYOLO默认使用COCO格式的数据集，标注文件为一个JSON，包含images、annotations、categories三个主要字段。实际采集到的原始数据有很多来自标注工具的YOLO格式，每一行是“class_id x_center y_center width height”，需要自己写一个转换脚本转成COCO格式。转换脚本的核心逻辑并不复杂：把YOLO的归一化坐标乘上图片宽高得到像素坐标，再把xywh格式转成COCO需要的[x1,y1,x2,y2]格式。但有一个坑值得提醒：不同标注工具对坐标是否归一化的定义不一样，有的直接用像素坐标，有的用归一化坐标，转换前一定要仔细确认。

数据集准备好之后，我用平台上的数据分析工具先做了一次统计学分析。结论：数据集中目标类别数量分布严重不均衡，“车辆”类别占到了全部目标的45%，“行人”占20%，“船只”占10%，其余类别的样本数量比较少。这个分布直接影响了后面训练时loss权重的设置，也在一定程度上了影响了模型对少数类别召回率的表现。

3.3 关键训练参数与调参心得

在MMYOLO里训练YOLOv8，关键的参数包括：输入分辨率（img_scale）、训练epoch数、batch size、学习率策略、数据增强策略和锚框设置。每一步的调整逻辑，简单说一下我的思路和依据。

输入分辨率是航拍检测的第一个核心参数。航拍目标普遍偏小，输入分辨率太低会直接抹掉小目标特征，但分辨率太高会导致GPU显存不足、训练速度急剧下降。经过多组对照实验，我们选择在训练过程中采用多尺度训练策略，主尺度设为1280x1280，同时每10个iteration在1024到1536之间随机缩放，让模型对目标尺度变化更鲁棒。这个策略在原生YOLOv8里也有，但在MMYOLO里配置起来逻辑更清晰。

损失函数部分，YOLOv8使用bbox_loss_weight系数来平衡分类和回归损失。MMYOLO的默认配置是基于COCO数据集调的，对于航拍数据不够适用。我把bbox_loss_weight从默认的7.5下调到6.0，原因是航拍数据集中目标尺度小，框的绝对像素波动范围不大，回归任务较简单，过高的回归损失权重会干扰分类学习。

数据增强是航拍任务的重头戏。MMYOLO自带的增强管线中，Mosaic和MixUp对航拍小目标影响很大。Mosaic把四张图拼一起训练，能大幅增加样本多样性，但也会让原本就小的目标变得更小，导致模型更倾向于忽略小微目标。我的做法是训练前30个epoch开启Mosaic，之后关闭，进入微调阶段。使用这种方式，模型对尺寸较小目标的mAP提升了约4个百分点。

学习率策略使用余弦退火策略，初始学习率0.0025，伴随warmup的10个epoch，最终在最后一个epoch降到接近0。训练过程中我每10个epoch跑一次验证集，以验证集的mAP50作为早停依据。整个训练过程中需要注意观察训练loss和验证mAP之间的曲线关系，出现loss下降但mAP不升的情况，大概率是过拟合了，这时候需要增加数据增强的强度，或者直接提前终止训练。

提示：MMYOLO训练过程中，即便同名配置文件，不同版本的默认超参也可能不同。改动任何参数后，建议先启动一个很小的子集训练，确认loss能正常下降再切到全量数据集。直接全量训练时发现参数写错，浪费的算力时间是很心疼的。

3.4 训练流程与多模型对比

整个训练过程采用了标准的流程：先在平台分布式训练节点上跑通一个小规模数据集，确认配置无误后提交全量训练；训练完成后在验证集上评估出mAP50、mAP50-95等指标；再使用MMYOLO自带的模型分析工具统计参数量和计算量。我们尝试了YOLOv8n、YOLOv8s和YOLOv8m三个规格的模型，因为无人机端侧算力有限，训练和部署都必须考虑算力约束。

实测结果在模拟项目X的验证集上，YOLOv8s的表现最均衡，mAP50约0.74，推理延迟适中，参数量约1100万。YOLOv8n速度快，但mAP50掉到0.68，小目标漏检明显。YOLOv8m精度最高，mAP50约0.78，但参数量超过2500万，在端侧平台上的推理帧率不达标。最终综合考虑精度和速度，选择YOLOv8s作为部署模型。

这里可以提供一个对照思路：模型规格的选择不是单纯的精度游戏，而是要看端侧算力预算和业务最低帧率要求。如果实测在目标平台上FP16推理到不了20帧，再好的精度也没有意义。

4. 模型转换与无人机端侧部署

4.1 ONNX导出与算子兼容检查

训练完成后，第一步是导出ONNX。MMYOLO集成了模型导出工具，基本命令是使用mmyolo的部署导出脚本，指定配置文件和权重文件。YOLOv8的模型导出ONNX时，有两大经典问题需要处理。

第一个问题是模型解码后的输出格式。YOLOv8原本的解码过程包含在模型前向计算中，输出的是已经解码后的检测框坐标、得分和类别。导出的ONNX有两种选择：一种是保留decode层，输出三个尺度的原始特征图；一种是把decode整个放进模型图里，直接输出最终检测结果。从端侧推理角度看，更推荐后者，因为端侧框架对复杂后处理的支持能力有限，把decode放进图里可以减少很多移植工作量。但坏处是：推理框架的NMS部分还是得单独做，而且动态输出维度可能会对引擎优化产生约束。

第二个问题是算子兼容性。YOLOv8的C2f模块里有大量split操作，DFL头中有一些结构特殊的卷积，这些在转换成ONNX后，某些嵌入式推理框架不一定支持。解决办法是用ONNX操作简化模型结构，比如可以把部分split操作合并成slice操作，也可以把某些没有被端侧框架支持的gelu激活函数替换为sigmoid或relu，但这样会损失少量精度。实际操作中，我用ONNX的简化器跑一遍，再逐个检查模型节点，列出所有不支持的算子类型，逐一确认处理方式。

4.2 端侧推理引擎转换

无人机端侧使用的推理框架，一般分两类：一类是芯片厂商自带的推理引擎，比如某主流GPU计算平台的TensorRT；另一类是通用的端侧推理框架，比如NCNN、MNN、OpenVINO等。某行业级无人机平台上的机载计算模块通常由嵌入式GPU提供算力，我们最终选用TensorRT作为推理框架，因为它对NVIDIA系GPU优化最充分，FP16推理速度快，显存利用率高。

转换流程上，用ONNX作为中间文件，使用TensorRT的trtexec工具将ONNX转换为FP16引擎文件。转换时有一个重要的取舍：是否开启动态shape。无人机视觉任务往往需要处理不同分辨率的视频流，动态shape能提高适用性，但TensorRT对动态shape的优化效果明显不如固定shape，推理速度会变慢。实测发现，把输入shape固定为1280x1280后，端侧平台的推理耗时比动态shape快约15%，最终我们牺牲了一点灵活性，选用固定shape方案。

FP16量化是一个精度与速度的平衡点。在8GB显存的嵌入式平台上，FP16推理比FP32快约40%，显存占用也降低近一半。但FP16量化过程中可能出现精度损失，尤其对小目标检测有影响。我的做法是：转完FP16后立即在验证集上跑一遍，计算mAP50对比FP32模型的差距。如果精度下降超过2%，就考虑使用INT8量化，但INT8量化需要校准数据集，且校准过程对航拍数据更敏感，后续可能需要做逐层量化分析。

注意：TensorRT版本之间存在较大差异。在AI算力开放平台上生成引擎文件时，所用的TensorRT版本必须与无人机机载模块上的版本一致，更准确说是主版本必须一致，小版本也最好一致。版本不一致会导致引擎文件加载失败，或者更隐蔽的推理结果错误。这个坑排查起来非常耗时，建议一开始就用同一版本的转换工具链。

4.3 无人机端推理流程与接入方式

无人机端侧的部署流程涉及两件事：一是推理流程怎么实现，二是和无人机飞控的接口怎么对接。

推理流程部分，我设计了一个标准的流水线：取流、预处理、推理、后处理、输出。取流环节通过无人机的SDK获取摄像头H264码流，解码成RGB图片，这一步本身会消耗一部分CPU资源，如果解码太慢，会直接影响整体帧率。实测中，我们的端侧模块解码1080p视频流大约耗时6ms，处于可接受范围。预处理部分包括resize、归一化、通道转换，用GPU完成。推理部分是模型在TensorRT引擎上的前向计算。后处理部分包含置信度筛选和NMS，NMS在端侧CPU上执行，这也是最容易成为性能瓶颈的单点模块。

NMS的优化有必要单独提一下。YOLOv8默认的NMS是在所有类别的候选框上做全局抑制，当输入分辨率高、目标密集时，候选框数量会非常多，CPU串行执行会有明显卡顿。我的优化思路是：先在GPU上做一次置信度阈值筛选，把得分低于0.25的框直接丢弃，再把剩余的少量候选框传给CPU做NMS。这一步优化让端侧后处理耗时从约18ms降低到了约6ms，对整体帧率提升非常明显。

无人机端侧的接入方式，根据业务需求分为图像传输和自主飞行两种。图像传输场景里，推理模块把检测结果通过RTSP视频流叠加到画面上，地面站实时查看。自主飞行场景里，检测结果会通过串口或以太网发送目标位置信息给飞控，由飞控实现目标跟随。第二种场景对检测延迟极其敏感，端到端延迟如果超过100ms，无人机运动状态下的目标跟踪就会明显滞后。我们最终通过流水线深度优化，将端到端延迟控制在80ms左右，基本满足自主跟随需求。

4.4 平台上的CI/CD与版本管理

这部分是我在算力开放平台上学到的一个重要经验：把模型版本管理纳入整个工作流。平台支持自定义数据集版本和模型版本，每完成一次训练，就在平台里记录当前训练配置、数据集版本、训练日志和评估指标，并给模型打上版本标签。这个习惯带来的收益在后期异常排查时特别明显，比如出现某个版本精度下降，可以直接回溯该版本使用的数据增强参数和数据集版本，快速定位是数据变化导致的还是参数变化导致的。

部署环节还涉及一个关键实践：部署包和推理代码的环境隔离。我把TensorRT引擎文件、模型配置文件、推理服务代码打成一个Docker镜像，镜像内锁定推理框架和CUDA版本，然后在平台上完成部署验证。镜像方式保证了从云端到边缘的一致性，避免出现“在云上调好的模型放到无人机上推理结果不对”的情况。

5. 实测效果与性能调优

5.1 推理耗时与准确率权衡

部署完成后，我们在模拟项目X的航拍验证集上进行了完整测试，并且在无人机机载模块上做了实际推理测试，记录了一些关键数据，供后续项目参考。

在目标检测精度指标上，最终部署的YOLOv8s模型在验证集上取得了mAP50约0.73的成绩，mAP50-95约0.42，对于航拍场景已经是不错的水平。对比原生YOLOv8s在COCO预训练权重上直接迁移的模型，mAP50大概只有0.61，差距非常明显，说明针对航拍场景做数据增强和微调是必不可少的步骤。

推理性能指标上，使用固定shape为1280x1280输入，FP16精度，机载模块实测单帧推理耗时约34ms，加上取流、预处理、后处理，端到端平均延迟约80ms，对应帧率在12帧左右。如果把输入分辨率降到960x960，推理耗时可以降到约22ms，端到端帧率能到20帧以上，但mAP50会掉约3个百分点。这正好呼应了前文的权衡逻辑：具体选择哪个分辨率，取决于业务需求到底更看重精度还是流畅度。

5.2 航拍小目标的专项优化

整个项目中最难的环节是航拍场景下的目标漏检问题。航拍视角下，一辆汽车可能在1280x1280的输入图中只有20x20像素，模型很难提取足够多的特征，这是航拍检测的通病。

针对这个问题，我尝试了三种优化方法，也推荐大家按这个顺序来排查。第一种是调整模型结构，把检测头改成带有可变形卷积的版本，让模型对目标形状变化更鲁棒。但这种方案需要改配置文件和模型定义，工作量和风险都比较大，效果也只提升了一个多百分点。第二种是使用切图推理（SAHI），把大图切成小图，每个小图分别跑模型，再把结果合并。这种方式对小目标检测效果提升非常明显，可以搭配图像重合率避免目标被切断，但推理时间线性增加，单帧处理会多出五倍以上的耗时，只适合离线分析场景。第三种是多尺度训练加高分辨率输入，前面已经提过，是性价比最高的一种方案。

我们最后采用的解决方案是生产环境跑固定分辨率1280x1280，但在无人机巡检的离线分析版本里加入SAHI切片推理模式，把精度拉满。这样兼顾了任务场景的差异：实时巡检对帧率要求高，允许一定程度的漏检；事后分析对精度要求高，可以接受较长的处理时间。

6. 常见问题与排查实战

6.1 算子不支持与转换失败

我们在ONNX转TensorRT过程中，最典型的报错是不支持的算子。YOLOv8的模型图里有大量Resize、Split、Gather等算子，不同TensorRT版本对这些算子的支持情况有所不同。排查方法是先用polygraphy工具对ONNX模型做一次完整的推理结果对比验证，它会逐个节点跑一遍，精确指出哪些算子导致了引擎构建失败或结果不一致。

GPF问题最强的是，由于YOLOv8使用了一个特殊的DFL（Distribution Focal Loss）解码模块，这个模块里有连续多个reshape和softmax操作，TensorRT的一些旧版本无法有效融合。解决办法是手动改onnx模型结构，把DFL模块用等效的原始矩阵运算替代，或者使用支持该模块的较新TensorRT版本。整体上，遇到算子问题不要慌，先用工具定位，再看是否能换版本、是否能化简、是否能重写等效逻辑。

6.2 机载平台性能瓶颈排查

推理速度不达标时，经常需要判断瓶颈究竟出在哪个环节。我的排查思路是：先分别测量取流时间、预处理时间、推理时间、后处理时间，然后画一个时间占比表。通常推理时间占比最大，但也不排除预处理或后处理是隐藏瓶颈。

我遇到过一个典型案例：预处理时间异常高，排查后发现是因为代码里在CPU和GPU之间反复拷贝数据，每次推理前都会把整帧图片从CPU拷贝到GPU，这个操作开销巨大。优化方案是把解码后的图像直接以GPU张量形式传输，避免CPU中转。改完之后整体延迟减少了约20%。

又比如后处理NMS耗时偏高的问题，前面说的置信度筛选方式实测效果很好。如果你的端侧平台CPU核数多，也可以考虑用多线程并行处理多个类别的NMS，但要注意线程安全问题。总之，性能优化不存在万能药，单点测量是找瓶颈的最有效手段。

6.3 常见问题速查表

提示：上表中的排查思路同样适用于其他目标检测模型，核心逻辑是“先确认信息通路，再定位具体环节”。很多人喜欢上来就修改模型结构，结果越改越乱，不如按部就班排查。

7. 一些额外的心得

7.1 算力平台使用经验

平台使用和本地开发有一些明显差异，值得单独说一说。初次在AI算力开放平台上跑MMYOLO项目，容易踩的第一个坑是环境版本对不上。平台基础镜像里的CUDA版本、Python版本、PyTorch版本如果和MMYOLO要求的不一致，训练到中途才报错，非常浪费时间。我的建议是：正式训练前先跑一个只要1分钟的小测试脚本，把数据加载、模型构建、一次前向反向全跑通，确认没问题再提大规模训练。

平台资源申请也要学会预估。规格太低的实例会让训练变成“漫长的等待”，规格太高又浪费成本。我一般是先查显存需求，再用“显存大小除以batch size x 单张图显存占用”估算单个节点能承载的并行规模。训练代码里的batch size一定要根据预估余量做设置，留出20%左右的显存缓冲，避免因为偶尔的显存抖动导致训练崩溃。

7.2 真正落地时要注意的点

部署阶段最容易被忽略的是无人机端的供电和散热。机载AI模块长时间满负荷推理时功耗会上升，功耗上升带来的热量积累如果超出了散热设计，模块会降频，推理性能会明显下降。我遇到过一次性能不稳定的情况，最后发现是散热风扇被遮挡，模块温度超过了75度触发了降频保护。这个属于硬件层面的问题，软件上几乎无法解决，只能在部署架构设计阶段做好准备。

另一个容易被忽视的是模型更新机制。无人机交付后，现场环境数据可能有变化，模型不能永远停留在初始版本。需要设计一套远程更新机制，定期从地面站推送模型权重到无人机存储上，并支持热切换，让模型可以在飞行间隙完成更新。

我在实际项目中的体会是，模型适配这件事本身不是最难的，难的是把训练、转换、部署、更新整个链路理顺，让每个环节都能快速迭代。这个项目在AI算力开放平台上跑通之后，整个链路端到端的迭代周期从一个星期压缩到了半天左右——新数据到了，上午标注，下午训练，傍晚就能更新到无人机上。如果你也在做类似的事，不妨先把链路打通，再慢慢调模型，效率会高很多。