NPU Delegate 接入跑到加速器上不等于真的加速很多边缘 SoC 都带 NPU厂商也会提供 TensorFlow Lite Delegate、RKNN、SNPE、NNAPI 之类工具。模型能跑到 NPU 上当然好但“跑上去”不等于“真的加速”。如果算子频繁回退 CPU、输入输出拷贝太重、batch 形态不合适最终延迟可能还不如纯 CPU。接入 NPU Delegate要先看算子支持表再看数据拷贝路径最后用端到端数据说话。别只盯厂商 PPT 里的 TOPS。一、先确认算子是否完整支持模型里只要有几个关键算子不支持就可能被切成多段执行一段 NPU一段 CPU再拷贝回来。每次切换都有开销。flowchart LR A[输入 Tensor] -- B[NPU 支持算子] B -- C{遇到不支持算子} C --|是| D[回退 CPU] D -- E[拷贝回 NPU] C --|否| F[NPU 继续执行] E -- F因此模型转换报告很重要。要看哪些算子被 NPU 接管哪些回退回退是否在主干路径上。二、初始化和内存分配也要测很多 demo 只测单次 inference不测模型加载、delegate 初始化和 tensor 分配。实际产品里冷启动时间也很关键。uint64_t t0 now_us(); interpreter-ModifyGraphWithDelegate(delegate); uint64_t t1 now_us(); interpreter-AllocateTensors(); uint64_t t2 now_us(); printf(delegate%llu us allocate%llu us\n, t1 - t0, t2 - t1);如果初始化很慢交互式设备可能需要预热如果内存分配峰值过高低内存设备会不稳定。三、减少无意义拷贝NPU 加速常见瓶颈是数据搬运。摄像头出来的 NV12 数据先转 RGB再 resize再拷贝给 NPU每一步都要成本。能不能用硬件 ISP、RGA 或 DMA buffer 直接对接是工程关键。pipeline: camera: NV12 preprocess: hardware_rga tensor_memory: dma_buffer inference: npu_delegate postprocess: cpu_lightweight如果前处理全在 CPU 上跑NPU 再快也可能等数据。边缘 AI 是系统工程不是只优化模型文件。四、端到端延迟才是最终指标验收时要拆分摄像头采集、前处理、推理、后处理、业务动作。NPU inference 从 20ms 降到 5ms但前处理仍然 40ms用户不会觉得快多少。还要测连续运行。NPU 驱动、内存泄露、温升降频都可能在长时间运行后暴露。demo 成功只是第一步稳定跑一天才像产品。我还会做 CPU fallback 统计。很多工具链会在转换报告里提示但运行时仍可能因为动态 shape 或特殊输入走回 CPU。每次版本升级后把 delegate 分段结果保存下来和上一版比较。delegate_check: total_ops: 86 npu_ops: 79 cpu_ops: 7 cpu_fallback: [RESIZE_NEAREST, CUSTOM_NMS]如果 CPU 回退在后处理小算子上可能能接受如果在主干卷积或 attention 上就要重新改模型结构。NPU 加速要看主耗时路径不是看接管算子数量凑百分比。五、总结NPU Delegate 接入不能只看模型是否跑到加速器上。算子支持、CPU 回退、初始化、内存分配、数据拷贝和端到端延迟才决定它是否真的加速。边缘设备上快不快不是 TOPS 说了算是整条链路的毫秒数说了算。