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 項目。