Ask HN: ChatGPTは7億人にサービスできるのに、なぜ私はGPT-4ひとつさえローカルで動かせないのか？
(news.ycombinator.com)- Sam Altmanが、ChatGPTは週あたり約7億人のユーザーを処理していると発表
- GPT-4級モデルをローカルで実行すると、VRAM不足・速度低下が深刻だが、OpenAIがどうやってこの大規模な利用量を低遅延・高性能で処理しているのか気になる
- 単なるGPUクラスター以上のモデル最適化・分散処理・専用ハードウェア・ロードバランシング手法を知りたい
主要コメントの要約
1. 超大規模分散推論アーキテクチャ
- モデルシャーディング(Model Sharding)
- パラメータを複数のGPUに分散して保存
- リクエストが来ると、各GPUが自分のパラメータ部分について計算を行い、その結果を結合
- テンソル並列性(Tensor Parallelism)
- 1つのレイヤー内の計算を複数GPUで並列実行
- パイプライン並列性(Pipeline Parallelism)
- レイヤーを複数段階に分け、パイプラインのように逐次・同時処理
- 混合並列処理でGPUメモリ・計算負荷を最適化
2. メモリ・速度最適化
- 量子化(Quantization): パラメータを低ビット精度に変換してVRAM使用量を削減
- レイヤーオフロード(Offloading): 必要に応じて一部レイヤーをCPUメモリへ移動
- LoRA / Adapter Layers: 特定タスクのみを微調整(fine-tuning)し、モデル全体の再読み込みを不要化
- KVキャッシュ(Key-Value Caching): コンテキストを再利用して反復計算を削除
3. 専用ハードウェア・ネットワーキング
- 最新のNVIDIA H100、A100、一部TPUを大規模活用
- GPU間はNVLink・NVSwitch、クラスター間はInfinibandで超高速データ転送
- データセンター間にグローバルバックボーンネットワークを構築し、遅延を最小化
4. 地理分散・ロードバランシング
- 世界各地の複数リージョンにGPUファームを配置
- GeoDNSでユーザーリクエストを最も近いリージョンへ接続
- トラフィックパターンに応じてGPUクラスターを動的に拡張・縮小
- 特定リージョンに負荷が集中した場合はグローバルトラフィックを再分配
5. リクエスト処理の最適化
- Batch Inference: 複数ユーザーのリクエストをまとめて一度に推論
- 小型モデルによる前処理: 簡単なリクエストは小型モデルで処理し、複雑なリクエストだけ大型モデルを呼び出す
- 結果キャッシュ: 同一プロンプト・類似リクエストの結果をキャッシュから即時返却
- プロンプトエンジニアリングで不要なトークン浪費を防止
6. 運用・コスト最適化
- GPU使用率の監視・スケジューリングで遊休リソースを最小化
- データセンターの電力効率化・液冷の導入
- 独自コンパイラ・ランタイム最適化で推論速度を向上
- モデル更新・デプロイ自動化パイプラインを運用
総合アーキテクチャの流れの例
- ユーザーリクエスト受信 → GeoDNSで近いリージョンへルーティング
- 前処理 → 簡単なリクエストは小型モデル、複雑なリクエストだけ大型モデルへ転送
- 分散推論処理
- モデルシャーディング + テンソル並列 + パイプライン並列を適用
- GPU間の高速ネットワークで中間結果を交換
- 後処理・結果キャッシュ → 同一・類似リクエストに備えてキャッシュ保存
- 応答返却 → 1~2秒以内に結果を提供
3件のコメント
openai の場合、NVIDIA ハードウェアだけでなく AMD の MI300X も推論に使用中で、学習では NVIDIA のみだが
推論では何としてでも投資コストに対して VRAM を確保しようと躍起になっている。
Microsoft の場合も同様に、推論では NVIDIA と AMD を混在利用している。
特にアジア側の Azure リージョンでは、OpenAI が使っている AMD の比率は
NVIDIA 8 / AMD 2 程度です
Hacker Newsの意見
Googleでこうしたシステムを直接扱う仕事をしている（個人の意見です）。賢い人たちが問題のあらゆる側面を真剣に考えていることは確実に言えます。これ以上の情報は話せませんが、同僚が書いた資料を共有したいです。アクセラレータのアーキテクチャや高速化のための最適化手法について、scaling bookに優れた説明があります。特に推論について知りたいなら、inferenceチャプターが役に立ちます。加えて、unslothのガイドもおすすめです。さまざまなモデルを深く掘り下げて最適化を見つけ、それをうまく整理して提供しています。Gemma 3nガイドのほかにも多くのガイドがあります
もう少し神秘性を排して説明すると、推論は（ほとんどの場合）ステートレスな作業です。したがって、学習のように何十万台ものマシン間でのメモリ一貫性やマシン障害を考慮する必要がありません。少量のデータを非常に大きなマシン群にうまく届ければよいだけです。私がいた場所の研究用マシンはGPUを8基搭載した超高性能マシンで、モデルが（合計の）VRAMに収まりさえすれば、どんな処理でもきちんと回せました。大規模拡張の秘密の材料は「莫大な資本」でした。NVIDIAから金ぴかのDGXマシンが送られてきたこともありましたが、これは高密度ではなく非常に高価でした。大企業の多くは堅牢なRPCやオーケストレーションの仕組みを持っているので、本当に難しいのはメッセージ配送ではなく、モデルをそのハードウェアに収まるように載せることです（これは私の専門分野ではありません）
現代的な大規模推論ラック、よく知られたRDMAや低遅延ネットワーキング手法、強力なMLAやキャッシュ最適化は、神秘的な技術のように描かれる必要はありません。これらはすでに公開の場でよく理解されており、むしろ有名企業が何か非常にカスタムなことをしている場合は、たいていレガシー互換性の問題のせいで負担になることさえあります。本当に重要なのは、大規模システムを回すために必要な体制とプロセスをきちんと整えることです。そこには機材調達、SREトレーニング、新しいTPU向けのRTLまで、さまざまな領域が含まれます。もし誰かが10倍先を行っているなら、すぐに分かるはずです （10年間、TOP-5企業で大規模推論の経験がある者です）
「私たちはあらゆる問題を本気で考える賢い人たちです」という表現については、実際には1970年代のメインフレーム風タイムシェアリングシステムをやっている、と考えればよいです
GoogleはTPUのおかげで、自社モデルの推論をNVIDIAカードを借りるよりはるかに採算よく回せているのではないかと気になります。OpenAIは主にMicrosoftとのパートナーシップを通じてGPUを確保していると理解しています。リンクも本もどちらも興味深く読みました
「今日では『小さな』モデルでさえハードウェアの限界ぎりぎりで動いている」という一文が印象的でした。これは60〜70年代の「小さなプログラムでさえハードウェアの限界に合わせて動く」という話に似て聞こえます。ソフトウェアエンジニアリングにおける最適化や効率性は失われたとしても、LLM開発ではまだ生きています
H100は1枚2万ドルで、80GBのVRAMを備えています。2Uラックサーバー1台にこうしたカードが10万ドル分入ると想像できます。こうした機材がラック全体に入り、CPU、RAM、冷却まで含めると、1ラックあたり100万ドル規模です（運用費や保守人員のコストは別です）。「安価な」機材であっても、計算の単位が非常に大きいのです。AIバブルが弾ける頃には、良いローカルモデルを現実的に回せるようになることを期待しています。10年後には、こうした10万ドル級のサーバーがeBayで3,000ドルで売られていて、電気工事士がガレージや即席サーバールームに240V電源を引いてほしいという依頼を受けているかもしれない、と想像しています
10年も待たなくても、DGX-1ならeBayで今すぐ1万ドル以下で買えます。256GB VRAM（HBM2）、NVLink、512GB RAM、40コアCPU、8TB SSD、100Gbit HBAを備えています。NVIDIA以外のブランド品なら6,000ドルでも購入可能です。ただし非常に重く、想像以上にうるさく、1台で240V 16A回路をほぼ使い切ります。同時に毎時13,000 BTUの熱も発生します
AIバブルが弾けなくても、そのサーバー群が10年後にeBayへ流れる可能性は高いです。データセンターがハードウェアを更新し、中古品を第三者へ売却するからです
個人的には、公開モデルは私たちが思っているよりはるかに少ない計算量しか使っていないのではないかと疑っています。最新のMixture of Expertsモデルでは、top-kサンプリング、つまり一部のエキスパート（パラメータ）だけを有効化して評価する構造のおかげで、SOTAモデルであってもnon-MoEの70〜80Bモデルよりはるかに多い計算を必要とするわけではありません
企業レベルのAIサービングでは、「どうやってユーザーにサービスを提供するか」が本当の問いではなく、投資家がいずれROIを期待していることが核心です。必要なだけのインフラは、投資さえ入ればいくらでも構築できます。最適化がなくても、必要なら必要なだけ倉庫とラックを建ててサービスすればよい構造です
アメリカ人ではないので、240Vの話が面白かったです
あなたに数千ドルがあるなら、彼らには数百億ドルがあります。1,000対10,000,000,000という規模の差です。彼らの持つ効率性も、スケールによってさらに1〜2桁優れています。また、MacBook（24GB RAM）でもGPT-4初期リリース級の性能に匹敵するローカルモデルを動かせます。性能比較リンク
1つのGPUノードだけでも非常に高いFLOPsとメモリ帯域幅を提供します。少数のリクエストを処理するときは、主にGPUが重みデータをRAMから演算ユニットへストリーミングするのを待っていることが多いです。リクエストをまとめてバッチ処理すれば、一度に1束の重みを読み込んで複数のリクエストを並列処理できるため、効率が最大化されます。さらに、モデルを8ビット以下の形式に圧縮してストリーミング量を減らし、最新GPUは8ビット/4ビット演算をサポートしています。Mixture of Expertsモデルでは、各トークンごとに一部のパラメータしか使わないため、読み込む重みも少なくて済みます。speculative decodingの手法では、小さなモデルを使って複数トークンを先に予測し、実際のメインモデルはそのうち一致するものだけを採用します。こうした最適化がすべて組み合わさって、優れた効率を生みます （Databricks推論チームのディレクター経験に基づく）
OpenAIの秘密のソースの1つは、数十億ドル規模の赤字です。2024年に50億ドルを失いました。関連記事
最近はagenticな方式が登場して、状況はかなり変わりました。以前は1リクエストあたり1回の処理でしたが、今では1つのタスクに対して数百回の処理を同時進行させます。こうした並列処理が可能だからこそ、OAI/Azureはローカルモデルに対して優位なのです
もしR&Dをやめて既存モデルの提供だけに専念すれば、損益分岐点には乗せられそうです
本質をよく突いています。Microsoftの最大100億ドルの投資が事前学習、R&D、推論コストを賄ってもなお、数十億ドルの赤字です。VC的な、成長志向の資本主義構造です
大規模推論では、リクエストをまとめて一括処理するバッチングが、個々のユーザーにGPUを割り当てる方式（個人環境）よりはるかに効率的です。中程度のエンジニアリング上の工夫を知りたいなら、私たちのチームがFin AIブログに書いた記事を見てみてください。（OpenAIなどは、おそらくここに書かれていない非公開の手法も使っているはずです）関連記事
週あたり7億人のユーザーがいると言っても、実際の負荷がどれほどかはあまり分かりません。ChatGPTユーザーの大半も、毎日1時間ずつ1週間使うとしても、96%の時間は遊休状態です。多くの人はより単純なモデルしか使いません。あえて「週間ユーザー」に言及するのは、日次アクティブユーザーの中にも1日に1回すら使わない人が少なくないことを意味します。核心的な課題は、1) モデルがメモリに収まり十分な速度でトークンを処理できるサーバーを作ること、2) ピーク時の総トークン処理量に見合うだけのサーバーを十分に確保すること、3) すべてのリクエストを効率よくサーバーへ振り分けること、です。細かい点はいろいろありますが、実際のところ最後の課題は検索エンジンを回すのにも少し似ているように感じます。すべての状態はチャット履歴内にあるので、同じチャットを常に同じサーバーが処理する必要はありません。「Thinking...」と表示されているとき、本当にモデルが計算中なのか、それともキューでサーバー待ちなのかは外からは分かりません
LLMが大規模でうまく動く最大の秘訣の1つは「バッチサイズ」です。最近のLLMはたいてい「Mixture of Experts」構造を使っており、全パラメータのうち一部だけを瞬間的に有効化します。そのおかげで大規模バッチ処理がはるかに効率的になります。もしGPT-4を自宅で動かすなら、モデル全体をVRAMに載せられなければならないので、H100のようなGPUが何枚も必要になります（1枚約4万ドル）。しかし個人の使用量では、こうしたカードをまともに活用できません。まるで「Appleは何十億人向けにiPhoneを作れるのに、なぜ自分はガレージで1台も作れないのか？」と尋ねるようなものです
要するに、推論負荷は多くのユーザーにうまく分散されるので効率よく回るのです
だとすると、利用頻度の低いパーツはメインメモリに、よく使うパーツはVRAMに載せておくような構成が可能なのかも気になります
比喩としてとても的確です
自宅でも実装でき、Cerebrasの性能で重要な役割を果たしているトリックの1つがspeculative decodingです。この方式では、はるかに小さいドラフトモデルで、はるかに少ない計算とメモリでトークンを予測し、メインモデルがそのトークン群のうち実際に自分が選びそうなものを採用します。適切に整えられた構成では、最大3倍の高速化が可能です。またstructured outputでは、予測可能なトークンをスキップする「fast forwarding」を適用し、JSONなどで冒頭の形式をあらかじめ埋めておくことで、最大3倍の高速化が可能です
LLM推論の核心は行列ベクトル積です。複数のクエリを同時に処理する必要がある場合は、各クエリのベクトルを集めて行列にし、行列-行列積によって同時に計算できます。ハードウェアの観点では、行列ベクトル積を何度も繰り返すより、1回の行列-行列積のほうがはるかに効率的です。これがまさにバッチ処理です。2つ目のトリックはspeculative decodingです。推論にはプロンプト処理とトークン生成の2段階があり、どちらも実際には「forward pass」という同じ構造です。プロンプト処理は行列-行列積で並列化でき、その最後の結果だけがトークン生成開始に使われます。ところが未来のトークンは事前には分からないので、通常は並列化できません。そこで高速なドラフトモデルで先のN個のトークンを予測し、それを入力プロンプトに入れてからメインモデルで並列forward passを走らせます。生成されたN個のトークンのうち、一致する最初のトークンまでをすべて有効トークンとして即座に取り出せます。理論上は2〜4倍の推論速度向上が期待できます。私はこれを仕事として直接実装したわけではありませんが、加えてクエリ長ごとの並列グルーピングやリアルタイムのロードバランシングなども適用しているのではないかと推測します（すべてのリクエストが同じ長さとは限らないので、資源の不均衡を防ぐために必要です）