効率的にトレーニングするにはどうすればいいですか?概要: 大規模なディープラーニングトレーニングのための並列分散システム

この記事は、Heart of Autonomous Driving の公開アカウントから許可を得て転載したものです。転載については出典元にお問い合わせください。

1 月 23 日の論文「並列および分散型の大規模モデル深層学習トレーニングのためのシステム」は UCSD からのものです。

ディープラーニング (DL) は、コンピューター ビジョン、自然言語処理、表形式データ分析など、さまざまな分野のアプリケーションを変革しました。 DL モデルの精度を向上させるための探求により、ますます大規模なニューラル アーキテクチャの調査が行われ、最近の Transformer モデルの中には、学習可能なパラメータが数千億に及ぶものもあります。これらの設計により、メモリのボトルネック、実行時の非効率性、モデル開発コストの高さなど、スケール主導のシステム課題が DL 空間にもたらされます。これらの問題に対処するための取り組みとして、ニューラル アーキテクチャの並列化、メモリ階層全体にわたるデータのスピル、メモリ効率の高いデータ表現などの手法が検討されてきました。この調査では、大規模モデルトレーニングシステムの状況を調査し、主要な課題と、それらの課題に対処するために使用されるさまざまな手法に焦点を当てます。

DL 実践における最近の発展により、システム モデルのサイズに関して DL 研究に新たな課題が生じています。実践者たちは、DL モデルに非常に大規模なニューラル グラフを使用することを検討し始めており、その一部には数十億、あるいは数兆ものトレーニング可能なパラメーターが含まれています。主な例としては、NLPトランスフォーマーモデルのBERT Large[16]、GPT-3[13]、MetaのDeep Learning Recommender Model（DLRM）[41]などが挙げられます。これらのモデルの規模の大きさにより、3 つの主要領域で深刻な課題が生じます。

• （１）メモリのスケーラビリティ標準的な DL トレーニングでは通常、モデルのパラメータをアクセラレータ (GPU など) のメモリに保存し、サンプリングされたデータを使用して各パラメータの勾配更新を計算します。非常に大規模なモデルの場合、パラメータ、中間計算、勾配更新を保持するために必要なスペースが、アクセラレータの比較的限られたメモリ リソースを超えることがよくあります。 Tesla V100 [2]などのハイエンドのコンシューマーGPUには16～32GBのデバイスメモリが搭載されていますが、大規模なDLRMには数百GBのスペースが必要になる場合があります。
• （２）パフォーマンスパラメータ数の増加は通常、実行時間の増加につながります。さらに、複雑なモデルアーキテクチャでは、モデルの学習能力を向上させるために大規模なデータセットが必要になることがよくあります。たとえば、GPT-3は300Bトークン[13]でトレーニングされ、オープンソースのBLOOM言語モデルは366Bトークン[12]でトレーニングされています。このようなモデルのトレーニングには数週間から数か月かかることもあります[12, 41]。したがって、実行パフォーマンスを向上できる最適化は、大規模な DL モデルの開発者にとって非常に有益です。
• （３）研修費用最初の 2 つの課題に対する標準的な解決策は、通常、複数のデバイス間でのストレージまたは実行の並列化です。ただし、このアプローチでは計算コストが大幅に増加する可能性があります。 BLOOMはトレーニングに416個のA100 GPUを使用し、Megatron LMは512個を使用します[5]。これはほとんどの実践者にとって非現実的であり、特にこれらの GPU を数週間、あるいは数か月のトレーニングに保持する必要がある場合は非現実的です。 BLOOM のトレーニングプロセスを AWS 上で複製するには 550 万ドルの費用がかかります。これは、最適なハイパーパラメータ設定と構成を評価するために複数のモデルをトレーニングすることを含むモデル選択の追加コストを考慮に入れていないことに注意してください[29]。

モデルサイズの限界が押し広げられるにつれて、大規模モデル DL 空間のさらなる進歩を可能にするために、これらの課題に対処することがますます必要になります。そのため、これらの問題に対処するためにさまざまなシステムや技術が開発されてきました。いくつかの方向性としては、再マテリアライゼーション[15]、データスピル/CPUオフロード[23、36、37、45–47]、パイプライン/モデル並列処理[21、25、27、33、40]、ハイブリッド並列処理[26、31、36、37、60]などがある。これらのトピックは「大規模モデルトレーニング手法」の傘下にあり、産業界や学界の研究者の注目を集めていますが、この分野の研究量が多いため、トピックの方向性を決定することが困難です。この記事では、大規模モデル DL トレーニング システムの現状をレビューし、この分野の成長と発展の将来の方向性を評価します。

この分野に関する高レベルで簡潔なレビューが最近いくつか発表されている[20, 54]が、それらは包括的ではなく、モデル選択、ハイブリッド並列処理、技術的な交差点などの主要なトピックをカバーしていない。この記事では、これらの分野について説明し、最先端の技術をさらに詳しく掘り下げていきます。

モデル並列処理とは、ニューラル アーキテクチャ グラフをサブグラフに分割またはシャーディングし、各サブグラフまたはモデル シャードを異なるデバイスに割り当てる手法を指します。フィードフォワード ネットワークでは、これらのフラグメントは積み重ねられたレイヤーのグループを指す場合があります。

モデル並列処理による高速化の可能性は、アーキテクチャとシャーディング戦略に大きく依存します。フィードフォワード ネットワーク上の順次モデル シャーディング (図 A を参照) では、並列実行の余地は提供されませんが、アクセラレータ間の依存関係グラフが導入されます。ただし、このシャーディング戦略は、メモリ要件を複数のデバイスに分散し、セットアップがかなり簡単であるため、Transformer などのシーケンシャル アーキテクチャでは依然として人気があります。他のケースでは、ニューラル計算グラフは、オペレータ間の並列処理の自然な機会を提供します (図 B を参照)。

図に示すように、A) は、単一の GPU に収まらない大規模なフィードフォワード ネットワークをモデル並列化して 3 つの GPU で実行する方法を示しています (注: 実行速度は高速化されません。並列実行はなく、パーティション化されたメモリ要件のみです)。B) 3 つの GPU でのパフォーマンス モデル並列シャーディング戦略の例。並列実行レイヤーは共通の色で表されます。この戦略は、演算子グラフ内の既存の並列実行の機会を活用します。グラフの性質がより順次的である場合は、これが必要ない場合があります。

もう 1 つのアプローチは、ネットワーク内の個々のオペレーターを実際に分割することです。一部の演算子 (埋め込みテーブルなど) は、最小限のオーバーヘッドで幅ごとに分割できます。行列乗算などの他の処理は、分割することができますが（例えば、並列GEMM戦略[55]を使用）、より多くの通信ステップが必要になります。図はモデル並列埋め込みテーブルの例を示しています。これらの幅スライス戦略は、入力テンソルの分割を必要とするため、テンソル並列処理と呼ばれることが多く、オペレータ間モデル並列処理よりもパフォーマンスの高いオペレータ内並列処理を実現できますが、実装にはより多くの労力と思考が必要です。さらに、ほとんどのテンソル並列演算子では、分割された出力を再集約するために少なくとも 1 つの全収集通信ステップが必要であるため、パフォーマンス上の利点は軽減されます。 Mesh TensorFlow[51]は、テンソル並列計算を指定するための一般的なフレームワークと言語を提供しますが、現在はサポートもメンテナンスもされていません。

あらゆるタイプのモデル並列処理では、GPU 間通信が導入されます。最新の Nvidia GPU は、最大 900GB/秒の帯域幅を提供する高速 GPU-GPU 通信ルートである「NVLink」相互接続をサポートしており、オーバーヘッドを最小限に抑えるのに役立ちます。ただし、特にユーザーが簡単にカスタマイズできないクラウド マシンの場合、NVLink は常にすぐに利用できるとは限りません。 NVLink がサポートされていない場合、GPU-GPU 通信は PCIe インターコネクトを介して実行されるため、速度が大幅に低下します。 Tesla V100 は、16GB/秒で 16 レーンの PCIe 3.0 相互接続をサポートし、DL アプリケーション向けの標準的な高性能 GPU と一般的に考えられています。

低速の相互接続を介して大量のデータが転送されるのを避けるために、モデル並列処理のユーザーは、スライス間で転送する必要があるアクティベーションの数を最小限に抑えるパーティショニング戦略を選択するか、計算をバランスさせて通信コストを隠すことがよくあります。この目的のために様々なシャーディングアルゴリズムが存在します[14、25、26、37、46、61]。

データ並列処理は、複数のミニバッチのデータを並列に消費する一般的なディープラーニング実行戦略です。データ並列実行技術は、非同期データ並列処理と同期データ並列処理の 2 つのカテゴリに分けられます。

最もよく知られているデータ非同期並列処理技術はパラメータ サーバーです。この技術では、コア マスターがベースライン パラメータのセットを保持し、分散ワーカーがさまざまなミニバッチでトレーニングされたモデルのコピーを保持します。分散ワーカーは定期的にベースライン サーバーに更新を送信し、ベースライン サーバーは分散ワーカーに置換パラメータを送信して、最新の状態に保ちます。ワーカーはベースライン サーバーとのみ通信/同期する必要があるため、ワーカー同士が同期しなくなる可能性があります。非同期技術では、単一の作業者によるトレーニングに比べて精度が低下する、作業者の復帰時間の違いにより結果が再現できないなど、多くの課題が生じます。これらの理由から、現代​​の DL トレーニング環境では、非同期手法は段階的に廃止され、代わりに同期手法が採用されるようになっています。

最も一般的な同期データ並列実行技術は、分散データ並列処理 (DDP) です。 DDP はモデルを複製し、そのコピーをさまざまなアクセラレータに配布します。まず、初期の「グローバル ミニバッチ」を受け入れ、それをレプリカ間で均等に分割し、各レプリカのローカル勾配更新を生成します。これらの勾配はレプリカ間で集約され、通常は all-reduce 通信パターンを使用してグローバル更新が生成されます。このグローバル更新は、各レプリカに並列に適用されます。この手法は、元のグローバル ミニバッチを使用した単一 GPU トレーニングと数学的に同等です。この手法では、all-reduce 通信ステップが導入されますが、これらのオーバーヘッドは重複してモデル実行時間内に隠れてしまうことがよくあります。

All Gather および All Reduce 通信パターンは、データ並列処理やより広範囲に分散された DL でよく使用されます。これらのパターンの目的は、異なるプロセッサ上の個別のデータを取得し、それらを集約してプロセッサに配布し、各プロセッサが同じデータのコピーを持つようにすることです。オール トゥギャザー モードでは、各プロセッサがデータを他のすべてのプロセッサに送信するアルゴリズムが使用されます。このアプローチは通常、各プロセッサにグローバルにブロードキャストする必要があるデータのパーティションがある場合に使用されます。通常、帯域幅を集中的に使用するプロセッサごとに通信ステップが必要であり、各プロセッサは他のすべてのプロセッサと通信する必要があります。 All-reduce パターンは All-together の上位レイヤーであり、いくつかの削減関数 (合計、平均など) と組み合わせられます。関数を同期的に実行すると、すべてをまとめて実行してからローカル関数アプリケーションを実行する場合と比べて手順が 1 つ節約されます。例えば、 Horovod [50]は、データ並列勾配集約のための帯域幅最適化削減パターンを実装しており、各プロセッサは完全な収集と削減を完了するために2×(−1)の通信ステップを必要とします。

ハイブリッド並列処理とは、さまざまな並列戦略を組み合わせて全体的なパフォーマンスを向上させる戦略を指します。たとえば、モデルの並列処理の上にデータの並列処理を重ねると、データの並列実行を高速化しながら、複数のデバイス間でメモリのスケーラビリティを実現できます。これらの戦略では、設計においてトレードオフが必要になります。単純なオーバーレイ ハイブリッド並列処理では、モデル並列処理のマルチデバイス要件とデータ並列処理のレプリケーション要件が倍増します。タスクの並列処理をさらに積み重ねると (たとえば、マルチモデル トレーニング)、方程式に別の乗法係数を追加できます。より複雑なハイブリッドでは、図に示すように、モデル並列アーキテクチャの一部のステージにデータ並列処理を適用し、他のステージをシリアルで実行する場合があります。この設計により、新しい「検索空間」が開かれることに注意してください。つまり、データの並列レプリケーションにはどのフェーズを選択すればよいのでしょうか。モデル並列シャーディングの決定は、データ並列パフォーマンスにどのように影響しますか?限られたリソースをさまざまなステージにどのように割り当てるべきか、またデバイスの相互接続とトポロジはパフォーマンスにどのように影響するか?

モデル アーキテクチャのスケールは、大まかに、深さのスケーリングと幅のスケーリングの 2 つのカテゴリに分けられます。ディープ スケーリングは、Transformer のような長いシーケンス チェーン アーキテクチャにとって最も一般的な要件です。幅のスケーリングは通常、非常に幅が広​​く、簡単に並列化できる演算子 (テーブル検索など) に使用されます。

モデルの並列処理などの技術は、大規模な Transformer のトレーニングや一般的なディープ モデル トレーニングに不可欠です。ただし、非常に深いモデルに対して並列実行を有効にするのは難しい場合があります。レイヤーのシーケンスが深い場合、最も自然なシャーディング戦略は、シーケンスをサブシーケンスに分割することです。しかし、このアプローチでは、パフォーマンス上の利点を実際に享受することなく、ユーザーに GPU の追加を強制します。シーケンスをサブシーケンスに分割しても、並列実行の高速化の機会は提供されません。 1 兆パラメータのモデルを考えてみましょう。メモリに収めるには 1024 個の GPU が必要になります。これらの GPU はすべて実行を「有効にする」ためだけに存在し、パフォーマンス上の利点は提供しません。実際、この戦略は、GPU 間の通信コストが原因で、同等のインメモリ トレーニング ジョブよりも遅くなる可能性があります。

複数の GPU にわたるアテンション ブロック内の操作を並列化するなど、幅方向のシャーディング戦略がいくつかあります。ただし、これらのアプローチでは、より多くのカスタマイズが必要になり、通信のオーバーヘッドが増加し、実装にはモデル設計者の多大な労力が必要になります。したがって、ディープ モデル トレーニング用のほとんどのシステムでは、一度に 1 つのアーキテクチャをターゲットにするのではなく、すべてのディープ モデル クラスに最適化できる一般化されたディープ シャーディング戦略を適用することを好みます。

順次依存関係の課題にもかかわらず、ディープシャーディングは多くの機会をもたらすこともできます。パイプライン化やスピルなどの手法は、深さ方向に分割されたモデルにのみ適用できます。

推奨モデルでは、埋め込みテーブルが幅シャーディングの最も一般的な候補となることがよくあります。ほとんどの企業は、特定のエンティティ（Meta、Netflix、TikTok など）からデータを収集してカスタマイズされたエクスペリエンスを作成する、埋め込みベースの e コマース モデルを使用しています。標準的なアプローチは、ユーザー ID をトレーニング可能なベクトルにマッピングするテーブルを作成し、これらのベクトルをその上の他の DNN に供給することです。しかし、Facebook のような数十億人のユーザーを抱えるプラットフォームで作業するには、テーブルを非常に広くする必要があります。単精度 (32 ビット) 浮動小数点数で満たされたサイズ 1024 のトレーニング可能なベクトルの 30 億のインデックス テーブルには、12 TB のメモリが必要です。実際の推奨モジュールには、参照用の複数のテーブル (ユーザー テーブル、ビジネス テーブル、ビデオ カタログ テーブルなど) が含まれる場合があり、これによりメモリ コストがさらに増加し​​ます。

埋め込みテーブルのパーティション分割は、テーブル検索が並列化されているため、簡単な作業です。つまり、1 つのインデックスの検索は他のインデックスに依存しません。したがって、テーブルをサブテーブルとして異なる GPU に分散することは、メモリ コストを分散するための一般的な戦略です。シャード間の並列実行では、ミニバッチ内のインデックス検索要求が適切な GPU にルーティングされるだけです。ただし、並列テーブル検索後にミニバッチを再集約して最上位の DNN に供給するには、潜在的にコストのかかる一括通信ステップが必要になります。

幅スライスを他の演算子 (行列乗算など) に適用することはあまり一般的ではありませんが、まったくないわけではありません。しかし、一般的に、埋め込みテーブルは最もメモリを消費する単一操作です[9]。幅シャーディングの主な使用例は埋め込みテーブルであるため、このケースを最適化することは過度に具体的であるように思われるかもしれません。しかし、埋め込みテーブルと推奨モデルはDLワークロードの大部分を占めており、MetaはDLトレーニングサイクルの50%がテーブルベースの推奨モデルの埋め込みに費やされていると報告しています[9]。したがって、適用範囲がシーケンシャルディープモデルのスケーラビリティを最適化するよりも制限されている場合でも、非常に幅広いモデルケースを最適化することは非常に価値があります。

次の図は、さまざまなトレーニング システムとテクニックを比較したものです。

再具体化などのいくつかの基本的な手法は、より高度な大規模モデルトレーニング システムの共通の構成要素としてよく使用されます。一般に、これらの手法は組織や構造に与える影響が少なく、他の方法と統合できます。

再マテリアライゼーションは勾配チェックポイントとも呼ばれ、バックプロパゲーションのメモリ要件を最小限に抑えることを試みる[15, 19]。バックプロパゲーションでは、勾配計算にチェーンルールを正しく適用するために、中間オペレータ出力を保存する必要があります。ただし、中間出力テンソルには大量のメモリが必要になる場合があります。ある分析[54]によれば、アクティベーションはResNet[22]のメモリ消費量の95%、Transformerのメモリ使用量の80%を占めていることが示されています。最初は、いくつかのチェックポイントを除くほとんどのアクティベーションが破棄され、チェックポイントはバックプロパゲーション中に破棄されたアクティベーションを再計算するために使用され、その後、計算とメモリを交換するために具体化されます。この方法では、任意の時点で、チェックポイント間の中間ポイントのみをメモリに保存する必要があります。このアプローチでは計算オーバーヘッドが発生します。つまり、フォワード パスは実質的に 2 回実行されます。ただし、フォワード パスの演算子は、バックプロパゲーションで使用される自動微分手順よりも高速であることが多いため、オーバーヘッドは見た目よりも小さくなります。いくつかの勾配チェックポイントシステムは、オーバーヘッドが30%しかなく、メモリを6～7倍節約できると主張しています[15]。

蓄積とは、バックプロパゲーション中にバッチ処理された勾配に必要なメモリのことを指す[25]。確率的勾配降下法では、サンプルをミニバッチにまとめてモデルに送り、パラメータ更新によって生成された勾配を各サンプルの更新の集約として表示できます。累積は、これらの集約された勾配の適用を遅らせ、代わりに新しいミニバッチ勾配更新を計算し、それらを集約勾配ベクトルに累積します。新しい勾配は、1 回ではなく 2 回のミニバッチ更新の合計になります。このようにして、実際に大きなバッチでトレーニングしなくても、有効なミニバッチ サイズと勾配の影響を拡大できます。より小さな個々のバッチはマイクロバッチと呼ばれ、有効な集約バッチはミニバッチと呼ばれます。累積はパイプラインの並列処理にとって非常に重要であり、他の手法と組み合わせて使用​​されることがよくあります。

ほとんどのトレーニングフレームワーク（TensorFlow、PyTorchなど）[8、42]は、勾配とパラメータの単精度浮動小数点（32ビット）表現を使用します。倍精度表現 (64 ビット) は比較的一般的ではありません。モデルのトレーニングに必要なメモリを削減する 1 つの方法は、データの半精度 (16 ビット) 表現、つまり低精度表現を使用することです。当然、値が近似されると精度の低下につながります[38]。ただし、このアプローチにより、速度が向上し、メモリを節約できます。これをバランスさせるために、自動混合精度（AMP）[3]は、精度を損なうことなくデータを16ビットに圧縮することが安全であるかどうかを自動的に判断します。 AMPは、精度をほとんど損なうことなく、大規模モデルをトレーニングする際に最大5.5倍の高速化を実現します[3]。 AMP は非常に低いレベルで数値を直接変更するため、この手法は大規模なモデルをトレーニングするための実際の体系的なアプローチとは直交することがよくあります。

場合によっては、DL トレーニングで使用されるベクトルが非常にスパースになります。たとえば、埋め込みテーブル検索では通常、テーブルへのインデックスがいくつかだけ使用されます。テーブルに適用される勾配ベクトルは、使用されているインデックスでのみゼロ以外の値を持ち、残りはゼロになります。実際、メモリ内にすべてのゼロを保持することは不要であり、メモリを無駄にします。スパース表現は、情報の損失を避けながら、これらのベクトルをゼロ以外の値になるまで圧縮しようとします。デフォルトでは、埋め込みテーブルに通常使用される最も単純なアプローチは、勾配を、インデックスを勾配値にマッピングする KV ペアとして表すことです。スパース表現を、全削減通信パターンなどの標準ベクトル表現を前提とする操作と組み合わせると、いくつかの複雑な問題が発生します。いくつかの研究[35]では、代替の通信モードを使用するか、データを標準の表現に戻すことでこの問題に対処する方法を示しました。スパースベクトル表現は非常に特殊な問題を解決しますが、幅広い埋め込みテーブルなどの一部の演算子の効率的なトレーニングには不可欠です。

パイプライン並列処理は「シーケンシャルディープモデル」設定を対象としています[25]。これは、モデル並列トレーニング パラダイムの直接的な拡張です。モデルの並列処理により、段階的なスライスのシーケンスが作成され、自然な「パイプライン」構造が作成されます。パイプライン処理は、ステージを実行操作で埋めようとすることでこのパイプライン構造を単純に利用し、純粋なシーケンシャル モデルの並列処理に存在するアイドル状態を削減します。各スライスはパイプラインのステージとして見ることができるため、3 つの GPU にまたがって 3 回分割されたモデルは 3 ステージのパイプラインになります。

CPUパイプラインでは、パイプラインはCPUに送られる様々な命令で満たされます[52]。 DLパイプラインの場合、パイプラインは勾配累積法[25, 27]と同様にミニバッチで満たされます。本質的に、パイプライン並列処理は、勾配累積とモデル並列処理の組み合わせです。独立したマイクロバッチはシャードされたパイプラインを介してシャトルされ、各マイクロバッチの勾配はパイプラインの各ステージに蓄積されます。ミニバッチ全体（すべてのマイクロバッチの組み合わせ）の勾配が集約されると、それをモデルに適用できます。この設計は、モデル並列とデータ並列のハイブリッドに似ており、データ スライスは異なるモデル並列スライス上で並列に処理されます。これは図に示されています。入力ミニバッチはマイクロバッチに分割され、パイプライン ステージを介して送信されます。はミニバッチによるスライス前段階を指し、 はミニバッチによるスライス後段階を指します。このようにして、「パイプライン化された」データ並列性が実現されます。つまり、異なるモデル並列性レベル間でデータが並列処理されます。バックプロパゲーションの前に、フォワードパイプラインをクリアする必要があることに注意してください。

バックプロパゲーションは、パイプライン化された並列トレーニングに課題をもたらします。バックプロパゲーションには中間出力が利用可能である必要があります。ただし、蓄積と組み合わせると、マイクロバッチごとに異なる中間出力のセットを保存する必要があり、蓄積によって得られるスケーラビリティの利点が失われます。 GPipe[25]は最も初期のパイプライン並列トレーニングシステムの1つであり、累積とチェックポイントを組み合わせることでこの問題の解決策を提案しています。アクティベーションはスライス/パイプライン ステージのバインディングにのみ保存され、勾配がパイプライン内で後方に移動するにつれてバックプロパゲーション中に再計算されます。チェックポイントは現在、パイプライン化された並列トレーニングシステムのほとんど、あるいはすべてにおいて標準的なアプローチとなっている[21]。もう一つの課題はパイプラインの構造です。スライス パイプラインは双方向である必要があります。予測中は入力とアクティベーションが前方に流れ、バックプロパゲーション中は勾配が後方に流れます。これにより問題が発生します。パイプライン内のデータは両方向に流れるため、ステージ間で「衝突」する可能性があります。したがって、予測とバックプロパゲーションの間にパイプラインフラッシュが発生します。適切に管理しないと、フラッシュによってパフォーマンスに重大な影響が生じる可能性があります。上の図はパイプライン並列化モデルを示しています。この時間の大部分は、パイプラインを完全にフラッシュする必要がある「バブル」期間に費やされることに注意してください。

主なパイプライン並列技術は次のとおりです。

GPipe[25]は、パイプラインがより長く満杯の状態を保つことができるように、アクセラレータ数を一定に保ちながらマイクロバッチの数を増やすことを提案しています。これによってフラッシングがなくなるわけではありませんが、全体的な効率は向上します。ただし、このアプローチでは、チェックポイント付きのアクティベーションのミニバッチを多数保存するために、より多くのメモリが必要になります。 DAP-PLE[17]は、GPipeの収束動作を維持しながらアイドル時間を短縮する代替パイプラインスケジュールを提案した。残念ながら、同時により多くのマイクロバッチを「アクティブ」に保つことでメモリ コストが大幅に増加し、すでにメモリの限界を超えているアプリケーションではスケジューリングが実行不可能になります。

非同期パイプライン並列処理という形で別のソリューションもあります。これは、厳密な収束動作を維持することを犠牲にして、パイプライン ステージとバックプロパゲーションを再配置してフラッシュを排除します。このシーケンスの「分離」により、問題はより効率的なものに緩和されますが、データの消費と消費順序に影響を与えるという犠牲を払います[21、32、39、59]。例えば、PipeDream[21]が提案した1F1Bモデルは、後続の各ステージ（異なるミニバッチ）に対して1つの前のステージを実行し、完全な比率と利用率を維持します。しかし、その設計ではより慎重な分割とパッキングが必要であり、古い重みの更新によって引き起こされる精度の低下を軽減するには重みの複数のコピーを保存する必要があり[21]、メモリコストが増加します。 1F1B のような非同期パイプラインはパフォーマンスは良好ですが、一般的な解決策ではありません。精度の損失はケース固有であり、非常に大きくなることがよくあります。精度が重要であり、収束動作を再現する必要があるアプリケーション (モデル選択など) は、非同期パイプライン並列処理には適していません。

モデルの並列処理は、複数の GPU にわたって実行するためのメモリ要件を分散することに重点を置いていますが、一部のシステムでは、より多くの GPU にスケールアウトするのではなく、メイン システム メモリ (DRAM) を活用しようとします。このアプローチの主な動機は、GPU メモリは限られていて高価である一方、DRAM は実際には安価で入手しやすいということです。

初期の研究[23、30、34、49、56]では、オフロードを「スワッピング」問題、つまりテンソルをGPUメモリからDRAMにいつスワップするかを決定する問題と見なしていました。ほとんどの場合、グラフ分析アルゴリズムを使用して、アクティベーション、勾配、またはパラメータが実行グラフで次にいつ使用される可能性があるかに応じて、スワップ操作を「挿入」する場所を決定します。 SwapAdvisor はこれらのスワッピング システムの中で最も先進的なシステムであり、並列遺伝的検索アルゴリズムを使用して、最適なパフォーマンスを得るためにスワップ演算子を配置する場所を分析します。また、数十億のパラメータを持つモデル アーキテクチャのトレーニングに不可欠な、パラメータとアクティベーションのオフロードをサポートする最初のシステムの 1 つでもあります。

こうした複雑なスワップの設定は難しい場合があります。SwapAdvisor の検索アルゴリズムは完了するまでに約 1 時間かかります。さらに、インジェクション グラフを交換する手法を拡張してマルチ GPU 並列処理をカバーする明確な方法がないため、マルチ GPU トレーニングに拡張することは困難です。

ZeRO-R [46]は、アクティベーションとパラメータをDRAMに動的に送信するオフロードシステムである別のアプローチを提案している。このアプローチでは、事前に荷降ろしを計画するのではなく、「必要なときに荷降ろしする」ことになります。設計の不規則性により、メモリの断片化などの問題が発生する可能性がありますが、グラフベースの設計と比較すると柔軟性が大幅に向上します。その後のバージョンでは、ZeRO Infinity[47]はこれを拡張して不揮発性メモリエクスプレス（NVMe）/ディスクストレージにオフロードし、さらなるスケーラビリティを実現しました。

Hydra[37]は「独立ブロック」戦略を選択し、モデルアーキテクチャをサブモデル（つまりモデル並列性）に分割し、DRAMとGPUメモリ間で自由に分散できるようにしました。これは、独立したデータ チャンクを下位レベルのメモリに送信できる RDBMS のオーバーフローに似ています。他のスピルオーバー システムとは異なり、Hydra の実行モデルはモデル並列処理と同一であり、各モデル スライスの実行を完全に分離します。通信と計算を重複させようとしますが、他の CPU オフロード技術によって検討されるきめ細かいテンソル オフロードの複雑さは無視されます。この一般化により、単一 GPU 実行には適さなくなりますが、マルチ GPU 並列化技術と組み合わせる場合には適しくなります。

図に示すように、Hydra のオーバーフロー戦略は、モデルの並列シャードを GPU メモリ内外に単純に昇格および降格するだけです。 ZeRO Offload で使用されるような他のオーバーフロー設計も同様ですが、構造上はそれほど堅牢ではありません。

L2L[45]はHydraに似た設計を採用していますが、シャーディングのアプローチにはより制限があります。これは特に Transformer アーキテクチャを対象としており、自己注意ブロック (標準の Transformer 演算子) を、ターゲット モデル クラス用に特別に選択されたヒューリスティックと交換します。これにより、Transformer アーキテクチャで優れたパフォーマンスを発揮できますが、Hydra の柔軟性や ZeRO-R の動的な汎用性は実現されません。

これらの手法はいずれも実行時に何らかの順序付けを利用するため、深くて大規模なモデルのメモリ要件を分散するためによく使用されることに注意してください。非常に幅の広い演算子 (埋め込みテーブルなど) は、パフォーマンスが大幅に低下することなくシリアル化することはできず、DRAM と GPU メモリの両方がオーバーフローする可能性はありません。ハイブリッド デバイスでワイド演算子を実行するための唯一のオプションは、並列演算子 (テーブルの場合はインデックス検索) をシリアル化し、操作のシーケンスをワイド モデルではなく 1 ディープとして書き換えるか、ワイド演算子を実際に CPU で実行することです。

一部のシステムではさらに進んで、実際に CPU 上で操作を実行します。ほとんどの DL 演算子は高度な並列処理をサポートするアクセラレータでより高速に実行されるため、通常は GPU または TPU コンピューティングを使用してモデル全体を実行する方が適切です。ただし、オフロードでは、データはいずれにしても CPU 上に存在するため、CPU 操作と並行して GPU 操作を実行することでオーバーヘッドが追加されることはありません。

ZeRO[48]は、特に人気のあるAdamオプティマイザ[28]向けに、GPU実行中にCPU上でパラメータ更新を実行することを提案した。 Adam オプティマイザーはいくつかの状態パラメータ (通常は 32 ビット) を保存し、精度の低下を避けるために 32 ビット パラメータで実行する必要があります。残念ながら、これにより、ユーザーはメモリ要件を削減するために 16 ビット表現を展開できなくなります。 Adam オプティマイザーの ZeRO バージョンは、パラメータの 32 ビット バージョンを DRAM 上に保持し、低精度の 16 ビット バージョンを GPU 上に保持することで、メモリの消費量を抑えます。実行中、システムは勾配とオプティマイザーの状態を DRAM に書き出し、CPU 処理を使用して 32 ビット パラメーターのパラメーター更新を実行します。 CPU-GPU 通信と GPU 計算が重複する 2 番目のステップでは、更新が 16 ビット パラメーターに伝播されます。

ハイブリッド CPU-GPU 計算は、非常に大規模な推奨モデルでも一般的です。埋め込みテーブルは、非常に大規模なメモリ集約型の演算子であり、通常は、さらなる処理のために多数の小さな DNN に送られます。最適化を行わないと、埋め込みテーブルのサイズが巨大になるため、CPUのみでの実行を強いられることになる[9]。あるいは、DNN を GPU メモリに常駐させながら、埋め込みテーブルを CPU に配置して、GPU アクセラレーションのメリットを享受することもできます。 Hotline [10]などのいくつかの作品は、CPUベースの埋め込みテーブルからGPUアクセラレーションDNNSまで、モデルを介したパイプラインデータを試みます。彼らは、このハイブリッド計算アプローチは、すべての通信ステップの必要性を排除するため、幅ごとのマルチGPUモデルの並列処理よりも高速であることを実証しました。

並列化手法は、さまざまな方法で組み合わせることができます。さまざまなシステムは、さまざまな「基本的な」並列メソッド（データの並列性やモデルの並列性など）の利点を組み合わせて、ユーザーにパフォーマンスとスケーラビリティを高めることを試みます。ハイブリッド並列性技術は、「真の」ハイブリッドの2つのカテゴリに分類できます。これは、ボトムアップから並列性テクニックを統合し、異なる実行段階で異なる戦略を選択するトップダウンハイブリッドです。

接地ミックス

従来、モデルの並列性と他の手法を組み合わせることは、最初から挑戦的な作業です。モデルの並列症は、標準実行のためのGPUの要件を増加させます。これにより、複製またはマルチインスタンスベースの並列性技術（例：データ並列性、タスク並列性など）との組み合わせが、モデル並列性のデバイス要件をさらに拡大するため、非実用的になります。

この問題に対処するために、Hydra [37]はオーバーフロー技術を使用してスケーラブルモデルの並列トレーニングに必要なGPUの数を減らすことを提案し、その後、効率的なマルチモデルトレーニングをサポートするためにタスク並列式の層を適用しました。 Hydraシステムは、モデル並列性のセグメント化された性質を活用して、標準のタスクの並列性とモデル並列性を上回ることができるハイブリッドの「微粒並列」スケジュールを実装します。これは図に示されています。現在、Hydraは、大規模なモデルのマルチモデルセットアップを明示的にターゲットにする唯一のシステムですが、この領域は、マルチユーザークラスターのモデル選択と管理のコストに取り組んでいるため、この領域が重要になる可能性があります。

もともとゼロ[46]によって導入された完全なシャードデータ並列処理（FSDP）は、モデルの並列性とデータの並列性のハイブリッドを提供します。モデル並列シャーディングの方法でまだ実行されているHydraとは異なり、FSDPはモデル並列性のみを使用してデータ並列インスタンス全体にモデルを分布させ、各データ並列クローンはレイヤーグループの部分パラメーターセットを保持します。レイヤーグループを実行すると、FSDPはすべてのステップを実行して、各データパラレルインスタンスで完全で非シャルドレイヤーグループを生成します。レイヤーグループは、純粋にデータ並列の方法で実行されます。レイヤーを実行した直後に、メモリフットプリントを再配置して再発見できます。同様のアプローチがバックプロパゲーションに使用されます。

FSDPでは、各アクセラレータのメモリ要件は、単一層の最小フットプリントに加えて、残りの分割メモリ要件に縮小されます。単一層の要件は一定の要因に因数分解されます。一定の要因は（ /）削減として表現できます。ここで、元のモデルメモリフットプリントであり、データ並列インスタンスの数です。これにより、ユーザーはデータ並列性のパフォーマンスとモデル並列性のスケーラビリティの両方から利益を得ることができます。これにより、大量の通信オーバーヘッドが追加されます - 各レイヤーの全採掘を実行します - そして、オーバーフローベースの手法とは異なり、これはスケーラビリティを実現するために拡大する必要があります。

Zero Offload [48]は、FSDPとアクセラレーターごとのオーバーフローを組み合わせて、近い将来使用されないスライスレベルのパラメーターをオフロードすることを提案しています。これにより、スケーラビリティが向上しますが、CPU-GPU通信を通じてより多くの通信オーバーヘッドを導入します。ゼロは、通信を計算と重複することで機能しますが、一般的にいくつかの減速は避けられません。分析によると、FSDPは標準データの並列性よりも遅いことが示されています（ただし、よりスケーラブルで、より大きなモデルを実行できます）。 FSDPの支持者は、ユーザーがバッチサイズを増やすことでより高いスケーラビリティを利用できると主張しています（したがって、分散データの並列DDPパフォーマンスに沿って実行時間をもたらす）が、バッチサイズは精度の収束動作に影響します。バッチサイズをスケーリングしてFSDPパフォーマンスを向上させると、非同期パイプラインと同じ問題が発生する可能性があります（極端ではありませんが）。 3D並列性により、FSDPとパイプラインの並列性とテンソルの並列性が組み合わされ、スケーラブルなデータの並列性を活用し、並列深さと幅のスライスで操作を実行します。これは通常、モデルの一部にFSDPを適用し、別の部分でのパイプライン、および幅スライシングにより適した別のセグメントでのテンソル並列性の形をとります。 3D並列処理には、通常、モデルアーキテクチャに基づいて多くのカスタマイズが必要です。HydraやFSDPなどの箱から出してはなりません。つまり、Megatron [53]などのシステムを使用して、Megatron-LM [5]やBloom [12]などの多くの非常に大規模なモデルのトレーニングに成功裏に適用されています。将来的には、3D並列ハイブリッドとHydraのシャードタスクの並列性を組み合わせることにより、新しい「4D並列」が可能になります。

戦略の発見

ポリシーディスカバリーシステムは、モデル内の並列化手法を組み合わせるプロセスを自動化しようとします。最近のいくつかの例は、FlexFlow [26]およびALPA [60]です。

フレックスフローは、パイプライン並列性、FSDP、シャードタスクの並列性などの高度なDL並列技術の開発前に構築され、主に畳み込みニューラルネットワークを標的とするデータ、テンソル、モデルの並列性のみを調査しました。 FlexFlowは、デバイストポロジグラフを構築し、アクセラレータをノードと相互接続（例：NVLINK、PCIE、Infiniband Networks）としてエッジとしてモデリングします。これにより、特定のデバイス構成内のエッジ間のデータの動きのコストを考慮したハイブリッド並列実行戦略を作成できます。シミュレーターを使用して、さまざまなパーティション戦略を評価し、パイロットパスにパスをモデルオペレーターのランタイム、およびエッジ帯域幅に基づいて通信オーバーヘッドをモデル化する理論計算を評価します。シミュレーターをOracleとして使用すると、オペレーターを分割するさまざまな方法を評価します。この「セグメンテーション」ベースの並列表現は、FSDPをサポートする可能性がありますが、異なるタスクで独立した実行（タスク並列性、パイプライン並列性など）を利用する並列化手法をサポートできないことに注意してください。さらに、特定の構成におけるメモリのスケーラビリティや、デバイスメモリの疲労の可能性を明示的に述べていません[11]。

ALPAは、メモリのスケーラビリティをより明確に考慮し、flexflowのようなオペレーター内セグメンテーションではなく、演算子間の並列性（例：モデル並列性、パイプライン並列性）を考慮します。命令レベルの並列処理（ILP）式を使用して、並列化ポリシーを設定する方法を決定します。これにより、デバイスのメモリ制限を超えると実行計画が変更されます[60]。ポリシー検索のためのより広いスペースを占めるこのアプローチは、FlexFlowよりも優れたパフォーマンスを実現できます。

これらのハイブリッド並列化戦略は、静的な非DATA依存性実行タスク（非再帰的なニューラルネットワークなど）に最適です。ただし、マルチモデルトレーニングなど、よりダイナミックなタスクに適していません。スケジューラではなく、トレーニング用のコンパイラです。将来の作業では、このギャップを埋め、動的なハイブリッド平行アクチュエータを構築することを検討できます。

推奨されるモデルデータの並列性

DLRMは、2つの異なるスケーリングの課題を組み合わせるため、開業医にユニークな課題を提示します。テーブルの埋め込みは非常に賢明であり、モデルの並列実行のために幅の分割を保証します。トップDNNは計算集中的ですが、規模は小さく、データの並列性から最も利益を得ます。したがって、モデルの表にテンソル並列性を適用し、DNNにデータの並列性を適用すると、このハイブリッド戦略は推奨モデルでうまく機能します。このアプローチは、完全にGPUに加盟したDLRMトレーニングの標準となっています[41]が、異種のCPU-GPU実行は、GPUリソ​​ースが少ないユーザーにも適しています。

ハイブリッドパラレルDLRMトレーニングは、埋め込みテーブルを複数のGPUに分割し、各GPUに上部DNNのローカルコピーを配置します。シェードテーブルは、サンプルディメンションにシャードされた入力を処理し、パーティションを実行して、テーブルの出力を再集計し、バッチディメンションのデータの各並列コピーをパーティション化します。これは、図に示されているように説明されています。

このアプローチにより、実践者はデータから利益を得て、神経アーキテクチャのモデルの並列性をモデル化できます。コミュニケーションの手順は集中的であり、多くの場合、頭上を重くします[35]が、並列実行の利点は通常これを上回ります。

一般に、さまざまな並列化戦略の利点と相まって、ハイブリッド並列処理は、必要に応じてモデルを効率的にトレーニングする機能をユーザーに提供します。シャードされたタスクの並列性やFSDPなどのハイブリッド並列技術は、スケーラビリティと効率を最初から組み合わせていますが、戦略の発見とDLRMとのハイブリッド並列性は、このグラフの異なる段階でハイブリッド並列化要件を持つモデルアーキテクチャを訓練するのに役立ちます。

元のリンク：https：//mp.weixin.qq.com/s/vmg0vh4vb_8pmucgewz8_w