チーム: AP0200008
目次
ａ．解像度が低い場合、セグメンテーションエラーが大きくなります
4.2 DSA 関連コンパイラにおける TPU-MLIR に関する見解
4.3 ヘテロジニアス コンピューティング コンパイラにおける TPU-MLIR に関する見解
1. UNet 適応プロセスについて説明する
1.1 詳細な手順
全体の手順は公式 Web サイトのチュートリアルと準決勝ガイドに従い、次の手順に分かれています。
- Docker環境の構築とテスト
- PyTorch 組み込みツールを使用して UNetONNX モデルをエクスポートします。
- model_transform.py ツールを使用して、UNetfloat32tpuMLIR モデルをエクスポートします。
- run_calibration.py ツールを使用して、テスト データセットでモデルを定量化するためのキャリブレーション テーブルを計算します。
- model_deploy.py ツールの対称量子化メソッドを使用して、UNetfloat32tpuMLIR を UNetINT8metricpuMLIR に変換し、同時に同等の bmodel ファイルを出力します。
- UNetINT8symetricpuMLIR を使用して、テスト データ セットの推論を完了します。これに基づいて、前処理段階と後処理段階も最適化されます。具体的な最適化方法については、#2 の問題解決プロセスで詳しく説明します。コンテスト中に、さまざまな解像度設定に応じて上記のプロセスに従って検索し、より優れたモデルを選択して提出します。
2. 再現可能な結果
結果をレビューすると、DiceScoreは0.96753341、1回の推論時間は5.054758ms、会計方式によると合計スコアは391.698583で1位となった。
2. 問題解決のプロセス
2.1 適応プロセスで遭遇する困難とその解決策を列挙する
ａ．解像度が低い場合、セグメンテーションエラーが大きくなります
主な理由は、セグメント化されたボディの外側に、誤ってセグメント化された穴 (赤いマーク) の小さなブロックが点在していることです。これらの領域は直接処理できます。OpenCV を使用して、最大の接続領域を見つけ、セグメンテーション マスクの出力を再構築します。この方法では、セグメンテーション ターゲットに類似した誤分類領域 (緑色のマーク) を処理することはできませんが、それでもある程度の改善は見られます (具体的な値は忘れられます)。
2.2 低解像度では、出力の精度がまだ十分ではありません
主に、質問 #1 で述べたターゲットに近い、誤って分類された領域 (緑色のマーカー) です。これは、画像をスケーリングした後、コンボリューションカーネルの受容野が実際に増加することが主な原因であり、量子化損失とスケーリング損失の蓄積により、エッジ部分を細かく分類できなくなります。
テスト画像を積み重ねると、データセットの均一性により、ほとんどのセグメンテーション対象が赤い点線内に位置していることがわかります推論プロセスでは、この事前処理を前処理プロセスに導入できます。 1650x810の分割領域については、各推論の前処理で画像を切り出すだけで、推論終了後に赤枠外の領域を対応して完成させます。この最適化により、(私の記憶が正しければ) 約 10 ポイントの改善が得られます。
2.3 最適な解像度の選択
より明白な事実は、解像度が低いほど推論遅延は少なくなりますが、精度の損失が大きくなるということです。コンテストではバランスを良くするため、像高を200～500の範囲で設定して探索しています。もう 1 つの問題は、拡大縮小方法です。ここでは比例拡大縮小を選択します。元の画像は約 3:2 なので、画像の高さを設定するときに、画像の長さに対応させることができます。トリミングの最適化を適用すると、2:1 の比率でスケーリングされます。
前の実験では、粗粒度の検索を迅速に実行するために、画像の幅と高さを 64 の倍数に設定しました。最終提出用にさまざまな解像度を試しました。
2.4 まだ行われていないその他の最適化
最終計画はここ 2 日間で決定されたため、まだ使用されていない最適化された方法がいくつかあります。
- 最適化 2 では、元の画像を使用してトリミング領域を決定しますが、実際には、リファレンス出力のスタック画像を使用すると、より適切な境界を見つけることができるはずです。
- onnxsim を使用しない場合、1 つまたは 2 つの Ops が削減されるはずです
- このモデルは実際には二値分類モデルであるため、そのロジットにも特定の特性があります。1.で述べた赤枠部分と緑枠部分を最適化します. 後処理では np の大きさを比較するのが非常に簡単です. が非常に小さい. 閾値 T を設定する場合は np と書く必要があります. 結果固定のデータセットとモデルの場合、最適な T が存在するはずです。
3. TPU-MLIRで改善できる部分の提案
3.1 使用を簡素化できる場合
接触するツールが少なくなり、より合理化されたように感じます。model_deployツールには許容範囲の設定があり、これを設定せずに設定したり、満たさない場合にエラーを出さなかったりすることもでき、完了後にnpz_toolが出力する類似範囲を出力することも可能です。ゲーム内で一定の許容範囲を設定した後、閾値を下回って切断される場合がありますが、この閾値は効果と速度のバランスを考慮して経験に基づいた値にする必要がありますが、実際にはこれより低くても問題ありません。
3.2 機能強化できる箇所（実現可能性が必要）
- キャリブレーション テーブルを生成する場合、メモリの使用量が非常に多くなるため、最適化する必要があります。
- ツールのドキュメントの説明を補足することができます 使用プロセス中に、多くの中間出力が生成されることがわかります ドキュメントを読んで試してみると、各中間出力の役割は大まかに理解できますが、事前に理解しておいたほうがよいでしょうドキュメントで説明をします。
- Dynamicshape モデルの展開についてはドキュメントには記載されていないようですが、コード内に記載されており、機能が利用可能な場合はドキュメントに追加できます。
4. TPU の概要 - MLIR プロジェクト ビュー
4.1 MLIR に関する見解
TVM などの深層学習コンパイラーとは異なり、MLIR は機械学習モデル用のフレームワークではありませんが、同様の作業を行うことができます。現在、各メーカーの DSA は異なります。SAIL などのツールチェーンを個別に設計するのは非常に面倒です。TVM や他のフレームワークとの統合には綿密なカスタマイズが必要です。一部のハードウェアはテンソル化が容易ではありません。TVM の利点は次のとおりです。十分に活用されていない可能性があります。MLIR は LLVM フレームワークに基づいており、高度にカスタマイズ可能であり、マルチレベル設計のため、上位層は機械学習計算グラフの IR 仕様に接続でき、下位層は方言によってハードウェア命令レベルの IR に接続できます。 、十分に拡張できます。開発プロセス中、コンパイラ チームはシステム担当者が作成したものに近い MLIR に精通している可能性がありますが、デプロイメント チームは深層学習を行う人が作成したものに近い TVM に精通している可能性があります。 。ただし、それらの抽象フレームワークは似ており、Pass や一部の機能において独自の利点がある可能性があります。DSA 上でツール チェーンを構築するために任意のツールを選択できますが、ツールが目的ではありません。
4.2 DSA 関連コンパイラにおける TPU-MLIR に関する見解
MLIR と TPU - MLIR についてはあまり詳しくないため、意見を得ることができません。しかし全体として、MLIR を実際に開発し、オープンソースとして開発したチームは、TPU-MLIR において確かに最高です。
4.3 ヘテロジニアス コンピューティング コンパイラにおける TPU-MLIR に関する見解
ヘテロジニアス コンピューティング コンパイラについてはわかりませんが、TPU-MLIR ツール チェーンに従うと、bmodel ファイルが最終的にまだ生成されていることがわかります。bmodel の読み込み中であるはずです -> ホストが入力テンソル アドレスを TPU に送信します-> TPU 計算、および bmodel ファイルも命令のシーケンシャルな集合です。本質的には、以前の BMNNSDK セットに似ていますが、MLIR プラットフォームを使用すると、後の期間の新しいハードウェアまたは命令セットでの拡張性が向上する可能性があります。