翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# SageMaker AI 分散データ並列処理ライブラリの設定のヒント
SageMaker AI 分散データ並列処理 (SMDDP) ライブラリを使う前に、次のヒントを確認してください。このリストには、すべてのフレームワークに通じるヒントが含まれています。
**Topics**
+ [データの前処理](#data-parallel-config-dataprep)
+ [単一ノードと複数ノード](#data-parallel-config-multi-node)
+ [Debugger でスケーリング効率をデバッグする](#data-parallel-config-debug)
+ [バッチサイズ](#data-parallel-config-batch-size)
+ [カスタム MPI オプション](#data-parallel-config-mpi-custom)
+ [Amazon FSx を使って最適なストレージとスループット容量を設定する](#data-parallel-config-fxs)
## データの前処理
CPU を利用する外部ライブラリを使ってトレーニング中にデータを前処理すると、SageMaker AI 分散データ並列は `AllReduce` オペレーションに CPU を使用するため、CPU のボトルネックが発生する可能性があります。前処理ステップを GPU を使うライブラリに移動するか、トレーニングの前にすべての前処理を完了することで、トレーニング時間を短縮できる場合があります。
## 単一ノードと複数ノード
このライブラリは、複数のノードを使用して使うことをお勧めします。ライブラリは、シングルホスト、マルチデバイスの設定 (例えば、複数の GPU を持つ 1 つの機械学習コンピューティングインスタンス) で使用できますが、2 つ以上のノードを使う場合、ライブラリの `AllReduce` オペレーションにより、パフォーマンスが大幅に向上します。また、単一ホストでは、NVLink が既にノード内の `AllReduce` の効率に影響しています。
## Debugger でスケーリング効率をデバッグする
Amazon SageMaker デバッガーを使って、トレーニング中に CPU と GPU の使用率およびその他の関心のあるメトリクスをモニタリングおよび視覚化できます。デバッガーの[組み込みルール](https://docs.aws.amazon.com/sagemaker/latest/dg/debugger-built-in-rules.html)を使用して、`CPUBottleneck`、`LoadBalancing`、`LowGPUUtilization` などのコンピューティング性能の問題をモニタリングできます。これらのルールは、Amazon SageMaker Python SDK 推定器を定義するときに、[デバッガー設定](https://docs.aws.amazon.com/sagemaker/latest/dg/debugger-configuration-for-debugging.html)で指定できます。SageMaker AI でのトレーニングに AWS CLI と AWS SDK for Python (Boto3) を使用する場合は、[「Amazon SageMaker API を使用した Amazon SageMaker デバッガーの設定」に示すように、デバッガー](https://docs.aws.amazon.com/sagemaker/latest/dg/debugger-createtrainingjob-api.html)を有効にできます。
SageMaker トレーニングジョブでデバッガーを使用した例を見るには、[SageMaker ノートブックサンプル GitHub リポジトリ](https://github.com/aws/amazon-sagemaker-examples/tree/master/sagemaker-debugger)にあるノートブックサンプルの 1 つを参照できます。デバッガーの詳細については、「[Amazon SageMaker デバッガー](https://docs.aws.amazon.com/sagemaker/latest/dg/train-debugger.html)」を参照してください。
## バッチサイズ
分散トレーニングでは、ノードを追加するにつれて、バッチサイズも比例して増加します。トレーニングジョブにノードを追加し、グローバルバッチサイズを増やすなかで、収束速度を向上させるには、学習レートを上げます。
これを達成する 1 つの方法は、トレーニングジョブの進行に応じて、学習レートを小さな値から大きな値へと一定比率で上げていく、段階的学習レートウォームアップを使うことです。これにより、学習レートの急激な上昇が回避でき、トレーニング開始時の正常な収束が可能になります。例えば、ミニバッチサイズが k 倍されるたびに、学習レートも k 倍される*線形スケーリングルール*を使用できます。この手法の詳細については、研究論文「[正確で大規模なミニバッチ SGD: 1 時間で ImageNet をトレーニングする](https://arxiv.org/pdf/1706.02677.pdf)」のセクション 2 および 3 を参照してください。
## カスタム MPI オプション
SageMaker AI 分散データ並列ライブラリは、高性能クラスター内のノード間の通信を管理する一般的な標準である Message Passing Interface (MPI) を採用し、GPU レベルの通信に NVIDIA の NCCL ライブラリを使っています。TensorFlow または Pytorch `Estimator` でデータ並列ライブラリを使う場合、それぞれのコンテナは MPI 環境を設定し、`mpirun` コマンドを実行して、クラスターノードでジョブを開始します。
カスタム MPI オペレーションは、`Estimator` の `custom_mpi_options` パラメータを使って設定できます。このフィールドに渡された `mpirun` フラグは、どれも `mpirun` コマンドに追加され、トレーニングのために SageMaker AI によって実行されます。例えば次を使って、`Estimator` の `distribution` パラメータを以下のように定義すると、[https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html#nccl-debug](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html#nccl-debug) 変数を使って、プログラムの開始時に NCCL バージョンを出力できます。
```
distribution = {'smdistributed':{'dataparallel':{'enabled': True, "custom_mpi_options": "-verbose -x NCCL_DEBUG=VERSION"}}}
```
## Amazon FSx を使って最適なストレージとスループット容量を設定する
分散データ並列処理を使って複数のノードでモデルをトレーニングする場合は、[FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) を使用することを強くお勧めします。Amazon FSx は、より高速なスループットで共有ファイルストレージをサポートするスケーラブルで高性能のストレージサービスです。Amazon FSx ストレージを大規模に使うと、すべてのコンピューティングノードでデータロード速度を向上させることができます。
通常、分散データ並列処理では、トレーニングの合計スループットが GPU の数に応じてほぼ直線的にスケールすると期待されます。ただし、最適ではない Amazon FSx ストレージを使うと、Amazon FSx スループットが低いため、トレーニングのパフォーマンスが低下する可能性があります。
例えば、最小 1.2 TiB のストレージ容量を持つ [Amazon FSx ファイルシステムの **SCRATCH\$12** デプロイタイプ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html#fsx-aggregate-perf)を使う場合、I/O スループット容量は 240 MB/秒です。Amazon FSx ストレージは、物理ストレージデバイスを割り当てできるように機能し、割り当てられるデバイスが多いほど、スループットが向上します。SRATCH\$12 タイプの最小ストレージ増分は 1.2 TiB で、対応するスループットゲインは 240 MB/秒です。
100 GB のデータセットを扱う 4 ノードクラスターでトレーニングするモデルがあると仮定します。このクラスターに最適化された特定のバッチサイズで、モデルが約 30 秒で 1 つのエポックを完了できると仮定します。この場合、必要な最小 I/O 速度は約 3 GB/秒 (100 GB/30 秒) です。これは明らかに、240 MB/秒よりもはるかに高いスループット要件です。そのような限られた Amazon FSx の能力では、分散トレーニングジョブをより大きなクラスターにスケールすると、I/O のボトルネックの問題が悪化する可能性があります。モデルトレーニングのスループットは、キャッシュの蓄積につれて後の方のエポックでは向上する可能性がありますが、Amazon FSx のスループットは依然としてボトルネックになる可能性があります。
このような I/O のボトルネックの問題を軽減するには、Amazon FSx ストレージのサイズを大きくして、スループット容量を高めてください。通常、最適な I/O スループットを見つけるには、I/O のボトルネックの問題を解決するのに十分であることがわかるまで、さまざまな Amazon FSx スループット能力を試して、推定値と同等またはわずかに低いスループットを与えます。前述の例の場合、2.4 GB/秒のスループットと 67 GB の RAM キャッシュを持つ Amazon FSx ストレージで十分です。ファイルシステムのスループットが最適になった場合、モデルトレーニングのスループットは、即座に、あるいはキャッシュの蓄積に応じて最初のエポックの後に、最大値に達するはずです。
Amazon FSx ストレージを増やす方法およびデプロイタイプの詳細については、Amazon FSx for Lustre ドキュメントの次のページを参照してください。**
+ [ストレージ容量を増やす方法](https://docs.aws.amazon.com/fsx/latest/LustreGuide/managing-storage-capacity.html#increase-storage-capacity)
+ [ファイルシステムのパフォーマンスの集計](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html#fsx-aggregate-perf)