Claude が書いた記事
AI のボトルネックは『箱と箱のあいだ』：GPU が待つ崖と、IB vs Ethernet の戦争
「AI の発展でネットワークがボトルネック」を、どこが詰まるかまで物理で特定した学習ログ。詰まるのは GPU の中でもユーザーへの配信でもなく、サーバとサーバのあいだ (NVLink → InfiniBand の 15 倍の崖)。学習の all-reduce が崖からはみ出して GPU が待つ時間こそが本体で、その先には IB vs Ethernet の思想戦争があった、と腹落ちするまでの記録。
俺の最初の疑問
「AI の発展でネットワークがボトルネックになっている」とニュースで聞いた。
俺はネットワークの技術サポートをやっている。だから余計に引っかかった。ほんまなら、どこのネットワークが詰まるんや？ 帯域なら太くすればええし、レイテンシなら近づければええ。普段はそう考えて手を動かしている。AI の何がそんなに特別なんか。
前提として、俺の守備範囲は Azure の Application Gateway / Load Balancer / Front Door あたり。「大量のユーザーからのリクエストを north-south でさばく」world で生きてきた。その目で見たときに、AI のネットワークがまったく別の生き物だった、というのが今回の話。
まず一言でいうと
GPU が速すぎて、計算が終わったあと「他の GPU のデータが揃うのを待つ時間」が無駄になる。その待ち時間がネットワークのボトルネック。
GPU は 1 枚で数百万円する。その GPU が「ネットワーク待ち」でボーッと遊んでいる時間は、金をドブに捨てている時間だ。だから「ネットワークがボトルネック」と騒がれる。
そして詰まる場所は、GPU の中でもなければ、ユーザーへの配信でもない。サーバとサーバのあいだだった。
何と比べるとわかるか
俺が普段チューニングしているネットワークと、AI 学習クラスタは、思想が真逆だった。
| Azure の世界 (俺の守備範囲) | AI 学習クラスタ | |
|---|---|---|
| トラフィックの形 | 大量の独立した小さいフロー (ユーザーごと) | 1 個の巨大な同期した計算 |
| 1 本詰まると | その 1 ユーザーだけ遅い、他は無事 | 全員止まる |
| 速くする方法 | 水平スケール、フロー分散 | 一番遅いリンクを潰す |
| 主役の方向 | north-south (ユーザー↔サーバ) | east-west の極端版 (GPU↔GPU) |
App GW や Front Door は「独立した客をさばく」world だ。AI 学習は逆で、全 GPU が一糸乱れず同じ計算を lockstep で進める。だから「速い者が遅い者を待つ」構造になる。ここを最初にズラさないと、ずっと違和感が残る。
何が問題なのか
学習はこのループの繰り返しだ。
①各 GPU が自分の担当データで計算 → ②全 GPU の計算結果(勾配)を全員で交換・合算 → ③次のステップへ
↑ここが全 GPU の同期バリア②で全 GPU が持っている勾配を互いに足し合わせて配り直す。これを all-reduce と呼ぶ。毎ステップ、数百 GB〜TB 級が GPU 間を飛ぶ。そして②が終わるまで誰も③に進めない。
→ 一番遅い 1 リンクが、何千枚の GPU 全部を待たせる (tail latency が全体を支配する)。俺の world では事故扱いのこの現象が、AI 学習では構造的に毎ステップ起きる。
図で見る
どこが詰まるか：箱の中と箱の外の崖
ネットワークは速い順に階層になっている。バーの長さが帯域だ。
同じサーバの中 (GPU 8 枚) は NVLink で全結合、約 900 GB/s でほぼ詰まらない。ところがサーバの外に出た瞬間、InfiniBand でも 1 本 50 GB/s。いきなり 15〜18 倍遅くなる。
核心はここだ。
モデルがデカすぎて GPU 8 枚 (= 1 サーバ) に収まらない。だから必ず箱の外に出ないといけない。その瞬間に崖から落ちる。
GPT 級のモデルは数千〜万枚の GPU を使う。計算の大半が「箱の外」をまたぐ。一番速い NVLink で繋がっているのは全体のごく一部だけで、残りは全部その 15 倍遅いリンクで all-reduce をやらされる。
その瞬間 GPU は何をしているか：待っている
詰まっている瞬間、GPU はもう計算を終えて、結果の交換が終わるのを突っ立って待っている。この待ち時間こそ「高い GPU を遊ばせている＝金をドブ」の正体だ。
ただし現実のフレームワーク (PyTorch DDP など) は賢い。逆伝播の最中に「もう計算済みのレイヤーの勾配」から先に all-reduce を始める。計算しながら裏で通信する＝ overlap だ。
つまり「ネットワークがボトルネック」を厳密に言うと、こうだ。
崖のせいで通信を計算の裏に隠しきれず、はみ出して exposed になった、あの待ち時間のこと。
なお all-reduce (勾配の全員交換) は学習の話で、推論には勾配がないので出てこない。推論も箱の外を渡る場面は増えているが (モデルが 1 枚に載らず複数 GPU に割る等)、あっちは「TB 級を一括同期」ではなく「小さいデータを超低レイテンシで頻繁に」で、性質が違う。学習は帯域勝負、推論はレイテンシ勝負だ。
混乱しやすいポイント
① ケーブルを 15 本にしても崖は埋まらない
「15 倍遅いなら 15 本束ねればええやん」── 俺が最初に思ったやつ。そして現場はとっくに束ねている (標準サーバは GPU 1 枚につき IB を 1 本ずつ、計 8 本生えている)。それでも埋まらない理由が 3 つある。
- (a) 1 枚の GPU に 18 本は挿せない。 NVLink の 900 GB/s は「速いケーブルが何本もある」のではなく、GPU のシリコンに直結した専用ファブリックだ。一方 IB は GPU → PCIe → NIC → ケーブル、と外付け部品を経由する。GPU から出せる PCIe レーンも、基板に挿せる NIC の枚数も有限で、50 GB/s の NIC を 18 枚ぶら下げる物理スペースがない。崖は「ケーブルの本数」ではなく「シリコン直結か、基板の外に出るか」の差。
- (b) 真ん中のスイッチが全員分を同時に運べない。 all-reduce は全 GPU が同時に喋る (ほぼ all-to-all)。本数を増やすほど、それを詰まらせない non-blocking fabric のコストと電力が超線形に爆発する (1〜2m 超で銅が届かず光トランシーバが要る、スイッチの radix の壁)。
- (c) 本数＝太さを増やしても、同期バリアは残る。 帯域は稼げても、一番遅い 1 本・一番遠い 1 ホップが全員を待たせる構造 (レイテンシとテール) は消えない。
だから NVIDIA の答えは「IB をもっと束ねる」ではなく GB200 NVL72、つまり NVLink そのものを箱の外へ延ばして、崖の位置を 8 枚から 72 枚まで上にズラすことだった。
② RDMA は「箱の外」専用の仕組み
GPU が待っている裏で動いている通信が RDMA = Remote Direct Memory Access だ。何が “ダイレクト” かというと、相手の CPU と OS カーネルをすっ飛ばして、相手のメモリ (HBM) を直接読み書きするところ。
普通の TCP なら、送受信のたびに CPU / カーネルがバイトをコピーする。RDMA では NIC が相手の HBM を直接読み書きし、CPU は最初に「行け」と言うだけ。特に NIC が GPU の HBM を直接触るものを GPUDirect RDMA と呼ぶ。前回の推論編 (LLM 推論サーバーの中身) で掴んだ「サーバー間は HBM ↔ RDMA ↔ HBM」が、まさにこれだった。
1 個だけ区別を固めておく。
| 区間 | 仕組み | RDMA？ |
|---|---|---|
| ② 同じ箱の中 GPU↔GPU | NVLink (シリコン直結) | ❌ |
| ③ 箱↔箱 サーバ間 GPU↔GPU | InfiniBand / RoCE 上の RDMA | ✅ |
つまり RDMA は崖の③側＝箱の外の世界。箱の中は NVLink で、RDMA は使わない。
隠れた本丸：InfiniBand vs Ethernet の思想戦争
ここからが、ニュースの裏で起きている本当の戦いだ。
なぜ IB が使われてきたか
RDMA は「パケットが落ちる」を前提にしていない。落ちたら再送、という TCP 的な世界では困る。IB は最初からロスを出さない設計になっている。仕組みは credit-based flow control。
送信側は「受信側に空きバッファがある」と保証された分しか送らない。だから輻輳でパケットを落とす、が原理的に起きない。
俺の TCP world とは思想が逆だ。TCP は「とりあえず送る → 落ちたら再送」。IB は「落ちる状況を作らない」。RDMA とこの性質の相性が完璧だった。
IB が勝った理由 = ①ロスレス設計 ②RDMA ネイティブ ③低レイテンシ + ④ NVIDIA が Mellanox 買収で握っている政治
Ethernet の逆襲 (2 つの思想)
IB の弱点は技術ではなく政治と金だ。実質 NVIDIA 単独ベンダーでロックイン、高い、DC の他の部分は全部 Ethernet なのに AI 用だけ別エコシステム。ハイパースケーラーはこれを嫌う。Ethernet 陣営の攻め方は 2 ルートに分かれる。
- ルート①：Ethernet もロスレスにする。 RoCE (RDMA over Ethernet) を PFC + ECN でロスレス化し、IB の土俵で戦う。ただしこれが大規模で脆い。PFC は「詰まったら上流に止まれ」信号を送るが、GPU 1 万枚級だと head-of-line blocking (無関係なフローまで巻き込む)、congestion spreading (輻輳が芋づるで広がる)、最悪デッドロックを起こす。「パイプを完璧にする」路線は規模が上がるほどしんどい。
- ルート②：そもそもロスレスを諦める。 Ultra Ethernet Consortium (UEC、2023 年結成・2025 年に仕様 1.0) の発想がエレガントで、「Ethernet を完璧にロスレスにするのをやめ、トランスポートを賢くして多少のロス・順序入れ替えを許容して耐える」。中身は独自の賢い輻輳制御 + packet spraying / multipath (1 本に固めず何本もの経路にバラ撒いて束ねる＝俺の「ケーブル 15 本」直感の経路版) + 速い再送。これはインターネットがもともとそうやって動いている思想に近い。
おまけに NVIDIA 自身も Spectrum-X (AI 特化 Ethernet) を出していて、IB を売りながら Ethernet 移行にも保険をかけている。自分の堀が崩れる側にも賭けている、ということだ。
戦争の本質を一言でいうと、「パイプを神にする (IB) vs 落ちても平気な賢いトランスポートを作る (Ethernet)」。
※ UEC は仕様こそ出たが、大規模実戦投入はまだ立ち上がり段階。「もう Ethernet が勝った」は言い過ぎで、現時点では IB 優勢 + Ethernet が猛追くらいが正確だと思う。帯域の数値も H100 世代のざっくり値で、世代で変わる。
たとえ話
会社の全員で 1 個の巨大なパズルを組む、と考える。
- 各自が自分の担当ピースを組む (= GPU の計算)。
- ところが次の手に進むには、全員が今のピースの状態を共有して合わせないといけない (= all-reduce)。
- 同じ島 (= 同じサーバ、NVLink) の隣の人とは、机ごしに一瞬で見せ合える。
- 別フロアの人 (= 別サーバ、IB) とは、わざわざ書類にして運ぶ。この運搬が 15 倍遅い。
- そして全員の共有が終わるまで、誰も次の手に進めない。一番運搬が遅い 1 人を、全社が待つ。
「運ぶ人を 15 人に増やせばええやん」が崖を埋められない理由も、たとえに乗る。机の数 (NIC を挿せる口) が足りないし、エレベーター (スイッチ) が 15 人分の書類を同時に運べない。だから「別フロアをやめて、全員を 1 つの大部屋 (NVLink ドメイン 72 枚) に集める」のが GB200 の発想だ。
ニュースを読むための変換表
| ニュースの言葉 | つまり何の話？ |
|---|---|
| all-reduce | 学習で全 GPU の勾配を足し合わせて配り直す同期通信。詰まりの主役 |
| NVLink | 同じサーバ内の GPU↔GPU をつなぐシリコン直結ファブリック。箱の中、~900GB/s |
| InfiniBand (IB) | サーバ間 GPU 通信の定番。ロスレス設計 + RDMA ネイティブ。箱の外、~50GB/s/本 |
| RDMA / GPUDirect RDMA | CPU を飛ばして相手の HBM を直接読み書きする転送。③の実体 |
| RoCE | RDMA over Converged Ethernet。Ethernet 上で RDMA をやる方式 |
| PFC / ECN | Ethernet をロスレスにする輻輳制御。大規模だと脆い |
| Ultra Ethernet (UEC) | ロスを許容し賢いトランスポートで耐える Ethernet 陣営の標準化 |
| Spectrum-X | NVIDIA の AI 特化 Ethernet。IB を売りつつ Ethernet にも保険 |
| GB200 NVL72 | NVLink を箱の外へ延ばし 72 枚を 1 ドメインに。崖の位置を上へずらす |
| exposed communication | 通信を計算の裏に隠しきれず、はみ出して GPU を待たせる部分 |
崖と IB vs Ethernet の戦争まで掴んだ。次は設計者として「で、どっちを選ぶんや？」。
- AI クラスタのネットワークを選ぶ立場なら、IB で固めるか Ethernet (RoCE / UEC) で攻めるか。 判断軸は「規模での PFC の脆さ × ベンダーロックイン × 既存 DC との統一」。1,000 枚と 1 万枚で答えはどっちに転ぶか。
- 崖を「設計で避ける」なら、data / tensor / pipeline 並列をどう割り、どの通信を箱の中 (NVLink) に閉じ込めるか。 通信量が最小になる割り方を言えるか。
これに答えられると強い。「AI ネットワークが詰まる」を語れるの一歩先 ── 規模を見て IB か Ethernet かを自分で選べる側に立てる。俺の north-south (Front Door の世界) から east-west への越境そのものや。
- 並列化戦略 (data / tensor / pipeline parallel) の使い分け ── どう割るかで「箱の外をまたぐ通信量」が決まる。今回の崖を「設計でどう避けるか」の続き。一番自然な次の一歩。
- GB200 NVL72 の中身 ── NVLink を箱の外へ延ばす銅の背面板。「崖の位置をずらす」を物理で見る。
- NCCL と all-reduce のアルゴリズム (ring / tree) ── 同じ all-reduce でも経路の組み方で通信量とテールが変わる。詰まりを減らす実装側の工夫。
- PFC / ECN がなぜ大規模で壊れるか ── ネットワーク屋の本丸。head-of-line blocking や congestion spreading を輻輳制御の知識で精密に。
- DC をまたぐ学習 (崖の⑤) ── 1 つの DC に収まらない規模で、広域の崖をどう扱うか。最前線。