Skip to main content
AI / ML

简介

当多个 AI 模型在 Qualcomm 设备上并发运行时,利用率的可见性变得至关重要。对于 CPU 工作负载,/proc/stat 提供了负载的直接视图。而对于基于 Hexagon DSP 的 NPU 工作负载,没有等效的标准 Linux 接口可以实时暴露 Q6、HVX(Hexagon Vector eXtensions)和 HMX(Hexagon Matrix eXtensions)的利用率。 没有直接的遥测数据,推理延迟只是一个间接信号。它可以表明性能发生了变化,但不能说明原因。团队无法可靠地判断加速器是否被使用、DSP 是否饱和,或者是否有余量运行更多模型。 本指南将带您从源码构建 libqcperf,并编写一个最小的 C 程序,将实时 NPU 指标流式传输到您自己的应用程序中。

为什么现有途径不够用

官方的 Qualcomm Profiler 不适合许多开放工作流,因为它需要 NDA 访问权限。 Hexagon SDK 中的 SysmonApp 可以通过 FastRPC 查询 CDSP 利用率,但它是一个离线流程:采集到二进制 .bin 文件,传输到主机,然后后处理为 HTML 或 CSV。这适用于一次性性能分析,而不是应用代码中持续的设备端遥测。 Hexagon QuRT PMU 计数器是另一个选择,但它们需要 DSP 端的插桩以及配合 Hexagon 工具链产物的部署。当目标是从标准 Linux 进程进行应用层监控时,这是一个很高的门槛。

您将完成的工作

  1. 确认设备上存在 FastRPC。
  2. 克隆并构建带 NPU 后端的 libqcperf。
  3. 使用 libqcperf API 编写并构建一个最小的 C 程序。
  4. 运行它,观察实时的 Q6、HVX 和 HMX 指标流式输出到 stdout。

前提条件

libqcperf 通过 FastRPC 与 CDSP 通信。在执行以下任何操作之前,设备需要启用 Qualcomm 外设并具备 FastRPC 用户空间。还需要安装 DSP 服务的头文件。 请先按照 IQ8 设备页面完成设置,然后再回到这里: 重启后,确认 FastRPC 存在:
如果 /dev/fastrpc-cdsp 不存在,则内核缺少 FastRPC 支持。这是 BSP 或镜像问题,不是您能在用户空间修复的。 您需要运行以下命令将您的用户添加到 fastrpc 组,然后注销并重新登录。
您还需要标准构建工具以及 DSP 头文件:

构建 libqcperf

所有工作都位于 ~/libqcperf-build 中。每个代码块都以自己的 cd 开头,因此您可以将任何代码块粘贴到新终端中,而无需跟踪当前所在目录。

克隆仓库

配置和构建

NPU 后端默认关闭。请显式启用它。此构建直接针对主机设备(原生 aarch64),因此不需要交叉编译工具链:
构建会产生 C 示例所链接的静态库归档:

编写 C 集成

对于应用层集成 — 将 NPU 遥测直接嵌入推理循环、将指标与延迟测量关联,或触发自适应行为 — 请直接使用 libqcperf API。 完整生命周期为九个步骤。这是一个最小但完整的程序,将全部四个 NPU 指标流式输出到 stdout。

程序

创建源文件:
将其保存为 ~/libqcperf-build/example/npu_monitor.c。

构建示例

该示例链接到之前构建产生的同一批静态库归档:

运行

预期输出(模型运行时每秒一个块):
按 Ctrl-C 停止。库在收到 SIGINT 时会干净地关闭。

底层原理

采样率与流式传输率

这两个参数相互独立,用途不同。 采样率(上面示例中为 100 毫秒)控制后台线程通过 FastRPC 调用 CDSP 读取原始硬件计数器的频率。较低的值提供更精细的时间分辨率,但会增加 FastRPC 开销。NPU 后端支持 1、5、10、50、100 和 200 毫秒。 流式传输率(1000 毫秒)控制后台线程触发数据回调的频率。每次回调交付包含自上次交付以来收集的所有样本 — 在 100 毫秒采样 / 1000 毫秒流式传输下为十个样本。回调以扁平的 metric_response 数组接收它们;上面的示例使用位掩码只提取每个指标最近的样本。 支持的流式传输率为 100 毫秒到 1000 毫秒,以 100 毫秒为步长。

FastRPC 路径

libqcperf 不会打开内核驱动或读取 sysfs 文件。它通过 FastRPC 调用 sysmonquery_get_profdata — 这与 llama.cpp 和 LiteRT-LM 用于将计算分发到 CDSP 的处理器间 RPC 机制相同。该调用穿过内核 FastRPC 桥(/dev/fastrpc-cdsp),并直接从 DSP 固件返回包含四个硬件计数器值的结构体。 运行时依赖是 libcdsprpc.so。这个共享库作为 FastRPC 用户空间的一部分已经存在于 Qualcomm Ubuntu 镜像中。如果它不存在,动态链接器会在到达 main 之前就无法启动进程。

后台线程

qcperf_start 会派生一个名为 qcperf_dsp_npu_thread 的单一后台线程。该线程在整个监控会话期间拥有 FastRPC 会话。您的数据回调是从这个线程调用的,而不是从调用 qcperf_start 的线程。请保持回调快速;任何阻塞工作都应交给队列处理。

解读指标

实时遥测将 NPU 从黑盒变为可观测的子系统。 几个值得了解的模式: 量化推理期间 HMX 低是最常见的意外。如果您预期量化模型在 NPU 上运行,但 HMX 利用率接近零,则工作负载没有走预期的加速器路径。常见原因:模型编译时未启用 HMX 算子、QNN 上下文二进制文件版本与设备端运行时不匹配,或模型正在回退到 CPU。 HVX 高、HMX 低表明模型在运行向量化但没有矩阵加速 — 这是 FP16 或非量化路径的典型情况,或者模型使用了 HVX 友好的算子(池化、归一化)但没有 INT8/INT4 矩阵乘法。 负载下 Q6 时钟逐级上升是 DCVS 正常工作。如果利用率高时时钟没有上升,请检查是否有功耗配置文件限制了 CDSP 频率。 推理运行时所有指标接近零通常意味着工作负载在 CPU 而非 DSP 上执行。用 htop 确认并检查您模型的后端配置。

故障排除

后续步骤

有了实时 NPU 遥测,自然的下一步是观察真实模型的运行: