# 集合通信 ## 定義 集合通信(collective communication)とは、多数の GPU/ノードが AllReduce・AllGather・AllToAll・ReduceScatter などの集団操作でデータを交換する仕組みで、LLM の分散学習・推論における通信の中核を担う。NVIDIA の NCCL([[NCCL]])や RCCL・MSCCL といった集合通信ライブラリ(CCL: Collective Communication Library)が実装を提供する。CCL は内部状態を露出しない「ブラックボックス」として振る舞うため、性能・信頼性の両面で運用上の課題を生む。([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) 数万〜10 万超の GPU 規模では、従来の CCL のカーネル駆動・コピーベース設計がスループットとレイテンシの制約になる。([[@2025__arXiv__Collective Communication for 100k+ GPUs]]) ## 横断的知見 - **同じ「CCL ブラックボックス」課題を、観測側と機構側の両方から攻めている**: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は CCL の内部状態(制御依存・データ依存)を**可観測化**して信頼性問題の根本原因分析を行い、[[@2025__arXiv__Collective Communication for 100k+ GPUs]](NCCLX)は通信スタックそのものを**再設計**して性能を上げる。前者は「見えないから直せない」を、後者は「速くできない/壊れやすい」を解く。どちらも NCCL を出発点とし、ブラックボックス性の打破という同じ問題意識を共有する。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **フロー/QP 単位の細粒度がスケール時の鍵になる**: Mycroft は同一 Coll Op 内でも異なる NIC・経路を使うフロー単位でトレースし、Op 単位では見えない局所的輻輳を検出する。NCCLX は Dynamic Queue Pair Load Balancing([[DQPLB]])で QP 単位の負荷を分散し輻輳を管理する。Op をひとかたまりに見ず、その下のフロー/QP 粒度に降りることが、両者で大規模時の性能・信頼性を左右する共通設計になっている。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **ゼロコピー/低オーバーヘッドが GPU リソース競合の回避軸**: NCCLX はユーザバッファから NIC への直接転送(ゼロコピー)で HBM 帯域と計算リソースの競合を削り、P2P レイテンシを最大 2 倍改善する。Mycroft は固定サイズ環形バッファ(512MB/ホスト)と非同期送信で計装オーバーヘッドをほぼゼロにする。通信の可視化も最適化も「GPU の本計算を邪魔しない」ことが必須要件になる。(Source: [[@2025__arXiv__Collective Communication for 100k+ GPUs]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) - **集合通信の細粒度可視化が診断の鍵という収束**: 複数の独立した取り組みが、AllReduce/All-to-All のブラックボックス性を「フロー/QP/チャンク」のいずれかの細粒度に降りて攻めるという同じ結論に収束している。[[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] の C4D は [[ACCL]] 層で集約通信のフローを監視し通信遅延行列の行・列偏りから slow connection を特定する。[[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] は PFC のフロー単位の来歴(プロベナンス)を辿る。既存の [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] はチャンク単位の依存トレース、[[@2025__arXiv__Collective Communication for 100k+ GPUs]] は QP 単位の負荷分散([[DQPLB]])を採る。Op をひとかたまりに見ず、その下の粒度に降りることがスケール時の診断・最適化の共通鍵になっている。(Source: [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **集合通信の症状が障害検知のシグナルになるという二面性**: 集合通信は障害の隠蔽源にも検知源にもなる。[[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] では NCCL がアダプタ障害を透過的にリルートして帯域が実質半減しステップ時間が約 0.3 秒増えるが、ジョブはクラッシュせず見かけ上動き続けるため[[ストラグラー|フェイルスロー]]を生む(MoE ではエキスパート並列の 2 同期点で影響が層数分累積)。Hawkeye の PFC 連鎖輻輳も同様に集合通信のフローを律速しつつ障害を吸収する。一方 C4D は同じ集合通信の周期性・同質性(BSP 同期点)を逆手に取り、各 GPU の到達タイミングのずれから異常を検知する。隠蔽されたフェイルスローを暴くのも、その周期性を診断トリガーにするのも、ともに集合通信の同期構造に依拠している。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **NCCL タイムアウトは症状であって原因ではなく、ネットワークへの誤帰属を招きやすい**: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] の障害タクソノミーでは、NCCL timeout はユーザコード・システムソフトウェア・ハードウェアの全ドメインにまたがる曖昧な症状として扱われる。論文は、NCCL timeout を近接原因であるネットワークへ素朴に帰属しがちだが、実際にはデッドロックや userspace crash、故障ハードウェアなど複数原因がありうると警告する。これは Mycroft/C4D/XPUTimer が集合通信内部や同期点を可視化しようとする動機を、運用タクソノミー側から裏づける。(Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **集合通信の信頼性は CCL 内部だけでなくファブリックの自己修復にも依存する**: Kokolis 2025 は InfiniBand link error が障害率に大きく寄与し、bring-up 期にはリンク問題で 50-75% の帯域損失を観測したと報告する。適応ルーティング(AR)は 512 GPU NCCL AllReduce のリンクエラー実験と、64 グループ×16 GPU の輻輳実験で帯域と性能分散を改善する。CCL の依存トレース(Mycroft)やフロー計画(C4P)が通信ソフトウェア側の対策であるのに対し、AR はスイッチが不健全リンクや輻輳を迂回するファブリック側の対策であり、両者は補完関係にある。(Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **少数の長寿命フローという分散訓練固有特性がネットワーク最適化の前提**: C4P は集約通信が「限られた数の長寿命フロー」からなる予測可能な通信モデルである点を活かし、フロー間の帯域競合をグローバルな経路計画で削減して単一 allreduce を 240Gbps から 360Gbps へ(50% 向上)、8 並行ジョブでスループットを 70.3% 向上させる。集合通信のフロー数が少なく予測可能であることが、汎用トラフィック工学では得られない大域計画を成立させる。NCCLX の QP 単位負荷分散([[DQPLB]])も、フローの長寿命性ゆえに QP 粒度の静的・準静的な分散が効くという同じ前提に立つ。(Source: [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - 集合通信は「予測が難しいが観測価値が高い」レイヤー。[[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]] では DP All-reduce/All-gather・PP P2P の予測誤差が 50% を超えることもある一方、マシン障害検知([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])では PFC/NVLink 系メトリクスが障害感度の上位を占める。(Source: [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - 通信ハングの故障 GPU 特定で、NCCL test の全数探索(thousand-GPU で 30 分超)に対し [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] は稼働中 ring-allreduce カーネルの SASS レジスタを CUDA-GDB で読む intra-kernel inspecting で O(1)・最大 309.2 秒を達成する。(Source: [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - CCL は計算と通信の境界に位置し主流フレームワーク(Megatron/DeepSpeed)で独立差し替え可能。[[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] はこれを「顧客コード非侵入で診断情報を仕込む架け橋」に使い、[[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] は CCL 計装をクラウド事業者には不向きと評する。(Source: [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - DP の AllReduce/Reduce-scatter/All-gather は通信量が PP を大きく上回り輻輳の主因。[[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] はこの量的偏りを使い DP グループにスイッチ層診断を集中する。一方 [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] は ncclAllReduce 等の NCCL API を計装しレイテンシ・メッセージサイズを非侵入で測る。(Source: [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]], [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]) - **AllToAllv スケジューリングは NP 困難問題から多項式時間問題に「問題の単純化」で帰着できる**: TACCL・TE-CCL・SyCCL が AllToAllv を NP 困難な制約充足問題として定式化し秒〜時間の合成時間を要するのに対し、[[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] は「スケール外を最適化し、スケール内で歪みを吸収する」という問題の再定義により 1 対 1 マッチング問題(多項式時間)に帰着する。既存 AllReduce/AllGather 最適化が「スケジュール合成コストを多数イテレーションで償却できる」という前提に立つのに対し、AllToAllv は MoE のゲーティングで数百ミリ秒ごとにパターンが変化するためこの前提が崩れる——すなわち集合通信の操作種別によってオンライン性の要件が根本的に異なる。(Source: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **Birkhoff 分解を GPU 集団通信層に初めて適用することで「最適性」と「インキャスト回避」を多項式時間で同時保証する**: C4P が長寿命フローの予測可能性を前提とし、TACCL/Wormhole が NCCL の固定スケジュールをブラックボックスとして扱うのと異なり、[[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] はBirkhoff 分解をスケール外スケジューリングに直接適用する。各ステージが 1 対 1 マッチング(インキャスト不発生)を満たし、かつボトルネックサーバを全ステージで連続稼働させることで理論下限に到達する——この 2 保証を持つスケジューラは従来のソルバーベースではなかった。FAST の最悪ケース性能境界は B₁/B₂ × (m + m/n) と数学的に証明されており、今日の H100 クラスタで最悪でも最適値の 2.12× 以内に収まる。(Source: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **ヘテロジニアスクラスタでは「スケジュール合成の正確さ」と「実行時のパイプライン均質性」が分離して問題になる**: TACCL・TE-CCL は同一トポロジから最適スケジュールを自動合成するが、帯域幅の異なるリンク上に所要時間不均一なプリミティブが同一ステップに並ぶと実行時にパイプラインバブルが生じ、合成された「最適」スケジュールが実性能を大幅に下回る。[[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]] はチャンキングによってリンク容量を基準時間ステップに正規化しプリミティブ所要時間を均質化することで合成と実行の乖離を解消する。FAST の Birkhoff 分解が AllToAllv の「各ステージを 1 対 1 マッチングに保つ」と同様に、HeteCCL の「各ステップ内のプリミティブ所要時間を均一化する」という設計原則は、いずれも「合成上の最適性と実行上の効率を分離せず同時に保証する」という共通指針の別表れである。(Source: [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **ヘテロジニアスクラスタは対称性ベースの探索削減を無効化し新たな枝刈り手法を要求する**: TACCL・TE-CCL・SyCCL はホモジニアスクラスタのトポロジ対称性を利用してスケジュール探索空間をサブドメインに分解するが、異種 GPU・異種リンク帯域幅の混在するヘテロジニアス環境ではこの対称性が消えグローバル制約全体を符号化せざるを得ず、32 GPU でも TACCL はタイムアウト・TE-CCL は 9 時間超を要する。HeteCCL は CEGIS(反例誘導的帰納合成)を集合通信合成に適用し、反例 1 件で部分木全体(n! 以上の規模)の候補を枝刈りすることで 64 GPU でも 9 分未満に収める。これは FAST が AllToAllv の動的スケジューリングでソルバーベースを排除した方向と同じ「固有の問題構造に合わせた探索削減」という設計志向を共有する。(Source: [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **集合通信フローの規則性が PLDES 高速化の基盤になる**: [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]](Wormhole)は DP フロー(AllReduce/Reduce-scatter/All-gather)が同一イテレーション内で同じ競合パターンを繰り返し(GPT-13B/128 GPU で 1633 パターン・1200 回超)、かつ輻輳制御収束後にレートが安定するという集合通信固有の構造を、メモ化と早送りで 744×(+Unison で 1012×)の計算削減に変換する。「少数の長寿命フローが予測可能なパターンを示す」という C4P(トラフィック計画)・NCCLX(QP 単位負荷分散)が前提とする同じ構造的特性が、ここでは PLDES 高速化の前提にもなっている。(Source: [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **AllToAllv のスケジューリングは AllReduce と根本的に異なる運用要件を持つ**: AllReduce は静的・均等でスケジュールの事前計算・償却が可能だが、AllToAllv は MoE のエキスパート選択で転送量が数百 ms 単位で変化しスキューが最大 12× に達する。[[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] は Birkhoff 分解を GPU 集合通信に初適用し、多項式時間(O(N⁵))でインキャスト回避と理論的完了時間下限を同時達成する——「操作ごとにオンライン性の要件が根本的に異なる」ことが集合通信スケジューリングの設計前提になる。(Source: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **ヘテロジニアスクラスタでは合成の正確さと実行時パイプライン均質性が分離した問題になる**: [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]] は、リンク速度が不均一な環境では対称性ベースの探索削減が失効し、合成時間が 64 GPU で 9 時間超に膨らむことを示す。チャンキングで各ステップ内のプリミティブ所要時間を均質化し、CEGIS(反例誘導的帰納合成)で探索を枝刈りすることで 9 分未満に短縮——FAST の Birkhoff 分解と共通する「問題固有の構造的単純化で NP 困難を回避する」設計志向が、ホモジニアス(FAST)とヘテロジニアス(HeteCCL)の双方で独立に現れる。(Source: [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]]) - **LLM 訓練の規則性(反復構造・ステディステート)がシミュレーション高速化にも転用される**: [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]] は DP フローの繰り返しパターン・97〜99% のステディステート占有率を活用し、フロー競合グラフ(FCG)のメモ化と早送りで ns-3 比 744〜1012× の高速化を誤差 1% 未満で実現する。C4P のトラフィック計画・NCCLX の QP 負荷分散と同じ「少数の長寿命フローの規則性を前提とする」設計パターンが、シミュレーション高速化の第三の応用面として加わる。(Source: [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]]) - **PTD-P 訓練では TP が通信量の約 99% を占め、プロトコル選択が PP/DP オーバーヘッドに非対称な効果をもたらす**: [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]] の GPT-3B 実測(32 GPU)で TP が ~85 GB、PP が ~1 GB、DP が 741 MB と TP が圧倒的に支配する。しかし TP 通信はノード内(NVLink/PCIe)で完結するため TCP→RoCEv2 の恩恵を受けないのに対し、ノード間の PP は 2.5×・DP は 1.6× の通信削減を得た。集合通信操作が「どのネットワーク層を通るか」によってプロトコル最適化の適用可否が分かれる。(Source: [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]]) - **通信マトリクスは並列化戦略とマッピングから事前計算可能であり、「予測可能性」は訓練前に検証できる**: 密活性化モデルでは、論理的な並列化戦略(p, t, d)と物理ハードウェアへのマッピングが決まれば、どの GPU ペアが通信するかを実行前に計算できる。一方 MoE の all-to-all 通信は動的で、訓練初期(イテレーション 10)と後期(イテレーション 90)でヒートマップが大きく異なる。MoE 訓練の通信パターンはゲートネットワークの学習に伴い収束し「半予測可能」になる。(Source: [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]]) - **フレームワーク非依存 CCL とフレームワークネイティブ実装の通信効率の乖離は、制御プレーン改善とグルーピングで埋められる**: [[Horovod]] は TF/PyTorch/MXNet 等に対応するフレームワーク非依存 CCL だが、フレームワーク内部情報(テンソル集合・バケット定義)にアクセスできないため、大規模時に O(N) の制御プレーンオーバーヘッドが生じ、6000 GPU ではコーディネータ処理が GPU 利用率を 55% 未満に律速した。[[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]] は応答キャッシュ(2 イテレーション目以降の制御通信を完全バイパス)とグルーピング(明示的通信バッファ制御)で既存 Horovod 比 2× の性能向上を達成し、フレームワークネイティブの tf.distribute 比 12% 優位、torch.DDP と同等の性能を実現した。フレームワーク非依存の設計制約を「訓練ランを通じてテンソル集合が固定」という観察でランタイム推論により克服する手法は、CCL が内部モデル情報を持てないという制約の別解を示す。(Source: [[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]], [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]]) - **グルーピングによる通信バッファ明示制御の効果はバックエンドに依存し、NCCL では有効だが MPI では限定的または負になる**: [[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]] の NCCL バックエンドではグルーピングにより大きなバッファでの AllReduce が可能になりネットワーク帯域利用効率が改善するが、MPI バックエンドでは効果が限定的または負になる場合がある。これは [[NCCL]] と MPI が大バッファを異なる方法で処理するためである。[[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication|FAST]] の Birkhoff 分解が均等/不均等を動的に判別してスケジューリング戦略を切り替える設計方針([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])と対照的に、バッファサイズ最適化がバックエンド特性と密結合する点は、フレームワーク非依存 CCL の抽象化の限界を示す。(Source: [[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **2022 年時点の HPC 大規模評価と 2025〜2026 年の産業規模評価では、集合通信の律速要因が制御プレーン(Horovod の O(N) 調整)からデータプレーン(NCCLX のカーネル駆動/コピーベース設計)へ移行している**: [[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]] が 6000 GPU でコーディネータの制御通信コストをボトルネックとして同定したのに対し、[[@2025__arXiv__Collective Communication for 100k+ GPUs]](NCCLX)は 10 万+ GPU 規模でカーネル駆動・コピーベースという NCCL のデータプレーン設計そのものを限界として再設計を迫る。同じ「集合通信がスループットのボトルネック」という問題意識が、スケール拡大に伴い制御プレーンからデータプレーンへ律速層を移しながら継続的に現れている。(Source: [[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **NCCL の「プロトコル選択のブラックボックス」が初めて解明され、ノード内外・メッセージサイズによる最適解の非対称性が定量化された**: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]] は NCCL 2.19.1 のプロトコル(Simple/LL/LL128)・データ転送(P2P/SHM/IB Verbs)・集団アルゴリズム(Ring/Tree)を初めて体系的に文書化した。実測(CSCS Alps、GH200、16 ノード、Cray Slingshot)で、LL128 がノード内(NVLink)では全サイズで最安定な性能を示す一方、ノード間大メッセージでは Simple が最速であることを確認した。これは「CCL はメッセージサイズが同じでも通信経路(ノード内外)によって最適プロトコルが異なる」という従来の直感を実測で裏付けた。同論文でノード間 LL128 が大サイズで LL を下回る場合があることも示され、NCCL_CROSS_NIC を調整した先行研究([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])やオートチューニングを推奨する主張([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])と整合する。(Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) - **Ring AllReduce の「2k-1 ステップ」構造は Mycroft のチャンク単位依存トレースと VCCL の SM-free 設計の共通的前提となっている**: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]] は Ring AllReduce が ReduceScatter フェーズ(k-1 ステップ)と AllGather フェーズ(k ステップ)の 2k-1 ステップで完結し、各ステップで send/recvReduceSend/recvReduceCopySend/recvCopySend/recv のプリミティブを厳密に適用することを文書化した。これは Mycroft([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])がチャンク単位の依存グラフ(制御依存・データ依存)を構築できる理論的根拠となり、VCCL([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])がノード内 P2P 操作でのカーネル起動ゼロを「Ring ステップ単位の同期に CPU スレッドを使う」設計で実現できる理由でもある。「プリミティブの種類と順序が確定している」という Ring の非パイプライン性が、外部からのトレース・内部の SM-free 再設計の双方を可能にしている。(Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]) - **「集合通信アルゴリズムのステップ分解」が診断粒度の新たな軸になる**: Mycroft はチャンク単位、C4D は BSP 同期点、Hawkeye は PFC フロー単位で集合通信の内部状態を観測する。[[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]](Vedrfolnir)はアルゴリズム固有の「ステップ」を分解単位とし、ステップ間の待機依存を**有向重み付きグラフ(待機グラフ)**で表現する。これにより「同一の集合通信 Op 内でどのフローが後続ステップを待機させているか」という co-flow 依存が可視化され、ネットワーク計測では見えないホスト側のボトルネック(クリティカルパス)を特定できる。アルゴリズムの論理的な操作単位(ステップ)を診断粒度にする発想は、チャンク・BSP 同期点・フローに並ぶ第四の観点として位置づけられる。(Source: [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **「SM をゼロにする」という CCL 再設計の二つの流儀——NCCLX と VCCL の対比**: [[@2025__arXiv__Collective Communication for 100k+ GPUs]](NCCLX)は CTran でホスト側に通信制御を移し大半のカーネルを排除するが、device-initiated API が未完で一部操作に SM を残す。[[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL)はノード内 P2P の全操作でカーネル起動をゼロにし、SM 占有を完全に排除した——CPU スレッドとコピーエンジン + `cuStreamWriteValue`/`cuStreamWaitValue` による GPU-CPU 同期を組み合わせることで実現。結果、非リダクション系 P2P 操作の訓練スループットが平均 4.00%・最大 5.28% 向上した。「SM をどこまで排除できるか」という同一の設計軸で、NCCLX が「大幅削減」、VCCL が「P2P 操作でゼロ」という独立した工学的帰結に到達しており、どちらも NCCL のカーネル駆動設計を出発点の限界と見なしている。(Source: [[@2025__arXiv__Collective Communication for 100k+ GPUs]], [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]) - **CCL 組み込みの O(μs) RDMA モニタが「ブラックボックス打破」の第三の経路を開く**: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL)はスライディングウィンドウ型 RDMA モニタを CCL 内部に組み込み、WR/WC のタイムスタンプを集積して O(μs) 粒度でスループットを推定し、「帯域 < 直近平均の 50% かつ RtS データ > 過去最大の 2 倍」という双閾値で異常を検知する。[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](Mycroft)が CCL 外から依存トレースを差し込み、[[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](Pulse)がネットワーク層で受動計測するのとは対照的に、VCCL は CCL 自身が計装者を兼ねることで「外部計装なし・SDK 改修不要」を最小コストで実現する。CCL ブラックボックス問題は「外から見える化する(Mycroft/Pulse)」と「内側から計装する(VCCL)」という二方向で収束点が異なり、かつどちらも既存 NCCL では不可能な設計である点で補完的である。(Source: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - **NCCL_CROSS_NIC=0 でリング経路をトポロジ境界に閉じ込められる(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: Rail-Optimized Topology において、3 ノード以上の AllReduce では NCCL がデフォルトで Spine を越えるリングを形成することがある(特に奇数ノード)。`NCCL_CROSS_NIC=0` を設定して「同一リングで同一 NIC を使う」よう制約すると、リングが Leaf 層内に閉じて Spine 通過トラフィックをほぼゼロにできる。性能劣化なしで確認されており、デフォルト設定として組み込んでいる。ただしユーザーがアプリケーションで別の環境変数設定を使うケースでは効果が失われる。 ## 未解決の問い - NCCL 2.19.1 ベースの Demystifying NCCL 解析が NCCL 2.23 以降(PAT アルゴリズム追加)や次世代バージョンでも有効か。CollNet/NVLS の詳細解析は誰が行うのか。([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) - Tree AllReduce の SM 非対称分割(Reduce フェーズに多スレッド割り当て)は、MoE の不均等な縮約負荷でも安定して機能するか。アルゴリズム選択(Ring vs Tree)とメッセージサイズのしきい値は訓練規模やトポロジに依存してどう変化するか。([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) - LL128 がノード間大メッセージで LL を下回る条件(128B オペレーション当たりコストの累積と輻輳によるストール)を事前に予測するモデルは成立するか。ATLAHS の誤差 5% 以内はこの非線形な劣化もカバーするか。([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) - Rail-Optimized Topology 上でサービスとして任意ノード数を払い出す場合、NCCL_CROSS_NIC=0 をユーザーのアプリケーション設定に関わらず確実に適用させる仕組みはどうあるべきか? - plugin 経由で制御情報を渡せる新しい CCL でも Mycroft の依存駆動分析は成立するか。CCL ごとにメトリクス再定義・トレースポイント・分析ルールの調整が要る。 - 観測(Mycroft)と機構(NCCLX)を統合した運用 — 例えば NCCLX 内蔵の Fault Analyzer/CollTrace と Mycroft の依存追跡 — はどこまで重なり、どう補完し合うか。 - ホスト駆動(NCCLX の CTran)で device-initiated(対称メモリ)型の細粒度利点をどこまで代替できるか。NCCLX の device-initiated API は未完。 - AllReduce/AllToAll 以外の操作(AllGather 等)や、訓練と推論で異なる通信パターンに、これらの知見はどの程度一般化するか。 - NCCL の透過的アダプタリルート(Guard)が引き起こすフェイルスローを、観測側(Mycroft の依存トレース・C4D の BSP 同期点監視)はどこまで早期に検知できるか。隠蔽が進む前に捕捉する遅延の下限はどこか。 - ファブリック側の適応ルーティングが障害を迂回したとき、CCL 側の診断レイヤーは「迂回により性能が落ちたが進行している」状態をどう扱うべきか。リルートで進める、ジョブを止めてノード/リンクを隔離する、経路計画を再最適化する、の切り替え基準は未整理である。 - フロー/QP/チャンクのどの粒度が診断と最適化の双方にとって最適か。Hawkeye はフロー、NCCLX は QP、Mycroft はチャンクを採るが、診断精度と計装オーバーヘッド・経路計画のしやすさを同時に満たす粒度は単一なのか、用途で分かれるのか。 - フォールトトレラント AllReduce(障害を吸収して進行を続ける)と経路計画(C4P の長寿命フロー大域計画)の分業はどう設計すべきか。リルートで帯域を犠牲にしてでも進めるべき局面と、計画で競合を避けて律速を解くべき局面の切り分けは未整理である。 - intra-kernel inspecting は ring 構造を前提とするが、tree/double-binary-tree やカスタム通信カーネルへどう拡張するか。 - 集合通信のアルゴリズム(ring vs tree)の違いはフロー観測パターンと診断精度にどう影響するか。 - FAST の Birkhoff 分解は均等 AllToAllv ではオーバーヘッドが生じる。スケード/均等を動的に判別してスケジューリング戦略を切り替える統合設計は成立するか。 - FAST は 4 サーバ(32 GPU)の実測にとどまる。Birkhoff 分解の段数が O(N²) になりうる極端なスケードでは、EP320 規模での実測性能はシミュレーション予測と乖離するか。 - テンソル並列・パイプライン並列が混在するハイブリッド並列化で、AllToAllv と他の集団通信がネットワークを共有する場合、FAST のスケール外スケジューリングは共有競合をどう扱うか。 - HeteCCL のチャンキングはヘテロジニアスリンクを均質化するが、同一ステップ内での縮約カーネルの計算レイテンシ差（GPU 世代間）はチャンキングで吸収しきれるか。計算・通信の協調最適化はどの設計が有効か。 - HeteCCL の階層合成（ポッド内 + ポッド間の 2 層）はポッドをまたぐグローバル最適化を犠牲にする。ヘテロジニアス大規模クラスタ（数千 GPU）でグローバル最適性を保ちつつスケールするアルゴリズムは成立するか。 - FAST の Birkhoff 分解(ホモジニアス・AllToAllv 特化)と HeteCCL の CEGIS(ヘテロジニアス・AllReduce/AllGather 等)のアプローチは統合できるか。ヘテロジニアスクラスタでの AllToAllv スケジューリングは未解決。 - Wormhole のメモ化が前提とする通信の規則性は、MoE の動的なエキスパート選択(FAST が示す最大 12× スキュー)下でも成立するか。 - Horovod の応答キャッシュ方式が前提とする「テンソル集合の固定性」は、動的アーキテクチャや MoE の動的エキスパート選択では成立しにくい。フレームワーク非依存 CCL においてテンソル集合の動的変化に対応したキャッシュ無効化・再学習の機構はどう設計するか。 - BytePS(パラメータサーバ方式)と AllReduce リング方式(Horovod/NCCL)の性能比較は HPC 環境(Summit の EDR InfiniBand)に限定される([[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]])。クラウド環境(イーサネット/RoCEv2)や 2025 年以降の大規模クラスタでの相対性能は検証されているか。 - VCCL の SM-free P2P は CPU スレッドとコピーエンジンを使うため GPU-CPU 同期オーバーヘッドが生じる。CPU スレッドのスケジューリング遅延が P2P レイテンシに与える影響は GPU 数規模に依存するか。NCCLX の CTran も同様の問題を抱えるが、両者でどちらの実装が低レイテンシ優先操作に適しているか。([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]) - VCCL の CCL 内蔵 O(μs) モニタと Mycroft の CCL 外部からの依存トレース、Pulse のネットワーク層受動計測を同一インシデントで組み合わせれば、「CCL 内 QP 切り替え遅延・CCL 外フロー輻輳・NIC ポート障害」を階層的に切り分けられるか。それとも計装点の違いにより同一障害を重複検知してノイズが増えるか。([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) - Vedrfolnir の待機グラフはアルゴリズム固有のステップ定義に依存するが、MoE の AllToAllv のようにステップのパターンが動的に変化するアルゴリズムへはどう汎化するか。Ring・Halving and Doubling 以外の集合通信アルゴリズム(Tree AllReduce 等)への拡張でクリティカルパスの計算複雑度はどう変わるか。([[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]]) - Vedrfolnir は NS3 シミュレーション(8 ノード)での評価にとどまる。実機テストベッド(数百〜数千 GPU)での待機グラフ構築・プルーニング・クリティカルパス計算のレイテンシは、ステップごとの診断応答時間の要件を満たすか。([[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]]) - **CCL Slow/Hang は件数以上に診断コストを支配する**: [[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]] は 1,000-H800 GPU クラスタの 3 か月観察で、CCL Slow/Hang が全訓練割り込みの 35.2% を占めながら診断時間の 58.8%(70 時間)を消費することを実測した。これは Mycroft([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])が CCL の暗黙的障害(silent timeout)を 15 秒以内に検知できると報告し、C4D([[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]])が BSP 同期点ベースで通信遅延行列を 5 分ハング/1 分スローで診断するのと対比されるとき、「診断ターゲットが同じ CCL 異常でも、どの情報源(CCL 外部トレース・BSP 同期・カーネルレベル Send/Recv)を使うかが精度と検知カテゴリの網羅性を決定的に分ける」ことを定量的に示す。(Source: [[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **「カーネルレベル Send/Recv」がハング 3 種・スロー 3 種を単一フレームワークで網羅できる唯一の粒度である**: CCL-D は Send/Recv プリミティブ(SendCount/RecvCount/SendRate/RecvRate)を用いることで H1 Not-Entered-Hang・H2 Inconsistent-Hang・H3 Hardware-Fault・S1 Computation-Slow・S2 Communication-Slow・S3 Mixed-Slow の全 6 カテゴリを網羅する。C4D(BSP 同期点ベース)が Inconsistent-Hang・Hardware-Fault・Comp-Slow・Mixed-Slow を見逃し、NCCL RAS(ホストレベルカウントのみ)が Not-Entered-Hang しか特定できず、Greyhound(ステップ時間監視)がハング機構を持たないのと比較すると、カーネルレベルへ降りた Send/Recv 単独が全カテゴリの十分条件であることが示される。XPUTimer([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])の intra-kernel SASS レジスタ読み取りとは異なり、CCL-D は CCL 実装への組み込みで外部 CUDA デバッガ依存を回避する。(Source: [[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]]) - **ノード内とノード間で最適な通信ライブラリが逆転する**: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]](SC 2024)は Alps・Leonardo・LUMI の3台を同一ベンチマークで評価し、「ノード内集団通信では*CCL が優位(トポロジ最適化のため)、ノード間点対点では GPU-Aware MPI が最大10倍高速(カーネルオーバーヘッドがないため)」という非対称な結論を示した。CCL の「ブラックボックス性」と「最適化の恩恵」はスコープ(ノード内/間)と操作種別(点対点/集団通信)によって逆の極性を持つ——特定の通信パターンで CCL が有利でも、別のパターンでは MPI が大幅に上回ることを実機で定量化した最初の大規模研究である。(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]]) - **ネットワークノイズは InfiniBand Dragonfly+ の集団通信を最大50%劣化させ、Slingshot はほぼ影響を受けない**: SC 2024 は Leonardo(InfiniBand HDR Dragonfly+)でサービスレベル差分実験を使って実本番ノイズが allreduce を最大50%・alltoall を最大20%低下させることを初めて定量化した。Alps/LUMI の HPE Cray Slingshot-11 は同様のノイズ耐性を示した先行研究と一致してほぼ影響を受けない。CCL の性能が「何 GPU 規模か」ではなく「どのファブリック技術か」によって支配される局面があることを示す。(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]]) ## 関連 - ソース: [[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]] / [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] / [[@2025__arXiv__Collective Communication for 100k+ GPUs]] / [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] / [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] / [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] / [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] / [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]] / [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] / [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] / [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] / [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] / [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] / [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] / [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]] / [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] / [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]] / [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]] / [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]] - 概念: [[LLM分散学習]] / [[耐障害LLM訓練]] / [[並列化戦略]] / [[GPUクラスタ運用]] / [[根本原因分析]] / [[ストラグラー]] / [[RDMAネットワーク監視]] / [[HPCインターコネクトベンチマーク]] - エンティティ: [[NCCL]] / [[NCCLX]] / [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters|VCCL]] / [[CTran]] / [[DQPLB]] / [[Megatron-LM]] / [[MegaScale]] / [[C4D]] / [[C4P]] / [[ACCL]] / [[Guard]] / [[Hawkeye]] / [[Infrawaves]] / [[iSING Lab]] / [[Kai Chen (HKUST)]] / [[ATLAHS]] / [[Torsten Hoefler]] / [[ETH Zürich]] / [[Daniele De Sensi]] / [[CINECA]] - 関連 MOC: [[AI Infra Telemetry - MOC]] / [[LLM4SRE - MOC]] ## 出典 - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](CCL ブラックボックス・フロー/チャンク単位トレース・依存駆動 RCA) - [[@2025__arXiv__Collective Communication for 100k+ GPUs]](NCCLX・CTran・ゼロコピー・DQPLB・10 万+GPU) - [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](NCCL 透過的リルートで帯域実質半減・ステップ時間+0.3 秒、MoE は 2 同期点で影響が層数分累積) - [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]](PFC 連鎖輻輳が集合通信のフローを律速、フロー単位の細粒度可視性、wait-for プロベナンス) - [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]](C4D=ACCL 拡張で集合通信をリアルタイム監視・BSP 同期点で異常検知、C4P=少数の長寿命フロー特性でトラフィック計画、単一 allreduce 240→360Gbps) - [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]](NCCL timeout の曖昧性、InfiniBand link error、適応ルーティングによる 512 GPU NCCL AllReduce の帯域安定化) - [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]](Birkhoff 分解を GPU 集団通信層に初適用・AllToAllv の 2 フェーズ動的スケジューリング・AMD MoE 訓練 RCCL 比最大 4.48× 向上・64 GPU で 221 µs 合成) - [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]](チャンキングによるヘテロジニアスリンクの均質化・CEGIS で合成を TE-CCL 比最大 322.8× 高速化・NCCL 比最大 2.8× の帯域幅・エンドツーエンド訓練 23〜37% 改善) - [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]](GPT-3B/32GPU で TP が通信量 99%・RoCEv2 が TCP 比 PP 2.5×/DP 1.6× 削減・通信マトリクスの事前計算可能性・MoE の半予測可能性定量化・解析的定式化の約 90% 推定精度) - [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL: SM-free P2P でカーネル起動ゼロ・訓練スループット平均 4.00%/最大 5.28% 向上、プライマリバックアップ QP で NIC 障害透過的吸収・GPU 待機時間 ~90% 削減、CCL 内蔵 O(μs) RDMA スライディングウィンドウモニタ、24K GPU 本番運用) - [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]](NCCL 2.19.1 内部解析: Simple/LL/LL128 三プロトコルの設計原理と実測・P2P_DIRECT モード・Ring AllReduce 2k-1 ステップ・Tree AllReduce SM 非対称分割・CSCS Alps GH200 16 ノードベンチマーク・ATLAHS シミュレーション誤差 5% 未満) - [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]] / [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]](Alps/Leonardo/LUMI 3台、最大4,096 GPU、ノード内外の通信 API 比較、ネットワークノイズ定量化、8つの観察、デフォルト設定チューニングで最大10倍改善)