# NIC 光モジュールのモニタリング — 関連文献の横断調査 NIC(ホスト側ネットワークインターフェース)に挿さるプラガブル光モジュールを、どのメトリクスで、どの計装点から、どの時間軸で監視するか。規格・実装レイヤと、大規模 AI クラスタの実測報告と、学術文献の系譜を突き合わせて整理する。 --- ## 1. 何が測れるか — 規格レイヤ 光モジュールが自ら公開する診断値は 3 世代の規格に分かれる。 | 規格 | 対象 | 主な観測量 | アクセス方式 | |---|---|---|---| | **SFF-8472**(DDM/DOM) | SFP/SFP+/SFP28 | 温度、電源電圧 Vcc、Tx バイアス電流、Tx 光出力、Rx 受光レベル、および各値の high/low alarm・warning 閾値 | アドレス A0h(識別)/ A2h(診断) | | **SFF-8636** | QSFP+/QSFP28(4 レーン) | 上記に加えレーン別 Rx 光パワー・Tx バイアス | ページ切り替え(閾値は Upper Page 03h) | | **CMIS 5.3**(OIF) | QSFP-DD/OSFP/QSFP112 | 上記に加え Module State、レーン別 Data Path State、そして **VDM** | Lower/Upper ページ + CDB | 規格レイヤで決定的に重要なのは CMIS の **VDM(Versatile Diagnostics Monitoring)** である。モジュールが最大 256 個の observable と 64 個の閾値を定義でき、observable には**メディア側 pre-FEC BER**・**eSNR(推定 SNR)**・エラードフレーム数・レーザ温度が含まれる。コヒーレント向けの C-CMIS は、eSNR がベンダ非依存であることを理由に **eSNR を用いたアラーム設定を推奨**している。 > [!warning] 閾値をそのまま SLO にしない > SFF-8472 系の alarm/warning 閾値は**ベンダ定義**であり、規格が値を決めていない。「まだアラームが出ていない」ことは「マージンがある」ことを意味しない。 --- ## 2. どう取るか — Linux / NIC 実装レイヤ | 取得経路 | 得られるもの | 制約 | |---|---|---| | `ethtool -m`(`ETHTOOL_MSG_MODULE_EEPROM_GET`) | 温度・電圧・レーザバイアス電流・レーザ出力・平均受光レベルと各閾値 | 1 回 128 バイト・半ページ境界をまたげない。ドライバがページ/バンク読み出し未実装だと **CMIS の閾値ページや VDM に到達できない** | | `ethtool -I --show-fec` | `corrected_blocks` / `uncorrectable_blocks` / `corrected_bits`(総計+レーン別) | BER にするには時間窓と総ビット数が要る | | `ethtool -S`(mlx5) | `rx_corrected_bits_phy`、`rx_err_lane_[l]_phy`(**FEC 訂正前**のレーン別生エラー)、`rx_pcs_symbol_err_phy`、`rx_crc_errors_phy`、`link_down_events_phy`、`rx_bits_phy` | 分母 `rx_bits_phy` の露出はカーネル版数依存 | | `mlxlink --show_counters` | **Raw Physical BER(pre-FEC)/ Effective Physical BER(post-FEC)**、レーン別 raw errors | MFT のインストールと特権が必要。ベンダ固有 | | `mlxlink --rx_fec_histogram --show_histogram` | FEC ブロックあたり誤りビット数の分布 | マージン評価に有用 | | `mlxlink --show_eye` | アイ開口(高さ/位相)・Physical Grade | レーン別 | | CMIS VDM(ページ経由) | モジュール自身が測る pre-FEC BER・eSNR・エラードフレーム数(現在値/最小/最大/平均) | モジュールが VDM を実装している場合のみ | CMIS の VDM 項目名の具体形は SONiC の実装(`sonic-platform-common` の `cmis.py`)が最良の参照になる。`prefec_ber_curr/min/max/avg_media_input{lane}`、`esnr_media_input{lane}`、`errored_frames_*` がレーン別・media/host 別に並ぶ。SONiC の `xcvrd` は挿抜をイベント駆動、**DOM を 60 秒周期ポーリング**で扱う。I2C が低速であるという物理的制約に基づく設計判断である。 ### 監視スタックの落とし穴 1. **node_exporter だけでは DOM は取れない**。標準の `ethtool` コレクタは `-m` を含まない。専用エクスポータ(`wobcom/transceiver-exporter`、`Showmax/prometheus-ethtool-exporter`)か textfile collector が要る。 2. **外部校正モジュールの生値は物理量ではない**。SFF-8472 の externally calibrated では係数・オフセット適用が必須で、自前パーサは**もっともらしい嘘の値**を出す。 3. **I2C が詰まると古い値が最新値として残る**。最終更新時刻をメトリクス化して鮮度を別途監視する必要がある。 4. **レーン別の偏りが総計に埋もれる**。8 レーン中 1 レーンだけが限界近い状態を捕まえるには、レーンをラベルに保持する。 5. **DAC / AOC と光の混在**。銅 DAC には光パワーが存在しない。`Identifier` / `cable_type` でラベル分離しないと偽陽性か見落としのどちらかになる。 6. **VF からは `*_phy` 系もモジュール情報も取れない**。ベアメタルの PF 上で動かす前提を明示する必要がある。 --- ## 3. 閾値監視が効かない理由 — pre-FEC BER の位置づけ 400G PAM4 の KP4 FEC(RS(544,514))は pre-FEC BER **約 2.4e-4** まで訂正する。この限界に近づいてもパケットは流れ続け、post-FEC は綺麗なまま、**ダッシュボードは緑のまま**マージンだけが削られる。そこに汚れたコネクタ・温度変動・クロストークが 1 つ加わると FEC が破綻し、訂正不能コードワードがアプリケーション層に到達する。 したがってアラームは post-FEC の訂正不能カウンタではなく、**pre-FEC BER のトレンドとレーン別の偏り**、および eSNR に置く。これは C-CMIS が eSNR をアラーム指標として推奨する思想と整合する。JANOG58 の Rack-Scale GPU サーバ運用報告も、Pre-FEC/Post-FEC BER と **FEC Symbol Error Bins** を用いた光リンク劣化の切り分け手順を示している。(Source: [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) --- ## 4. どれだけ効いているか — 大規模 AI クラスタの実測 | 出典 | 規模 | 光関連の数値 | |---|---|---| | [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] | Alibaba 本番 AI 訓練クラウド | **`Optic module & fiber error` 6.7%**。光は **DAC 比 1.2〜10 倍**の障害率。納品時の汚染で通常の **10〜20 倍**(徹底清掃を数十回)。リンク修理チケット週数十件、累計 O(10K) 件のホットフィックス | | [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] | 15K GPU 目標 | **NIC–ToR リンクが月 0.057% 故障**、ToR スイッチ 0.051%/月。訓練ジョブ 1 本が月 1〜2 回クラッシュ。**リンクフラップ 5K〜60K 件/日** | | [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] | Tencent 512K GPU | `Optical Fiber` **7%** + `Link Flap` 2% + `Wire conn.` 3%。fail-slow 13% / fail-hang 17% | | [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] | Meta RSC-1/2 計 28K GPU | レモンノード 40 台の根本原因のうち **`Optics` 2.6%**(母数が小さい) | | [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] | ByteDance >10K GPU / 7 か月 | **`AOC error` 0.9%**。ただし「光ケーブル関連カウンタの不在により部分的に取りこぼす」と原典が自認 | | [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] | ByteDance >10K GPU | 割合は原典に数値なし。フラップの down-up 間隔は数秒。根本原因は NIC・AOC ケーブル・スイッチ間のリンク品質で、**信号強度の品質管理**により改善 | | [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] | Azure A100 | MTBI **17.5 時間**。**BER > 1e-12 の欠陥 InfiniBand リンクが熱帯地域 DC で 35 倍** | | [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] | ByteDance 本番 RoCE | 割合は原典に数値なし。**光ファイバの損傷・経年劣化と光モジュール内の埃がパケット破損を起こし、スイッチ/RNIC でドロップ**と定性記述 | | [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] | OpenAI + Microsoft、50K / 75K GPU の本番事前訓練 | T0-T1 リンクフラップが**常時毎分数件**。**T0 スイッチの光トランシーバ 1 個のグリッチで 4 リンク同時フラップ → 1 分間スループット約 25% 低下**(ジョブは落ちず即回復)。**NIC 側 800G 光モジュールのフラップは全ポート喪失で救済不能** | | [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]] | Google TPUv4、6,144 本の光 ICI リンク / 48 台の OCS | **光 ICI ケーブルの日次故障率 0.005%**、OCS 0.04%、TPU マシン 0.08%。可用性 99.98%、訓練ジョブの約 1% がハードウェア停止の影響を受ける。**OCS + 光ファイバは pod 総資本コストの 5% 未満・総電力の 3% 未満**。訓練ジョブの 95% が耐障害 ICI ルーティングを選択(実運用のステップタイム低下 0.5〜8.6%) | | [[@2018__IMC__A Large Scale Study of Data Center Network Reliability]] | Facebook バックボーン光ファイバ / 7 年 | ベンダの 90% でリンク障害は **5,709 時間に 1 回未満**(広域バックボーン。クラスタ内光モジュールではない) | > [!note] Meta のモデル開発側報告は光を独立計上しない > Llama 3(16K GPU・54 日・419 件の予期せぬ中断、`Network Switch/Cable` 8.4%、<https://arxiv.org/abs/2407.21783>)も、その後継の [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]](32K GPU・678 件、`Network Switch/Cable` **36 件 5.3%**、2.3 件/1000 サーバ/日、有効訓練時間 95〜97%)も、光モジュールを独立カテゴリに持たない。後者は本文に `optical` / `transceiver` / `BER` / `FEC` のいずれの語も現れないことが確認されており、光関連の故障はすべて `Network Switch/Cable` に丸め込まれている。なお Llama 3 の Table 5 は件数列と割合列が内部で不整合(148/419 = 35.3% だが 30.1% と印字)なので引用時に注意が要る。 --- ## 5. 横断的知見 1. **「光関連が何%か」は、その組織が物理層をどこまで観測できているかの関数である。** Meta は `Network Switch/Cable` に丸め込み、Alibaba・Tencent・ByteDance は独立計上する。そして独立計上した文献は**いずれも観測不足を自認している**([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] は光ケーブル用カウンタの不在を明記)。公開されている光関連の割合は**すべて下限値**として扱うのが安全である。 2. **障害の主戦場はクラッシュから「静かな劣化」へ移った。** dual-ToR を入れた Alibaba は「リンク障害をクラッシュから性能劣化(帯域半減)へ移した」と明言する。冗長化が進むほど、光障害は可用性の問題ではなく**スループットと尾部レイテンシの問題**に転化する。[[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] の「冗長性が性能問題を隠す」は同じ構造である。([[グレイ障害]] / [[潜在的障害]]) 3. **NIC 側光モジュールは冗長化で救えない最後の単一障害点である。** T0-T1 間のフラップは MRC で ride out できても、NIC 側 800Gb/s 光モジュールを 4×200Gb/s に分割している構成では、NIC トランシーバがフラップすると NIC の全ポートを失い QP が落ちる。計装点を「スイッチ ASIC / NIC・DPU / 集団通信ライブラリ / 物理部品」の 4 層で見る [[RDMAネットワーク監視]] の整理において、NIC 側の物理部品層だけがアーキテクチャによる救済を受けられない。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) 一方 [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]] は、[[光回線交換]](OCS)による動的再構成という救済機構を物理層そのものに持ち込む設計を採る。再構成性がない場合、1024 ホストのジョブを成立させるには各ホスト 99.9% の可用性が要るが、OCS を入れると **99% まで要件が緩和される**。**光障害を「検知して直す」のか「トポロジで迂回する」のか**という設計分岐がここで立ち、後者を選べば個別モジュールの監視精度に対する要求そのものが下がる。 4. **光障害率は部品固有の AFR ではなく施工品質と設置環境に支配される。** Aegis の建設汚染 10〜20 倍と SuperBench の熱帯 35 倍は、いずれも部品の信頼性ではなく外部要因である。**光モジュール単体の AFR/FIT を実測で公開した文献は見つからなかった。** 公開されているのは (a) リンク単位の月次・日次障害率、(b) 障害原因の内訳比率、(c) DAC 比の相対値の 3 種にとどまる。 5. **時間軸が「反応」と「予防」に分岐する。** [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] の OptProphet は光トランシーバ故障を**平均 1.11 日前**に予測する予防型(予測 F1 0.884 / 分類 F1 0.855)。対して [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] や [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]] は顕在化後に素早く切り分ける反応型である。 --- ## 6. 学術文献の系譜 ### 6.1 パケット破損と箇所特定(データセンターネットワーク側) - [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]](Danyang Zhuo, Monia Ghobadi, Ratul Mahajan, Klaus-Tycho Förster, Arvind Krishnamurthy, Thomas Anderson、SIGCOMM 2017)。本領域の古典。**15 の本番データセンター・35 万本のリンク**を解析し、破損損失が輻輳損失と質的に異なること——**破損率はリンクごとに時間的に安定し、利用率と相関しない**——を示した。この観察から CorrOpt を設計し、破損リンクを安全に切り離しつつ各 ToR の最小パス数を保証し、症状から根本原因(**ケーブル交換・コネクタ清掃**)を推薦する。**70 以上のデータセンター**に展開し、破損損失を **3〜6 桁**削減、修復精度を **60%** 改善した。光モジュール監視を「個々の劣化検知」ではなく「フリート全体の修復オペレーション最適化」として定式化した点で、いまなお参照価値が高い。 - **007: Democratically Finding the Cause of Packet Drops**(NSDI 2018、<https://arxiv.org/pdf/1802.07222>)。TCP 再送を投票に見立ててドロップ箇所を特定する。 - **FANcY: FAst in-network GraY failure detection for ISPs**(SIGCOMM 2022、<https://dl.acm.org/doi/10.1145/3544216.3544242>)。既存の監視ツールで検知できない、故障ハードウェアによる長時間のパケットドロップ(グレイ障害)をデータプレーンで検知・箇所特定する。 - **Gray Failure: The Achilles' Heel of Cloud-Scale Systems**(HotOS 2017)。差分観測可能性(differential observability)という定式化。光モジュールの緩慢な劣化はこの枠組みの典型例である。 ### 6.2 光レイヤの機械学習(光通信コミュニティ側) データセンターネットワークの文脈とは別に、光通信コミュニティには「ソフト障害(soft failure)」検知の厚い蓄積がある。**この系譜がデータセンター/AI クラスタの文献とほとんど交差していない**ことが、今回の調査で最も目を引いた構造である。 - **An Overview on Application of Machine Learning Techniques in Optical Networks**(Francesco Musumeci, Cristina Rottondi, Avishek Nag ほか、IEEE Communications Surveys & Tutorials 21(2):1383-1408, 2019、<https://arxiv.org/abs/1803.07976>)。光通信・光ネットワークへの機械学習応用の基本サーベイ。 - **A Review of Machine Learning-based Failure Management in Optical Networks**(Danshi Wang, Chunyu Zhang, Wenbin Chen, Hui Yang, Min Zhang, Alan Pak Tao Lau、2022-08-23、<https://arxiv.org/abs/2208.10677>)。障害管理を**アラーム解析・故障予測・故障検知・故障箇所特定・故障種別同定**の 5 応用領域に分類したレビュー。 - **Machine-Learning-Based Soft-Failure Detection and Identification in Optical Networks**(OFC 2018, M3A.5、<https://opg.optica.org/abstract.cfm?uri=ofc-2018-M3A.5>)。 - **Two-stage machine learning for modulation-robust soft-failure detection and localization in optical fiber transmission links**(JOCN 18(7):674)。段 1 で**受信 pre-FEC BER と OSNR の窓統計**から異常を検知する。NIC 側 VDM が公開する observable とほぼ同じ入力を使う点で、実装との接続が具体的に見える。 - **Modeling Soft-Failure Evolution for Triggering Timely Repair with Low QoT Margins**(<https://arxiv.org/pdf/2208.14535>)。QoT マージンが薄い条件下で修理を適時に発火させる問題設定。§3 で述べた「マージンだけが削られる」状況の定式化にあたる。 - **A Data Augmented Bayesian Network for Node Failure Prediction in Optical Networks**(<https://arxiv.org/pdf/2102.03616>)。 ### 6.3 ギャップ - **光通信コミュニティの soft-failure 検知と、AI クラスタ運用側の光モジュール障害報告が接続されていない。** 前者は長距離コヒーレント伝送を主対象に pre-FEC BER・OSNR の時系列から劣化を追い、後者は数万本のショートリーチ光リンクを抱えながら「光ケーブル関連カウンタが無い」と述べている。CMIS VDM が pre-FEC BER と eSNR をモジュール自身に測らせる形で標準化された今、**前者の手法を後者のスケールに適用する研究**が空白として残る。[[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] はこの空白を埋めにいく数少ない例だが、APNet のショートペーパー(3 ページ)であり内部手法は公開情報から追えない。 - **光モジュール単体の AFR/FIT を実測で公開した一次資料が存在しない。** - Redfish `PortMetrics` のトランシーバ関連プロパティ、OpenBMC の DOM 公開実装、Meta FBOSS `qsfp_service` の一次ドキュメントは未確認。 > [!warning] 引用してはいけない数値 > 「10M 光モジュールのクラスタでは 48 秒に 1 回リンクフラップ」(<https://arxiv.org/abs/2603.03736>)は、MTBF 1e7 時間・フラップ MTTF 3e5 時間を仮定した**著者自身によるモデル推計**であって実測ではない。「AI クラスタ障害の 90% が光モジュール起因」は一次資料を特定できなかった。ベンダ白書(Clockwork、Credo、Cisco)は算定根拠を示していない。 --- ## 7. 未解決の問い - CMIS VDM の pre-FEC BER・eSNR を数万ポート規模でフリート収集したとき、I2C ポーリングのコストと 60 秒粒度は劣化の早期検知に十分か。フラップが毎分数件のオーダーで起きる環境で、60 秒粒度の DOM とサブ秒粒度の `link_down_events_phy` をどう組み合わせるか。 - CorrOpt が定式化した「切り離してよいリンクの選択」は、rail-optimized トポロジと dual-ToR を前提とする AI クラスタでどう変わるか。冗長パスの前提が違えば最適な切り離し方針も変わるはずである。 - 光通信の soft-failure 検知手法(pre-FEC BER と OSNR の窓統計による 2 段検知)を、ショートリーチのデータセンター光モジュールにそのまま適用できるか。距離・変調方式・FEC 方式の違いがどこで効くか。 - 「NIC トランシーバのフラップは ride out できない」という制約に対し、NIC 側の光設計(ポート分割の粒度、AEC/DAC への置き換え)でどこまで緩和できるか。 --- ## 関連 - 概念: [[RDMAネットワーク監視]] / [[データセンターネットワーク信頼性]] / [[データセンター内光配線設計]] / [[光トランシーバー電力方式]] / [[グレイ障害]] / [[障害予測]] / [[GPUクラスタ運用]] / [[Rail-Optimizedトポロジ]] - 実務資料: [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]] / [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] ## 出典 - 規格: [OIF-CMIS 5.3](https://www.oiforum.com/wp-content/uploads/OIF-CMIS-05.3.pdf) / [C-CMIS 1.3](https://www.oiforum.com/wp-content/uploads/OIF-C-CMIS-01.3.pdf) / [VDM webinar](https://www.oiforum.com/wp-content/uploads/VDM_CMIS_Webinar.pdf) / [SFF-8472 Rev 12.3](https://modultech.ru/wp-content/uploads/2019/09/SFF-8472.pdf) - 実装: [ethtool(8)](https://man7.org/linux/man-pages/man8/ethtool.8.html) / [ethtool netlink](https://docs.kernel.org/networking/ethtool-netlink.html) / [mlx5 counters](https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/counters.html) / [mlxlink](https://networking-docs.nvidia.com/mftswum/422/mlxlink+utility) / [SONiC cmis.py](https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/api/public/cmis.py) / [SONiC transceiver-monitor HLD](https://github.com/sonic-net/SONiC/blob/master/doc/xrcvd/transceiver-monitor-hld.md) - 監視スタック: [wobcom/transceiver-exporter](https://github.com/wobcom/transceiver-exporter) / [Showmax/prometheus-ethtool-exporter](https://github.com/Showmax/prometheus-ethtool-exporter) / [node_exporter ethtool collector](https://github.com/prometheus/node_exporter/blob/master/collector/ethtool_linux.go) - 学術: 各節に URL を併記