OpenNVR实测高通NPU加速视频检测

OpenNVR 0.1.10 把摄像头后面的 AI 推理接到了 Qualcomm Hexagon NPU 上。作者真正有价值的发现，不只是模型能跑，而是推理加速之后，瓶颈转移到了 CPU 上的图片处理，部署链路里还藏着几种会让测试结果失真的静默回退。

如果你在做本地视频分析、边缘 AI，或者需要给推理服务接硬件加速，这篇值得读。它提供了一套部署和验收思路，但原文缺少几组关键测试结果，不能据此判断完整的性能收益。

NPU 加速后，慢的可能已经不是模型

OpenNVR 是采用 AGPL 许可证的开源网络录像系统（NVR），支持通过 ONVIF 或 RTSP 接入摄像头、录像和串流，也能运行用户选择的模型，包括 YOLO 检测、姿态估计、人脸识别、车牌 OCR、开放词汇检测，以及能观察场景并推理的视觉语言智能体。系统运行在自有硬件上，可按需断网部署，并审计每次推理。

0.1.10 首次提供硬件加速版本。作者实测的是 Arduino Ventuno Q：搭载 Qualcomm Dragonwing IQ-8275（QCS8275）、八核 ARM、Hexagon NPU，运行 Ubuntu 24.04，是一块小型无风扇设备。

作者分别考虑了单帧 YOLO、包含视频流与解码等任务的完整系统，以及处理一张 1080p JPEG 的适配器调用。但提供的原文中，这几处测试标题下面没有具体数据，无法比较 CPU 与 NPU 的完整延迟或吞吐。

能确认的数字是：一次适配器调用里，NPU 推理约占 9 ms，其余时间主要花在繁忙 CPU 上的 JPEG 解码和预处理。

模型跑得更快，不等于整个请求会按同样比例变快。

这也是这组实验最有用的提醒：优化对象应该是请求全链路，而不是单独一个推理函数。

容器能启动，还得证明模型确实用了 NPU

OpenNVR 通过 ONNX Runtime 的 QNN execution provider 使用加速器，相关能力由 onnxruntime-qnn 插件 wheel 提供。宿主机不需要安装 Qualcomm SDK，但仍需向 -qualcomm 容器开放 DSP 设备节点、DMA heap，并绑定挂载两个宿主机库。

启动脚本会探测 /dev/fastrpc-cdsp，自动选择 Qualcomm 版本；也可通过 OPENNVR_ACCEL=cpu|intel|qualcomm 指定。只有 CPU 的机器继续使用原来的镜像。编译后的计算图会缓存，第二次启动可跳过约 6 s 的编译。

这里更关键的是可观测性。系统会报告 ONNX Runtime 实际使用的 provider；如果请求加速器却回退到 CPU，指标里会出现 requested != effective。

作者踩过三个与此直接相关的坑：

• 把插件 provider 写进 providers= 列表，会被静默忽略，需要通过 add_provider_for_devices 按设备挂接。
• python:slim 缺少 libatomic1，会导致 HTP 后端加载失败，session 无报错地回退到 CPU。
• 最初测出的漂亮「NPU 延迟」12 ms，实际来自 session 失败后启用的占位检测器（stub detector），并非真实模型。

因此，健康检查端点和 degraded 计数器也是性能验收的一部分。

作者还遇到了 Ubuntu 镜像所带 Docker Compose 2.24.6 在创建时随机丢失容器第二个网络的问题。安装器为此增加版本检查，并在每次 up 后修复网络成员关系。这属于该部署环境的故障记录，不能直接推断所有环境都会复现。

怎么测，才能避免拿到一个漂亮的假数字

原文提供了两条命令，用来分别测试 CPU 和 QNN HTP：

python -m detect_pipeline.bench --latency 200 --providers CPUExecutionProvider
python -m detect_pipeline.bench --latency 200 --providers QNNExecutionProvider:htp

重点看 --providers：工具不仅报告每个设备的 median、p90 和 min，还会说明真正执行的 provider；加速器回退时，以非零状态退出。这样验收脚本才能识别「命令跑完了，但加速没生效」。

同一版本还列出了通过 OpenVINO 支持 Intel iGPU 和 NPU、VAAPI 解码、可选的签名自更新，以及摄像头轮播、CSV/Excel 导入导出和批量操作。app SDK 的 Look、Investigate 步骤可用于编写摄像头工作流。

这些功能列表不能当作跨平台性能结论。作者明确表示自己只有一块板卡，并希望借到 Jetson、Rockchip 或 Hailo 设备继续测试；所给内容也没有提供 NVIDIA、桌面 GPU 或 Jetson 的实测结果。

我的判断

我认可作者把「实际执行了什么」放到性能数字前面。占位结果、CPU 回退和后端加载失败都可能让接口正常返回，单看耗时很容易得出错误结论。

但这篇更适合作为工程排障记录，暂时不足以支撑硬件选型。提供的原文没有完整的 CPU/NPU 对照、模型配置和测试窗口；作者提到这些细节在 benchmark 文档里，这里无法核实。9 ms 也只是一次调用中的 NPU 部分，不能直接换算成摄像头并发能力。

与 CPU 部署相比，这条路线增加了设备透传、宿主机库和 provider 配置的复杂度。是否划算，需要在目标设备上测完整业务链路。宿主机免装 Qualcomm SDK，确实减少了安装步骤，但没有消除硬件依赖。

能拿来做什么

• 给本地推理服务增加「请求的后端」和「实际执行的后端」指标，并让不符合预期的回退在验收阶段直接失败。
• 在边缘视频项目中，分别记录推理、JPEG 解码和预处理耗时，再测完整系统，避免只围着模型做优化。
• 把真实模型是否加载成功加入健康检查。如果 Node 服务调用推理容器，也应识别降级状态，防止把占位输出当成有效识别结果。
• 评估同类板卡时，先运行原文的 CPU/QNN 基准，再加载视频流、解码、跟踪和 API，观察共享 CPU 后的端到端表现。