# RDMAネットワーク監視 ## 定義 RDMA ネットワーク監視は、lossless Ethernet 上の RDMA(RoCE)や InfiniBand で構成される AI/HPC クラスタのネットワークを、固有の障害(PFC deadlock/storm、QPC キャッシュ消費、silent drop、RNIC 起因ドロップ、PFC 設定ミス)を含めて検知・箇所特定し、サービス影響を評価する取り組み。[[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] はエンドツーエンドの能動プロービングに基づく初のサービス認識型 RoCE 監視・診断システムで、市販 RNIC の UD QP と CQE タイムスタンプでネットワーク RTT とエンドホスト処理遅延を低オーバーヘッドで測り、RNIC 起因とネットワーク内ドロップを区別し、問題がネットワーク起因かを判定する。TCP プローブ([[papers/2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis|Pingmesh]] 2015)では RoCE 固有問題を検知できない点が出発点。[[テレメトリ]] の一系統で、[[LLM学習モニタリング]] のネットワーク視点と接続する。 ## 横断的知見 - **監視の構え(stance)が「能動プローブ・受動トラフィック・フルスタック計装」の三系統に分かれる**: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] は市販 RNIC からエンドツーエンドにプローブを撃つ能動方式で、ERSPAN/INT(レガシースイッチ非対応)を避け展開容易性を優先する。[[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] は NIC 上で実トラフィックをマイクロ秒粒度に計測する受動・非侵入方式。[[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] はアプリ〜物理の 4 層を計装し sFlow+INT でパス解析するフルスタック方式。同じ RDMA ネットワークでも「外から撃つ/内で測る/全層を計装する」で展開コストと可観測性の取り方が分岐する。(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) - **「サービス障害がネットワーク起因か」を切り分けることが監視の中心価値になる**: R-Pingmesh は NCCL の "error code 12" のようにサービスログがネットワーク問題を装う事例を挙げ、ネットワーク無罪の証明(異常プローブの不在確認)を一次目的に据える(サービス認識)。これは [[Astral]] が層間ログ相関で「計算異常なら物理層、通信異常ならパス重複/INT 遅延」と切り分けるのと同じ問題意識で、大規模 LLM 訓練ではネットワークと end-host の責任分界を素早く付けることがダウンタイム短縮に直結する([[GPUクラスタ運用]])。(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) - **箇所特定はネットワークトモグラフィ的な投票で実装される**: R-Pingmesh は二分ネットワークトモグラフィに着想した投票機構(異常プローブ経路で各リンクの通過回数を数え最多得票を最疑とする)で物理リンク/スイッチを箇所特定し、6 か月・数万 RNIC の本番運用で報告 157 件のスイッチ問題を全件正確に特定した一方、RNIC 問題は CPU 占有由来の偽陽性で精度が落ちる。能動プローブ単独では end-host 起因と network 起因の弁別が誤箇所特定を生むという観察は、[[Fault Localization]] の「単一信号では起因の層を取り違える」課題の RDMA 版。(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **計装位置の三分岐がさらに「スイッチ・データプレーン/集団通信ライブラリ層/物理部品」へ広がる**: [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] は P4 でプログラム可能なスイッチ(Intel Tofino)のデータプレーン内で PFC 因果関係を線速解析し、来歴(プロベナンス)を辿って異常タイプ(backpressure/storm/deadlock)を診断する——計装点がスイッチ ASIC にある。[[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] の C4 は集団通信ライブラリ([[ACCL]])を拡張し、BSP 同期点での各 GPU 到達タイミングのずれと通信遅延行列から異常を検知するホスト・ライブラリ層の計装。[[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] の OptProphet は光トランシーバーの物理メトリクスから故障を予測する物理部品層の計装。既存の R-Pingmesh(市販 RNIC からの能動プローブ)・Pulse(NIC 上の受動マイクロ秒計測)・Astral(全層計装)と並べると、「スイッチ vs NIC/DPU vs ホスト/集団通信ライブラリ vs 物理部品(光モジュール)」のどこを計測点に置くかが RDMA 監視の設計軸として立ち上がる。各手法は計測点に応じて可視化できる異常の層が固定される(Hawkeye は PFC 連鎖、C4 は通信律速、OptProphet は物理劣化)。(Source: [[@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__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **「反応(即時診断)」と「予防(故障前予測)」へ時間軸が分かれる**: Hawkeye は苦情の出たフローから上流の根本原因へ来歴を遡り、性能異常を 90% 以上の精度で即時診断する。C4 は故障検知を数時間から数十秒へ短縮し、エラー誘発ダウンタイムを 31.19% から 1.16% へ削減する——いずれも劣化が顕在化してから素早く切り分ける反応型。対して OptProphet は光トランシーバー故障を平均 1.11 日前に予測してアラームを上げる予防型。同じ RDMA/光ネットワークでも、診断レイテンシを縮める方向(反応)と、故障の前に先回りする方向(予防)に設計が分岐する。([[障害予測]])(Source: [[@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__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **集団通信を律速する根因が物理/リンク層へ降りる**: OptProphet が扱う光トランシーバーの物理故障、Hawkeye が辿る PFC の連鎖的輻輳拡散(lossless を保つための pause が backpressure→storm→deadlock と広がる)、C4P がパス探査で回避するフォルトリンクは、いずれもソフトウェア層でなく物理/リンク層の劣化が[[集合通信]]のスループットを律速する構図。R-Pingmesh の物理リンク/スイッチ箇所特定や Astral の「計算異常なら物理層」という切り分けと合わせ、大規模 LLM 訓練の RDMA 監視では根因の探索が物理層へ降りていく傾向が読み取れる。(Source: [[@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__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **網羅監視と probing 削減のトレードオフ**: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] が RoCE を service-aware に網羅監視するのに対し、[[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]] はトラフィックスケルトン推論で probing を 2 桁削減しつつ precision 98.2% を狙う(両者 Alibaba Cloud 系、underlay の traceroute で R-Pingmesh/007 を踏襲)。(Source: [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **同じデータ源を別目的に使う**: ERSPAN/ROCET のスイッチ層パケットミラーリングは元来ネットワーク障害検知用だが、[[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] はそのフローデータを上位アプリ(訓練ステップ)の意味解釈へ転用する。(Source: [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - **エンドホスト RDMA テレメトリは「ネットワーク無罪/有罪」だけでなく NIC 実装バグの切り分けに効く**: R-Pingmesh はサービス障害がネットワーク起因かを能動プローブで弁別し、Pulse は NIC 上の受動計測で通信の進行を可視化する。[[@2023__NSDI__Empowering Azure Storage with RDMA]] の [[RDMA Estats]] はさらにホスト/NIC/ネットワークの境界にタイムスタンプを置き、sK-RDMA の FMR hidden fence という NIC 実装由来の性能問題を、`T5 - T1` とデータセンター間 RTT の相関から切り分けた。RDMA 監視の設計軸に「サービス影響の判定」だけでなく「NIC マイクロアーキテクチャ挙動の説明」が加わる。(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - **講演資料上の実装課題は、R-Pingmesh を研究論文から運用ツールへ移す段差を示す**: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] は、NCCL エラーが見えても原因がホスト側(GPU ダウン、ハング、メモリ不足、NCCL 設定)かネットワーク側か分からない問題を、R-Pingmesh 型の能動プロービングで補う方針を示す。一方、`yuuki/rpingmesh` のダッシュボード例では、実装上まだ監視できていない RNIC の組み合わせがあると注記される。能動プローブは切り分けに有効だが、サービス単位の RNIC ペア選択、プローブ網羅性、Grafana 上の行列表示まで含めて運用設計が必要になる。(Source: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **集合通信を診断対象にすると「ホスト側の co-flow グラフ視点」が計装位置の五番目の軸として浮上する**: 既存の R-Pingmesh(能動プローブ)・Pulse(NIC 受動計測)・Hawkeye(P4 スイッチ計装)・C4(CCL API 拡張)・VCCL(CCL 内蔵モニタ)はいずれも単一フローまたは単一ノードの指標を対象とする。[[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]](Vedrfolnir)は、集合通信アルゴリズムをステップ単位に分解して**フロー間の待機依存を有向重み付きグラフ(待機グラフ)として明示的に表現**し、ホスト側とネットワーク側を統合した根本原因分析を行う。「計算・通信のどのフローが集合通信全体のクリティカルパスを律速しているか」という問いは、単一フロー監視では答えられず、co-flow 間の依存関係を俯瞰するグラフ視点が必要であることを示している。NS3 評価では [[Hawkeye]] 比 98% のテレメトリ削減を達成し、ステップ認識型の適応検知がオーバーヘッドを大幅に抑制する。(Source: [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **CCL 内蔵 RDMA モニタが計装位置の四番目の軸を開く——外部計装不要の「CCL 自己計装」**: 既存の R-Pingmesh(能動プローブ)・Pulse(NIC 受動計測)・Hawkeye(P4 スイッチ計装)・C4(CCL API 拡張)の四系統は、いずれも何らかの外部計装を必要とする。[[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL)のスライディングウィンドウ型 RDMA モニタは、WR(Work Request)と WC(Work Completion)のタイムスタンプを CCL が直接読み込み、スライディングウィンドウ内の平均スループットを O(μs) 粒度で推定する。「帯域が直近平均の 50% 未満 かつ RtS データ量が過去最大の 2 倍超」という双閾値で NIC ポート異常を検知し、プライマリバックアップ QP 切り替えをトリガーする——可視化と対処が CCL 内で完結する。NIC や P4 スイッチへの外部アクセス権限を必要としないため、クラウドプロバイダ環境やサードパーティ CCL 利用者でも導入できる点が他の系統との差別化になる。(Source: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) ## 未解決の問い - 能動プローブ(R-Pingmesh)・受動トラフィック(Pulse)・フルスタック計装(Astral)を併用したとき、計装オーバーヘッドと箇所特定精度はどう配分するのが最適か。 - IB(InfiniBand)の Adaptive Routing 下では経路が固定されず、経路集約に基づく箇所特定が崩れる。Adaptive Routing でのトモグラフィ的局所化をどう実現するか(R-Pingmesh の将来課題)。 - ネットワーク監視と GPU/コンピュート異常検知(GPU underclocking・OOM・down、[[GPUレジリエンス]])をどう統合し、サービス障害の起因層を一括で絞り込むか。 - RoCE/オープンスタック([[オープンネットワーキング]]、SAKURAONE の SONiC+RoCEv2)の層をまたぐチューニング負荷を、監視・診断はどこまで肩代わりできるか。 - スイッチ・データプレーン側(Hawkeye)・NIC/DPU 側(Pulse)・集団通信ライブラリ層(C4)・物理部品予測(OptProphet)の計測点をどう分業・統合すれば、各手法が固定的に可視化する層(PFC 連鎖・通信律速・物理劣化)を一つの診断パイプラインに束ねられるか。計測点ごとに見える異常が異なる以上、単一の計装では起因層を取り違える R-Pingmesh の課題が層をまたいで再帰しないか。 - PFC 連鎖輻輳の即時診断(Hawkeye)と光トランシーバー故障の事前予測(OptProphet)を結べば、光リンクの物理劣化が PFC backpressure として顕在化する前に、劣化しつつあるリンクを先回りで切り離せるか。反応型診断と予防型予測の接続が fail-slow リンクの早期隔離につながるか。 - 標準的集団通信に従わないワークロードでスケルトン推論の忠実度をどう事前保証するか。([[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]]) - **マイクロバースト可視化にはスイッチごとに収集手段が分岐し、2 秒以下の間隔でも取得精度の課題が残る(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: 400G/800G 混在構成では NOS がスイッチごとに異なるため、テレメトリ収集手段も分岐する。Leaf(QFX5240 / JunOS)は gNMI で最短 2 秒間隔が可能だが、データレートが高いと更新が止まる事象があり、gNMIc プロセスをデータ種別ごとに多重化して対応。Spine(SN4700 / Cumulus Linux)は gNMI が約 15 秒間隔が限界だったが、Cumulus Linux 5.11 以降の OpenTelemetry サポートで約 2 秒間隔・TSDB への直接書き込みが可能になった。それでも「取得間隔の微妙なズレによってレート計算が不安定になるリスク」が残っており、投資判断に使えるインターコネクト稼働状況の正確な可視化はまだ達成していないと報告されている。 - フロー単位の粒度で捉えられない短時間の輻輳・マイクロバーストは性能診断にどの程度の見逃しを生むか。([[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - マルチベンダー混在でスイッチごとに NOS が異なる場合、2 秒以下のマイクロバースト収集に向けた統一収集パイプラインをどう設計するか? gNMIc の多重化・OpenTelemetry 移行のどちらが長期的に維持しやすいか? - RDMA Estats のようなホスト/NIC タイムスタンプ、Hawkeye の PFC プロベナンス、R-Pingmesh の能動プローブを同一インシデントでどう統合すれば、NIC firmware、ホスト内 PCIe 輻輳、物理ネットワーク輻輳を誤らず切り分けられるか。([[@2023__NSDI__Empowering Azure Storage with RDMA]]) - VCCL の CCL 内蔵 RDMA モニタ(WR/WC タイムスタンプ)は NIC ポート単位の障害は捕捉するが、PFC 連鎖輻輳(Hawkeye の対象)や光トランシーバーの物理劣化(OptProphet の対象)は見えない。「CCL が気づかない低速でじわじわ悪化する RDMA 劣化」を検知するには、スイッチや NIC 外部の計装と VCCL モニタをどう組み合わせれば総合的なカバレッジを得られるか。([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - RNIC 組み合わせをどの粒度で継続プローブすれば、サービス影響のある RoCE 問題を網羅しつつ、プローブ負荷と可視化コストを抑えられるか。講演資料の `yuuki/rpingmesh` ダッシュボード例は、実装上まだ監視できていない組み合わせがあることを示す。([[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]]) - Vedrfolnir の待機グラフと Hawkeye の PFC プロベナンスグラフは、それぞれ「ホスト側の co-flow 依存」と「ネットワーク側の PFC 連鎖」を独立したグラフとして構築し後から統合するアーキテクチャを採る。両グラフを共通の依存フレームワークで統一表現する場合、どの抽象化が両者の強みを損なわずに統合できるか。([[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]]) - Vedrfolnir は Ring・Halving and Doubling のステップ分解のみを例示するが、AllToAll・ReduceScatter・TreeAllReduce など他のアルゴリズムへの汎化では待機グラフの複雑度はどう変わるか。MoE の動的なエキスパート選択パターンを持つ AllToAllv では、ステップ定義が実行時に変化するため事前分解が困難になるが、どう対処するか。([[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]]) ## 関連 - ソース: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] / [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] / [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] / [[@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__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] / [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]] / [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] / [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] / [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] / [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]] / [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]] - 概念: [[テレメトリ]](能動/受動の計装) / [[オープンネットワーキング]](RoCE/Ethernet) / [[LLM学習モニタリング]](ネットワーク視点) / [[Fault Localization]] / [[GPUクラスタ運用]] / [[障害予測]](OptProphet の予防型) - エンティティ: [[R-Pingmesh]] / [[Astral]] / [[Pulse]] / [[Kefei Liu]] / [[Jiao Zhang]] / [[BUPT]] / [[Douyin Vision]] / [[NCCL]] - 関連 MOC: [[HPC - MOC]] / [[分散深層学習 - MOC]] ## 出典 - [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]](§4 設計, §6 評価, §7.1 問題分類 + 表2) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](§3 フルスタック監視・階層相関) - [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](§4 NIC Agent 計測) - [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]](§提案手法 データプレーン内 PFC 因果関係解析・異種 wait-for プロベナンスグラフ、§実験結果 精度 90%+/オーバーヘッド 1-4 桁減) - [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]](C4D=ACCL 拡張・BSP 同期点・通信遅延行列、C4P=RDMA 動的負荷分散・パス探査によるフォルトリンク回避) - [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](Abstract:光トランシーバー故障の予測+分類、F1 0.884、平均 1.11 日前アラーム) - [[@2023__NSDI__Empowering Azure Storage with RDMA]](§5 RDMA Estats、§8.3 FMR hidden fence / PFC and MACsec / congestion leaking / loopback RDMA) - [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL スライディングウィンドウ型 RDMA モニタ: WR/WC タイムスタンプ集積・O(μs) スループット推定・双閾値(帯域 < 50% かつ RtS データ > 2×)・外部計装不要・CCL 内で対処まで完結)