SageMaker トレーニングコンパイラのベストプラクティスと考慮事項 - Amazon SageMaker
ベストプラクティス考慮事項

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SageMaker トレーニングコンパイラのベストプラクティスと考慮事項

SageMaker Training Compiler を使用する際には、以下のベストプラクティスと考慮事項を確認してください。

ベストプラクティス

Training Compiler SageMaker でトレーニングジョブを実行する際に最良の結果を得るには、以下のガイドラインを参考にしてください。

一般的なベストプラクティス

  • サポートされるインスタンスタイプ と テスト済みモデル のいずれかを使用していることを確認します。

  • トレーニングスクリプトで Hugging Face Transformers ライブラリを使用して NLP モデルのトークナイザーを作成する場合は、padding='max_length' を指定して、静的な入力テンソル形状を使用していることを確認してください。バッチ内の最長のシーケンスにパディングすると、各トレーニングバッチのテンソルの形状が変わる可能性があるため、padding='longest' を使用しないでください。動的入力形状はモデルの再コンパイルを開始し、合計トレーニング時間が長くなる可能性があります。Transformer トークナイザーのパディングオプションの詳細については「Hugging Face Transformers documentation」の「Padding and truncation」を参照してください。

  • GPU メモリの使用率を測定して、GPU メモリに収まる最大バッチサイズを使用していることを確認します。Amazon SageMaker Training Compiler は、トレーニング中のモデルのメモリ使用量を削減します。これにより、通常は GPU batch_size メモリにより大きなメモリ容量を収めることができます。より大きな batch_size を使用すると GPU の使用率が向上し、合計トレーニング時間が短縮されます。

    バッチサイズを調整する場合、learning_rate も適切に調整する必要があります。例えば、バッチサイズを k 倍に増やした場合は、learning_rate を直線的に (単純に k の乗算)、もしくは k の平方根を乗算して調整する必要があります。これは、トレーニング時間を短縮しながら、同じか同様の収束動作を実現するためです。人気モデルでテスト済みの batch_size のリファレンスについては、「テスト済みモデル」を参照してください。

  • コンパイラで高速化されたトレーニングジョブをデバッグするには、compiler_config パラメータ の debug フラグを有効化します。これにより SageMaker 、 SageMaker デバッグログをトレーニングジョブのログに入れることができます。

    huggingface_estimator=HuggingFace(
    ...
    compiler_config=TrainingCompilerConfig(debug=True)
)

    コンパイラでトレーニングジョブの完全なデバッグを有効化すると、オーバーヘッドが増す可能性があることに注意してください。

のベストプラクティス PyTorch

  • PyTorch モデルを持ち込んでチェックポイントを設定したい場合は、必ず PyTorch /XLA のモデル保存機能を使用してモデルを適切にチェックポイントしてください。この機能について詳しくは、XLA Devices torch_xla.core.xla_model.saveに関するドキュメントのを参照してくださいPyTorch 。

    PyTorch スクリプトに変更を加える方法については、を参照してください PyTorch 直接使用する大規模言語モデル (Hugging Face ストランスフォーマートレーナー API なし)。

    モデル保存機能を使用する実際の用途について詳しくは、「 PyTorch/XLA TPUのHugging Face: より高速で安価なトレーニング」ブログの「チェックポイントの書き込みと読み込み」を参照してください。

  • 分散トレーニングで最適なトレーニング時間を達成するには、以下を考慮します。

    • 単一の GPU インスタンスではなく、複数の GPU を備えたインスタンスを使用します。例えば、単一の ml.p3dn.24xlarge インスタンスは 8 x ml.p3.2xlarge インスタンスと比較してトレーニング時間が短縮されます。

    • ml.p3dn.24xlarge や ml.p4d.24xlarge などの EFA サポートのあるインスタンスを使用します。これらのインスタンスタイプでは、ネットワーク速度が加速され、トレーニング時間が短縮されます。

    • データセットの preprocessing_num_workers パラメータを調整して、前処理が遅いためにモデルトレーニングが遅れることがないようにします。

考慮事項

トレーニングコンパイラーを使用する際には、次の点を考慮してください。 SageMaker

ログ記録、チェックポイント、プロファイリングによるパフォーマンスの低下

  • 明示的な評価につながるモデルテンソルのログ記録、チェックポイント、プロファイリングは避けます。明示的な評価とは何かを理解するために、次のコードコンパイル例を考慮します。

    a = b+c
e = a+d

    コンパイラはコードを次のように解釈し、変数 a のメモリフットプリントを削減します。

    e = b+c+d

    次に、コードを変更して変数 a の print 関数を追加した例を考慮します。

    a = b+c
e = a+d
print(a)

    コンパイラは、変数 a を次のように明示的に評価します。

    e = b+c+d
a = b+c    # Explicit evaluation
print(a)

    たとえば PyTorch、では torch.tensor.items () を使用しないでください。明示的に評価が行われる可能性があります。深層学習では、このような明示的な評価によってモデルのコンパイルグラフ内の融合オペレーションが中断され、テンソルの再計算につながるため、オーバーヘッドが発生する可能性があります。

    Training Compiler SageMaker の使用中に引き続きトレーニング中にモデルを定期的に評価したい場合は、明示的な評価によるオーバーヘッドを減らすため、ロギングとチェックポイントの頻度を低くすることをお勧めします。例えば、エポックごとではなく 10 エポックごとにログを記録します。

  • グラフのコンパイルはトレーニングの最初の数ステップで実行されます。そのため、最初の数ステップは非常に時間がかかると予想されます。ただし、これは 1 回限りのコンパイルコストであり、コンパイルによって今後のステップがはるかに速くなるため、より長い期間トレーニングすることで償却できます。初期コンパイルのオーバーヘッドは、モデルのサイズ、入力テンソルのサイズ、入力テンソルの形状の分布によって異なります。

/XLA API を直接使用する場合の /XLA API PyTorch の使用が間違っている PyTorch

PyTorch/XLA は、既存のトレーニング API の一部を置き換える一連の API を定義しています。 PyTorchこれらを適切に使用しないと、 PyTorch トレーニングが失敗します。

  • PyTorch モデルをコンパイルする際によくあるエラーの 1 つは、演算子とテンソルのデバイスタイプが間違っていることです。 PyTorch モデルを正しくコンパイルするには、CUDA を使用するか、CUDA デバイスと XLA デバイスを混在させるのではなく、必ず XLA devices (xm.xla_device()) を使用してください。

  • mark_step() は XLA 専用の障壁です。正しく設定しないと、トレーニングジョブが停止します。

  • PyTorch/XLA は追加の分散型トレーニング API を提供します。API を適切にプログラミングしないと、勾配が正しく収集されず、トレーニングが収束しなくなります。

PyTorch スクリプトを適切に設定し、前述の API の不適切な使用を避けるには、を参照してください。 PyTorch 直接使用する大規模言語モデル (Hugging Face ストランスフォーマートレーナー API なし)