HyperAI超神经

Profiler v1.9 の改良点は、実行時やメモリで最もエネルギーを消費する実行ステップに重点を置き、GPU と CPU 間のワークロード分散も視覚化します。

Profiler v1.9 には、次の 5 つの主要な新機能が追加されています。

1. 分散トレーニングビュー: これは、分散トレーニングタスクで消費される時間とメモリを理解するのに役立ちます。トレーニングモデルがあるとします。負荷をワーカーノードに分割して並列実行すると、ブラックボックスのようになってしまい、さまざまな問題が発生する可能性があります。モデルの全体的な目標は、トレーニング速度を向上させることです。この分散トレーニングビューは、単一ノード内の問題の診断とデバッグに役立ちます。

2. メモリビュー: このビューにより、メモリ使用量をより深く理解できます。このツールは、実行のさまざまな段階でプログラムのアクティブなメモリ割り当てを表示することで、メモリ不足エラーを回避するのに役立ちます。

3. GPU アプリケーションの視覚化: このツールは、GPU が完全に活用されるようにします。

4. クラウドストレージのサポート: Tensorboard プラグインは、Azure Blob Storage、Amazon S3、Google Cloud Platform からデータを読み取り、解析できるようになりました。

5. ソースコードにジャンプします。 この機能により、スタックトレース情報を視覚化し、ソースコードに直接ジャンプできるようになります。これにより、分析結果に基づいてコードを迅速に最適化し、反復することができます。

PyTorch プロファイラー Colab ポータル

Colab ポータルの中国語版

Colab コンテンツの概要:

データとモデルを準備する
プロファイラーを使用して実行イベントを記録する
プロファイラーを実行する
TensorBoard を使用して結果を表示し、モデルのパフォーマンスを分析する
プロファイラーによるパフォーマンスの向上
他の高度な機能を使用してパフォーマンスを分析する

PyTorch プロファイリングツールを使ってみる

初め：

$ pip インストール torch-tb-profiler

import torch.profiler as profiler
With profiler.profile(XXXX)

述べる： CUDA と CPU の分析については、を参照してください。ここ

with torch.profiler.profile( 
activities=[ 
torch.profiler.ProfilerActivity.CPU, 
torch.profiler.ProfilerActivity.CUDA],

profiler.record_function("$NAME"): 関数ブロックにデコレーター (名前関連のラベルを参照するデコレーター) を追加できるようにします。
profiler.profile の Profile_memory=True パラメータを使用すると、CPU と GPU のメモリ使用量を分析できます。

PyTorch モデルのパフォーマンスを視覚化する

### 分散トレーニング

ディープラーニングの最近の進歩により、大規模なデータセットと大規模なモデルの価値が証明されました。これは、モデルのトレーニングにより多くのコンピューティングリソースが必要になることも意味します。

Distributed Data Parallel (DDP) と NVIDIA Multi-Card Communication Framework (NCCL) は、ディープラーニングトレーニングを高速化するために PyTorch で広く採用されているパラダイムです。

このバージョンの PyTorch Profiler では、NCCL バックエンドの DDP がサポートされるようになりました。
ここに画像の説明を挿入します

コンピューティング/通信の概要

分散トレーニングビューの「計算/通信の概要」では、すべてのワーカー間の「ロードバランサー」ノードの計算と通信の比率を粒度の観点から観察できます。

ロードバランサー関連のリンク: ここ

シナリオ 1:

1 つのワーカーの計算時間とオーバーラップ時間が他のワーカーの計算時間よりも長い場合は、ワークロードバランシングに問題があるか、1 つのノードが分散していることを示している可能性があります。計算は、GPU コア時間の合計からオーバーラップ時間を差し引いたものです。オーバーラップタイムとは、計算プロセス中にインターリーブ通信によって節約される時間を指します。

オーバーラップが長いほど、計算と通信の間の並列性が優れていることを示します。理想的には、計算と通信が完全に重複します。通信時間は、総通信時間からオーバーラップ時間を差し引いたものです。

次の例は、これが Tensorboard でどのように見えるかを示しています。
ここに画像の説明を挿入します
はぐれ者の例

シナリオ 2:

バッチサイズが小さい場合 (つまり、すべてのワーカーでの計算が比較的小さい場合)、または送信する必要があるデータが大きい場合、プロファイラーでは計算通信率も小さくなることがあります。そして長い待ち時間。

ユーザーは、この計算/通信ビューに基づいてコードをレビューしたり、勾配累積を採用して通信を削減したり、バッチサイズを増やすことで通信率を削減したりすることができます。 DDP 通信時間はモデルのサイズによって異なります。バッチサイズはモデルサイズには依存しません。したがって、バッチサイズを増やすと、計算時間が長くなり、計算通信のケースが大きくなる可能性があります。

### 同期/通信の概要

同期/通信ビューでは、通信効率を観察できます。これは、ステップ時間から計算時間と通信時間を引いたものとして計算されます。同期時間は、他のワーカーの待機と同期に費やされる合計通信時間の一部です。同期/通信ビューには、初期化、データローダー、CPU 計算などが含まれます。

このビューから次のことがわかります。総通信量のうち実際にデータ交換に使用される割合と、他のワーカーがデータを提供するのを待つアイドル時間はどれくらいですか。

たとえば、非効率なワークロードバランシングや分散の問題がある場合、これは [同期/通信] ビューで発見できます。このビューには、一部のワーカーが他のワーカーよりも長く待機していることが表示されます。

上の表から、各ノードのすべての通信事業者の詳細な統計を知ることができます。このテーブルを通じて、どのオペレータタイプが呼び出されるか、各オペレータが呼び出される回数、各オペレータによって送信されるデータのサイズなどを知ることができます。

メモリビュー

このツールを使用すると、モデル内のオペレーターのハードウェアリソース消費を把握できます。オペレーターレベルで時間とメモリの消費量を理解すると、パフォーマンスのボトルネックを解決し、モデルの実行を高速化するのに役立ちます。GPU のメモリサイズが限られているため、メモリ使用効率を最適化すると、次のような効果が得られます。

端末レベルのタスクでより優れたパフォーマンスを発揮する大規模なモデルを実行できるようになります。
バッチサイズを大きくできるため、トレーニング速度が向上します。

プロファイラーは、プロファイラー間隔中のすべてのメモリ割り当てを記録します。「デバイス」を選択すると、GPU 側またはホスト側の各オペレーターのメモリ使用量の詳細が表示されます。

注: 次のメモリデータを生成するには、profile_memory=True を有効にする必要があります。

タイムライン上の GPU メトリクス

この機能を使用すると、1 つ以上の GPU が十分に活用されていない場合に、パフォーマンスの問題を簡単にデバッグできます。理想的には、プログラムの GPU 使用率が高く (100% の GPU 使用率にできるだけ近い)、CPU 間の通信コストが最小限で、電力消費がないことが必要です。

概要： 概要ページでは、3 つの重要な GPU 使用率メトリクス (つまり、GPU 使用率、推定 SM 効率、推定達成占有率) の結果がさまざまなレベルで強調表示されます。

基本的に、各 GPU には多くの SM があり、各 SM には多くの Warp があり、多くのスレッドを同時に実行できます。 Warp はスレッド数が GPU に依存するため、多くのスレッドを実行します。高いレベルの観点から見ると、タイムライン上の GPU メトリクスは、開発者がスタック全体の全体像を把握するのに役立ちます。これは非常に重要です。

GPU 使用率が低い場合は、モデルに潜在的な問題があることを示しています。一般的な理由は次のとおりです。

カーネル内の並列処理が不十分です。つまり、バッチサイズが小さすぎます。
ループ内で小規模なカーネルを呼び出します。つまり、起動時のオーバーヘッドは償却されません。
CPU または I/O のボトルネックにより、作業内容が不十分になり、GPU 使用率が低下します。

概要ページの「パフォーマンスに関する推奨事項」セクションには、GPU 使用率を改善できる実用的な提案が含まれています。この例では、GPU 使用率が低いため、パフォーマンス上の推奨事項はバッチサイズを増やすことです。パフォーマンスの推奨事項に従って、バッチサイズを 4 から 32 に増やすと、GPU 使用率が 60.68% 増加しました。

GPU 使用率: Profiler では、GPU エンジンがワークロードを実行するときにステップ間隔時間が発生します。使用率が高いほど良いことになります。 GPU 使用率のみによってパフォーマンスのボトルネックを判断するのは正確ではありません。ストリーミングマルチプロセッサ (ストリーミングマルチプロセッサ) がいくつ実行されているかはわかりません。

このメトリクスはアイドル期間の検出に役立ちますが、値が高いことが必ずしも GPU 使用率の高さを示すわけではないことに注意してください。たとえば、継続的に実行されているシングルスレッドカーネルの GPU 使用率は 100% になります。

推定ストリームプロセッサ効率 (Est. SM Efficiency) は、より詳細な指標です。 これは、追跡プロセス全体で使用されている SM の割合を表し、SM 上に少なくとも 1 つのアクティブなラップが存在する時間の割合と、アイドルワープである時間の割合を表します。

NVIDIA ドキュメント: ここ

SM の推定効率にも限界があります。ブロックごとに 1 つのスレッドしか持たないカーネルでは、すべての SM を完全に利用することはできません。 SM 効率のみに基づいて各 SM の使用率を知ることは不可能です。これは、メモリのロード結果を待つ間の一時停止を含む、各 SM の進行中の動作のみを知ることができます。

SM の高い使用率を維持するには、ストールが発生したときに実行できる十分な数の Ready Wrap を確保する必要があります。

パフォーマンス診断の問題については、推定達成占有率の方が推定 SM 効率と GPU 使用率よりも正確です。推定される達成占有率は、SM ごとに同時にアクティブにできるワープの数を示します。多くの場合、十分な数のアクティブなワープがあることが、良好なスループットを達成するための鍵となります。 GPU 使用率や SM 効率とは異なり、この値をできるだけ高くすることが最終目標ではありません。

経験則として、このメトリクスを 15% 以上に増やすことで、良好なスループットの向上を実現できます。しかし、ある時点で利益が減少することがあります。たとえば、値が 30% に達した場合、その後のリターンは不確実になります。このメトリクスは、カーネル実行中のすべてのワープスケジューラの平均を示します。

NVIDIA ドキュメント: ここ

推定占有率の値が大きいほど良好です。

詳細: Resnet50_batchsize4

詳細な詳細: Resnet50_batchsize32

カーネルビュー: カーネルには「SM ごとのブロック数」と「推定達成占有率」があります。

推定達成占有率は、モデルの健全性を比較するのに便利なツールです。

SM あたりの平均ブロック数:

SM あたりのブロック数 = コア内のブロック数/GPU 内の SM の数。この数値が 1 未満の場合は、GPU マルチプロセッサが完全に利用されていないことを示します。「SM あたりの平均ブロック数」は、各実行の継続時間を重みとして使用した、このカーネル名のすべての実行の加重平均です。

平均推定占有率:

推定達成占有率は上記のように定義されます。平均推定達成占有率は、各実行の継続時間を重みとして使用した、このカーネル名のすべての実行の加重平均です。

追跡ビュー:

トレースビューには、モデル内のオペレーターの継続時間とどのシステムが操作を実行したかを表すタイムラインが表示されます。このビューは、高コストと長い実行の原因が入力によるものなのか、モデルのトレーニングによるものなのかを特定するのに役立ちます。現在、追跡ビューにはタイムライン内の GPU 使用率と推定 SM 効率が表示されます。

上記の例では、スレッド 28022 での「ProfilerStep5」の GPU 使用率は、「Optimizer.step」での GPU 使用率よりも高くなります。拡大してその理由を確認できます。

上の写真からわかるように、前者のコアは後者のコアよりも長くなります。後者のカーネル実行時間は短すぎるため、GPU 使用率が低下します。

推定SM効率： 各コアの SM 効率は 0 ～ 100% の間で計算されます。たとえば、以下のカーネルには 64 ブロックしかなく、この GPU の SM が 80 である場合、その「推定 SM 効率」は 64/80、つまり 0.8 になります。

クラウドストレージのサポート

pip install tensorboard を実行した後、クラウドプロバイダーを通じてデータを読み取るために、次のコマンドを実行できます。

torch-tb-profiler[blob] 
torch-tb-profiler[gs] 
torch-tb-profiler[s3]

データは、pip install torch-tb-profiler[blob]、pip install torch-tb-profiler[gs]、または pip install torch-tb-profiler[S3] を使用して、クラウドサービスプロバイダーを通じて読み取ることができます。

詳細については、以下を参照してください。ここ

ソースコードにジャンプ

TensorBoard と PyTorch Profiler を Visual Studio Code (VS Code) に直接統合することの大きな利点の 1 つは、Profiler のスタックトレースからソースコード (ファイルと行) に直接ジャンプできることです。 VS Code Python 拡張機能は TensorBoard 統合をサポートするようになりました。

ソースコードへのジャンプは、Tensorboard が VS Code で実行されている場合にのみ使用できます。 _stack=True でプロファイリングすると、スタックトレースがプラグイン UI に表示されます。 PyTorch Profiler でスタックトレースをクリックすると、VS Code が対応するファイルを開き、デバッグのために対応するコードに直接ジャンプします。このようにして、分析結果と提案に基づいてコードを迅速に最適化および変更できます。

Visual Studio Code プラグイン UI を使用してソースコードにジャンプする

バッチサイズのパフォーマンスを最適化する方法に関する詳細なチュートリアルを確認してください。ここ

PyTorch Profiler は、Trainer.profiler=pytorch を使用して Lightning トレーニングタスクを開始してトレースを生成するだけで、PyTorch Lightning と統合することもできます。

詳細な例: ここ

元のアドレス: ここ

PyTorch 公式ブログ: PyTorch Profiler V1.9 の詳細説明