大規模モデル: 大規模モデルの難しさは何ですか?

みなさんこんにちは。私の名前はティムです。

GPT モデルの誕生以来、そのパラメータスケールは継続的に拡大しています。ただし、モデルを直接的に大きくすることはできません。データ、スケジューリング、並列コンピューティング、アルゴリズム、マシンリソースに対応する変更を加える必要があります。

今日は、ビッグモデルとは何か、モデルを大きくすることがなぜ難しいのか、CV/NLPや検索プロモーションのシナリオにはどのような戦略があるのかをまとめてみましょう。

大型モデルとは何ですか？

ビッグモデルは、その名の通り「大きい」ことに重点を置いています。主にいくつかの側面が含まれます:

データ規模が大きく、大量のデータを使用することで、モデルの一般化能力とパフォーマンスが向上します。
大規模並列コンピューティング機能。GPU や TPU の普及など、コンピューティングハードウェアの継続的な進歩により、大規模並列コンピューティング機能が向上し、大規模なモデルのトレーニングと推論が可能になりました。
モデルの複雑さの増大: 大規模なモデルではネットワーク構造がより深く複雑になり、より豊富な機能と関係を捉えることができるため、モデルの表現力が向上します。

大規模モデルは、主にスパース大規模モデルと密な大規模モデルの 2 つのカテゴリに分けられます。

スパース大規模モデル: スパース大規模モデルとは、一般的に検索、推奨、広告のタスクにおいて、モデル内に多数のスパースパラメーターが存在する状況を指します。膨大なサンプルと大規模なスパース埋め込みを特徴とし、CPU/GPU パラメータサーバーモード (PS) を使用したトレーニングに適しています。
高密度大規模モデル: 高密度大規模モデルとは、モデル内のほとんどのパラメータがゼロ以外の値であり、明らかなスパース性特徴がないことを意味します。これは通常、CV および NLP タスクで使用されます。定期的なサンプルデータと大規模で密なパラメータが特徴で、純粋な GPU 集団通信モードでのトレーニングに適しています。

検索やプロモーションなどの大規模なスパースモデルの場合、通常、スパース機能の埋め込みと密なモデルの 2 つの部分が含まれます。

このうち、スパース特徴の埋め込み計算は大規模なスパースモデルの鍵となる一方、密なモデル部分は一般的に小さく、GPU に配置できるため、データの並列処理や全削減通信を実行できます。

トレーニング中は、特徴埋め込みテーブルに対して検索や順列化などの複雑な操作が必要となり、その後、高密度モデル計算用のテンソルが生成されます。

特徴埋め込みテーブルは多くの場合、多くのストレージスペースを占有し、それを完全に保存するには多数の GPU サーバーが必要になります。これが典型的なテンソル並列処理です。

このようなシナリオでは、典型的な全対全通信モードが発生し、全対全通信によって深刻なインキャスト通信 (多対 1) が発生し、ネットワークの輻輳につながり、ネットワークアーキテクチャ、輻輳制御プロトコル、負荷分散アルゴリズムなどに高い要求が課せられます。

CV および NLP タスクの場合、モデルパラメーターが非常に大きいため、単一の GPU メモリで収容できるスペースをはるかに超えてしまいます (NVIDIA の最新の A100 には 80 GB のメモリがあります)。

したがって、大規模なモデル全体に対応するには、モデルの特定のレイヤーのテンソルと、異なるレイヤー間のパイプラインを並列化する必要があることがよくあります。

計算プロセス中には、単一のマシン内での通信と異なるマシン間の通信の両方が行われます。具体的な通信モードは、モデルの分割と配置方法によって異なります。

トレーニングプロセスを高速化するために、完全な大規模モデル間でデータ並列処理がよく使用されます。完全な大規模モデルごとに異なるトレーニングデータが提供され、おなじみの all-reduce 通信モードが実現されます。

要約すると、高密度の大規模モデルと疎な大規模モデルではモデル特性に明らかな違いがあり、コンピューティング/ストレージ/通信リソースに対する要件も大きく異なります。

GPU コンピューティングリソースの利用率を最大化し、最高の加速効果を実現するには、モデルの特性と実装方法と組み合わせて、GPU サーバーアーキテクチャ、ネットワークアーキテクチャ、トレーニングデータの保存と取得、分散トレーニングフレームワークを総合的に検討して設計する必要があります。

大型モデルの難しさは何ですか?

大規模モデルには、膨大なサンプル、パラメーター（数兆レベル）、長い収束時間という 2 つの主な課題があります。

これら 2 つの点を過小評価しないでください。過小評価すると、解決が必要な多くの問題が発生します。

1. 大規模モデルのトレーニングには、より大きな計算能力が必要です。

大規模モデルのトレーニングに必要な合計計算能力は、実は非常にシンプルです。つまり、6 * モデルパラメータの数 * トレーニングデータ内のトークンの数が、すべてのトレーニングデータを処理するために必要な計算能力です。ここでの 6 は、モデルの順方向および逆方向の伝播中に各トークンに必要な乗算と加算の計算回数です。

簡単に言えば、一連の行列乗算は、左側のニューロンの数と右側のニューロンの数によって完全な二部グラフが形成されることを意味します。左ニューロン L と右ニューロン R のいずれかを選択します。

順方向伝播中: L は出力に L と R 間の重み w を掛け、それを R に送信します。R は 1 つのニューロンにのみ接続することはできないため、複数の L を加算する必要があります。これは、加算を必要とする削減です。
R は、受信した勾配を L と R 間の重み w で乗算し、それを L に送信します。L は 1 つの R にのみ接続することはできないため、勾配を減らして追加する必要があります。重み w を更新する必要があることを忘れないでください。そのため、w の勾配を計算する必要があり、R が受信した勾配は L の順方向伝播の出力 (アクティベーション) で乗算されます。バッチには通常、複数のサンプルがあり、重み w を更新するには、これらのサンプルの勾配を合計する必要があります。
合計で 3 回の乗算と 3 回の加算があります。Transformer がどれだけ複雑であっても、行列計算はそれほど単純です。その他のベクトル計算、ソフトマックスなどは、計算能力を考慮する主な要素ではないため、見積もり時に無視できます。

モデルのトレーニングに必要な合計計算能力を各 GPU の理論上の計算能力で割り、さらに GPU の実効計算能力利用率で割ると、必要な GPU 時間が得られます。

一般的な大規模言語モデルの基盤をトレーニングするのに半年から数か月かかり、また多くのマシンリソースも消費する場合、大規模モデルのトレーニングは非常に「高価」になり、大規模モデルのトレーニングは個々の大企業に限定されます。

たとえば、試したい実験が 100 個あり、モデルのトレーニングに半年かかる場合は、優先度の高い実験のみを選択できます。

これが、現在、すべての大規模な言語モデルベースが最新のオープンソースモデルを追跡している理由です。なぜなら、汎用性の高い大型モデルベースを自分で作ると、コストがかからず、時間もかかる上、かと言って効果もあまりない可能性があるからです。

2. 大規模モデルのトレーニングには、より多くのビデオメモリリソースが必要です。

ディープラーニングのトレーニングに必要なメモリには、モデルパラメータ、バックプロパゲーション勾配、オプティマイザが使用するメモリ、フォワードプロパゲーションの中間状態 (アクティベーション) が含まれます。ビデオメモリ使用量 = モデルパラメータサイズ + バッチサイズ * オプティマイザパラメータと中間変数のサイズ。

オプティマイザが使用するメモリの計算は、実は非常に簡単です。最も古典的な Adam オプティマイザを使用する場合、計算には 32 ビット浮動小数点を使用する必要があります。計算に混合精度を使用する場合でも、各パラメータには 4 バイトの 32 ビットバージョン (順方向伝播用に 16 ビットバージョン、最適化用に 32 ビットバージョン) と 4 バイトの運動量、および 4 バイトの分散 (合計 12 バイト) を格納する必要があります。 SGD のようなオプティマイザーを使用する場合は、分散を保存する必要がなく、8 バイトしか必要ありません。
順方向伝播の中間状態 (アクティベーション) は、逆方向伝播中の勾配を計算するために必要であり、バッチサイズに比例します。バッチサイズが大きいほど、モデルパラメーターメモリが読み取られるたびに実行できる計算が多くなり、GPU メモリ帯域幅への負荷が軽減されます。重要なポイント: 順方向伝播における中間状態の数はバッチサイズに比例します。

もちろん、計算能力をメモリと交換したり、時間をメモリと交換したりするなど、メモリリソースを節約する方法もあります。

計算能力をメモリと交換する秘訣は、各層の順方向伝播の勾配と中間状態を大量に保存するのではなく、特定の層を計算するときに、順方向伝播の中間状態を一時的に最初から再計算することです。

これを各レイヤーに対して実行すると、このレイヤーの勾配を格納するために必要なのは 2 バイトだけですが、中間状態を計算するための計算能力のオーバーヘッドは非常に高くなります。

そのため、実際には、Transformer 全体は通常、いくつかのグループに分割され、各グループにはいくつかのレイヤーがあり、各グループの最初のレイヤーの中間状態のみが保存されます。後続のレイヤーは、グループの最初のレイヤーから再計算され、計算能力とメモリのオーバーヘッドのバランスが取られます。

時間を節約してメモリを増やすコツは、ミニバッチデータの順方向計算勾配を順番に実行し、同時に勾配を蓄積することです。蓄積された結果は、最後のミニバッチ計算の後に平均化され、モデル変数が更新されます。

さらに、マルチレベルキャッシュが可能で、GPU メモリが収まらない場合は CPU メモリにスワップアウトできます。

たとえば、LLaMA-2 70B モデルの場合、モデルパラメータには 140 GB、バックプロパゲーションされた勾配には 140 GB、オプティマイザー状態 (Adam を使用している場合) には 840 GB が必要です。

3. データ量とデータ品質に対する要求は非常に高い

膨大なデータサンプルの場合、すべてを入力することは必ずしも効果的ではありません。どのデータが価値があり、どのデータが価値がないかを把握することが重要です。データの量が増えるにつれて、データの価値を見極めることがますます難しくなります。

また、大量のデータはどこに保存するのでしょうか？一般的には、HDFS または S3 に保存できます。しかし、ストレージとアクセスによってマシンがいっぱいにならず、すぐに取得できるようにするにはどうすればよいでしょうか? 同じデータを使用してモデルを複数回トレーニングする場合、キャッシュを使用してモデルのトレーニング時間を短縮できますか?

4. トランスフォーマーの「不可能三角形」の特徴

写真

Transformer のトレーニングの並列性、推論の効率、競争力のあるパフォーマンスのバランスをとることの難しさは、「不可能三角形」として知られています。

トランスフォーマーは、ステップごとに O(N) の複雑さとメモリにバインドされたキー値キャッシュのため、推論中に最適な効率を示しません。この非効率性により、特に長いシーケンスの場合、実際の展開が複雑になります。

5. ディープラーニングフレームワークにはあまり適していない

この分野は近年になって普及し始めたばかりであり、pytorch や tensorflow などの以前のフレームワークは長い間存在していたため、当時は大規模モデルの分散トレーニングの需要シナリオに対する詳細な抽象設計と最適化はありませんでした。

したがって、この分野は、ビッグデータフレームワークをディープラーニングフレームワークにエンドツーエンドで接続し、新しいプログラミングパラダイムと対応するコンピューティングフレームワークを形成することによって解決する必要があります。

以下では、CV、NLP、検索プロモーションのシナリオをそれぞれ詳しく説明します。

CV と NLP のシナリオ:

CV および NLP シナリオの場合の主な機能は次のとおりです。

モデルは一般的に複雑であり、単一のマシンから高いパフォーマンスを必要とします。業界では、主に高性能 GPU をコンピューティングに使用し、同期パラメータ更新に All-reduce 通信トポロジを採用しています。
モデルが大きい（DenseNet 部分）。例えば、NLP 分野では、GPT-3 のようなモデルは最大 1750 億のパラメータを持ち、最大 2.8 TB のビデオメモリを占有するため、単一のマシンメモリでは収容できません。

GPT-3 のような高密度部分が大きいモデルの場合、単一の Allreduce カードのメモリでは対応できません。分散トレーニング用の有向非巡回グラフ (DAG) を構築するには、モデル並列処理を使用して計算グラフをさまざまなデバイスに分割する必要があります。Gpipe、Megatron、Oneflow、Whale はすべて、モデル並列処理のソリューションを提案しています。

各ワーカーがデータの一部のみを保持するデータ並列処理と比較すると、モデル並列処理の各ノードはすべてのデータを使用します。

以下では、モデル並列化のいくつかの方法について簡単に説明します。

Tensor Parallelism は主に、レイヤー内の行列計算を 1D Megatron などの異なる計算マシンに分割します。
パイプライン並列処理では、モデルのレイヤーを異なるマシンに分割するため、フォワード操作を異なるマシン間で連続的に実行する必要があります。一般的な並列処理では、バッチサイズをより小さなマイクロバッチに分割することでデータの依存関係が軽減され、コンピューティングプロセス全体が非同期になり、リソースの使用率が最大化されます。

CTR プロモーション検索シナリオ:

CTR 大規模モデルシナリオでは、小規模モデルと大規模語彙の特徴を備えています。

モデルの高密度部分は一般に非常に小さく、多くの場合、マシンのメモリに収容できます。ただし、特徴量の大きさは数千億に達する可能性があり、スパース部分または埋め込みテーブルが TB レベルに達し、単一のマシンでは対応できなくなります。
バッチの埋め込み検索は大規模であるため、クエリに時間がかかります。特徴の数が多いため、バッチには数十万の ID タイプの特徴が含まれる場合があります。TF のネイティブ埋め込み検索クエリは時間がかかるため、トレーニングと推論のパフォーマンスが低下します。
データは大規模なスパース性が特徴です。データが密な画像やテキストである CV や NLP シナリオとは異なり、検索とプロモーションのデータは非常にスパースです。第一に、すべてのユーザーとシナリオに対して大量のデータを効果的に収集することはできないためです。第二に、モデリングで使用される機能の規模が大きいため、高次元のスパース性が生じ、データの保存形式と計算効率に影響するためです。

したがって、大きな密なパラメータを持つ大規模な CTR モデルの問題を解決する鍵は、スパースパラメータを単一マシンストレージから分散ストレージに変換し、主にデータ並列処理によってスループットを向上させることです。

次に、トレーニングフレームワークの最適化ポイントについて説明します。 2 つの核となるポイントは、分散通信トポロジの設計と、埋め込みルックアップのパフォーマンス最適化です。

スパースパラメータは、パラメータサーバーの助けを借りて、埋め込みストレージと更新の負担を PS に転送します。スパースパラメータはパーティションに保存され、各ワーカーはシャードの一部のみを持ち、勾配が更新されると AlltoAll が実行されます。スパーステンソルのストレージと通信のコストを解決してみてください。
密なパラメータは、allreduce の助けを借りて、レプリケーションに保存されます。各ワーカーにはコピーがあり、勾配が更新されると allreduce が実行されます。 Allreduce と alltoall はどちらも同期通信に nccl を使用するため、より効率的です。 hb が alltoall を実行する場合、完全なパラメータではなくスパース勾配を通信します。通信量は ps と同じですが、通信効率は高くなります。

実装面では、TF ネイティブ演算子 (コア演算子は GatherV2 演算子) を置き換えることで、Sparse パラメータの読み取りプロセスを実行できます。

この演算子の機能は、ID リストインデックスに対応する Embedding データを Embedding テーブルから読み取り、それを返すことです。これは本質的にハッシュクエリプロセスです。

演算子を置き換え、上流ノードと下流ノードの入出力を同時に変更することで、ローカルの埋め込みテーブルからのクエリが分散 KV からのクエリに変換されます。