在 RK3588 多路视频分析项目里，MPP、RGA 和 RKNN 往往要协同工作，分别负责解码、图像处理和模型推理。很多团队在联调阶段最头疼的不是某个模块跑不起来，而是“怎么算调好了”。验收指标定得太松，后期现场容易出问题；定得太严，又可能卡在测试环节迟迟无法交付。这里分享几个实际可行的定义思路。
首先是端到端的吞吐量，不能只看单路。比如标称支持 8 路 1080p，就要在真实码流下，同时跑满 8 路解码 + 推理，统计稳定运行时的总帧率，而不是单独测一个模块的峰值。建议把“每路最低帧率”和“整机平均帧率”分开定义，避免某一路占用过多资源影响其他路。
其次是时延边界。视频分析对时延敏感时，需要定义“从图像采集到结果输出”的最大允许值。注意包括解码缓冲、RGA 缩放、模型前处理和推理排队的时间。更关键的是要测试持续运行时的时延抖动，尤其是多路场景下 RKNN 推理是否出现周期性排队，导致某几帧突然超时。
然后是资源占用和稳定性。CPU 占用率、内存带宽和 NPU 使用率都要设上限，但更重要的是持续压力测试。比如连续运行 72 小时，观察内存是否缓慢增长、解码器是否丢帧、RGA 是否偶发超时。项目里常见的问题是单独跑各自都正常，一旦 8 路同时触发中断和 DMA，就会出现隐性冲突，这类问题要靠长时间运行来暴露。
最后要定义失败处理机制。比如某一秒码流异常或推理超时，系统是自动丢弃还是整体卡住？验收指标里应当包括“异常注入后的恢复时间”，用测试脚本强行丢包或人为降低 NPU 频率，确认多路调度能平稳降级而不是崩溃。
综合来说，验收指标最好由业务场景倒推出来，而不是拍脑袋。明确每路分析的最小帧率、最大时延、资源和稳定性要求，并留出 20%~30% 的冗余，才能真正反映 MPP、RGA 与 RKNN 联调的工程成熟度。