フィンテックにおける LLM 向けの分散コンピューティングの事例

プラトン再発行

フォロワー： 0

前年、つまり 2023 年は、AI ドメイン分野の進歩という点で明らかに際立った年でした。従来、AI を最大限に活用するには、インフラストラクチャとサポートへの多額の投資が必要であると常に考えられてきました。これほど明確になったことはありません
昨年と同様、生成 AI の出現のおかげで。 Gen AI より前の従来の AI テクノロジーのほとんどは、少数の GPU と RAM 上で適度にパフォーマンスを発揮していました。 Open AI による GPT-3 のリリースと、さらに大規模な
オープンソースモデルの数。これらの大規模言語モデルはあらゆる意味で大規模であり、高性能 GPU の形で大量の計算リソースと RAM の点で大規模なメモリを必要としました。特に金融サービスセクターはトップとして認識されています
このテクノロジーの恩恵を受ける人。この分野でデータ、特にテキストデータの分析と処理に使用されるリソースの数は、LLM を使用して大幅に最適化できます。実際、最も有用であるのはオープンソース LLM です。
この分野。これには複数の理由があります

(a) データの重要性とそのセキュリティ: 金融セクターのかなり多くのデータは機密性の高いものです。彼らは安全に確保され、一般の人の立ち入りは禁止されています。これらのデータが漏洩する可能性があると、ビジネスに重大な問題を引き起こす可能性があります。それは主張を成す
特に重要で機密性の高いユースケースでは、独自のソリューションではなく、オープンソースまたは内部ソリューションを対象とします。

(b) LLM のカスタマイズ: この分野のユースケースのほとんどでは、正しい応答を提供するために、企業ごとに異なる非常に特殊なデータセットを使用して LLM モデルをカスタマイズする必要があります。

金融分野におけるオープンソース LLM の適用可能性が高まっていることは明らかですが、同時に LLM ソリューションの基本的な実装には多くの課題があります。両方の計算能力の観点から必要となる膨大な数のリソース
そしてメモリはコストがかかるだけでなく、サポートするのも困難です。ビッグサイエンスプロジェクトが発表した最近のマイルストーンである BLOOM のケースを考えてみましょう。BLOOM は、176 の自然言語と 46 のプログラミング言語をサポートできる 13 億のパラメーターを備えたモデルです。一方で一般の人は
これらの 100B 以上のパラメーターモデルにアクセスしやすくなったことで、その使用が容易になりましたが、それに伴うメモリと計算コストの高さという課題は依然として残っています。特に、OPT-175B や BLOOM-176B などのモデルは、推論のために 350 GB を超えるアクセラレータメモリを必要とし、
さらに微調整します。したがって、このような LLM を実際に利用するには、多くの場合、複数のハイエンド GPU またはマルチノードクラスターが必要になりますが、コストが高いため、多くの研究者や実務者にとってアクセスが制限されます。

これにより、彼らが言うように、まったく異なる見通しをまとめてテストする必要が生じます。
既成概念にとらわれない考え方.

クライアント – サーバーのアプローチ

このため、考えられる解決策の 1 つとして、LLM の分散コンピューティング設定が必要になります。私たちはすでにクラウドやエッジコンピューティングなどの通常の分散コンピューティングシステムを使用しているため、これは理にかなっています。これにより、複数のメンバー間のコラボレーションが容易になります。
インターネット上で大規模な言語モデルの推論と微調整を目的としたユーザー。分散ネットワークの参加者は、サーバー、クライアント、またはその両方の役割を引き受けることができます。サーバーは、通常、モデルレイヤーのサブセットをホストする責任があります。
Transformer ブロック、およびクライアントからのリクエストの管理。クライアントは、パイプライン並列の連続したサーバーのチェーンを形成して、モデル全体の推論を実行できます。推論を超えて、パラメータ効率を使用して微調整アクティビティに従事できます。
アダプターなどのトレーニング方法、またはレイヤー全体をトレーニングすることによって。トレーニングされたサブモジュールはモデルハブで共有でき、他のユーザーが推論やさらなるトレーニングに利用できます。これは、この共同作業における既存の 100B 以上のモデルの効率的な実行を示しています。
この設定は、動的量子化、低遅延接続の優先順位付け、サーバー間の負荷分散などのいくつかの最適化によって支援されます。これについてもう少し詳しく説明しましょう。

設計 および 技術概要

大規模な言語モデルの実際のアプリケーションは、推論と下流タスクへのパラメータ効率の高い適応という 2 つの主なシナリオに大別できます。分散ネットワークの設計の概要を説明し、それがどのように効果的に行われるかを説明したいと思います。
両方のシナリオを管理し、システムユーザー間でのトレーニング済みアダプターのシームレスな共有を促進します。

10 億スケールのモデルの推論 : トークン生成プロセスでは、クライアントはモデルのトークン埋め込みをローカルに保存します。これは通常、総パラメータ数のごく一部を構成し、最新のラップトップの RAM に快適に収まります。
サーバーとワークステーション。クライアントはサーバーに依存して Transformer ブロックを実行します。各サーバーは複数の連続したブロックをホストし、その数は利用可能な GPU メモリによって決まります。各推論セッションの前に、クライアントは次のことを確立します。
すべてのモデル層を集合的に包含するサーバーのチェーン。アクティブなセッション中、クライアントはローカルの埋め込み層を利用してプレフィックストークンの埋め込みベクトルを取得し、これらのベクトルをサーバーに送信し、更新された表現を受信します。
最終ブロックの出力を取得した後、クライアントは次のトークンの確率を計算し、このプロセスを繰り返します。サーバーは後続の推論ステップのために過去のクライアント入力からのアテンションキーと値を保持し、クライアントは過去の入力を保存します
サーバーに障害が発生した場合やオフラインになった場合に、迅速な交換を容易にするために各サーバーに送信されます。
下流タスクのトレーニング: 大規模言語モデル (LLM) は、単純なプロンプトエンジニアリングで多くの問題に優れていますが、最適な結果を達成するには、多くの場合トレーニングが必要です。すべてのモデルパラメータの更新を伴う従来の微調整戦略
下流のタスクでは、広範なハードウェア要件があるため、非常に大規模なモデルでは非現実的になります。たとえば、BLOOM-176B を微調整するには、モデル、勾配、オプティマイザーの状態に対応するために 3 TB 近くの GPU メモリが必要になります。対処する
この課題に対処するために、NLP コミュニティは、事前トレーニングされたモデルのパラメーターのほとんどを保存する、パラメーター効率の高い微調整方法を考案しました。既存のパラメーターのサブセットを選択するアプローチもあれば、トレーニング可能な重みを追加してモデルを強化するアプローチもあります。
メモリ要件が低いにもかかわらず、これらのパラメーター効率の高いアプローチは、多くの場合、フルモデルの微調整と有利に競合し、低データのシナリオではそれを上回るパフォーマンスを発揮します。
分散型微調整: 分散ネットワークにおける微調整の背後にある基本的な考え方は、クライアントがトレーニング済みパラメーターを所有し、サーバーが元の事前トレーニング済みレイヤーをホストするというものです。サーバーはレイヤー全体でバックプロパゲーションを実行し、勾配を返すことができます。
アクティベーションに関しては、サーバー側のパラメーターは更新されません。これにより、クライアントは干渉することなく、同じサーバーのセットで異なるトレーニングタスクを同時に実行できます。

内部構造と最適化

分散推論ではパフォーマンスに関する考慮事項が最も重要であり、これには 5 つの重要な側面が含まれます: 計算速度 (XNUMX 年前のゲーム GPU と新しいデータセンター GPU の比較)、ノード距離による通信遅延 (大陸間とローカル)、
帯域幅に起因する通信遅延 (10 Mbit/s 対 10 Gbit/s)。 GeForce RTX 3070 のようなコンシューマーグレードの GPU でさえ、BLOOM-176B の完全な推論ステップを XNUMX 秒未満で実行できる能力を誇っていますが、課題は GPU メモリの制約にあります。
効率的なソリューションが必要です。これに対処する 1 つの方法は、パラメータストレージを最適化するために量子化を採用し、通信速度を向上させるために動的サーバーの優先順位付けを採用することです。

コンシューマ GPU の使用: 各サーバーが少なくとも 16 GB の CPU RAM と 8 GB の GPU メモリを備えているという事実を考慮すると、主な目的はモデルのメモリフットプリントを最小限に抑え、各デバイスがより多くの Transformer に対応できるようにすることです。
ブロック。 176B パラメータを持つ BLOOM の場合、352 ビット精度で 16 GB の GPU メモリが必要ですが、動的ブロック単位量子化を通じて隠れ状態を圧縮し、混合行列分解を使用して重みを 8 ビット精度に減らすことでこれを最適化できます。
これにより、必要なノード数が大幅に削減され、レイテンシが効果的に半分になり、障害の可能性が最小限に抑えられます。
圧縮 コミュニケーション バッファー:
パイプライン並列通信の前に隠れ状態に対して動的ブロックワイズ量子化を使用することで、生成品質を損なうことなく帯域幅要件を半分に抑えることができます。
モデルの重みを圧縮する: 行列乗算に 8 ビット混合行列分解を利用することで、品質を犠牲にすることなくメモリ使用量を約半分に削減します。
インターネット上でのコラボレーション: ノードが参加、離脱、または失敗した場合でも、信頼性の高い推論とトレーニングを保証するため。 Hivemind ライブラリを利用して、分散トレーニングやサーバーとクライアントのカスタムフォールトトレラントプロトコルを利用できます。

民主化とプライバシーの問題

ブロックチェーンからインスピレーションを得て、GPU リソース (サーバー) を供給するピアと、推論や微調整にこれらのサーバーを利用するピアの間の潜在的な不均衡に対処できます。これに対処するには、インセンティブのシステムを導入することが考えられます。実行中の仲間
サーバーは特別なポイントを獲得し、優先度の高い推論や微調整、その他の報酬と引き換えることができます。このアプローチは、積極的な参加を促進し、バランスの取れたネットワークを維持することを目的としています。現在のアプローチの限界として認識されているのは、次のような可能性があることです。
モデルの初期層を提供するピアが入力トークンを回復するために入力を利用する可能性があるというプライバシー上の懸念。これに対処する 1 つの方法は、機密データを扱うユーザーに対して、クライアントを信頼できるサーバーに制限するか、隔離された群れを確立することをお勧めします。
ただし、セキュアなマルチパーティコンピューティングや NVIDIA のプライバシー保護ハードウェアなど、プライバシーを強化するテクノロジを検討することはできます。

まとめ

このブログを通じて私の目的は、AI の分散コンピューティングについての私の見解を紹介し、分散コンピューティングが必要な理由と、分散コンピューティングを実装するための 1 つの可能なアプローチについての簡単な技術概要の両方を説明することです。これを実現するための新しいアイデアについては喜んで議論します。検討中
今後数年のうちに金融分野で AI が大規模に活用されるだろうという事実を考えると、新しいリソースを作成する前に、現在のリソースを最適に活用する方法を考え始める必要があります。もう 1 つの目的は、大規模な言語モデルへのアクセスを民主化することです。
これまでは困難または法外なコストがかかっていた、より広範囲のアプリケーション、研究、研究課題が可能になります。