4、模型选择与准备：根据旭日芯片算力与内存限制，选择合适的YOLO变体并导出ONNX模型
旭日系列芯片（如旭日X3、旭日X3派）在边缘AI部署中面临的核心约束并非单一算力，而是“算力-内存-带宽-功耗”四者的耦合。以旭日X3为例，其BPU（Brain Processing Unit）提供约5 TOPS INT8算力，但片上SRAM仅数MB，外部LPDDR4x内存通常为2GB或4GB，且内存带宽有限。若直接选用YOLOv5m或YOLOv8s等中等规模模型，即使INT8量化后权重文件可能小于50MB，但推理时的中间特征图、激活值以及多尺度输出层的数据搬运会迅速占满带宽，导致实际帧率远低于理论算力峰值。因此，模型选择必须从“算力匹配”转向“系统级资源匹配”。
上图展示了从芯片资源约束到模型选择决策，再到最终部署产物的完整链路。核心逻辑是：先量化资源底线，再筛选模型，最后通过ONNX导出验证可行性。下面将分模块展开具体操作。
4.1 核心原理：为什么YOLOv5s和YOLOv8n是旭日芯片的“甜点”模型
YOLOv5s与YOLOv8n分别代表两个不同代际的轻量化设计思路。YOLOv5s采用CSPDarknet53骨干网络，其参数量约7.2M，计算量约16.5 GFLOPs（FP32）。YOLOv8n则引入了C2f模块和Anchor-Free检测头，参数量约3.2M，计算量约8.7 GFLOPs。从数值上看，YOLOv8n在计算量上比YOLOv5s减少约47%，但mAP50仅下降约1-2个百分点（在COCO数据集上）。对于旭日X3的5 TOPS INT8算力，FP32的GFLOPs需要换算为INT8下的等效计算量——通常INT8算力是FP32的2-4倍，因此YOLOv8n的INT8等效计算量约2.2-4.3 GFLOPs，处于芯片的舒适区。
然而，仅看GFLOPs远远不够。旭日BPU对模型的支持存在算子约束：例如，部分版本的BPU工具链不支持某些自定义C2f模块中的大卷积核分解，或者对SiLU激活函数的实现效率低于ReLU。YOLOv8n的C2f模块包含多个分支，若工具链无法高效映射，实际推理速度可能反而不如YOLOv5s。因此，选择模型时必须结合BPU工具链的算子支持列表进行预检。
关键判断指标：
- 参数量（Params）：直接影响权重文件大小和内存占用。旭日X3的2GB内存版本，建议模型参数量不超过10M，否则留给运行时缓冲区的空间会被压缩。
- 计算量（FLOPs）：决定理论推理速度。建议INT8等效计算量不超过4 GFLOPs，以保证30FPS以上的实时性。
- 峰值内存占用：包括权重、激活值、中间特征图。需通过ONNX Runtime或BPU模拟器实测，而非仅凭理论估算。
- 后处理开销：YOLOv8n的Anchor-Free头输出维度更高（80类×3个尺度），NMS计算量比YOLOv5s大，需在CPU上执行时预留算力。
4.2 判断方法：从候选模型到最终选型的四步筛选流程
实际操作中，建议按照以下步骤进行模型选型，避免“拍脑袋”决策：
- 步骤一：候选池构建——从YOLOv5n、YOLOv5s、YOLOv8n、YOLOv8s中选取。YOLOv8s参数量11.2M，计算量28.6 GFLOPs，通常超出旭日X3的舒适区，除非任务非常简单（如单类别检测）。
- 步骤二：理论指标初筛——使用Netron或thop库统计参数量和FLOPs，排除计算量超过6 GFLOPs的模型。
- 步骤三：BPU算子兼容性检查——查阅旭日工具链（如HBDK或OE包）的算子支持文档，重点检查：
Conv、Concat、Upsample、Add、SiLU、Sigmoid。若发现不支持的算子，需考虑替换或改用其他模型。 - 步骤四：ONNX导出与模拟器验证——导出ONNX后，使用BPU模拟器或开发板实测推理延迟和内存峰值，对比不同模型的实测数据。
| 模型 | 参数量(M) | FP32 FLOPs(G) | INT8等效FLOPs(G) | COCO mAP50 | 旭日X3预估帧率(FPS) |
|---|---|---|---|---|---|
| YOLOv5n | 1.9 | 4.5 | 1.1-2.3 | 45.7 | 60-80 |
| YOLOv5s | 7.2 | 16.5 | 4.1-8.3 | 56.8 | 25-35 |
| YOLOv8n | 3.2 | 8.7 | 2.2-4.4 | 53.9 | 40-55 |
| YOLOv8s | 11.2 | 28.6 | 7.2-14.3 | 60.2 | 15-20 |
上表数据基于COCO验证集，实际部署时需根据目标场景重新评估。例如，若检测目标为工业零件（类别少、形态固定），YOLOv8n的精度可能完全够用，且帧率优势明显。
4.3 案例拆解：从YOLOv5s切换到YOLOv8n的实战过程
某智能安防项目需要在旭日X3派上实现30FPS的行人检测，原方案采用YOLOv5s，实测帧率仅22FPS，且内存占用达到1.6GB（2GB版本），接近极限。项目组决定评估YOLOv8n。
初始现象与目标：YOLOv5s在FP32下推理延迟45ms，INT8量化后延迟降至28ms，但帧率仍不达标。目标是将帧率提升至30FPS以上，同时保持mAP50不低于50。
关键输入数据：
- YOLOv5s ONNX模型大小：28MB（FP32），INT8量化后约7MB。
- YOLOv8n ONNX模型大小：13MB（FP32），INT8量化后约3.5MB。
- BPU模拟器报告：YOLOv5s峰值内存占用1.2GB，YOLOv8n峰值内存占用0.8GB。
分析判断过程：YOLOv5s的CSPDarknet骨干网络在BPU上映射效率较高，但检测头部分（3个Detect层）的卷积操作在INT8量化后精度损失较大，导致mAP50从56.8降至52.1。YOLOv8n的Anchor-Free头虽然计算量小，但其DFL（Distribution Focal Loss）头包含额外的卷积层，需要确认BPU工具链是否支持。
实际操作步骤：
- 使用YOLOv8官方仓库导出ONNX：
yolo export model=yolov8n.pt format=onnx opset=12。 - 使用Netron检查ONNX图，确认所有算子均在BPU支持列表中。发现DFL头中的
Softmax算子需要替换为BPU支持的ArgMax+Gather组合。 - 编写脚本修改ONNX图，将
Softmax替换为等效实现，并重新导出。 - 使用旭日工具链进行INT8量化校准，校准数据集为500张行人图片。
- 部署到开发板实测：帧率38FPS，内存占用0.9GB，mAP50为51.3，满足需求。
结果对比与复盘：YOLOv8n在INT8量化后精度损失仅2.6个百分点，但帧率提升73%。代价是需要额外处理DFL头的算子替换，增加了约2天的开发工作量。复盘经验：模型切换不能只看理论指标，必须结合BPU工具链的算子支持做定制化修改。
风险提示：YOLOv8n的DFL头在部分BPU工具链版本中可能无法高效映射，导致实际帧率低于预期。建议在选型前先使用工具链的model_analyzer工具进行预分析，避免后期返工。
4.4 ONNX导出：从PyTorch到ONNX的完整操作流程
无论选择哪个模型，ONNX导出都是部署的关键一步。以下是标准操作流程：
# 以YOLOv8n为例
yolo export model=yolov8n.pt format=onnx opset=12 dynamic=False
# 若需要动态输入，可添加 dynamic=True，但旭日BPU通常要求固定输入尺寸
# 推荐输入尺寸：640x640（平衡精度与速度）
导出后需进行以下验证：
- 输入输出检查：使用ONNX Runtime加载模型，输入随机张量，确认输出shape符合预期（YOLOv8n输出为1×84×8400，其中84=4+80）。
- 算子兼容性：使用
onnx2bpumodel工具（旭日提供）进行转换，若报错则根据提示修改ONNX图。 - 精度对比：在开发板上运行同一张测试图片，对比PyTorch输出与ONNX输出的差异，确保误差在可接受范围（通常IoU差异小于0.01）。
经验提醒：导出ONNX时务必固定输入尺寸（如640×640），避免动态shape导致BPU内存分配失败。若需多尺度检测，建议在预处理阶段进行缩放，而非依赖模型动态输入。
4.5 常见误区与总结复盘
误区一：只看算力不看内存带宽。旭日X3的5 TOPS算力看似充裕，但若模型中间特征图过大，内存带宽会成为瓶颈。例如YOLOv5s在640×640输入下，三个检测层的特征图总大小约数十MB，频繁的DMA搬运会拖慢推理速度。
误区二：忽略后处理开销。YOLOv8n的NMS在CPU上执行时，若检测目标数量多（如密集人群），NMS耗时可能超过模型推理本身。建议在部署时使用Fast NMS或Tiny NMS优化。
误区三：ONNX导出后不做算子级优化。BPU工具链对某些算子（如Resize、Transpose）的映射效率较低，手动替换为Conv或Pool可显著提升性能。
总结复盘：模型选择与准备是部署成功的第一步，也是最容易“埋雷”的环节。建议建立标准化的选型流程：先明确任务精度底线，再结合BPU工具链的算子支持列表筛选模型，最后通过ONNX导出和模拟器验证确认可行性。对于旭日X3，YOLOv8n通常是性价比最高的选择，但需额外关注DFL头的算子兼容性；YOLOv5s则更适合对精度要求较高、且能接受较低帧率的场景。无论选择哪个模型，务必在开发板上进行实测，以实测数据为准。