2、Arm Ethos-U NPU 概述：架构特点、支持的算子、内存层次与性能特性
在嵌入式与物联网边缘侧部署深度学习模型时，Arm Ethos-U 系列 NPU（Neural Processing Unit）已成为与 Cortex-M 系列 CPU 协同工作的关键加速引擎。与 GPU 或桌面级 NPU 不同，Ethos-U 专为微控制器级功耗与面积约束设计，其架构核心并非追求极致算力，而是在极低功耗预算下实现确定性的推理延迟。理解其架构特点、算子支持范围、内存层次与性能特性，是进行模型选型与延迟预算评估的前提。本章将拆解 Ethos-U 的硬件微架构、指令流特点、内存带宽瓶颈以及性能估算方法，帮助开发者建立从算子到硬件映射的量化认知。
Ethos-U 并非通用处理器，而是一个可配置的、以数据流驱动的专用加速器。它通过 Vela 编译器将 TFLite 模型编译为 NPU 指令，由 CPU 触发执行。其设计哲学是“权重驻留、激活流式”，即权重尽可能常驻在 NPU 内部 SRAM 中，而激活值则通过 AXI/AHB 总线以流式方式读写。这种设计显著减少了对外部存储器的随机访问，从而在低功耗下获得高吞吐。
2.1 架构核心：MAC 阵列与数据流引擎
Ethos-U 的算力核心是脉动式 MAC（Multiply-Accumulate）阵列。以 Ethos-U55 为例，其 MAC 阵列可配置为 8x8、16x8 或 32x8 三种规格，分别对应 0.5 TOPS、1 TOPS 和 2 TOPS 的 INT8 峰值算力（在 1 GHz 下）。但实际部署中，系统时钟通常运行在 400-800 MHz，因此有效算力需按实际频率折算。MAC 阵列采用权重固定、激活流动的脉动结构，每个周期从左侧读入激活值，从上方广播权重，计算结果沿对角线方向累加输出。这种结构避免了复杂的多播网络，但要求权重在计算前已预加载到阵列内部的寄存器文件中。
与 MAC 阵列紧耦合的是激活引擎（Activation Engine），它负责执行逐元素操作，如 ReLU、LeakyReLU、Tanh、Sigmoid 以及池化（Max/Average）。激活引擎与 MAC 阵列通过内部 FIFO 连接，使得卷积层后紧跟的激活函数无需经过外部内存往返，实现了“融合”执行。Vela 编译器会自动识别这种融合机会，将多个算子合并为一个 NPU 指令序列，从而减少内存访问次数。
| 配置项 | Ethos-U55 (小尺寸) | Ethos-U55 (大尺寸) | Ethos-U65 (高带宽) |
|---|---|---|---|
| MAC 阵列规模 | 8x8 (64 MACs) | 32x8 (256 MACs) | 32x8 (256 MACs) x2 |
| INT8 峰值算力 (1GHz) | 0.5 TOPS | 2 TOPS | 4 TOPS |
| 内部 SRAM | 约 384 KB | 约 1 MB | 约 4 MB |
| 总线接口 | AHB (32-bit) | AXI (64-bit) | AXI (128-bit) |
| 典型目标 | 关键词唤醒、传感器融合 | 视觉检测、音频事件分类 | 视频理解、多模型并发 |
在模型选型时，不要只看 TOPS 数字。实际吞吐量受限于 MAC 利用率，而利用率又取决于卷积层的通道数与 MAC 阵列宽度的匹配程度。例如，一个 3x3 深度可分离卷积的深度维为 32，在 32x8 阵列上利用率可达 100%，但在 8x8 阵列上仅能利用 50%。
2.2 支持的算子与 Vela 编译器映射
Ethos-U 并非支持所有 TFLite 算子。其硬件原生支持算子集合有限，主要包括：常规卷积（Conv2D）、深度可分离卷积（DepthwiseConv2D）、全连接（FullyConnected）、池化（MaxPool/AvgPool）、激活（ReLU/LeakyReLU/Tanh）、加/减/乘（Add/Sub/Mul）、拼接（Concatenate）以及 Reshape/Transpose（仅限特定布局）。对于不支持的算子（如 LSTM、Gather、Split 等），Vela 编译器会将其标记为“CPU 算子”，在运行时由 Cortex-M 内核执行，并通过 NPU 与 CPU 之间的同步机制交换中间结果。
这种“NPU+CPU”混合执行模式是延迟预算的关键变量。如果模型中 CPU 算子占比过高，NPU 的加速优势会被通信开销抵消。Vela 编译器提供了 --cpu-operator-subset 选项，允许开发者指定哪些算子强制在 CPU 上执行，以便在编译阶段就评估混合执行的开销。此外，Vela 还会执行算子融合（如 Conv+ReLU+MaxPool 融合为一个 NPU 指令）和权重重排（将权重重新排列为 MAC 阵列友好的格式），这些优化对最终性能影响巨大。
# 使用 Vela 编译模型并输出性能报告
vela --target-profile ethos-u55-128 \
--config my_config.ini \
--output-dir ./output \
model_quantized.tflite
# 关键输出项：
# Total MACs: 12.3M
# NPU MACs: 11.8M (95.9%)
# CPU MACs: 0.5M (4.1%)
# Estimated NPU cycles: 1,234,567
# Estimated CPU cycles: 45,678
# Estimated total latency @500MHz: 2.56 ms注意：Vela 报告的延迟是基于理想内存带宽的估算值。实际延迟可能因系统 SRAM 的竞争（如 DMA 与 CPU 同时访问）而增加 20-50%。在硬实时场景中，建议在估算值上增加 30% 的裕量。
2.3 内存层次：从 Flash 到 MAC 阵列的搬运路径
Ethos-U 的内存层次分为四层：Flash（权重持久化）→ 系统 SRAM（中间缓冲）→ NPU 内部 SRAM（权重驻留区）→ MAC 阵列寄存器（计算窗口）。每一层的带宽和延迟差异巨大。Flash 的读取延迟通常在几十纳秒，但带宽极低（约 50-100 MB/s）；系统 SRAM 的带宽可达 1-2 GB/s（取决于总线宽度）；NPU 内部 SRAM 的带宽则高达 4-8 GB/s（与 MAC 阵列直接相连）。
Vela 编译器采用“权重双缓冲”策略：当 MAC 阵列正在计算当前卷积层时，DMA 控制器会预取下一层的权重到 NPU SRAM 的另一个缓冲区。这种流水线操作隐藏了 Flash 到 SRAM 的加载延迟，但前提是 NPU SRAM 容量足够容纳两层权重。如果模型单层权重超过 SRAM 容量，Vela 会执行“权重分片”（weight sharding），将一层拆分为多个子块，每个子块计算完成后立即释放空间。分片会引入额外的 DMA 同步开销，通常导致性能下降 10-30%。
2.4 性能特性：MAC 利用率与内存带宽瓶颈
Ethos-U 的实际性能由两个因素共同决定：MAC 利用率和内存带宽。MAC 利用率定义为实际有效 MAC 操作数与理论峰值 MAC 操作数之比。影响利用率的因素包括：
- 通道数对齐：MAC 阵列宽度为 8 的倍数，如果卷积层输出通道数不是 8 的倍数（如 16、24、32），会产生填充浪费。
- 空间维度：对于 1x1 卷积，MAC 阵列利用率最高；对于 3x3 卷积，需要额外的数据重排，利用率略有下降。
- 深度可分离卷积：其深度维通常较小（如 32），在 32x8 阵列上利用率高，但在 8x8 阵列上可能只有 50%。
内存带宽瓶颈则出现在激活值读写上。假设一个卷积层输出特征图为 32x32x64（INT8），则激活数据量为 64KB。如果系统 SRAM 带宽为 1.6 GB/s（64-bit AXI @200MHz），则读写一次需要 80μs。而 MAC 阵列计算该层仅需 32x32x64x3x3 = 589,824 次 MAC，在 1GHz 下耗时 0.59ms。显然，内存访问时间远小于计算时间，因此激活带宽通常不是瓶颈。真正的瓶颈往往在权重加载：如果权重需要从 Flash 读取，而 Flash 带宽只有 50MB/s，则加载 500KB 权重需要 10ms，这远超计算时间。
| 瓶颈类型 | 典型场景 | 缓解策略 |
|---|---|---|
| 权重加载瓶颈 | 大模型（>1MB 权重）从 Flash 加载 | 使用外部串行 Flash 的 Quad-SPI 模式；或将权重预加载到系统 SRAM |
| MAC 利用率低 | 通道数非 8 倍数的小模型 | 调整模型通道数为 8/16/32 的倍数；使用 Vela 的通道填充选项 |
| CPU 算子开销 | 模型中包含 LSTM/自定义算子 | 尽量替换为 Conv1D 或 GRU（若支持）；或接受混合执行 |
| DMA 竞争 | 多核系统（CPU+NPU+DMA）同时访问 SRAM | 使用 AXI QoS 优先级；错峰调度 |
2.5 案例拆解：MobileNetV2 在 Ethos-U55 上的延迟估算
假设我们有一个基于 MobileNetV2 的图像分类模型（输入 96x96x3，10 类），量化后权重为 2.3MB，总 MAC 数为 42.6M。目标平台为 Ethos-U55（32x8 阵列，1MB SRAM，500MHz 时钟，AXI 64-bit @200MHz）。
初始现象：Vela 编译后报告估算延迟为 4.8ms，但实际运行在 FPGA 上测得 6.2ms，偏差 29%。
分析过程：检查 Vela 报告发现，模型中有 3 个层因权重超过 SRAM 剩余空间而被分片（weight sharding），分片导致额外 1.1ms 的 DMA 同步开销。此外，最后一层全连接（输出 10 类）的权重为 2.5KB，但输入特征图 7x7x1280 需要从 SRAM 读取，而该层被映射到 CPU 执行（因为 Ethos-U 不支持全局平均池化后的全连接直接融合），CPU 执行耗时 0.3ms。
优化操作：
- 将输入分辨率从 96x96 降至 80x80，MAC 数降至 29.5M，权重不变，但激活值减少 30%，缓解 SRAM 压力。
- 在模型末尾添加一个 1x1 卷积（输出 16 通道），替代全局平均池化+全连接，使整个模型完全在 NPU 上执行。
- 使用 Vela 的
--weight-estimation选项预检权重驻留情况，调整层顺序（将大权重层放在模型前部，利用双缓冲预取）。
结果对比：优化后 Vela 估算延迟为 3.1ms，实际 FPGA 测量为 3.4ms，偏差 9.7%。MAC 利用率从 71% 提升至 88%。代价是模型精度从 92.1% 降至 91.4%（因输入分辨率降低），但仍在应用容忍范围内。
复盘经验：延迟预算评估不能仅依赖 Vela 估算，必须结合目标平台的 SRAM 容量、Flash 带宽和 CPU 算子占比进行修正。对于权重大于 1MB 的模型，优先考虑剪枝或量化感知训练以减少权重体积，而非依赖分片。
2.6 常见误区与总结
误区一：认为 TOPS 越高，推理越快。实际上，Ethos-U55 的 2 TOPS 在 500MHz 下有效算力仅 1 TOPS，且如果模型 MAC 利用率低于 50%，实际吞吐可能不如一个优化良好的 DSP 实现。
误区二：忽略量化精度的影响。Ethos-U 支持 INT8 和 INT16（部分配置）。INT16 的 MAC 操作数减半，且权重体积翻倍，导致内存带宽压力增大。对于动态范围大的模型（如 LSTM），建议使用 INT16，但需重新评估延迟预算。
误区三：将所有算子都放在 NPU 上执行。某些算子（如 ResizeBilinear、Pad）在 CPU 上执行可能更快，因为 NPU 需要额外的数据重排。Vela 的自动调度通常合理，但手动指定 CPU 算子子集有时能减少总延迟。