RK3588 NPU 軟體堆疊如何組合在一起
Rockchip 的 RKNN 軟體堆疊將模型準備與裝置上的執行分開。 RKNN-Toolkit2提供轉換和評估工具。 RKNN-Toolkit-Lite2 在支援的目標平臺上提供 Python 介面，而 RKNN Runtime 則提供 C/C++ 介面。核心驅動程式將執行時連線到 NPU。檢查這些元件與為您的模組提供的板支援包的相容性。
有用的部署記錄可識別主機板和 SoM 版本、Linux 映像、驅動程式、執行時、轉換工具版本、原始型號和轉換後的型號。將建置指令碼和預處理設定儲存在模型工件旁邊。檔案名稱例如 detector.rknn 僅憑這一點無法解釋為什麼一種部署的行為與另一種部署不同。
步驟1：轉換前建立參考
在代表性驗證集上執行原始模型。儲存原始輸出和重要的應用指標：分類準確性、檢測品質或其他特定於任務的衡量標準。對於偵測器，保留標籤排序、置信閾值和後處理設定。這成為轉換後模型的比較點。
寫下整個輸入合約。包括尺寸、批次大小、RGB 或 BGR 排序、佈局、數值範圍、標準化、調整大小和填充。如果應用程式以與訓練不同的方式對影像進行信箱處理或兩次減去偏移量，則正確的模型可能會產生較差的結果。同樣仔細地記錄網路外部的後處理。
使用Rockchip的 RKNN 模型動物園 當它包含匹配模型和目標時作為起點。它的轉換和推理範例比假設任何匯出的網路將不變地工作更有用。選擇一個已知的儲存庫修訂版並按照該特定範例的說明進行操作。
步驟2：轉換模型並檢查運運算元支援
- 匹配目標。 選擇 RK3588 目標和與預期電路板映像相容的工具鏈。
- 檢查圖表。 確認匯出模型中實際操作的形狀、預處理、輸出和支援。
- 建構參考轉換。 使用該圖形和軟體版本支援的精確度選項。
- 閱讀完整的建置日誌。 在新增相機採集或使用者介面之前解決故障並調查警告。
- 比較輸出。 透過原始模型和轉換後的模型執行相同的輸入，並進行相同的後處理。
不受支援的操作可能需要不同的匯出、圖形重寫或明確 CPU 處理階段。不要假設執行時將透明地執行每個不支援的層。如果部分工作負載轉移到 CPU，請在效能測量中包含傳輸和同步。
步驟 3：根據您的精確度要求評估 INT8
量化改變了數字表示。當所選轉換流程使用校準資料時，選擇代表部署的輸入：照明、物件大小、背景和操作條件。保留一個單獨的驗證集來評估結果。成功完成的轉換仍需要準確性檢查。
比較應用程式輸出，而不僅僅是兩個張量之間的差異。例如，小的數值變化可以使檢測跨越置信度閾值。檢查困難的情況、範例很少的類別以及原始模型已經處於邊緣狀態的條件。如果精確度低於可接受限度，請在變更硬體之前重新檢查校準範圍和預處理。
的 ONNX 執行時量化文件 是數值權衡和準確性調查的有用背景。 RKNN 轉換選項和支援的精確度仍必須在 Rockchip 自己的所選版本的檔案中進行檢查。
步驟4：測量超過推理時間
在預熱後和持續運作期間再次測量部署的工作負載。記錄溫度、功率模式、並發程序和 機殼 或冷卻佈置。有用的結果是在產品運作的條件下可重現的效能範圍，包括準確性和延遲。
| 測量 | 它回答什麼 | 記錄什麼 |
|---|---|---|
| 模型執行持續時間 | 這個執行時呼叫需要多長時間？ | 輸入形狀、精度、時序邊界和執行時版本 |
| 端對端延遲 | 交付成果時觀察是多久前的？ | 捕捉時間、預處理、排隊、推理和輸出時間 |
| 持續吞吐量 | 隨著時間的推移交付了多少完成的結果？ | 執行長度、已完成的請求以及丟棄或跳過的輸入 |
| 應用精度 | 部署的模型是否符合任務要求？ | 驗證集、任務指標和決策閾值 |
| 熱行為 | 系統預熱後結果是否穩定？ | 環境條件、冷卻、溫度和時鐘（如果有） |
作為說明性預算，如果應用程式每 40 毫秒接收一個新幀，則如果它處理每一幀，則它必須保持每秒 25 幀的速度。 12 毫秒的推理測量將剩餘預算的其餘部分用於僅在適當安排的設計中進行採集、準備和交付。它並沒有證明相機到結果有 12 毫秒的延遲。這些數字是一個規劃範例，並非測量的 ForgeEdge 效能。
對軟體持續時間使用單調時鐘。報告中位數和尾部延遲，而不是單一最佳觀察結果，並保留原始測量值。對於多個攝影機，請考慮所有活動流程的工作負載，包括解碼、影像轉換、記憶體移動和記錄。在整個測試過程中佇列不斷增長表明平均容量低於傳入工作負載。
常見部署症狀
| 症狀 | 第一次調查 |
|---|---|
| 正確的型號、不正確的標籤或包裝盒 | 顏色順序、標準化、調整大小/填充、輸出佈局和後處理 |
| 轉換後的模型無法初始化 | 目標選擇、執行時/驅動程式相容性和模型工件完整性 |
| 短期基準良好，持續表現較差 | 溫度、功耗模式、記憶體壓力與競爭工作 |
| 可接受的推理時間，明顯延遲的結果 | 捕捉緩衝、佇列壽命、副本和輸出排程 |
| INT8 輸出遺失有用的檢測 | 校準覆蓋率、預處理等效性和任務級驗證 |
將原型變成可重複的產品
將模型、執行時和應用程式配置打包為受控版本。定義啟動檢查、故障報告、復原和回滾路徑。保持一個小的參考輸入測試，可以在連線相機之前識別不正確的部署。將軟體檢查與實體感測器測試分開，實體感測器測試還測試佈線、驅動程式和曝光設定。
當電路板需要不同的聯結器、電源調節或感測器介面時，請檢視 SoM 與 SBC 決策 和 載板設計流程。這些決策決定了成功的模型演示如何成為可維護的系統。
RK3588 NPU 部署問題
每個ONNX模型都可以在RK3588 NPU上運作嗎？
相容性取決於實際的圖形、形狀、操作和所選的工具鏈。透過對您打算發布的模型進行轉換和裝置上驗證來建立支援。
廣告中的加速器等級是否可以預測應用程式 FPS？
不會。網路、精確度、記憶體行為、預處理和執行時間決定了應用程式的測量吞吐量。比較平臺時使用目標工作負載及其完整資料路徑。
我應該先最佳化神經網路嗎？
先介紹一下。如果擷取、影像轉換或排隊佔主導地位，則減少模型執行時間可能對應用程式所經歷的結果壽命影響不大。
對完整的電腦視覺任務進行基準測試
對於物件偵測應用，測量相機擷取、調整大小和標準化、NPU 推理、輸出解碼和決策交付。報告模型版本、輸入解析度、精度、置信閾值和評估資料集以及計時結果。否則，兩個明顯相似的邊緣人工智慧基準測試可能會描述不同的任務。
在提交模型架構之前，透過選定的 RKNN 工具鏈測試匯出的圖和所需的運運算元。檢查量化後的準確性和持續執行期間的行為，而不僅僅是轉換是否成功。物件偵測、分割和分類具有不同的輸出處理成本；驗證為專案選擇的實際工作負載。