同一颗芯片，同一个模型，两次测出来的延迟是 134.7 毫秒 和 5.03 毫秒。测试对象是跑在高通 Dragonwing RB3 Gen 2（QCS6490）上的 YOLOv11-N，测量环境是高通 AI Hub 的真机工作台。差别不在模型，也不在芯片，而在走的是哪条运行时路径。

六条路径里，有两条给出了可用的数字，另外四条直接失败。失败的部分反而更值得看。

  • 路径一最危险：它能跑通。只是它悄悄把网络的大部分放在了 GPU 和 CPU 上。如果没有逐层性能分析，记录下来的结论就会是"RB3 Gen 2 跑 YOLOv11-N 需要 134.7 毫秒"，然后就此收工。
  • 路径三的失败没有任何路标：一次上下文二进制转换，只返回一个退出码。相关任务详情已提交到上游（qualcomm/ai-hub-models#364）。
  • 路径四是经典情形："编译通过"不等于"能跑起来"。图组合是在设备上单独的一道关卡，它可以说不。
  • 路径六是对照组：在一台旗舰手机上，即便是默认的 TFLite 委托也能把全部计算落到 NPU 上。坏掉的默认行为只属于边缘 SoC 这条路径，与模型无关，也与 TFLite 本身无关。

由此得到一条规则：不带路径的延迟数字不算一次测量。运行时、精度、层的落点，都是这个数字的一部分。逐层性能分析是唯一能区分"NPU 慢"和"NPU 根本没拿到活"的证据，而这两个结论指向完全相反的决定——换芯片，还是换导出设置。

同样的毛病在瑞芯微板子上反复出现：一个 RKNN 模型可以逐算子地悄悄回退到 CPU。厂商不同，工具链不同，失效模式一模一样——默认路径是乐观的，性能分析不会说谎。

做边缘 AI 基准测试，就把路径和数字一起公布。读到一份没写路径的基准，现在至少知道它可能藏了什么。