この記事は、Dylan Patel と Gerald Wong によるコラム SemiAnalysis から編集されたものです。少し前に、Dylan Patel が Google の社内書簡「We Have No Moat, And Bothher Does OpenAI」に関するニュースを発表しました。
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
GPT-4「錬金術」ガイド: MoE、パラメータ量、トレーニングコスト、推論の秘密
原文: 象を拾う
出典： 海外ユニコーン企業
著者: ディラン・パテル、ジェラルド・ウォン
编译：Haina、wenli、Cage
編集者: シキ
この記事は、Dylan Patel と Gerald Wong によるコラム SemiAnalysis から編集されたものです。少し前に、Dylan Patel が Google の社内書簡「We Have No Moat, And Bothher Does OpenAI」に関するニュースを発表しました。
GPT-4 は、科学と工学の革新が深く融合した結果です。途中には無数のトリックが含まれています。外の世界にとって、GPT-4 の構造を理解できれば、それは「錬金術のレシピ」を手に入れるようなものです。最強モデルの。このコンテンツでは、GPT-4 アーキテクチャ、トレーニングおよび推論インフラストラクチャ、パラメーター量、トレーニング データ セット、トークン番号、コスト、MoE モデル、およびその他のパラメーターと情報の詳細が詳細に提供されます。
ディランとジェラルドは、OpenAI が GPT-4 のアーキテクチャを公開しない理由は、いわゆる AI の安全性に関する考慮事項のためではなく、このアーキテクチャが簡単にコピーされるためであると考えています (「天才ハッカー」として知られるジョージ・ホッツ)も同様の意見を表明しましたが、George は、GPT-4 はそれぞれ約 1100 のパラメータを持つ 8 つのエキスパート モデルの MoE で構成されていると主張しています。
著者 2 人は、Google、Meta、Anthropic、Inflection、Character.ai、Tencent、ByteDance、Baidu などの企業が、短期的には GPT-4 と同等かそれ以上の強力なモデル機能を備えるようになるだろうと予測しています。 GPT-4 のアーキテクチャは「簡単にコピーできる」にもかかわらず、彼らの見解では、OpenAI には最も耐久性のある堀、つまり最大数のエンド ユーザー、優れたエンジニアリング人材、そしてモデルの世代間の変更における先行者利益が備わっています。
フレンドリーなリマインダー: 記事内のデータは、元の著者の複数の当事者による収集と調査から得たものであり、OpenAI によって確認されていません。Dylan Patel の調査は一般に信頼性が高いと考えられており、GPT-4 の良い参考資料として使用できます。徹底的な研究資料。さらに、OpenAI と Google を除けば、複雑な MoE フレームワークのトレーニングと推論を得意とする科学者が現在不足しているため、記事内の再現されやすい見解は「主要当事者」であると疑われる可能性があると考えられます。現在の GPT-4 は MoE の第 1 世代にすぎず、OpenAI が出した最終的な答えではなく、そのプロセスにおける多くの経験は他のチームには得られず、これらの経験は間違いなく OpenAI 独自の利点となるでしょう。
以下にこの記事の目次を記載しますので、要点と合わせて読むことをお勧めします。
👇
01 概要
02 モデル構造
03 データセット
04 パラレル戦略
05 研修費用
06 萌え
07 推理
08 インフラと推論コスト
09 マルチクエリアテンションメカニズム
10 連続バッチ
11 投機的デコード
12 ビジョンマルチモーダル
01.概要
OpenAI のエンジニアリング能力と彼らが作成したものは驚くべきものですが、それはソリューションが克服できないという意味ではありません。彼らの解決策は非常に洗練されており、一連の複雑な要素の考慮とバランスも必要であり、モデル規模の拡大はその一部にすぎません。 **OpenAI の最も耐久性のある堀は 3 つの側面から来ています。1 つ目は、実際のユーザーが最も多いこと、2 つ目は、優れたエンジニアリングの人材がいること、そして最後に、将来のモデル開発においても最先端を維持し続ける可能性が高いことです。 **
GPT-4 が特定のアーキテクチャを選択した理由を理解することは貴重であるだけでなく、最近では、A100 での GPT-4 のトレーニングと推論のコスト、および次世代モデル アーキテクチャで H100 を使用する方法についても概説します。
GPT-3 から GPT-4 へ、OpenAI はモデルのサイズを 100 倍に拡大したいと考えていますが、このプロセスの中心となるのは当然のことながらコストの問題です**。高密度トランスフォーマーは、OpenAI GPT-3、Google PaLM、Meta LLaMA、TII Falcon、MosaicML MPT などの一般的に使用されるモデル アーキテクチャです。現在、少なくとも 50 社がこのアーキテクチャを使用して LLM をトレーニングしています。これは、アーキテクチャの良い例です。 、ただし、そのスケーラビリティは非常に限られています。
AI Brick Wall は、GPT-4 がリリースされる前に、この記事でモデルのトレーニング コストについて説明しました。トレーニング コストの観点から見ると、密なモデル (密なトランスフォーマー) は独自の「AI レンガの壁」に直面しようとしています。上位レベルのアーキテクチャ上の取り組みを行ってください。
しかし、過去 6 か月間で、トレーニング費用は問題ではない可能性があることに気づきました。モデルのトレーニングに何百万ドル、さらには何億ドルも費やすのは馬鹿げているように思えますが、テクノロジー大手にとっては実際には些細なことです。大規模なモデルは設備投資プロジェクト (設備投資項目) であり、モデルが大きければ大きいほど、より良い結果が得られます。唯一の制限要因は、人間がモデルの拡張中にフィードバックを提供し、モデル アーキテクチャを変更するのに十分な能力と時間を持っているかどうかです。規模。
メタは毎年「メタバース」に160億ドル以上を投資し、グーグルは新たなプロジェクトの試みに約100億ドルを費やし、アマゾンはAlexaに500億ドル以上を費やし、仮想通貨は「価値のないもの」に1000億ドル以上が無駄にされている。社会全体が、さまざまな方法で製品化できる大規模モデルをトレーニングできるスーパーコンピューターの開発に 1,000 億ドル以上を費やすことになります。複数の国や企業が大型模型での訓練活動**を繰り返すことになるが、これは新たな「宇宙における軍拡競争」**である。以前の「資源の無駄」と比較して、人間のアシスタントや自律エージェントの出現により、本当の価値は短期間で実現されます。
しかし、今後数年間で、Google、Meta、OpenAI、Microsoft、その他の企業は、モデルをトレーニングするためのスーパーコンピューターの構築に 1,000 億米ドル以上を費やすことになります。
モデルのサイズを拡大する際のより重要な問題、つまり実際の「AI レンガの壁」は、推論リンクにあります。ここでの目標は、トレーニングのコンピューティング能力を推論のコンピューティング能力から切り離すことであるため、デプロイされるモデルについては、DeepMind の Chinchilla-optimal を超えてトレーニングすることが理にかなっています。 (注意: トレーニング データの量を増やしてモデルを過学習させるのは、小規模モデルの能力を高め、推論のコストを削減するための戦略です。) これが、スパース モデル アーキテクチャ (スパース モデル アーキテクチャ) が使用される理由です。このアーキテクチャに基づく理由は、すべてのパラメータをアクティブにする必要があるわけではありません。
推論リンクの問題の本質は、ユーザーとエージェントにモデルを展開するコストが高すぎることです。推論のコストはトレーニングのコストよりも数倍高く、この問題を解決することがモデル アーキテクチャとインフラストラクチャの観点からの OpenAI の目標です。
大規模なモデル、特に高密度モデルを使用した推論になると、モデルのサイズが多変量の問題になる可能性があります。 On Device AI - 両刃の剣 この記事では、エッジ コンピューティングの状況について説明しました。簡単に言うと、端末デバイスは大規模な言語モデルの実装に必要なスループットとメモリ帯域幅を決して確保できず、たとえ帯域幅が十分であったとしても、エッジ デバイスのハードウェア コンピューティング リソースの利用効率は非常に低くなります。データセンターも同様の問題に直面しています。
データセンターやクラウドにとって、コンピューティングリソースの利用は非常に重要です。 (注: 現在、業界における GPU/TPU 使用率の上限は約 50% です。) NVIDIA のソフトウェアが広く評価されている重要な理由の 1 つは、NVIDIA が新世代の GPU を継続的に投入する過程で、また、常に更新されています。チップ周辺、チップ間、メモリ間のよりスマートなデータ移動を可能にすることで、FLOPS 使用率の向上を推進するソフトウェアの世代です。
現段階では、LLM 推論のユースケースはほとんどが「ライブ アシスタント」です。これは、ユーザーにとって本当に役立つために十分な高いスループットを達成する必要があることを意味します。人間に例えると、人間の平均読書速度は 1 分あたり約 250 ワードであり、人によっては 1 分あたり約 1,000 ワードに達することもあります。モデルに対応すると、1 秒あたり少なくとも 8.33 トークン、できれば 1 秒あたり 33.33 トークンを出力することになります。つまり、人間のあらゆるニーズを満たすことが可能です。
ただし、メモリ帯域幅の制限により、最新の NVIDA H100 GPU サーバーであっても、数兆個のパラメータを持つ高密度モデル (密モデル) では、数学的にこのスループットを達成することはできません。トークンが生成されるたびに、トークンをメモリからチップにロードする必要があり、その後、このトークンが再度送信されて次のトークンが生成されます。さらに、アテンション メカニズムを実装するための KV キャッシュ (KV Cache) にも追加の帯域幅が必要です。
上の図は、単一のユーザー LLM を十分に高いスループットで処理するために必要なメモリ帯域幅を示しています。この図から次のことがわかります。
• H100 の 8 倍の帯域幅でも、1 兆パラメータ規模の高密度モデルを 1 秒あたり 33.33 トークンの速度で処理することはできません。
• さらに、8x H100 の FLOPS 使用率は、1 秒あたり 20 トークンの場合でも 5% 未満であり、推論コストが非常に高くなります。
実際、今日の 8 ウェイ テンソル並列化 H100 システムの場合、推論制約は約 3,000 億のフィードフォワード パラメーターです。
ただし、OpenAI は、A100 と 1 兆を超えるパラメータを持つモデル を使用して人間の読み取り速度を達成しており、1000 トークンあたり 0.06 ドルという低価格で広く入手可能であり、これはまさしくそのスパース アーキテクチャだからこそ可能です。
次に、GPT-4 モデル アーキテクチャ、トレーニングと推論のインフラ、パラメーターの数、トレーニング データ セットの構成、トークンの数、レイヤーの数、並列戦略、マルチモーダル ビジュアル エンコーダー、一連の異なるエンジニアリング設計の背後にあるものなど、考慮事項、実装テクニック、および OpenAI が大規模モデル推論のボトルネックに対処する方法。
02. モデルの構造
GPT-4 の規模は GPT-3 の 10 倍以上です、約 1.8 兆個のパラメータがあり、これらのパラメータは 120 のトランス層に分散されていると推定されます。比較のために、GPT-3 のパラメータは以下のとおりです。約17500億です。 (注: GPT-3 のトランス層は 12 層のみで、層数は GPT-4 の 1/10 です。)
コストを管理するために、OpenAI は MoE モデルを使用することを選択しました。 OpenAI はモデル内で 16 人の MLP.2 タイプのエキスパートを使用しており、各エキスパートには約 1,110 億のパラメーターがあります。これらのエキスパート モデルのうち 2 つは、各前方パスで呼び出されます。
さらに、アテンション メカニズムでは約 550 億の共有パラメータが使用されます。
各前方推論 (トークンの生成) では、約 2,800 億のパラメーターと 560 TFLOP のみが使用されます。一方、密なモデルが純粋に使用される場合、各前方推論には約 1.8 兆のパラメーターと 3,700 TFLOP が必要です。
03. データセット
GPT-4 は約 13 兆のトークンでトレーニングされました。これは、CommonCrawl RefinedWeb に約 5 兆の高品質トークンが含まれていることを考慮すると妥当です。参考までに、DeepmindのChinchillaモデルとGoogleのPaLMモデルはそれぞれ約1.4兆トークンと約0.78兆トークンでトレーニングされており、PaLM2は約5兆トークンでトレーニングされたと言われています。
OpenAI が GPT-4 をトレーニングするために使用するデータセットは、13 兆個の一意のトークンではありません。逆に、高品質のトークンが不足しているため、このデータセットには複数のエポックが含まれています。テキストベースのデータには 2 エポック、コードベースのデータには 4 エポックがあります。 (注: これは、モデルによって何度も学習された高品質のテキストとコードを指します。) これは、チンチラ最適化 (モデルは 2 倍のトークンでトレーニングする必要がある) の達成にはほど遠いですが、これも次のことを示しています。ネットワークが簡単であること トークンを取得するだけでは十分ではありません。実際にネットワーク上に存在する高品質のテキスト トークンは現在利用可能なものの 1000 倍、音声とビデオのトークンはさらに多くなるはずですが、これらのトークンの収集は Web スクレイピングだけでは達成できません。残念ながら、OpenAI の RLHF データに関する情報はあまり見つかりませんでした。
事前トレーニング段階では、コンテキストの長さ (seqlen) は 8k です。 GPT-4 の 32k コンテキスト バージョンは、事前トレーニング後の 8k 微調整に基づいて実装されます。
クラスター上のバッチ サイズは数日間徐々に増加しましたが、最終的に OpenAI は 6,000 万ものバッチ サイズを使用しました。もちろん、すべてのパラメータがすべてのパラメータを参照するわけではないため、これはエキスパートあたり 750 万のバッチ サイズにすぎません。
04. パラレル戦略
すべての A100 GPU での並列処理は非常に重要です。
OpenAI は 8 ウェイ (8-way) のスケール テンソル並列処理 (Tensor Parallelism) を使用しますが、8 ウェイ (8-way) になっている理由は、これが NVLink の制限であるためです。さらに、OpenAI は 15 ウェイ (15 ウェイ) パイプライン並列戦略を使用していると聞きました。理論的には、データ通信と計算時間を考慮すると 15 ウェイは多すぎますが、メモリ容量によって制限される場合は妥当でもあります。
パイプライン並列処理とテンソル並列処理だけを使用する場合、FP16 では各 GPU のパラメータに約 30GB が必要で、KV キャッシュと KV オーバーヘッドを考慮すると、OpenAI で使用される GPU のほとんどが 40GB A100 である場合、このアーキテクチャは理論的にも合理的です。 OpenAI は、ZeRo ステージ 1、ブロックレベルの FSDP、またはハイブリッド共有データ並列処理を使用する場合があります。
フルモデルの FSDP が使用されない理由は、通信コストが高いことが考えられます。 OpenAI は、おそらくすべてのノードではないものの、ほとんどのノード間に高速ネットワークを備えていますが、少なくとも一部のクラスターは他のクラスターよりも接続帯域幅がはるかに低いと考えられます。
OpenAI がこのような高いパイプライン並列処理で巨大なバブルをどのように回避するのかは不明です。おそらく彼らはコストを負担しただけだろう。
05. トレーニング費用
OpenAI は、90 ～ 100 日間のトレーニングで約 25,000 個の A100 GPU 上で GPT-4 のトレーニングに約 2.15e25 FLOPS を使用し、最大コンピューティング能力使用率は約 32% ～ 36% でした。 **
この極端に低い使用率は、チェックポイントの再起動を必要とする多数の障害が原因の 1 つであり、前述のバブルに多くのコストがかかっています。
もう 1 つの理由は、非常に多くの GPU にわたる all-reduce は非常にコストがかかることです。特に、クラスタが実際には比較的弱いネットワーク接続 (クラスタの異なる部分間の 800G/1.6T ノンブロッキング接続など) を備えた多数の小さなクラスタで構成されていると考えられるが、これらの一部は 200G/400G の速度でしか接続できないと思われる場合は特にそうです。
クラウド上のコストが A100 あたり 1 時間あたり約 1 ドルだとすると、このトレーニング セッションだけで約 6,300 万ドルになります**。これには、すべてのトライアル、失敗した試行、およびデータ収集、RLHF、スタッフなどにかかるその他のコストは含まれません。これらの要素を考慮すると、実際のコストはさらに高くなります。さらに、チップ構成、ネットワーク機器、データセンターを完成させ、設備投資（Capex）を負担し、それらをレンタルするチームが必要であることも考慮する必要があります。
現在、事前トレーニングは約 8,192 台の H100 を使用して約 55 日で完了でき、総コストは 2,150 万ドルで、各 H100 GPU のコストは 2 ドル/時間です。
年末までに 9 社がさらに多くの H100 GPU を搭載すると予想されます。おそらく、これらの H100 がすべてモデルのトレーニングに使用されるわけではありませんが、これらの企業は間違いなく大型モデルを採用し、重要なプレーヤーになるでしょう。 Meta は年末までに 100,000 台を超える H100 を保有すると予想しており、その大部分は推論用に自社のデータセンターに導入される予定ですが、最大の単一クラスターには 25,000 台を超える H100 GPU が搭載される予定です。 (注: Meta のコンピューティング リソースにより、LLaMA の能力は、オープンソースおよび民間展開にとって重要な変数に進化することになります。) 多くの企業が、今年末までに GPT-4 と同じ能力を持つモデルをトレーニングする予定です。
06.MoE
MoE は、推論中のパラメータの数を減らす効果的な方法であると同時に、パラメータの数も増加するため、トレーニング トークンごとにより多くの情報をエンコードするのに役立ちます。十分な高品質のトークンを入手するのは非常に難しいため、MoE アーキテクチャを選択する必要があります。 OpenAI が本当に Chinchilla-Optimal を実装したい場合は、今すぐ 2 倍の数のトークンをトレーニングする必要があるからです。
そうは言っても、OpenAI にはいくつかのトレードオフがあります。たとえば、すべてのトークンを生成するときにモデルのすべての部分が使用されるわけではないため、推論中に MoE を扱うことは非常に困難です。これは、他の部分が使用されている間、一部の部分が休止状態になる可能性があることを意味します。これは、ユーザーにサービスを提供する際の使用率に重大な影響を与える可能性があります。
研究者らは、64 ～ 128 人の専門家を使用した方が、16 人の専門家を使用した場合よりも優れた損失結果が得られたことを証明しましたが、これは単なる研究です。専門家の数を減らす理由はいくつかあります。 OpenAI が 16 人の専門家を選んだ理由の 1 つは、より多くの専門家がいると一般化して収束を達成することが困難になるためです。このような大規模なトレーニングの実行を考慮して、OpenAI は専門家の数をより控えめにすることを選択しました。
また、使用するエキスパートの数を減らすことは、推論アーキテクチャにとって役立ちます。 MoE 推論アーキテクチャに移行する場合、さまざまな複雑なトレードオフが存在します。基本的な LLM 推論のトレードオフから始めて、OpenAI が直面した問題とその選択について探ってみましょう。
07. 推理
このパートでは、私たちが連絡を取ったすべての LLM 企業が、NVIDIA の FasterTransformer 推論ライブラリは非常に悪く、TensorRT はさらに悪いと考えていることをまず指摘したいと思います。 Nvidia のテンプレートを使用して変更する機能がなければ、つまり独自のソリューションを最初から作成することになりますが、NVIDIA は LLM 推論のニーズに適応するためにできるだけ早くこの問題を解決する必要があり、そうしないと実際にはオープン ツールになってしまいます。サードパーティのハードウェアのサポートを追加します。大規模なモデルは今後もますます登場しており、NVIDA が推論においてソフトウェアの利点を提供できず、カーネルを依然として手書きする必要がある場合、AMD の MI300 やその他のハードウェアの市場はさらに大きくなるでしょう。
LLM の推論リンクには 3 つの重要な要素があり、主に使用されるチップの数に関係します。
1. レイテンシー
モデルは妥当な遅延以内に応答する必要があります。ユーザーは、チャット アプリケーションで出力の受信を開始するまでに数秒待つことを望んでいません。入力および出力トークンの処理時間は変動する可能性があります。
2. スループット
モデルは 1 秒あたり特定の数のトークンを出力する必要があります。人間による使用量は 1 秒あたり約 30 トークンであり、他のさまざまなユースケースではスループットがそれよりも高くなる場合もあれば、低くなる場合もあります。
3. 利用率（Utilization）
モデルを実行するハードウェアは高い使用率を達成する必要があり、そうしないとコストが法外に高くなります。待ち時間が長く、スループットが低い、より多くのユーザー要求をグループ化することで使用率を高めることは可能ですが、これにより難易度が高くなります。
LLM 推論は主に、メモリ帯域幅と計算という 2 つの主要な要素のバランスを取ることを目的としています。
簡単に言えば、各パラメーターは、それに関連付けられた 2 つの FLOP とともに読み取る必要があります。したがって、ほとんどのチップ (たとえば、H100 SXM のメモリ帯域幅は 3 TB/s しかありませんが、FP8 は 2,000 TFLOP/s です) の比率は、バッチサイズ 1 での推論では完全にアンバランスになります。 1 人のユーザーのみを処理する場合、つまりバッチ サイズが 1 の場合、トークン生成ごとに各パラメーターをストリーミングするために必要なメモリ帯域幅が推論時間の大部分を占め、計算時間はほとんど無視できます。
大規模なモデルを複数のユーザーに拡張できるようにするには、バッチ サイズが 1 より大きい必要があり、複数のユーザーがパラメーター読み取りコストを共有します。たとえば、バッチ サイズが 256 または 512 の場合、読み込まれるメモリの各バイトは 512 FLOP/s または 1024 FLOP/s に相当します。この比率は、H100 の FLOPS に対するメモリ帯域幅の比率に近くなります。使用率を高めるのに役立ちますが、待ち時間が長くなるという欠点があります。
モデルのサイズは複数のチップに適合する可能性があるため、メモリ容量が LLM 推論の主なボトルネックであると多くの人が考えていますが、この見方には問題がある可能性があります。大規模なモデルの推論には複数のチップが必要で、メモリ容量が増えると適応されるチップが少なくなりますが、レイテンシを短縮し、スループットを向上させるには、実際には必要以上のチップを使用する方が良いです。また、より大きなバッチ サイズを使用すると、使用率を継続的に高めることができます。
アプリケーションが可能な限り低いレイテンシを必要とする場合、より多くのチップが必要となり、経済的にできる限り多くの方法でモデルを分割します。バッチ サイズが小さいほどレイテンシは低くなりますが、バッチ サイズが小さいと MFU [使用率] も低下し、その結果、トークンあたりの総コスト (チップ秒またはドル) が高くなります。
アプリケーションがオフライン推論を必要とし、遅延が問題にならない場合、主な目標はチップあたりのスループットを最大化する (つまり、トークンあたりの総コストを最小限に抑える) ことです。バッチ サイズを大きくすると一般に MFU [使用率] が向上するため、バッチ サイズを増やすことが最も効率的ですが、小さなバッチ サイズでは効果的ではない特定のパーティショニング戦略は、バッチ サイズが大きくなり効果的になるにつれて大きくなります。
**チップを増やしてバッチ サイズを大きくすると、使用率が高まるためコストが安くなりますが、これにより 3 番目の変数であるネットワーキング時間も発生します。 ** モデルを複数のチップに展開する方法は遅延を効果的に解決できますが、使用率が犠牲になります。
保存時間の重み負荷部分と非注意的計算時間はどちらもモデルのサイズに比例し、チップ数に反比例します。特定のパーティション レイアウトの場合、チップ間通信に必要な時間は、使用されるチップの数に応じてあまり減少しない (またはまったく減少しない) ため、チップの数が増加するにつれて、ボトルネックはますます重要になります。
バッチ サイズとサイズが大きくなるにつれて、KV キャッシュのメモリ要件が爆発的に増加することに気付きました。
アプリケーションが長い注意コンテキスト (長い注意コンテキスト) を含むテキストを生成する必要がある場合、推論時間が大幅に増加します。 500B を超えるマルチヘッド アテンションを持つモデルの場合、アテンションの KV キャッシュは非常に大きくなる可能性があります。バッチ サイズが 512、コンテキスト長が 2048 のモデルの場合、KV キャッシュの合計量は 3TB になります。モデルパラメータのサイズの 3 倍。オンチップ メモリ (オンチップ メモリ) は、トークンが生成されるたびに 1 回ロードされるオフチップ メモリ (オフチップ メモリ) からこの KV キャッシュをロードする必要があります。この間、チップのコンピューティング コアは基本的にアイドル状態。
シーケンスの長さが長いと、メモリ帯域幅とメモリ容量にとって特に問題になります。 16k コンテキストを備えた OpenAI の GPT-3.5 ターボと 32k コンテキストを備えた GPT-4 が高価である理由は、メモリの制約により大きなバッチを処理できないためです。
バッチが小さいほど、ハードウェア使用率が低くなります。また、シーケンスの長さが増加すると、KV キャッシュが肥大化します。 KV キャッシュはユーザー間で共有できないため、個別のメモリ読み取りが必要となり、メモリ帯域幅がさらに減少します。 MQA の詳細については、以下を参照してください。
08. インフラと推論のコスト
インフラ
MoE のアーキテクチャにより、GPT-4 の推論は遅延、スループット、使用率の点で課題に直面します。各トークンのフォワード パスはさまざまなエキスパート モデルにルーティングされる可能性があるため、この場合、特にバッチサイズが大きい場合、低レイテンシー、高スループット、高使用率を達成することは非常に困難です。
OpenAI の GPT-4 アーキテクチャには 16 のエキスパート モデルが含まれており、各転送チャネルには 2 つのルーターがあります。これは、バッチ サイズが 8 の場合、各エキスパートのパラメータ読み取りがバッチ サイズの「1」のみを占める可能性があることを意味します。さらに深刻なことに、これにより、1 人のエキスパートのバッチサイズが 8 になる一方、他のエキスパートのバッチサイズは 4、1、または 0 のみになる可能性があります。
さらに、ルーティング アルゴリズムは、トークンが生成されるたびにフォワード パスを異なる方向にルーティングするため、トークン間のレイテンシとエキスパート バッチ サイズに大きな変動が生じます。つまり、異なるトークンを処理する場合、異なる専門家が異なるタスクに割り当てられる可能性があり、それに応じて計算負荷とバッチ サイズの両方が変化する可能性があります。
推論インフラは、OpenAI が MoE の設計において少数の専門家を選択する際の主な考慮事項の 1 つです。より多くの専門家を使用すると、メモリ帯域幅が推論の大きなボトルネックになります。 OpenAI は、独自の推論クラスターで 4k を超えるバッチ サイズを達成することがよくあります。これは、エキスパート間で最適な負荷分散を行ったとしても、各エキスパートが到達できるバッチ サイズは約 500 にとどまることを意味します。これを実現するには、非常に大量の使用量が必要です。
私たちの理解では、OpenAI は 128 個の GPU のクラスターで推論を実行し、異なるデータセンターや地理的地域にそのようなクラスターが複数存在すると考えられています。推論は 8 ウェイ テンソルと 16 ウェイ パイプラインで並行して実行されます。ノードごとに 8 つの GPU を使用すると、各 GPU のパラメーターは約 130B のみになります。つまり、FP16 では GPU あたり 30GB 未満、FP8/int8 では 15GB 未満になります。これにより、すべてのバッチの KV キャッシュ サイズが大きくなりすぎない限り、40 GB A100 で推論を実行できます。
FP16、FP8、および int8 は異なる数値精度 (精度) 表現であり、メモリとコンピューティング リソースの使用量を削減することで、モデルのトレーニングと推論の効率を向上させるために、ディープ ラーニングの計算プロセスでよく使用されます。
FP16、FP8、int8 はそれぞれ 16 ビット浮動小数点数、8 ビット浮動小数点数、8 ビット整数を指しますが、精度は 32 ビット単精度浮動小数点数 (FP32) よりも低くなります。 ) ですが、メモリとコンピューティング リソースを大幅に削減できます。ディープ ラーニングでのモデルのトレーニングと推論を高速化するために使用します。たとえば、FP16 を使用すると、精度をあまり落とさずに計算時間を半分以上短縮できます。また、int8 を使用すると、精度をあまり落とさずに計算時間を約 4 分の 1 に短縮できます。
なお、低精度の計算を行うとモデルの精度に一定の影響を与える可能性があるため、精度と効率をトレードオフし、状況に応じて最適な精度表現方法を選択する必要があります。特定のタスクの要件。
ネットワーク通信が不規則になりすぎることを回避し、同時に各トークン生成の間に KV キャッシュを再計算する法外なコストを回避するために、さまざまなエキスパートを含むさまざまなレイヤーは、KV キャッシュを共有するために異なるノードに分割されません。
**将来のすべての MoE モデル拡張と条件付きルーティングにとって最大の困難。 KV キャッシュ周りの 120 ルーティング レイヤーの制限に対処する方法です。 **
MoE モデルでは、ブランチあたりのルーティング層の数は 120 層を超えることはできません。そうしないと、KV キャッシュを効果的に処理できません。これは、モデルの推論プロセス中に各ブランチで KV キャッシュを計算する必要があり、計算コストの増加につながるためです。
この問題に対する簡単な解決策は、レイヤー制限 120 に基づいて 15 の異なるノードにスパニング ルートを配置することです。このようにして、計算負荷をさまざまなノードに均等に分散できるため、モデルの効率とパフォーマンスが向上します。ただし、最初のノードはデータのロードと埋め込みを行う必要があるため、推論クラスターのヘッド ノードに配置するレイヤーの数をいかに減らすかが重要です。
さらに、入力データのエンコードおよびデコードのプロセス中に、推論デコードに関するノイズが発生する可能性がありますが、これについては後で詳しく説明します。より重要な問題は、そのようなノイズを信じるべきかどうかを判断することです。これは、ヘッド ノードに含めるレイヤーの数を減らすことが合理的である理由も説明できます。
コストの推論
175B パラメータを持つ Davinchi モデルと比較して、GPT-4 はフィードフォワード パラメータが 1.6 倍ありますが、コストは Davinchi の 3 倍です。これは主に、GPT-4 では大規模なクラスターが必要であり、使用率が低いためです。
GPT-4 8k コンテキスト長 (seqlen) での推論に 128 個の A100 を使用すると、1k トークンあたり約 0.0049 ドルのコストがかかると推測されます。 GPT-4 8k コンテキストでの推論に 128 個の H100 を使用すると、1k トークンあたりのコストは約 0.0021 ドルになります。 (注: GPT-4-8k の現在の価格は、入力トークン 0.03/1k、出力トークン 0.06/1k です。現時点では、OpenAI による推論チップの使用は、著者が推測するほど贅沢なものではありません。この計算は、より低い値として使用できます。 **これらのコストは高い使用率とバッチサイズで計算されていることに注意することが重要です。 **
私たちは、OpenAI が不況時にクラスターをシャットダウンし、それらのノードを他のタスク (小規模なテスト モデルのチェックポイント トレーニングの再開やさまざまな新しい手法の実験など) に再利用すると仮説を立てています。そうすることで推論コストを低く抑えることができますが、そうしないと OpenAI の使用率がさらに低くなり、コスト見積もりが 2 倍以上になる可能性があります。
09. マルチクエリ アテンション メカニズム
マルチクエリ アテンションの使用は非常に一般的ですが、OpenAI も同様であることを強調したいと思います。一般に、必要なアテンション ヘッドは 1 つだけであり、KV キャッシュのメモリ容量を大幅に削減できます。それでも、32k コンテキストを持つ GPT-4 は 40GB A100 では実行できませんし、最大バッチ サイズの 8k にはすでに上限が設定されています。 MQA がない場合、最大バッチ サイズ 8k が大幅に制限され、経済的メリットが大幅に減少します。
10. 連続バッチ処理
ある程度の最大レイテンシを許容し、推論コストを最適化するために、OpenAI は可変バッチ サイズと連続バッチ技術の両方を使用します。このアプローチにより、モデルのパフォーマンスを犠牲にすることなくコンピューティング リソースの使用率が向上し、モデルの推論プロセス中の待ち時間の短縮とスループットの向上が実現できます。連続バッチ処理の概念が理解できない場合は、AnyScale の公式記事「How Continuous Batching Enables 23x Throughput in LLM inference while getting p50 latency」を読む価値があります。 (ピックアップ注: Anyscale が開発した分散コンピューティング フレームワーク Ray は、モデルのインフラ パイプラインで OpenAI によって使用されています。Pickup は以前にこの会社に関する研究を発表しました。)
11. 投機的デコード
OpenAI が GPT-4 モデルの推論タスクに投機的デコーディング技術を使用しているという噂があります。このメッセージの正確性を確信することはできませんが、単純な取得タスクとより複雑なタスクの両方における、トークンごとのレイテンシと分散の一般的な変動は、この手法が可能であることを示唆しているようです。ただし、変数が多すぎるため、この手法が実際に使用されるかどうかを確認することはできません。
LLM の使用は通常、2 つのフェーズに分かれています。
1. プレフィルステージ
このフェーズでは、まずhint()が入力として与えられ、モデルを実行してKVキャッシュと最初の出力ログを生成します。このうち、logits は LLM がタイムステップごとに出力する確率分布ベクトルであり、各トークンの可能性を表すために使用されます。この事前設定フェーズは、並列計算のため通常は高速です。
2. デコード段階
この段階では、出力ログからトークンが選択され、モデルにフィードバックされて次のトークンのログが生成されます。これは、必要な数のトークンが生成されるまで繰り返されます。トークンを生成するには各デコードを順番に計算する必要があるため、小さなバッチで実行する場合、この第 2 段階の演算強度 (つまり、メモリ帯域幅のバイト当たりの計算された FLOP 数) は非常に低くなります (注意: シーケンス計算は計算能力の十分な活用につながりません。 ) したがって、デコードは通常、自己回帰生成で最もコストがかかる部分です。
これが、OpenAI の API 呼び出しでトークンを出力するよりもトークンを入力する方がはるかに低コストである理由です。
投機的デコードの中心となるアイデアは、より小さくて高速なドラフト モデルを使用して、事前にいくつかのトークンをデコードし、それらをバッチとして Oracle モデルにフィードすることです。ドラフト モデルの予測が正しい場合 (つまり、Oracle モデルの予測と一致する場合)、1 つのバッチを使用して複数のトークンをデコードでき、トークンあたりのメモリ帯域幅と時間を大幅に節約できます。
ただし、より大きなモデルがドラフト モデルによって予測されたトークンを拒否した場合、残りのバッチは破棄され、アルゴリズムは標準のトークンごとのデコードに戻ります。投機的デコードを拒否サンプリング スキームと組み合わせて、元の分布からトークンをサンプリングすることもできます。このアプローチは、帯域幅がボトルネックとなる小規模なバッチ設定でのみ機能することに注意してください。
つまり、投機的デコードは帯域幅と引き換えに計算を行うものであり、それが魅力的なパフォーマンス最適化のターゲットである主な理由は 2 つあります。まず、投機的デコードは、デコード段階の計算プロセスを変更することによってモデルの推論速度とスループットを向上させるだけであるため、モデルの品質はまったく低下しません。第 2 に、他の方法は主に最適化のためのモデル構造、パラメータ、トレーニングなどから開始するのに対し、その利点は逐次計算を並列実行に変換することにあるため、一般的に、この方法が提供する利点は他の方法とは独立しています。
現在の推論方法は、バッチごとに単一のシーケンスを予測します。ただし**、この方法は、大規模なバッチや低精度のドラフト モデルの場合には適切に拡張できません。 **直観的には、長く連続するトークン シーケンスの場合、2 つのモデルが一致を予測する確率は指数関数的に減少します。これは、アルゴリズムの強度が拡大するにつれて、投機的デコードのリターンが急速に減少することを意味します。
OpenAI が投機的デコードを使用している場合、おそらく長さが約 4 トークンの短いシーケンスに対してのみ使用されていると考えられます。さらに、GPT-4 モデルのパフォーマンスの低下は、OpenAI が投機的復号モデルの低確率シーケンスをモデルの事前トレーニングに追加したためであると考える人もいますが、これは真実ではない可能性があります。
また、Google は完全なシーケンスが生成されるのを待ってからユーザーに送信するため、Bard モデルでも投機的デコードが使用されていると考える人もいますが、私たちはこの推測が真実であるとは信じていません。
12. ビジュアルマルチモーダル
ビジョン マルチモーダル: さまざまなモダリティ (画像、テキスト、音声など) からの情報の共同処理と分析を指します。通常、これらの異なるモダリティの情報は意味的に関連しているため、それらを組み合わせることで、より豊富な情報とより正確な推論結果を提供できます。
GPT-4のビジュアルマルチモーダル機能は、テキストエンコーダから独立したビジュアルエンコーダによって実現されており、テキストエンコーダとのクロスアテンション機構(Cross-tention)を備えており、そのアーキテクチャはFlamingoモデルに似ていると言われています。ビジョン エンコーダーは 1.8 兆パラメータの GPT-4 モデルで微調整されましたが、追加の約 2 兆トークンのテキスト データで事前トレーニングされただけであり、ビジョン データではありませんでした。
OpenAIはビジョンモデルをゼロからトレーニングする予定だが、技術がまだ成熟していないため、テキストからトレーニングすることでリスクを軽減したいとしている。
**噂によると、OpenAI の GPT-5 はビジョン モデルをゼロからトレーニングし、画像と音声の処理を自動的に生成する機能を備えているとのことです。 **
ビジュアル マルチモーダル テクノロジの主な目標は、自律エージェントが Web ページを読み取り、その画像やビデオ コンテンツを転写できるようにすることです。 OpenAI がこのモデルをトレーニングするために使用するデータには、結合データ (レンダリングされた LaTeX/テキストを含む)、Web ページのスクリーンショット、Youtube ビデオのサンプル フレームなどが含まれており、Whisper テクノロジーを使用して転写されます。
LLM の過剰最適化問題に関する興味深い点の 1 つは、ビジュアル モデルの IO コストがプレーン テキスト モデルの IO コストと異なることです。テキストモデルのIOコストは非常に安価ですが、ビジョンモデルではデータロードのIOコストがテキストモデルの約150倍となります。各トークンのサイズは 600 バイトですが、テキスト モデルのサイズは 4 バイトのみです。現在、画像圧縮の研究では多くの研究が行われています。 (Xianxiang 注: テキスト情報は圧縮が容易であり、画像/ビデオのトークン化はマルチモーダル分野で注目に値する方向です。)
これは、各モデルの強力なビジュアルおよびオーディオ機能を考慮して、2 ～ 3 年後にハードウェアを最適化するベンダーにとって非常に重要です。彼らは自分たちのアーキテクチャがあまり適合していないことに気づくかもしれません。全体として、将来の LLM アーキテクチャは、現在見られる削減されたテキストベースの高密度モデルや MoE モデルを超えて確実に進化するでしょう。
参照