4、轻量级目标检测模型：YOLO系列（Tiny YOLO、YOLOv5n）、SSD、EfficientDet-Lite等模型结构对比

在TinyML目标检测的工程实践中，模型选型直接决定了后续在Ethos-U上的部署难度、推理延迟与精度上限。本章聚焦三类最具代表性的轻量级检测模型——YOLO系列（Tiny YOLO、YOLOv5n）、SSD（Single Shot MultiBox Detector）以及EfficientDet-Lite，从网络结构、算子构成、参数量、计算量（MACs）、锚框机制、后处理复杂度等维度展开系统对比。理解这些差异，是后续在Ethos-U上完成算子映射、内存规划与性能调优的前提。

轻量级目标检测模型结构对比总览 YOLO系列 Tiny YOLO / YOLOv5n SSD Single Shot MultiBox EfficientDet-Lite 复合缩放 + BiFPN 骨干网络 Darknet / CSPDarknet 骨干网络 VGG16 / MobileNetV2 骨干网络 EfficientNet-B0~B3 特征融合 FPN / PANet 特征融合 多尺度特征图直接输出 特征融合 BiFPN 加权双向融合 检测头 Anchor-based + 多尺度 检测头 默认框 + 类别/位置回归 检测头 共享卷积头 + 多尺度输出

上图从宏观视角展示了三类模型的共性流水线——骨干网络提取特征、特征融合层整合多尺度信息、检测头输出类别与位置。然而，它们在具体实现上差异显著，这些差异直接影响Ethos-U上的算子映射策略与内存带宽需求。下面逐一拆解。

4.1 YOLO系列：从Tiny YOLO到YOLOv5n的演进

核心原理

YOLO（You Only Look Once）将目标检测视为单次回归问题，输入图像经过骨干网络后直接输出边界框坐标、置信度与类别概率。Tiny YOLO是YOLOv2/v3的轻量变体，骨干网络仅包含9层卷积，特征图尺寸逐级递减，最终在13×13或26×26尺度上输出预测。YOLOv5n则采用CSPDarknet53骨干，引入Focus模块（或6×6卷积）进行下采样，并使用PANet（Path Aggregation Network）进行特征融合，在保持精度的同时将参数量压缩至约1.9M。

判断方法与操作流程

在Ethos-U部署YOLO系列时，需重点关注以下算子：

  • Conv+BN+LeakyReLU：Tiny YOLO大量使用3×3卷积，Ethos-U的MAC阵列可高效处理，但需注意BN层在推理时可折叠进卷积权重，减少运行时计算。
  • MaxPooling：Tiny YOLO使用2×2最大池化，Ethos-U支持该算子，但需确认池化步长与核大小是否匹配硬件配置。
  • Upsample：YOLOv5n的PANet包含上采样操作，Ethos-U通常通过最近邻插值实现，需注意内存访问的连续性。
  • YOLO层（检测头）：包含大量1×1卷积和reshape操作，输出张量形状为[B, anchors×(5+classes), H, W]，需在CPU上完成后处理（NMS）。
# 以YOLOv5n为例，ONNX导出后关键节点统计
# 总节点数: 约230个
# Conv: 96个 (3×3: 72, 1×1: 24)
# MaxPool: 3个
# Upsample: 2个
# Concat: 4个
# Reshape/Transpose: 8个
# 参数量: 1,766,361 (约1.7M)
# 计算量: 4.2 GMACs (输入640×640)

案例拆解：Tiny YOLO在Cortex-M55+Ethos-U55上的部署

某工业视觉项目需在嵌入式设备上检测传送带上的零件缺陷，选用Tiny YOLO（输入416×416，20类）。初始部署时发现推理延迟为180ms，超出实时要求（100ms）。通过Ethos-U的Vela编译器分析，定位到以下瓶颈：

  1. 内存布局：默认的NHWC布局导致Ethos-U的DMA访问效率低，改为NCHW后延迟降至140ms。
  2. 量化精度：使用8位量化后，检测精度mAP从0.72降至0.68，但延迟进一步降至95ms。通过混合量化（保留最后两层为16位）恢复至0.71，延迟仅增加8ms。
  3. 后处理优化：NMS在CPU上耗时15ms，改用快速NMS（按类别分组+置信度阈值0.25）后降至6ms。

最终系统延迟为89ms，满足实时要求。复盘发现，Tiny YOLO的9层卷积结构在Ethos-U上算子映射简单，但检测头输出张量较大（13×13×125），需合理规划SRAM分区。

经验提醒：YOLOv5n相比Tiny YOLO精度更高（COCO mAP 0.45 vs 0.23），但PANet引入的Concat和Upsample会增加Ethos-U的DMA负载。若硬件SRAM有限（如1MB），建议优先选择Tiny YOLO或对YOLOv5n进行通道剪枝。

4.2 SSD：多尺度默认框的经典范式

核心原理

SSD（Single Shot MultiBox Detector）在骨干网络的不同层上附加多个卷积检测头，每个检测头负责预测不同尺度的默认框（Default Boxes）。以MobileNetV2-SSD为例，在Conv13、Conv14、Conv15等层上分别输出19×19、10×10、5×5等尺度的特征图，每个位置生成6个默认框，总计1917个候选框。SSD的检测头由3×3卷积组成，输出类别分数（num_classes+1）和边界框偏移（4×num_anchors）。

判断方法与操作流程

SSD在Ethos-U上的部署要点：

  • 多检测头并行：每个检测头独立输出，可分别映射到Ethos-U的不同计算区域，但需注意输出张量的拼接顺序。
  • 默认框生成：SSD的默认框参数（scale、aspect_ratio）在训练时固定，推理时无需计算，但后处理需按特征图尺寸逐一解码。
  • Conv+ReLU6：MobileNetV2使用ReLU6激活，Ethos-U支持该算子，但需确认硬件实现是否与软件一致。
  • Depthwise卷积：MobileNetV2的深度可分离卷积在Ethos-U上效率较高，但需注意通道数是否为4的倍数（硬件对齐要求）。
模型 骨干网络 参数量(M) GMACs(300×300) 默认框数量 Ethos-U友好度
Tiny YOLO 9层卷积 15.8 5.4 845 高（算子简单）
YOLOv5n CSPDarknet 1.9 4.2 25200 中（PANet复杂）
SSD-MobileNetV2 MobileNetV2 4.3 1.2 1917 高（深度可分离）
EfficientDet-Lite0 EfficientNet-B0 3.2 0.9 1530 中（BiFPN复杂）

案例拆解：SSD在智能门禁中的精度-延迟权衡

某智能门禁项目需检测人脸和人体（2类），选用SSD-MobileNetV2（输入320×320）。在Ethos-U55（128 MACs）上实测延迟为45ms，但mAP仅0.61，误检率较高。分析发现：

  1. 输入分辨率：320×320对远距离小目标不友好，提升至416×416后mAP升至0.68，延迟增至72ms。
  2. 量化损失：全INT8量化后mAP降至0.55，通过量化感知训练（QAT）恢复至0.64。
  3. 检测头裁剪：移除Conv15检测头（负责大尺度目标），参数量减少12%，延迟降至60ms，mAP仅下降0.02。

最终方案采用416×416输入+QAT+裁剪检测头，延迟68ms，mAP 0.63，满足门禁场景需求。复盘发现，SSD的多尺度检测头设计在Ethos-U上可灵活裁剪，但需注意不同检测头的输出张量内存对齐。

风险提示：SSD的默认框数量虽少于YOLOv5n，但后处理需遍历所有特征图位置，若在CPU上执行NMS，可能成为瓶颈。建议将置信度阈值提前至0.3，减少候选框数量。

4.3 EfficientDet-Lite：复合缩放的效率典范

核心原理

EfficientDet-Lite是Google针对移动端优化的检测模型，核心创新包括：

  • EfficientNet骨干：通过复合缩放（宽度、深度、分辨率）获得B0~B3等变体，在相同FLOPs下精度优于MobileNetV2。
  • BiFPN（双向特征金字塔网络）：对不同尺度的特征图进行加权融合，权重可学习，比PANet更高效。
  • 共享检测头：所有尺度共用同一组卷积参数，减少参数量。

判断方法与操作流程

EfficientDet-Lite在Ethos-U上的部署挑战：

  • BiFPN的加权求和：涉及逐元素乘法和加法，Ethos-U的MAC阵列可处理，但需将权重预先量化。
  • Swish激活：EfficientNet使用Swish（SiLU），在INT8量化时需用H-Swish近似，否则精度损失较大。
  • SE模块（Squeeze-and-Excitation）：包含全局平均池化和全连接层，Ethos-U对全局池化支持有限，可能需在CPU上执行。
  • 多输入分辨率：Lite0~Lite3对应不同输入尺寸（320~512），需根据硬件SRAM选择。
# EfficientDet-Lite0 在Ethos-U55上的性能预估
# 输入: 320×320×3
# 骨干: EfficientNet-B0 (约4.0M参数)
# BiFPN: 3个双向融合层
# 检测头: 共享卷积 (3×3, 64通道)
# 预估延迟: 55-70ms (128 MACs, INT8)
# 内存峰值: 约1.2MB (特征图+中间缓冲)

案例拆解：EfficientDet-Lite在无人机巡检中的部署

无人机巡检项目需检测电力线缺陷（5类），选用EfficientDet-Lite1（输入384×384）。在Ethos-U65（256 MACs）上部署时遇到以下问题：

  1. SE模块瓶颈：全局平均池化在Ethos-U上无法高效执行，改为在CPU上计算，增加3ms延迟。
  2. Swish量化：直接量化导致mAP从0.58降至0.47，改用H-Swish（ReLU6(x+3)/6）后恢复至0.55。
  3. 内存优化：BiFPN的中间特征图占用大量SRAM，通过算子融合（Conv+Add+ReLU合并）减少30%内存占用。

最终延迟82ms，mAP 0.55，满足无人机实时传输需求。复盘发现，EfficientDet-Lite的精度优势在INT8量化后仍能保持，但需仔细处理SE模块和Swish激活。

总结对比：三类模型在Ethos-U上的适用场景不同——Tiny YOLO适合极简硬件（如Cortex-M55+Ethos-U55），YOLOv5n适合需要高精度的场景（但需优化PANet），SSD-MobileNetV2在延迟和精度间平衡最佳，EfficientDet-Lite适合追求极致效率且能处理SE模块的硬件。选型时需结合目标类别数、输入分辨率、硬件MAC阵列大小和SRAM容量综合判断。

4.4 模型结构对比与Ethos-U部署决策矩阵

核心原理

Ethos-U的硬件架构决定了其对不同算子的支持程度。其MAC阵列擅长3×3和1×1卷积，对Depthwise卷积支持良好，但对全局池化、复杂激活函数（如Swish）和动态形状操作支持有限。因此，模型选型需遵循以下原则：

  • 算子覆盖率：统计模型中各算子类型，优先选择Ethos-U原生支持的算子。
  • 内存峰值：特征图大小和中间缓冲决定了SRAM需求，需确保不超过硬件容量。
  • 量化友好度：模型中的激活函数和归一化方式影响INT8量化精度。

判断方法与操作流程

在Ethos-U上部署目标检测模型的推荐流程：

  1. 模型转换：将PyTorch/TensorFlow模型导出为ONNX，再转换为TensorFlow Lite格式。
  2. 量化校准：使用代表性数据集进行INT8量化，评估精度损失。
  3. Vela编译：使用Vela编译器将TFLite模型映射到Ethos-U，生成可执行文件。
  4. 性能分析：通过Ethos-U的Cycle Counter工具分析各层延迟，定位瓶颈。
  5. 迭代优化：根据分析结果调整模型结构（如裁剪检测头、替换激活函数）或硬件配置（如MAC阵列大小）。
对比维度 Tiny YOLO YOLOv5n SSD-MobileNetV2 EfficientDet-Lite0
骨干网络类型 普通卷积堆叠 CSPDarknet 深度可分离卷积 EfficientNet-B0
特征融合 无（单尺度） PANet 多尺度检测头 BiFPN
锚框机制 3×3网格 3×3网格 6个默认框/位置 3×3网格
后处理复杂度 低（845框） 高（25200框） 中（1917框） 中（1530框）
Ethos-U算子兼容性 高 中（Upsample/Concat） 高（Depthwise） 低（SE/Swish）
典型延迟(128 MACs) 95ms 120ms 45ms 70ms

案例拆解：多模型对比选型实战

某智能摄像头项目需在Ethos-U55（128 MACs，1MB SRAM）上实现10类目标检测，输入分辨率要求320×320。团队对四个候选模型进行了系统评估：

  1. Tiny YOLO：延迟95ms，mAP 0.23，内存占用0.8MB，但精度不足。
  2. YOLOv5n：延迟120ms，mAP 0.45，内存占用1.5MB（超出SRAM），需外部存储，不可行。
  3. SSD-MobileNetV2：延迟45ms，mAP 0.61，内存占用0.6MB，满足要求。
  4. EfficientDet-Lite0：延迟70ms，mAP 0.58，内存占用1.1MB（略超），需优化。

最终选择SSD-MobileNetV2，并通过QAT将mAP提升至0.64。复盘发现，YOLOv5n的PANet在SRAM受限时无法部署，而EfficientDet-Lite的SE模块可通过CPU卸载解决，但增加了开发复杂度。

常见误区：不要仅凭参数量或GMACs判断模型在Ethos-U上的性能。例如，YOLOv5n参数量虽小，但PANet的Concat操作导致内存峰值高；SSD的GMACs虽低，但多检测头输出可能造成DMA带宽瓶颈。务必使用Vela编译器进行实际性能评估。

4.5 模型结构对Ethos-U部署的深层影响

核心原理

Ethos-U的硬件设计围绕MAC阵列展开，其计算效率取决于数据复用率和内存访问模式。模型结构决定了特征图的通道数、空间尺寸和算子类型，进而影响：

  • 数据复用：3×3卷积在MAC阵列中可复用输入特征图，而1×1卷积则需频繁加载权重。
  • 内存带宽：Upsample和Concat操作需要额外的DMA传输，增加带宽压力。
  • 量化误差传播：深层网络和复杂激活函数（如Swish）在INT8量化时误差累积更明显。

判断方法与操作流程

针对Ethos-U的模型优化策略：

  1. 算子替换：将Swish替换为ReLU6，将SE模块替换为全局平均池化+1×1卷积（简化版）。
  2. 通道剪枝：对检测头或BiFPN的通道数进行剪枝，减少计算量。
  3. 层融合：将Conv+BN+ReLU融合为单算子，减少内存访问。
  4. 输入分辨率调整：在精度允许范围内降低输入尺寸，减少特征图内存。
# Vela编译器优化示例
vela --accelerator-config=ethos-u55-128 \
     --optimise-for-size \
     --config=my_config.ini \
     model_ssd_mv2.tflite

案例拆解：YOLOv5n的PANet优化

某项目需在Ethos-U65（256 MACs，2MB SRAM）上部署YOLOv5n（输入416×416）。初始部署失败（内存溢出），通过以下优化成功：

  1. PANet简化：移除PANet的底层融合层（P2），仅保留P3-P5，内存峰值从2.3MB降至1.8MB。
  2. Upsample替换：将最近邻上采样替换为转置卷积（步长2），虽然计算量增加，但内存访问更连续。
  3. 检测头量化：对检测头使用16位量化，其余层保持8位，mAP从0.42提升至0.44。

最终延迟105ms，mAP 0.44，满足项目需求。复盘发现，PANet的简化对精度影响较小（-0.01 mAP），但显著降低了内存压力。

经验总结：在Ethos-U上部署目标检测模型，需从算子兼容性、内存峰值、量化精度三个维度综合评估。建议先使用Vela编译器进行快速性能预估，再根据瓶颈进行针对性优化。模型结构对比不仅是理论分析，更需结合硬件特性进行工程调优。
← 上一章 📖 返回目录 下一章 →