> [!abstract] 概要 > 現代の AI ワークロード、特に Mixture-of-Experts(MoE)アーキテクチャは、低レイテンシかつきめ細かい GPU 間通信をデバイス側制御とともにますます要求するようになっている。従来の GPU 通信はホスト起動モデルに従い、CPU がすべての通信操作をオーケストレーションする——これは CUDA ランタイムの特性である。この方式は集団通信操作に対しては堅牢であるものの、計算と通信の緊密な統合を必要とするアプリケーションは、CPU 協調オーバーヘッドを排除するデバイス起動通信から恩恵を受けられる。 > > NCCL 2.28 は、Device API を導入し、3つの操作モードを提供する: NVLink/PCIe 向けの Load/Store Accessible(LSA)、NVLink SHARP 向けの Multimem、そしてネットワーク RDMA 向けの GPU-Initiated Networking(GIN)である。本論文は GIN のアーキテクチャ・設計・意味論を提示し、MoE 通信への影響を強調する。GIN は3層アーキテクチャを土台とする: i) デバイス通信初期化と集団メモリウィンドウ登録のための NCCL Core ホスト側 API、ii) CUDA カーネルから呼び出し可能なリモートメモリ操作のためのデバイス側 API、iii) 広範なハードウェアサポートのために二重の意味論(GPUDirect Async Kernel-Initiated と Proxy)を持つネットワークプラグインアーキテクチャ。GPUDirect Async Kernel-Initiated バックエンドは直接的な GPU-to-NIC 通信のために DOCA GPUNetIO を活用し、Proxy バックエンドは標準的な RDMA ネットワーク上でロックフリーな GPU-to-CPU キューを介して同等の機能を提供する。我々は、MoE 通信ライブラリである DeepEP との統合を通じて GIN の実用性を実証する。包括的なベンチマークにより、GIN が NCCL の統一ランタイム内でデバイス起動通信を提供し、低レイテンシ操作を NCCL の集団通信アルゴリズムと本番インフラストラクチャに組み合わせることが示される。 ## 論文情報 - タイトル: GPU-Initiated Networking for NCCL - 著者・所属: Khaled Hamidouche・John Bachan・Pak Markthub・Peter-Jan Gootzen・Elena Agostini・Sylvain Jeaugey・Aamir Shafi・Georgios Theodorakis・Manjunath Gorentla Venkata(全員 [[NVIDIA]] Corporation) - 媒体・発表年: arXiv preprint、2025年11月19日投稿(v2: 2025年11月24日) - arXiv ID: 2511.15076(cs.DC) ## 概要 本論文は、NCCL 2.28 で導入された Device API のうち、ネットワーク越しの RDMA によるデバイス起動通信を担う GPU-Initiated Networking(GIN)を解説する。GIN は CPU の介在なしに GPU カーネルから直接ネットワーク操作(one-sided put/signal)を発行できるようにし、NVIDIA の MoE 通信ライブラリ [[DeepEP]] への統合を通じてその実用性を実証している。 ## 問題設定 現代の AI ワークロード(MoE のトークンルーティング、コンパイラ生成カーネルにおける通信融合)は、CPU 協調オーバーヘッドを伴わない計算・通信の緊密な統合を必要とする。従来の NCCL はホスト起動モデルであり、各通信呼び出しごとに個別のカーネル起動と明示的なホスト・デバイス同期を要求する。この特性は集団通信操作には堅牢だが、動的なトークンルーティングのような不規則な通信パターンには不向きである。NVSHMEM は GDAKI(GPUDirect Async Kernel-Initiated)機能によってこの課題への解を示していたが、NCCL のエコシステム(階層的通信子・弾力性・耐障害性)とは独立したランタイムとして存在していた。 ## 提案手法 ### アーキテクチャ GIN は3層アーキテクチャで構成される(Figure 3)。 - **NCCL Core(ホスト側)**: 通信子初期化、GIN リソース管理、集団メモリウィンドウ登録(`ncclCommWindowRegister`)を担う。 - **Device GIN API(デバイス側)**: GPU カーネルから直接呼び出し可能な `ncclGin` オブジェクトを介して put/signal 等の one-sided 操作を発行する統一インタフェース。 - **GIN Network Plugin(プラガブルバックエンド)**: GDAKI と Proxy の二重意味論を実装するプラグイン層。NCCL の InfiniBand トランスポートは両方を実装し、外部ベンダーも独自実装を供給できる。 **Figure 1: NCCL Device API の3操作モード** ![[_attachments/arxiv-2511.15076/fig01-device-api-modes.png]] (Fig. 1. NCCL Device API アーキテクチャが示す3つの操作モードとその基盤インターコネクト技術。LSA は PCIe/NVLink 上のノード内メモリ操作、Multimem は NVLink SHARP によるハードウェアマルチキャスト、GIN は InfiniBand/RoCE 上のネットワークベース通信に対し GDAKI と Proxy の二重バックエンド実装を提供する。) **Figure 2: NCCL Device API と従来 NCCL の高水準アーキテクチャ比較** ![[_attachments/arxiv-2511.15076/fig02-architecture-comparison.png]] (Fig. 2. 左が NCCL Device API(LSA・Multimem・ネットワーク RDMA 向け GIN の3操作モード)で、集団対称メモリ上でシングルショット集団通信アルゴリズムを実現する。右が従来 NCCL で、通常メモリ上でパイプラインプリミティブ(Simple・LL・LL128)を用いるホスト起動集団通信を使う。) **Figure 3: GIN アーキテクチャ** ![[_attachments/arxiv-2511.15076/fig03-gin-architecture.png]] (Fig. 3. NCCL Core・プラグイン層・デバイス側 API の相互作用を示す GIN アーキテクチャ。NCCL Core は Device Communicator・Memory Window Registration・Two-sided Collectives API を持ち、Device GIN API(put/signal)経由で GinNet Plugin(GDA-KI・Proxy の2インタフェース、それぞれ DOCA GPUNetIO・Proxy(RDMA Ops)実装)へディスパッチする。既存の Two-sided Collectives API は従来どおり Net Plugin(RDMA Ops)を使う。) ### 核となる設計要素 - **one-sided 通信意味論**: put(リモート書き込み)と put with signal(書き込み+リモート通知)を提供し、受信側の協調を必要としない。ハンドシェイクプロトコルのオーバーヘッドを排除し、MoE の動的トークンルーティングのような不規則な通信パターンに特に有効。 - **ウィンドウベースの(非)対称メモリ**: 通信バッファは `ncclCommWindowRegister` により全ランクで集団的に登録され、MPI RMA ウィンドウモデルに倣う。各ランクは異なるバッファサイズを登録できる非対称性を許容する設計だが、NCCL 2.28 時点の実装は対称サイズを強制する(将来リリースで緩和予定)。 - **GIN コンテキストによるネットワーク並列性**: 各コンテキストは GPU と NIC 間のチャネルを抽象化し、キューペア(QP)を含む。1通信子あたり複数コンテキストを持つことで、複数 NIC・ポート・QP にまたがる独立した並行通信ストリームを実現する。 - **非同期完了追跡**: ローカル完了追跡にはカウンタ(送信側バッファの再利用可否)、リモート完了追跡にはシグナル(宛先でのデータ到着・可視性の確認)という2つの機構を用いる。OpenSHMEM のアドレスベース同期と異なり、GIN は ID ベースアドレシングを採用し、リソース管理とハードウェア実装の効率化を図る。 - **順序保証の意味論**: GIN 操作はデフォルトで無順序だが、同一コンテキスト・同一ピアへの put と signal の間にのみ順序を保証する。signal 完了時点で、同一コンテキスト上の先行する全 put が完了・可視であることが保証され、明示的な fence 操作なしの軽量な順序付けを実現する。flush はローカル完了(バッファ再利用可否)のみを保証し、リモート可視性は保証しない。 ### バックエンド実装(GDAKI と Proxy) - **GDAKI バックエンド**: DOCA GPUNetIO を活用し、GPU スレッドが RDMA ワークキューエントリ(WQE)をデバイスメモリ上に構築し、NIC のドアベルレジスタへ直接書き込んで DMA 転送を起動する。NIC ハードウェアが GPU メモリ上の新規 WQE をポーリングして自律的に進行を管理する。CPU の PCIe ラウンドトリップを排除し小メッセージで低レイテンシを達成するが、ConnectX-6 Dx 以降の NIC・CUDA 12.2+・適切な GPUDirect RDMA 構成(`nv_peer_mem` または `dmabuf`)を要求する。 - **Proxy バックエンド**: CPU を GPU-NIC 間の仲介として通信経路に組み込む。GPU スレッドは 64 バイトの操作記述子(送受信ウィンドウハンドル・オフセット・サイズ・完了アクション)をロックフリーキューへ enqueue し、通信子ごとに専用の CPU プロキシスレッドがこれをポーリングしてネットワークプラグインの `iput`/`iput_signal` インタフェース経由でネットワーク操作を発行する。GDAKI より追加のレイテンシを伴うが、任意の CUDA バージョン・任意の GPUDirect RDMA 対応 NIC(InfiniBand・RoCE・iWARP)・Volta 以降の GPU をサポートし、ホスト側でのデバッグを容易にする。 バックエンド選択は通信子初期化(`ncclCommInitRank`)時に DOCA GPUNetIO サポートの有無を自動検出し、利用不可なら Proxy にフォールバックする(環境変数 `NCCL_GIN_BACKEND` で上書き可能)。 | Characteristic | GDAKI | Proxy | |---|---|---| | 通信経路 | 直接 GPU↔NIC | GPU→CPU↔NIC | | CPU 関与 | ゼロ(完全デバイス駆動) | 必要(通信子ごとに専用スレッド) | | 進行モデル | NIC ハードウェアが GPU メモリを自律的にポーリング | CPU スレッドがキューをポーリングし NIC へ発行 | | 操作の発行 | GPU が直接 NIC ドアベルへ書き込み | GPU が記述子を enqueue、CPU が抽出・発行 | | ハードウェア要件 | ConnectX-6 Dx 以降 NIC、CUDA 12.2+ | 任意の CUDA バージョン、任意の RDMA NIC | | 実装基盤 | DOCA GPUNetIO デバイス verbs | Plugin `iput`/`test` API | | デバッグ支援 | デバイス側ツールのみ | ホスト側の検査・トレーシング | | 移植性 | GPU-NIC 直接アクセスを要求 | あらゆるベンダーに対応 | | 用途 | 本番 HPC/AI クラスタ | 開発・レガシー・マルチベンダー環境 | (Table I. GDAKI と Proxy の対比。) ## 新規性 既存の GPU-initiated networking の試み(GPUrdma・GIO)は InfiniBand verbs を device-callable 関数として公開したが、GPU-NIC 間のメモリ一貫性の課題に直面した。NVSHMEM は device-callable な one-sided 操作(put/get/atomics)を成功させたが、既存の集団通信フレームワークから独立したスタンドアロンランタイムとして存在する。DeepEP・pplx-kernels のような専用 MoE 通信ライブラリも同様に NCCL のエコシステムから独立している。 GIN の新規性は、GDAKI(直接 GPU-to-NIC 通信)と Proxy(コモディティハードウェア上の CPU 支援動作)という二重バックエンドを通じて、デバイス起動ネットワークプリミティブを NCCL の本番インフラストラクチャへ一意に統合する点にある。この統合は NCCL のエコシステム互換性(階層的通信子・弾力性・耐障害性メカニズム)を保ちながら、MoE 推論やカーネル融合パターンといった新興ワークロード向けのデバイス駆動通信を可能にする。 ## 実験設定 - **ハードウェア環境**: NVIDIA EOS クラスタ。DGXH100 ノード576台、ノードあたり H100 80GB HBM3 GPU 8基(計640GB)、第4世代 NVLink(900GB/s 双方向、GPU あたり18リンク)、InfiniBand 8×400Gbit/s(計算用)+2×400Gbit/s(ストレージ用)、Intel Xeon Platinum 8480CL(2ソケット、計112コア)。 - **ソフトウェア**: NVSHMEM 3.4.5、NCCL 2.28、DeepEP 1.2.1(本番 MoE 通信ライブラリ)。 - **比較対象**: NVSHMEM IBGDA・IBRC トランスポート。ただし DeepEP の実装は IBGDA と密結合しているため、DeepEP 統合評価では NVSHMEM IBGDA のみと比較する。 - **評価指標**: ping-pong テストによる往復レイテンシ(µs)、ディスパッチ/コンバイン操作の帯域幅(GB/s)。 ## 実験結果 ### Point-to-Point マイクロベンチマーク 4バイト〜4MBのメッセージサイズで put with signal のレイテンシを測定した(Figure 4)。小メッセージ(4〜128バイト)では、NCCL GIN GDAKI が16.7µsの往復レイテンシを達成し、NVSHMEM IBRC(16.0µs)に匹敵する一方、NVSHMEM IBGDA は24.3µsだった。GDAKI の直接 GPU-to-NIC 経路が CPU プロキシオーバーヘッドを排除する一方、Proxy バックエンドは GPU-to-CPU キュー経由にもかかわらず18.0µsを達成した。大きなメッセージサイズでは帯域幅制約が支配的になり、全実装の性能が収束する。 ### High-Throughput(HT)カーネル HT カーネルは大バッチ(4096トークン)の訓練・推論プリフィル向けで、階層的通信(送信・転送・NVLink 受信の SM 役割分担)を用いる。2ノード(16GPU)・BF16精度では、ディスパッチ操作が NCCL GIN で84.36GB/s、NVSHMEM で84.97GB/sの RDMA 帯域を達成した。8ノード(64GPU)では両実装とも約53〜54GB/sの RDMA 帯域を維持し、規模・精度モード・操作種別を通じて結果は1〜2%以内に収まった。 ### Low-Latency(LL)カーネル LL カーネルは小バッチ(1〜128トークン)の推論デコード向けで、全対全 RDMA メッシュ接続を用いる。BF16精度・隠れ次元7168で、ディスパッチ操作は14,352バイト(トークンデータ14,336バイト+メタデータ16バイト)、コンバイン操作は14,336バイトのメッセージを転送する。 - **NVLink 有効(ハイブリッド RDMA+NVLink)**: 1ノード(8GPU)で NCCL GIN がわずかに NVSHMEM を上回った(ディスパッチ185.28GB/s・40.62µs 対 182.15GB/s・41.43µs、コンバインはほぼ同一の約211GB/s・69µs)。マルチノード規模では NCCL GIN が一貫して低レイテンシを示し(2ノードで9%低いレイテンシ:142.51µs 対 157.00µs)、コンバイン操作は全規模で1〜3%以内に収まった。 - **NVLink 無効(純粋 RDMA)**: 1ノード(8GPU)で NCCL GIN が47.00GB/s・160.82µs、NVSHMEM が46.79GB/s・160.67µsを達成。8ノード(64GPU)では両実装とも約34〜35GB/s・219〜225µsを維持し、ほとんどの指標が1〜2%以内に収まった。 ## 考察 評価結果は、NCCL GIN が NVSHMEM と同等の性能特性を持つデバイス起動通信能力を提供することを示す。マイクロベンチマークとアプリケーションワークロード(HT・LL カーネル)の両方で、GIN はデバイス起動プリミティブを NCCL のトポロジ認識集団通信と単一ランタイム内で統合し、デバイス側 API の柔軟性と NCCL の本番インフラストラクチャを組み合わせる。GIN の価値は生の性能を超えてエコシステムの統一に及び、アプリケーションは LSA(NVLink/PCIe)・Multimem(NVLink SHARP)・GIN(ネットワーク RDMA)という統一された通信抽象化群にアクセスできるようになる。この統合は、階層的通信子(エキスパート並列・テンソル並列・パイプライン並列)・耐障害性・弾力性・トポロジ認識最適化という NCCL の本番運用機能を保持する。 GIN の実装は現在も活発に開発中であり、ワークキューエントリのバッチ化や複数操作にわたるドアベルコスト償却などの最適化が計画されている。 ## 強み / 弱点・課題 **強み**: - GDAKI バックエンドが NVSHMEM IBRC に匹敵する低レイテンシ(16.7µs)を達成しつつ、NCCL の本番インフラ(階層的通信子・耐障害性・弾力性)をそのまま利用できる。 - GDAKI と Proxy の二重バックエンド設計により、ConnectX-6 Dx 以降の最新ハードウェアから任意の RDMA 対応 NIC まで幅広い展開シナリオをカバーする。 - DeepEP という実運用の MoE 通信ライブラリへの統合により、既存 NVSHMEM ベース実装からの移行が現実的な性能コストで可能であることを実証した。 **弱点・課題**: - NCCL 2.28 時点では、ウィンドウ登録は非対称バッファサイズを設計上許容しつつも実装上は対称サイズを強制しており、disaggregated serving(prefill/decode でバッファサイズが異なる)への完全対応は将来リリース待ちである。 - GIN は現在も活発な開発段階にあり、ワークキューエントリのバッチ化やドアベルコスト償却などの最適化は「計画中」であって本論文の評価には未反映。 - 評価は NVIDIA EOS クラスタ(H100・400Gbit/s InfiniBand)という特定の本番環境に限定されており、RoCE 環境や異なる GPU 世代での性能特性は本論文からは読み取れない。 ## 出典 - arXiv: https://arxiv.org/abs/2511.15076 - PDF: `.raw/papers/arxiv-2511.15076.pdf`