📚 课程目录第2章 Ethos-U NPU架构概览

2、Ethos-U NPU架构概览：NPU硬件特性、支持的操作、内存层次、延迟与吞吐量关键指标

在开始量化实操之前，我们必须先理解 Ethos-U NPU 的硬件“脾气”。量化本质上是用软件算法去适配硬件加速器的数据通路和计算约束。如果对 NPU 的架构特性没有清晰认知，后续的量化参数设置、算子替换和延迟调优都将是无源之水。本章将深入拆解 Ethos-U 系列（以 Ethos-U55 和 Ethos-U65 为典型代表）的硬件特性、支持算子集合、内存层次结构，以及衡量其性能的关键指标，帮助你在模型部署前建立完整的硬件心智模型。

2.1 NPU 硬件特性与计算引擎

Ethos-U 系列是 Arm 专为 Cortex-M 和 Cortex-A 平台设计的嵌入式神经网络加速器。它并非一个通用的 CPU 或 GPU，而是一个高度专用的可配置加速器。其核心计算引擎是 MAC（乘加）阵列，U55 提供 32 至 128 个 MAC 单元，而 U65 则扩展到 256 至 512 个。这意味着每个时钟周期最多可完成 512 次乘加运算。然而，MAC 阵列的利用率高度依赖于数据的摆放和算子是否被 Vela 编译器有效映射。若量化模型中的算子无法被 NPU 原生支持，Vela 会将其回退到 CPU 执行，导致数据在 CPU 与 NPU 之间频繁搬运，严重拉低有效吞吐量。

除了 MAC 阵列，NPU 还集成了专用的激活引擎和池化引擎。激活引擎支持 ReLU、LeakyReLU、Sigmoid、Tanh 等常见非线性函数，且这些函数在硬件上以查找表（LUT）或专用电路实现。这里有一个关键的量化要点：Sigmoid 和 Tanh 在 NPU 上通常要求输入为 int8 或 int16 的特定量化参数（scale 和 zero_point）。如果量化配置不当，激活引擎可能无法正确解析数据，导致精度损失或硬件报错。池化引擎则支持最大池化和平均池化，但平均池化的除法操作在 int8 域中需要额外的缩放处理，这通常由 Vela 编译器自动插入 requantization 节点。

核心原理：Ethos-U 采用权重驻留（Weight Stationary）的数据流设计。权重数据预先加载到 MAC 阵列附近的局部缓冲区中，输入激活数据以流的形式通过阵列。这种设计减少了权重的重复读取，但要求输入激活的布局必须严格遵循 NHWC（高度、宽度、通道）且通道数对齐到 8 或 16 的倍数。量化实操中，若遇到通道数不为 8 的倍数（如 3 通道 RGB 输入），Vela 会自动进行通道填充（Padding），这会增加额外的计算和内存开销，但这是保证硬件高效运行的必要代价。

2.2 支持的操作与算子映射策略

并非所有 TensorFlow Lite 算子都能在 Ethos-U 上获得硬件加速。理解“支持的操作”边界是量化部署的第一步。下表列出了 Ethos-U55/U65 原生支持的核心算子类别及典型限制：

算子类别	具体算子	硬件限制与量化要求
卷积	CONV_2D, DEPTHWISE_CONV_2D	权重必须为 int8 或 int16；若使用 int16 权重，MAC 利用率减半；支持 1x1 至 7x7 卷积核
池化	MAX_POOL_2D, AVG_POOL_2D	池化窗口最大 8x8；AVG_POOL 要求输入输出 scale 一致或由编译器插入 requant
激活	RELU, RELU6, TANH, SIGMOID	RELU 系列无额外参数；TANH/SIGMOID 要求输入 scale 为 1/256，zero_point 为 -128
元素级操作	ADD, MUL, MINIMUM, MAXIMUM	两个输入张量的 scale 和 zero_point 必须完全一致，否则需插入残差缩放节点
全连接	FULLY_CONNECTED	本质是 1x1 卷积的变体，支持 int8 输入输出
数据重塑	RESHAPE, TRANSPOSE, CONCATENATION	仅支持特定内存布局，TRANSPOSE 若无法在硬件中完成将回退 CPU

在实操中，我们经常遇到 SOFTMAX 或 LSTM 这类复杂算子。Ethos-U 原生不支持 SOFTMAX，Vela 会将其标记为 CPU 算子。此时，整个模型图会被分割为多个子图：NPU 子图和 CPU 子图。每次子图切换都需要通过总线进行数据搬运，这会产生微秒级的延迟开销。因此，在量化模型设计阶段，应尽量避免在关键路径上使用 NPU 不支持的算子，或者通过算子融合（如将 ReLU 融合进前一卷积层）来减少子图切换次数。

判断方法：使用 Vela 编译器进行编译时，添加 --verbose 标志，输出日志中会明确标注 Operator not supported: SOFTMAX 等信息。通过分析日志中的 Total SRAM used 和 CPU/GPU/NPU cycles 比例，可以快速定位性能瓶颈是否由算子回退引起。

2.3 内存层次结构与数据搬运成本

Ethos-U 的内存系统分为三个层次：片内 SRAM、片外 Flash 以及（仅 U65 支持的）片外 DDR。SRAM 是 NPU 直接访问的高速缓存，其容量通常为 512KB 至 1MB（U55 可配置）。Flash 用于存储模型权重和只读数据，DDR 则用于存放较大的中间激活张量或 U65 的权重流。

内存层次对量化实操的直接影响体现在权重布局和激活缓冲上。Vela 编译器负责将权重数据重新排列为 NPU 友好的格式（如 Z 字形扫描顺序），并规划激活张量在 SRAM 中的生命周期。如果模型过大导致 SRAM 溢出，Vela 会采用“权重重载”策略，即多次从 Flash 或 DDR 中读取权重。每次重载都会产生额外的 DMA 传输延迟。量化位宽直接决定了内存带宽压力：将权重从 int16 降至 int8，理论上可将 Flash 读取带宽需求减半，从而显著降低内存延迟。

// 示例：Vela 编译日志中的内存分配信息片段
Total SRAM used: 420 KB
Total Flash used: 1.2 MB
Total DDR used: 0 KB (U55)
Weights compressed: 35% (from 1.8 MB to 1.2 MB)

在案例中，我们曾部署一个 4MB 的 MobileNetV2 模型到仅有 512KB SRAM 的 U55 上。初始编译时，Vela 报告需要 3 次权重重载。通过应用 per-channel 量化 和 权重聚类 技术，我们将模型压缩至 2.8MB，重载次数降为 2 次，端到端延迟降低了 18%。这说明内存层次优化与量化精度之间存在直接权衡。

2.4 延迟与吞吐量关键指标解析

衡量 Ethos-U 性能的核心指标有三个：端到端延迟（Latency）、MAC 利用率（MAC Utilization）和内存带宽瓶颈（Memory Bandwidth Bound）。延迟通常以毫秒（ms）为单位，指从输入张量进入 NPU 到输出张量可用的总时间。MAC 利用率是实际有效 MAC 运算次数与理论峰值 MAC 次数的比值。例如，U55 在 400MHz 下，128 MAC 的理论峰值为 400M * 128 = 51.2 GOPS。若实际运行仅达到 20 GOPS，则利用率为 39%。

低利用率通常由以下原因导致：1) 算子回退（CPU 执行拖慢整体）；2) 填充开销（通道数不对齐导致 MAC 空转）；3) 数据依赖停顿（等待前一算子输出）。内存带宽瓶颈则表现为：MAC 阵列等待数据加载，而 DMA 引擎忙于搬运权重。此时，即使 MAC 利用率高，整体延迟也受限于 AXI 总线带宽。

常见误区：许多开发者只关注模型的理论 MAC 数，而忽略内存带宽。在 Ethos-U 上，当模型权重超过 SRAM 容量时，系统变为内存受限（Memory-Bound）而非计算受限（Compute-Bound）。此时，盲目增加 MAC 阵列大小（如从 U55 升级到 U65）不会提升性能，反而可能因 DDR 延迟引入新的瓶颈。正确的做法是先通过量化压缩权重，使模型适配 SRAM 容量。

为了准确评估性能，建议使用 Arm 提供的 Ethos-U NPU 性能分析器 或 Vela 的 --report 选项生成详细报告。报告中会包含每个算子的周期数、DMA 等待周期和 MAC 活跃周期。通过分析这些数据，可以精准定位是卷积层计算慢，还是数据搬运慢。在后续章节的量化实操中，我们将反复使用这些指标来验证量化方案的有效性。

总结复盘：本章建立了 Ethos-U 的硬件架构认知框架。核心要点归纳为：

1. MAC 阵列是心脏，但利用率取决于数据布局和算子支持度。

2. 内存层次决定性能上限，量化位宽直接影响 Flash/DDR 带宽压力。

3. 延迟与吞吐量是量化效果的最终裁判，必须结合 Vela 报告进行数据驱动的调优。

在开始实际量化操作前，请务必确认你的目标模型算子是否全部在支持列表中，并估算模型权重是否超出目标设备的 SRAM 容量。这将为后续的量化参数选择和精度调优奠定坚实的硬件基础。