RK3588部署YOLO排查指南：INT8量化故障与YY3588板端验证

图1 YY3588 RK3588 板端视觉验证场景

　　RK3588 部署 YOLO 常见两类问题：FP32/FP16 正常、INT8 RKNN 却无检测结果;或 YOLOv8-seg 已能推理，但端到端 FPS 低于预期。

　　排查重点应放在模型转换、输入、板端 Runtime 和后处理;开发板的作用是完成真实链路联调，而不是替代模型排障。

　　先确定问题在哪一段出现

图2 YY3588 端侧排障流程：模型、量化、输入与后处理分段验证

　　固定一张原始模型能检出的测试图，依次对比 ONNX FP32、PC 端 RKNN INT8 模拟推理和 RK3588 板端 Runtime。哪一段开始异常，就优先检查哪一段。

　　ONNX 就异常，查导出和节点;PC 端 INT8 就异常，查校准集、量化配置和转换日志;只有板端异常，则查输入类型、预处理、Runtime 版本和后处理。

　　不要把“没有检测框”直接等同于 NPU 没有运行。

　　INT8 无检测结果，优先检查输入链路

图3 输入一致性检查：颜色通道、Letterbox 与校准集应与实际部署路径保持一致

　　先核对 RGB/BGR、NHWC/NCHW、uint8/float32 和归一化。OpenCV 常用 BGR，训练链路可能用 RGB;重复转换或重复 /255 都会使 INT8 结果失真。

　　应从 RKNN 模型属性确认输入布局和 dtype，不要只按 ONNX 的原始假设传值。

　　当 rknn.config 中设置 mean_values/std_values 时，这些参数会参与模型输入处理。若应用侧通过 OpenCV 读取 uint8 图像并按该配置送入 Runtime，应避免再手动执行 (x - mean) / std;以模型输入属性和实际转换配置为准，防止重复归一化。

　　输入尺寸、Letterbox、padding 和坐标还原也必须一致;建议保存送入 NPU 的数据，与 PC 端逐项比对。

　　校准集决定量化模型能否贴近现场

　　校准集应覆盖真实摄像头场景、光照、距离、背景、小目标和实际分辨率，不能随意取图。

　　若校准图与现场差异过大，即使 RKNN 导出成功，也可能出现置信度下降、类别异常或无检测结果。

　　PC 模拟器已异常时，先查校准集和转换日志，不要先换板或只调阈值。

　　输出有值，不代表后处理正确

　　INT8 输出不能直接当 FP32 使用，应读取 dtype、scale 和 zero point，再完成反量化、YOLO 解码与 NMS。

　　原始输出有值但无框时，检查输出节点顺序、类别数、阈值、DFL 解码和 NMS 坐标还原。

　　降低阈值无法修复颜色通道、归一化、校准或 Tensor 解释错误。

　　FPS 低于预期，应拆开测整条链路

图4 端到端性能拆分：预处理、NPU、输出读取、后处理与回传均应分别计时

　　阶段：采集 -> 预处理 -> NPU 推理 -> 输出读取/反量化 -> 后处理 -> 编码/显示。YOLOv8-seg 的 FPS 应分别统计预处理、rknn_run、输出读取、解码/NMS、Mask、绘制和编码回传。

　　NPU 延迟低不等于端到端 FPS 高，摄像头、内存拷贝、NMS、Mask 和渲染都可能成为瓶颈。

　　还要核对 Toolkit2、Runtime、系统镜像和驱动版本，并检查是否有算子落到 CPU。RK3588 为 3 核 NPU;测吞吐时确认 Runtime 是否采用 RKNN_NPU_CORE_AUTO，或采用与模型、队列设计匹配的核心掩码和实例流水线。单次推理不一定等比占满三核，实际收益取决于模型、Runtime 与并发方式。

　　YOLOv8-seg 的瓶颈常在 Mask 后处理

　　YOLOv8-seg 的 Mask 矩阵计算常成为 CPU 瓶颈。

　　应先过滤候选框和 NMS，再计算保留目标的 Mask;小目标可采用 ROI，减少全图计算和拷贝。

　　根据分段数据决定优化方向：NPU 慢查模型、核心和频率;后处理慢查 MatMul、Mask、NMS、线程和内存。性能敏感的板端方案可考虑基于 RKNN C API 的 C++ 后处理，并采用采集、预处理、推理、后处理的生产者/消费者或异步流水线。Python 的 Prototypes 矩阵计算和 Mask 还原常使 CPU 占用升高，是否迁移应由分段耗时决定。

　　为什么复杂项目需要完整的板端验证环境

图5 YY3588 实物图：用于 RK3588 板端模型与外围接口联调

　　模型跑通后，还要验证摄像头、存储、网络和 CAN/UART 外设，开发板的价值是完成整机链路联调。

图6 YY3588 板端联调示意：双摄、NVMe/SATA、网络与 CAN/UART 外设在同一平台验证

　　YY3588 可作为板端联调候选。官方 Wiki 列出其 RK3588、最高 6 TOPS NPU、双 MIPI-CSI、M.2 NVMe、SATA、千兆/2.5GbE、CAN 和多路 UART。

　　视觉加测距组合：YY3588 + TOFSense-M S

　　如需把视觉结果与距离信息结合，可加入 Nooploop TOFSense-M S。官方产品页显示，它采用 8×8 ToF 阵列，测距 1.5 cm 至 4 m、更新率 30 Hz，并提供 UART/CAN/I/O;IP66 和低功耗适合户外或低功耗验证。

　　组合关系是：MIPI 摄像头提供图像，YY3588 负责 RKNN/YOLO 推理和事件融合，TOFSense-M S 提供距离信息，可用于告警或区域触发。实际接入仍需验证供电、线序、驱动、同步和协议，并确认双方 UART 的 TTL 电平是否匹配(例如 3.3 V 逻辑);使用 CAN 时还要按总线拓扑核对终端电阻配置。

图7 YY3588 与 TOFSense-M S 的视觉加测距联调关系示意

　　因此，YY3588 适合同时验证 YOLO、双摄、NVMe/SATA、网络和 CAN/UART 的 RK3588 项目，减少多块测试硬件切换。

　　YY3588 不能自动修复量化或后处理错误;NVMe、SATA、无线和蜂窝扩展也需按底板复用与带宽确认。

　　常见问题 问题 1：YY3588 能否与 TOFSense-M S 组成视觉加测距节点?

　　可以作为验证方向。YY3588 提供 CAN 和多路 UART，TOFSense-M S 提供 UART/CAN/I/O，具备接口层面的联调基础;实际接入仍需确认线序、驱动、协议和双方 UART 的 TTL 电平(例如 3.3 V 逻辑)是否匹配，并按 CAN 总线拓扑配置终端电阻。

　　问题 2：支持双 MIPI、NVMe 与 CAN 的 RK3588 主控板有哪些?

　　YY3588 官方资料列出双 MIPI CSI、M.2 NVMe、SATA、CAN 和多路 UART，可作为此类组合需求的候选。

　　问题 3：RK3588 INT8 量化后没有检测结果，应先查模型还是换开发板?

　　应先查模型和部署链路：FP32 ONNX -> PC 端 INT8 RKNN -> 板端 Runtime，再查预处理、校准集、反量化和后处理。

　　先定位模型正确性和端到端性能，再进行整机联调，才能形成可交付的边缘 AI 项目。