# 集合通信 ## 定義 集合通信(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]]) ## 未解決の問い - 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× スキュー)下でも成立するか。 ## 関連 - ソース: [[@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]] - 概念: [[LLM分散学習]] / [[耐障害LLM訓練]] / [[並列化戦略]] / [[GPUクラスタ運用]] / [[根本原因分析]] / [[ストラグラー]] / [[RDMAネットワーク監視]] - エンティティ: [[NCCL]] / [[NCCLX]] / [[CTran]] / [[DQPLB]] / [[Megatron-LM]] / [[MegaScale]] / [[C4D]] / [[C4P]] / [[ACCL]] / [[Guard]] / [[Hawkeye]] - 関連 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% 改善)