# 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学習モニタリング]] のネットワーク視点と接続する。 ## 子概念 - [[ECMP]] - [[MRC]] - [[SRv6]] - [[オープンネットワーキング]] - [[ホスト内ネットワークボトルネック]] - [[不均衡障害分類]] ## 横断的知見 - **アプリケーション起点の性能目標とネットワーク起点の監視を接続するには、平均帯域でなく計算・通信の重なりを観測する必要がある**: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]は、データ並列の逆伝搬時間が通信時間を上回れば通信が隠れ、通信が上回ればGPU idle時間が増えることを示す。[[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]がCPU・GPU・Root Complex・RNICのコンポーネント別帯域を可視化するのに対し、本資料は逆伝搬、Bucket、Chunk、AllReduceというアプリケーション側の単位をネットワーク目標へ接続する。RDMA監視では帯域低下の検知だけでなく、どの計算時間を超えたため学習性能へ露出したのかを対応づける必要がある。(Source: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]], [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) - **マイクロバースト可視化の要求は、アプリケーションの通信分割粒度から生じる**: 本資料は全データがBucket、Chunk、MTUへ分割されて送信され、`perf-tests`と`nccl-tests`が異なる粒度のMessage Sizeを測ると整理する。[[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]がマルチベンダー環境で2秒級の取得間隔でも精度課題を示すのと合わせると、分散学習のバーストを捉える監視は、スイッチの平均レートだけでなくフレームワークのBucket/CCLのChunkに対応する時間粒度を必要とする。(Source: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]], [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) - **監視の構え(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]]) - **NIC 側光モジュールは、計装点 4 層のどこにも救われない「最後の物理単一障害点」であり、これが予防型検知(OptProphet)の必要性を非対称に高める**: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] は、T0 スイッチ側の光トランシーバがグリッチして 4 リンクを連続フラップさせても [[MRC]](トランスポート層のパケットスプレー・選択的再送信)が自動的に ride out し、50K GPU 本番ジョブはクラッシュせずスループット約 25% 低下が 1 分間続いた後に全速回復したと報告する。ところが**同じ光モジュール障害でも NIC 側(800Gb/s 光学を 4x200Gb/s に分割する構成)でトランシーバ自体がフラップすると、NIC の全ポートを同時に失い QP が失敗するため MRC でも ride out できない**、という非対称性を明記する。既存の計装点 4 層(スイッチ ASIC=Hawkeye、NIC/DPU=Pulse、集団通信ライブラリ=C4、物理部品=OptProphet)のうち、OptProphet の光トランシーバー故障予測(平均 1.11 日前アラーム)は「T0 スイッチ側ならトランスポート層の耐性で吸収できるので予防の価値が相対的に低い」障害と「NIC 側なら耐性で吸収できず唯一の防衛線になる」障害の両方を無差別に対象としている。MRC の知見は、予防型予測の投資を NIC 側光モジュールへ優先配分すべきだという設計上の示唆を、トランスポート層の耐性データという独立ソースから与える。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **SRv6 の静的経路は、能動プロービング系統(R-Pingmesh)に「経路の曖昧性ゼロ・データプレーン内高頻度化」という新しい実装選択肢を加える**: R-Pingmesh は市販 RNIC からエンドツーエンドにプローブを撃つ能動方式だが、ECMP ハッシュを使う従来ネットワークでは特定プローブがどの物理経路を通るか厳密には分からない。[[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] の Clustermapper は、静的 [[SRv6]] 経路のおかげでプローブパケットが通る経路を正確に把握しつつ、ICMP のようにコントロールプレーンでレート制限されずデータプレーン内で他のトラフィックと同様に処理されるため、ミリ秒単位の高頻度プロービングを継続できると報告する。R-Pingmesh の「二分ネットワークトモグラフィ的投票による箇所特定」は経路の不確実性を統計的に均して精度を出す設計だが、SRv6 環境では経路が確定的であるため理論上この統計処理自体が不要になりうる——ルーティング方式(ECMP か静的ソースルーティングか)が能動プロービングの設計そのものを規定するという新しい軸が浮かぶ。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **集団通信を律速する根因が物理/リンク層へ降りる**: 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]]) - **binary network tomography 的な投票による箇所特定は、ホスト内(Hostping)とネットワーク内(R-Pingmesh)の双方で独立に再発明されている**: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]](Hostping拡張版)は RNIC-エンドポイント間パスの正常/異常観測からリンク単位の状態を逆算する Algorithm 1 を、[[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] は異常プローブ経路上の各リンクの通過回数を数えて最多得票リンクを箇所特定する投票機構を、それぞれ独立に binary network tomography から導出している。両者とも「単一の観測(パス単位の正常/異常)からより細かい粒度(リンク単位)の状態を逆算する」という同型の統計的推論を、対象領域(ホスト内 PCIe/メモリチャネル/UPI vs. ネットワーク内スイッチ/リンク)が異なるだけで別々に実装している点は、箇所特定アルゴリズムが計装位置に依存しない汎用的な設計パターンであることを示唆する。加えて Hostping 拡張版は R2R(RNIC-to-RNIC)probing という、R-Pingmesh のプローブ機構と機能的に類似する RNIC 間相互プロービングを新たに導入しており、両システムは「ホスト内診断ツール」と「ネットワーク監視ツール」という出自でありながら、接続性検証の実装が収斂しつつある。(Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]], [[@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]]) - **輻輳を主眼とする RDMA 監視系(Hawkeye・C4・R-Pingmesh)は、破損(corruption)という質的に異なる障害クラスを暗黙に見落とす**: [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]](CorrOpt)は 15 本番 DCN・35 万リンクの計測で、パケット破損による損失が輻輳による損失と同水準の規模を持つにもかかわらず、破損損失率は**利用率と相関せず(平均ピアソン相関 0.19)、時間的に安定**していることを示した。これは Hawkeye の PFC 連鎖解析や C4 の通信律速検知など、いずれも輻輳・バックプレッシャーを前提にした監視系(送信レート低下や経路変更で緩和できるという想定)が、破損には原理的に効かないことを意味する。破損はリンクを物理的に無効化して技術者が修理するしかなく、ソフトウェア的な反応では解決しない。RDMA 監視の設計は「輻輳系(反応可能)」と「破損系(無効化と物理修理が必須)」で対処の性質そのものが分岐するという軸を、CorrOpt は輻輳とのペア計測で定量的に裏付けた最初の研究である。(Source: [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]], [[@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]]) - **光層の根本原因診断は RxPower/TxPower のパターンマッチングという共通言語を持つ**: CorrOpt は「送受信の光パワー水準(H/L)の組み合わせ」からコネクタ汚染・ケーブル損傷・送信機劣化・トランシーバ不良・共有コンポーネント故障の 5 種を判別する診断表(Table 2)を確立した。[[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](OptProphet)の光トランシーバー故障予測も同様に光層の物理メトリクスを入力とする。両者は「反応型(検知してから無効化・修理)」対「予防型(故障の 1 日以上前に予測)」という時間軸の違いはあるが、光層の物理指標(RxPower/TxPower、あるいは pre-FEC BER)を根本原因の手がかりとする点で系譜を共有する。CorrOpt はこの系譜の起点にあたる 2017 年の研究である。(Source: [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **監視の時間軸に「デプロイ前の事前探索」という第四の系統が加わる**: これまでの横断的知見は「能動プローブ・受動トラフィック・フルスタック計装」という本番稼働中の監視三系統([[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] 等)を扱ってきたが、[[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]](Collie)はデプロイ前にハードウェアの弱点を能動的に探索する第四の時間軸を提示する。Collie は性能カウンタ・診断カウンタを焼きなまし法で極値領域へ駆動し、本番投入前に PFC pause frame ストームや低スループットを引き起こす条件(minimal feature set)を特定する。R-Pingmesh・Hawkeye・C4・OptProphet がいずれも「稼働中に起きた/起きつつある異常を検知・診断する」のに対し、Collie は「まだ起きていない異常を人工的に誘発して発見する」という質的に異なるアプローチであり、RDMA サブシステムのライフサイクル全体では「Collie(デプロイ前探索)→ R-Pingmesh/Hawkeye/C4(稼働中診断)→ OptProphet(劣化予測)」という時系列が成立する。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **Collie が発見する異常の根本原因は、監視系が計装する「スイッチ・NIC/DPU・集団通信ライブラリ・物理部品」の 4 層のうち、主に NIC/DPU 層(ホスト-RNIC間)に集中する**: Collie が報告する 18 件の異常の根本原因(Appendix A)は RNIC 内部キャッシュミス・PCIe backpressure・クロスソケット通信といった、RNIC とホストハードウェアの相互作用に起因する。これは [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] が NIC 上で実トラフィックを受動計測する計装位置と同じ層だが、Collie は受動計測ではなく能動的にワークロードを生成してこの層のボトルネックを人工的に誘発する点で異なる。「NIC/DPU 層の異常はデプロイ前に人工的に誘発して発見できるが、スイッチ層の PFC 連鎖(Hawkeye)や物理層の光劣化(OptProphet)は本番トラフィックがなければ顕在化しにくい」という、層ごとの事前検証可能性の違いを示唆する。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - **診断対象がネットワークからホスト**内**部へ降りる第五の層が加わる**: 既存の監視系(R-Pingmesh・Pulse・Hawkeye・C4・Collie)はいずれも RNIC とネットワーク(スイッチ・ケーブル)、または RNIC とホストの境界を対象とするのに対し、[[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]](Hostping)は RNIC よりさらに内側、RNIC-エンドポイント(GPU・メモリノード)間の PCIe リンク・PCIe スイッチ・メモリチャネル・CPU ソケット間バス(UPI)を診断対象とする。RNIC 線速の急増(25Gb/s→200Gb/s)に PCIe 帯域の伸びが追いつかないため、ホスト内部が新たなボトルネック源になりつつあるという背景は、Hawkeye・C4 が主眼とするネットワーク輻輳、OptProphet が扱う光層劣化のいずれとも異なる第五の層を切り拓く。([[ホスト内ネットワークボトルネック]])(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - **ホスト内診断も binary network tomography に基づく投票機構を継承する**: R-Pingmesh の箇所特定(二分ネットワークトモグラフィに着想した投票機構でスイッチ・物理リンクを特定)と同じ着想を、Hostping はホスト内トポロジ(RNIC-エンドポイント間のパス)に適用する。ネットワークレベルの箇所特定手法(パス単位の観測からリンク単位の状態を逆算)が、対象をスイッチファブリックからホスト内部のPCIe/メモリチャネルへ置き換えても同じ数理的枠組みで機能することを示しており、「計装位置ごとに固定される可視化層」という既存の観察に、ホスト内層でも通用する共通の推論アルゴリズムがあるという新しい軸を加える。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **誤設定(ACS/ATS)はハードウェア障害と見分けがつかない症状を生む、ホスト側特有の根本原因である**: Hawkeye・C4・R-Pingmesh が扱う根本原因はいずれもネットワーク輻輳・PFC連鎖・光劣化という物理/輻輳系だが、Hostping は ACS(Access Control Service)の意図しない有効化や ATS(Address Translation Service)の無効化という PCIe 設定ミスが、リンク障害と同水準の帯域劣化・レイテンシ増加を引き起こす事例を報告する。ホスト内層の根本原因は物理故障だけでなく設定層にも及ぶため、Hostping の診断は「リンク障害 vs 設定ミス」を切り分ける段階を持つ(GPU 側レイテンシが異常なら誤設定、そうでなければリンク障害と推定)。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - **既存監視系がPFC連鎖の「異常検知」に注力する一方、PFC一時停止カウンタそのものが分単位の粗粒度でもバースト検知の一次シグナルとして機能しうる**: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] は、Meta の本番RDMA AIデータセンターで分単位のPFC一時停止カウンタ(`switchos`)とミリ秒級ホストサンプリング(`finecounters`)を突き合わせ、同一リンクでPFC一時停止頻度がスパイン間で2桁の差を示す一方、分単位平均トラフィックレートは12%差に収まることを発見した。[[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] はP4スイッチのデータプレーン内でPFC連鎖(backpressure/storm/deadlock)を線速解析する高コストな計装を要するのに対し、本論文は「PFC一時停止カウントという既に大半のRDMAネットワークに展開済みの分単位カウンタ自体が、平均トラフィックレートでは見えないバースト性・負荷不均衡の代理指標になる」ことを示した。既存の計装点4層(スイッチASIC=Hawkeye、NIC/DPU=Pulse、集団通信ライブラリ=C4、物理部品=OptProphet)のいずれとも異なり、「新規計装を追加せず、既存の粗粒度カウンタの読み方を変えるだけで得られる可視化」という第六の軸を加える。(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **観測される輻輳の空間分布そのものがPFC展開の副作用として変化しており、監視系の計装点設計はこの変化を前提にすべきである**: 同論文は、PFC導入によりRDMAデータセンターの輻輳箇所がTCP/IPデータセンターのエッジ(ToR→host)からネットワークコア(ToR→spine)へシフトしたことを実測で示した。これは、Hawkeyeがスイッチデータプレーンを計装点に選ぶ設計判断や、R-Pingmeshがトモグラフィ的投票でスイッチ・リンクを箇所特定する設計判断が、「RDMAネットワークではコアが最も輻輳しやすい」という本論文の実測知見と整合することを裏付ける一次資料である。既存の監視系の設計が経験則的に妥当だったことを、独立した測定研究が定量的に補強する関係にある。(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **Collie/Huskyの「デプロイ前の事前探索」に、Luminaは「決定論的イベント注入による仕様準拠性検証」という別軸を加える**: Collie([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])はfirst-party trafficを焼きなまし法で駆動し性能異常(MFS)を探索するのに対し、[[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]](Lumina)はプログラマブルスイッチによるin-network決定論的イベント注入(パケットドロップ・ECN・破損)でRNICに正確な障害シナリオを与え、再送ロジック・輻輳通知・カウンタが**IB仕様どおりに動くか**を検証する。Collieの発見は「なぜ遅いか」(性能)、Luminaの発見は「仕様どおりに動いているか」(正しさ)という異なる問いに答える。両者ともデプロイ後の商用RNIC(NVIDIA・Intel)を対象とし、ベンダーに直接バグを報告・確認させている点は共通する。R-Pingmesh・Hawkeye・C4・OptProphetのような本番稼働中監視(反応/予防)、Collieのようなデプロイ前性能探索に続く「デプロイ後・仕様準拠性検証」という第五の時間軸・目的軸として位置づけられる。(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]], [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - **Luminaが発見する「noisy neighbor」現象は、Hawkeyeが扱うPFC連鎖輻輳と同じ「無関係なフローへの波及」という現象クラスに属するが、原因の層が異なる**: LuminaはCX4 Lxで、一部のReadコネクションに注入したパケットドロップが、ドロップに関与しない無関係な(innocentな)コネクションのタイムアウト・大幅なMCT悪化を引き起こす「noisy neighbor」問題を発見した(`rx_discards_phy`カウンタの急増から、RNICパイプライン全体のストールが示唆される)。これは[[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]が扱うPFC連鎖(backpressure→storm→deadlockと無関係フローへ拡散する)と現象として類似するが、Luminaのnoisy neighborはNIC内部のマイクロアーキテクチャ資源共有(RNIC pipeline stall)に起因し、Hawkeyeが扱うPFCはスイッチ・リンクレベルの輻輳制御機構に起因する点で原因の層が異なる。「無関係フローへの波及」という現象は、スイッチ層(PFC)とNIC層(パイプライン共有)の両方で生じうるという知見を加える。(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **各研究が言及するカウンタ名は、mlx5 ドライバの公式仕様に対応する一次情報を持つ**: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]] は CX4 Lx の noisy neighbor 現象を `rx_discards_phy` カウンタの急増から示唆したが、この名前がどの計測点(物理ポート)・どの種別(Error)に属するかは論文自体には明記されない。[[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]](kernel.org 公式仕様)は `rx_discards_phy` を「物理ポートでのバッファ不足によるドロップ、増加はアダプタ側の輻輳を示唆」と定義し、[[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]](CorrOpt)が根本原因診断に使う RxPower/TxPower 水準も同ドキュメントの `rx_pcs_symbol_err_phy`・`rx_corrected_bits_phy`・`rx_err_lane_[l]_phy` という FEC/BER 系カウンタ群と同じ物理層診断語彙に属する。個別の RDMA 監視研究がアドホックに言及するカウンタ名は、ベンダーが公開する統一仕様(Ring/Netdev・vPort・Physical Port・Priority Port・Device の 5 計測点、Informative/Acceleration/Error の 3 種別)の部分集合として位置づけ直せる。(Source: [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]], [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]], [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]]) - **計装点4層+ホスト内層(Hostping)+粗粒度カウンタ層(IMC)に、「カーネルverbs/ドライバ層への戻り値ゲート型eBPF計装」という第七の軸が加わり、対象が「ネットワーク性能異常」から「カーネルバグによるジョブ失敗」へ移る**: これまでの計装点(スイッチASIC=Hawkeye、NIC/DPU受動=Pulse、CCL API拡張=C4、CCL内蔵=VCCL、物理部品=OptProphet、ホスト内PCIe=Hostping)はいずれもネットワーク性能異常・輻輳・劣化を診断対象とする。[[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](RDMATracer)は、[[Meta]]のAI訓練ジョブ失敗の5〜20%を占める**NICドライバのカーネルバグ**を診断対象とし、カーネルのkernel-verbs層・ドライバ層に`fentry`/`fexit`を配置してsyscallの戻り値が非ゼロのときのみキャプチャする。既存監視系がいずれも「性能がどれだけ劣化したか」を測るのに対し、RDMATracerは「syscallが失敗したかどうか」という二値のイベントを対象とし、対象が性能異常からソフトウェアバグ/正しさの問題へ移る点で既存7系統のいずれとも異なる。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - **既存監視系の「不可視性」は主にネットワーク・ハードウェアの不透明性に起因するが、RDMATracerが扱う不可視性はソフトウェアスタックの構造(薄いverbsラッパー+リトライロジック欠如)に起因する**: Hawkeye・Pulse・C4・OptProphet・Hostpingが扱う不可視性は、いずれもRNIC・スイッチ・光モジュールという**ハードウェア**の内部状態が外部から見えないことに起因する。RDMATracerが報告する不可視性(12か月の観測ウィンドウでsyscall失敗試行の96%が他レイヤー信号を伴わない)は、`rdma-core`バンドルの`libibverbs`がカーネルのioctlへの薄いラッパーでリトライロジックを持たず、カーネルエラーが即座にユーザ空間(NCCL)へ伝播してcommunicator破棄・アプリケーションクラッシュに直結するという**ソフトウェアスタックの構造**に起因する。既存の誤帰属問題(既存分類器ALPSがsyscall失敗の25%を"Network Event"と誤分類)も、この構造的な不可視性が生む症状の一つである。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - **選択的計装サーフェスの縮小率(約6桁のオーバーヘッド削減)は、既存監視系のオーバーヘッド削減アプローチ(トラフィックスケルトン推論・CCL内蔵モニタ等)と同じ「計装点を絞る」設計判断を、カーネル関数の名前空間ゲート+ヒューリスティックという別の軸で実現する**: [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]]がトラフィックスケルトン推論でprobingを2桁削減するのと同様に、RDMATracerは4つの操作者由来ヒューリスティック(読み取り専用除外・汎用カーネル内部処理除外・クリーンアップパス除外・重要オブジェクト操作へ焦点化)で約2,000個のRDMA関数を13個へ絞り込み、全RDMA関数追跡比で約2,000倍(0.0000024%/約5% CPU)のオーバーヘッド削減を達成する。両者は「網羅性とオーバーヘッドのトレードオフ」という同じ設計軸に立つが、RDMATracerのヒューリスティックは機械的に符号化可能で他ベンダーの名前空間へ移植できる点(recall=1.000, F1=0.765の正解データ検証済み)が特徴的である。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]], [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]]) - **計装点4層+ホスト内層+粗粒度カウンタ層+eBPF層の議論はいずれも「異常検知・診断の自動化」を目的とするが、ICLensは自動検知を持たず「人間がコンポーネント別グラフを目視比較して切り分ける」運用可視化に徹する、質的に異なる第八の軸を示す**: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]](ICLens)は、GPU-to-GPU通信路上のCPU・GPU・Root Complex・RNICという4コンポーネントの帯域をTX/RX方向別に単一ダッシュボードへ並置するだけで、異常検知アルゴリズムや閾値判定を持たない。TCP誤用ケース(RNIC不活性+CPU負荷増)とGPUDirect RDMA誤設定ケース(RNIC活性+CPU PCIe/Memory負荷増)は、RNICメトリクス単体では区別できないが、著者らはこれをアルゴリズムではなく「グラフを並べて見比べる」ことで切り分けると論文中で明記する。Hawkeye(P4データプレーン内自動解析)・C4(閾値ベース自動検知)・R-Pingmesh(トモグラフィ的投票による自動箇所特定)・VCCL(双閾値による自動NICポート異常検知)がいずれも人間の介在を最小化する方向に設計されているのに対し、ICLensは逆に「人間の目による比較」を一次インターフェースに据える。これは自動化の巧拙ではなく、複数ベンダー(NVIDIA・Intel)にまたがる異種メトリクスをまず単一の可視化平面(Prometheus + Grafanaライクなダッシュボード)に統合すること自体が価値を持つという、監視パイプラインの前段(計装・統合)と後段(自動診断)を切り分ける視点を加える。(Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]], [[@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]]) - **ICLensのRNIC Exporterは`/sysfs`経由のRDMAトラフィックカウンタをポーリングする点で、mlx5 ethtoolカウンタ仕様と同じ計測レイヤーに属するが、標準Linuxカーネルインターフェースカウンタ(`/proc/net/dev`)ではRDMAトラフィックが不可視になるという実務上の制約を明記する**: [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]]は5計測点(Ring/Netdev・vPort・Physical Port・Priority Port・Device)を整理するが、ICLensの実装記述は「RDMAトラフィックはRNICハードウェアにオフロードされるため`/proc/net/dev`のような標準カーネルインターフェースカウンタには現れず、`/sysfs`(例: `/sys/class/infiniband/mlx5_1/ports/1/counters/port_rcv_data`)から取得する必要がある」という、実装者が直面する具体的な落とし穴を一次情報として提供する。既存のRDMA監視系(R-Pingmesh・Hawkeye等)がこの計測レイヤーの選択を前提として設計を進めるのに対し、ICLensはなぜその前提が必要か(標準インターフェースの不可視性)を明示的に述べている点で、計装レイヤー選択の理由づけを補強する。(Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]], [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]]) - **既存監視系がいずれも「異常をどう検知・可視化するか」を扱う一方、RTFDは「検知後の分類・局所化をどう自動化するか」という下流工程を対象とし、計装位置の軸とは独立な「診断の自動化」という軸を加える**: R-Pingmesh(能動プローブ)・Hawkeye(P4スイッチ計装)・Pulse(NIC受動計測)・C4(CCL拡張)はいずれも異常の検知・可視化までを担い、根本原因の分類や障害箇所の細粒度局所化には人手分析を要すると各研究自身が明記する。[[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]](RTFD)は、R-Pingmesh が出力するホスト側の遅延・帯域・パケットロス時系列をLSTM分類器にかけ、事前学習+SFTの二段階でまれな障害を少数ショット分類し、異常パスから障害セグメントへ消去法で局所化する。これは既存の計装点4層(スイッチASIC・NIC/DPU・CCL・物理部品)がいずれも「どこで測るか」を軸とするのに対し、「測定済みデータをどう自動分類・局所化するか」という直交する軸を提示する——RTFDはR-Pingmeshの後段に接続する後処理レイヤーとして位置づけられる。(Source: [[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **能動プローブ(R-Pingmesh)に対し、FlowTracer は「実運用トラフィックの受動ホップバイホップ追跡」という第九の計装軸で ECMP パス不均衡を可視化する**: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] は市販 RNIC からエンドツーエンドに合成プローブを撃つ能動方式でサービス障害のネットワーク起因/非起因を切り分けるのに対し、[[@2024__arXiv__FlowTracer - A Tool for Uncovering Network Path Usage Imbalance in AI Training Clusters]] は逆に合成トラフィックを注入せず、ワークロードが生成する実際の RoCE/TCP フローを SSH 経由でホップごとに受動追跡し、新指標 Flow Imbalance Metric(FIM)でリンク単位のフロー分布不均衡を定量化する。両者とも「単一の観測から経路・リンク単位の状態を逆算する」という点で計装位置は異なるが目的は重なり、FlowTracer 自身も related work で R-Pingmesh・RD-Probe を「合成トラフィックを注入する能動プロービングツール」として明示的に対比している。既存の計装点(スイッチ ASIC・NIC/DPU・CCL・物理部品・ホスト内・粗粒度カウンタ・eBPF・運用可視化)のいずれとも異なり、「診断対象が異常の検知・分類ではなく、正常時も含めたルーティング設定間のフロー分布比較(ECMP vs 静的ルーティング)」という評価志向の目的を持つ点が特徴的である。(Source: [[@2024__arXiv__FlowTracer - A Tool for Uncovering Network Path Usage Imbalance in AI Training Clusters]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **RDMAトランスポート障害の少数ショット・データ不均衡問題は、マイクロサービス障害分類の「二重の不均衡」問題とは異なる解法(事前学習+SFTによる転移学習)で取り組まれている**: [[不均衡障害分類]]で扱うSLIM(マイクロサービス障害箇所特定)は、変更後サービスの障害サンプルが1〜2件しかない状況でSMOTEのような再サンプリングがほぼ無効であることを示し、F1直接最適化というアルゴリズム設計レベルの対処を採る。RTFDは同じ「まれな障害・データ不均衡」問題に対し、標準環境で汎用障害パターンを事前学習し、対象DCNへの展開時に信頼度ベースの疑似ラベリングでSFTするという転移学習的アプローチを採る。両者とも「再サンプリングでは足りない」という診断は共通するが、SLIMが単一ドメイン内での学習目標の再設計で対処するのに対し、RTFDはドメイン間(標準環境→対象DCN)の知識転移で対処する点で解法の系統が異なる。RDMAトランスポート障害とマイクロサービス障害という異なる階層の障害分類が、同じ「レアイベントの少数ショット学習」という問題構造を共有しながら異なる解法系統に分岐している。(Source: [[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]], [[@2024__ASE__SLIM - A scalable and interpretable light-weight fault localization algorithm for imbalanced data in microservice]]) ## 未解決の問い - アプリケーションの計算時間・Bucket/Chunk分割・AllReduceの通信量を、スイッチやNICのマイクロバースト可視化へどの粒度で対応づければ、平均帯域では隠れる一時的な輻輳をGPU idle時間や学習Step時間へ因果的に結びつけられるか。([[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]) - RTFDのSFTが用いる信頼度閾値$\tau_{high}/\tau_{low}$の具体的な値や、中間信頼度サンプルの扱いは論文中に明示されない。この閾値設計が異なるDCNトポロジ間でどこまで転移可能か、また閾値の選び方がcross-topology汎化性能(weighted precision/recall/F1の最小値0.84〜0.89台)にどう影響するかは未検証。([[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]]) - RTFDはSimAI上のシミュレーションのみで評価されており、著者ら自身が実データセンターでの展開・検証を今後の課題として挙げる。R-Pingmeshの実運用データ(6か月・数万RNIC)にRTFDのLSTM分類器を適用した場合、シミュレーション評価で報告された精度(平均0.92前後)は維持されるか。([[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - Collie・Luminaのようなデプロイ前後の能動探索(性能異常探索・仕様準拠性検証)で発見された既知の異常パターン(MFS、CX4 LxのNoisy neighbor等)を、本番監視系(R-Pingmesh・Hawkeye)の異常検知ルールへ事前知識として組み込むことは可能か。特にLuminaのnoisy neighbor問題(`rx_discards_phy`カウンタの急増)のようなNIC内部由来のシグナルを、本番運用中にリアルタイムで検知するにはどのような計装が必要か。([[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]]) - [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] はPFC一時停止カウンタが粗粒度でもバースト検知に有効であることを示したが、実際の異常検知・診断システム(Hawkeye・R-Pingmesh・C4)への組み込みは検証していない。PFC一時停止カウンタの不均衡度(スパイン間の2桁差のようなシグナル)を既存の監視パイプラインへリアルタイムに統合すれば、Hawkeyeのようなスイッチデータプレーン計装なしでバースト性負荷不均衡を検知できるか。 - 同論文はポート単位の分単位カウンタとホスト側4.8msサンプリングを紐付けられないという限界を明記する。RDMA EstatsやHawkeyeのPFCプロベナンスのような、より細粒度のホスト-ネットワーク対応づけ手法と組み合わせれば、この限界は解消できるか。 - 能動プローブ(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]]) - ICLensの「人間目視によるコンポーネント別グラフ比較」という運用可視化アプローチに、Hawkeye・C4・R-Pingmeshのような自動異常検知ロジックを重ねれば、TCP誤用・GPUDirect RDMA誤設定のような「RNIC単体では区別できないが人間には一目瞭然」なパターンを、閾値やルールベースでどこまで自動判別できるか。ICLensが示す3ケースの診断パターン(RNIC不活性+CPU負荷増/RNIC活性+CPU PCIe・Memory負荷増/CPU側無負荷でRNIC帯域のみ低下)を教師データとして使えるか。([[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) - Vedrfolnir は Ring・Halving and Doubling のステップ分解のみを例示するが、AllToAll・ReduceScatter・TreeAllReduce など他のアルゴリズムへの汎化では待機グラフの複雑度はどう変わるか。MoE の動的なエキスパート選択パターンを持つ AllToAllv では、ステップ定義が実行時に変化するため事前分解が困難になるが、どう対処するか。([[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]]) - MRC が T0 側の光トランシーバ障害を吸収してしまうと、その障害は訓練ジョブから見えなくなる。**耐性機構が物理劣化を隠す**この構図の下で、劣化しつつあるリンクを別系統(モジュール自身の CMIS VDM が公開する pre-FEC BER・eSNR、あるいは `ethtool -I --show-fec` の訂正ブロック数)からどう拾い上げるか。[[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] の「冗長性が性能問題を隠す」と同じ問題が、トランスポート層の耐性でも再現する。([[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) - NIC 側光モジュールのフラップが唯一 ride out できない障害だとすると、NIC 側の光設計(ポート分割の粒度を下げる、短距離区間を AEC/DAC へ置き換える)でどこまで緩和できるか。[[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] は短距離区間での AEC 採用をコスト・信頼性の両面から推すが、NIC 側単一障害点の緩和効果として定量化した資料は見当たらない。([[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) - 光障害への対処は「検知して直す」(OptProphet・[[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks|CorrOpt]] 系)と「トポロジで迂回する」([[光回線交換]]・MRC)に分岐する。[[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]] は OCS による再構成でホスト可用性要件を 99.9% から 99% へ緩和したと報告するが、迂回機構を持つ設計では個別光モジュールの監視精度への要求はどこまで下げてよいか。逆に、迂回に頼りすぎると劣化の蓄積を見逃さないか。([[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - Collie がデプロイ前に発見した性能異常(MFS)の情報を、本番監視系(R-Pingmesh・Hawkeye 等)の異常検知ルールへ事前知識として組み込むことは可能か。既知の MFS に一致するトラフィックパターンを本番監視側で優先的にウォッチすれば、反応型診断のレイテンシをさらに縮められるか。([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - Collie の探索空間はネットワーク内輻輳(パケットロス・複数ホップ)を含まない単純化された環境(2 台のサーバ + 単一スイッチ)を前提とする。Hawkeye が扱う PFC 連鎖輻輳のような複数ホップにまたがる異常も、同様の焼きなまし法ベースの事前探索で発見できるよう拡張可能か。([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - mlx5 ethtool カウンタ仕様([[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]])は Mellanox/NVIDIA ConnectX 向けの一次資料だが、他ベンダー(Intel E810 等)の RNIC カウンタ体系との対応関係は未整理。[[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]] が報告する CX5-E810 間の相互運用性問題の一部は、両ベンダーのカウンタ意味論の食い違いに起因していないか。ベンダー横断でカウンタ名・意味を対応づけるマッピング表を作れば、マルチベンダー環境での根本原因診断を標準化できるか。 - RDMATracerのkernel-verbs/ドライバ層計装(ソフトウェアバグ診断)と、既存監視系4層+ホスト内層+粗粒度カウンタ層(いずれもネットワーク性能異常診断)を単一の診断パイプラインに統合すれば、「ジョブが失敗した理由」を性能劣化・輻輳・NICドライババグのどれであるかを一括で切り分けられるか。RDMATracerが除外するクリーンアップパス由来の失敗(∼21%)はカーネルパニックとして表面化するが、既存監視系の異常検知ルール(Hawkeye・R-Pingmesh)はこれを検知対象に含めているか。([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - RDMATracerの4ヒューリスティック(44関数サンプルでrecall=1.000, F1=0.765)は単一著者組織(Meta)・単一ベンダー(Mellanox系ドライバ)での検証にとどまる。他クラウド事業者・他ベンダーNIC(Intel E810等)のカーネルドライバ実装へ同じヒューリスティックを適用した場合、名前空間ゲートの変更だけで同水準の精度を再現できるか。([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - FlowTracer のホップ特定は本文中では Arista の ECMP ハッシュ可視化 CLI に依存すると記述される。R-Pingmesh・Hostping の binary network tomography 的投票による箇所特定はベンダー中立なアルゴリズムだが、FlowTracer のようにベンダー固有 CLI へ依存する経路可視化を、マルチベンダー環境(Lumina が扱う CX4 Lx / Intel E810 混在等)へ一般化するには何が必要か。FlowTracer が提案する FIM(Flow Imbalance Metric)を既存の RDMA 監視系(R-Pingmesh・Hawkeye)の異常検知ルールへ組み込み、ECMP 由来の負荷不均衡と PFC 連鎖輻輳を同一ダッシュボードで見分けることは可能か。([[@2024__arXiv__FlowTracer - A Tool for Uncovering Network Path Usage Imbalance in AI Training Clusters]]) ## 関連 - ソース: [[@2024__arXiv__FlowTracer - A Tool for Uncovering Network Path Usage Imbalance in AI Training Clusters]] / [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] / [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]] / [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]] / [[@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]] / [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]] / [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]] / [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]] / [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]] / [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]] / [[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]] - 概念: [[テレメトリ]](能動/受動の計装) / [[オープンネットワーキング]](RoCE/Ethernet) / [[LLM学習モニタリング]](ネットワーク視点) / [[Fault Localization]] / [[GPUクラスタ運用]] / [[障害予測]](OptProphet の予防型) / [[RDMA]](Collie のホスト側探索空間設計) / [[eBPF]](RDMATracerのカーネル計装基盤) / [[GPU観測性]](ICLensのGPU/CPU/RNICコンポーネント別可視化) / [[不均衡障害分類]](RTFDの少数ショット・データ不均衡対処との対比) - エンティティ: [[R-Pingmesh]] / [[Astral]] / [[Pulse]] / [[Kefei Liu]] / [[Jiao Zhang]] / [[BUPT]] / [[Douyin Vision]] / [[NCCL]] / [[ByteDance]] / [[Xinhao Kong]] / [[Soudeh Ghorbani]] / [[Meta]] / [[Carnegie Mellon University]] / [[InterconnectLens]] / [[Prometheus]] / [[NVIDIA Data Center GPU Manager]] / [[University of Tokyo]] - 教科書: [[wiki/surveys/RDMAネットワークモニタリングの教科書]](本 concept の計装点 7 層と時間軸 4 系統を座標系として明示し、機構・障害の分類学・計測の設計空間・実務・統合を 5 部 19 章に展開したページ) - 関連 MOC: [[HPC - MOC]] / [[分散深層学習 - MOC]] ## 出典 - [[@2024__arXiv__FlowTracer - A Tool for Uncovering Network Path Usage Imbalance in AI Training Clusters]](§III 設計・アーキテクチャ・ホップバイホップ経路探索・FIM 指標、§IV ECMP vs 静的ルーティングの実測比較(不均衡 36.5% vs 6.2%)) - [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]](§3.4 PFC一時停止カウンタと平均トラフィックレートの乖離によるバースト検知、§2.4 switchos/finecounters テレメトリ設計) - [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]](§3-6 探索空間・SA アルゴリズム・MFS, §7 評価: 8 サブシステムで 18 件の異常、15 件が新規発見) - [[@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 日前アラーム) - [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]](§2-3 破損 vs 輻輳の特性差、§4 根本原因の光パワーシグネチャ、§5 CorrOpt のリンク無効化最適化) - [[@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 内で対処まで完結) - [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]](mlx5 ドライバの ethtool カウンタ一次仕様: 5 計測点(Ring/Netdev・vPort・Physical Port・Priority Port・Device)× 3 種別(Informative/Acceleration/Error)、輻輳・リンク品質・PCIe 信号品質の代表カウンタ) - [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](§提案手法 kernel-verbs/ドライバ層への戻り値ゲート型eBPF計装、§実験結果 ALPS基準73%カバレッジ・オーバーヘッド1桁未満、対象がネットワーク性能異常からNICドライバのカーネルバグへ移る第七の計装軸) - [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]](§2 ICLensのExporter構成(dcgm-exporter・拡張版Intel pcm・procfsベースRNIC Exporter)とダッシュボード設計、§3 TCP誤用・GPUDirect RDMA誤設定・イーサネットスイッチ輻輳の3ケーススタディ) - [[@2025__ICPADS__Classifying Host-Side RDMA Pingmesh Results to Efficiently Identify Transport Faults in Data Centers]](§III 提案手法(特徴抽出・LSTM分類・SFTによるトポロジ適応・障害局所化)、§IV 評価: 6障害タイプ平均F1 0.93・3トポロジ平均accuracy 0.918・AUC 0.94)