考えてみてください。連合学習は大規模な言語モデルをトレーニングできるのでしょうか?

1. 概要

大規模言語モデル (LLM) の急速な発展に伴い、LLM が人工知能業界の発展に与える影響についての議論がますます活発化しています。大規模言語モデルはパラメータが多く、大量の計算能力を必要とし、大量のトレーニングデータに依存するため、大規模言語モデルの開発が人工知能スタートアップの開発の道を破壊したという見方もある。大規模なモデル、大規模なパラメータ、ビッグデータは、実際には大規模な人工知能企業に集中しており、スタートアップの機会はますます少なくなっています。もう1つの観点は反対です。大規模言語モデルの開発は、ある程度、複数の分野での人工知能の広範な発展を促進したと考えています。たとえば、一部の垂直分野の大規模言語モデルは、プライベートデータを使用して大規模言語モデルに基づいて直接構築でき、大規模言語モデルはさまざまなビジネスシナリオに直接適用できます。

この記事では、上記の 2 つの観点については説明しません。2 番目の観点で言及されているアプリケーション方法、つまり垂直分野のアプリケーションニーズを満たすためにデータのプライバシーを確保しながら、プライベートデータを使用して大規模な言語モデルをトレーニングする方法に焦点を当てます。これは、LLM が人工知能のスタートアップ企業の発展を促進するための鍵にもなります。具体的には、大規模な言語モデルのトレーニングにフェデレーテッドラーニングを使用できるかどうかが懸念されます。

1.1 大規模言語モデルの構造と必要なリソース

Transformer アーキテクチャは優れた並列性と容量を備えているため、さまざまな LLM を開発するための事実上のバックボーンネットワークとなり、言語モデルを数千または数億のパラメータに拡張することが可能になりました。一般的に、既存のLLMの主流のアーキテクチャは、図1に示すように、エンコーダデコーダ、因果デコーダ、プレフィックスデコーダの3つのタイプに大別できます[8]。

写真

図 1. 3 つの主流アーキテクチャにおける注意パターンの比較。青、緑、黄、灰色の丸い四角形は、それぞれプレフィックストークン間の注目度、プレフィックストークンとターゲットトークン間の注目度、ターゲットトークン間の注目度、マスクの注目度を表します。

エンコーダ/デコーダアーキテクチャ。 Vanilla Transformer モデルは、エンコーダーとデコーダーとして機能する 2 つの積み重ねられた Transformer ブロックで構成されるエンコーダー/デコーダー構造に基づいて構築されます。エンコーダーは、入力シーケンスをスタックされたマルチヘッド自己注意層でエンコードして潜在表現を生成し、デコーダーはこれらの表現をクロスアテンションしてターゲットシーケンスを自動的に生成します。 T5 や BART などのエンコーダー/デコーダーは、さまざまな NLP タスクで有効性が示されています。これまでのところ、Flan-T5 などのエンコーダー/デコーダーアーキテクチャに基づいて構築された LLM はごくわずかです。
因果デコーダーアーキテクチャ。因果デコーダーのアーキテクチャには、各入力トークンが過去のトークンとそれ自身にのみ注意を払うことができるようにするための単方向注意マスクが含まれています。入力トークンと出力トークンはデコーダーによって同じように処理されます。このアーキテクチャの代表的な言語モデルとして、因果デコーダーアーキテクチャに基づいて GPT シリーズのモデルが開発されています。特に、GPT-3 はこのアーキテクチャの有効性を実証し、LLM の驚くべき含意学習能力も示しました。興味深いことに、GPT-1 と GPT-2 は GPT-3 の優れた機能を実証しておらず、このモデルアーキテクチャのモデル容量を増やすにはスケーリングが重要な役割を果たしたようです。これまで、因果デコーダーは、OPT、BLOOM、Gopher などのさまざまな既存の LLM によって LLM のアーキテクチャとして広く採用されてきました。
プレフィックスデコーダーアーキテクチャ。プレフィックスデコーダーアーキテクチャ (非因果デコーダーとも呼ばれる) は、因果デコーダーのマスキングメカニズムを変更して、プレフィックストークンに双方向で対応し、生成されたトークンに一方向にのみ対応できるようにします。このように、エンコーダー-デコーダー構造と同様に、プレフィックスデコーダーはプレフィックスシーケンスを双方向にエンコードし、エンコードとデコード中に同じパラメーターを共有しながら、出力トークンを 1 つずつ自動的に予測できます。最初から事前トレーニングする代わりに、因果デコーダーを継続的にトレーニングし、それをプレフィックスデコーダーに変換して収束を高速化することが実用的な提案です。たとえば、U-PaLM は PaLM から派生します。プレフィックスデコーダに基づく既存の代表的な LLM には、GLM130B と U-PaLM があります。

しかし、大規模言語モデルの開発においては、主に以下の点に焦点を当てて疑問を呈する人が増えています。

プライバシーは侵害されるべきではありません。最先端のモデルには、一般的なブラックボックス API を通じてのみアクセスできます。これらの API は、企業が集中型 LLM プロバイダーにデータを送信する際にプライバシーに関する懸念を引き起こします。たとえば、Samsung は ChatGPT 経由で秘密情報を漏洩したと報じられており、このような API に関連するリスクが浮き彫りになっています。
独自のトレーニング済みモデルは重要な知的財産です。企業にとって、AI から最も恩恵を受ける可能性のある問題やデータセットは、機密性が高く、独自のものであることが多いです。これにより、パブリックモデルの微調整が不可能になるため、企業はオンプレミスでモデルを微調整するか、企業のファイアウォール内にモデルを展開する方が適切です。
コストの問題。現在、LLM トレーニングには数千の GPU ノードが必要であり、数十億ドルのコストがかかります。モデルでは、クラウドコストを削減するためにモデルのパフォーマンスにわずかに影響を及ぼすなど、さまざまなトレードオフのバランスを取る必要がある場合があります。モデルを所有することで、顧客はモデルを便利に微調整し、再トレーニングすることができます。たとえば、冗長なモデルパラメータを削除して、クラウドコストを最小限に抑えながら、ドメイン固有のタスクで高いパフォーマンスを実現できます。

これが、この記事で説明する方法、つまり FL+LLM につながります。この方法では、大規模な言語モデルをトレーニングするためにフェデレーテッドラーニングが導入され、企業のビジネスユーザーに多くの利点がもたらされ、モデルの規模とパフォーマンス、プライバシー、効率、クラウドコンピューティングコスト、人件費の面で企業が大規模なモデルを使用する能力が大幅に強化されます。

1.2 フェデレーテッドラーニングの概要

フェデレーテッドラーニング (FL) は、トレーニングデータを分散したまま、複数のクライアント (モバイルデバイスや組織全体など) が中央サーバー (サービスプロバイダーなど) の調整の下で共同でモデルをトレーニングする機械学習環境です。 FL は、集中型のデータ収集と最小化の原則を具体化しており、従来の集中型の機械学習やデータサイエンスのアプローチに伴うプライバシー、セキュリティのリスク、コストの多くを軽減できます。したがって、FL は効果的な高性能コンピューティングパラダイムであり、データプライバシー要件を満たす分散トレーニング方法としても考えられています。現在、FL は、GBoard、キーワード検出などの一部の消費者向けデバイス、医薬品、医療研究、金融、製造など、いくつかのアプリケーションシナリオで効果的に使用されています。さらに、Tensorow Federated、LEAF、PaddleFL、PySyなど、多数のFL開発ツールとプラットフォームが登場し、FLの開発をさらに促進しています。

フェデレーテッドラーニングフレームワークでは、中央サーバーが共有可能なグローバルデータを保存および初期化します。各クライアント (参加者、エッジデバイス) はローカルデータを保存し、ローカルデータに基づいてローカル機械学習モデルをトレーニングします。クライアントは、特定の通信メカニズムに基づいて、モデルパラメータやその他のデータを中央サーバーに送信します（クライアントの元のデータ全体が送信されることはありません）。中央サーバーは、各クライアントがアップロードしたデータを収集し、グローバルモデルをトレーニングして構築します。各クライアントは、連合学習メカニズム全体で同じ ID とステータスを持ちます。フェデレーテッドラーニングは、データを提供することなく 2 つ以上のデータ使用エンティティ (クライアント) 間でデータを共有する問題を効果的に解決し、データサイロの問題を解決します。さらに、各クライアントのデータ特性を整合するという前提の下、フェデレーテッドラーニングのグローバルモデルは、集中型データストレージと同じモデリング効果を実現できます。

以下は、非常に重要な 4 つの連合学習アルゴリズムです。

1. FedAvg（Federated Averaging）[1]：FedAvgは、2016年にGoogleによって提案された最も古典的な連合学習アルゴリズムです。このアルゴリズムは、勾配降下法を使用してモデルパラメータを反復的に更新します。 FedAvg では、各クライアント (携帯電話やその他のデバイスなど) はまず独自のデータを使用してローカルでモデルをトレーニングし、次にローカルモデルの重みを中央サーバーに送信します。中央サーバーは、すべてのクライアントから重みの更新を収集し、重みの平均を計算し、更新された重みを個々のクライアントに配布します。このプロセスは、収束に達するまで複数ラウンドにわたって実行されます。

2. FedProx（Federated Proximal）[2]：FedProxは、非独立かつ同一に分散された（非IID）データと、フェデレーテッドラーニングにおけるデバイスの異質性の問題を解決する、改良されたフェデレーテッドラーニングアルゴリズムです。これらの問題は、特にトレーニングデータが不均一に分散されている場合に、トレーニングの品質の低下につながる可能性があります。 FedProx は、最適化目標に近似項を追加することでこの問題を解決します。これにより、モデルは更新時にグローバルモデルの重みに近いローカルモデルの重みにさらに注意を払うようになります。これにより、非 IID データとデバイスの異質性による悪影響を軽減し、モデルのパフォーマンスを向上させることができます。

3. SCAFFOLD（確率的制御平均化による連合学習）[3]：SCAFFOLDは、勾配スパース性とデバイス間通信に重点を置いた効率的な連合学習アルゴリズムです。 SCAFFOLD は、各ラウンドで制御変数を維持することで通信量を削減します。この制御変数は、グローバルモデルの勾配の変化に応じて調整できるため、各デバイス間の通信がよりコンパクトになります。 SCAFFOLD は通信効率が高く、モデルのパフォーマンスを犠牲にすることなく通信コストを削減できます。

4. FedNova（正規化平均化による連合学習）[4]：FedNovaの中心的なアイデアは、正規化平均化法を使用して、高速なエラー収束を維持しながらターゲットの不一致を排除することです。各反復では、各クライアントデバイスでローカルトレーニングが実行され、ローカルモデルパラメータが正規化され、正規化されたパラメータが中央サーバーに送信されます。すべてのクライアントからパラメータの更新を収集した後、中央サーバーはそれらを正規化して平均化し、ターゲットの不一致を減らします。その後、中央サーバーは更新されたモデルパラメータをクライアントに配布し、次の反復でトレーニングを継続します。 FedNova の利点は、高速なエラー収束を維持しながら、データの異質性によって生じるターゲットの不整合を排除できることです。これにより、FedNova アルゴリズムは、独立していない同一に分散されたデータやデバイスの異質性を処理する際に、より優れたパフォーマンスを発揮します。

2. 大規模言語モデルを訓練するために連合学習構造を使用する難しさ

近年、LLMとFLに関する研究は一定の進歩を遂げています。しかし、現在の技術的およびリソース的な状況では、直接 FL+LLM は依然として一連の問題に直面しています。

2.1 データ

LLM のトレーニングには、非常に大量のデータが必要です。 ChinchillaらはLLMを訓練するのにどれだけのデータが必要かを調査した[9]。 2020 年 5 月、OpenAI は LLM データスケーリング法則 (Kaplan スケーリング法則とも呼ばれる) を実証しました。3000 億トークンを使用して、パラメーター付きの 1750 億 LLM をトレーニングできます。 2022 年 9 月、DeepMind は「データ最適」LLM の新しいデータスケーリング法則 (チンチラスケーリング法則またはホフマンスケーリング法則とも呼ばれる) を発見しました。パラメータサイズが 70B の最適な LLM をトレーニングするには、1,400B (1.4T) のトークンを使用する必要があります。

写真

表1.チンチラデータ最適化モデルと整合するために必要なデータセットのサイズ[9]

Chinchilla が表 1 に示したデータから、連合学習構造を LLM のトレーニングに適用すると、必然的に大量のデータが異なるクライアントデバイスに分散されることがわかります。クライアントの数が少ない場合、各クライアントに保存および持ち運ばれるデータの量は依然として多く、各クライアントのコンピューティングパフォーマンス要件は非常に高く、連合学習アーキテクチャの本来の設計意図と一致しません。クライアントの数が非常に多く、各クライアントに保存されるデータの量が中程度の場合、多数のクライアント間の調整呼び出しメカニズム、マルチパーティのコンピューティングパワー、およびリソースの不均衡な割り当てによるリソースの不均衡問題が非常に顕著になります。不均衡な状況でのクライアントのインセンティブメカニズムも特に重要であり、連合学習の中心モデル効果とトレーニング効率に大きな影響を与えます。

2.2 クライアントデバイス

フェデレーテッドラーニングアーキテクチャに基づく分散システムでは、単一のクライアントがどのようにして LLM モデル全体に対応するのでしょうか。既存のフェデレーテッドラーニングプラットフォーム、特に実用的なシナリオでは、分散クライアントデバイスは主に携帯電話やタブレットなどです。これらのデバイスは、LLM モデル全体を収容したり、モデルのトレーニングに十分なメモリリソースを提供したりすることはできません。これらのデバイスがトレーニングプロセスから完全に除外されると、フェデレーテッドラーニングアーキテクチャの本来の設計意図とも矛盾することになります。しかし、クライアントがモデル全体を収容できず、クライアントをトレーニングプロセスから完全に除外できない場合、どのようにして LLM を並行してトレーニングするのでしょうか。

マイクロソフトは記事の中で、LLaMAの現在のデバイスメモリ使用量を分析しました[10]。モデルのトレーニング中、メモリオーバーヘッドのほとんどはモデルの状態 (モデルパラメーター、オプティマイザーの状態、勾配) に使用されます。残りのメモリオーバーヘッドは、残留状態 (アクティベーション、一時キャッシュ、メモリの断片化) によって発生します。

LLaMA 7B モデルを例にとると、モデルパラメータに必要なメモリは (パラメータ数 * 各パラメータのメモリ) 次のように計算されます。fp32 精度: 7 * 4 バイト = 28 GB、fp16 精度: 7 * 2 バイト = 14 GB、int8 精度: 7 * 1 バイト = 7 GB、混合精度 (fp16/32) トレーニング: ストレージ fp16 精度 + fp32 精度 = 14 GB +28 GB = 42 GB。

勾配に必要なメモリ (モデルパラメータと同じ方法で計算、パラメータ数 * パラメータあたりのメモリ): fp32 精度: 7 * 4 バイト = 28 GB、fp16 精度: 7 * 2 バイト = 14 GB、int8 精度: 7 * 1 バイト = 7 GB、混合精度 (fp16/32) トレーニング: fp16 精度のみを保存 = 14 GB。

オプティマイザーに必要なメモリ (パラメータ数 * 各パラメータのメモリ * 2、Adam を例にとると): fp32 精度: 7 * 4 バイト * 2 = 56 GB、fp16 精度: 7 * 2 バイト * 2 = 28 GB、int8 精度: 7 * 1 バイト * 2 = 14 GB、混合精度 (fp16/32) トレーニング: ストレージ fp32 精度 = 56 G。

一般に、LLaMa モデルのトレーニングに必要な合計メモリは次の通りです: fp32 精度: 28+28+56 = 112GB、fp16 精度: 14+14+28 = 56GB、int8 精度: 7+7+14 = 28G、混合精度 (fp16/32) トレーニング: 42+14+56 = 112GB。

LLaMA 7B のサイズは現在の LLM に比べて非常に小さいですが、一部の携帯電話やタブレットでは LLaMA 7B のメモリ消費量を満たすのが難しく、FL アーキテクチャでのクライアントデバイスの選択に大きな制約が生じます。

2.3 トレーニングアルゴリズム

既存の連合学習トレーニングアルゴリズムは LLM には非効率的です。前述のように、フェデレーテッドラーニングの動作プロセスは次のとおりです。「各クライアントは、ローカルデータに基づいてローカルモデルをトレーニングします。クライアントは、特定の通信メカニズムに基づいて、モデルパラメーターやその他のデータを中央サーバーに送信します。中央サーバーは、各クライアントによってアップロードされたデータを収集し、グローバルモデルをトレーニングして構築します。」 LLM のパラメータ数とモデル構造は非常に大きく、送信および集約プロセスは通信状況の影響を受けるため、作業プロセス全体の効率は非常に低くなります。

3. FL+LLM はどのような進歩を遂げましたか?

FL+LLM はまだ多くの問題に直面していますが、多くの研究者が関連方向の技術的な可能性を探求し始めており、ある程度の進歩を遂げています。この章では、関連する作業の進捗状況を紹介します。

3.1 FedLLM: 独自のデータに基づく大規模言語モデルの構築

FedLLMはMLOpsをサポートするトレーニングパイプラインであり、企業が独自のデータに基づいて独自の大規模言語モデルを構築できるようにします[7]。コードは公開されています: https://github.com/FedML-AI/FedML/tree/master/python/app/fedllm。 FedLLM は、単に「LLM の連合学習」ではなく、「LLM の基本的なエコシステム設計」を意味します。

FedLLM は、FedML.Inc. によって開始された FL+LLM フレームワークです。 FedML, Inc. (https://FedML.ai) は、中国人が率いる国際チームです。南カリフォルニア大学出身で、この技術を研究する世界でも初期の機関の 1 つです。過去数年間、FedML は博士課程の学生が主導するオープンソースの科学研究プロジェクトとしてスタートし、複数の科学研究基金に役立ち、50 件を超える関連するトップ論文の出版において研究室を支援してきました。 2023年、FedMLは、Camford Capitalが主導し、Plug and Play Ventures、AimTop Ventures、Acequia Capital、LDV Partnersなどの投資家が参加した、600万ドルのシードおよびプレシードラウンドの資金調達を完了したことを発表しました。

図2. FedLLMトレーニングプロセス

図 2 に示すように、FedLLM はデータコラボレーション、コンピューティングコラボレーション、モデルコラボレーションを実装し、集中型および地理的に分散された GPU クラスターでのトレーニング、およびデータアイランドのフェデレーテッドラーニングをサポートします。 FedLLM は、HuggingFace や DeepSpeed などの一般的な LLM ライブラリと互換性があり、効率性とセキュリティ/プライバシーを向上させるように設計されています。

データコラボレーション - ドメイン固有の独自データに関する LLM のトレーニングを可能にします。一般的な LLM である ChatGPT と GPT-4 は、人間によって公開され注釈が付けられた大量のテキストでトレーニングされます。 ChatGPT がうまく機能しない可能性がある業種は多数あります (ヘルスケア、フィンテック、法律、自動車など)。企業が独自のデータでモデルをトレーニングできるようにすることで、プライバシーを保護しながらパフォーマンスを向上させることができます。場合によっては、データセットがさまざまなデータウェアハウスに分散されていると、FedML フェデレーテッドラーニングトレーニングパイプライン「Train on the Edge」が安全かつスケーラブルな方法でそれを処理します。
コンピューティングコラボレーション - 分散コンピューティングリソースを活用します。コンピューティング能力への多額の投資により、LLM 事前トレーニングを実施できるのは、Microsoft、Google などの少数の大手テクノロジー企業のみです。さまざまな業種の企業は、数十億ドルかかる数千の GPU ノードを購入する余裕がありません。 GPU リソースを最大限に活用するためのよりコスト効率の高い方法は、組織間の共有メカニズムを確立することです。 FedML は、地理的に分散された CPU/GPU ネットワーク上でトレーニングジョブをスケジュールできる「クラウドでのトレーニング」プラットフォームを通じてこれを実現します。このコンピューティングに関するコラボレーションにより、組織内で大量の GPU ノードを購入する際の経済的負担を軽減できます。
モデルのコラボレーション - フェデレーション方式でモデルを提供します。大規模なモデルベースの提供も課題です。他の MLOps と比較して、FedML は地理的に分散されたクラウドコンピューティングリソースを介したフェデレーテッドモデル推論というアイデアの先駆者です。推論リクエストが推論エンドポイントに送信されると、マスターノードはリクエストを GPU ベンダーがホストする分散エッジノードにルーティングし、GPU のアイドル時間を共有できるようになります。このようなモデルサービスプラットフォームは、より優れたサービス信頼性とより安価なクラウドコンピューティングコストを提供できます。

FedLLM は、既存のオープンソース LLM と一般的なフレームワークを活用して、特定のアイランド GPU クラスターでのローカルトレーニングを行います。

モデル定義と事前トレーニング済みの重みは、EleutherAI の pythia の 2.8B、7B、および 12B バージョンから取得されます。リファレンス実装として Hugging Face のトランスフォーマーを使用します (https://github.com/huggingface/peft?ref=blog.fedml.ai)。 FedLLM は、企業や開発者が任意の LLM にプラグインできる、モデルに依存しないフレームワークでもあります。
FedLLM は、LoRA などのパラメータ効率の高いトレーニング方法をサポートします。そのリファレンス実装は、HuggingFace の peft (https://huggingface.co/docs/transformers/index?ref=blog.fedml.ai) から取得されています。
スタンドアロントレーナーの場合、トレーニング/評価コードは Transformers ライブラリ (https://huggingface.co/docs/transformers/index?ref=blog.fedml.ai) の Trainer に基づいています。
特定の GPU クラスター上の分散トレーニングフレームワークは、DeepSpeed （https://www.deepspeed.ai/?ref=blog.fedml.ai）によって処理されます。 Zero3 を有効にすると、単一の GPU のメモリコストも削減されます。 FedML と DeepSpeed 間の互換性を強化することで、FedLLM は異なる物理空間の分散クラスターでトレーニングジョブを実行できるようになります。

FedML では、FedLLM を適用する例も示されています。図 3 に示すように、ローカルデータはローカルのままであり、モデルパラメーターまたは重みデータのみが中央サーバーとの間でやり取りされます。この特定の例では、ローカルデータでのトレーニングの利点と、他のデバイスからのトレーニングを活用して中央サーバーによるトレーニングを微調整する利点を組み合わせたチャットタイプのアプリケーションを想定しています。チャットアプリケーションは単なる例であり、LLM モデルを利用する他のアプリケーションに置き換えることができます。

図3. FedLLMアプリケーションの例

FedLLM は、ある程度まで、連合学習を使用して LLM をトレーニングできます。しかし、第 2 章で議論したことを振り返ると、連合学習アーキテクチャを使用して LLM をトレーニングするにはまだ多くの問題があります。公開されている技術コンテンツから判断すると、FedLLM はこれらの問題を解決できていません。 FedLLM アーキテクチャで想定されるコンピューティングノードは、すべて一定のコンピューティング能力を持つ GPU ノードです。FedLLM が解決できる問題は、「大量の GPU を購入する必要がない」ことです。しかし、実際の連合学習では、多くのクライアントノードは携帯電話やタブレットであり、FedLLM はこれらの状況に適応できません。同じ問題はクライアントノードのデータ量の場合にも存在します。つまり、FedLLM は、クライアントがローカル LLM をトレーニングするために必要なデータ量に対応できるほど十分大きいと想定します。最後に、FedLLMでは、FL for LLMに適した集約アルゴリズムがどのようなものか、またクライアント側でLLMをトレーニングするためのアルゴリズムを改善する必要があるかどうかについては議論されていませんでした。FL+LLMの適用を真に促進するためには、この点をさらに改良し解決する必要があります。

3.2 DeepSpeed: 規模、速度、コスト、使いやすさを改善することで大規模モデルのトレーニングを進化させ、1,000億のパラメータモデルをトレーニングする能力を解き放ちます。

LLM は、トレーニング中に中間アクティベーション、重み、その他のパラメータを保存するために、多くのメモリを必要とすることがよくあります。100 億のモデルは単一の GPU でトレーニングすることすらできないため、モデルのトレーニングは非常に非効率的で、場合によっては不可能になります。初期の段階では、一部の研究者は、主にデータ並列処理 (モデルの異なるインスタンスを異なる GPU と異なるデータバッチで実行) とモデル並列処理 (モデルをトレーニング用に複数の GPU に分割) を使用して、マルチノード分散トレーニングの問題に焦点を当てていました。

DeepSpeed は、分散トレーニングと混合精度技術を通じてトレーニング速度の向上とリソースの節約を目的とした、Microsoft が開発したディープラーニングトレーニング最適化ツールです。これは、複数のプラットフォームで実行されるオープンソースの Python ライブラリです。 TensorFlow、Pytorch、Keras などの従来のディープラーニングフレームワークと比較して、DeepSpeed はモデルパラメータを GPU 全体に分散して大規模なモデル計算を実現し、より少ない GPU で、ビデオメモリに制限されることなく、より大きなモデルをトレーニングできます。

データ並列処理では、すべてのワーカー間でモデルとオプティマイザーが複製されるため、メモリ効率は良くありません。 DeepSpeed は、データ並列処理におけるメモリ効率を向上させるオプティマイザーファミリである ZeRO を開発しました。モデルの並列処理については、DeepSpeed は NVIDIA の Megatron-LM を借用して、Transformer ベースの言語モデルに大規模なモデルの並列処理を提供します。

具体的には、DeepSpeed （https://www.deepspeed.ai）を使用すると、1 回のクリックで ChatGPT のようなモデルトレーニングが可能になり、SOTA RLHF システムに比べて 15 倍の高速化と、あらゆる規模で前例のないコスト削減が実現します。 DeepSpeedには3つの革新があります。

DeepSpeed トレーニング: DeepSpeed は、大規模なディープラーニングトレーニングを効果的かつ効率的に行う一連のシステムイノベーションを提供し、使いやすさを大幅に向上させ、可能なスケールの観点からディープラーニングトレーニングの状況を再定義します。 ZeRO、3D-Parallelism、DeepSpeed-MoE、ZeRO-Infinity などのこれらのイノベーションはすべて、DeepSpeed-Training の中核をなしています。
DeepSpeed 推論: DeepSpeed 推論は、Transformer モデル推論のための包括的なシステムソリューションです。 DeepSpeed 推論は、(1) 集約 GPU メモリに収まる密な Transformer モデルと疎な Transformer モデルのスループットを最大化しながらレイテンシを最小限に抑えるマルチ GPU 推論ソリューション、および (2) GPU メモリとコンピューティングに加えて CPU と NVMe メモリを活用して集約 GPU メモリに収まらない大規模なモデルで高い推論スループットを実現する異種推論ソリューションで構成されています。
DeepSpeed 圧縮: 推論効率をさらに向上させるために、DeepSpeed は研究者や実務者に、モデルを圧縮するための使いやすく柔軟に構成された圧縮手法を提供し、速度の向上、モデルサイズの縮小、圧縮コストの大幅な削減を実現します。さらに、ZeroQuant や XTC など、SoTA の圧縮技術の革新も DeepSpeed-Compression に組み込まれています。

具体的には、DeepSpeed Inference の 2 つのコアコンポーネントが次のように紹介されています。

DeepSpeed Transformer: DeepSpeed Transformer は、密な Transformer モデルと疎な Transformer モデルの両方で、レイテンシを最小限に抑えながらスループットを最大化するように設計された GPU 専用のソリューションです。あらゆる規模の Transformer モデルに対して最先端のレイテンシとスループットを実現し、単一の GPU での実行や、数百万のパラメータを持つモデルの推論のために数百の GPU にスケーリングすることをサポートします。 DeepSpeed Transformer ソリューションは、次の 3 層システムアーキテクチャで構成されています。i) 小さなバッチサイズでのメモリ帯域幅の利用と、大きなバッチサイズでの高スループットに最適化された単一の GPU Transformer コア、ii) テンソルスライスと推論に最適化されたパイプライン並列処理を活用して GPU 上で高密度 Transformer モデルをスケーリングする複数の GPU 高密度 Transformer レイヤー。大規模な GPU スケールのスパーストランスフォーマーレイヤーは、並列技術と通信最適化戦略を組み合わせて MoE トランスフォーマーレイヤーを数百の GPU に拡張すると同時に、最適化されたスパースカーネルを使用して単一 GPU のスパース計算のオーバーヘッドを最小限に抑えることを目的としています。この階層化アプローチでは、各レイヤーがバッチサイズ、高密度モデルのスケーリング、スパースモデルのスケーリングというレイテンシ課題の固有の側面に対処しながらも、相互に互換性があり、相互に構築されるため、DeepSpeed Transformer は、バッチサイズ、モデルサイズ、モデル機能の異質性にもかかわらず、これまでにない規模で高密度 Transformer モデルとスパース Transformer モデルの両方に対して最適なレイテンシとスループットを実現する包括的なシステムです。
ZeRO-Inference: ZeRO-Inference は、異機種 GPU + CPU + NVMe ベースのソリューションであり、大規模な分散型ディープラーニング向けの新しいメモリ最適化テクノロジーです。最小限の GPU リソースで大規模モデル推論を可能にすることで、メモリの問題を解決します。 DeepSpeed Transformer と比較すると、レイテンシの影響を受けにくいがリソースが限られているアプリケーションの場合、ZeRO-Inference は、モデルパラメータを保存するのに十分な CPU または NVMe メモリがある限り、単一または複数の GPU 上で数千億のパラメータを持つモデルを推論できます。

図4.DeepSpeed圧縮ライブラリ

DeepSpeed Compression は、図 4 に示すように、圧縮の構成可能性の課題に対処するためにシームレスなパイプラインを提案します。 DeepSpeed Compression の中核は、圧縮コンポーザーと呼ばれるコンポーネントであり、いくつかの重要な機能が含まれています。

1. 極端な量子化、ヘッド/行/チャネルのプルーニング、知識蒸留などのさまざまな最先端の圧縮方法を提供し、モデルのサイズと推論コストを効果的に削減できます。最先端の圧縮方法がさらに取り入れられるにつれて、このリストは増え続けます。

2. さまざまな圧縮技術を組み合わせて複数の圧縮方法の複合的な利点を提供するという複雑な問題を自動的に処理する、使いやすい API を提供します。たとえば、XTC では、軽量レイヤー削減、バイナリ化、知識蒸留の組み合わせが必要です。しかし、それらを組み合わせるのは難しくありません。圧縮コンポーザーを使用すると、圧縮を有効にして圧縮モデルをクリーンアップするための 2 つの新しい API 呼び出しを追加するだけで、極端な圧縮を簡単に適用できます。

3. モジュール方式で設計されているため、ユーザーは新しい圧縮方式を簡単に追加できます。たとえば、カスタム圧縮レイヤーを圧縮コンポーザーに登録することで、追加の圧縮方法を追加できます。また、新しい方法は、コンポーザーによってすでに管理されている既存の方法と組み合わせることができます。

4. DeepSpeed ライブラリとシームレスに統合されます。これには2つの利点があります。まず、DeepSpeed の圧縮は、DeepSpeed のトレーニングや推論と同じように、JSON ファイルで指定して有効化できます。さまざまな圧縮手法の組み合わせを有効にするには、JSON ファイル内の数行を変更するだけで済みます。 2 番目に、圧縮スキームが設定されると、圧縮コンポーザーはモデルレイヤーとトレーニングを自動的に変更して圧縮プロセスを有効にするため、ユーザーによるモデル構造やトレーニング手順の追加変更は必要ありません。

3.3 関連するアルゴリズムの基礎

LLMの大規模な事前トレーニングのコスト問題に対処するために、研究者らはアルゴリズムレベルから、大規模言語モデル向けの低ランク適応法、大規模言語モデルをトレーニングするための軽量な方法であるLoRA（LOW-RANK ADAPTATION）を提案しました。事前トレーニング済みモデルの重みを固定し、トレーニング可能なランク分解マトリックスを Transformer アーキテクチャの各レイヤーに挿入することで、下流タスクのトレーニング可能なパラメーターの数が大幅に削減され、下流タスクでの事前トレーニング済みモデルの微調整効率が効果的に向上します。

写真

プロジェクトアドレス: https://github.com/microsoft/LoRA [6]

さまざまなドメインやタスクに大きな言語モデルを微調整するという課題に対処するために、部分的な微調整、アダプター、プロンプトを使用するなど、多くのソリューションがあります。ただし、これらの方法には次の問題があります。

アダプターは追加の推論レイテンシを導入します（モデル層の増加により）
プレフィックス調整をトレーニングするのは難しく、プロンプトのために予約されているシーケンスは、下流タスクの入力シーケンススペースを占有し、モデルのパフォーマンスに影響を与えます

Loraが提案するアイデアは次のとおりです。モデルには多くのパラメーターがありますが、モデルは実際には主に低ランクの寸法コンテンツ（低本質的な次元）に依存しています。適応中に、ウェイトの更新には「固有のランク」も低いと想定されています。事前に訓練された重量マトリックスw_0∈R^d×kの場合、後者を低ランク分解で表すことにより、その更新を制約します。

写真

トレーニング中、W_0は凍結されており、グラデーションの更新を受け取りませんが、AとBにはトレーニング可能なパラメーターが含まれています。 W_0と∆W = Baの両方に同じ入力を掛け、それぞれの出力ベクトルに座用します。 h = w_0xの場合、変更されたフォワードパスの収率：

写真

図5。aとbのみのトレーニングを修復しました

図5に示すように、Aはランダムガウスで初期化され、Bはゼロで初期化されるため、トレーニングの開始時に∆W = BAはゼロです。次に、∆WXはα/Rで調整されます。ここで、αはrの定数です。 Adamで最適化する場合、初期化が適切に調整されている場合、αの調整は学習レートの調整とほぼ同じです。したがって、αを調整せずに試行する最初のRにαを設定するだけです。このスケーリングは、rを変更するときにハイパーパラメーターを再調整する必要性を減らすのに役立ちます。

写真

図6。従来の微調整およびロラ図

図6に示すように、Rは適応に使用される低ランクマトリックスのランクを指定するハイパーパラメーターです。 Rが小さいほど、低ランクマトリックスが簡単になるほど、適応プロセス中に学習する必要があるパラメーターが少なくなり、トレーニングが速くなり、それに応じて計算要件が削減されます。ただし、小さいRの欠点は、低ランクマトリックスがタスク固有の情報をキャプチャできないことです。これにより、適応品質が低下する可能性があり、モデルはより高いRと比較して新しいタスクでパフォーマンスが低下する可能性があります。要約すると、LORAのRの値を決定するには、モデルの複雑さ、適応性、および過小装着または過剰装着のリスクとの間のトレードオフが必要です。したがって、Rの異なる値を試して、新しいタスクで望ましいパフォーマンスを達成する適切なバランスを見つけることが重要です。

たとえば、マトリックスランク（R）は非常に低い場合があります。GPT-3 175Bモデルの場合、ランク1またはランク2は基本的に元のRANK-1288の効果を整列させることができます。

Adamで微調整されたGPT-3 175Bと比較して、Loraのトレーニング可能なパラメーターは10,000倍少なく、GPUメモリの要件が3倍少ない
Roberta、Deberta、GPT-2、GPT-3などの大規模な言語モデルでは、LORAは、トレーニング可能なパラメーターが少なく、トレーニングスループットが高く、アダプターとは異なるにもかかわらず、モデル品質の点で微調整よりもPAR以上でパフォーマンスを発揮します。

3.4関連するハードウェアの基本

最後に、私たちは物事のハードウェア側に来ます。

Grace Hopperは、Nvidia Ampere GPUの前世代と比較して、大規模なAIおよびHPCアプリケーションに桁違いの改善を提供するように設計されたNvidia Data Center GPUの第9世代です。スレッドブロッククラスタリングとスレッドブロック再構成により、空間と時間のデータの局所性が向上し、新しい非同期実行エンジンとともに、アプリケーションが常にすべてのユニットを忙しくしておくことができます。 Nvidia Grace Hopperは、Nvidia Grace CPUとNvidia Hopper GPUを、900 GB/sの総帯域幅を持つチップ間相互接続であるNVIDIA NVLink C2Cを介してSuperChipに組み合わせています。 NVLINK C2Cメモリの一貫性により、Grace CPU SuperChipとGrace Hopper SuperChipの両方が、統一されたプログラミングモデルを使用してプログラムできます。

写真

図7。NVIDIAグレースホッパースーパーチップロジックの概要

2023年6月、Nvidiaは、新しいGH200 Grace Hopper "SuperChip"（大規模なAIアプリケーション専用に作成されたCPUとGPUの組み合わせ）がフルプロダクションに入力したことを発表しました。 528 GPUテンソルコアを持ち、最大480GBのCPUメモリと96GBのGPUメモリをサポートし、GPUメモリ帯域幅の最大4TB/秒を備えています。

写真

図8。NVIDIAのGH200「Grace Hopper」AI SuperChip [5]

GH200は、「ホッパー」に基づいており、Nvidiaの「Grace」CPUプラットフォーム（両方ともコンピューターパイオニアGrace Hopperにちなんで名付けられた）と組み合わされており、NvidiaのNVLinkチップからチップ（C2C）相互接続テクノロジーを介して単一のダイになります。 Nvidiaは、この組み合わせが、人工知能と機械学習アプリケーションのトレーニング（モデルの作成）と推論（ランニングモデル）の両方を大幅に加速することを期待しています。

NVIDIAのAccelerated Computingの副社長であるIan Buck氏は、次のように述べています。「Grace Hopper SuperChipがフルプロダクションであるため、グローバルメーカーはすぐに加速されたインフラストラクチャを提供することができ、独自の独自のデータを活用する生成的なAIアプリケーションを構築および展開することができます。 GH200は、GPUの合計システムメモリ帯域幅の30倍も提供します。さらに、GH200は、NVIDIA HPC SDK、NVIDIA AI、NVIDIA Omniverseなど、すべてのNVIDIAソフトウェアプラットフォームを実行できます。 Nvidiaはまた、このCPU/GPUの組み合わせチップをDGX GH200と呼ばれる新しいスーパーコンピューターに組み込むことを発表しました。これにより、256 GH200チップの組み合わせ機能を活用して単一のGPUとして実行し、パフォーマンスと144メガバイトの共有メモリの144メガバイトを提供します。 DGX GH200は、生成言語アプリケーション、推奨システム、およびデータ分析のために、巨大な次世代AIモデルをトレーニングできます。 NvidiaはDGX GH200の価格を開示していませんが、昨年出荷されたDGX H100に基づいている場合、8セットのH100 GPUを搭載した8U GPUサーバーキャビネットは約20万ドルです。 AnandTechによると、DGX GH200コンピューターの価格は「8桁（USD）レベルに簡単に到達しています。」

NvidiaやCerebrasなどのベンダーからの継続的なハードウェアの進歩のおかげで、ハイエンドクラウドAIモデルは、時間の経過とともにより能力が高まり、以前よりも速くすることができます。内部テストによると、DGX GH200システムは、大量のメモリを必要とするAIワークロードの処理に関して、DGX H100よりも優れたパフォーマンスを示し、たとえば、GPT3モデルトレーニングのメモリ容量を2〜6回使用できます。より速く、そしてグラフニューラルネットワークの処理速度でさえ、5倍もはるかに高速です。

GH200だけの観点からは、LLMの分散トレーニングをある程度サポートすることができ、FL+LLMをより実現可能にします。ただし、記事の冒頭での議論に戻ると、FLの当初の意図は、多数の分散型一般的なデバイスを使用して、一方では散在するクライアントリソースを効果的に利用でき、他方では、各クライアントのデータプライバシーニーズを満たすことができます。これらのクライアントにGH200をインストールすることを要求することは明らかに非現実的であり、このようなGPUのコスト消費はFLの元の意図と一致していません。

さらに、一部の研究者は、GH200自体が大規模なモデルのアプリケーションとプロモーションに大きな影響を与えないと考えています[11]。彼らは、コンピューティングパワーレベルでは、単一のGHチップとH100チップFP8のフローティングポイントコンピューティングパワーに違いはないと分析しました。内部テストにおけるGH200のより良いパフォーマンスは、その保存によるものです。 DGX GH200の内部GPUとCPUは、DGX H100のそれとは異なる方法で接続されており、その高速アクセスストレージ容量は大幅に改善できます。ただし、クラスターパフォーマンスの改善には、主に3つの主要な要素、コンピューティングパワー自体、ネットワーク、ストレージが含まれます。したがって、従来のGPT3やGPT4などの主流の大規模モデルでは、DGX H100クラスター（NVLinkネットワーク）とDGX GH200システムの間に明らかな違いはありません。

H100に関しては、大規模なモデルトレーニングのパフォーマンスを分析するレポートがあります[12]。 2つのMLPERFベンチマークレビューの最新データの中で、NVIDIA H100チップセットは、人工知能コンピューティングパワーパフォーマンスのテストですべてのグループに記録を設定し、すべてのテストを完了できる唯一のハードウェアプラットフォームでもあります。 NVIDIAおよびGPUクラウドコンピューティングプラットフォームCoreWeaveによって提出されたデータは、このテストの業界標準を設定します。 896 Intel Xeon 8462Y+プロセッサと3584 NVIDIA H100チップの合計アクションにより、GPT-3ベースの大手言語モデルトレーニングタスクを完了するのに10.94分しかかかりませんでした。 Bert-Largeモデルのトレーニングでは、H100とCoreWeaveはデータを0.13分の極端にスワイプし、64枚のカードの場合、テストデータも0.89分に達しました。

4。その後の開発に関する議論

この記事では、アルゴリズムの改善、ハードウェア開発、分散トレーニングのためのアーキテクチャ、フェデレーション学習など、FL+LLMに関連するいくつかの方法について説明します。その中でも、FEDLLMはFL+LLMと最も一致するはずですが、実用的で技術的に完全なFL+LLMとはほど遠いものです。

DeepSpeedは、分散トレーニングと混合されたトレーニングを目的としたトレーニング速度を改善し、分散トレーニングのシナリオを対象としています。 FLの場合、各コンピューティングノードが持っているデータの量はデバイス自体に関連しており、異なるコンピューティングノードに同様のデータがあることを確認することは困難です。さらに、FLのコンピューティングノードは携帯電話、タブレットなどであり、一般に中央サーバーとのリモート接続状態にあり、接続の安定性と通信コストは比較的低いです。したがって、deepspeedをFL+LLMに直接適用することは依然として非常に困難です。

Loraは現在非常に人気のある微調整方法であり、より優れた微調整方法が継続的に提案されています。アルゴリズムの改善により、FLクライアントノードがローカルデータに基づいてモデルをトレーニングする可能性があります。ハードウェアの現在の開発について議論したように、ハードウェア自体のパフォーマンスは常に改善されていますが、FLのアプリケーションシナリオでは、携帯電話やタブレットがそのようなハードウェア条件を持つことは非常に困難です。

FL+LLMに関連するいくつかの現在の研究の分析に基づいて、Federated LearningサポートLLMには、解決する必要がある多くの問題がまだあると感じています。 Fedllmを含めて、実際には、小さなストレージ容量、処理パフォーマンスの低下、およびこれらの条件が最も典型的なアプリケーションシナリオであるクライアントデバイスを処理する方法については話しませんでした。 FL+LLMの問題に注意を払い、より多くの技術的な詳細と実装可能なソリューションを提供できるより多くの研究者を楽しみにしています。