# Collective Communication for 100k+ GPUs > [!abstract] 概要 > 大規模言語モデル(LLM)の規模拡大は、特に訓練ワークロードが数十万 GPU に及ぶとき、極めて効率的な GPU 間通信機構を要求する。従来の通信手法はこの規模でスループットとレイテンシに大きな制約を抱え、最先端モデルの開発と展開の双方を妨げる。本稿は、Meta が開発し、大規模訓練の同期要求から推論の低レイテンシ要求まで LLM のライフサイクル全体で性能を最適化するよう設計された NCCLX 集合通信フレームワークを提示する。本フレームワークは 10 万を超える GPU からなるクラスタ上の複雑なワークロードを支えるよう設計され、信頼性が高く高スループットかつ低レイテンシなデータ交換を保証する。Llama4 モデルでの実証評価は通信効率の大幅な改善を示す。本研究は、次世代 LLM を前例のない規模で動作させるための堅牢な解を提供する。 ## 論文情報 - タイトル: Collective Communication for 100k+ GPUs - 著者(代表): Min Si, Pavan Balaji, Minlan Yu, James Hongyi Zeng ほか(全員 [[Meta]]。一部は Meta 在籍時の作業) - 発表: arXiv:2510.20171v4 [cs.DC](2026-01-09)。Date 表記は 2026-01-12、Correspondence は James Hongyi Zeng - コード: https://github.com/meta-pytorch/torchcomms (`comms/ncclx`) - 関連既存ノート: [[papers/2025__arXiv__Collective Communication for 100k+ GPUs|Collective 100k+ 既存ノート]] - 関連トピック: [[集合通信]] / [[LLM分散学習]] / [[耐障害LLM訓練]] / [[GPUクラスタ運用]] / [[並列化戦略]] / [[LLM学習モニタリング]] / [[LLM推論]] ## 概要 NCCLX は、NVIDIA の [[NCCL]] ライブラリを基盤としつつ Meta が開発した集合通信フレームワークで、Llama4 の開発・展開を支えるために作られた(§1)。PyTorch の下層で動作し、訓練と推論の全通信を一元管理する。NCCLX が掲げる主要特徴は、(1) 10 万 GPU 超でのスケーラビリティと性能、(2) 多様なモデルアプリケーション向けのカスタム機能、(3) 通信スタック全体にわたるプログラムの容易さ、(4) 監視・デバッグ・運用のためのツール群、である(§1, 表1)。 中核となるのは、ホスト駆動・ゼロコピー・SM フリーを設計原理とするカスタムトランスポート CTran であり、host-initiated API、GPU 常駐メタデータ付き host-initiated API、device-initiated API(進行中)の三実行モードを統一スタックで提供する。各モードはコレクティブ・point-to-point・RMA のセマンティクスを支える(§3, 図2)。 ## 問題設定 LLM の訓練は多次元のモデル並列を生み、性能特性の異なる複数の中〜大規模トラフィックフローを同時に発生させる(§2.1)。内側の並列領域(例: tensor parallelism, TP)のコレクティブは実行中に完全に露出し高帯域域に留まる一方、中間領域(expert parallelism EP, pipeline parallelism PP)は部分的に隠れた中サイズメッセージを伴い、外側領域(FSDP, DP)は大容量だが内側で隠蔽されやすい。推論は逆に、小〜中サイズメッセージの低レイテンシ通信を要し、MoE の AllToAll が代表的なボトルネックとなる(§2.1)。 従来の [[NCCL]] は host-initiated だがカーネル駆動・コピーベースで、静的に表現できる規則的なコレクティブには向くが、先行計算が生成する動的引数を扱いにくく、GPU→host コピーや CUDA Graph 非互換、高価なパディングを招く(§2.2)。一方 NVSHMEM は device-initiated で低レイテンシだが、全 rank に対称メモリ領域を確保・登録する必要があり PyTorch とメモリを共有できないため、過度な利用がモデルのスケールを制約する。実運用では両者が併存し、二重ランタイム化が性能最適化・資源共有・運用保守の負担を倍化させる(§2.2)。 ネットワークは 10 万 GPU 超を単一の高性能 RoCE ファブリックに統合する複数データセンタ(DC)建屋構成を採る。DC 内は 3 層 Clos(RTSW / CTSW / ATSW)で、建屋間は ATSW 層を全結合メッシュで接続する(§2.3, 図1)。Llama3 比でクロス AI-Zone のオーバーサブスクリプション比を 1:7 から 1:2.8 に低減した。同一 rack 内が最低レイテンシで、rack 間・AI-Zone 間・DC 建屋間はそれぞれ約 7×・15×・30× のレイテンシ増を被る(§2.3, §4.4)。 ## 提案手法 ### CTran: カスタムトランスポート(§4) CTran は、Llama4 規模の訓練で NCCL に見いだした二つの限界(カーネル駆動設計とコピーベース転送)を解消するために開発された(§4)。 - ホスト駆動型カスタマイズ(§4.1): communicator ごとに専用 CPU バックグラウンドスレッドを起動し、ユーザがコレクティブを呼ぶと CPU スレッド上でアルゴリズムをスケジュールしつつ、stream 順序を守るための stall kernel を起動する。同期は host-pinned フラグで行う(図3)。ネットワーク転送のみのコレクティブ(FSDP の inter-node AllGather, PP の P2P)は CPU スレッドから直接 RDMA を発行する fully-host-driven モード、NVLink 転送を伴う場合は host-kernel coordinated モードを採る。同期オーバーヘッドは常に 1 マイクロ秒未満で複雑なパイプラインでも隠蔽できると測定している。 - ゼロコピーデータ転送(§4.2): ベースライン NCCL は送受信双方で FIFO バッファを介する D2D コピーを要し(図4a)、SM と HBM 帯域を消費して計算と競合する。CTran はユーザバッファ間で直接 RDMA / NVLink CopyEngine 転送を行い中間 FIFO を排除する(図4b)。これにより資源競合を抑え、ネットワーク層側でのデータ分割・QP 割当による負荷分散も可能になる。 - ゼロコピー用テンソル登録管理(§4.3.1): PyTorch の CUDA cache allocator(CCA)を拡張し、auto-registration(lazy registration)と memory-pool の二モードを提供する。登録は通常数百マイクロ秒〜数ミリ秒だが、GPU RDMA ドライバのプロセス間ロック競合により 100 ミリ秒に達する登録時間のスパイクを観測しており、NVIDIA と原因究明・修正に取り組んでいる。expandable segment モードでの再マッピング多発(特に PP)に対しては memory-pool モードで対処する。 - CTran とネットワークの協調設計(§4.4): ゼロコピーは制御メッセージを receiver→sender の 1 往復に減らしレイテンシを下げるが、一括ハンドオフのため fabric 任せの輻輳制御になり過剰なバッファ蓄積を招きうる。そこで DQPLB(Dynamic Queue Pair Load Balancing, §4.4.1)を導入し、接続種別(同一 rack / zone 内 cross-rack / DC 内 cross-zone / cross-DC)とトポロジ別に未確認データ量・QP 数・最大セグメントサイズを設定する。1 つの制御 QP と複数のデータ QP を用い、IBV_WR_RDMA_WRITE_WITH_IMM のイミディエイトデータにシーケンス番号・fast path・通知フラグを埋め込み、スライディングウィンドウで順序保証する(図6)。Llama3 比でスイッチバッファ蓄積を一桁削減した。 ### Llama4 向け大規模訓練のカスタマイズ(§5) - PP のゼロコピー・SM フリー Send/Receive(§5.1): コピーベースの 128KB〜512KB チャンクでは DC ネットワークの高レイテンシを隠せず、staging copy が SM(4 thread block × 640 threads 規模)を占有して GEMM と競合する。CTran はゼロコピー化し、receiver の CPU スレッドが受信バッファの RDMA 登録を交換、sender がユーザバッファから直接 RDMA write する。GPU 資源を使わず数十 MB の Send/Receive でピーク帯域に到達する。PP には memory-pool モードを適用しランプアップ費用を不可視化した。 - TP の RMA Put による細粒度オーバーラップ(§5.2): 既存の TP オーバーラップ(Transformer Engine, PyTorch Async TP, ByteDance の Flux)は CUDA IPC 依存で単一ホスト(TP ≤ 8)に限られる。CTran は MPI-2 準拠の片側 Put セマンティクスを持つ CtranWindow と Put API を用い、intra-node は SM フリーの NVL CopyEngine、inter-node は RDMA write にマップする。Llama 訓練は [[Megatron-LM]] 類似の TP を用い、Ring パイプラインをトポロジ対応の Tree パイプラインに拡張して、低速な inter-node RDMA 転送を高速な intra-node NVLink チャンク転送で隠す(図8)。 - HSDP のフォールトトレラント AllReduce(§5.3): 10 万デバイス規模では障害でジョブが頻繁に停止・再起動する。FSDP は冗長な重みを持たず弾力化が難しいため、最外殻を Hybrid Sharding Data Parallel(HSDP)へ移行した。replica group 内は FSDP でシャード、group 間は入力を分散し step 末に AllReduce で勾配同期する。global coordinator が障害検知と動的な group 管理(縮小=shrink / 拡張=grow フェーズ。新規は 4K-GPU group)を司る。Fault Tolerant AllReduce(FTAR)は Ring を用い固定チャンクサイズ S と本数 C で決定的トラフィックを実現、in-kernel copy/reduce をネットワーク RDMA に隠す(図9)。8MB チャンク・512 threads × 2 thread block で帯域を飽和できる。 - ネットワークトポロジ対応最適化(§5.4): トポロジ対応のジョブ配置と、ring 系の線形複雑度を避ける recursive doubling/halving(対数複雑度)を採用。AllGather の farthest-first 戦略がオーバーサブスクライブ網で最適と判定した。 ### マルチノード推論のカスタマイズ(§6) - EP の GPU 常駐コレクティブ(§6.1): NCCL の AllToAllv はメタデータが CPU 常駐で、CUDA Graph 捕捉時に固定されてしまうため maxcounts(最悪ケースのパディング)送信を強いられ、MoE 推論で過大なレイテンシ・帯域を生む(図13, 図14)。AllToAllvDynamic はメタデータを GPU 常駐とし参照渡しで受け取ることで、router kernel が更新した実際の send counts で転送でき、転送量を実需サイズに削減する(図15, 図16)。MetaShuffling の token shuffling スタックに統合される。 - 低レイテンシ最適化(§6.2): N-rank の AllToAll は LogP モデルで T = Tc·(N−1) + S/BW と近似でき、小メッセージでは準備オーバーヘッド Tc が支配的になる(表2: 制御メッセージ交換 50%, RDMA put 発行 20%, 受信完了待ち 30%)。クリティカルパスの C++/API 最適化(積極的なインライン化、低レイテンシ条件のテンプレート渡し)、CUDA Graph 利用時のメモリハンドル一回交換とダブルバッファリングによる制御メッセージ削減、small-message fast path と work request chaining(scatter list)による RDMA put オーバーヘッド削減を行う。ホスト駆動でも device-initiated に近い低レイテンシを達成できると示す(図19)。 ### その他の最適化とツール(§7) - 訓練のスケーラブル初期化(§7.1): 通信協調のオーバーヘッドは二次的に増大し、100K 規模では初期化が再起動時間を支配する。Global Process Group(eager モードで単一 global communicator を作り ncclCommSplit で派生)、TCPStore ベースの bootstrap ring 形成、bi-directional / tree AllGather、O(N²)→O(N) の CPU 最適化などで、デフォルト process group 生成をベースライン NCCL 比で最大 11× 高速化した(図20, 図21)。 - 内部メモリ管理(§7.2): NCCL は Llama4 事前学習で 10+ 並列グループにわたり約 10 GB(H100 HBM の約 12.5%)を消費する。Lazy Algorithm Initialization/Connection、Lazy Channel Allocation、メタデータ用 Slab Allocator により、64K GPU でメモリ使用をほぼ 2 分の 1 に削減した(表4, 図23, 図24)。 - 障害箇所特定(§7.3): NCCL の RAS は cascaded failure の識別とカーネル開始追跡に限界がある。CollTrace で per-collective・network RDMA 粒度の状態を計装し、collective 間の依存を解析する Fault Analyzer が初発の停止コレクティブと故障ホストを特定する。8K GPU での NIC 障害トリアージとモデルコードのバグ(TP PG で rank が hang)トリアージの二例を示す。 - 性能オブザーバビリティ(§7.4): IB トランスポート層のイベント(RDMA WQE、制御メッセージ)を監視する Perf profiler。AlgoProfiler / SlowRankDetector / QueuePairProfiler の三モジュールを持ち、PTP で全 host のクロックを同期する。 - CPU エミュレーション(§7.5): CUDA/RDMA を mock 共有ライブラリで差し替え、未改変の NCCL コードを CPU クラスタで実行。host あたり 32 プロセスで 3,072 CPU サーバから 96K 規模テストが可能。busy-loop on I/O や O(N²) 複雑度、64K rank 超での TCP listen queue 溢れ(指数バックオフ再接続で対処)などを発見した。 ## 新規性 - カーネル駆動・コピーベースが主流のなか、ゼロコピー・SM フリー・ホスト駆動を設計原理に据えた CTran により、ユーザバッファ間で直接 RDMA を発行し HBM 帯域・SM の競合を解消する(§8.2)。 - NVSHMEM のような別ランタイムを要さず、ホスト駆動のまま低レイテンシ AllToAll を実現する点(§6.2, §8.2)。 - メタデータを GPU 常駐とすることでパディングを回避する GPU-resident collective スキーム(AllToAllvDynamic)を導入した点(§6.1)。 - フォールトトレラントコレクティブ(FTAR)と自動の障害解析(Fault Analyzer)で、障害を跨いだ訓練継続とデバッグ時間短縮を本番システムに組み込んだ点(§5.3, §7.3)。 ## 実験設定 - 環境: 10 万 GPU 超を単一 RoCE ファブリックに統合した Meta の複数 DC 建屋クラスタ(H100、3 層 Clos + ATSW メッシュ)(§2.3)。 - 対象モデル: Llama4(推論評価は Llama4 Maverick)(§1, §6.3)。 - 比較対象: ベースライン NCCL(コピーベース送受信、NCCL zero-copy、NCCL AllReduce、デフォルト process group 初期化など)。 ## 実験結果 - ゼロコピー P2P(§4.5, 図7): コピーベースは転送ごとに一定のレイテンシ税を課し、cross-Host で全体転送時間を最大 2 倍に増やす。中サイズの帯域もチャンキングにより劣化する。 - P2P(§5.5, 図10): CTran ctranSend と NCCL zero-copy はコピーベース比で 1.09〜2.7 倍の高速化を達成。ただし NCCL zero-copy は PyTorch expandable segment 併用時のバッファ登録が不十分で本番投入できない。 - TP オーバーラップ(§5.5, 図11): 単一ノードで TP-Overlapping により E2E レイテンシを 1.57× 低減。NVL CopyEngine 利用のため SM を消費せず計算と干渉しない。 - FTAR(§5.5, 図12): 標準 NCCL AllReduce と同等レイテンシを thread block 半分(2 対 4)で達成。同じ thread block 数に揃えると FTAR は 9〜18% 低レイテンシ。実訓練で内側計算への干渉は確認されなかった。 - 推論デコード(§6.3, 表3): AllToAllvDynamic はベースライン比で 15〜80% のデコードレイテンシ改善。単一ノード比では k=1 で最大 43% 改善。転送量(k)が大きいほど利得が増す。 - スケーラブル初期化(§7.1, 図21): デフォルト process group 生成でベースライン NCCL 比最大 11×。96K 規模では NCCL の初期化が 4 分超に達する。 - メモリ管理(§7.2, 表4): 64K GPU の Llama4 事前学習で 10+ communicator のメモリをほぼ 2 分の 1 に削減。 - 訓練ステップ(§1): Llama4 の各定常訓練ステップのレイテンシを各規模で最大 12% 削減。 ## 考察 本研究は、通信インフラを最先端 AI の計算需要と協調設計することの重要性を強調する(§9)。CTran のホスト駆動フレームワークは、HPC で確立された古典的 CPU 通信アルゴリズム(Brucks, Recursive Doubling など)の移植を容易にし(§4.3.2)、TP オーバーラップ・FTAR・GPU 常駐コレクティブのような細粒度のモデル協調設計を可能にした。device-initiated API は今後の課題として残されている(§3)。集合通信の信頼性・依存追跡という観点では [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] の課題意識と通底し、本稿の Fault Analyzer / CollTrace(§7.3)は同方向の運用ツールと位置づけられる。 ## 強み - 訓練と推論の双方を単一スタック(統一ランタイム)で支え、二重ランタイム化の運用負担を避ける設計(§2.2, §8.2)。 - ゼロコピー・SM フリーにより通信と計算の資源競合を構造的に解消し、図7・図10・図11 で定量的に裏づけている。 - 100K 規模特有のボトルネック(初期化の非線形増大、メモリ・QP 資源の浪費、障害箇所特定)を、CPU エミュレーションを含む実践的手法で個別に解いている(§7)。 - NCCL/PyTorch エコシステムとの後方互換性を保ちつつ拡張する現実的な本番志向(環境変数での切替、オフライン auto-tuning との連携)(§3, 表4)。 ## 弱点・課題 - device-initiated API は進行中で未完成であり、小メッセージ・細粒度オーバーラップでの NVSHMEM 的利点は将来課題に留まる(§3)。 - ゼロコピーのテンソル登録は GPU RDMA ドライバのプロセス間ロック競合で 100 ミリ秒級の登録スパイクを生じ、原因は NVIDIA と究明中(§4.3.1)。 - NCCL zero-copy は本番投入できず(登録支援が不十分)、memory-pool モードは明示的なテンソルラベリングを要し、CUDA Graph による自動化は事前学習でまだ無効(§4.3.1, §5.5)。 - 評価は Meta 内部の Llama4 と自社 RoCE ファブリックに特化しており、他組織・他ハードウェアへの一般化可能性は本稿の範囲外(§9)。 - GPU 常駐コレクティブは AllToAllvDynamic のみ実装済みで、AllGather などへの拡張は未実装(§6.1.1)。 ## 出典 - [[.raw/papers/arxiv-2510.20171.pdf]](arXiv:2510.20171v4 [cs.DC]) - コード: https://github.com/meta-pytorch/torchcomms - 既存ノート: [[papers/2025__arXiv__Collective Communication for 100k+ GPUs|Collective 100k+ 既存ノート]]