3、Arm Ethos-U系列NPU架构：Ethos-U55与U65的硬件特性、计算单元、内存层次、支持算子与限制
Ethos-U系列是Arm面向Cortex-M与Cortex-A系列CPU设计的神经网络加速器（NPU），其核心目标是在资源受限的嵌入式与物联网场景中，以极低的功耗实现高效的INT8/INT16量化神经网络推理。理解Ethos-U55与U65的硬件架构差异，是进行Vela编译器优化、模型性能分析以及部署方案选型的前提。本章将深入拆解两款NPU的微架构、计算单元、内存层次结构、算子支持范围及硬件限制，帮助开发者建立从芯片底层到上层应用的完整认知。
上图展示了Ethos-U55与U65在系统集成位置、计算资源与内存接口上的核心差异。U55面向Cortex-M系列，通常作为协处理器紧耦合在MCU系统中；U65则面向Cortex-A应用处理器，通过SMMU（System Memory Management Unit）实现虚拟地址映射，支持与Linux/RTOS系统异步协同工作。两者在MAC阵列规模、SRAM容量和总线接口上的差异，直接决定了Vela编译器在优化策略上的不同侧重点。
3.1 硬件特性与系统集成模式
核心原理：从协处理器到独立加速单元
Ethos-U55是Arm推出的首款针对Cortex-M系列设计的微NPU，其设计哲学是“最小化CPU干预”。它通过AHB（AMBA High-performance Bus）从接口与Cortex-M33或Cortex-M55连接，NPU内部维护独立的命令队列，CPU只需将Vela编译生成的命令流基地址写入NPU寄存器，即可触发推理任务。U55不支持虚拟内存，所有地址均为物理地址，因此模型权重和中间张量必须放在CPU可访问的连续物理内存区域。
Ethos-U65则面向Cortex-A系列（如Cortex-A35、A53、A55），其最大的硬件特性是集成了SMMU。这使得U65可以访问操作系统管理的虚拟内存空间，模型权重可以存放在文件系统缓存中，由MMU按需分页加载。U65还支持与CPU的异步流水线操作——CPU在NPU执行当前推理任务时，可以同时准备下一帧数据，显著提升多任务场景下的吞吐量。
判断方法：根据目标平台选择NPU型号
| 特性维度 | Ethos-U55 | Ethos-U65 |
|---|---|---|
| 目标CPU | Cortex-M33/M55 | Cortex-A35/A53/A55 |
| 总线接口 | AHB-Lite（32位） | AXI（64位） |
| 内存管理 | 物理地址直通 | SMMU虚拟地址映射 |
| 典型时钟 | 50-200 MHz | 200-400 MHz |
| 典型功耗 | < 50 mW | < 500 mW |
| 操作系统支持 | 裸机/RTOS | Linux/Android/RTOS |
在实际项目选型中，如果产品基于MCU实现且对功耗极度敏感（如TWS耳机、智能传感器），应选择U55；如果产品基于Linux应用处理器（如智能摄像头、语音助手），需要运行较大模型且要求多任务并发，则U65是更合理的选择。
案例拆解：智能门锁的人脸识别方案选型
某智能门锁产品需要实现本地人脸识别，模型为MobileNetV1（INT8量化，约4.2MB权重）。初始方案采用Cortex-M55 + Ethos-U55，实测推理时间为180ms，功耗为45mW，满足电池供电需求。但后续产品迭代需要增加活体检测功能，模型体积增至7.8MB，U55的512KB SRAM无法容纳全部中间张量，导致频繁的Flash读取，推理时间恶化至420ms。项目组将方案调整为Cortex-A35 + Ethos-U65，利用SMMU将权重映射到DDR，推理时间稳定在85ms，且CPU可以同时运行网络协议栈和UI渲染。此案例说明，模型规模与内存层次的匹配度是选型的关键约束。
--memory-mode参数评估不同内存策略下的性能表现。
3.2 计算单元与数据路径
核心原理：MAC阵列与专用硬件单元
Ethos-U55和U65的核心计算单元均为8位MAC（乘累加）阵列。U55提供128或256个MAC的配置选项，U65提供256或512个MAC。每个MAC单元在单个时钟周期内完成一次INT8乘法与累加操作。值得注意的是，Ethos-U系列不支持FP32或FP16计算，所有浮点运算必须在编译阶段由Vela量化为INT8或INT16格式。
除了MAC阵列，NPU还集成了专用的激活函数引擎，支持ReLU、LeakyReLU、Tanh等常见激活函数，无需CPU参与。U65额外增加了硬件池化单元（MaxPool/AvgPool）和双线性插值单元（用于Resize操作），这些在U55中需要由CPU或Vela生成的额外指令完成。
操作流程：理解Vela如何映射算子到计算单元
# 典型Vela编译命令
vela --target-profile ethos-u55-256 \
--optimise-for latency \
--memory-mode shared_sram \
model.tfliteVela编译器会将TFLite模型中的算子（如CONV_2D、DEPTHWISE_CONV_2D、FULLY_CONNECTED）映射为NPU可执行的命令序列。对于卷积操作，Vela会将输入特征图、权重和输出特征图分配到SRAM的不同区域，并生成MAC阵列的微码指令。如果算子不在NPU支持列表中（如某些复杂的LSTM变体），Vela会将其标记为“CPU算子”，在编译报告中提示开发者。
案例拆解：YOLOv5s在U55上的算子分布分析
我们使用Vela编译一个YOLOv5s检测模型（INT8，输入尺寸256x256），目标平台为Ethos-U55-256。编译报告显示：模型共包含127个算子，其中112个被成功映射到NPU（包括Conv2D、DepthwiseConv2D、Add、MaxPool），15个算子被标记为CPU算子（主要是ResizeNearestNeighbor和Concatenation的某些变体）。NPU算子的计算量占总MACs的94.7%，但CPU算子消耗了总推理时间的31%——因为CPU需要等待NPU完成前序任务后才能执行这些算子，且CPU与NPU之间的数据同步开销较大。通过修改模型结构，将Resize操作替换为U65支持的硬件双线性插值（如果使用U65），或者调整Concatenation的轴顺序，可以减少CPU算子数量。
Conv2D + BiasAdd + ReLU的融合结构，避免单独的激活层；使用DepthwiseConv2D替代部分Conv2D以减少计算量；对于上采样操作，优先选择ResizeBilinear而非ResizeNearestNeighbor，因为前者在U65中有硬件加速。
3.3 内存层次结构与数据流优化
核心原理：SRAM、Flash与DDR的三级存储
Ethos-U系列的内存层次分为三级：NPU内部SRAM、外部Flash（或DDR）、以及CPU侧的系统内存。SRAM是NPU直接访问的高速缓存，用于存放输入特征图、权重和输出特征图。U55的SRAM容量为384KB或512KB，U65为1MB。Vela编译器的核心任务之一，就是通过“内存规划”（Memory Planning）算法，将模型的中间张量尽可能多地驻留在SRAM中，减少对外部存储的访问次数。
权重存储策略是性能优化的关键。Vela支持两种权重编码模式：Constant DMA（权重在推理前一次性加载到SRAM）和Streaming DMA（权重按需分块加载）。对于U55，由于SRAM较小，Vela通常采用Streaming模式，将大模型的权重切分为多个块，在计算当前层的同时预取下一层的权重。U65由于SRAM较大，更倾向于Constant模式，减少DMA中断频率。
判断方法：分析内存瓶颈
| 内存指标 | U55典型值 | U65典型值 | 优化手段 |
|---|---|---|---|
| SRAM容量 | 512KB | 1MB | 调整--memory-mode |
| 权重加载带宽 | AHB 32-bit @ 100MHz = 400MB/s | AXI 64-bit @ 300MHz = 2.4GB/s | 权重压缩（Vela自动应用） |
| 中间张量溢出率 | 通常 > 30% | 通常 < 10% | 优化网络结构/输入尺寸 |
开发者可以通过Vela生成的memory_usage_summary.txt文件查看每个算子的SRAM占用情况。如果发现某个算子的输出张量被频繁溢出到Flash，应考虑减小输入分辨率或使用更小的通道数。
案例拆解：语音唤醒词模型的SRAM优化
一个基于DS-CNN的语音唤醒词模型（包含5个Conv2D层，总权重1.2MB）在U55上部署时，Vela默认配置下中间张量溢出率达到45%，推理延迟为32ms。通过分析内存报告，发现第3层Conv2D的输出特征图（尺寸为10x10x128）占用了大量SRAM。优化措施：1）将输入特征图从40ms音频帧（1600个采样点）降为30ms（1200个采样点），特征图尺寸缩小25%；2）使用--weight-compression参数启用更强的权重压缩算法；3）将第3层的stride从1改为2，减少输出尺寸。优化后，溢出率降至12%，推理延迟降至21ms，同时模型精度仅下降0.3%（从96.2%降至95.9%），在可接受范围内。
3.4 支持算子与硬件限制
核心原理：NPU指令集的算子覆盖范围
Ethos-U系列支持以下算子类别：
- 卷积类：Conv2D、DepthwiseConv2D、Conv2DTranspose（U65支持，U55需CPU辅助）
- 池化类：MaxPool2D、AvgPool2D（U65硬件加速，U55由Vela生成组合指令）
- 激活类：ReLU、ReLU6、LeakyReLU、Tanh、Sigmoid（查表实现）
- 元素级操作：Add、Sub、Mul、Minimum、Maximum
- 数据移动：Reshape、Transpose（仅限特定维度）、Concatenation（沿通道维）
- 全连接：FullyConnected（映射为1x1卷积）
不支持的算子包括：Softmax（需CPU计算）、LSTM/GRU（循环神经网络）、Gather/StridedSlice（动态索引）、ResizeNearestNeighbor（U55不支持，U65支持双线性插值）。对于不支持的算子，Vela会将其标记为“CPU offload”，在推理时由CPU执行，但会引入额外的数据拷贝开销。
操作流程：使用Vela报告识别限制
# 编译后查看算子支持报告
vela --verbose --show-cpu-operators model.tflite
# 输出示例：
# CPU operators: 3
# - SOFTMAX (tensor_id: 12)
# - RESIZE_NEAREST_NEIGHBOR (tensor_id: 15)
# - GATHER (tensor_id: 18)开发者应尽量将Softmax等操作合并到前一个卷积层中（如使用Conv2D + Softmax的融合变体），或者使用近似替代方案（如分段线性逼近）。对于Gather操作，建议在模型训练阶段将其替换为固定索引的卷积核。
案例拆解：语义分割模型的算子适配
一个基于DeepLabV3的语义分割模型（MobileNetV2骨干）在U65上部署时，Vela报告显示有7个算子需要CPU执行，其中包括3个ResizeBilinear（上采样）和4个Concatenation（沿高度/宽度维）。由于U65的硬件插值单元仅支持2倍整数倍上采样，而模型需要4倍上采样，Vela无法直接映射。解决方案：1）将模型中的ResizeBilinear替换为两个连续的2倍上采样操作，使U65硬件可以处理；2）将Concatenation的轴从H/W维改为通道维，因为NPU仅支持通道维拼接。修改后，CPU算子数量降为2个（Softmax和最后的ArgMax），推理速度从45ms提升至28ms。
3.5 性能分析工具与调优实践
核心原理：Vela编译报告与Ethos-U性能计数器
Vela编译器生成的debug文件夹中包含详细的性能估算报告，包括每个算子的MACs、内存访问次数、预计周期数。实际硬件性能可以通过NPU的性能计数器（Performance Counters）获取，包括总周期数、MAC利用率、SRAM命中率、DMA等待周期等。Arm提供的Ethos-U Core Driver库支持在推理完成后读取这些计数器。
操作流程：性能调优的标准步骤
- 使用Vela编译模型，生成
--verbose报告，记录初始性能基线。 - 检查
CPU operators列表，优先消除或替换这些算子。 - 分析
memory_usage_summary.txt，定位SRAM溢出严重的层。 - 尝试不同的
--memory-mode（如shared_sram、dedicated_sram）和--optimise-for（latency或throughput）。 - 在目标硬件上运行推理，读取性能计数器，对比实际与估算的差异。
- 如果MAC利用率低于50%，考虑增大batch size（如果模型支持）或调整输入分辨率。
案例拆解：手势识别模型的调优全过程
某手势识别模型（基于ResNet-8，输入64x64x3）在U55-128上初始推理延迟为15ms，MAC利用率为38%。通过性能计数器发现，DMA等待周期占总周期的42%，原因是权重Streaming模式过于频繁。优化步骤：1）将--memory-mode改为dedicated_sram，为权重预留独立SRAM区域；2）使用--weight-compression启用稀疏权重编码（模型剪枝后稀疏度达60%）；3）将输入分辨率从64x64降至56x56（精度损失0.8%）。优化后，推理延迟降至8.2ms，MAC利用率提升至67%，DMA等待降至19%。此案例表明，内存访问模式优化往往比计算优化带来更显著的收益。