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

モデル並列処理の概要

モデル並列処理は、深層学習モデルを複数のデバイス、インスタンス内またはインスタンス間で分割する分散型トレーニング方法です。この概要ページでは、モデル並列処理の概要、通常は非常に大きなサイズの DL モデルをトレーニングするときに発生する問題の克服に役立つ方法の説明、モデル並列戦略とメモリ消費量の管理に役立つ SageMaker モデル並列ライブラリが提供する内容の例を示します。

モデル並列処理とは

深層学習モデル (レイヤーとパラメータ) のサイズを大きくすると、コンピュータービジョンや自然言語処理などの複雑なタスクの精度が向上します。ただし、1 つの のメモリに収まる最大モデルサイズには制限がありますGPU。DL モデルをトレーニングする場合、GPUメモリの制限は次の方法でボトルネックになる可能性があります。

1 つの でのモデルのトレーニングに関連する制限を克服するためにGPU、 SageMaker はモデル並列ライブラリを提供し、複数のコンピューティングノードで DL モデルを効率的に分散およびトレーニングできるようにします。さらに、 ライブラリを使用すると、 EFAがサポートするデバイスを使用して最も最適化された分散トレーニングを実現できます。これにより、低レイテンシー、高スループット、OS バイパスでノード間通信のパフォーマンスが向上します。

モデル並列処理を使用する前にメモリ要件を見積もる

SageMaker モデル並列ライブラリを使用する前に、次の点を考慮して、大規模な DL モデルをトレーニングする際のメモリ要件を理解してください。

AMP (FP16) と Adam オプティマイザを使用するトレーニングジョブの場合、パラメータあたりの必要なGPUメモリは約 20 バイトで、次のように分類できます。

パラメータが 100 億の比較的小さな DL モデルでも、少なくとも 200GB のメモリが必要になることがあります。これは、1 つの で使用可能な一般的なGPUメモリ (例えば、40 GB /80 GB のメモリを持つ NVIDIA A100 と 16/32 GB の V100) よりもはるかに大きくなりますGPU。 40GB モデルとオプティマイザの状態に必要なメモリ量に加えて、フォワードパスで生成されるアクティベーションなど、他のメモリ消費量もあることに注意してください。必要なメモリは 200GB をはるかに超える場合があります。

分散トレーニングでは、GPUsそれぞれ NVIDIA V100 EC2 および A100 Tensor Core を持つ Amazon P3 A100 および P4 インスタンスを使用することをお勧めします。 V100 CPU コア、、アタッチされたストレージボリュームRAM、ネットワーク帯域幅などの仕様の詳細については、「Amazon EC2 インスタンスタイプ」ページの「高速コンピューティング」セクションを参照してください。

高速コンピューティングインスタンスを使用しても、Megatron-LM や T5 などの約 100 億個のパラメータを持つモデルや、GPT-3 などの数十億個のパラメータを持つさらに大規模なモデルでは、各GPUデバイスのモデルレプリカを適合させることができないことは明らかです。

ライブラリがモデルの並列処理とメモリ節約の手法を採用している方法

このライブラリは、さまざまなタイプのモデル並列処理機能と、オプティマイザ状態のシャーディング、アクティベーションチェックポイント、アクティベーションオフロードなどのメモリ節約機能で構成されています。これらの手法をすべて組み合わせることで、数千億のパラメータで構成される大規模なモデルを効率的にトレーニングできます。

シャーディングデータ並列処理 ( で使用可能 PyTorch）

シャーディングデータ並列処理は、モデルの状態 (モデルパラメータ、勾配、オプティマイザの状態) をデータ並列グループGPUs内で分割する、メモリを節約する分散トレーニング手法です。

SageMaker は、MiCS の実装を通じてシャーディングデータ並列処理を実装します。これは、c ommunication s cale を模倣し、ブログ記事「 での巨大なモデルトレーニングのほぼ線形スケーリング」で AWS説明されているライブラリです。

シャーディングデータ並列処理は、スタンドアロン戦略としてモデルに適用できます。さらに、NVIDIAA100 Tensor Core 、 を搭載した最もパフォーマンスの高いGPUインスタンスを使用している場合ml.p4d.24xlargeはGPUs、 SMDDP Collectives が提供するAllGatherオペレーションでトレーニング速度を向上させることができます。

シャーディングデータ並列処理について詳しく調べ、シャーディングデータ並列処理を設定したり、テンソル並列処理やFP16トレーニングなどの他の手法と組み合わせて使用する方法については、「」を参照してくださいシャーディングデータ並列処理。

パイプライン並列処理 ( PyTorch および で使用可能 TensorFlow）

パイプライン並列処理は、レイヤーのセットまたはオペレーションをデバイスのセット全体に分割し、各オペレーションはそのまま残します。モデルパーティションの数 (pipeline_parallel_degree) の値を指定する場合、 GPUs (processes_per_host) の総数をモデルパーティションの数で割り切れる必要があります。これを正しく設定するには、pipeline_parallel_degree および processes_per_host のパラメータに正しい値を指定する必要があります。簡単な計算は以下のようになります。

(pipeline_parallel_degree) x (data_parallel_degree) = processes_per_host

指定した 2 つの入力パラメータを指定すると、ライブラリがモデルレプリカ (別名 data_parallel_degree) の数を計算します。

例えば、 などの 8 つのGPUワーカーを持つ ML インスタンスを使用する"processes_per_host": 8ように "pipeline_parallel_degree": 2と を設定するとml.p3.16xlarge、ライブラリは GPUsと 4 方向のデータ並列処理全体で分散モデルを自動的にセットアップします。次の画像は、4 方向のデータ並列処理と双方向パイプライン並列処理GPUsを実現する 8 つの にモデルを分散する方法を示しています。各モデルレプリカは、パイプライン並列グループとして定義し、 としてラベル付けしPP_GROUP、2 つの に分割されますGPUs。モデルの各パーティションは 4 つの に割り当てられGPUs、4 つのパーティションレプリカはデータ並列グループにあり、 としてラベル付けされますDP_GROUP。テンソル並列処理がなければ、パイプライン並列グループは基本的にモデル並列グループになります。

パイプラインの並列処理について詳しくは、「Model SageMaker Parallelism Library の主な機能」を参照してください。

パイプライン並列処理を使用してモデルの実行を開始するには、 SageMaker 「モデル並列ライブラリ を使用して SageMaker 分散トレーニングジョブを実行する」を参照してください。

テンソル並列処理 ( で利用可能 PyTorch）

Tensor 並列処理は、個々のレイヤー (nn.Modules) をデバイス間で分割し、並列に実行します。次の図は、ライブラリがモデルを 4 つのレイヤーに分割して双方向のテンソル並列処理 ("tensor_parallel_degree": 2) を実現する方法の最も単純な例を示しています。各モデルレプリカのレイヤーは二分され、2 つの に分散されますGPUs。この例では、モデル並列設定には "pipeline_parallel_degree": 1と "ddp": True (バックグラウンドで PyTorch DistributedDataParallel パッケージを使用) も含まれているため、データ並列度は 8 になります。このライブラリは、テンソル分散モデルのレプリカ間の通信を管理します。

この機能の便利さは、特定のレイヤーまたはレイヤーのサブセットを選択してテンソル並列処理を適用できる点にあります。のテンソル並列処理やその他のメモリ節約機能の詳細 PyTorch、およびパイプラインとテンソル並列処理の組み合わせの設定方法については、「」を参照してくださいテンソル並列処理。

オプティマイザ状態シャーディング ( で利用可能 PyTorch）

ライブラリがオプティマイザステートシャーディングをどのように実行するのかを理解するために、4 つのレイヤーからなる単純なモデル例を考えてみましょう。ステートシャーディングを最適化する上で重要なのは、オプティマイザの状態をすべての にレプリケートする必要がないことですGPUs。代わりに、オプティマイザの状態の単一のレプリカが、デバイス間の冗長性なくデータ並列ランクにわたってシャーディングされます。例えば、0 はレイヤー 1 GPU のオプティマイザ状態を保持し、次の GPU 1 は L2 のオプティマイザ状態を保持します。次のアニメーション図は、オプティマイザ状態のシャーディング手法による後方伝播を示しています。後方伝播の最後には、optimizer apply (OA) オペレーションでオプティマイザの状態を更新し、all-gather (AG) オペレーションで次の反復に備えてモデルパラメータを更新するための計算時間とネットワーク時間が残ります。最も重要なのは、reduceオペレーションが 0 GPU のコンピューティングと重複する可能性があるため、メモリ効率が高く、後方伝播が速くなります。現在の実装では、AG と OA のオペレーションは compute と重複しません。その結果、AG オペレーション中の計算時間が長くなる可能性があるため、トレードオフが発生する可能性があります。

この機能の使用方法の詳細については、「Optimizer State Sharding」を参照してください。

アクティベーションオフロードとチェックポイント ( で利用可能 PyTorch）

GPU メモリを節約するために、ライブラリはアクティベーションチェックポイントをサポートしているため、フォワードパス中にユーザーが指定したモジュールのGPUメモリに内部アクティベーションが保存されるのを防ぎます。ライブラリはバックワードパス中にこれらのアクティベーションを再計算します。さらに、アクティベーションオフロード機能は、保存されたアクティベーションをCPUメモリにオフロードし、バックワードパスGPU中に にフェッチバックして、アクティベーションメモリのフットプリントをさらに削減します。これらの機能の使用方法について詳しくは、「Activation Checkpointing」と「Activation Offloading」を参照してください。

モデルに適した手法の選択

適切な手法と設定の選択の詳細については、SageMaker 「分散モデル並列のベストプラクティス」と「設定のヒントと落とし穴」を参照してください。