无论是正在评估 Easy-EAI 开发板（RV1126B、RK3576、RK3588 等平台）准备立项的客户，还是负责产线质检的 QA 工程师，验证硬件在极限满负荷状态下的稳定性，都是必不可少的一环。
一套标准的极限压力测试，能直观评估四个关键项：供电设计（PDN）是否扎实、内存高频读写是否出现位翻转、总线带宽是否存在瓶颈、散热方案能否压住长时间高负载。
本文提供一套基于 Google stressapptest 与 NPU 联合压测的标准化操作流程，以 EASY-EAI-Nano-TB （RV1126B）为例，覆盖环境准备、通用计算压测、NPU 算力榨取与状态监控四个阶段，并给出可量化的验收标准。
01
常见误区为什么自测往往测不出真问题？
在没有统一标准的情况下自行压测，容易陷入三类误区：
1. 测试维度太单一
仅写一个while true死循环把 CPU 跑满，忽略内存带宽、eMMC 并发 I/O 与 NPU 负载，无法模拟真实的复杂 AI 落地场景。
2. 致命的破坏性操作
照搬网上的脚本，错误地将 I/O 测试节点指向底层物理分区（如/dev/block/by-name/recovery）。这会导致系统核心分区被乱码覆盖，设备直接变砖，且丧失 OTA 救援能力。
3.缺乏量化评估标准
盲目跑几天几夜，却不知道去哪里看日志，也不知道读出的内核温度多少算正常，测试失去评估意义。
02
环境准备编译安装 stressapptest
stressapptest（SAT）由 Google 开源，能最大化处理器与 I/O 到内存的随机流量，是业界常用的硬件稳定性验证工具。
# 1. 安装编译依赖sudoapt update &&sudoapt install -y build-essential git automake libtool# 2. 克隆源码gitclonehttps://github.com/stressapptest/stressapptest.gitcdstressapptest# 3. 编译与安装./configuremake -j$(nproc)sudomake install# 4. 验证安装whichstressapptest
前提： 需通过 SSH 登录板卡，且板卡处于联网状态。
03
CPU / 内存 / 磁盘 IO 联合压测
严重警告： 进行 File IO 测试时，绝对禁止将测试路径指向裸设备节点（如/dev/block/xxx）。这会导致物理扇区被覆盖，直接损坏固件分区。必须指定挂载好的用户级文件路径。
后台运行综合压测指令：
nohupsudo stressapptest -s43200\-C $(nproc)\-M $(($(free -m | awk '/Mem:/{print $2}')*50/100))\-m $(nproc)\-f /userdata/stress_io.tmp\-W\--stop_on_errors\-l /userdata/stress.log &
关键参数说明：
执行后 CPU 与内存负荷被拉满，测试在后台运行并记录日志。
04
榨取 NPU 算力让 AI 负载也满载
仅有 stressapptest 还不够。作为 AI 板卡，NPU 功耗占比极高，必须让 NPU 也满载，才能实现"全系统极限压测"。
本文以 Easy-EAI 网盘提供的 YOLOv11 Demo 为基础（配套教程见文末链接）。
1. 修改 main.cpp 为无限循环推理
核心改动是将单次推理改为while(1)循环，并加入延时控制：
intloop_cnt =0;while(1) { loop_cnt++; printf("===== Loop %d start detect =====\n", loop_cnt); Mat image = cv::imread(p_img_path); if(image.empty()) { printf("Read image %s failed, skip loop!\n", p_img_path); usleep(200000); // 读取失败延时 200ms 重试 continue; } std::vector
2. 后台执行
cd/userdata/yolov11_detect_demo_releasenohup./yolov11_detect_demo ./yolov11s_rv1126b.rknn ./bus.jpg &
提示： 可执行多次，产生多个进程，将 NPU 负载拉高至理想压测位。
05
实时监控与温度抓取
压测启动后需验证 CPU 与 NPU 是否真的被"榨干"，并记录系统温度表现。
1. 监控 CPU 与内存实时负载
sudoapt update &&sudoapt install htophtop
正常状态下，所有 CPU 核心进度条顶到 100%，内存占用达到预设的 50% 以上。
2. 监控 NPU 实时利用率
Rockchip 将 NPU 负载信息暴露在底层 debug 节点：
watch -n 1cat/sys/kernel/debug/rknpu/load
正常满载状态下，NPU 的 Load 值应处于 90%~100% 之间。
3. 后台记录温度曲线
nohup bash-c 'whiletrue;dodate"+%Y-%m-%d %H:%M:%S">>/userdata/temp.log; cat/sys/devices/virtual/thermal/thermal_zone0/temp>>/userdata/temp.log; sleep10; done'&
4. 查看压测状态
tail-f /userdata/stress.log # 观察有无 Error 字样tail-f /userdata/temp.log # 观察温度变化趋势
06
验收标准如何判定"稳定合格"
完成 12 小时（或按需求设定的 72 小时）压测后，依据以下两点验收。
1. 零错误容忍（看 Log）
打开/userdata/stress.log，滑动到最末尾：
及格线： 必须显示Status: PASS
异常判定： 若日志抛出Hardware Error、读写校验失败退出，或系统直接内核 Panic 死机重启 —— 说明板卡在极限供电下出现电压跌落，或内存阻抗匹配存在瑕疵，未通过高压稳定性评估
2. 核心温度表现与 Thermal 机制解读
查看/userdata/temp.log（内核读出的数值需除以 1000 才是真实摄氏度，如 65000 代表 65℃）：
正常表现：对于 RV1126B / RK3576 这类芯片，在无主动散热风扇、仅配备基础铝制散热片的情况下，双烤（CPU + NPU 满载）温度稳定在 65℃ ~ 80℃ 之间，属于优秀的工业级散热表现。
降频保护（Thermal Throttling）： RK 芯片在设备树（dts）中定义了安全温度阈值（通常为 85℃ 左右）。当核心触碰此红线，内核安全机制会介入，强行降低 CPU 与 NPU 运行频率来强制降温。
关键认知： 若发现温度卡在 85℃ 且应用明显变卡，这并不代表板卡死机或损坏，而是说明当前裸板的物理散热无法压住极限功耗。在实际装配密闭外壳的量产项目中，可能需考虑增加导热硅胶垫或风扇。
综上所述
压测的价值不在于"跑多久"，而在于能否把结果转化为可判定的工程结论。
很多团队花几天几夜跑完测试，最终只得到一句"没死机"——这既无法支撑立项决策，也无法在量产阶段复现比对。真正的验收需要落到两个可量化的点上：日志里有没有 PASS、温度稳定在哪个区间。前者验证供电与内存的电气可靠性，后者验证散热方案与结构设计的匹配度。
尤其需要理解的是降频不等于故障：温度触及 85℃ 触发 Thermal Throttling，是内核保护机制正常工作的表现，它给出的信号是"当前裸板散热压不住极限功耗"，而非"板子坏了"。正确解读这一信号，才能在装配密闭外壳的量产阶段提前规划导热硅胶垫或风扇，而不是误判为硬件缺陷。
对正在评估平台的客户而言，这套标准化流程的意义在于：不依赖各家口径不一的"跑分"宣传，在立项阶段用同一套方法就能更直观地横向比对不同板卡的稳定性。
