AIインターコネクト — NVLink、NVSwitch、UALink、そしてスケールアップの技術

• はじめに
• 分散学習と推論の通信ボトルネック
• スケールアップ vs スケールアウト
• NVLinkとNVSwitchの原理
• NVLinkドメインとラックスケール — GB200 NVL72
• UALinkとUltra Ethernet — オープンな代替
• ネットワークトポロジ — fat-tree、dragonfly、rail-optimized
• 集合通信 — all-reduce、ring vs tree
• 演算と通信のオーバーラップ
• ネットワークが学習効率を分ける
• 未来 — より大きなドメイン、光、オープン化
• 開発者への示唆
• All-reduce通信時間を計算してみる
• NVLink世代とNVSwitchドメイン規模
• Google TPUの光回路スイッチ(OCS)
• コンピュート-通信オーバーラップをさらに深く — FSDPプリフェッチ
• 実務チェックリスト — NCCLチューニングとトポロジ認識
• おわりに
• 参考資料

はじめに

GPU一つの演算性能を語るとき、私たちはしばしばTFLOPSのような数値に注目します。しかし、数千枚、数万枚のGPUを束ねて一つの巨大なモデルを学習させる時代に入ると、システム全体の性能を決めるのは個々のGPUの演算能力ではなく、GPUとGPUをつなぐインターコネクト(interconnect)、すなわち通信経路になりました。

少し大げさに言えば、2026年の大規模AIインフラ競争は「誰がより速いチップを作るか」の競争ではなく、「誰がより多くのチップを損失なく一つのように束ねるか」の競争です。NVIDIAがBlackwell世代でGB200 NVL72というラックスケールシステムを前面に押し出した理由も、AMDやBroadcom、GoogleなどがUALinkコンソーシアムを作った理由も、GoogleがTPUに光回路スイッチ(OCS)を導入した理由も、すべて同じところを向いています。それは、通信ボトルネックをいかに減らすか、ということです。

本記事では、分散学習と推論において通信がなぜボトルネックになるのかから始め、スケールアップとスケールアウトの違い、NVLinkとNVSwitchの原理、GB200 NVL72のようなNVLinkドメイン、UALinkやUltra Ethernetといったオープンな代替、ネットワークトポロジと集合通信(collective communication)、そして演算と通信のオーバーラップまでを順を追って整理していきます。ハードウェアエンジニアではなく、モデルを学習しサービングする開発者の視点から、「なぜGPUを増やしても私の学習は速くならないのか」という問いに答えることを目標とします。

分散学習と推論の通信ボトルネック

まず直観をつかみましょう。一つのモデルを複数のGPUに分けて学習するとき、各GPUは自分の担当分の計算を終えたあと、必ず他のGPUと結果をやり取りしなければなりません。データ並列(data parallelism)では、各GPUが異なるデータバッチで勾配を計算したあと、それらをすべて合算して平均を取る必要があります。この処理があの有名なall-reduceです。テンソル並列(tensor parallelism)では、一つの行列積が複数のGPUに分割されているため、レイヤーごとに中間結果を交換しなければなりません。

問題は、演算はどんどん速くなるのに、通信はそれほど速くならないという点にあります。GPUの浮動小数点演算性能は世代ごとに急峻に上がってきましたが、チップの外へデータを送り出す帯域幅は物理的制約のために同じ速度では追いつけません。その結果、演算対通信の比率(compute-to-communication ratio)が悪化し、GPUが通信を待って遊ぶ時間が増えていきます。

これを簡単なモデルで表すと次のようになります。

1ステップの時間 ≈ max(演算時間, 通信時間)            (完全に重なるとき)
1ステップの時間 ≈ 演算時間 + 通信時間                (まったく重ならないとき)

通信時間 ≈ 転送すべきバイト数 / 有効帯域幅 + 遅延(latency)

ここで核心は「有効帯域幅」です。カタログに書かれた最大帯域幅と、実際に集合通信を回したときに出る帯域幅の間には、いつも隔たりがあります。トポロジ、メッセージサイズ、通信ライブラリのアルゴリズム選択、そして他のトラフィックとの競合が、すべてこの隔たりを生み出します。

大規模学習において通信が占める割合は決して小さくありません。数千GPU規模で、データ並列のall-reduceとテンソル並列の通信を合わせると、うまくチューニングされていない場合、全体のステップ時間の30パーセントから半分以上を通信が食ってしまうこともあります。推論でも同様です。巨大モデル一つを複数のGPUに広げてサービングするとき、トークン一つを生成する遅延時間はテンソル並列の通信遅延に大きく左右されます。特に2026年に入って推論capexが学習capexを初めて追い越した状況では、推論経路の通信効率は直接的なコスト問題になりました。

スケールアップ vs スケールアウト

インターコネクトを理解する最初の軸は、スケールアップ(scale-up)とスケールアウト(scale-out)の区別です。

スケールアップは、一つの緊密に結合されたドメインの中でGPU数を増やすことです。一つのサーバノード内の複数のGPU、あるいは一つのラック内の数十個のGPUを非常に速い専用リンクで束ね、まるで一つの巨大なGPUのように動作させます。NVIDIAのNVLink、NVSwitchが代表的で、オープンな代替としてUALinkがここに属します。スケールアップドメインの中では帯域幅が非常に大きく遅延が非常に小さいため、テンソル並列のように通信が頻繁な並列化手法を存分に使えます。

スケールアウトは、複数のノード、複数のラックをデータセンターネットワークで接続し、数百、数千、数万GPU規模に拡張することです。InfiniBandやイーサネットがここで使われ、オープン標準陣営ではUltra Ethernet Consortium(UEC)がこの領域を狙います。スケールアウトのリンクはスケールアップのリンクより帯域幅が小さく遅延が大きいです。そのため、通信があまり頻繁でないデータ並列やパイプライン並列をこの層に配置するのが普通です。

二つの軸を表で比較すると次のようになります。

実務ではこの二つを階層的に組み合わせます。一つのNVLinkドメインの中にテンソル並列を置き、ドメインの間をデータ並列とパイプライン並列でつなぐ、という具合です。この配置が通信量と通信位置を決め、結局は学習効率を左右します。

NVLinkとNVSwitchの原理

ここでスケールアップインターコネクトの代表格であるNVLinkとNVSwitchを覗いてみましょう。

NVLinkは、GPU同士を直接接続するNVIDIAの高速リンクです。PCIeを通じてCPUを経由せず、GPU同士が点対点でデータをやり取りします。各GPUには複数のNVLink「レーン」の束があり、これを他のGPUやスイッチに接続します。世代を重ねるごとにリンクあたりの信号速度とリンク数が増え、GPU一枚が外部とやり取りできる総帯域幅が着実に大きくなりました。

世代別のおおよそのGPUあたり双方向NVLink帯域幅は次のとおりです。正確な数値は製品や構成によって異なるため、傾向を見る用途として参考にしてください。

世代が上がるたびに帯域幅が実質ほぼ2倍に増えてきた点は注目に値します。Blackwell世代の第5世代NVLinkはGPU一枚あたり約1.8 TB/sに達しますが、これは一般的なスケールアウトネットワークのポート帯域幅より一桁から二桁大きい値です。同じドメインの中にいるか外にいるかが、なぜそれほど大きな差を生むのかが分かる部分です。

ところが、GPUを二つずつ直接接続する方式だけでは限界があります。GPUが8枚にもなれば、すべてのペアを直接つなぐのは非効率で、それ以上に多くなればほぼ不可能です。ここでNVSwitchが登場します。NVSwitchはNVLinkトラフィックを交換する専用スイッチチップで、ドメイン内のすべてのGPUがまるで互いに直接接続されているかのように均一な帯域幅で通信できるようにします。いわゆる「all-to-all」のノンブロッキング(non-blocking)トポロジをNVLinkドメインの中で実装するわけです。

NVSwitchを備えたノードの構造を単純化すると次のようになります。

        +--------+   +--------+   +--------+   +--------+
        | GPU 0  |   | GPU 1  |   | GPU 2  |   | GPU 3  |
        +---+----+   +---+----+   +---+----+   +---+----+
            |            |            |            |
        ====+============+====NVLink==+============+====
            |            |            |            |
        +---+------------+------------+------------+---+
        |               NVSwitch  fabric              |
        +---+------------+------------+------------+---+
            |            |            |            |
        ====+============+====NVLink==+============+====
            |            |            |            |
        +---+----+   +---+----+   +---+----+   +---+----+
        | GPU 4  |   | GPU 5  |   | GPU 6  |   | GPU 7  |
        +--------+   +--------+   +--------+   +--------+

この構造のおかげで、ノード内のどのGPUペアでも同一のフル帯域幅で通信でき、all-reduceのような集合通信がトポロジに足を引っ張られません。テンソル並列をNVLinkドメインの中に置くのが定石になった理由です。

NVLinkドメインとラックスケール — GB200 NVL72

NVSwitchの真の力は、一つのノードを越えてラック全体へ拡張されたときに現れます。NVIDIAのGB200 NVL72はその頂点にあるシステムです。

GB200 NVL72は、一つのラックの中に72個のBlackwell GPUを収め、これらをNVSwitchベースの単一のNVLinkドメインで束ねます。つまり、ラック内の72個のGPUがすべてNVLink帯域幅で互いに通信できます。伝統的にNVLinkドメインは一つのノード(通常8 GPU)の中に閉じ込められており、その外はより遅いスケールアウトネットワークでした。NVL72はこの境界をラック全体へと押し広げました。72個のGPUが一つの大きなGPUのように動作するわけです。

これがなぜ重要なのでしょうか。巨大モデルを学習またはサービングするとき、テンソル並列とエキスパート並列(MoEのexpert parallelism)は通信が非常に頻繁で、スケールアウトネットワークの上では効率が大きく落ちます。ところがNVLinkドメインが72 GPUに大きくなれば、こうした重い通信パターンをすべて速いドメインの中に閉じ込められます。特にMoEモデルでトークンを複数のエキスパートにルーティングするall-to-all通信がNVLinkドメインの中で起きれば、推論遅延とスループットが劇的に改善します。

ラックスケールシステムを単純化すると次のような図になります。

   GB200 NVL72  (単一NVLinkドメイン、72 GPU)
   +-----------------------------------------------+
   |  コンピュートトレイ x N  (各トレイ: Grace CPU +|
   |                      Blackwell GPU)            |
   |        |        |        |        |            |
   |   +----+--------+--------+--------+----+       |
   |   |     NVSwitchトレイ (バックプレーン)    |  |
   |   +----+--------+--------+--------+----+       |
   |        |        |        |        |            |
   |  ...すべてのGPUがフルNVLink帯域で接続...        |
   +-----------------------------------------------+
            |  (スケールアウト: イーサネット / InfiniBand)
            v
   他のラック群 (数千GPU規模クラスター)

ラック単位で見ると、NVLinkドメインはスケールアップの境界であり、その外へ複数のラックをつなぐのはスケールアウトの領域です。次世代のVera Rubinは2026年末の登場が予告されており、HBM4メモリとともにワットあたり性能を大幅に引き上げることを目標としています。インターコネクトもこの流れに合わせて、より大きなドメインとより高い帯域幅へと進化しています。

UALinkとUltra Ethernet — オープンな代替

NVLinkとNVSwitchは強力ですが、NVIDIA独自技術です。単一ベンダーに縛られることを懸念する陣営は、オープン標準を推し進めてきました。

**UALink(Ultra Accelerator Link)**は、スケールアップインターコネクトのオープンな代替です。AMD、Broadcom、Googleを含む複数の会社がUALinkコンソーシアムを構成し、複数ベンダーのアクセラレータを一つのスケールアップドメインに束ねられる共通規格を作っています。目標は明確です。NVLinkがNVIDIAのエコシステムの中で果たすことを、オープンでマルチベンダーな方式で成し遂げることです。UALinkが成熟すれば、アクセラレータ製造者とスイッチ製造者が分離して競争できるエコシステムが開かれます。

**Ultra Ethernet(UEC, Ultra Ethernet Consortium)**は、スケールアウト領域を狙ったオープン標準です。既存のイーサネットをAI/HPCワークロードに合わせて改善し、InfiniBandが占めてきた高性能スケールアウト領域を標準イーサネットのエコシステムへ持ってこようとする試みです。より良い輻輳制御、より効率的なマルチパス転送、集合通信のための最適化などが核心です。

三つの陣営を整理すると次のようになります。

ここにもう一つ興味深いアプローチがGoogleのTPUです。GoogleはTPU同士をICI(Inter-Chip Interconnect)で接続し、これに光回路スイッチ(OCS, Optical Circuit Switch)を組み合わせてトポロジを動的に再構成します。電気パケットスイッチの代わりに光経路そのものを差し替えることで、障害が起きたノードを迂回したり、ジョブに合ったトポロジを構成したりする柔軟性を得ます。TPU v6 Trilliumは直前世代比でピーク性能を約4.7倍引き上げ、第7世代のIronwoodは推論に焦点を当てた世代として位置づけられました。

こうした流れの背景には、クラウド事業者によるカスタムASICの普及があります。推論用ASICのシェアは2024年の約15パーセントから2026年には約40パーセント水準へと急速に増えると見込まれています。NVIDIAがアクセラレータ市場の約75から80パーセントを握り、AMD MI350Xなどが挑戦する構図ですが、インターコネクト標準をめぐる競争はそれよりはるかに多層的です。

ネットワークトポロジ — fat-tree、dragonfly、rail-optimized

スケールアウト領域に出ると、トポロジ設計が重要になります。トポロジとは、ノードとスイッチをどう接続するかの設計図であり、同じ数のGPUとケーブルでも、トポロジによって集合通信の性能が大きく変わります。

**Fat-tree(クロス、Clos)**は最も広く使われる構造です。複数段のスイッチを階層に積み、上に上がるほどリンクを太くして、どの二つのノードの間でも十分な帯域幅を保証します。理想的にはノンブロッキング(non-blocking)の二分割帯域幅(bisection bandwidth)を提供し、すべてのノードが同時に通信してもボトルネックがありません。ただし段数が増えるとスイッチとケーブルのコストが急増します。

Dragonflyは、グループを作り、グループ内は密に、グループ間は少数の長いリンクでつなぐ構造です。大規模でケーブルとスイッチのコストを抑えるのに有利ですが、グループ間リンクが少ないため特定のトラフィックパターンで輻輳が生じることがあり、適応型ルーティングが重要です。

Rail-optimizedトポロジは、AI学習に特化した配置です。各ノードのi番目のNIC(レール)を同じレール専用スイッチに集めます。すると、データ並列all-reduceのように「同じ順番のGPU同士」が通信するパターンが単一ホップで終わり、スイッチ段数を減らして帯域幅を最大に活かせます。

三つのトポロジを比較すると次のようになります。

トポロジ選択は抽象的な話ではありません。同じGPU数でも、トポロジによって実際の学習スループットが数十パーセントずつ変わることもあります。

集合通信 — all-reduce、ring vs tree

分散学習通信の主役は集合通信(collective communication)です。その中でもall-reduceが最も重要です。all-reduceは、すべてのGPUが持つテンソルを要素ごとに合算(あるいは平均)したあと、その結果を再びすべてのGPUに分配する演算です。データ並列学習で勾配を合わせる、まさにその演算です。

all-reduceを実装する方式はいくつかありますが、代表的にring方式とtree方式があります。

Ring all-reduceは、GPUを論理的な輪に並べ、データを刻んで輪に沿って回します。二つの段階に分かれます。まずreduce-scatter段階で各GPUが自分の担当する刻みの合計を集め、続いてall-gather段階でその合算結果を全員に広げます。ring方式の長所は、通信量がGPU数にほぼ無関係に一定だという点です。

ring all-reduceの流れを擬似コードで書くと次のようになります。

# ring all-reduce 概念 (N個のGPU、各自が長さNのチャンク配列を持つ)
# 段階1: reduce-scatter
for step in range(N - 1):
    send_chunk = (rank - step) % N
    recv_chunk = (rank - step - 1) % N
    send(buffer[send_chunk], to=(rank + 1) % N)
    incoming = recv(from=(rank - 1) % N)
    buffer[recv_chunk] += incoming   # 部分和を累積

# この時点で各GPUは互いに異なる一つのチャンクの '完全な合計' を持つ

# 段階2: all-gather
for step in range(N - 1):
    send_chunk = (rank - step + 1) % N
    recv_chunk = (rank - step) % N
    send(buffer[send_chunk], to=(rank + 1) % N)
    buffer[recv_chunk] = recv(from=(rank - 1) % N)

# 終了後、すべてのGPUが同一の '全体合計' を保有

ring all-reduceで各GPUがやり取りするデータの総量は、おおよそ次のようになります。

GPUあたり転送量 ≈ 2 x (N - 1) / N x (テンソルサイズ)
            ≈ 2 x (テンソルサイズ)        (Nが大きいとき)

つまり、GPU数Nがいくら大きくなっても、GPUあたりの転送量はテンソルサイズの約2倍に収束します。帯域幅の観点で非常に効率的なため、大規模データ並列に広く使われます。ただし段階数がNに比例して増えるため、小さなメッセージでは遅延が累積するという短所があります。

Tree all-reduceは、ツリー構造で合算と分配を行います。段階数がNの対数に比例し、メッセージが小さいかGPU数が多いときに遅延の面で有利です。一方、帯域幅効率はringより落ちることがあります。

実務ではライブラリがメッセージサイズとトポロジを見て、二つの間から自動でアルゴリズムを選びます。NVIDIAのNCCL、そして他の集合通信ライブラリがこの仕事をしてくれます。開発者が暗記するよりも、「ライブラリがトポロジを正確に認識するよう環境をうまく構成すること」のほうが重要です。

reduce-scatterとall-gatherを別々に使うパターンもますます重要になっています。ZeROやFSDP系のメモリ節約手法は、all-reduceをreduce-scatterとall-gatherに分解し、パラメータと勾配をシャーディングしながら通信を行います。通信パターンを理解すれば、なぜ特定の並列化戦略が特定のトポロジで速いのかが自然に見えてきます。

演算と通信のオーバーラップ

通信をいくら速くしても、通信が0になることはありません。そこで二つ目の戦略が登場します。それは、通信を演算の後ろに隠すこと、すなわち演算と通信のオーバーラップ(overlap)です。

核心となるアイデアは単純です。あるGPUが次のレイヤーの勾配を計算している間に、すでに終わった前のレイヤーの勾配をバックグラウンドでall-reduceで送るのです。通信を別のストリームで非同期に回し、演算が進む時間の後ろに通信を隠します。うまく重ねれば、通信時間が事実上タダのように感じられます。

逆伝播でのオーバーラップを単純化すると次のようになります。

# 逆伝播で勾配通信を演算の後ろに隠す (概念)
for layer in reversed(layers):
    grad = compute_gradient(layer)        # 演算ストリーム
    handle = async_all_reduce(grad)       # 通信ストリームで非同期に開始
    pending.append((layer, handle))
    # 次のレイヤーの演算がすぐ続き、通信はバックグラウンドで進む

for layer, handle in pending:
    handle.wait()                         # 必要なときだけ完了を待つ
    apply_update(layer)

オーバーラップがうまくいくには、いくつかの条件が揃う必要があります。通信ストリームと演算ストリームが同じリソースを巡って激しく競合しないこと、勾配を適度なサイズにまとめて(bucketing)あまりに小さな通信が頻繁にならないようにすること、そして通信を開始する時点と結果を待つ時点の間に十分な演算があることです。フレームワークはこうしたバケッティングと非同期通信を標準で提供しますが、モデル構造と並列化設定に応じてチューニングが必要です。

オーバーラップの効果を時間軸で描くと次のようになります。

オーバーラップなし:
  [演算 L1][通信 L1][演算 L2][通信 L2][演算 L3][通信 L3]   <- 通信がそのまま足される

オーバーラップあり:
  [演算 L1][演算 L2][演算 L3]
           [通信 L1][通信 L2][通信 L3]                     <- 通信が演算の後ろに隠れる
  結果として全体の時間が短くなる

ここで再びインターコネクトが登場します。ドメイン内の帯域幅が十分に大きければ、通信が短くなって演算時間の中により簡単に隠れます。逆に帯域幅が不足すると、通信が演算より長くなり、いくら非同期で回しても通信の尻尾が露わになります。結局、ハードウェアの帯域幅とソフトウェアのオーバーラップは互いを補完する一対です。

ネットワークが学習効率を分ける

ここまでの話を一文に要約すると、ネットワークがすなわちスケーリング効率を決めるということです。これをスケーリング効率(scaling efficiency)という指標で考えてみましょう。

スケーリング効率 = (N個のGPUでのスループット) / (1個のGPUスループット x N)

理想 = 1.0 (線形スケーリング)
現実 = 通信オーバーヘッド、負荷不均衡、オーバーラップの限界のため1.0より小さい

GPUを2倍に増やしたのにスループットが2倍にならないのは、ほとんど常に通信のせいです。通信が占める割合が大きいほど、同じGPU追加で得られる利得が減ります。だからインターコネクトが貧弱なクラスターは、GPUをいくら買い集めても、一定規模を超えると効率が崩れます。

ここでNVLinkドメインを大きくする戦略の意味が明確になります。通信が最も頻繁なテンソル並列とエキスパート並列を速いNVLinkドメインの中に閉じ込めれば、スケールアウトネットワークには通信があまり頻繁でないデータ並列とパイプライン並列だけが残ります。GB200 NVL72が72 GPUを一つのドメインに入れたのは、重い通信をより大きな速い領域の中に閉じ込めてスケーリング効率を引き上げようとする設計なのです。

おおよその直観を表に整理すると次のようになります。

この表は精密な測定値ではなく、感覚をつかむためのものです。核心は、通信の割合を減らすあらゆる努力、すなわちより大きなドメイン、より良いトポロジ、より賢い集合通信、より緻密なオーバーラップが、そのままスケーリング効率につながるという点です。

未来 — より大きなドメイン、光、オープン化

インターコネクトの未来は、いくつかの方向に収束します。

第一に、ドメイン拡張です。一つのノードの8 GPUからラックの72 GPUへと大きくなったNVLinkドメインは、今後さらに大きくなる可能性が高いです。ドメインが大きくなるほど、重い通信をより多く速い領域の中に閉じ込められるからです。Vera Rubin世代はこの流れの次の章を予告します。

第二に、**光インターコネクト(optical interconnect)**です。電気信号でケーブルを長く引くと、電力と信頼性で限界がきます。光はより遠い距離をより少ない電力でつなぎ、GoogleのOCSのようにトポロジを動的に再構成する柔軟性まで与えます。コパッケージド光学(co-packaged optics)がスイッチとアクセラレータに近づいて入ってくれば、帯域幅と電力効率の新しい章が開かれます。

第三に、オープン標準の成熟です。UALinkとUltra Ethernetが定着すれば、アクセラレータとスイッチが分離して競争するエコシステムが作られます。単一ベンダー依存を減らしたいクラウド事業者にとって、これは戦略的に重要です。推論ASICのシェア拡大と相まって、インターコネクト標準の競争は今後さらに激しくなるでしょう。

第四に、推論中心への重心移動です。2026年に推論capexが学習capexを追い越し、インターコネクト設計の優先順位も変わっています。学習はスループットが、推論は遅延が重要なので、小さなメッセージの低遅延通信とMoEのall-to-allルーティングがますます重要な設計目標になります。

開発者への示唆

ハードウェアエンジニアでなくても、モデルを学習しサービングする開発者がインターコネクトから得るべき実務的な示唆は明確です。

第一に、**並列化戦略をトポロジに合わせてください。**通信が最も頻繁なテンソル並列とエキスパート並列はNVLinkドメインの中に置き、データ並列とパイプライン並列をドメインの間に配置するのが基本です。この配置を逆にすると、速いドメインを遊ばせて遅いネットワークを酷使することになります。

第二に、**通信ライブラリがトポロジをきちんと認識するようにしてください。**NCCLのようなライブラリはトポロジを見てアルゴリズムを選びます。環境変数とトポロジ情報が誤っていると、最適でない経路をたどります。プロファイリングで実際の集合通信帯域幅を測定し、カタログ値との隔たりを疑う習慣が必要です。

第三に、**オーバーラップを測定してください。**フレームワークがオーバーラップをオンにしたからといって、実際にうまく重なるとは限りません。通信が演算の後ろにきちんと隠れているかをタイムラインプロファイラで確認し、バケットサイズと非同期設定を調整してください。

第四に、**スケーリング効率を指標にしてください。**GPUを増やすたびにスループットが比例して伸びるかを測定し、効率が崩れる地点を探してください。その地点こそがインターコネクトがボトルネックになるところであり、並列化の再配置やより大きなドメインが必要だという信号です。

第五に、**通信量そのものを減らすアルゴリズムを検討してください。**勾配圧縮、より大きなマイクロバッチ、通信頻度を減らす学習手法などは、すべて通信ボトルネックを緩和します。ハードウェアを変えずに効率を引き上げる余地がここにあります。

All-reduce通信時間を計算してみる

ここまで抽象的に扱ってきた通信時間を実際の数値で計算してみると、感覚がずっとつかみやすくなります。データ並列学習で、1ステップの勾配all-reduceにかかる時間を見積もってみましょう。

先に見たように、ring all-reduceで各GPUがやり取りするデータの総量はテンソルサイズの約2倍です。モデルのパラメータ数をP、パラメータあたりの勾配バイト数をBとすると、all-reduceすべきテンソルのサイズはP掛けるBバイトです。したがってGPUあたりの転送量はその2倍に近くなります。

ここに有効帯域幅と遅延を入れれば、1ステップの通信時間を見積もれます。具体的な数値を入れて計算する過程をコードで書くと次のようになります。

# all-reduce通信時間の見積もり (概念的な計算)
params = 70e9          # パラメータ数 (例: 70Bモデル)
bytes_per_param = 2    # bf16勾配はパラメータあたり2バイト
tensor_bytes = params * bytes_per_param        # all-reduce対象のサイズ

# ring all-reduceでGPUあたり転送量 ~ 2倍
per_gpu_bytes = 2 * tensor_bytes

link_bw = 1.8e12       # 有効帯域幅1.8 TB/s (Blackwell NVLinkを仮定)
scaleout_bw = 50e9     # スケールアウト有効帯域幅50 GB/sを仮定

t_nvlink = per_gpu_bytes / link_bw     # NVLinkドメインの中で
t_scaleout = per_gpu_bytes / scaleout_bw  # スケールアウトネットワークで

print("all-reduce対象:", tensor_bytes / 1e9, "GB")
print("GPUあたり転送量:", per_gpu_bytes / 1e9, "GB")
print("NVLink通信時間:", t_nvlink * 1000, "ms")
print("スケールアウト通信時間:", t_scaleout * 1000, "ms")

70Bモデルのbf16勾配は約140 GBで、GPUあたりの転送量は約280 GBです。有効帯域幅1.8 TB/sのNVLinkドメインの中では約0.16秒、有効帯域幅50 GB/sのスケールアウトネットワークでは約5.6秒かかります。同じ通信がドメインの中か外かによって数十倍の差になるわけです。この単純な計算一つが、なぜ誰もがNVLinkドメインを大きくしようとするのかをそのまま示しています。

もちろん実際には勾配をバケットに分けて演算と重ねるため、上の通信時間全体がそのままステップ時間に足されるわけではありません。しかし通信量そのものが減らなければ、オーバーラップが隠せる限界も確かに存在します。

NVLink世代とNVSwitchドメイン規模

先に見た世代別の帯域幅表を少し拡張し、NVSwitchが束ねるドメイン規模まで一緒に見ると、流れがより鮮明になります。以下の数値は製品や構成によって異なるため、傾向を見る用途として参考にしてください。

注目すべきは、帯域幅が大きくなっただけでなく、一つのドメインに入るGPU数も一緒に大きくなったという事実です。8 GPUノードに閉じ込められていたNVLinkドメインが、Blackwell世代でラック全体の72 GPUに拡張されたことは、単なる帯域幅の増加よりも本質的な変化です。重い通信を閉じ込められる速い領域のサイズが、まるごと大きくなったからです。

Google TPUの光回路スイッチ(OCS)

NVIDIAが電気ベースのNVSwitchでドメインを大きくする一方で、Googleはまったく異なる道を選びました。それが光回路スイッチ(OCS, Optical Circuit Switch)です。

一般的なデータセンタースイッチは電気パケットスイッチです。入ってきたパケットを電気信号で受け取り、宛先を読み、適切なポートへ送り出します。パケットごとに電気-光変換とルーティング判断が起きるため、帯域幅が大きくなるほど電力と遅延の負担が増えます。一方OCSはパケットを覗きません。ただ入力光ファイバと出力光ファイバを小さな鏡(MEMS)で物理的に接続するだけです。一度経路が設定されれば光が変換なしにそのまま通過するため、帯域幅に無関係に電力がほぼ一定で、遅延が非常に小さいです。

代わりにOCSはパケット単位で経路を変えられません。経路を変えるには鏡を再整列する必要があり、ミリ秒単位の時間がかかります。そのためOCSはトラフィックを刻々とスイッチングする用途ではなく、ジョブに合わせてトポロジそのものを再構成する用途で使われます。TPUポッドにあるジョブが入ってくると、OCSが必要なTPUを望む形(例: 3次元トーラス)に接続し、ジョブが終わると再びほどいて別のジョブに再配置します。

電気スイッチングと光回路スイッチングの違いを図で描くと次のようになります。

電気パケットスイッチ:
  光 -> [電気変換] -> [パケットルーティング] -> [電気変換] -> 光
        (パケットごとに変換と判断、帯域幅が大きいほど電力増加)

光回路スイッチ(OCS):
  光 ============ [MEMS鏡で経路を接続] ============ 光
        (変換なしに光がそのまま通過、トポロジを再構成)

  ジョブA: TPUを3Dトーラスに接続
  ジョブB: 別のTPU集合を別の形に接続
  障害ノード: 鏡を再整列して迂回

この柔軟性のおかげで、Googleは障害が起きたTPUをトポロジから外して予備ノードに入れ替えたり、ジョブ規模に合わせてポッドを切り出して使ったりすることを、まるでソフトウェアのように行えます。電気スイッチ中心の固定トポロジと比べると、運用の柔軟性と電力効率で明確な強みです。

コンピュート-通信オーバーラップをさらに深く — FSDPプリフェッチ

先に逆伝播でのオーバーラップを見ましたが、最新のメモリ節約学習では順伝播でもオーバーラップが重要です。FSDP(Fully Sharded Data Parallel)はパラメータをGPUにシャーディングしておき、あるレイヤーを計算する直前にall-gatherでそのレイヤーの全パラメータを集めます。計算が終わると再び捨ててメモリを節約します。

ここで核心は「次のレイヤーのパラメータを前もって取得する(prefetch)」ことです。現在のレイヤーを計算している間に、次のレイヤーに必要なパラメータのall-gatherをバックグラウンドで前もって始めておけば、次のレイヤーの計算が始まるときには通信がすでに終わっています。概念をコードで書くと次のようになります。

# FSDP順伝播でのパラメータプリフェッチ・オーバーラップ (概念)
def forward(layers, x):
    handle = async_all_gather(layers[0].shard)   # 最初のレイヤーのパラメータを集める
    for i, layer in enumerate(layers):
        handle.wait()                            # 現在のレイヤーのパラメータ準備完了
        params = layer.full_params

        if i + 1 < len(layers):
            # 次のレイヤーのパラメータを前もってバックグラウンドで集める
            handle = async_all_gather(layers[i + 1].shard)

        x = layer.compute(x, params)             # 現在のレイヤーを計算 (通信と重なる)
        layer.free_full_params()                 # メモリを回収
    return x

こうすると通信(all-gather)が演算(layer.compute)の後ろに隠れ、通信遅延が計算時間の中に吸収されます。ただしプリフェッチを遠くまでしすぎるとその分メモリを多く使うため、通常は1つか2つ先のレイヤーだけを前もって取得します。ここでもドメインの帯域幅が十分に大きくなければall-gatherが短くならず計算の中にうまく隠れない、という点は同じです。

実務チェックリスト — NCCLチューニングとトポロジ認識

先に扱った開発者への示唆をそのまま実行に移せるよう、分散学習をセットアップするときに点検する項目をチェックリストとして整理します。

• トポロジ認識の確認: 通信ライブラリがノード内のNVLink/NVSwitch構造とノード間ネットワークを正確に認識しているか確認してください。トポロジファイルや自動検出がずれると、最適でない経路をたどります。
• NICとGPUの親和性(affinity)の整合: 各GPUが物理的に近いNICを使うよう親和性を合わせてください。ずれると通信が不必要にCPUソケットをまたぎます。
• 集合通信帯域幅の実測: 学習コードの前にマイクロベンチマークでall-reduce帯域幅を測定し、カタログ値に対してどれだけ出るか確認してください。有効帯域幅が期待より低ければ、設定の問題である可能性が高いです。
• アルゴリズム選択の点検: メッセージサイズに応じてringとtreeのうち適切なアルゴリズムが選ばれているか確認し、必要なら環境変数で誘導してください。
• バケットサイズの調整: 勾配バケットが小さすぎると通信オーバーヘッドが増え、大きすぎるとオーバーラップの機会が減ります。モデルに合った適正サイズを見つけてください。
• オーバーラップのタイムライン確認: プロファイラで通信が実際に演算の後ろに隠れているかを目で確認してください。通信の尻尾が露わになれば、バケットと非同期設定を見直してください。
• 並列化次元の配置点検: テンソル/エキスパート並列がNVLinkドメイン境界の中に入っているか、データ/パイプライン並列がスケールアウトに置かれているか確認してください。
• スケーリング効率の追跡: GPU数を増やすたびにスループットが比例して伸びるか記録し、効率が折れる地点をボトルネックの信号としてください。

このチェックリストは特定のライブラリに限定されない一般原則です。核心は「ハードウェアが持つ帯域幅をソフトウェアが最後まで引き出せているか」を常に疑い測定する姿勢です。

おわりに

AIインフラの競争がチップ単位からシステム単位へ移っていくにつれ、インターコネクトはもはや背景インフラではなく、性能を分ける核心的な変数になりました。NVLinkとNVSwitchが作るスケールアップドメイン、GB200 NVL72のようなラックスケールシステム、UALinkやUltra Ethernetといったオープンな代替、そしてGoogle TPUの光回路スイッチまで、すべてが同じ問いに異なる答えを出しています。「どうやってより多くのアクセラレータを損失なく一つのように束ねるか」という問いです。

開発者にとってこのすべての話が与える教訓は一つに収束します。演算だけを見るのではなく通信を見よ、ということです。通信を理解すれば、なぜある学習はGPUを増やしても速くならないのか、なぜある推論は遅延が長くなるのか、なぜ同じモデルが異なるクラスターでまったく違う効率を出すのかが見え始めます。そしてその理解こそが、より速くより安価なAIシステムを作る出発点になります。

参考資料

• NVIDIA公式サイト
• NVIDIA開発者ドキュメント
• NVIDIA NCCL — 集合通信ライブラリ
• UALink Consortium
• Ultra Ethernet Consortium
• Google Cloud TPU
• AMD公式サイト
• SemiAnalysis — 半導体/インフラ分析
• IEEE Spectrum — 半導体とコンピューティング