从开箱到 NPU 实战：Quectel Pi M2 开发板深度测评— RK3576 + Debian 13 + YOLOv5 目标检测全流程实录
前言
过去两年，AI 的战场正从云端悄悄转移到边缘：摄像头要自己"看懂"画面，网关要自己"判断"异常，机器人要自己"决定"下一步动作。把算力从机房搬到设备旁边，换来的是更低的延迟和更好的隐私，代价是一块更烫手、更难伺候的板子。
Quectel Pi M2 并不是为这个趋势定制的"AI 专用板"。它首先是一块通用型单板计算机：RK3576 八核处理器、4GB 内存、64GB eMMC，预装 Debian 13，还带实时内核；40-pin 排针、双 MIPI CSI、千兆网口一应俱全，做网关、做控制、做多媒体都能胜任，而那颗标称 6 TOPS 的 NPU，只是它众多能力中的一项。
正因为它不是"AI 专用板"，我反而更好奇：这颗 NPU 到底好不好用？于是这次体验我没有按"参数巡礼"的方式写，而是挑了一个最能压榨硬件、也最容易暴露问题的方向——端侧目标检测，作为检验它的主线。这是我的选择，不是板子的全部。
拿到板子前，期待和怀疑同时存在：期待 6 TOPS 能换来多流畅的推理，也怀疑国产开发板常见的"参数好看、文档拉胯"会不会重演。所以我没有从参数表写起，而是从"插上电、打开终端"写起：一条命令能不能跑通官方 demo？换成自己拍的照片会不会翻车？标称的 20ms 一帧，放进真实场景还剩多少？——这些问题，才是决定一块通用板子能不能扛起 AI 任务的关键。
这篇测评会把这些过程原原本本记录下来：有顺畅的时候，也有卡住的时候；有和官方数据严丝合缝的复现，也有夜间场景里三处明晃晃的误检。板子能做的事远不止 AI，但如果你也正想用一块通用开发板扛起端侧智能任务，希望这些文字能帮你省下几个小时的试错时间。
摘要
Quectel Pi M2 是移远通信基于瑞芯微 RK3576 打造的通用型高性能单板计算机：八核处理器、实时内核、丰富扩展接口，可用于网关、控制、多媒体等多种场景；其标称 6 TOPS 的 NPU 只是众多能力之一。本文不做面面俱到的参数巡礼，而是选取端侧目标检测这一条主线，从开箱上电开始，完整走通「系统环境确认 → 官方 NPU 例程复现 → 自备图片目标检测 → 性能实测与调频对比 → 问题排查」全流程，全程以命令行为主，所有数据均为实测采集。
测试覆盖 5 张图片（1 张官方图 + 4 张原创照片）、3 种调频策略、5 个典型故障场景，累计采集 40 余条检测结果与 15 组耗时数据。
一句话结论：这是一块"开箱即用、上手门槛低"的通用开发板——作为我本次选择的体验方向，它跑端侧目标检测时预装模型、一条命令就能跑通 YOLOv5s，单帧推理约 20ms，NPU 这一能力经受住了考验；同时也有若干文档没写清楚的坑，需要提前知道。用来做边缘 AI 的项目验证完全够用，但离"开箱即演示 AI"还差一个摄像头和一份更细的避坑文档。
写在前面：测试目标与方法
作为移远产品体验官，拿到板子后我最想回答三个问题：
- 开箱能跑什么？ 预装的东西够不够撑起一个真实案例？
- 标称 6 TOPS 的 NPU，实际表现如何？ 和官方宣传数据对得上吗？
- 坑多不多？ 一个普通开发者能不能在一小时内跑通第一个检测？
为了避免"照着宣传册写评测"，本文遵循三条原则：
- 命令行优先：不依赖图形化工具，所有操作可复制、可复现；
- 数字必须实测：每个耗时、每个置信度都来自终端输出或截图，不引用官方数字充当结论；
- 问题上桌：误检、漏检、装不上、跑不起来，全部如实记录。
需要说明的是，本次测试没有外接 USB 摄像头（板子本身不带摄像头），因此实时视频检测不作为本次测试范围，全部采用图片输入的方式验证 NPU 推理链路。视频编解码、GPU、无线性能不在本次测试范围内。
一、开箱与硬件规格
1.1 核心配置
| 项目 | 规格 |
|---|---|
| 主控 | Rockchip RK3576，4×Cortex-A72 + 4×Cortex-A53 |
| NPU | 6 TOPS（INT8），支持 INT4/INT8/FP16 量化 |
| 内存 | 4GB（系统识别 3.8GiB） |
| 存储 | 64GB eMMC（根分区 42GB，可用约 35GB） |
| 视频 | 支持 8K 级解码 / 4K 编码（官方标称） |
| 网络 | 千兆以太网 + 板载无线模组 |
| 扩展 | 40-pin 排针（兼容树莓派配件）、MIPI CSI ×2、TF 卡槽、风扇接口 |
| 供电 | USB-C |
图 1 正面：双 USB-A、HDMI、USB-C 供电、千兆网口、MIPI CSI 排线座、40-pin 排针一应俱全，蓝色电源灯点亮
图 2 背面：RK3576 核心模组屏蔽罩与 MIPI CSI/FAN 丝印清晰可见，板载无线模组带金属屏蔽罩
1.2 接口逐一看
对着板子从左上到右下走一遍，接口可用"一个不少"来形容：
| 接口 | 位置 | 实测用途 |
|---|---|---|
| USB-A ×2 | 左侧 | 上方为 USB 3.0（蓝色胶芯）、下方 USB 2.0；键鼠即插即用，实测同时接键盘鼠标无冲突 |
| USB-C | 顶部 | 供电 + OTG；实测 5V 电源即可点亮 |
| HDMI | 右侧 | 接 1080p 显示器，开机直接出画面，无需配置 |
| RJ45 千兆网口 | 左下 | 有线网络，插上即通 |
| MIPI CSI 排线座 | 中部（FAN/CSI 丝印） | 摄像头接口，本板为空座 |
| 40-pin 排针 | 底部 | GPIO/I2C/SPI/UART，布局兼容树莓派配件 |
| TF 卡槽 | 中部 | 系统备份、扩容 |
| 电源/复位按键 | 右侧 | 短按开机、长按断电 |
对做项目的人来说，这套接口的含义很直接：传感器走 40-pin、视觉走 MIPI CSI、网络走千兆网口、调试走 USB，覆盖了绝大多数边缘计算场景的连接需求，不需要额外买转接板。
1.3 形态与做工
板子采用了「核心模组 + 底板」的模块化设计（丝印 OSM6102AP 中的 OSM 对应 Open Standard Module 标准模块形态），核心模组被金属屏蔽罩完整覆盖，同时承担散热作用——实测连续跑推理十几分钟，屏蔽罩温热但不烫手，被动散热足够，无需加装风扇。
焊点饱满、丝印清晰，40-pin 排针焊接平整，整体做工对得起"工业级"的定位。
1.4 开箱第一印象
板子比想象中小巧，一张名片左右的面积，布局紧凑。上电后蓝色指示灯亮起，HDMI 直接出画面，从插电到进入桌面大约 30 秒。
唯一的"硬件遗憾"：板子没有内置摄像头，MIPI CSI 座是空的，USB 摄像头需要自备。这一点官方文档提到过，但新手容易忽略（后文"问题"章节有详细记录）——毕竟大多数人是奔着"AI 板子能看会认"来的。
二、系统与开箱体验
2.1 桌面环境
预装基于 Debian 13（trixie）的 GNOME 桌面，中文界面，常用软件一应俱全：
- 基础：终端、文件管理器、文本编辑器、截图工具
- 网络：Firefox 浏览器
- 工具：日历、录音机、天气、时钟、地图、文档扫描仪
- 特色：NPU TEST 等自家工具入口
图 4 开箱即用的 Debian 13 桌面，中文环境，常用软件已预装
对第一次接触的人来说，这个桌面最大的价值是"不用配"——不用配网络、不用装驱动、不用折腾显示，插上就能用。对老手来说，它意味着你可以随时打开终端，把板子当纯命令行设备用。
2.2 系统信息确认
uname -a && cat /etc/os-release | head -4 && free -h && df -h / ~ | tail -2
实测输出：
Linux linaro-alip 6.1.118-rt36 #1 SMP PREEMPT_RT Tue Sep 22 04:29:16 UTC 2026 aarch64
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
total used available
Mem: 3.8Gi 1.66Gi 2.3Gi
/dev/root 42G 4.7G 35G 12% /
图 5 系统信息采集：内核、发行版、内存、磁盘一目了然
2.3 实时内核意味着什么
6.1.118-rt36 里的 rt 就是 PREEMPT_RT（实时抢占补丁）。它不是营销词，而是实打实的内核改造：把内核中原本不可抢占的临界区（自旋锁、中断处理）改造成可抢占，把最坏任务响应延迟从毫秒级压缩到几十微秒级。
对三类人意义重大：
- 运动控制：步进电机、伺服控制对抖动极其敏感，普通内核的偶发卡顿会导致丢步；
- 工业总线：EtherCAT、CANopen 的周期任务需要确定性调度；
- 机器人：多关节协同控制的实时性直接影响轨迹精度。
代价是内核吞吐会有小幅下降（大约 1%~5%），但对 AI 推理这种"算力密集型"任务几乎没有影响——毕竟 NPU 推理是批量计算，不怕几微秒的调度抖动。用实时内核跑 AI，是"稳"和"快"都想要的表现，这是很多同价位开发板没有的配置。
2.4 资源余量
跑完 GNOME 桌面 + 终端 + 截图工具后，内存占用 1.66GB，剩余 2.3GB；64GB eMMC 只用了 4.7GB（12%）。这意味着：
- 还可以同时开浏览器、跑模型、做数据可视化；
- 剩下 35GB 空间足够存放几百个模型文件或几个小时的视频素材；
- 如果是做产品原型，这个余量能撑得住"系统 + 应用 + 数据"三层同时运行。
三、NPU 初体验：一条命令跑通 YOLOv5
3.1 先搞清楚工具链分工
很多人卡在 NPU 门外，不是不会写代码，而是没搞清 Rockchip 这套工具链谁管谁。一张表说清楚：
| 组件 | 运行位置 | 职责 |
|---|---|---|
| rknn-toolkit2 | PC（x86 Linux） | 模型转换、量化、精度仿真 |
| rknn-toolkit-lite2 | 板端（Python） | 板端 Python 推理 API（API 2.x） |
| librknnrt.so | 板端（C 库） | 真正的推理运行时，所有路线最终都调它 |
| rknn_server | 板端（调试） | 配合 PC 端连板调试的代理服务 |
最关键的一条经验：rknn-toolkit-lite2 的版本必须与板端 librknnrt.so 版本对齐。本板运行时是 2.3.2，所以 Python 包也要装 2.3.2，否则轻则报错、重则结果错乱。
3.2 官方已备好一切
板子预置了完整的模型仓库和推理程序：
/usr/share/model/yolov5/
├── RK3576/yolov5s-640-640.rknn # 官方预转换模型（RK3576 专用）
├── model/bus.jpg # 官方测试图
├── model/coco_80_labels_list.txt # COCO 80 类标签
└── rknn_yolov5_demo # 已编译好的推理程序
注意那个 RK3576/ 目录——RKNN 模型是芯片代际绑定的，RK3576 的模型不能拿到 RK3566/RK3588 上用，反过来也一样。这一点官方做了正确的目录划分，点赞。
3.3 复现官方结果
cd /usr/share/model/yolov5
rknn_yolov5_demo /usr/share/model/yolov5/RK3576/yolov5s-640-640.rknn \
/usr/share/model/yolov5/model/bus.jpg letterbox /home/a123/bus_letterbox.jpg
实测识别结果（与官方文档逐项一致）：
person @ (209 243 286 510) 0.879723
person @ (479 238 560 526) 0.870588
person @ (109 237 232 534) 0.828112
bus @ (93 129 553 464) 0.700761
person @ (79 353 122 517) 0.307297
loop count = 10 , average run 20.159300 ms
图 6 官方测试图 bus.jpg：4 人 + 1 巴士全部检出，坐标与置信度和官方文档完全一致
图 7 检测结果图在桌面上打开，蓝框 + 类别 + 置信度一目了然
性能对照：官方文档给出 letterbox 模式平均 20.16ms，本次实测 20.1593ms——误差不到 0.01%，几乎是完美的复现。这个"毫秒级吻合"比任何宣传语都有说服力：说明板子的 NPU 频率、内存带宽、调度策略都和官方测试环境一致。
3.4 模型输入输出拆解
想改代码做二次开发，必须看懂模型 I/O。终端日志给出了完整信息：
input : images [1, 640, 640, 3] NHWC INT8 zp=-128 scale=0.003922
output0: output0 [1, 255, 80, 80] NCHW INT8
output1: 286 [1, 255, 40, 40] NCHW INT8
output2: 288 [1, 255, 20, 20] NCHW INT8
逐层拆解：
- 输入：640×640 彩色图，NHWC 排布，INT8 量化。
zp=-128, scale=0.003922（约 1/255）意味着反量化公式是(int8 + 128) / 255，输出天然落在 0~1 区间——模型图内已经把 Sigmoid 烧进去了，后处理千万别再做一次 Sigmoid，这是新手最容易踩的精度坑。 - 输出：三个尺度对应 stride 8/16/32。每个特征图 255 通道 = 3 个 anchor × 85 项（4 个框参数 + 1 个目标置信度 + 80 个类别概率）。80×80 负责小目标，40×40 中等，20×20 大目标。
- 解码：
xy = (σ·2 − 0.5 + grid) × stride，wh = (2σ)² × anchor，再做置信度过滤（0.25）与 NMS（0.45）。
理解这三件事，你就能用 Python 把同一套模型跑在自己的业务代码里，而不只是跑 demo。
3.5 两种预处理模式
官方 demo 提供 resize 和 letterbox 两种模式，官方文档给出的对照数据是：
| 模式 | 官方耗时 | 特点 | 适用 |
|---|---|---|---|
| resize | 19.31 ms | 直接拉伸到 640×640，速度快，但比例失真 | 对姿态不敏感的检测 |
| letterbox | 20.16 ms | 等比缩放 + 灰边填充，保持比例 | 通用场景 |
本次全程使用 letterbox（实测 20.1593ms），比 resize 慢约 4%，换来的是框体位置和比例不失真。对做坐标换算、测距、跟踪的项目来说，这 4% 的耗时换来的精度是值得的——如果为了快用 resize，之后的坐标反变换会把误差全部吃掉。
3.6 NPU 频率调节
系统提供了 6 种调频策略：
rknpu_ondemand vop2_ondemand userspace powersave performance simple_ondemand
手动定频 950MHz（NPU 最高频）：
sudo sh -c 'echo userspace > /sys/class/devfreq/27700000.npu/governor && \
echo 950000000 > /sys/class/devfreq/27700000.npu/userspace/set_freq'
cat /sys/class/devfreq/27700000.npu/cur_freq # 950000000
图 8 定频成功：cur_freq = 950000000
定频要不要做？先看第五章的实测数据再决定——结论可能和你想的不一样。
四、实战：用自己的照片做目标检测
官方测试图只是"考试"，真正的体验得用自己的图。我准备了 4 张原创照片：布偶猫、哈士奇、办公室桌面、夜间楼下街道，全部用手机拍摄，覆盖室内/室外、白天/夜晚、单目标/多目标、近景/俯拍等典型场景。
4.1 检测命令
cd /usr/share/model/yolov5
rknn_yolov5_demo /usr/share/model/yolov5/RK3576/yolov5s-640-640.rknn "<图片路径>" letterbox "<输出路径>"
注意 cd 这一步不能省——demo 内部用相对路径找标签文件，在家目录执行会直接失败（详见第六章坑 1）。
4.2 案例一：布偶猫（500×742）
cat @ (15 11 492 731) 0.478677
once run use 28.921000 ms
loop count = 10 , average run 19.929100 ms
图 9 猫咪正确检出 cat 类，但置信度只有 47.9%
亮点：单目标小图，平均耗时 19.93ms——这是五张图里最快的，说明小分辨率图片的前处理开销很低。
问题：置信度偏低（47.9%）。结合图片分析，三个可能原因：
- 背景融合：白色长毛猫坐在浅色背景前，轮廓边缘对比度低，边界框回归容易发散；
- 姿态因素：坐姿正面、身体紧凑，与训练集中常见的全身站立姿态差异较大；
- 类别样本：COCO 数据集中布偶猫这类长毛品种样本占比不高，模型对"典型橘猫/短毛猫"更敏感。
实践建议：默认置信度阈值 0.25 对这类"高对比度差"场景偏宽松，实际部署建议按业务调高到 0.35~0.45，或者干脆换成自己数据微调过的模型。
4.3 案例二：哈士奇（720×1280）
dog @ (32 206 738 1250) 0.862268
once run use 26.748000 ms
loop count = 10 , average run 20.190100 ms
图 10 哈士奇检出 dog 类，置信度 86.2%
大目标、高对比度场景下，置信度提升到 86.2%，框体紧贴目标边缘，质量很好。耗时为 20.19ms——比猫图慢 0.26ms，原因很简单：720×1280 的分辨率更大，letterbox 缩放开销略高。
对比价值：同一模型、同一流程，猫 47.9% vs 狗 86.2%，差了近一倍。这组对比直观说明了置信度不是"绝对正确率"，而是"模型有多确定"——它对背景、姿态、品种分布极其敏感。做业务系统时，用置信度做分级处理（高置信度直接判定，低置信度转人工复核）比单纯调阈值更靠谱。
4.4 案例三：办公室桌面（1080×810，32 个目标）
这是最能体现 6 TOPS 算力的一张图——画面里有多人、多台显示器、笔记本电脑、办公椅、键盘、鼠标、绿植：
图 11 办公室场景：框体密集但基本无重叠错乱，绿色植物、键盘、鼠标都被单独框出
person × 8 (最高 0.664)
laptop × 8 (最高 0.556)
chair × 10 (最高 0.452)
tv × 1 (0.451)
potted plant × 2
keyboard × 2
cell phone × 1
--------------------------------
合计 32 个目标框，覆盖 7 个类别
loop count = 10 , average run 23.265700 ms
图 12 桌面场景的完整推理日志（32 个目标框）
三个观察值得记录：
- 小目标检出能力不错：桌面下方的键盘、鼠标（鼠标框面积很小）都被单独框出，说明 80×80 的高分辨率特征图在工作；
- 相似类别会打架：画面里的 27 寸显示器被识别成
tv（电视），这是 COCO 数据集的固有局限——显示器在训练集中常被标注为 tv，二者形态高度相似，工业场景需要自己标注数据来区分； - 密集场景下耗时只增加 3ms：从单目标 20ms 到 32 目标 23.27ms，NMS 的开销约 3ms，说明后处理实现效率不错，NPU 余量充足。
对做零售客流、工位监测、会议室占用这类应用来说，32 目标/帧、43 FPS 的吞吐完全够用。
4.5 案例四：夜间街道（1278×1706，10 个行人 + 3 处误检）
从 6 楼俯拍夜间的街道，隔着防盗窗拍摄，这也是最"刁钻"的一张：
图 13 夜间俯拍街道：行人基本被框出，但出现误检（顶部红色招牌判成 tv、窗框判成 traffic light）
person × 10 (最高 0.589，最低 0.179)
tv × 2 (0.656 / 0.299) ← 红色招牌误检
traffic light × 1 (0.320) ← 窗框误检
bicycle × 1 (0.111) ← 疑似电动车
once run use 27.208000 ms
loop count = 10 , average run 24.850400 ms
图 14 夜间街道场景的完整推理日志
逐条客观评价：
- 行人检出 10/10：夜里走动、骑车、坐姿的行人都被找到，这在俯视 + 隔窗 + 夜间三重不利条件下已经相当不错；
- 置信度整体偏低（0.18~0.59）：夜间光照不足、俯视角度导致人体比例异常（只看到头和肩）、防盗窗横杆遮挡，三个因素叠加把置信度压到了整体较低的水平；
- 误检 3 处：顶部红色招牌（方形 + 发光 + 红底白字）被判成
tv，竖条纹窗框被判成traffic light，说明模型对"矩形发光体"和"竖向结构"有过度联想； - 平均耗时 24.85ms：五张图里最高，因为分辨率最大（1278×1706），letterbox 缩放成本最高。
这条数据的价值：它证明了 YOLOv5s + COCO 预训练模型的边界——在理想光照、正常视角下可靠，在夜间 + 极端视角下明显衰减。如果真要用在安防场景，必须补夜间数据微调，或换成更强的模型（yolov8m / yolov11l），或加红外补光。
4.6 五张图横向对比与规律总结
| 图片 | 分辨率 | 检出情况 | 首帧 | 平均 |
|---|---|---|---|---|
| bus.jpg（官方） | 810×1080 | 4 person + 1 bus | 28.10 ms | 20.16 ms |
| mao.jpeg | 500×742 | cat 0.479 | 28.92 ms | 19.93 ms |
| dog.jpeg | 720×1280 | dog 0.862 | 26.75 ms | 20.19 ms |
| desk.jpeg | 1080×810 | 32 目标 / 7 类 | — | 23.27 ms |
| 楼下街道.jpeg | 1278×1706 | 10 person + 3 处误检 + 1 bicycle | 27.21 ms | 24.85 ms |
图 15 四张图的检测结果同时在桌面打开
从这五组数据能提炼出三条规律：
- 耗时和分辨率强相关，和目标数量弱相关：500×742 最快（19.93ms），1278×1706 最慢（24.85ms），差距 5ms；而 32 目标的桌面图只比单目标慢 3ms。说明瓶颈在前处理（缩放）和拷贝，不在 NPU 计算；
- 首帧比平均慢 6~8ms：所有图的首帧耗时都在 26~29ms，比平均值高 30% 左右，这是模型第一帧的内存分配和算子初始化开销。做实时系统时，建议预热几帧再开始计时；
- 数值稳定性很好：同类场景的重复测量误差在 ±0.3ms 内（如 dog 图的 20.19 / 20.46 / 21.87 三次），说明测量本身可信。
五、性能评测：定频前后对比
5.1 测试方法学
做性能对比最怕"测了个寂寞"。本次测试的设定：
- 测量口径：用 demo 输出的
average run（10 次循环平均值），不用once run（首帧含初始化，偏大 30%）； - 控制变量：同一张图（dog.jpeg）、同一模型、同一命令、每次独立进程运行；
- 对比维度：默认调频 / userspace 定频 950MHz / simple_ondemand 三组；
- 局限性：每组只跑了一轮 10 次循环，没有做多轮重复取最小值，所以 ±1ms 内的差异应当视为噪声而非结论。
# ① 定频 950MHz
sudo sh -c 'echo userspace > /sys/class/devfreq/27700000.npu/governor && echo 950000000 > /sys/class/devfreq/27700000.npu/userspace/set_freq'
# ② 恢复自动调频
sudo sh -c 'echo simple_ondemand > /sys/class/devfreq/27700000.npu/governor'
5.2 实测数据
| 调频策略 | NPU 频率 | 平均耗时 |
|---|---|---|
| 默认（首次运行） | 自动 | 20.19 ms |
| userspace 定频 | 950 MHz | 20.46 ms |
| simple_ondemand | 满载时自动到 950 MHz | 21.87 ms |
图 16 定频 950MHz 后，dog.jpeg 平均耗时 20.4583 ms
图 17 切换 simple_ondemand 后，平均耗时 21.8731 ms，
cur_freq 显示满载时同样在 950MHz
5.3 结论（有点反直觉）
对于 YOLOv5s 这类轻量模型，定频带来的收益在测量噪声范围内（±5%）。三组数据 20.19 / 20.46 / 21.87ms，最大差距 1.68ms（8%），而且定频组并没有比默认组更快。
拆解原因：
- DVFS 响应够快：
rknpu_ondemand策略下，NPU 在持续推理负载中 1~2 帧内就顶到了 950MHz，定频并不能让它"更快"，只能让它"更稳"； - 前后处理占比不可忽视：粗算 NPU 纯推理约 17~18ms，前处理（缩放/letterbox）+ 后处理（解码/NMS）+ 内存拷贝约 2~3ms，定频只影响前者；
- 单帧粒度太粗：20ms 的样本里，DVFS 的升降频切换被平均掉了，看不出差异。
实用建议：
- 日常跑 YOLOv5s，不需要定频，默认策略就好；
- 做长时、可复现的基准测试（比如写测评报告）时，定频才有意义——它能消除 DVFS 抖动，让数据可比；
- 如果是跑更大模型（yolov8l、多模型并行）或对延迟抖动敏感的场景（如机械臂视觉伺服），定频的价值会显现出来。
5.4 六种调频策略怎么选
| 策略 | 行为 | 适用场景 |
|---|---|---|
| rknpu_ondemand | 默认，负载跟随 | 通用 |
| simple_ondemand | 简单负载跟随 | 轻量负载、省电 |
| userspace | 固定频率（手动指定） | 基准测试、可复现实验 |
| performance | 锁最高频 | 极限性能、散热充足 |
| powersave | 锁最低频 | 待机、低功耗场景 |
| vop2_ondemand | 显示子系统联动 | 显示密集型应用 |
六、踩坑实录（问题与解决）
这一节是给后来者的"避坑指南"，每一个坑都真实踩过，按"现象 → 排查 → 根因 → 解决"四段式记录。
坑 1：在家目录直接运行，报 cv::imread ... fail!
现象：图片明明存在，demo 却读不到，报 cv::imread model/bus.jpg fail!。
排查过程：先 ls 确认图片存在 → 怀疑权限（ls -l 正常）→ 怀疑输入路径大小写（正常）→ 突然意识到 demo 内部的路径是相对的 model/bus.jpg，而当前目录是 ~，根本不存在 ./model/ 子目录。
根因：rknn_yolov5_demo 用相对路径找图，且内部依赖 ./model/coco_80_labels_list.txt 标签文件，必须在其"工作目录"下运行。
解决：
cd /usr/share/model/yolov5 # 关键一步
rknn_yolov5_demo ...
图 18 典型报错：cv::imread model/bus.jpg fail!（官方 FAQ 也提到"需先进入示例目录"）
图 19 第一次执行的命令——看起来完全正确，错在"在哪个目录执行"
预防：任何官方 demo，先 cd 到它所在目录再跑；或者干脆把 model/ 一起复制到家目录。
坑 2：Python 3.13 装不上 rknn-toolkit-lite2
现象：pip install rknn-toolkit-lite2 直接失败，提示找不到匹配的发行版。
排查过程：查 PyPI 页面 → 发现该包的 wheel 命名带 cp312 → 板子系统 Python 是 3.13 → Python 不满足 ABI 兼容（wheel 只发布到 cp312）。
根因：rknn-toolkit-lite2 是带原生库的平台相关包，Python 的 wheel 标签严格绑定 cp312，Python 3.13 无法直接安装。板子系统恰好是 Debian 13（默认 Python 3.13），于是"官方系统"和"官方工具链"之间出现了版本错位。
解决：
- 方案 A：装 Miniconda，建 Python 3.12 环境（较重，但稳妥）；
- 方案 B：下载 cp312 的 wheel 解压后用
PYTHONPATH指向，绕过 pip 的标签检查（轻量，但依赖包内部实现）。
建议官方：要么把系统 Python 降到 3.12，要么预装好 conda 环境并在文档里说明——目前这个错位会让大部分想写 Python 代码的人在第一小时就卡住。
坑 3：以为 /dev/video-camera0 是摄像头
现象：ls /dev/video* 有 76 个节点（video0~video74 共 75 个，外加 video-camera0），看起来"摄像头很充足"；但 ffmpeg 抓帧报 Inappropriate ioctl for device。
排查过程：
- 先试
/dev/video-camera0→ 失败； - 用
v4l2-ctl --list-devices枚举 → 无任何真实摄像头； - 查资料确认：这些节点是 RKISP（图像信号处理器）框架开机注册的框架节点，每个 ISP 控制器会注册一组 video 节点（用于捕获、参数、3A 统计等），没有实体 sensor 时全部是空壳。
图 20 75 个 video 节点全是空壳，没有实体摄像头
根因：板子本身不带摄像头，MIPI CSI 座为空；USB 摄像头需要自备。
解决：外接 USB 摄像头（UVC 协议，即插即用），或改用图片/视频文件作为输入。
建议官方：在快速上手文档首页用醒目提示写明"MIPI CSI 为空座、需自备摄像头"，并附一句 v4l2-ctl --list-devices 的辨别方法。这个小坑对新手友好度伤害极大——很多人会以为"板子坏了"。
坑 4：NPU 定频需要 sudo，重启后失效
定频写入 /sys/class/devfreq/... 需要 root 权限；断电重启后配置丢失，回到 rknpu_ondemand。做基准测试时，每次都要重新设置一遍。
解决：写个开机脚本，或者用 systemd 服务固化（本测评场景不需要，所以没做）。
坑 5：板子直连 GitHub 不通
官方文档多处指向 GitHub（源码、SDK、模型），实测板子直连不通，curl 超时。
解决：所有下载走国内镜像——Miniconda 用清华源、PyPI 用清华源、模型文件从官方仓库镜像下载后拷入板子。
建议官方：文档里提供国内镜像或离线包，减少"第一步就卡住"的挫败感。
| # | 问题 | 影响面 | 严重度 |
|---|---|---|---|
| 1 | 工作目录导致读图失败 | 所有官方 demo | 中（易排查） |
| 2 | Python 3.13 vs cp312 | 所有 Python 开发 | 高（卡住入门） |
| 3 | 无摄像头但节点一堆 | 所有视觉应用 | 高（认知误导） |
| 4 | 定频需 sudo 且不持久 | 基准测试 | 低 |
| 5 | GitHub 不通 | 环境搭建 | 中 |
七、总结与建议
历时数天，从开箱上电到 NPU 实战，我用端侧目标检测这条主线，把 Quectel Pi M2 从头到尾"压榨"了一遍。需要先说明的是，M2 并不是一块 AI 专用板，而是基于 RK3576 的通用型单板计算机——八核处理器、6.1.118-rt36 实时内核、4GB 内存、64GB eMMC、40-pin 排针、双 MIPI CSI、千兆网口，做网关、控制、多媒体都能胜任。跑 YOLO 只是我个人选择的体验方向，而正是这个最吃硬件、也最容易暴露问题的方向，最能检验它的真实成色。
先说好的方面。第一是开箱即用。Debian 13 桌面完整、中文环境、网络即通，插上电 30 秒进桌面，不用装驱动、不用配显示。NPU 模型和推理 demo 全部预装，进入 /usr/share/model/yolov5 一条命令就能跑通官方 bus.jpg。第二是数据扎实。实测 letterbox 模式平均 20.1593ms，与官方文档 20.16ms 误差不到 0.01%；4 张原创照片中，哈士奇置信度 86.2%，办公室桌面一帧检出 32 个目标仍有 23ms，五张图的重复测量误差在 ±0.3ms 内，数值稳定性和硬件一致性都令人放心。第三是实时内核，PREEMPT_RT 补丁对运动控制、工业总线这类确定性场景是同价位板子少有的加分项。第四是资源宽裕、被动散热足够，连续推理十几分钟屏蔽罩仅温热。
问题同样不能回避。我真实踩了五个坑：demo 依赖相对路径，在家目录运行直接读图失败；系统 Python 3.13 与 rknn-toolkit-lite2 的 cp312 轮子不匹配，会卡住所有想写 Python 的人；板子本身不带摄像头，75 个 /dev/video* 节点全是 RKISP 空壳，却极易误导新手；定频需要 sudo 且重启失效；直连 GitHub 不通。模型层面，YOLOv5s 在白天、正常视角下可靠，但夜间俯拍街道出现三处误检（红色招牌判成 tv、窗框判成 traffic light），布偶猫因背景融合置信度只有 47.9%——这是预训练模型的固有边界，也是所有端侧方案都要面对的现实。
一个反直觉的结论值得强调：对 YOLOv5s 这类轻量模型，手动定频 950MHz 相比默认自动调频几乎没有收益（20.46ms vs 20.19ms），因为 DVFS 一两帧内就能顶满频率，瓶颈反而在图像前处理。定频的真正价值在于基准测试的可复现性，而非日常提速。
综合来看，在"功耗十瓦以内的边缘盒子"这个定位里，M2 的完成度和性价比都在第一梯队。它缺的不是算力，而是"最后一公里"：更前置的避坑文档、与工具链对齐的 Python 版本，以及一个能让新手开箱即演示的摄像头。如果你想低成本验证边缘 AI、做工业网关或需要实时性的嵌入式项目，它值得入手；但如果你期待的是"插电就能看会认"的完整套件，还需自备摄像头和一点折腾的耐心。对我而言，这趟体验最大的收获不是那个 20ms 的数字，而是确认了一件事：国产通用开发板，已经能让人把精力真正放在应用上，而不是环境上。