AI Connectivityとは？GPUをつなぐ3層ネットワークとInfiniBand・RoCEv2・Ultra Ethernetの選び方

AI Connectivityは標準化団体が定義した規格名ではありません。ネットワーク機器ベンダーや通信事業者はGPUクラスタ向けネットワークの意味で、API管理のKongはAIエージェントとAPI・LLMの接続管理の意味で使っています。本記事では前者、つまりGPUなどのAIアクセラレータ同士やGPUクラスタと外部をつなぐ通信基盤を扱います。実体は、NVLinkやUALinkが担うGPU間の近距離接続、InfiniBand・RoCEv2・Ultra Ethernetが担うノード間接続、推論リクエストやストレージを流す通常のネットワークの3層です。この記事では3層の役割、規格ごとの違いと選び方、必要帯域の計算と実測の手順を、2026年10月時点の公開仕様に沿って説明します。

まとめ：AI Connectivityの3層と選定の結論

• スケールアップ層：ノード内・ラック内のGPUを1台のように束ねる。NVIDIAはNVLink（第5世代でGPUあたり1,800GB/s）、業界標準はUALink 200G 1.0（2025年4月批准・最大1,024アクセラレータ）。
• スケールアウト層：ノードをまたいでGPUを結ぶRDMAネットワーク。選択肢はInfiniBand（専用網・800Gb/s世代）、RoCEv2（Ethernet上・ロスレス構成ではPFCとECNを調整）、Ultra Ethernet（UEC仕様1.0.3が2026年7月公開）。
• フロントエンド層：推論APIの受付、学習データの読み込み、管理通信を流す通常のIPネットワーク。GPU間通信とは別のNIC・別のネットワークに分けるのが基本です。
• 学習の通信量はAll-Reduceの式で事前に見積もれます。80億パラメータのbf16勾配を64GPUで同期すると、GPUあたり400Gb/sで約0.63秒、100Gb/sで約2.52秒が理想条件での見積もりです。
• 構築後はnccl-testsのbusbwを見て、設計どおりの帯域が出ているかを判定します。
• 単一ノードの推論や数台規模のファインチューニングなら、スケールアウト用のRDMA網は不要なことが多く、先にフロントエンドとストレージを固めるほうが効果があります。

設計時は、まずモデルが単一ノードに収まるかを確認し、ノード間通信が必要な場合にスケールアウト層の方式と帯域を決めます。

AI Connectivityの定義：汎用ネットワークと切り分ける理由

AI Connectivityという語は、特定の製品やプロトコルを指しません。共通しているのは「GPUの計算を止めないためのネットワーク」という目的です。社内LANやWebサービスのネットワークは、多数の独立した通信を公平にさばき、パケットが落ちてもTCPの再送で回復すれば問題になりません。AI学習のネットワークは前提が逆です。

• 全GPUが同時に同じ量を送る：同期データ並列学習では、逆伝播中に準備できた勾配からAll-Reduceなどの集団通信を実行し、全員が終わるまで次のステップに進めません。
• 最も遅いリンクが全体の速度になる：1本のリンクで再送や輻輳が起きると、そのGPUを待つ間ほかの全GPUが止まります。平均の帯域ではなく、裾の遅延（テールレイテンシ）が学習時間を決めます。
• CPUを経由しない：RDMA（Remote Direct Memory Access）でGPUメモリから相手のGPUメモリへ直接書き込み、OSのTCP/IPスタックを通しません。損失への対処は方式や実装で異なり、ネットワーク側のフロー制御とトランスポート側の再送・輻輳制御を組み合わせます。

このため、AI向けの基盤では「GPU同士の通信」と「それ以外の通信」を別のネットワークとして設計します。NTTのAIOWNのように通信事業者がAI向けの接続をサービスとして提供する動きもあり、事業者側の構成はAIOWNの中身とIOWNとの違いで整理しています。

GPUクラスタを結ぶ3層：スケールアップ・スケールアウト・フロントエンド

AI Connectivityを設計するときは、通信の距離と相手で3つの層に分けて考えます。層ごとに使う技術も、決める人も違います。

スケールアップ層の単位はGB/s（バイト）、スケールアウト層はGb/s（ビット）で表記されるのが慣例です。単位換算に加えて、片方向か双方向合計かもそろえてください。ここで挙げたNVLink帯域は双方向合計で、NICの400Gb/sは片方向の公称速度です。

スケールアップ層：NVLinkとUALinkの帯域

スケールアップ層は、GPUのメモリを互いに読み書きできる距離でつなぎ、複数のGPUを1台の大きなGPUのように扱うための接続です。NVIDIAのNVLinkページによると、GPU間の帯域は第4世代（Hopper）が900GB/s、第5世代（Blackwell）が1,800GB/s、第6世代（Vera Rubin）が3,000GB/sです。72基のGPUを全対全でつなぐNVL72構成の総帯域は、第5世代で130TB/s、第6世代で216TB/sとされています（出典：NVIDIA NVLink）。なお、Rubin発表時のNVIDIA技術ブログは第6世代をGPUあたり3.6TB/sとしており、出荷前の世代は公式ページ間でも数値がそろっていません。Rubin世代の構成はNVIDIA Rubin（Vera Rubin）の7チップ構成と性能で詳しく扱っています。

NVLinkはNVIDIA製GPUで使われるほか、NVLink FusionによってカスタムXPUへの対応も進んでいます。オープンな接続規格としては、85社超が参加するUALink Consortiumが2025年4月8日に「UALink 200G 1.0」仕様を批准しました。200G 1.0は1レーンあたり200Gb/s、1ポッド最大1,024基のアクセラレータを接続する仕様です。2026年4月7日にはCommon 2.0と200G DL/PL 2.0なども公開され、In-Network Computeや管理機能が追加されています（出典：UALink Consortium 2026年4月7日発表）。Ethernetの物理層を流用してスケールアップ層を作る取り組みとしては、OCPのESUN（Ethernet for Scale-Up Networking）も2025年10月に始まっています。

スケールアウト層：ノードをまたぐRDMAネットワーク

スケールアウト層は、GPUサーバー同士をつなぐネットワークです。現在の主流構成では、GPU1基ごとに専用のNIC（400Gb/s級）を1枚割り当て、8GPUのサーバーなら8本の回線を出します。各サーバーのGPU 0番同士、1番同士を同じスイッチ群にまとめる「レール最適化」配線にすると、同じレールで同一リーフスイッチに接続されたGPU間はスイッチ1段で通信できます。別のリーフやブロックをまたぐ場合は、追加のホップが必要です。次章で比べるInfiniBand・RoCEv2・Ultra Ethernetは、すべてこの層の選択肢です。

フロントエンド層：推論・ストレージ・管理の通信

フロントエンド層は、利用者からの推論リクエスト、学習データやチェックポイントの読み書き、ジョブ管理やモニタリングを流すネットワークです。技術的には通常のEthernetとIPで、クラウドならVPCがこれに当たります。Google CloudのA3 UltraとA4では、GPU間通信用のConnectX-7 NIC 8枚（合計3,200Gbps）は「GPU間の高帯域通信専用で、インターネット接続など他の用途には使えない」と明記されており、フロントエンド用には別のNIC（gVNIC）が付きます。この構成では、GPU間通信と汎用通信に別のNICを割り当てています。ただし、NICの分離だけからクラウド内部のネットワーク全体が物理的に分離されているとは判断できません。

InfiniBand・RoCEv2・Ultra Ethernetの比較と選び方

スケールアウト層の3方式は、どれもRDMAでGPUメモリ間を直接つなぐ点は同じです。違いは「損失と輻輳への対処をどこに持つか」と「何社の機器から選べるか」にあります。

InfiniBand：クレジット制フロー制御による損失対策

InfiniBandは、送信側が受信側のバッファに空きがあるとき（クレジットがあるとき）だけ送るフロー制御を持ち、原理的にバッファあふれによるパケット損失が起きません。経路はサブネットマネージャが集中管理します。NVIDIAの製品ではQuantum-2が400Gb/s（NDR）、Quantum-X800が800Gb/s（XDR）です。AzureのND H100 v5は、GPUごとに400Gb/sのQuantum-2 InfiniBandを持ち、VMあたり3.2Tbpsを提供しています。チューニングの手間が少ない代わりに、スイッチ・NIC・ケーブルの調達先がほぼNVIDIA一社に限られ、Ethernetとは別の運用スキルが必要です。

RoCEv2：Ethernet上のRDMAとPFC・ECNの調整

RoCEv2（RDMA over Converged Ethernet v2）は、InfiniBandのトランスポートをUDP/IPに包んでEthernetで運ぶ方式です。IANAにはUDP 4791番が「IP Routable RocE」としてInfiniBand Trade Associationの名義で2014年に登録されています。Ethernetはもともとパケットを落とす前提なので、無損失（ロスレス）構成にするには2つの仕組みを組み合わせます。

• PFC（Priority Flow Control、IEEE 802.1Qbb）：スイッチのキューがあふれそうになると、RDMA用の優先度クラスだけ上流に一時停止を送る。
• ECN（Explicit Congestion Notification）：キューが埋まり始めた段階でパケットに印を付け、送信側に速度を落とさせる。RDMA向けの制御方式としてはDCQCNが広く使われています。

PFCは止めすぎると一時停止が隣のスイッチへ連鎖し、無関係な通信まで止まる（ヘッドオブラインブロッキングやPFCストーム）ので、ECNが先に効くようにしきい値を設定するのが定石です。NVIDIAのCumulus Linuxのように、PFCを使わないlossyモードのRoCE設定を用意している実装もあります（Cumulus Linux 5.12 RoCE）。Ethernetの機器と運用ノウハウをそのまま使え、複数ベンダーから選べるのが最大の利点です。輻輳制御の一般的な考え方は輻輳の仕組みとTCP輻輳制御を参照してください。

Ultra Ethernet：現行仕様とRoCEv2との設計差

Ultra Ethernetは、Linux Foundation系列のUltra Ethernet Consortium（UEC）が策定したAI・HPC向けの通信スタックです。仕様1.0が2025年6月11日に公開され、その後1.0.1（2025年9月5日）、1.0.2（2026年1月28日）と修正が続き、2026年7月16日公開の1.0.3が現行版です（出典：UEC Specification History）。

RoCEv2との一番の違いは、損失のあるネットワークでも性能が出るように設計され、ロスレス網でも動く点です。1つの通信を複数の経路に分散して送るパケットスプレー、順不同で届いたパケットをそのままメモリに書く処理、落ちたパケットだけを再送する選択的再送をトランスポート側に持たせ、PFCに頼らずに輻輳と損失をさばきます。BroadcomはUEC準拠をうたう800GのNIC「Thor Ultra」を2025年10月に発表しており、UEC準拠をうたう機器の発表が始まった段階です。2026年時点で新規に大規模クラスタを組むなら候補に入りますが、既存のRoCEv2網を置き換える理由になるかは、相互接続の実績が出てから判断しても遅くありません。

スケールアウト方式の選定条件

• InfiniBandを選ぶ：数千GPU規模の学習を単一テナントで回し、ネットワークの調整に人を割けない場合。NVIDIA製GPUで統一するならNVIDIAの参照構成に沿って組めますが、既存の運用スキルと保守体制も含めて比較します。
• RoCEv2を選ぶ：社内にEthernetとBGPの運用チームがあり、複数ベンダーの機器を混在させたい、またはマルチテナントで使う場合。PFCとECNの設定を検証する期間を計画に入れてください。
• Ultra Ethernetを候補に入れる：2026年以降に新設する大規模クラスタで、ベンダー固定を避けたい場合。UETに対応するエンドポイントが必要です。既存のEthernetスイッチでも動作でき、追加機能を使う場合はスイッチ側の対応も確認します。
• クラウドで借りる：方式は事業者が決めます（AWSはEFA、AzureはInfiniBand、Google CloudはRoCEベースのGPUDirect RDMA）。選ぶのはインスタンスの種類と配置です。

必要帯域の見積もり：All-Reduceの通信時間と計算条件

データ並列の学習では、各ステップで全GPUの勾配を合計してそろえるAll-Reduceが走ります。NVIDIAのnccl-testsのドキュメントは、リング方式のAll-Reduceにかかる時間の下限を次の式で示しています（出典：nccl-tests PERFORMANCE.md）。

t = (S / B) × 2(n − 1) / n

Sは同期するデータ量、Bは1ランク（GPU）あたりのボトルネック帯域、nはGPU数です。nが大きくなると係数は2に近づくので、「勾配サイズの約2倍をGPUあたり帯域で割った時間」が目安になります。次のPythonで、80億パラメータのモデルをbf16の勾配（1パラメータ2バイト）で、8ノード×8GPU＝64GPUのデータ並列で学習する場合を計算します。

# All-Reduceにかかる時間の理論下限を見積もる（nccl-tests の busbw 定義に基づく）
# t = (S / B) * 2 * (n - 1) / n
#   S: 1回に同期するデータ量（バイト） B: 1ランクあたりのボトルネック帯域（バイト/秒） n: ランク数

def allreduce_seconds(size_bytes: float, link_gbps: float, ranks: int) -> float:
    bytes_per_sec = link_gbps * 1e9 / 8          # Gb/s -> B/s
    return size_bytes / bytes_per_sec * 2 * (ranks - 1) / ranks

params = 8e9                 # 80億パラメータ
grad_bytes = params * 2      # bf16 の勾配 = 2バイト/パラメータ
ranks = 64                   # 8ノード x 8GPU

for gbps in (400, 200, 100, 25):
    t = allreduce_seconds(grad_bytes, gbps, ranks)
    print(f"GPUあたり {gbps:>3} Gb/s : {t:6.2f} 秒")

Python 3で実行した結果は次のとおりです。

GPUあたり 400 Gb/s :   0.63 秒
GPUあたり 200 Gb/s :   1.26 秒
GPUあたり 100 Gb/s :   2.52 秒
GPUあたり  25 Gb/s :  10.08 秒

この値は、各ランクが指定帯域で通信する均一なモデルを仮定し、起動遅延やプロトコルの負荷を省いた見積もりです。ノード内集約や階層型All-Reduceを使う構成では、ノード間通信量を別途評価します。PyTorchのDDPのように逆伝播の計算と勾配の通信を重ねる実装では、通信を隠せる量が、各勾配バケットが準備できる時刻と、通信に重ねられる逆伝播の計算時間で決まります。通信時間がステップ全体の計算時間より短いだけでは、通信待ちがなくなるとは限りません。逆に、1ステップの計算が1秒程度のモデルで25Gb/s相当の回線しかなければ、GPUは時間の大半を通信待ちで過ごします。GPUを増やしても速くならない場合は、通信時間の見積もりと実測を比較し、通信がボトルネックかを確認します。

テンソル並列やパイプライン並列を組み合わせると、ノード内のNVLinkに乗る通信とノード間に出る通信の割合が変わります。テンソル並列はノード内に閉じ、ノード間はデータ並列だけにする構成が一般的なのは、帯域が1桁違うスケールアップ層に重い通信を寄せるためです。

nccl-testsの実測手順：busbwによる帯域評価

机上の見積もりの次は、構築したクラスタで実際にどれだけ出ているかを測ります。標準的な道具はNVIDIAのnccl-testsです。READMEに載っている実行例は次の2つです。CUDA・NCCLと対応GPUを用意してnccl-testsをビルドし、複数ノードではMPIによる実行先の割り当ても設定します。

# 1ノード・8GPUで、8バイトから128MiBまで2倍ずつ増やして測る
$ ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8

# 8GPUのノード8台・計64プロセスで、8バイトから8GiBまで測る（MPI=1でビルドしておく）
$ mpirun -np 64 -N 8 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1

出力にはalgbwとbusbwの2列が出ます。algbwはデータ量を時間で割っただけの値で、GPU数が増えると下がって見えます。busbwはAll-Reduceの場合algbwに2(n−1)/nを掛けた値で、GPU数によらずハードウェアのボトルネック（NVLink、PCIe、ネットワーク）の速度と直接比べられます。

• 1ノード内の測定：大きなメッセージサイズでのbusbwを、NVLinkの片方向帯域を基準に確認します。例えばHopperの公称900GB/sは双方向合計なので、通常の比較では片方向450GB/sを基準にし、使用アルゴリズムや集約オフロードの有無も確認します。
• 複数ノードの測定：busbwがGPUあたりのNIC帯域（400Gb/sなら50GB/s）を大きく下回る場合は、NICとGPUのPCIe配置、RDMAが実際に使われているか（TCPに落ちていないか）、PFC・ECNの設定を順に疑います。
• 特定のノードだけ遅い：ノードを半分ずつ外して測り直すと、劣化したケーブルや光モジュールを持つノードを絞り込めます。1本の不良リンクが全体を引きずるのがAI Connectivityの特徴です。

GPU側の使用率や温度を並行して記録したい場合は、nvidia-smiの使い方とDCGMへの移行判断の手順が使えます。

主要クラウドのGPUノード間ネットワーク：帯域と配置の制約

クラウドでGPUクラスタを借りる場合、スケールアウト層の方式は事業者が決めています。利用者が気を付けるのは、帯域の数字よりも「どの範囲のインスタンス同士ならRDMAでつながるか」という配置の制約です。

AWSのEFAは、独自のSRD（Scalable Reliable Datagram）プロトコルでOSを迂回する通信と輻輳制御を行います。AWSのドキュメントは、EFAのトラフィックがアベイラビリティーゾーンやVPCを越えられず、ルーティングもできないと明記しています（出典：Elastic Fabric Adapter）。可用性のためにノードを複数AZへ散らすと、学習用の通信ができなくなります。AzureのND H100 v5では、InfiniBandの接続は同じVMスケールセットに属するVM間で自動構成されるため、別々に作ったVMは高速網でつながりません（出典：ND H100 v5 sizes series）。

Google CloudのA3 MegaがRDMAではなくTCPベースの方式で1,800Gbpsを出しているように、RDMAは必須条件ではありません（出典：Network bandwidths and GPUs）。クラウドではインスタンスの種類を選んだ時点で方式が決まるので、比べるべきは表の帯域と配置制約、そして確保できる台数です。GPU特化の事業者を含めた選択肢はネオクラウドの仕組みと主要企業にまとめています。

推論とエッジの接続：MECを使う構成例

単一GPUで完結する推論や、リクエストごとに独立して処理する構成ではGPU間の同期が不要なため、スケールアウト層よりもフロントエンド層の遅延と可用性が効きます。工場の画像検査や車両の映像解析のように数十ミリ秒単位の応答が要る用途では、推論サーバーをクラウドの遠いリージョンではなく、通信事業者の局舎内に置く構成が選択肢になります。これがMEC（Multi-access Edge Computing）で、ETSIの専門グループが複数ベンダーのMEC基盤の上でアプリケーションを動かすための仕様を標準化しています。

• 端末→プライベート5G→構内の推論サーバー：工場内で完結し、外部回線の遅延と障害の影響を受けない。モデル更新だけをクラウドから配る。
• 端末→公衆5G→事業者局舎のMEC→クラウド：複数拠点で同じ推論基盤を共有する。判定結果と再学習用の一部データだけをクラウドへ送る。
• 端末内推論＋クラウド：小型モデルを端末で動かし、判断に迷う入力だけをクラウドの大型モデルへ回す。回線が切れても最低限の処理が続く。

これらはエッジでの推論を中心にした構成例です。端末内推論とクラウドを併用する例では、クラウド側でも大型モデルによる推論を行います。推論が単一ノードで完結するエッジ構成では、GPU間通信用のスケールアウトRDMA網は不要です。複数ノードにモデルを分割する場合は、通信量に応じて検討します。

RDMA網を入れないほうがよい場面と失敗パターン

AI Connectivityの話はGPU数千基の学習クラスタを前提にしがちですが、多くの企業の用途はそこまで大きくありません。次の場面では、スケールアウト用のRDMA網への投資を急がず、まず見積もりと実測で必要性を確かめます。

• 1ノードに収まる推論：モデルが1台のサーバー内で動くなら、GPU間通信は搭載構成に応じてノード内のNVLinkやPCIeで完結します。ノード間の高速網は使われません。
• LoRAなど小規模なファインチューニング：例えば同期する勾配が500MB、64ランク、GPUあたり100Gb/sなら、前章の式では約0.079秒です。これは理想条件での見積もりで、実時間は構成や通信効率によって増えます。
• GPUが十数基以下で、増設の予定が無い：GPU数だけでは費用対効果を決められません。既存網で通信待ちが小さく、稼働時間を含めた削減額が導入・運用費を下回る場合は、RDMA網への投資を見送ります。

逆に、よくある失敗は次の3つです。1つ目は、RoCEv2を導入したのにPFCとECNを既定値のまま本番に入れ、負荷が上がった時点で一時停止の連鎖が起きるケースです。2つ目は、NICとGPUが別のCPUソケット側のPCIeに刺さっていて、データがCPUソケット間の接続を経由してしまい、busbwがNIC帯域を大きく下回るケースです。3つ目は、クラウドで可用性を優先してノードを別のAZやスケールセットに分け、RDMAがつながらなくなるケースです。構築直後にnccl-testsで基準性能を測り、想定する同時実行数や負荷でも再測定します。原因の特定には、NCCLログ、PCIe構成、スイッチのPFC・ECNカウンタも確認します。

よくある質問

AI Connectivityは特定の製品名ですか？

特定の製品名や規格名ではありません。ネットワーク機器ベンダーや通信事業者はGPUクラスタ向けのネットワークやAI用途の接続サービスを、KongのようなAPI管理ベンダーはAIエージェントとAPIの接続管理を指して使います。本記事で扱う前者の中身はNVLink・UALink、InfiniBand・RoCEv2・Ultra Ethernet、通常のIPネットワークの組み合わせです。

RDMAとは何ですか？

RDMA（Remote Direct Memory Access）は、相手のサーバーのメモリへCPUとOSのTCP/IP処理を介さずに直接読み書きする通信方式です。GPUDirect RDMAではNICがGPUメモリに直接アクセスするため、遅延とCPU負荷が下がります。InfiniBand、RoCEv2、AWSのEFAはいずれもこの方式を提供します。

InfiniBandとRoCEv2はどちらが速いですか？

ポート速度はどちらも400〜800Gb/s級で、大きな差はありません。差が出るのは混雑時の安定性です。InfiniBandはクレジット制のフロー制御で調整なしでも損失が起きにくく、RoCEv2はPFCとECNの設定次第で混雑時の安定性が変わります。実際の差はnccl-testsで測って判断してください。

Ultra EthernetはRoCEv2の後継ですか？

同じEthernet上のRDMAですが、設計の前提が違います。RoCEv2はPFCを使うロスレス構成が一般的ですが、PFCなしの構成もあります。一方、Ultra Ethernetはパケットスプレーや選択的再送をトランスポート側に持ち、損失のあるネットワークでも動くよう設計されています。仕様は2026年7月公開の1.0.3が現行版で、対応NICの発表が始まった段階です。

MECの構成例にはどんなものがありますか？

代表的なのは、工場内のプライベート5Gと構内の推論サーバーで完結させる構成と、公衆5Gで通信事業者局舎のMECへつなぎ複数拠点で推論基盤を共有する構成です。どちらも学習はクラウド側で行い、エッジは推論と結果の送信に絞ります。

関連記事

• ネオクラウドとは？GPU特化クラウドの仕組みと主要企業・日本の事業者【2026年10月】
• AIOWNとは？読み方（エーアイオン）とNTTのAIネイティブインフラの中身・IOWNとの違い
• NVIDIA Rubin（Vera Rubin）とは？7チップ構成・性能・出荷時期とBlackwellとの違い【2026年10月】
• 輻輳とは？ネットワーク混雑の仕組み・原因・TCP輻輳制御から対策の判断まで実装者向けに解説
• nvidia-smiの使い方｜GPU使用率とメモリの見方・CSV記録・DCGMへの移行判断