← 一覧へ戻る

Claude が書いた記事

GPU クラスターのレール最適化 ── 32 ポートなのに IB スイッチが 8 台もいる理由

1 ラックに GPU サーバー 4 台 × 8 GPU = 32 ポートなのに、なぜ IB スイッチ (InfiniBand スイッチ) が 8 台もいてポートはスカスカなんや？ ── AI クラスターの『レール最適化』を、8 本のパラレルワールドとして腹落ちするまでの学習ログ。

俺の最初の疑問

AI クラスターの構成図を眺めていて、算数が合わなくて引っかかった。

1 ラックに GPU サーバーが 4 台。1 台に GPU が 8 枚。GPU 1 枚につきネットワークの口 (ポート) が 1 個やから、ラック全体で 4 × 8 = 32 ポート。InfiniBand のスイッチは 1 台で 64 ポートある。

なら 64 ポートのスイッチ 1 台で 32 本ぜんぶ挿して余るやんけ。なんで IB スイッチが 8 台も並んでて、しかもポートがスカスカなんや？

「効率が悪い設計」にしか見えへんかった。ここを潰したら、AI ネットワークの形が一気に腹落ちした記録。

まず一言でいうと

スカスカはわざとやった。これを 「レール最適化 (rail-optimized)」 と呼ぶ。

各スイッチに、全サーバーの「同じ番号の GPU」だけを集める。 1 号スイッチには全サーバーの GPU1 のケーブルだけ。2 号スイッチには GPU2 だけ。これを 8 枚ぶん、8 台のスイッチに完全に分ける。

1 台のレールスイッチ (例: 64 ポート) をズーム。下りに刺さるのは同じラックの GPU1 が 4 本だけ。残り 60 ポートはわざと空けて、ぜんぶ Spine への上り (アップリンク) に回す。下り 4 本に対し上りが圧倒的に多い＝スカスカの正体。

つまり 1 台のスイッチには、ラック内 4 サーバーの GPU1 が 4 本しか刺さらない。残り 60 ポートは、わざと空けて上の Spine スイッチ行きにとっておく。 この「贅沢な空け方」こそが、数万台までフルスピードで伸ばすための芯やった。

何と比べるとわかるか

普段の俺の感覚 (north-south のネットワーク) と、AI クラスターは設計思想が真逆やった。

普段のネットワークレール最適化 (AI back-end)
ポートの埋め方空きが出ないよう詰める (コスト効率)わざとスカスカに空ける (渋滞回避)
スイッチの足し方足りなくなったら増やす最初から GPU の枚数 (8) ぶん並べる
何を最適化するか機器の利用率1 粒もパケットを落とさず全二重
通信相手不特定多数 (誰から来るか読めない)同番号 GPU に固定 (相手が決まっている)

普段は「ポートを埋める＝善」やのに、ここでは「ポートを空ける＝善」。この一発の逆転を飲み込めるかどうかが分かれ目やった。

何が問題なのか ── All-to-All という悪魔

なぜそこまでするのか。AI の学習には All-to-All (全対全) という凶悪な通信フェーズがあるから。

巨大なモデルは 1 枚の GPU に収まらんから、何千枚もの GPU に分割して計算させる (テンソル並列・パイプライン並列)。各 GPU が自分の担当を計算し終えた瞬間、「俺の結果を全員に配る、お前らの結果も全員ぶん同時にくれ」というフェーズが来る。これが All-to-All。

これは 「全員が、全員へ、別々の巨大データを、休まず同時に、全二重で送りつける」 という、帯域を 100% 使い切る通信パターン。途中に 1 箇所でも細い道があれば、そこで全 GPU が詰まって学習が止まる (ブロッキング)。GPU は計算を終えて通信待ちでボーッと遊ぶ。1 枚数百万円の GPU が遊ぶ＝金をドブに捨てる時間や。

なぜ「箱と箱のあいだ」が詰まるのか、待ち時間が金を捨てる話は AI のボトルネックは『箱と箱のあいだ』 で潰した。この記事はその先の「じゃあどう配線して渋滞を消すか」の話。

ここで俺が最初にハマった誤解がこれ。

All-to-All って、(GPU1〜8) × サーバー数 が、別の (GPU1〜8) × サーバー数 と、ごちゃ混ぜに全交差で通信するんちゃうの？

その通りにやったらパンクする。GPU の口は 1 個しかないのに、そこから全番号の GPU へ斜めにも横にも送ろうとすると、スイッチの中で経路の奪い合い (輻輳) が起きる。

ここで出てくる PFC (Priority Flow Control) を先に押さえておくと、あとの図がわかる。AI のバックエンドは「1 粒もパケットを落とさない (ロスレス)」のが鉄則で、スイッチのバッファが溢れそうになると、手前の機器へ「待て (PAUSE)」とブレーキをかけて送信を止めさせる。これが PFC や。落とさないための良い仕組みやけど、All-to-All でごちゃ混ぜに詰まると、A が B に「待て」、B も溢れて C に「待て」…と、ブレーキが上流へ芋づる式に連鎖する。最後はネットワーク全体が固まって動けなくなる (PFC デッドロック)。これが図の「PFC 連鎖で停止」の正体や。

レール最適化は、この「ごちゃ混ぜ」を 「同番号だけ」に絞って隔離する ことで渋滞を消す。テンソル並列・パイプライン並列というアルゴリズムの工夫が、通信相手を「同じ番号の GPU」に綺麗に落とし込んでくれている。だから物理的にもレールを分けられる。

図で見る

1. ごちゃ混ぜ (パンク) vs レール最適化 (レール間の衝突が消える)

同じ All-to-All でも、つなぎ方で天国と地獄。左のごちゃ混ぜは通信が交差してパンクし PFC 連鎖で停止。右のレール最適化は『1 番は 1 番とだけ』なので通信が交差せず、8 本 (図は 4 本) の独立した道路を並行して走る。だからレール同士は正面衝突せず、数万台までスケールできる (レール 1 本の中に残る混雑は別途さばく)。

2. 8 本のパラレルワールド

GPU 1 枚＝出口 1 個。同じ番号の GPU だけが同じレールに集まり、上空の Spine までプレーンごとに分離されたまま (ずっと InfiniBand)。各レールは同番号を 4 本だけ挿し、残りポートは Spine 行きに空ける (スカスカの正体)。一方、同じサーバーの中の隣の GPU 同士は外に出ず NVLink で直結。

混乱しやすいポイント

① 「スカスカ」は無駄やない ── 上り (アップリンク) のための空き

最初の引っかかりの答え。スイッチに GPU 4 個しか繋がないのは、残りを全部 Spine への上り (アップリンク) に使いたいから。AI 学習では「同じラック内の GPU 同士」で通信することはほぼない。相手は別ラックにいる何千・何万枚の GPU や。だから、入ってきた 4 本をぜんぶラックの外 (上の Spine) へ抜く帯域がいる。GPU 接続でポートを埋めてしまうと、外へ抜ける道 (アップリンク) が足りなくなる。

② なぜ「同番号だけ」で計算が成立するのか

「相手を同番号に絞ったら、全 GPU と話せてないやん」と思う。けど学習アルゴリズム (テンソル並列・パイプライン並列) が、データの配り方を工夫して 「同番号 GPU の集合の中での All-to-All」 に分解してくれている。世界中のサーバーの GPU1 (たとえば 3,000 枚) はレール1 の網の中だけで全対全を完結し、GPU2 はレール2 の中だけで完結する。8 本に割って負荷を並列化しているから、数万台規模でも正面からぶつかり合わずにさばける。

ただし「完全に衝突ゼロ」ではない。レール最適化が消すのはレール同士 (横方向) の衝突で、レール 1 本の中はまだ数千枚の GPU の All-to-All や。ここはノンブロッキングな Clos (クロス。スイッチを多段に積んで、網をどこで半分に割っても帯域が落ちないようにした設計。リーフ-スパイン構成の元になった古典で、略語やなく考案者 Charles Clos の名前) で帯域を足りるように組むが、それでも経路の選び方 (ECMP のハッシュ) がたまたま重なれば一時的な混雑は起きる。その残りは、トポロジーでなく 経路を動的に選び直す adaptive routing・スイッチ内で集計する SHARP・(イーサ側なら) UEC のパケットスプレー で吸収する。レールはあくまで「一番デカい構造的な衝突」を物理で消す土台や。

③ サーバー A の GPU1 と GPU2 は「別世界」

ここが一番スッキリした点。サーバー A の GPU1 が属する通信の世界と、GPU2 が属する世界は、物理スイッチも配線もパケットも一切交わらないパラレルワールド。専門用語で プレーン (plane) とか レール (rail) と呼ぶ。GPU1 → 専用ポート → 1 号レール、GPU2 → 専用ポート → 2 号レール、と箱を出る時点で出口が分かれている。

④ じゃあ隣の GPU とは話せないの？ → NVLink

同じサーバーの中の GPU1 と GPU2 がデータを合体したいときは、わざわざ外のスイッチに出て U ターンしない。サーバーの基板の上に NVLink という、外のレール (400G / 800G) より数倍〜十倍速い直結バスが敷いてある。外は混ぜずに並列、中は超高速で直結 ── この二重構造が芯。

⑤ 上空の Spine も「混ぜない」、しかも 2 系統ある

IB スイッチのアップリンクの先を「普通の光イーサネットでまとめる」と、せっかく 8 本に分けたレールが上空でごちゃ混ぜになって台無しになる。だから Spine も「1 号プレーン専用 Spine」「2 号プレーン専用 Spine」と分けたまま、端から端までずっと InfiniBand で通す (途中でイーサに変換すると低遅延が死ぬ)。

さらに GPU サーバーの裏には、この IB とは 別系統 のイーサネットも刺さっている。役割が違う。

  • back-end (InfiniBand): GPU 同士が計算結果を同期する専用の孤立した超高速道路。レール最適化の主役はこっち。
  • front-end (Ethernet): 学習データをストレージから読む・チェックポイントを保存する・管理画面と話す道路。こっちは普通のイーサ (SONiC 等)。

たとえ話

  • 8 車線の独立した高速道路: 1 本の広い道に全車を流す (ごちゃ混ぜ) と事故って全部止まる。番号で 8 本の別々の道に振り分け、各道を完全に並行して走らせると、全体は止まらない。
  • パラレルワールド: GPU1 の宇宙と GPU2 の宇宙は、同じ部屋にあるのに物理的に一切交わらない。8 個の宇宙が重なって存在している。
  • 社内便と公道: 同じ箱の中 (NVLink) は社内便で一瞬。箱をまたぐ (レール) のは公道に出て走る。用が隣の席なら社内便で済ませ、公道は混ぜない。

出てきた言葉の変換表

言葉つまり何の話？
レール最適化 (rail-optimized)同じ番号の GPU だけを 1 台のスイッチに集め、8 本の独立ネットワークに分ける設計
レール / プレーン1 本ぶんの独立した通信網。GPU1 用・GPU2 用…と 8 本が交わらず並行する
All-to-All (全対全)全 GPU が全 GPU へ別々のデータを同時に送り合う、帯域 100% の通信フェーズ
Full Bisection Bandwidthネットワークをどこで半分に割っても帯域が落ちない＝ノンブロッキングな設計
Clos (クロス)スイッチを多段に積んで全体で帯域を詰まらせない網。リーフ-スパインの元。略語でなく考案者 Charles Clos の名前
PFC (Priority Flow Control)バッファが溢れる前に手前へ「待て」とかけるブレーキ。落とさない代わり、詰まると連鎖して全体が固まる (PFC デッドロック)
ブロッキング / 輻輳途中の細い道で全体が詰まること。これを避けるのがレール最適化の目的
NVLink同じサーバーの中の GPU 同士を直結する超高速バス。外のレールには出ない
Spineレールの上空でラックをまたいで束ねる背骨スイッチ。プレーンごとに分離される
back-end / front-end ネットワークGPU 同期用の IB / データ読み込み・管理用の Ethernet。2 系統に分離する
深掘りメニュー 次におすすめのトピック

この記事の続きとして、未来の自分が次に掘るといいトピック。

  • InfiniBand の物理と冷却 ── レールを通すケーブル (ラック内メタル / ラック外光) と、1 発のロスで学習が全停止するから要る水冷の話。
  • RoCE / Ultra Ethernet ── 「ずっと IB」の対抗馬。パケットスプレーで全レールにばら撒く UEC が、レール最適化の前提をどう変えるか。
  • SONiC ── front-end や一部 back-end のスイッチの中身。レールを構成する箱そのものの正体。
  • GPUDirect / SmartNIC ── レールの出入口。CPU を飛ばして GPU メモリへ直接読み書きする仕組み。