「Amazon SageMakerデータパラレルライブラリを使用して、トレーニングを高速化します」

「Amazon SageMakerデータパラレルライブラリを活用して、効率的なトレーニングを実現しましょう」

大規模言語モデル（LLM）のトレーニングは、Llama2、Falcon、およびStarCoderなど、いくつかの公開モデルがリリースされたことで、昨年からますます人気が高まっています。顧客は、10億から1750億以上のパラメータを持つ前例のないサイズのLLMをトレーニングしています。これらのLLMをトレーニングするには、現在の巨大なトレーニングデータセットとモデルサイズを処理するために、数百から数千のグラフィックスプロセッシングユニット（GPU）を使用する必要があります。分散トレーニングにおけるボトルネックの1つは、NVIDIA Collective Communication Library（NCCL）によって処理されるGPU通信です。多くの大規模分散トレーニングジョブでは、GPU間の通信に実際のGPU演算よりも多くの時間が費やされることがあります。このGPU通信のボトルネックを軽減し、トレーニングを高速化するために、Amazon SageMakerは、SageMaker分散データパラレルライブラリ（SMDDP）の一部として最適化されたAllGather集合操作を発表しています。AllGatherは、DeepSpeedゼロ冗長最適化器（ZeRO）やFully Sharded Data Parallelism（FSDP）などの一般的なメモリ効率の良いデータパラレルismソリューションで最もよく使用される集合操作であり、GPU通信のオーバーヘッドの主な要因です。本記事では、SMDDPの動作概要、Amazon SageMakerトレーニングスクリプトでのSMDDPの有効化方法、および期待できるパフォーマンスの向上について説明します。

解決策の概要

従来のデータ並列トレーニングでは、モデル全体を複数のGPUに複製し、各モデルがデータセットの異なるシャードでトレーニングするようにします。バックワードパスでは、勾配はGPUワーカー間で平均化され、異なるデータシャードでトレーニングされたにもかかわらず、各モデルレプリカは同じ勾配値で更新されます。この手法により、大規模なデータセットでの高速トレーニングが可能になります。しかし、現在の一部の大規模モデル（例：Llama2 70B）は、GPUメモリ全体に収まるほどには大きくないため、従来のデータ並列ismは使えません。GPUメモリの制約を克服しながらデータ並列ismの利点を引き続き得るため、DeepSpeed ZeRO、PyTorch FSDP、およびAmazon SageMakerモデル並列ismライブラリなどのシャードデータ並列ismが人気を集めています。

シャードデータパラレリズムでは、モデル全体をGPUワーカーに複製するのではなく、モデルのパラメータ、勾配、およびオプティマイザの状態を分割して（つまり、シャード化して）トレーニングジョブのGPUに分散させます。前向きおよび後ろ向きの計算を行うために、パラメータは他のGPUワーカーのシャードから収集され、1つまたは複数のモデル層が形成されます。計算が実行された後、これらの層はメモリから解放され、次の一連の層のために収集されます。モデルパラメータの分割ではなく、オプティマイザの状態と勾配のみが分割されるバリアントもあります。このタイプのシャードデータパラレリズムでも、AllGatherは前向きパス計算の前にのみ使用され、他のGPUワーカーから異なる勾配またはオプティマイザの状態シャードで更新されたモデルパラメータを収集するために使用されます。DeepSpeed ZeROステージおよびSHARD_GRAD_OP FSDPシャーディング戦略に詳細については、参照してください。

パラメータがシャードされないときは、AllGather集合操作が実行されます。NCCLはこのルーチンの標準のオープンソース実装を提供します。以下に示すように、AllGatherに関与する各GPUワーカーは、入力バッファを持ち始め、他のワーカーからのすべての入力バッファが連結されたままになります。シャードデータパラレリズムでAllGatherが使用される場合、入力バッファにはモデルパラメータのシャードが含まれ、大きな出力バッファには他のシャードから生成された1つまたは複数のモデル層が実現されます。

• エグゼクティブアーキテクトのFinOpsへのアプローチ：AIと自動化がデータ管理を効率化する方法
• テックの雇用削減はAI産業について何を示しているのか？
• 「データウェアハウジング入門ガイド」

分散トレーニングでは通常、NCCLはAllGatherに使用されますが、その基礎となる低レベルの実装はAmazon Elastic Compute Cloud（Amazon EC2）インスタンスのネットワークインフラに適したものではないため、パフォーマンスが低下し、エンドツーエンドのトレーニングが遅くなることがあります。SMDDPライブラリは、PyTorchを使用した分散トレーニングジョブのパフォーマンスを向上させるためのNVIDIA GPU用の集合通信ライブラリであり、NCCLに代わるプラグアンドプレイの置換となります。具体的には、SMDDPはp4d/p4deインスタンスタイプ向けに最適化されたAllGatherの実装を提供します。

AllGatherのような集合操作は順方向と逆方向のパス計算をブロックするため、これらの操作の高速な実行は、収束に副作用を与えることなくエンドツーエンドのトレーニング時間を短縮します。シャーディングされたデータ並列トレーニングで使用頻度の低い他の集合操作は、NCCLにフォールバックして処理されます。

ウォークスルー

AWSに最適化されたAllGather

AWSに最適化されたAllGatherは、以下の技術を使用してNCCLに比べてAWSインフラ上でのパフォーマンスを向上させます：

1. Elastic Fabric Adapter（EFA）ネットワークを介してインスタンス間でデータを移動します。EFAはAWSの低レイテンシで高スループットなネットワークソリューションであり、インターノードネットワーク通信においてオールトーオールのパターンを使用することで、NCCLのリングやツリーの通信パターンに比べてパケットホップを少なくすることができます。
2. GDRCopyを使用して、ローカルのNVLinkとEFAネットワークトラフィックを調整します。GDRCopyは、CPUプロセスとGPU CUDAカーネル間の低レイテンシ通信を提供するライブラリです。この技術により、ノード内およびノード間のデータ移動をパイプライン化することができます。
3. GPUストリーミングマルチプロセッサの使用を削減し、モデルカーネルにより多くの計算パワーを返します。AWS P4d/P4deインスタンスは、それぞれ108のストリーミングマルチプロセッサを備えたNVIDIA A100 GPUを搭載しています。NCCLは最大24のストリーミングマルチプロセッサを使用してコレクティブを実行する一方で、SMDDP Collectivesは最大9のストリーミングマルチプロセッサしか使用しません。保存されたストリーミングマルチプロセッサは、モデル計算カーネルによるより速い実行に活用できます。

使用方法

SMDDPコレクティブは、PyTorchを介してtorch.distributedモジュールのプロセスグループ抽象化とネイティブに統合されています。プロセスグループは、AllGather、ReduceScatter、AllReduceなどの一般的な集合操作のためのインターフェースを定義します。ユーザーは一般的な分散コードを書き、使用されるコンピュートデバイスに基づいてこれらの操作の実装を提供するbackendを選択することができます。CPUトレーニングジョブでは、glooまたはmpiバックエンドがよく使用され、NVIDIA GPUではncclバックエンドが使用されます。

SMDDPライブラリは、プロセスグループ抽象化にカスタムバックエンドとして自身を登録することで機能します。これは以下のコードスニペットで示されるインポートステートメントによって行われます。その後、GPUベースの分散トレーニングジョブのバックエンドを選択する際に、ncclをsmddpで置き換えるだけです。 smddpバックエンドはncclバックエンドと同じセマンティクスを守り、同じトレーニングシナリオをサポートします。

DeepSpeed

import smdistributed.dataparallel.torch.torch_smddpdeepspeed.init_distributed(dist_backend="smddp")  # "nccl"の代わりに

FSDP

import smdistributed.dataparallel.torch.torch_smddpdist.init_process_group(backend="smddp")  # "nccl"の代わりに

ベンチマーク

モデルトレーニングなしで単体のAllGatherパフォーマンスをベンチマークにしました。以下は、32のp4dインスタンスでのNCCLとSMDDP AllGatherのサンプル結果です。X軸はAllGatherの出力サイズを、Y軸はp4dの400 GbpsのEFAネットワークのネットワーク利用率を表します。4つのサブグラフは、それぞれ1つ、2つ、4つ、8つのランクが各p4dインスタンスでAllGather操作に参加する一般的な通信グループパターンを表しています。

これらのマイクロベンチマークは、SMDDP が 2 つの主要な特徴を持って NCCL よりも優れていることを示しています：

1. すべての設定において、SMDDP のピークパフォーマンス（約 90% の帯域幅利用）は NCCL のピークパフォーマンス（約 80% の帯域幅利用）よりも高い。
2. SMDDP は NCCL よりもはるかに小さなバッファサイズでピークパフォーマンスに到達します。これにより、小さいモデルや DeepSpeed で小さい AllGather バッファサイズを設定した場合など、トレーニングスピードが向上します（AllGather サイズはレイヤーサイズと等しくする必要はありません）。

モデルトレーニングのベンチマーク

GPU通信が大きなボトルネックとなる大規模なトレーニングジョブでは、SMDDP によってモデルのトレーニングスピードが目を見張るほど向上します（モデルごとの TFLOPS/GPU で測定）。

設定	パフォーマンス
モデル/トレーニング	クラスター	シャーデッドデータ並列処理ソリューション	NCCL によるモデル TFLOPS/GPU	SMDDP によるモデル TFLOPS/GPU	% スピードアップ
13B Llama2 シーケンス長：4096 グローバルバッチサイズ：4M トークン	64 p4d.24xlarge ノード（512 NVIDIA A100 GPUs）	PyTorch FSDP	97.89	121.85	24.40%
65B GPT-NeoX シーケンス長：2048 グローバルバッチサイズ：4M トークン	64 p4d.24xlarge ノード（512 NVIDIA A100 GPUs）	DeepSpeed ZeRO Stage 3*	99.23	108.66	9.50%

*EleutherAI の Megatron-DeepSpeed リポジトリが使用されました。テンソル並列処理も 8 つのテンソル並列度で有効になっています。

注：モデル TFLOPS/GPU は、ここで定義されたモデル FLOPS の利用率の計算に基づいています。他の場所でのベンチマークの数字では、ハードウェアの TFLOPS/GPU がパフォーマンス指標として引用されることがあります。ハードウェアの TFLOPS/GPU は、おおよそ 4/3 x モデル TFLOPS/GPU として近似することができます。

結論

この記事では、たった 2 行のコード変更で Amazon SageMaker 上のシャーデッドデータ並列トレーニングジョブを大幅に高速化する方法を紹介しました。大規模な分散トレーニングは LLM の出現によりますます普及していますが、スケールの拡大とともに高コストも発生します。GPU間の通信ボトルネックを削減することで、SMDDP はスケールでより速くトレーニングし、計算リソースを節約するお手伝いをします。シャーデッドデータ並列トレーニングの SMDDP サンプルは、Amazon SageMaker Examples GitHub リポジトリでご覧いただけます。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!