我们如何在 CI 中捕获 Snapdragon 上的静默 NPU 回退 [D]

发布这篇文章是因为我在多个向 Snapdragon 部署机器学习的团队中都看到了这个确切的错误，这个模式值得记录下来。ONNX Runtime 的 QNN 执行提供程序（针对 Snapdragon SoC 上 Qualcomm 的 Hexagon NPU 的那个）会将不受支持的操作静默地路由到 CPU。你的精度没问题，在开发板上的评估延迟看起来也没问题，但生产环境中的延迟神秘地增加到了三倍，因为输入分布以不同的方式对回退路径施加压力——而运行时除了没人读的启动日志行之外，从不发出更响亮的警告。默认的中位数 N 延迟门控没有捕捉到这一点，因为回退创建了双峰分布，而中位数落在了快速集群上。 最终需要三点：1. **在真实硬件上运行**——模拟器在软件中实现 ISA，因此每个操作都被“支持”（出于错误的原因），而云 x86 根本不加载 QNN EP。2. **同时基于变异系数和中位数进行门控**——健康的 NPU 上 CV 为 2-5%，间歇性回退将其推高至 >15%。3. **解析 ORT 性能分析 JSON 并断言 NPU FLOP 百分比**——路由信息就在那里，但你需要选择 `profiling_level=detailed` 并进行后处理；默认的警告级别日志只说“23 个节点分配给 QNN，7 个给 CPU”。第三个是实际识别哪个操作回退的诊断，因此你可以将其替换为受支持的等效操作、固定 QNN SDK 或升级到固件。 我已经用实际的 Python（CV 门控函数 + ORT 性能分析解析器）写下了完整的模式：[https://edgegate.frozo.ai/blog/how-we-catch-silent-npu-fallback-on-snapdragon-in-ci](https://edgegate.frozo.ai/blog/how-we-catch-silent-npu-fallback-on-snapdragon-in-ci) 好奇这里是否有人遇到过类似的在 Jetson 上使用 TensorRT 或在 iOS 上使用 CoreML 的静默回退模式——我预料会出现症状（双峰延迟、静默提供程序路由），但还没有深入挖掘。ExecuTorch 也是如此。