# NCCL NVIDIA の Collective Communication Library。LLM 分散訓練で最も広く使われる CCL で、ノード内は PCIe/NVLink、ノード間は RDMA を使って all-reduce / all-gather / reduce-scatter 等の集団通信と P2P(send/recv)を提供する。(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], §2.1) [[Pulse]] にとっての要点: - 集団通信は **ring ベース / tree ベース**のアルゴリズムを count に応じて動的に選択するため、送信量はフックだけでは決まらない。Pulse はアクティブなピアのパターンから ring/tree を推定して期待送信量を導く(CollNet/NVLS は対象外)。 - 集団通信はデータを **slice**(≤1MB)に分割し、バブル緩和のため各集団通信を複数チャネル(≥2)に細分する(ノード間では 1 チャネル = 1 QP)。この slice 単位の同期がストラグラー由来のマイクロ秒のギャップを生む。 - **all-to-all** は NCCL 2.28 以前は専用オペレータを持たず P2P 操作の集合(カスタム集団通信)として実装され、MoE のトークンの dispatch/combine に使われる。Pulse は NCCL の Group call(`ncclGroupStart`/`End`)をフックして構成する P2P を束ねる。 他のソースでも LLM 訓練の標準通信基盤として頻出する([[MegaScale]]・[[Minder]]・LLM 訓練サーベイ)。 [[MEGATRACE]]([[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]], ICDCS 2026)は NCCL Verb API(Broadcast/AllReduce/AllGather/ReduceScatter/Send/Recv)の呼び出しタイムスタンプ・stream・rank を非侵入的にインターセプトし、「計算の narrow waist」として扱う。RDMA verbs インターフェース(`ibv_post_send`/`ibv_poll_cq`)を通過する Work Request(WR)を「通信の narrow waist」として別途計装し、両者を合わせてオーバーヘッド 0.16% でハング・スローダウンの局所化を行う。Mycroft・eACGM・XPUTimer が NCCL 内部を計装・フックして観測対象とする点は共通するが、MEGATRACE は集合通信 API 呼び出しのタイミングパターンから訓練スケジュール(TP/PP/DP)の依存 DAG を再構築しクリティカルパス分析でパイプラインバブルに吸収される偽陽性を除去する点に主眼を置く。(Source: [[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]]) NCCL を基盤・対象とする周辺研究: - [[NCCLX]]([[@2025__arXiv__Collective Communication for 100k+ GPUs]])は NCCL を基盤に拡張した Meta の集合通信フレームワークで、ホスト駆動・カーネル駆動・コピーベースという NCCL の制約(動的引数の扱いにくさ、CUDA Graph 非互換、パディング)を比較対象として、ゼロコピーの [[CTran]] を提示する。(Source: [[@2025__arXiv__Collective Communication for 100k+ GPUs]], §2.2) - Mycroft([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])は NCCL(2.21.5)のソフトウェアスタックへ直接トレースポイントを追加する軽量計装(約1100行の C++)で、proxy スレッドから臨界経路のランタイム状態を連続トレーシングする。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], §4.2) - [[eACGM]]([[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]])は `ncclAllReduce` 等の NCCL API を eBPF で計装してレイテンシとメッセージサイズを測定し、注入したネットワーク遅延・パケットロスを GMM で 85.04%(全層中最高)の精度で検知する。(Source: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]) - [[XPUTimer]](Flare、[[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])は `LD_PRELOAD` で NCCL カーネルをフックしつつ、通信ハング時には CUDA-GDB で稼働中の ring-allreduce カーネルのレジスタを読む intra-kernel inspecting で故障 GPU を O(1) 特定する。NCCL を debug 情報付きで再コンパイルする必要がない点が利点。(Source: [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]] は、NCCL all-reduce ベンチマークを DeepSpeed 訓練前のチューニング段に使い、NCCL_NTHREADS や NCCL_MIN_NCHANNELS などの環境変数を探索する。64 GPU では改善は約 0.5% と小さいが、480 GPU 規模では BO チューニング済み構成が既定構成より GPU あたり最大 +10GB/s の帯域を得ると報告する。(Source: [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]]) **「Every Microsecond Matters」([[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]])** は NCCL 2.28 以降のデバイス側 API 上に低レイテンシ AllReduce カーネル群を実装した論文(ETH Zürich・NVIDIA 共著)。既存の one-shot/two-shot AllReduce 実装が memory barrier(GB200 実測で 1 回あたり 1 µs 超)に依存している点を突き止め、LL・sentinel 同期・双方向通信+double buffering・two-shot LL128 atomic の 4 技術で barrier を完全に排除する設計を `NCCL_SYM_KERNEL`(`AllReduce_LLBuffer` / `_Twoshot` / `AllReduce_LL128_Atomic`)として NCCL に統合した。GB200 の Speed-of-Light(SoL)理論下限 1.404 µs に対し 2 GPU で約 7% のオーバーヘッドまで到達し、vLLM 推論の inter-token latency を最大 13% 削減する。 **「Demystifying NCCL」([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])** は NCCL 2.19.1 の内部設計を初めて体系的に解析した論文。ETH Zürich SPCL・NVIDIA・Broadcom の共著。以下を文書化した: - **三プロトコル設計原理**: Simple(メモリフェンス・ほぼピーク帯域・~6µs/hop)・LL(フラグ同期・25〜50% 帯域・~1µs/hop)・LL128(フラグ同期・~95% 帯域・~2µs/hop、128B アトミック書き込みを要求し PCIe 環境では無効化)。 - **P2P_DIRECT モード**: 同一プロセス内では IPC ハンドルなし + directSend/directRecv で中間 FIFO バッファコピーを排除。 - **Ring AllReduce は 2k-1 ステップ**(ReduceScatter k-1 + AllGather k)、**Tree AllReduce は SM を非対称 2 分割**して Reduce/Broadcast を並行実行しパイプライン効率を高める。 - **LL128 はノード内(NVLink)で全メッセージサイズにわたり最も安定した性能**を示す。ノード間大メッセージでは Simple が一貫して最速。 - 本解析は ATLAHS シミュレーションツールチェーンの基盤となり誤差 5% 未満を達成。 **[[PrismLLM]]([[@2026__arXiv__A Few GPUs, A Whole Lotta Scale]])** は NCCL のデータ転送ロジックを直接改変し、少数 GPU での大規模訓練エミュレーションを実現する。具体的には (1) NCCL グループ削減で、仮想ランクについてサンドボックスと重なる通信グループのみをインスタンス化し(2,000 仮想ランクでアクティブグループ数を 8,617→82 に削減)、(2) ランタイム通信プルーニングで、ring/tree アルゴリズム上の非近傍仮想ランクへのデータ転送をスキップしつつ、reduction/broadcast の数値的正しさを補正値の事前計算で保証する。プルーニングなしの Vanilla 実装は通信レイテンシが最大 148 倍に膨張するのに対し、PrismLLM は実行ベースライン比で最大誤差 0.2% に抑える。Mycroft・eACGM・XPUTimer が NCCL を「観測・診断」対象として扱うのに対し、PrismLLM は NCCL 自体の内部動作を改変して「エミュレーション基盤」として使う点で異なるアプローチを取る。(Source: [[@2026__arXiv__A Few GPUs, A Whole Lotta Scale]]) **[[NIXT]]([[@2026__arXiv__NIXT - A NCCL Inspector Exporter Tool for Observability of Collective Communication in Large Model Training]])** は NCCL 2.28 に同梱される公式プロファイラプラグイン NCCL Inspector の出力を DuckDB ベースの関係データベースへ変換し、要約統計・時間的/空間的/資源的/その他の相関分析プリミティブによって性能変動帰属とストラグラー箇所特定を可能にするエクスポータツール。Mycroft が NCCL ソフトウェアスタックへ直接トレースポイントを追加するのに対し、NIXT は NCCL Inspector という既存プラグイン API の出力を非侵襲的に後段解析する。Nemotron-4 15B/340B(最大 2,048 H100 GPU)の実運用トレースで、ReduceScatter+AllGather が通信量の 99.7% を占め NIC-only 経路が全転送バイトの 70.4% を占めることを定量化し、本番訓練の帯域変動係数(CV)が nccl-tests での孤立再現実験より 2〜5 倍大きいことから ML フレームワークが変動の一因であると報告する。(Source: [[@2026__arXiv__NIXT - A NCCL Inspector Exporter Tool for Observability of Collective Communication in Large Model Training]]) **「Doubling all2all Performance with NVIDIA Collective Communication Library 2.12」([[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]、Karthik Mandakolathur・Sylvain Jeaugey、2022年公開)** は、NCCL 2.12で導入されたPXN(PCI × NVLink)機能を解説するNVIDIA公式ブログ記事。GPUがCPU間プロトコル(QPI等)を経由せずNVLink経由でノード内の別GPUへデータを移し、そのGPUに近いNICから送信できるようにする機能で、(1) 最大8メッセージを1つに集約するmultireceiveによるメッセージレート改善、(2) [[Rail-Optimizedトポロジ]]でのrailを跨がない経路選択によるspineスイッチ通過トラフィック削減、の2つの改善でall2all性能を高める。DGX A100・InfiniBand環境の実測では128ノード/1024GPU構成でレイテンシが約2.55倍改善した(約3980µs→約1560µs)。また、GPU:NIC比が1:1のトポロジやコミュニケータがGPUの部分集合のみを含む場合([0,4]・[1,5]のようなモデル並列分割)でring形成が困難だった問題も解消し、モデル並列の柔軟性を向上させた。(Source: [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) **「GPU-Initiated Networking for NCCL」([[@2025__arXiv__GPU-Initiated Networking for NCCL]])** は NCCL 2.28 の Device API のうち、ネットワーク越し RDMA を担う GPU-Initiated Networking(GIN)を解説する論文。NCCL Device API は LSA(NVLink/PCIe のロード/ストアアクセス)・Multimem(NVLink SHARP マルチキャスト)・GIN(ネットワーク RDMA)の3操作モードを提供し、GIN は GDAKI(DOCA GPUNetIO による直接 GPU-to-NIC 通信、16.7µs 往復レイテンシ)と Proxy(ロックフリー GPU-to-CPU キュー、18.0µs)の二重バックエンドを持つ。[[DeepEP]] への統合により、High-Throughput・Low-Latency 両カーネルで NVSHMEM/IBGDA ベースの既存実装と同等の性能(帯域差1〜3%程度)を達成した。Mycroft・NIXT・eACGM・XPUTimer が NCCL を観測・診断対象として扱うのに対し、本論文は NCCL 自体にデバイス起動通信の新機能を追加する開発者視点の論文である点で異なる。(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]]) **「The Landscape of GPU-Centric Communication」([[@2026__CSUR__The Landscape of GPU-Centric Communication]])** は NCCL を RCCL・oneCCL と並べて Table 3 で7軸(コレクティブプリミティブ・APIモデル・実行エンジン・アクセラレータ統合・イントラノードファブリック・トランスポートバックエンド・進行/開始・トポロジ認識)比較したサーベイ。NCCL の実行エンジンが「GPUカーネル(デバイス自律的)」である点を、RCCL の「GPUカーネル(タイル認識)」・oneCCL の「CPUワーカー+デバイスキュー」と対比し、NCCL のみが完全に GPU 自律的な NVLink/NVSwitch トポロジグラフ構築を自動で行うと特徴づける。NCCL 2.28 のデバイス側 API 導入([[GPU起動型ネットワーキング]]の GIN を含む)を、NVSHMEM を模倣した「計算と通信の融合」への転換点として位置づける。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]]) **「AI Systems Performance Engineering」第4章([[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]])** は、NCCLを実務チューニングの観点から解説する実務書の章。研究論文群(Pulse・NCCLX・Mycroft・Demystifying NCCL等)がNCCL内部の観測・改変を扱うのに対し、本章はNCCLの4大通信アルゴリズム(**Ring**: 帯域最適・O(N)レイテンシで大メッセージ向き、**Tree/NVLSTree**: O(log N)レイテンシで小メッセージ向き、**CollNet**: ノード内集約+ノード間ツリー交換の階層型、**PAT**: Ring/Treeのパイプライン化ハイブリッド)を運用者視点で整理する。加えて実務上の6つの落とし穴(Gloo誤用による2桁性能劣化、コミュニケータ頻繁再初期化による48ms/iterのオーバーヘッド、`NCCL_P2P_DISABLE`等のデバッグ用環境変数の消し忘れ、CPU-GPU NUMAアフィニティ不整合、警告ログの無視、コミュニケータハング)を具体的なコマンド・環境変数とともに提示する。Metaの報告では大規模GPUクラスタの障害の30.1%がGPU故障、17.2%がHBM3メモリ故障であり、これがNCCLコミュニケータハングの高頻度化の背景にあるとする。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]]) **[[CCL-Bench]]([[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]])** は、Perlmutter A100上のvLLM推論(Qwen3-4B・Llama-3.1-8B・DeepSeek-MoE-16B)でNCCLと[[MSCCL++]]をワークロード・ハードウェア・フレームワーク・TP/EP次数を固定してペア比較した。通信比率はMSCCL++が一貫して有利(Qwen3-4B: 49.5%→46.5%、DeepSeek-MoE-16B: 53.7%→46.4%)だが、レイテンシへの効果はワークロード依存(Llama-3.1-8Bでは36.6ms→38.4msへ悪化)であり、通信削減とend-to-endレイテンシ改善が必ずしも一致しないことをトレースベースの一次エビデンスとして定量化した。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) **[[FabricPerf]]([[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]])** は、NCCL自体を計装・改変する上記研究群(Pulse・Mycroft・eACGM・XPUTimer・NIXT・PrismLLM等)とは異なり、NCCLの通信カーネル(送受信コード)をアセンブリレベルでプロービングし、NICが存在しないNvLink等のScale-upネットワークをパケット単位で計測する。GPU内蔵クロックによるGPTPクロック同期と、通信をメモリトラフィックとしてモデル化しCUPTIで解析する二本柱を持つ。H100/GB200 NVL72上でNCCL(v2.28.9、Ring[51]アルゴリズム)のSendRecv/AllGather/ReduceScatterを計測し、①チャネル間のP99レイテンシがP50の約2倍に達する不均衡(work-stealingで46%改善)、②ネットワークバッファのLLCヒット率が16チャネル以上・350GB/s以上で約0%へ崩壊する現象(LLC eviction優先度チューニングで読み取りヒット率34.86ポイント改善)という2つの新規知見を報告した。既存のNCCLベンチマーク(nccl-tests)がカーネル所要時間からアルゴリズム変換でスループットを近似するのみでパケット単位のレイテンシを測れない点を明示的な出発点としている。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) **「アクセラレータ間通信の実際」([[@2024__SpeakerDeck__アクセラレータ間通信の実際]]、PFN、MPLS Japan 2024)** は、H100 クラスタ運用開始後に発生した NCCL の NIC 自動選択偏り問題を実運用視点で報告する。SuperMicro SYS-821GE-TNHR サーバでは NIC 8 枚搭載を前提とした PCIe SW の論理分割機能により、ドキュメント上 4 個の PCIe SW が nvidia-smi 上は 8 個に見え、GPU1/GPU3 から見て NIC0・NIC1 が等距離、GPU5/GPU7 から見て NIC2・NIC3 が等距離という対称的なトポロジになった結果、NCCL は常に NIC0・NIC2 のみを選択しパイプライン並列の性能が出なくなった。SuperMicro 提供のファームウェアで PCIe SW を統合するワークアラウンド(GPU あたり uplink 帯域半減とのトレードオフ)で対処した。NCCL_DEBUG=INFO によるトポロジ検出ログの確認と、nccl-tests の busbw を理論値と比較する運用手順も紹介する。(Source: [[@2024__SpeakerDeck__アクセラレータ間通信の実際]]) **[[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]**(TPDS 2020、PNNL)は、NCCL-V1(PCIe/QPI専用、オープンソース)とNCCL-V2(NVLink/PCIe/NVSwitch/NV-SLI/IB/IP対応、クローズドソース)の違いを起点に、6種のGPUプラットフォームでNCCLリング構成をインターコネクトトポロジごとに実測比較した早期の研究。PCIeでは二分木ネットワークを辿るリング、NVLink-V1では2本の独立リング、NVLink-V2ではbackbone ringによる高速リング+低速リングが構築されることを図示し、この構成の違いがCL帯域のGPU数依存性(PCIeは減少、NVLinkは増加)を生むことを実証した。また5GPU構成でNCCLリングが特定GPU(G0)に負荷集中する構造的ボトルネックを発見した。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] は、AI Toolkit 層の通信障害(Communication Fault)として NCCL Fault・NVLink Fault・MPI Fault の3種を挙げる。NCCL Fault はネットワーク障害またはリモートプロセスの異常終了に起因しうるとされ、NVLink Fault は主に GPU のハードウェア障害(過熱等)に起因するとされる。同サーベイが引用する Hu ら(Kalos)の観測では、Kalos クラスタでの 7B モデル訓練が GPU 過熱をもたらしがちで、これが NVLink Fault を引き起こし、通信コスト最適化が進むほど GPU アイドル率が異常に低くなるにつれてこの現象が増加すると報告される。ただし同サーベイのギャップ分析(表13)では、NCCL Fault・NVLink Fault のいずれも Simulee・CUDAsmith・CLsmith・FastFIT という既存の AI Toolkit 向け FI(fault injection、障害注入)ツールで未対応(Covered: False)であることが示される。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]]) ## 未編纂の観察 - [プラグイン安全性] NCCLbpf([[@2026__arXiv__NCCLbpf - Verified, Composable Policy Execution for GPU Collective Communication]])は、NCCL の tuner/profiler/net プラグインが未検証ネイティブコードとして実行される安全性ギャップに対し、NCCL ソース改変なしに [[bpftime]] のユーザ空間 eBPF ランタイムをプラグイン ABI 内へ組み込む。ロード時検証で null-pointer 逆参照等のクラッシュ要因を防ぎ、型付き map による profiler→tuner のクローズドループ適応と、1.07µs のアトミックホットリロード(ドロップ呼び出しゼロ)を実現する。8x B300 NVLink 上でメッセージサイズ対応ポリシーが AllReduce スループットを NCCL 既定(NVLS)比最大 27% 改善する一方、意図的に劣化させたポリシー(channel 数 1 固定)も verifier を通過してしまい、verifier がポリシーの意味的正しさまでは保証しないことを実証した。Mycroft・eACGM・XPUTimer・NIXT・FabricPerf が NCCL を観測・診断対象として計装するのに対し、NCCLbpf は NCCL の意思決定プラグイン自体を安全に拡張・置換する制御指向のアプローチを取る点で異なる。(Source: [[@2026__arXiv__NCCLbpf - Verified, Composable Policy Execution for GPU Collective Communication]]) - dmaplane 論文の Table 1 能力比較では、NCCL は barrier 同期された collective 通信を対象とし内部にバッファプール・トポロジ検出ロジックを持つが、point-to-point パイプラインの下層に位置するカーネルレベルのバッファライフサイクル・completion 安全性は対象外と位置づけられる（NCCL は per-channel credits を持つが kernel-space の MR 登録・NUMA-aware 配置検証・dma-buf エクスポートは持たない）(Source: [[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]]) ## 関連 - ソース: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] / [[@2024__SpeakerDeck__アクセラレータ間通信の実際]] / [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]] / [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]] / [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] / [[@2025__arXiv__Collective Communication for 100k+ GPUs]] / [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] / [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] / [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] / [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]] / [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]] / [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]] / [[@2026__arXiv__A Few GPUs, A Whole Lotta Scale]] / [[@2026__arXiv__NIXT - A NCCL Inspector Exporter Tool for Observability of Collective Communication in Large Model Training]] / [[@2025__arXiv__GPU-Initiated Networking for NCCL]] / [[@2026__CSUR__The Landscape of GPU-Centric Communication]] / [[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]] / [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]] / [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]] / [[@2023__NSDI__TACCL - Guiding Collective Algorithm Synthesis using Communication Sketches]] / [[@2026__TACO__BridgedRing - A Cost-Effective Hardware-Software Co-Design to Overcome the UPI Bottleneck in GPU Servers]] / [[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]] - 概念: [[LLM分散学習]] / [[並列化戦略]] / [[Mixture-of-Experts]] / [[LLM学習モニタリング]] / [[LLM訓練シミュレーション・エミュレーション]] / [[GPU起動型ネットワーキング]] / [[RDMA]] / [[クリティカルパス分析]] / [[Rail-Optimizedトポロジ]] / [[障害注入]] / [[eBPF]] - エンティティ: [[Pulse]] / [[Megatron-LM]] / [[BlueField-3]] / [[NCCLX]] / [[eACGM]] / [[XPUTimer]] / [[ATLAHS]] / [[DeepEP]] / [[MEGATRACE]] / [[MSCCL++]] / [[CCL-Bench]] / [[FabricPerf]] / [[Neutrino]] / [[Sylvain Jeaugey]] / [[Karthik Mandakolathur]] / [[TACCL]] / [[Yusheng Zheng]] / [[bpftime]] / [[dmaplane]] ## 出典 - [[@2026__arXiv__NCCLbpf - Verified, Composable Policy Execution for GPU Collective Communication]](NCCL の tuner/profiler/net プラグインへ検証済み eBPF ランタイムを組み込む安全性・コンポーザビリティ研究) - [[@2026__TACO__BridgedRing - A Cost-Effective Hardware-Software Co-Design to Overcome the UPI Bottleneck in GPU Servers]](Ring AllReduceがUPI Wallに直面することを実測し、NVLink Bridge+delegated reductionのBridgedRingを比較・互換対象として提案) - [[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]](Table 1 の能力比較表で dmaplane と対比される)