高通跃龙IQ-9100平台的极限压力测试(2): AI推理叠加与极限状态稳定性验证

weixin_38498942

392人浏览 · 2026-05-28 11:06:14

weixin_38498942 · 2026-05-28 11:06:14 发布

1. 前言

1.1 解码边界确定后的推理叠加

上一篇对多路4K HEVC解码进行了独立压力测试，明确了测试矩阵、工具互证方法、热与降频对丢帧的影响。产线场景中推理模型与解码同时运行，因此本部分在相同监控框架下叠加推理负载。主模型采用YOLOv8检测流，重点考察解码倾向推理流水线灌满时，帧率、尾延迟、三路算力分配及内存边界的表现。

1.2 本文交付物

本文提供以下具体结果：叠加后的FPS/延迟曲线、CPU+GPU+NPU采样脚本输出的CSV、内存压力触顶时OOM killer的行为、72小时长稳运行中的慢泄漏检测、故障注入后的系统自愈能力。

2. 解码+推理叠加测试

在这里插入图片描述

（图1 解码多路与YOLOv8推理叠加数据流，此处为示意图）

2.1 流水线衔接规则

解码与推理不各自独立运行时钟。固定策略为：解码侧每产出一帧有效图像，推理侧消费一帧。队列深度设置上限，满时丢弃最旧或当前帧（策略写入报告，两种均测试）。产线通常选择“保最新”，实验室中为观察恶化过程可临时改为“堆积观测”，但该配置不写入推荐集。

GStreamer中，解码后接videoconvert转换至推理所需的格式，若分辨率大于模型输入尺寸，再通过videoscale固定到 640×640 或训练规格。此处多一次拷贝会消耗上一篇中预留的余量，因此将格式转换开销单独记录一列。

2.2 帧率指标

同时记录两路帧率：解码输出FPS和推理完成FPS。理想情况下两者重合。若解码FPS仍高而推理FPS塌陷，瓶颈在NPU排队或后处理；反之，推理跟得上而解码掉帧，则需检查DDR或散热。YOLOv8单次推理耗时分为pre+infer+post三段，记录标准差及p95分位数，以反映现场卡顿体感。

2.3 延迟测量方法

在片源中嵌入时间戳水印，推理结果画框回写或另存后对比时间戳。端到端延迟定义为水印时刻到结果落盘时刻的差值，采样200帧绘制直方图。叠加模型后p95延迟相对于纯解码的抬升量写在摘要首句。

2.4 加压顺序

第一天仅开启解码至稳态；
第二天在同一脚本中打开推理开关；
第三天将路数从2路增至4路。

每天的数据文件名带后缀，避免混淆。每日只变动一个维度，以便问题复盘。

2.5 batch与stride的影响

边缘侧YOLOv8默认batch=1，对齐产线节拍。若实验性设为batch=2，需在表中注明等效FPS的计算方式（按帧数还是按batch）。stride非1时会减少预处理裁剪次数、降低CPU占用，但可能引入特征图对齐异常。此类异常除日志中标记WARN外，必须截取一帧坏图作为附件。

3. CPU/GPU/NPU三路负载监控

3.1 进程级CPU占用分析

htop用于确认哪些线程占用CPU：解码、色彩转换、后处理中未关闭的Python对象等。若线程名不明确，通过/proc/pid/task/*/comm修改短名。

3.2 负载采样脚本

若无厂商提供的stats工具，使用以下脚本每秒记录一次负载，写入mix_load.csv（具体节点依BSP替换）：

#!/bin/sh
OUT=mix_load.csv
echo "ts,cpu_busy,gpu_busy,npu_busy" > "$OUT"
while true; do
  TS=$(date +%s)
  CB=$(grep '^cpu' /proc/stat | awk '{u=$2+$4; t=$2+$3+$4+$5; print int(100*u/t)}')
  GB=$(cat /sys/class/kgsl/kgsl-3d0/gpu_busy_percentage 2>/dev/null || echo NA)
  NB=$(cat /sys/class/.../npu_busy 2>/dev/null || echo NA)
  echo "$TS,$CB,$GB,$NB" >> "$OUT"
  sleep 1
done

NB节点通过find命令搜索后写死，在仓库中附带内核版本注释。

3.3 三路曲线可视化

绘图时横轴为时间，左纵轴为百分比，右纵轴叠加解码FPS和推理FPS。使用蓝、绿、红分别表示CPU、GPU、NPU占用，灰线表示两路帧率。评审时重点指出：最先达到瓶颈的单元决定扩容策略——NPU先满则减小batch或更换小模型；GPU先满检查是否误走GL路径；CPU先满多为格式转换成Python开销。

3.4 采样开销控制

轮询间隔不低于500毫秒，默认1秒，长跑改为5秒。脚本中cat失败时输出NA而非静默吞掉，避免后期绘图出现零值平台。使用logrotate按大小切分日志，配置copytruncate或改用rsyslog，确保采样进程本身不成为压测负载。

4. 内存压力与OOM测试

4.1 内存加压方法

在侧车进程中使用mmap申请大块匿名内存并逐页touch，以缓慢速率（每秒几十MB）将MemAvailable压至警戒线以下。避免瞬间撞墙，以便观察前兆抖动。

4.2 OOM Killer行为记录

使用dmesg -w另开终端监控。触发OOM后记录被杀进程的PID、oom_score、oom_score_adj，并与推理服务设置的nice及oom_score_adj对照。若解码进程被杀而推理进程仍在空转，或推理被杀导致解码堆积爆内存，均视为策略事故。将经过验证的优先级配置写入交付镜像的README。

4.3 cgroup内存限制（若启用）

在容器或cgroup v2场景下，为推理服务设置memory.high（软顶）和memory.max（硬顶）。软顶触发时内核开始回收，业务侧应感知背压；硬顶为最后防线。具体数值基于稳态常驻内存加峰值抖动再增加15%余量确定。

4.4 swap开关的影响

分别测试开启swap与关闭swap两种配置。关闭swap时间题暴露更早，适合研发阶段；开启swap更接近客户现场默认配置。若两种配置下性能均不理想，应减少路数或降低模型复杂度。

5. 72小时长稳测试

在这里插入图片描述

（图：72小时满载长稳测试曲线，此处为示意图）

5.1 长跑脚本设计

编写supervisor循环：解码+推理主进程崩溃后立即拉起，崩溃计数落盘，每小时输出一行摘要。日志文件名带日期，防止单文件撑爆磁盘。

5.2 内存缓慢泄漏检测

每小时抓取/proc/meminfo中的MemAvailable和Slab，以及推理进程的VmRSS。若VmRSS每日增长几十MB且不回落，优先排查队列buffer未释放或Python对象循环引用问题。

5.3 温度漂移对比

对比相同路数下凌晨三点与下午三点的壳温及频率。若下午出现周期性掉帧而凌晨没有，归因为环境热约束，而非软件回归。

5.4 丢帧率变化趋势

对第1小时与第72小时的丢帧率进行双样本t检验或计算相对变化。从0.2%爬升至8%虽可能被现场评价为“感觉还行”，但属于恶化前兆，需检查风扇积灰或磁盘SMART。

5.5 磁盘与日志管理

72小时内若每帧打印一行debug，存储将迅速耗尽。规定info级别日志按分钟聚合，仅异常帧才记录完整hex头。磁盘剩余空间设置告警，与温度告警共用通知渠道。

6. 故障注入与恢复

6.1 拔网线（模拟RTSP断流）

解码输入走网络时，中途执行ip link set eth0 down三十秒再恢复。预期行为：自动重连、缓冲清空、无僵尸文件描述符。若进程挂死，截取栈和strace提交问题单。

6.2 杀进程测试

对推理服务执行kill -9，验证守护进程是否在5秒内拉起，首帧延迟是否超出阈值。拉起后比较VmRSS是否回到基线。

6.3 模拟DSP侧故障

在允许的环境下，通过停止DSP固件加载服务或向错误节点写入（具体操作依据发布文档），触发恢复流程。观察点：用户态是否收到明确错误码、能否降级到CPU软解或跳过帧、是否需要整机重启。能分级恢复则标记为绿，只能重启标记为红，并在交付风险表中注明。

6.4 组合故障：断网+升温

最后一天进行组合故障测试：网络闪断同时用加热风枪（控制温度不超规格）远距离吹向进风口。此类测试可检验看门狗与重试退避机制是否互锁死。组合故障下翻车案例常见，因此列入内测清单而非对外宣传。

7. 性能数据汇总与选型建议

7.1 汇总表结构

汇总表包含以下列：散热工况、解码路数、片源规格、推理模型输入、推理batch、解码FPS、推理FPS、p95延迟、CPU/GPU/NPU峰值、稳态功耗、是否节流、72h丢帧漂移、故障注入结论。该表用于售前对比，明确标注测试条件。

7.2 选型建议

密闭机柜场景应在开放散热数据基础上直接减少一路解码或降低一档分辨率作为安全边际。
当推理与解码争抢带宽时，优先保证解码稳定，推理允许掉帧抽样——此为多数安防质检合同的隐含要求。若业务优先级相反，另开附录说明，不混入主结论。

7.3 对固件和驱动的反馈

压测中若出现频率抖动与丢帧强相关、某版本驱动在高路数下retry计数异常，整理为三行以内邮件：现象、复现命令、log片段。邮件标题格式：[Stress][IQ-9100][Decoder+NPU]，便于后续检索。

8. 小结

两篇文档共同完成了IQ-9100在“多路4K硬解+YOLOv8推理”典型产线路径上的压力测试：先确定解码性能顶点，再观察叠加推理后各资源的瓶颈，通过内存压力和长稳测试发现慢速恶化，最后用故障注入验证系统的自恢复能力。具体性能数值随BSP版本和壳体环境变化，但测试方法与记录格式可复用。后续新平台测试时，优先执行本检查表，再评估新特性。