RK3588 NPU ガイド: モデルの展開、INT8、およびパフォーマンス テスト

RK3588 NPU ソフトウェア スタックがどのように連携するか

Rockchip の RKNN ソフトウェア スタックは、モデルの準備をデバイス上での実行から分離します。 RKNN-Toolkit2 は、変換および評価ツールを提供します。 RKNN-Toolkit-Lite2 はサポートされているターゲット プラットフォームで Python インターフェイスを提供し、RKNN ランタイムは C/C++ インターフェイスを提供します。カーネル ドライバーはランタイムを NPU に接続します。これらのコンポーネントと、モジュールに提供されているボード サポート パッケージとの互換性を確認してください。

有用な導入レコードにより、ボードと SoM リビジョン、Linux イメージ、ドライバー、ランタイム、変換ツールのバージョン、元のモデルと変換されたモデルが特定されます。ビルド スクリプトと前処理設定をモデル アーティファクトの横に保存します。次のようなファイル名 detector.rknn あるデプロイメントが別のデプロイメントと異なる動作をする理由をそれだけでは説明できません。

ステップ 1: 変換前に参照を確立する

代表的な検証セットで元のモデルを実行します。生の出力と重要なアプリケーション メトリクス (分類精度、検出品質、または別のタスク固有の測定値) を保存します。検出器の場合、ラベルの順序、信頼度のしきい値、および後処理設定を保存します。これは、変換されたモデルの比較ポイントになります。

入力コントラクト全体を書き留めます。寸法、バッチ サイズ、RGB または BGR の順序、レイアウト、数値範囲、正規化、サイズ変更、パディングが含まれます。アプリケーションがトレーニングとは異なる方法で画像をレターボックス化したり、オフセットを 2 回減算したりすると、正しいモデルであっても悪い結果が生じる可能性があります。ネットワーク外での後処理も同様に慎重に文書化してください。

Rockchip を使用する RKNN 模型動物園 一致するモデルとターゲットが含まれる場合の開始点として。その変換と推論の例は、エクスポートされたネットワークが変更されずに機能すると仮定するよりも役立ちます。既知のリポジトリ リビジョンを選択し、その特定の例の指示に従います。

ステップ 2: モデルを変換し、オペレーターのサポートを確認します。

1. ターゲットを合わせます。 RK3588 ターゲットと、目的のボード イメージと互換性のあるツールチェーンを選択します。
2. グラフを調べます。 エクスポートしたモデルで形状、前処理、出力、実際の操作のサポートを確認します。
3. 参照変換を構築します。 そのグラフとソフトウェア バージョンでサポートされている精度オプションを使用してください。
4. 完全なビルド ログを読んでください。 カメラ取得またはユーザー インターフェイスを追加する前に、障害を解決し、警告を調査してください。
5. 出力を比較します。 同じ後処理を使用して、元のモデルと変換されたモデルを通じて同じ入力を実行します。

サポートされていない操作では、別のエクスポート、グラフの書き換え、または明示的な CPU 処理ステージが必要になる場合があります。ランタイムがサポートされていないすべてのレイヤーを透過的に実行するとは想定しないでください。ワークロードの一部が CPU に移動する場合は、パフォーマンスの測定に転送と同期を含めます。

ステップ 3: 精度要件に対して INT8 を評価します

量子化により数値表現が変化します。選択した変換フローでキャリブレーション データを使用する場合は、照明、オブジェクト サイズ、背景、動作条件など、展開を代表する入力を選択します。結果を評価するために別の検証セットを保持します。変換が正常に完了しても、精度チェックが必要です。

2 つのテンソル間の違いだけでなく、アプリケーションの出力も比較します。たとえば、小さな数値変化により、検出が信頼度のしきい値を超えてしまう可能性があります。困難なケース、例がほとんどないクラス、および元のモデルがすでに限界に達していた条件を検査します。精度が許容限界を下回る場合は、ハードウェアを変更する前に、キャリブレーション カバレッジと前処理を再検討してください。

の ONNX ランタイム量子化ドキュメント 数値のトレードオフと精度の調査に関する有用な背景です。 RKNN 変換オプションとサポートされる精度については、選択したリリースの Rockchip 独自のドキュメントで確認する必要があります。

ステップ 4: 推論時間を超える測定

ウォームアップ後、および継続的な実行中にデプロイされたワークロードを再度測定します。温度、電力モード、同時プロセス、エンクロージャまたは冷却装置を記録します。有益な結果は、製品が動作する条件下で、精度や遅延を含む再現可能なパフォーマンスエンベロープになります。

予算の例として、40 ミリ秒ごとに新しいフレームを受信するアプリケーションは、すべてのフレームを処理する場合、1 秒あたり 25 フレームに追いつく必要があります。 12 ミリ秒の推論測定では、その予算の残りは、適切にスケジュールされた設計での取得、準備、配信にのみ残されます。 12 ミリ秒のカメラから結果までの遅延を証明するものではありません。これらの数値は計画例であり、ForgeEdge のパフォーマンスを測定したものではありません。

ソフトウェアの持続時間には単調クロックを使用します。単一の最良の観測値ではなく中央値と末尾の遅延をレポートし、生​​の測定値を保存します。複数のカメラの場合、デコード、画像変換、メモリ移動、記録など、すべてのアクティブなストリームのワークロードを考慮します。テスト中にキューが増加する場合は、平均容量が受信ワークロードを下回っていることを示します。

デプロイメントの一般的な症状

プロトタイプを再現可能な製品に変える

モデル、ランタイム、アプリケーション構成を管理されたリリースとしてパッケージ化します。起動チェック、障害レポート、リカバリ、ロールバック パスを定義します。カメラが接続される前に、不適切な展開を特定できる簡単な参照入力テストを行ってください。ソフトウェア チェックを物理センサー テストから分離します。物理センサー テストでは、ケーブル配線、ドライバー、露出設定も実行されます。

ボードに別のコネクタ、電源調整、またはセンサー インターフェイスが必要な場合は、 SoM 対 SBC の決定 そして コンピューティングモジュール設計プロセス用のベースボード。これらの決定によって、成功するモデルのデモンストレーションがどのように保守可能なシステムになるかが決まります。

RK3588 NPU 導入に関する質問

すべての ONNX モデルは RK3588 NPU で実行できますか?

互換性は、実際のグラフ、形状、操作、および選択したツールチェーンによって異なります。出荷する予定のモデルの変換とデバイス上での検証を通じてサポートを確立します。

宣伝されているアクセラレータの評価はアプリケーションの FPS を予測しますか?

いいえ。ネットワーク、精度、メモリの動作、前処理、およびランタイムによって、アプリケーションの測定されたスループットが決まります。プラットフォームを比較する場合は、ターゲット ワークロードとその完全なデータ パスを使用します。

最初にニューラル ネットワークを最適化する必要がありますか?

まずはプロフィール。取得、画像変換、またはキューイングが大部分を占める場合、モデルの実行時間を短縮しても、アプリケーションが経験する結果の経過時間にはほとんど影響しない可能性があります。

完全なコンピューター ビジョン タスクのベンチマークを行う

物体検出アプリケーションの場合、カメラのキャプチャ、サイズ変更と正規化、NPU 推論、出力のデコード、および決定の配信を測定します。モデルのバージョン、入力解像度、精度、信頼しきい値、評価データセットをタイミング結果とともにレポートします。そうしないと、一見似ている 2 つの Edge AI ベンチマークが異なるタスクを記述している可能性があります。

モデル アーキテクチャにコミットする前に、選択した RKNN ツールチェーンを通じてエクスポートされたグラフと必要な演算子をテストします。変換が成功したかどうかだけでなく、量子化後の精度や継続実行時の動作も確認します。オブジェクトの検出、セグメンテーション、分類には異なる出力処理コストがかかります。プロジェクトに選択された実際のワークロードを検証します。

FPGA、NPU、MPU の設計役割を比較する