王若然1. 项目背景与问题定位
最近在将YOLOv5n模型部署到RK3588芯片时，遇到了一个典型的技术难题：如何在YOLOv8项目环境下训练YOLOv5n模型，并导出符合RKNN格式要求的ONNX文件。这个需求源于实际项目中硬件平台的限制——RK3588的NPU对模型结构有特定要求，而YOLOv8的模型输出结构与YOLOv5存在本质差异。
问题的核心在于输出层的设计差异。RK3588的RKNN工具链要求YOLOv5模型的ONNX输出必须是三个特定尺度的特征图（stride 8/16/32），每个尺度的输出通道数必须为255。这个255的计算逻辑是：3个anchor × (4个坐标偏移 + 1个置信度 + 80个类别分数)。例如对于640×640的输入，输出应为：
- 输出0：[1, 255, 80, 80]
- 输出1：[1, 255, 40, 40]
- 输出2：[1, 255, 20, 20]
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. YOLOv8与YOLOv5的结构差异解析
2.1 模型保存格式差异
YOLOv8保存的模型文件(.pt)实际上是一个checkpoint字典，其中包含两个关键对象：
ckpt["ema"]: EMA(指数移动平均)版本的模型ckpt["model"]: 原始模型对象
这两个对象都是Ultralytics框架下的DetectionModel实例，而非原生YOLOv5的模型结构。这是导致导出问题的根本原因之一。
2.2 输出层实现差异
YOLOv8的输出结构由两个关键文件决定：
tasks.py: 控制forward/predict流程head.py: 定义检测头的输出形式
与YOLOv5不同，YOLOv8的输出层设计更加灵活，但这也导致其无法直接导出YOLOv5传统的三个[1, 3*(5+nc), H, W]格式的输出。具体差异体现在：
- 特征图尺度可能不一致
- 通道组织顺序不同
- 后处理逻辑集成方式不同
注意：YOLOv8的模型结构虽然性能更优，但这种设计差异使其难以直接兼容RK3588的NPU加速需求。
3. 解决方案与实施步骤
3.1 回归YOLOv5原生训练环境
经过多次尝试，确认最可靠的解决方案是使用原生YOLOv5代码库进行训练和转换。具