1. 项目概述为什么我们需要关注NPU的“心跳”最近几年嵌入式开发和边缘计算领域最火的话题之一就是各种片上系统SoC集成的专用AI加速器也就是我们常说的NPU神经处理单元。从手机到开发板从智能摄像头到工业网关NPU正在成为新一代智能设备的标配。我手头这块Banana Pi BPI-M7开发板搭载的正是瑞芯微Rockchip的旗舰芯片RK3588它内置的算力高达6 TOPS的NPU是跑本地大语言模型、实时图像识别这些重负载AI任务的利器。但问题来了。当你费尽心思把模型转换、部署到板子上看着程序跑起来你怎么知道它真的在“用”NPU而不是偷偷跑在CPU或者GPU上更进一步当程序声称在调用NPU时它的负载到底是多少三个核心是均匀分配任务还是只有一个在满负荷运转其他在“摸鱼”这些信息对于性能调优、功耗评估和故障排查至关重要。然而和CPU、内存有top、htop、free这些成熟工具不同NPU的监控在Linux生态里还处于“蛮荒时代”各家厂商都有自己的“土办法”。这篇文章我就以手头的Banana Pi BPI-M7RK3588为例带你彻底搞懂如何在Linux系统下像监控CPU一样实时、清晰地监控Rockchip NPU的使用情况。这不仅仅是运行几个命令我会深入解释这些命令背后的原理分享从系统内核到用户脚本的完整监控方案并附上我实际部署AI应用时踩过的坑和总结的实用技巧。无论你是正在评估RK3588的AI性能还是已经部署了应用需要优化这篇文章都能给你提供直接的、可操作的参考。2. 核心原理Rockchip NPU的监控机制是如何工作的在开始敲命令之前我们有必要先搞清楚系统到底是通过什么途径向我们“汇报”NPU的工作状态的。理解了这个你不仅能明白下面所有操作的意义还能在遇到问题时自己找到排查方向。2.1 内核的“后门”DebugFS文件系统Rockchip选择了一种在Linux内核开发中非常经典且直接的调试方式DebugFS。你可以把它理解成内核专门为开发者开的一个“后门”或者“仪表盘”。与/proc文件系统类似DebugFS通常挂载在/sys/kernel/debug/也是一个虚拟文件系统它不占用真实的磁盘空间里面的文件直接映射到内核中的数据结构或函数。当内核中Rockchip NPU的驱动程序通常是rknpu驱动被加载并初始化后它就会在DebugFS中创建一个专属的目录例如/sys/kernel/debug/rknpu/并在里面生成一些可供读取的文件。我们最关心的那个文件——load就是驱动内部一个实时统计函数的输出接口。当你用cat命令读取这个文件时内核会立刻执行对应的函数计算当前NPU各个核心的负载率然后将结果以纯文本格式返回给你。注意DebugFS默认可能没有挂载或者普通用户没有读取权限。这就是为什么我们经常需要sudo来执行这些监控命令。如果你的系统没有/sys/kernel/debug/rknpu/这个路径首先需要确认内核配置是否包含了NPU驱动和DebugFS支持。2.2 NPU负载数据的来源与计算逻辑那么驱动计算的“负载”到底是什么它通常不是像CPU那样统计时间片占用率而是基于NPU核心的当前工作状态空闲、繁忙和任务队列长度等信息进行估算的一个百分比。以RK3588为例它的NPU内部通常包含多个计算核心Core0, Core1, Core2。驱动会周期性地或在查询时检查每个核心状态寄存器核心是否处于运行RUN状态。任务队列有多少个计算任务神经网络层或算子正在排队等待该核心处理。驱动综合这些信息通过一个预设的算法比如运行状态权重高队列长度权重低折算出一个0%到100%的利用率。这个数值是瞬时的只代表你执行cat命令那一瞬间的状态。这就是为什么单纯跑一次cat命令在NPU空闲时看到全是0%而在运行AI任务时可能看到某个核心瞬间跳到90%以上。2.3 与其他系统监控组件的对比理解DebugFS的定位能帮助我们建立正确的使用预期vs. /proc 或 /sys/proc和/sys下的信息更多是面向系统管理和配置的静态或半静态信息如CPU型号、内存总量、设备树。而DebugFS下的信息动态性、实时性更强更偏向于内核模块的深度调试。vs. 性能计数器PMU一些高端的NPU会提供硬件性能计数器可以精确统计执行的指令周期、内存访问次数等。DebugFS提供的负载信息可以看作是对硬件计数器数据的一种高层、易读的封装和摘要。目前Rockchip公开的接口中DebugFS是最直接的用户层监控手段。3. 实操指南三种由浅入深的NPU监控方法理论清楚了我们进入实战环节。我将介绍三种监控方法从最简单的单次查询到接近top命令的实时监控满足不同场景的需求。3.1 基础确认你的系统识别NPU了吗在监控之前首先要确认你的Banana Pi BPI-M7系统已经正确识别并驱动了NPU。最可靠的方法不是看设备树而是看内核启动日志。打开终端输入以下命令dmesg | grep -i npu这个命令会在庞大的内核日志中过滤出所有包含“npu”不区分大小写的行。如何分析输出理想情况你会看到类似rknpu: rknpu driver initialized successfully或rockchip-npu: probe success这样的信息。这表明rknpu内核模块已成功加载并探测到硬件。常见问题没有输出很可能NPU驱动没有加载。你需要检查内核配置确保编译了CONFIG_ROCKCHIP_RKNPU等相关选项并尝试使用sudo modprobe rknpu手动加载模块。出现错误信息例如failed to get sram resource或ioremap failed。这通常是设备树Device Tree配置有问题NPU所需的内存资源或时钟未能正确分配。这需要你核对板级设备树文件.dts中关于NPU节点的配置是否与BPI-M7的硬件设计一致。实操心得在烧录第三方或自己编译的固件后第一步就应该执行这个检查。我遇到过因为内核版本不匹配驱动编译进去了但设备树节点名称不对导致驱动加载失败的情况。dmesg | grep -i npu是硬件就绪性的“第一道安检”。3.2 实时监控方案一使用watch命令进行周期轮询确认NPU驱动正常后我们就可以读取它的负载信息了。最直接的文件路径是sudo cat /sys/kernel/debug/rknpu/load但正如前面原理部分所说这只是一次“快照”。为了看到变化我们需要让它周期性地刷新。Linux下的watch命令就是干这个的。执行以下命令watch -n 1 sudo cat /sys/kernel/debug/rknpu/load-n 1指定刷新间隔为1秒。你可以根据需求调整比如-n 0.5就是0.5秒。sudo cat ...这是watch要周期性执行的命令。执行效果与解读 终端会清空并固定显示一个动态更新的界面例如Every 1.0s: sudo cat /sys/kernel/debug/rknpu/load NPU load: Core0: 12%, Core1: 0%, Core2: 95%解读此时我的板子上可能运行了两个AI任务。一个轻量级任务只占用了Core0的12%算力而一个重型任务比如一个大模型的推理几乎吃满了Core295%Core1则处于空闲状态。这清晰地展示了NPU核心间的负载不均衡。优点简单直接无需额外工具。刷新间隔可自定义。缺点屏幕输出不会滚动历史只显示当前瞬间值。按CtrlC退出后所有输出消失不便于事后分析。如果NPU负载变化极快毫秒级1秒的间隔可能错过峰值。注意事项watch命令默认会用clear命令清屏这可能导致在串口终端或某些日志记录场景下你只能看到最后一屏数据。如果你需要记录连续的输出应该放弃watch采用下面脚本中的循环方法并将输出重定向到文件。3.3 实时监控方案二使用增强脚本ntop.sh社区开发者Pelochus在为RK3588优化LLM运行的项目ezrknpu中提供了一个更实用的脚本ntop.sh。它本质上是一个加强版的while循环但提供了一些便利功能。你可以直接创建一个名为ntop.sh的文件内容如下#!/bin/bash # 参数检查 if [[ $1 -h ]]; then echo echo ntop.sh Help echo echo -c: Clears output every refresh echo -h: Shows this help screen echo echo For more information visit https://github.com/Pelochus/ezrknpu echo exit fi CLEAR if [[ $1 -c ]]; then CLEARclear fi while true; do eval $CLEAR # 如果CLEAR为空这行什么也不做 sudo cat /sys/kernel/debug/rknpu/load sleep 0.5 # 监控间隔可调整例如 sleep 0.2 获得更高刷新率 done给脚本添加执行权限并运行chmod x ntop.sh ./ntop.sh # 默认不清屏输出会不断滚动 ./ntop.sh -c # 带-c参数每次刷新前清屏类似watch与watch命令的对比分析特性watch命令ntop.sh脚本 (不带-c)ntop.sh脚本 (带-c)显示方式清屏后显示当前值连续滚动输出历史值清屏后显示当前值历史追溯不支持支持可向上滚动查看不支持中断后输出消失保留在终端屏幕上消失刷新间隔通过-n设置最小约0.1秒通过sleep值设置可更精细如0.05秒同左自定义功能困难容易可在循环内添加时间戳、格式化等同左核心优势与使用场景故障排查场景推荐使用不带-c的模式当你的AI应用运行异常怀疑NPU调用有问题时让脚本在后台运行./ntop.sh npu_log.txt 它会把所有时间点的负载记录到文件。事后你可以分析这个日志文件看看在程序崩溃或报错的时间点附近NPU负载是否有异常波动例如突然降为0可能驱动崩溃。性能分析场景观察一个AI任务从开始到结束的全过程。滚动输出的历史记录能让你看到负载是如何上升、达到平台期、然后下降的有助于判断任务是否完全利用了NPU以及计算瓶颈在哪里。自定义扩展你可以轻松修改这个脚本。例如在cat命令前加上date命令来为每一行输出添加精确的时间戳或者使用awk命令只提取某个核心的负载值进行绘图。踩坑记录我最初使用watch命令时有一次为了抓取一个偶发的性能下降问题守了半天屏幕。后来问题复现了我却因为手忙脚乱没看清瞬间的数值。自从改用这个脚本并重定向输出到文件后任何偶发问题都能通过分析日志文件找到线索。对于严肃的开发和调试能够记录历史的工具远比只能看实时画面的工具重要。4. 让监控有意义如何让NPU“动”起来监控工具准备好了但如果你不运行任何AI任务那么监控窗口里将永远是一片祥和的0%。这就像给一辆顶级跑车装上了转速表和时速表却从不启动发动机。下面我们来聊聊如何让你的RK3588 NPU真正“负载”起来从而验证监控的有效性。4.1 寻找与运行现成的NPU示例程序最快捷的方式是使用芯片厂商或开发板社区提供的示例。检查SDK或镜像许多为Banana Pi BPI-M7或RK3588定制的Linux发行版如Armbian、官方Debian/Ubuntu镜像可能会在/usr/share或/opt目录下预置NPU示例。使用find命令搜索sudo find /usr -name *npu* -type f 2/dev/null sudo find /opt -name *npu* -type f 2/dev/null你可能会找到一些C或Python的Demo程序。使用Rockchip官方示例访问Rockchip的GitHub仓库或Wiki搜索“rknpu”或“rknn”。RKNN是Rockchip的神经网络推理框架。官方通常会提供编译好的rknn_demo或rknn_benchmark工具以及配套的测试模型如mobilenet_v1.rknn。运行这些Demo你的NPU监控窗口应该立刻看到变化。运行社区AI项目正如原文提到的ezrknpu项目它专注于在RK3588上使用NPU运行大型语言模型LLM。克隆并按照其README编译运行你会看到NPU负载随着文本生成而剧烈波动这是对NPU压力测试和监控的绝佳场景。4.2 解读负载输出从数字到性能洞察当你运行起一个AI任务后监控工具会输出类似Core0: 85%, Core1: 10%, Core2: 0%的信息。这不仅仅是几个数字负载不均如果只有Core0高负载其他核心很低可能意味着你运行的AI模型或推理任务没有很好地支持多核并行。RK3588的NPU有3个核心理想情况下大型模型应该能调度到多个核心上运行以加速推理。这可能受限于模型本身的分割、RKNN驱动版本或推理框架的调度策略。负载波动对于一个持续的视频流分析任务负载应该保持在一个相对稳定的高位。如果你看到负载像锯齿一样剧烈跳动例如从90%瞬间到5%又跳回去可能意味着流水线不顺畅NPU经常在等待CPU准备数据如图片预处理或取回结果如后处理存在性能瓶颈。负载与功耗/发热在高负载下比如持续80%用手触摸开发板上的RK3588芯片散热片或附近区域感受温度变化。同时你可以用sudo armbianmonitor -m如果使用Armbian或其他工具监控CPU频率和系统整体功耗。NPU高负载时SoC的整体功耗会显著上升这关系到你的设备散热设计和电源选型。4.3 压力测试与稳定性验证为了全面评估NPU你可以设计一个简单的压力测试循环#!/bin/bash # npu_stress_test.sh DEMO_PROGRAM/path/to/your/rknn_demo # 替换为你的Demo路径 MODEL_FILE/path/to/your/model.rknn # 替换为你的模型路径 echo Starting NPU stress test. Monitor with another terminal using ntop.sh for i in {1..100}; do echo Iteration $i $DEMO_PROGRAM $MODEL_FILE /dev/null 21 sleep 1 # 间隔1秒模拟间歇性任务 done echo Stress test finished.运行这个脚本同时在另一个终端用./ntop.sh -c监控。观察长时间运行是否稳定负载百分比是否始终正常运行几十轮后系统是否会报错或死机早期固件可能存在内存泄漏或驱动稳定性问题。温升情况持续运行半小时后芯片温度是否达到平衡是否会触发温降频可以用cat /sys/class/thermal/thermal_zone*/temp监控温度5. 进阶技巧与深度问题排查掌握了基本监控方法后我们可以探讨一些更深入的问题和技巧这些往往是在实际项目开发中才会遇到的“深水区”。5.1 监控数据的记录、可视化与分析对于性能分析和长期测试将数据记录下来并画成图表远比盯着终端看更有价值。方法一使用脚本记录数据创建一个记录脚本log_npu.sh#!/bin/bash LOG_FILEnpu_usage_$(date %Y%m%d_%H%M%S).log echo Timestamp, Core0(%), Core1(%), Core2(%) $LOG_FILE echo Logging NPU usage to $LOG_FILE. Press CtrlC to stop. while true; do TIMESTAMP$(date %Y-%m-%d %H:%M:%S.%3N) # 使用tr删除冒号和空格并用逗号分隔 USAGE$(sudo cat /sys/kernel/debug/rknpu/load | awk -F: {print $2, $3, $4} | tr -d %, | tr ,) echo $TIMESTAMP, $USAGE $LOG_FILE sleep 0.1 # 以100ms的高频率记录 done运行此脚本它会生成一个CSV格式的日志文件。之后你可以将文件拷贝到PC上用Python的PandasMatplotlib或Excel轻松绘制出三个核心的负载随时间变化的曲线图。方法二与系统监控工具集成更专业的做法是将NPU负载作为一个指标集成到像PrometheusGrafana这样的监控栈中。这需要编写一个小的exporter。思路是创建一个简单的Python HTTP服务定期读取/sys/kernel/debug/rknpu/load将其解析为Prometheus支持的metrics格式例如npu_core_usage{core0} 12.0。这样你就能在Grafana上创建一个与CPU、内存、网络并列的NPU监控仪表盘实现真正的全景式监控。5.2 常见问题排查清单当监控发现异常时可以按照以下清单进行排查现象可能原因排查步骤/sys/kernel/debug/rknpu/load文件不存在1. DebugFS未挂载。2. NPU驱动未加载或加载失败。3. 内核未配置NPU驱动。1. mountNPU负载始终为0%但AI程序在运行1. 程序未调用NPU跑在CPU上。2. 使用的RKNN模型版本与驱动不兼容。3. 程序运行时权限不足。1. 用htop观察CPU占用是否激增。2. 确认程序使用了RKNN API (rknn_init,rknn_run)。3. 尝试用sudo运行程序。NPU负载显示为异常值如负数或100%驱动内部统计计算Bug。1. 升级内核或NPU驱动到最新版本。2. 作为已知问题记录不影响基本使用。监控命令执行卡住或无响应1. NPU驱动内核模块可能死锁或崩溃。2. DebugFS文件系统异常。1. 尝试sudo rmmod rknpu然后sudo modprobe rknpu重新加载驱动。2. 检查系统日志journalctl -k寻找内核错误。只有部分核心有负载1. AI任务计算量小单核即可满足。2. 模型或框架不支持多核调度。3. 驱动或固件对多核支持有缺陷。1. 运行一个更大的模型如ResNet50 vs MobileNet。2. 查阅RKNN文档确认多核推理的配置方法。3. 尝试不同的官方示例交叉验证。5.3 性能调优的初步思路监控的最终目的是为了优化。当你通过监控发现了性能瓶颈可以尝试以下方向模型优化使用Rockchip提供的RKNN-Toolkit2对原始模型如ONNX、TensorFlow Lite进行量化INT8精度往往比FP16快很多、剪枝和算子优化。一个优化后的RKNN模型在相同精度下NPU利用率可能更高计算更密集或利用率更低因为算得更快空闲时间更多。流水线优化如果发现NPU负载锯齿状波动说明NPU在等待。尝试使用双缓冲或多线程技术让一个线程专门负责图像预处理并填充缓冲区A另一个线程负责从缓冲区B取数据送NPU推理并处理结果。当NPU在处理B时CPU同时在准备A两者重叠可以显著提升整体吞吐率使NPU负载曲线变得更平稳、更高。核心绑定对于一些对延迟极其敏感的应用你可以尝试通过修改程序或系统配置将负责NPU任务调度的CPU线程绑定到特定的CPU核心上减少缓存失效和上下文切换可能带来小幅的性能提升和更稳定的延迟。监控Rockchip NPU的使用情况虽然目前还没有一个像htop那样统一、美观的工具但通过深入理解其基于DebugFS的工作原理并灵活运用watch命令、自定义脚本乃至集成到专业监控系统我们完全可以实现对这颗AI核心的透明化、可量化的观察。从确认硬件就绪到观察任务运行再到深度性能分析和故障排查这套方法贯穿了基于RK3588进行AI应用开发的全生命周期。