たった今、OpenAI の GPT-4 が業界関係者によって再び「オープンソース化」されました。
これらには、GPT-4 のアーキテクチャ、トレーニングと推論のインフラストラクチャ、パラメーターの量、トレーニング データセット、トークン番号、コスト、専門家の混合 (MoE) などの非常に具体的なパラメーターと情報が含まれます。
特に、さまざまなプロジェクトの背後で、OpenAI はどのように重視されていますか。そして、大規模なモデル推論における最大のボトルネックを乗り越える方法。
そのような重い啓示は誰から来たのでしょうか？
この記事の著者は、Dylan Patel と Gerald Wong という名前の SemiAnalysis への 2 人の寄稿者です。
ディラン・パテル氏は、以前業界で大騒ぎを引き起こしたGoogleの内部文書漏洩（「我々には堀はないし、OpenAIにもない」）の著者の一人でもあったことは言及する価値がある。
DeepMind CEOのHassabis氏は最近、海外メディアThe Vergeとのインタビューで、Googleエンジニアから流出した文書の信頼性を認めた。
ディラン・パテルがいくつかの特別なチャネルを持っていることがわかり、それが今日の啓示をもう少し本物にしています。
Going out to askのCEO、李志飛氏も講演
多くの企業が GPT-4 を作成できます
ニュース速報記事の著者の意見では、OpenAI がオープンでない理由は、人間が AI によって滅ぼされないようにするためではなく、AI が構築するものが再現可能であるためです。
同氏は、将来的には中国と米国のすべての大手インターネット企業やAI新興企業がGPT-4と同等、あるいはGPT-4を超えるモデルを構築できるようになるだろうとも予測している。
しかし同氏は、GPT-4がOpenAIの偉大な傑作であることも認めた。エンジニアの独創的なデザイン、複雑な構造、そしてエンジニアリング上のさまざまな巧妙なトレードオフが凝縮されています。
OpenAI の最も耐久性のある堀は、実際のユーザー、業界トップのエンジニアリング人材からのフィードバック、そして先行者利益によってもたらされる継続的なリーダーの地位を持っていることです。
モデルの枠組み
まず第一に、このニュースを伝えた著者は、GPT-4 には120 層に合計 1 兆 8,000 億個のパラメータが含まれているのに対し、GPT-3 には約 1,750 億個のパラメータしか含まれていないと考えています。
つまり、GPT-4の規模はGPT-3の10倍以上になります。
以前、GPT-4のパラメータは100兆であるとインターネット上で言われていましたが、それは否定されました
コストをリーズナブルに保つために、OpenAI は構築にMoE モデルを採用しています。
具体的には、GPT-4 には、MLP エキスパートごとに約1,110 億のパラメーターを備えた16 のエキスパート モデルがあります。このうち、順伝播には 2 つのエキスパート モデルが使用されます。
各トークンが指す専門家を選択するための高度なアルゴリズムについては文献で多くの議論が行われていますが、GPT-4 で OpenAI が使用するアルゴリズムは実際には非常に単純であると言われています。
さらに、モデルには約550 億のパラメータがあり、これらはアテンション メカニズムの共有に使用されます。
GPT-4 は、各フォワード パス推論 (トークンの生成) で、約 2,800 億のパラメーターと 560TFLOP のみを使用する必要があります。
これは、前方パスごとに約 1.8 兆のパラメーターと 3700 TFLOP を必要とする多くの純粋に高密度のモデルとはまったく対照的です。
データセットの構成
OpenAI は13 兆のトークンを使用してGPT-4 をトレーニングしました。
このデータ セットには 13 兆のトークンが含まれているだけでなく、高品質のトークンがないため、このデータ セットには多くのエポックも含まれています。
Scale AI とデータセット内には、数百万行の命令微調整データも含まれています。
しかし、この啓示の著者は、これらの RLHF データに関する情報はあまり見つからなかったと述べました。
事前トレーニング段階のコンテキスト長は 8K (seqlen) に達し、32k バージョンは事前トレーニングされた 8K バージョンに基づいて微調整されました。
バッチ サイズはクラスター内で数日かけて徐々に増加し、OpenAI で使用される最終的なバッチ サイズは 6,000 万です。
もちろん、すべてのエキスパートモデルがすべてのトークンを認識できるわけではないため、これは各 750 万トークンのエキスパート モデルのサイズ「のみ」です。
並行戦略
A100GPUにとって並列戦略は非常に重要です。
NVLink は非常に多くの .html しかサポートしていないため、OpenAI は 8 方向のテンソル並列処理を使用します。
しかしさらに、速報ニュースの著者は、OpenAI が 15 個の並列パイプラインを使用していると聞きました。
理論的には、データ通信とコンピューティング時間を考慮すると、15 パイプラインは少し多すぎます。
しかし、メモリ容量には限界があるため、非常に多くのパイプラインが意味を持ちます。
純粋にパイプライン化されテンソル並列化された場合、FP16 パラメーターは GPU あたり約 30GB になります。
しかし、KV キャッシュとコストを追加すると、OpenAI で使用される GPU のほとんどが 40GB A100 であれば、そのようなアーキテクチャは理論的には理にかなっています。
OpenAI が ZeRo Stage 1 を使用し、ブロックレベルの FSDP またはハイブリッド共有データ並列処理を使用している可能性があります。
なぜ FSDP の完全なモデルを使用しなかったのでしょうか? おそらく通信費が高いからだと思います。
OpenAI はほとんどのノード間に高速ネットワークを備えていますが、すべてのノードをカバーしているわけではありません。
その中で、少なくとも一部のクラスターの接続帯域幅は他のクラスターよりも大幅に低くなります。
しかし、著者は、OpenAI がこのような高いパイプライン並列性の下で各バッチでの「巨大なバブル」の生成をどのように回避するのかよく理解できないと述べ、OpenAI がこれらのコストに抵抗した可能性が非常に高いと述べています。
研修費用
OpenAI は、約 2.15e25 FLOPS で GPT-4 をトレーニングし、約 25,000 台の A100 で 90 ～ 100 日間トレーニングし、使用率は 32% ～ 36% です。
この極端に低い使用率は、以前のチェックポイントからトレーニングを再開する必要があった失敗の数が多かったことも原因の 1 つです。前述のバブルコストなど。
この場合の無駄なトレーニングコストは非常に高くなります。
もう 1 つの理由は、非常に多くの GPU の中での all-reduce は非常に高価であることです。
この図は、各操作を融合できないこと、アテンション メカニズムに必要なメモリ帯域幅、パラメータ読み取りに相当するハードウェア オーバーヘッドが非効率につながることを前提としています。実際、Nvidia の FasterTransformer ライブラリなどの最適化されたライブラリを使用した場合でも、合計のオーバーヘッドはさらに大きくなる可能性があります。
内部告発者の著者は、このクラスタが実際にはネットワーク接続が弱い小さなクラスタのグループである場合、クラスタの異なる部分間のノンブロッキング (ノンブロック) 接続速度は 800G/1.6T であるが、これらの部分はそれらの間の接続速度はわずか 200G/400G です。
OpenAI クラウド コンピューティングのコストが A100 時間あたり約 1 ドルであるとすると、このような条件下では、トレーニング コストは約 6,300 万ドルになります。
これには、すべての実験、失敗したトレーニング、およびデータ収集、RLHF、人件費などのその他のコストは含まれません。
先ほど述べた要因を考慮すると、実際のコストはさらに高くなります。
また、これは、他者がチップ/ネットワーク/データセンターを購入し、これらのシステムを構築するために設備投資を行い、OpenAI にリースできることを前提としている必要があります。
しかし現在では、H100 時間あたり 2 ドルで、2,150 万ドルのコストをかけて、わずか 55 日間で約 8,192 台の H100 の事前トレーニングを実行できます。
上の図は、公開されている一部の高度なモデルのパラメーターとトークンの数を示しています。図の線は、Google DeepMind の Chinchilla スケールの観測値 (より大きなエラーバーを平滑化) であり、線上の各点は、そのパラメーターとトークンの数でモデルをトレーニングするのに必要な理論上の FLOPS を示しています。
しかし、報告書の著者は、今年末までに少なくとも9社が上記の規模を超えるH100クラスターを保有するだろうと述べた。
これらすべての企業が個々のモデルのトレーニングにすべてを使用するわけではありませんが、使用する場合は GPT-4 よりも大きなモデルを使用することになります。
たとえば、Meta は今年末までに 100,000 を超える H100 を保有する予定ですが、そのかなりの部分は推論のために自社のデータ センターに分散される予定です。
しかし、その最大の単一クラスターは依然として 25,000 H100 を超えるでしょう。
つまり、今年末までに、多くの企業は GPT-4 サイズのモデルをトレーニングするのに十分なコンピューティング リソースを手に入れることになるでしょう。
この表は、必要な人員、ML Ops ツール、データ収集/前処理、障害回復、ワンショット/少数ショットの学習例、推論などを考慮せずに、Nvidia A100 でモデルをトレーニングする理論上の最適なコストです。部品代
混合エキスパート モデルのトレードオフ
MoE (専門家の混合モデル) は、推論中のパラメータの量を減らしながら、同時にパラメータの量を増やす優れた方法です。
ただし、十分な高品質のトークンを取得するのは非常に難しいため、これは各トレーニング トークンがより多くの情報をエンコードするために必要です。
OpenAI が本当に最高のパフォーマンスを追求したい場合、それを達成するために2 倍の数のトークンをトレーニングする必要があります。
そうは言っても、OpenAI はかなりのトレードオフを行いました。
たとえば、モデルのすべての部分がトークン生成ごとに使用されるわけではないため、推論中に MoE を扱うことは非常に困難です。
これは、他の部分が動作している間、一部の部分が休止状態になる可能性があることを意味します。
この状況では、ユーザーにサービスを提供する際の使用率が大幅に低下する可能性があります。
研究者らは、64 ～ 128 個のエキスパート モデルを使用すると、 16 個のエキスパートモデルを使用するよりも優れた損失プロファイルが得られることを示しましたが、これは単なる研究です。
比較的少数のエキスパート モデルを使用する理由はたくさんありますが、OpenAI が 16 人のエキスパートを選択した理由の 1 つは、より多くのエキスパート モデルを多くのタスクで一般化するのが難しいためです。
また、より専門的なモデルを使用すると収束を達成することも難しくなります。
このような大規模なトレーニング プロセスにおいて、OpenAI はエキスパート モデルの数をより控えめにすることを選択しました。
さらに、使用するエキスパート モデルの数を減らすことも、推論インフラストラクチャに役立ちます。ハイブリッド エキスパート モデル推論アーキテクチャに切り替える場合、さまざまな困難なトレードオフやトレードオフが存在します。
この最新ニュースの著者は、LLM 推論の基本的なトレードオフの議論から始まり、次に OpenAI が直面する問題とその選択について議論します。
推論のトレードオフ
ちなみに、推論のトレードオフを紹介する前に、内部告発者はすべての LLM 企業と話をした結果、NVIDIA の FasterTransformer 推論ライブラリが非常に悪く、TensorRT はさらにひどいことを発見しました。
これは、Nvidia が変更を加えない場合、ユーザーは独自のソリューションを一から作成する必要があることを意味します。
大規模な言語モデルについての推論には、次のような 3 つの主なトレードオフ、バッチ サイズ (同時に処理されるユーザーの数) の次元、および使用されるチップの数があります。
1. 遅延
モデルは妥当な遅延内で応答する必要があります。チャット アプリで出力の受信を開始するまでに数秒待ちたい人はいません。事前入力 (入力トークン) とデコード (出力トークン) の処理時間は異なります。
2. スループット
モデルは 1 秒あたり特定の数のトークンを出力する必要があります。人間は 1 秒あたり約 30 個のトークンを必要とします。他のさまざまな使用例では、スループットが低くても高くても許容されます。
3. 活用
モデルを実行するハードウェアは高い使用率を達成する必要があり、そうしないとコストが法外に高くなります。より高いレイテンシーとより低いスループットを使用して、より多くのユーザー要求を結合して使用率を高めることができますが、難易度も高くなります。
LLM 推論の鍵は、メモリ帯域幅と計算の 2 つの点のバランスを取ることです。
LLM の理論的な帯域幅要件: iPhone 14 で実行できる最大モデル サイズは、FP16 パラメータ最大 10 億個、または int4 パラメータ最大 40 億個であると想定できます。これは、スマートフォンに基づく LLM の基本的な制限です。モデルは採用されない
簡単に言えば、各パラメータを読み取る必要があり、それに関連付けられた2 つの FLOPがあります。
したがって、ほとんどのチップ (H100 SXM のメモリ帯域幅は 3 TB/秒しかありませんが、FP8 のメモリ帯域幅は 2,000 TFLOP/秒です) の比率は、バッチ サイズ 1 の推論では完全にアンバランスになります。
ユーザーが 1 人だけの場合 (バッチ サイズ 1)、トークンが生成されるたびに各パラメーターを読み取るために必要なメモリ帯域幅が推論時間の大部分を占めますが、計算時間はほとんど無視できます。
大規模な言語モデルを複数のユーザーに効率的に拡張するには、バッチ サイズが 1 を超える必要があります。複数のユーザーがパラメータの読み取りコストを共有します。たとえば、バッチ サイズが 256/512 の場合、メモリ読み取りバイトあたり 512 FLOP/s または 1024 FLOP/s を取得できます。
この比率は、メモリ帯域幅と FLOPS の間の H100 のバランスに近くなります。これにより、使用率が向上しますが、遅延が長くなります。
大規模モデルでは推論に複数のチップが必要であり、メモリ容量が大きいほど搭載できるチップの数が少なくて済むため、メモリ容量が LLM 推論の大きなボトルネックであると多くの人が考えています。
ただし、実際には、より多くのチップを使用する方が、待ち時間が短くなり、スループットが向上し、使用率を高めるためにより大きなバッチ サイズを使用できるようになります。
GPT-4 推論のトレードオフとインフラストラクチャ
上で述べたように、GPT-4 推論は非常に困難です。しかし、再び MoE MOD となると、まったく新しい一連の困難が生じます。
トークンを生成する各転送パスは、異なるエキスパートのセットにルーティングできます。これにより、より大きなバッチ サイズでのスループット、レイテンシ、および使用率の間のトレードオフに問題が生じます。
OpenAI の GPT-4 には 16 人のエキスパートがおり、各フォワード パスはそのうちの 2 人にルーティングされます。
これは、バッチ サイズが 8 の場合、読み取られる各エキスパートのパラメータのバッチ サイズは 1 のみである可能性があることを意味します。
さらに悪いことに、これは、あるエキスパートのバッチ サイズが 8 であるのに、他のエキスパートのバッチ サイズが 4、1、または 0 であることを意味する可能性があります。
生成されたトークンごとに、ルーティング アルゴリズムがさまざまな方向にフォワード パスを送信するため、トークン間の遅延が発生し、エキスパートのバッチ サイズが大幅に変化します。
OpenAI が少数の専門家を選んだ主な理由の 1 つは、推論インフラストラクチャです。より多くの専門家を選択すると、メモリ帯域幅が推論のボトルネックになります。
OpenAI の推論クラスターは、通常 4k 以上のバッチ サイズに達する可能性があります。これは、エキスパート間の負荷バランスが最適であっても、エキスパートのバッチ サイズは約 500 程度にすぎないことを意味します。これを実現するには、非常に大量の使用量が必要です。
内部告発者によると、OpenAI は 128 個の GPU のクラスターで推論を実行していることがわかりました。これらのクラスターは、複数のデータセンターおよび地理的な場所に複数存在します。
推論では、8 方向のテンソル並列処理と 16 方向のパイプライン並列処理が使用されます。8 つの GPU で構成される各ノードのパラメーターはわずか約 130B、つまり FP16 では GPU あたり 30GB 未満、FP8/int8 では 15GB 未満です。
これにより、すべてのバッチの KV キャッシュ サイズが大きすぎない限り、40 GB A100 で推論を実行できます。
異なるノード上の異なるエキスパートを含むレイヤーは分割されません。これは、ネットワーク トラフィックが不規則になりすぎ、生成された各トークン間の KV キャッシュの再計算にコストがかかりすぎるためです。
将来の MoE モデル拡張と条件付きルーティングの場合、最大の課題は、KV キャッシュのルーティングをどのように処理するかです。
モデルには 120 のレイヤーがあるため、単純に 15 の異なるノードに分散できますが、最初のノードはデータのロードと埋め込みを行う必要があるため、推論クラスターのマスター ノードに配置するレイヤーの数を減らすのが合理的です。
また、「投機的デコード」 (以下) に関するいくつかの噂があり、マスターノードに含まれるレイヤーの数を減らす必要がある理由も説明されています。
推論コスト
1,750 億のパラメータを持つ Davinchi モデルと比較すると、GPT-4 のコストは 3 倍ですが、フィードフォワード パラメータは 1.6 倍しか増加しません。
これは主に、GPT-4 では大規模なクラスターが必要であり、使用率が低いためです。
著者らは、128 台の A100 で GPT-4 の 8k シーケンス長を推論するコストは 1,000 トークンあたり 0.0049 ドルであるのに対し、128 台の H100 で GPT-4 の 8k シーケンス長を推論するコストは 1,000 トークンあたり 0.0021 ドルであると考えています。
これはかなり高い使用率を想定しており、バッチ サイズが大きく保たれることに注意してください。
しかし、OpenAI が十分に活用されていない場合があることは明らかです。
この点に関して、著者は、OpenAI がオフピーク時間中にクラスターをシャットダウンし、ノードを再構成し、小規模なテスト モデルのトレーニングを再開し、推論コストを削減するためにさまざまな新しいテクノロジーを試すだろうと仮説を立てました。
OpenAI がそうしなかった場合、その使用率は低くなり、コストは 2 倍以上になっていたでしょう。
マルチクエリの注意
さらに、OpenAI はマルチクエリ アテンション (MQA) も使用しています。
論文アドレス: https://arxiv.org/pdf/1911.02150.pdf
つまり、必要なアテンション ヘッドは 1 つだけであり、KV キャッシュのメモリ フットプリントを大幅に削減できます。
それでも、長さが 32k の GPT-4 は40GB A100 では実行できず、最大バッチ サイズには 8k の上限があります。
連続バッチ
OpenAI は、可変バッチ サイズと連続バッチ処理を実装します。
そうすることで、ある程度の最大レイテンシが可能になり、推論コストが最適化されます。
投機的デコード
OpenAIは、依然として100％の不確実性が残るGPT-4の推論過程で「投機的復号」を利用していたことが明らかになった。
トークンごとのレイテンシの変化、および単純な取得タスクを実行する場合とより複雑なタスクを実行する場合の違いは、これが可能であることを示唆しているように見えますが、まだ変数が多すぎて確実ではありません。
ここでは、内部告発者は、DeepMind による研究「段階的投機的デコーディングによる LLM 推論の加速」のテキストを説明するために、適切な修正を加え、詳細を追加しました。
通常、LLM の使用には 2 つのフェーズがあります。
1 つ目はプレフィルで、ヒント テキストがモデルに供給されて、KV キャッシュと最初の出力のログ オッズ (可能なトークン出力の確率分布) が生成されます。プロンプトテキスト全体を並行して処理できるため、このプロセスは通常高速です。
第 2 段階はデコードです。出力の対数オッズからトークンを選択し、それをモデルにフィードします。これにより、次のトークンの対数オッズが生成されます。必要な数のトークンが生成されるまで、このプロセスを繰り返します。
デコードは連続して実行する必要があるため、そのたびに重みをコンピューティング ユニットを通じてストリーミングして単一のトークンを生成する必要があります。したがって、この 2 番目のステージは、ミニバッチで実行する場合、非常に計算量が多くなります (つまり、メモリ帯域幅のバイトあたりの FLOP を計算します)。したがって、デコードは通常、自己回帰生成で最もコストがかかる部分です。
これが、OpenAI の API 呼び出しにおいて入力トークンが出力トークンよりもはるかに安い理由です。
「投機的デコード」の基本的な考え方は、より小型で高速なドラフト モデルを使用して複数のトークンを事前にデコードし、それらをバッチとして予測モデルにフィードすることです。
ドラフト モデルの予測が正しい場合、つまり、大規模なモデルがそれらの予測と一致する場合、単一のバッチを使用して複数のトークンをデコードできるため、メモリ帯域幅と時間を大幅に節約できます。
ただし、より大きなモデルがドラフト モデルによって予測されたトークンを拒否した場合、残りのバッチは破棄され、アルゴリズムは自然に標準のトークンごとのデコードに戻ります。
「投機的デコード」には、元の分布からサンプリングするための拒否サンプリング スキームが伴う場合もあります。これは、帯域幅がボトルネックとなる小規模バッチ設定でのみ役立つことに注意してください。
帯域幅と計算を交換する投機的デコードは、次の 2 つの主な理由により、パフォーマンス エンジニアリングのターゲットとして魅力的です。
まず、モデルの品質が低下することはありません。第 2 に、そのパフォーマンスは「逐次実行」から「並列実行」に変換することで得られるため、他のアプローチとは直交するパフォーマンスの向上が得られることがよくあります。
現在の推論方法は、バッチ予測の別個のシーケンスです。ただし、このアプローチは、大規模なバッチやドラフトの低いモデルの調整にはうまく対応できません。
直観的には、2 つのモデルが連続する長いトークンのシーケンスに一致する確率は指数関数的に低く、これは、演算密度が増加するにつれて、投機的デコードによる利益が急速に減少することを意味します。
内部告発者は、OpenAI が「投機的デコード」を使用する場合、約 4 つのトークンのシーケンスでのみ使用できると考えています。
余談ですが、OpenAI の去勢に関する陰謀全体が、GPT-4 の品質を低下させる原因となっているのは、単純に、OpenAI が予測モデルを「推測的復号」モデルからの低確率シーケンスにさらしているためかもしれません。
また、Google はシーケンス全体が完全に生成されるのを待ってからユーザーに送信するため、Bard は「投機的デコード」も使用していると推測されていますが、内部告発者の意見では、この推測は完全に間違っています。
ビジュアルマルチモーダル
視覚的なマルチモーダル機能は、少なくとも主要な研究と比較して、GPT-4 の最も印象に残らない部分です。
もちろん、マルチモーダル LLM 研究の結果を商業化した人はまだ誰もいません。
内部告発者によると、これはテキストエンコーダから独立したビジュアルエンコーダであり、クロスアテンション機能があり、アーキテクチャはFlamingoに似ており、GPT-4 1.8Tにはより多くのパラメータが追加されているという。
GPT-4 のマルチモーダル機能は、テキストの事前トレーニング後に約 2 兆のトークンを使用して微調整されます。
OpenAIはビジュアルモデルにおいて、当初はゼロから学習させたかったが、成熟度が足りなかったため、テキスト学習モデルから微調整するしかなかったという。
そして次世代モデル GPT-5 は、視覚モデルをゼロからトレーニングし、画像を生成し、さらには音声を生成できるようにする必要があります。
この視覚能力の主な目的の 1 つは、自律エージェントが Web ページを読み取り、画像やビデオを転写できるようにすることです。
OpenAI がマルチモーダル モデルをトレーニングするために使用するデータには、「結合データ」(LaTeX/テキスト)、Web ページのスクリーンショット、YouTube ビデオ (フレームのサンプリング、字幕を取得するための Whisper の実行) が含まれていることは言及する価値があります。
LLM の過剰最適化に関する興味深い事実は、ビジュアル モデルの IO コストがテキスト モデルとは異なることです。ビジュアル モデルでは、データ読み込み IO はテキスト モデルの約 150 倍です。
ビジュアルモデルのIOコストは低い
ビジュアル モデルの各トークンは 600 バイトで、テキストは 4 バイト/トークンです。
そのため、画像圧縮に関しては多くの作業が必要になります。ハードウェア ベンダーは、LLM の使用例と比率に基づいて 2 ～ 3 年先までハードウェアを最適化しているため、これは非常に重要です。
彼らは、各モデルが強力なビジュアルおよびオーディオ機能を備えた世界にいることになるかもしれません。
彼らは自分たちがそのアーキテクチャにあまり適していないことに気づくかもしれません。
一般に、このアーキテクチャは、現在見られるテキストベースの簡略化された密集モデルや MoE モデルを確実に上回ります。
参考文献:
https://www.semianalysis.com/p/gpt-4-architecture-infrastructor