# I've Got 99 Problems But FLOPS Ain't One > [!abstract] 概要(abstract 日本語訳) > ハイパースケーラーは大規模ネットワーク展開の分野を支配しているが、直面している課題についてデータや洞察を共有することはほとんどない。この優位性を踏まえ、この分野で解くべき問題は何か。我々は、機械学習応用向けに 1000 億ドル規模のデータセンターを建設するという公開計画を出発点に、非従来的なアプローチをとる。言語モデルのスケーリング則を活用し、そのようなデータセンターが担うであろうワークロードを明らかにし、ネットワーキング研究に焦点を当てながら遭遇し得る課題を探求する。データセンターの建設と巨大モデルの訓練は技術的に可能であるが、そのためにはデータセンター間通信のための新しいワイドエリアトランスポート、データセンター内通信のためのマルチパストランスポートと新しいデータセンタートポロジ、高速スケールアップネットワークとトランスポートが必要であり、ネットワーキングコミュニティ向けの豊富な研究課題を概説する。 ## 論文情報 - **タイトル**: I've Got 99 Problems But FLOPS Ain't One - **著者・所属**: Alexandru M. Gherghescu、Vlad-Andrei Bădoiu、Alexandru Agache、Mihai-Valentin Dumitru、Iuliu Vasilescu、Radu Mantu、[[Costin Raiciu]](University Politehnica of Bucharest / [[Broadcom]]) - **媒体**: ACM HotNets '24(第23回 ACM Hot Topics in Networks ワークショップ) - **発表**: 2024年11月18〜19日、Irvine, CA, USA - **DOI**: https://doi.org/10.1145/3696348.3696893 - **ページ数**: 10 ## 概要 本論文は、1000 億ドル規模の AI データセンター建設計画を現実の制約から分析し、次世代 LLM 訓練インフラがネットワーキング研究に突き付ける課題を体系的に整理したポジションペーパーである。NVIDIA Blackwell GB200 GPU のスペックとスケーリング則から 103.8 兆パラメータモデルの物量要件を導出し、電力・スケールアップ・スケールアウト・ワイドエリアの各ネットワーク層でどの研究課題が残るかを具体的な数値つきで示す。FLOPs 不足ではなくネットワーキングが真のボトルネックであるという主張が論文タイトルに凝縮されている。 ## 問題設定 - **入力**: NVIDIA GB200 NVL72 ラック(3M USD/ラック、130 kW TDP)の公開スペックと、Kaplan・Hoffmann スケーリング則 - **出力**: 100 兆パラメータ LLM を訓練するための物理インフラ・並列化設計・ネットワーク設計の具体的仕様と、それが示す未解決の研究課題 - **前提条件**: $100B 予算の 70% がコンピュートに割り当てられる仮定。FP4 演算精度、32K トークンのシーケンス長、標準 Transformer アーキテクチャ(Transformer および MoE)を検討 ## 提案手法 ### インフラ設計 予算 700 億ドルをコンピュートに投じると約 23,300 ラック(1.67M GPU)、最大消費電力 3 GW、FP4 演算性能 16.8E21 FLOPS となる。IT 機器の電力を合計すると 3.6 GW。PUE 1.15〜1.3 を加味すると 4.16〜4.71 GW となり、これは米国内の単一拠点では調達不可能な規模である。 PJM グリッド(最大余剰 9,915 MW)が候補として浮かぶが、100 km 圏内の単一拠点では不十分。そのため**東西海岸分割(east-west split)**を提案する。東西分割の利点は(1)再生可能エネルギーを地理的に分散調達できる、(2)自然・人為的災害への耐障害性が上がる、(3)訓練後の推論提供で両コースト低レイテンシを実現できる、の三点である。 ### モデルとスケーリング則 **Figure 1: Loss-optimal model sizes** ![[_attachments/hotnets24-333/fig01-scaling-laws.png]] (Figure 1. Kaplan et al. と Hoffmann et al. A1/A2/A3 の計算最適スケーリング則比較。Hoffmann A2 に基づき、3〜48 か月の訓練期間に対して 24.9T〜103.8T パラメータが最適と判定。横軸は FLOPs、縦軸はパラメータ数。) Hoffmann et al. のアプローチ 2 を採用し、103.8T パラメータモデルを選択。アーキテクチャ仕様: - 語彙サイズ: 256,000 トークン(多言語・Unicode 対応) - 134 層、256 アテンションヘッド、隠れ次元 244,224(計 96 兆パラメータ) - シーケンス長: 32K トークン ### モデル物質化(3D 並列化) 必要総メモリ 384.14 TB(モデル 144.04 TB、勾配 48.01 TB、オプティマイザ状態 192.05 TB)。 1 ラック 72 GPU(NVL72)に 4 層を収容。テンソル/シーケンス並列度 t=18(ラック内全 GPU)、パイプライン並列度 134、データ並列度 696。 **Figure 2: 3D並列化 デバイスあたり forward+backward タイムライン** ![[_attachments/hotnets24-333/fig02-3d-parallelism-timings.png]] (Figure 2. 1 デバイスが担うレイヤーの forward と backward の通信・計算タイムライン。スケールアップ(4ピア)、スケールアウト(87ピア)、クロスDC の各フェーズを示す。forward 計算 132.82 ms、通信 10.2 ms、DP 勾配 all-reduce の各ステージが視覚化されている。) 通信のピックアップ: - テンソル/シーケンス並列(TP/SP): all-gather + reduce-scatter 2セット = 7.82 GB、8.2 ms。計算と隠蔽不可。 - パイプライン並列(PP): P2P 217 MB、2.17 ms。計算と隠蔽不可。 - データ並列(DP): 5段階の階層的 all-reduce。ラック内 16.57 ms → スケールアウト 98.27 ms → クロス DC 60 ms RTT → all-gather 49.14 ms → スケールアップ all-gather 8.3 ms。3 種ネットワークにまたがるためパイプライン可能。 ### ネットワーク設計 **露出ネットワーキング時間**の基準値: - Dense Transformer: 5%(理想ネットワーク・14.4 Tbps スケールアップ・800 Gbps スケールアウト) - MoE: 20%(同条件) **Figure 3: ネットワーク容量と露出通信時間の関係** ![[_attachments/hotnets24-333/fig03-network-exposed-comms.png]] (Figure 3. スケールアップ速度(a)・スケールアウト速度(b)・ワイドエリア速度(c)が露出ネットワーキング時間(%)に与える影響。スケールアップ 0.8 Tbps では Dense Transformer 40%・MoE 75%、14.4 Tbps で 5%/20%。スケールアウト 100 Gbps では 55〜85%。ワイドエリアでは無損失 20 Gbps 以上で 30 ms 伝播遅延を完全隠蔽可能だが、テール損失があると再送が露出ネットワーキングを拡大。) ### スケールアウトネットワーク 800K GPU に 800 Gbps NIC を接続する Fat Tree は 4 段・87,500 スイッチ・240 万スイッチ間リンクを要し、**光トランシーバだけで 50 億ドル**に達する。予算 10%(50 億ドル/DC)内に収まらないため代替が必要。 **マルチプレーン設計**: 同一 51.2 Tbps チップを 128×400 Gbps / 256×200 Gbps / 512×100 Gbps に再構成。4 プレーン構成で 256 ポートスイッチが実現でき、3 段 Fat Tree に削減できる。スイッチ数・リンク数を標準比 1/3 に削減。 **マルチレール設計**: 各ラックの 1 GPU のみをスケールアウトネットワークに接続し、ラックを独立ネットワーク(レール)に分割。72 レール構成で 11K GPU のサブネットワーク。マルチプレーンと組み合わせると**スイッチコスト 50%・リンクコスト 66% 削減**。 **Figure 4: AIML向けトポロジ(マルチプレーン・マルチレール)** ![[_attachments/hotnets24-333/fig04-aiml-topologies.png]] (Figure 4. マルチレール(Rail 1〜72)とマルチプレーン(Plane 1/2)を組み合わせたトポロジ概念図。各ラックのスケールアップネットワークが接続されるレール・プレーンの関係を示す。) ### トランスポートプロトコル 現行 RoCEv2 は ECMP のコリジョンと PFC の head-of-line blocking のため、理論最適 FCT 1 ms に対して**9 ms**を要する。 **Figure 5: パイプライン並列の FCT 分布** ![[_attachments/hotnets24-333/fig05-fct-pipeline.png]] (Figure 5. 8,192 ホスト・2 段 Fat Tree・800 Gbps リンクの RoCEv2 シミュレーション。1 path(RoCE)は FCT 9 ms。マルチパス(128 paths)で理論最適に近づく。NDP/Homa 相当のマルチパスで最適の 5% 以内。) SOTA 輻輳制御(ベストエフォート・シングルパス)で 7 ms → 露出ネットワーキング 8%/25%。NDP/Homa のようなマルチパストランスポートで最適の 5% 以内。業界は Ultra Ethernet Consortium を通じて Ethernet ベースのマルチパス・ロッシー動作に移行中。 ## 新規性 1. **規模感を「実現可能」として定量化**: 100T パラメータ訓練が技術的に可能であることを公開スペックと既存手法の延長で示した。 2. **ネットワーキング研究課題の体系的列挙**: FLOPs ではなくネットワークが主ボトルネックとして、スケールアップ・スケールアウト・ワイドエリアの3層で具体的な未解決問いを提示。 3. **東西分割 DC + 5段階 DP 通信パイプライン**: データセンター分割を前提としたデータ並列通信の設計を具体的に示した。 4. **マルチプレーン・マルチレール**の合算コスト削減効果を定量化。 既存研究(MegaScale、Megatron-LM、ZeRO 等)は単一 DC・万 GPU 規模の実装が中心。本論文は百万 GPU・複数 DC スケールの設計空間に踏み込んだ点で新規性がある。 ## 実験設定 - **シミュレーション環境**: 8,192 ホスト・800 Gbps リンク・完全プロビジョニング 2段 Fat Tree における P2P 同期転送の RoCEv2 シミュレーション - **比較対象**: RoCEv2(シングルパス)対マルチパス数のバリエーション(1〜128 paths) - **評価指標**: FCT(フロー完了時間)の CDF と負荷に対する FCT 推移 - **理論解析**: スケーリング則・並列化式・通信量計算はすべて公開論文の式を使用 ## 実験結果 - **P2P FCT**: RoCEv2 は理論最適 1 ms に対して 9 ms(9倍)。SOTA CC で 7 ms。NDP/Homa 相当で 5% 以内に到達(図5)。 - **露出ネットワーキング時間**: スケールアップ 0.8→14.4 Tbps で Dense Transformer は 40%→5%、MoE は 75%→20%(図3a)。スケールアウト 800 Gbps なら Dense Transformer に追加削減効果なし。 - **コスト**: Fat Tree 4段から 76 レール・4プレーンに変えるとスイッチチップ 39K、リンク 800K/DC。コスト 50%/66% 削減。 - **ワイドエリア**: 20 Gbps/GPU 以上で 30 ms 伝播遅延を計算で完全隠蔽可能。テール損失があると特に MoE(backward 90 ms)で露出。 ## 考察 MoE モデルは Dense Transformer より**ネットワーク要求が高い**。backward 計算が 90 ms と短い(Dense は 265 ms)ため DP 勾配交換との重なりが少なく、スケールアウトが部分的に露出する。スケールアウト 1.6 Tbps まで上げると MoE の露出が 5% 未満に収まる。 テンソル並列の障害ドメインがラックレベルに固定されるため、スケジューリング・配置設計も新たな制約を受ける。ワイドエリアトランスポートに TCP を使うと CWND 適応が不要な損失を生む一方、B4 的なコントローラはソフトウェアの同期問題を追加する。最終的には bit エラーに起因する再送は避けられず、冗長化(redundancy)が必要。 ## 強み / 弱点・課題 **強み**: - 公開情報のみから現実的な物量設計を導いた透明性 - スケールアップ・スケールアウト・ワイドエリアを一貫した計算フレームワークで接続 - 研究課題を具体的な問いの形で列挙し、後続研究の出発点を提供 **弱点・課題**: - 電力・冷却・ソフトウェアスタック・スケジューリングの詳細は Future Work - 東西 DC 間の同期オーバーヘッドや障害時のグレースフルデグラデーションは未定量化 - マルチプレーン・マルチレールのスケジューリングとフォールトトレランスへの影響は open question - スパースモデル(MoE)の専門家ルーティングがネットワークに与える不均一トラフィックの分析は略 ## 関連ページ - [[LLM分散学習]] — 分散訓練の全体像 - [[データセンター輻輳制御]] — DCQCN/RoCEv2 の制約 - [[RDMA]] — スケールアウト基盤プロトコル - [[集合通信]] — DP all-reduce の詳細 - [[RoCE設計課題]] — RoCEv2 の限界 - [[Broadcom]] — Costin Raiciu の所属機関 ## 出典 - PDF: `.raw/papers/hotnets24-333.pdf` - 本文テキスト: `.raw/papers/hotnets24-333.txt` - DOI: https://doi.org/10.1145/3696348.3696893