NPU与delegate基础：理解NPU架构、delegate在推理框架中的位置、与CPU/GPU执行的差异
在正式编写自定义算子之前，我们必须先建立对NPU硬件和delegate机制的底层认知。NPU（Neural Processing Unit）并非一个统一的抽象设备，不同厂商（如高通Hexagon、联发科APU、华为达芬奇、苹果ANE）的架构差异极大，而delegate正是为了屏蔽这些差异而存在的软件抽象层。本章将拆解NPU的核心计算范式、delegate在推理框架中的桥梁位置，以及它与CPU/GPU执行在调度、内存和精度上的本质区别。
2.1 NPU核心架构与计算范式
NPU的设计目标非常明确：以最低的功耗完成神经网络推理中最常见的计算模式——密集矩阵乘法和卷积运算。与CPU的通用控制逻辑和GPU的大规模线程调度不同，NPU通常采用脉动阵列（Systolic Array）或近存计算（Near-Memory Computing）架构。以Google Edge TPU为例，其核心是一个256x256的MAC（乘累加）阵列，数据在阵列中像脉搏一样逐周期流动，权重和激活值在计算单元间直接传递，避免了频繁的寄存器访问。
从指令集角度看，NPU通常不提供完整的通用指令集，而是暴露一组张量指令，例如“执行3x3卷积，stride=2，ReLU激活”。这意味着NPU上的算子粒度远大于CPU指令。例如，一个Conv2D在CPU上可能被编译成数百条指令，而在NPU上只是一条硬件指令。这种设计带来的直接后果是：并非所有算子都能在NPU上高效执行。像动态形状的Reshape、带有复杂控制流的循环、或者需要高精度（FP64）的算子，在NPU上要么不被支持，要么性能极差。
另一个关键特性是内存层次结构。NPU通常配备大容量片上SRAM（例如高通Hexagon V73拥有数MB的向量存储），但缺乏CPU那样的多级Cache和虚拟内存管理。数据必须显式地在DDR和SRAM之间搬运，这个搬运过程往往由驱动或编译器自动插入DMA指令。对于自定义算子而言，这意味着我们需要明确算子的输入输出张量在内存中的布局（NHWC还是NCHW），以及是否需要额外的内存拷贝。
2.2 Delegate在推理框架中的桥梁角色
Delegate（委托）是推理框架中一个可插拔的后端适配层。以TensorFlow Lite为例，其执行流程是：模型被解析为FlatBuffer格式的计算图，然后由Interpreter逐节点执行。当启用NPU delegate时，框架会调用ApplyDelegate()接口，将图中支持的部分子图替换为一个“自定义节点”，该节点内部指向NPU编译后的二进制或句柄。
Delegate的核心职责包括三部分：图分区（Graph Partitioning）、算子映射（Op Mapping）和运行时管理（Runtime Management）。图分区负责判断哪些节点可以交给NPU，哪些必须留在CPU。例如，一个Conv2D+ReLU+MaxPool的子结构通常可以整体下沉到NPU，而中间的Reshape如果导致数据重排，则可能被分割。算子映射则是将框架的算子定义（如ADD）转换为NPU驱动能识别的算子ID和参数结构。运行时管理则涉及输入输出张量的内存分配、同步机制（如fence/semaphore）以及错误处理。
理解delegate的位置至关重要：它位于框架核心与硬件驱动之间。向上，它必须遵循框架的算子接口协议；向下，它必须适配NPU的驱动API。这种双重约束意味着，当我们注册自定义算子时，需要同时修改两个层面：一是框架侧的算子定义和序列化格式，二是NPU侧的算子实现和注册表。
| 对比维度 | CPU执行 | GPU执行 | NPU执行 |
|---|---|---|---|
| 调度单位 | 指令级（ILP） | 线程块（SIMT） | 张量指令（数据流） |
| 内存模型 | 多级Cache + 虚拟内存 | 全局显存 + 共享内存 | 片上SRAM + DMA搬运 |
| 典型精度 | FP32/FP64 | FP16/FP32 | INT8/INT16/FP16 |
| 算子支持范围 | 所有算子 | 大部分张量算子 | 仅已注册的算子子集 |
| 功耗效率 | 高（>10W） | 中高（5-15W） | 极低（<2W） |
| 延迟特性 | 低延迟但吞吐受限 | 高吞吐但延迟略高 | 低延迟且高吞吐（固定形状） |
2.3 执行差异：调度、内存与精度
三种执行方式在工程实践中的差异远比理论复杂。首先是调度模型。CPU采用抢占式调度，操作系统负责上下文切换；GPU采用流（Stream）和事件（Event）模型，需要显式同步；NPU则通常采用任务队列（Task Queue）模型，驱动将多个算子打包成一个序列，由NPU硬件调度器顺序执行。这意味着在NPU上，算子之间的启动开销几乎为零，但一旦某个算子需要CPU介入（例如动态形状计算），就会产生严重的流水线停顿。
其次是内存布局。CPU和GPU通常默认使用NHWC（TensorFlow）或NCHW（PyTorch）布局，但NPU为了最大化MAC阵列利用率，往往要求特定的数据排布。例如，高通Hexagon要求激活值按NHWC且通道数对齐到32的倍数。如果自定义算子的输入来自CPU侧，delegate必须插入一个布局转换节点，这个转换本身可能消耗大量带宽。在编写自定义算子时，务必检查NPU SDK提供的TensorLayout枚举，避免隐式转换。
最后是精度策略。CPU默认FP32，GPU常用FP16混合精度，而NPU为了追求极致能效比，通常采用INT8量化。这意味着自定义算子在NPU上执行时，输入张量可能已经是反量化的定点数。如果我们的算子内部需要累积中间结果，必须注意累加器的位宽（通常为INT32），并在输出前进行缩放（Scale）和零点（Zero Point）偏移。忽略这一点，轻则精度下降，重则数值溢出导致NaN。
2.4 案例拆解：一个Conv2D算子在不同硬件上的执行路径
为了直观理解差异，我们以一个3x3 Conv2D（输入特征图112x112x64，输出112x112x128）为例，观察其在三种硬件上的执行表现。
背景与约束：目标设备为高通骁龙8 Gen 2，包含Cortex-X3 CPU、Adreno 740 GPU和Hexagon NPU。模型为MobileNetV2，要求端到端延迟小于10ms，功耗低于500mW。
初始现象：纯CPU执行时，该Conv2D耗时约3.2ms，功耗约450mW；GPU执行耗时约1.1ms，但功耗达到800mW；NPU执行耗时仅0.4ms，功耗约120mW。显然NPU在延迟和功耗上均占优。
分析过程：进一步剖析NPU执行路径。首先，TFLite delegate将Conv2D+BN+ReLU6合并为一个复合算子，并映射到Hexagon的Conv2D_3x3指令。输入张量在DDR中的布局为NHWC，但NPU要求通道对齐到32，因此驱动自动插入了PadChannel操作，将64通道补齐到96（浪费了32个通道的存储和计算）。然后，数据通过DMA搬运到NPU的SRAM，MAC阵列以脉动方式计算，输出结果再通过DMA写回DDR。整个过程中，CPU仅在启动和结束时介入，中间无中断。
实际操作步骤：我们尝试优化。第一步，在模型转换时设置--allow_custom_ops并手动指定输入布局为NCHW，但发现Hexagon对NCHW支持不佳，反而增加了转换开销。第二步，修改自定义算子的注册信息，将输入通道数从64改为96（在CPU侧提前Pad），消除了NPU侧的隐式Pad操作。第三步，将后续的ReLU6融合进Conv2D的激活参数中，减少一次SRAM读写。优化后，该算子耗时降至0.3ms，功耗降至100mW。
结果对比与复盘：优化前后延迟降低25%，功耗降低17%。关键经验是：NPU的性能瓶颈往往不在计算本身，而在内存对齐和算子融合。自定义算子注册时，应主动声明对齐要求，并尽可能将相邻的激活函数、归一化操作融合到主算子中，减少NPU与CPU之间的同步点。
2.5 常见误区与总结复盘
在理解NPU和delegate时，开发者常陷入以下误区：
- 误区一：认为NPU支持所有算子。实际上，NPU对动态形状、字符串处理、稀疏计算的支持极差。一个包含
tf.where或tf.range的模型，即使其他部分都是Conv，也可能因为图分区失败而整体回退到CPU。 - 误区二：忽略量化误差。NPU的INT8推理要求权重和激活值都经过校准。如果自定义算子内部有敏感的计算（如Softmax），直接量化可能导致精度崩溃。此时应考虑混合精度，将该算子留在CPU执行。
- 误区三：将delegate视为简单的函数调用。Delegate的初始化可能涉及加载NPU固件、分配专用内存池、编译子图等耗时操作。如果每次推理都重新创建delegate，开销会非常大。正确做法是复用delegate实例，并预编译子图。
- 误区四：忽视内存拷贝。当NPU和CPU共享同一物理内存时（如ION buffer），可以零拷贝访问。但若使用普通malloc内存，则每次推理都需要两次DMA拷贝。自定义算子应优先使用框架提供的内存分配接口（如
IsValidBuffer检查）。