# NIC 光トランシーバーのモニタリングに関する文献横断調査 NIC(ホスト側ネットワークインターフェース)に挿さる光トランシーバーを、どのメトリクスで、どの計装点から、どの時間軸で監視するか。 規格と実装のレイヤ、大規模実測の一次資料、学術文献の系譜を突き合わせて整理する。 前半の 2 節で対象そのものと語彙を確認し、§3 以降で監視の設計に入る。 --- ## 1. 光トランシーバーという部品 **光トランシーバー**は、電気信号と光信号を相互に変換する着脱可能な部品である。 スイッチや NIC のポートに挿し込んで使い、故障すれば挿し替えられる。 この着脱できる性質を**プラガブル**と呼ぶ。 内部は送信と受信の 2 系統に分かれる(図 1)。 送信側は、ホストから来た電気信号を変調器で光の強弱に変え、レーザから送り出す。 受信側は、届いた光をフォトディテクタで電気に戻し、増幅器を通してホストへ渡す。 監視で読む値の大半は、この 4 つの部品の状態を間接的に表している。 たとえばレーザが劣化すれば、それを光らせるための電流が増える。 ![[Attachments/NIC光トランシーバーのモニタリング/figure-01-transceiver-anatomy.png|900]] 図 1 光トランシーバーの内部構造と、各部品から取り出せる観測量。値は I2C バス越しに読むため、読み出し頻度に物理的な上限がある。 モジュールの外形と端子の規格を**フォームファクタ**と呼ぶ。 速度が上がるにつれて SFP、QSFP、QSFP-DD や OSFP へと世代が進み、1 つのモジュールが収める**レーン**(並列の信号路)の本数も増えた。 たとえば 800Gbps のモジュールは、200Gbps のレーン 4 本、あるいは 100Gbps のレーン 8 本として終端される。 レーンごとに独立した光パワーとエラーカウンタを持つため、監視ではレーンを区別して保持できるかどうかが精度を左右する。 同じポートに挿さるものが、すべて光であるとは限らない。 - **DAC**(Direct Attach Cable):銅線の直結ケーブル。光を使わないため、光パワーという観測量がそもそも存在しない。 - **AOC**(Active Optical Cable):両端にトランシーバを固定した光ケーブル。片端だけを交換できない。 - 光トランシーバー:着脱可能で、任意の光ファイバと組み合わせられる。 本ページが主題とするのは、NIC 側に挿さる光トランシーバーである。 スイッチ側のトランシーバと物理的には同じ部品だが、障害が起きたときに救済できるかどうかは両者で大きく異なる(§9)。 --- ## 2. 監視で使う用語 以降で繰り返し使う語をまとめる。 - **光パワー**:送受信する光の強さ。dBm という対数の単位で表し、0 dBm が 1 mW にあたる。3 dB 下がるごとに強さが半分になる。送信側を Tx パワー、受信側を Rx パワーと呼ぶ。 - **バイアス電流**:レーザを発光させるために流す直流電流。レーザが老朽化すると、同じ光出力を保つのに必要な電流が増える。 - **BER**(Bit Error Rate、ビット誤り率):受信したビットのうち誤っていたものの割合。1e-12 なら、1 兆ビットに 1 ビット誤る。 - **FEC**(Forward Error Correction、前方誤り訂正):冗長ビットを付けて送り、受信側で誤りを訂正する仕組み。100Gbps 以降のイーサネットは標準で搭載する。 - **pre-FEC BER と post-FEC BER**:訂正する前の誤り率と、訂正した後の誤り率。前者は物理層がどれだけ余裕を残しているかを表し、後者は上位層に実際に漏れる誤りを表す。訂正能力の範囲内であれば、pre-FEC BER が悪化しても post-FEC BER はゼロのままである。この非対称が、本ページの議論の多くを支配する。 - **eSNR**:モジュールが自ら推定する信号対雑音比。値が大きいほど信号が雑音に対して余裕を持つ。 - **DDM**(Digital Diagnostic Monitoring、DOM とも呼ぶ):モジュールが自分の温度、電圧、光パワーなどを内部の記憶領域に書き出し、外部から読めるようにする仕組み。 - **I2C**:モジュールとホストをつなぐ低速なシリアルバス。DDM の値はこのバス越しに読むため、読み出し頻度に物理的な上限がある。 - **リンクフラップ**:リンクが短時間落ちて、すぐ復帰する現象。 - **ハード故障とソフト故障**:恒久的に動作不能になり交換が必要な故障と、一時的に劣化してから自力で正常へ戻る故障。 - **AFR**(annualized failure rate、年次故障率):1 年あたりに故障する部品の割合。**MTBF**(平均故障間隔)は同じ情報を時間の側から表したものである。 - **グレイ障害**:動いているように見えるのに性能だけが落ちている状態。監視側からは正常に見え、利用側からは遅く見えるという、観測のずれとして現れる。 --- ## 3. 規格レイヤが公開する診断値 光トランシーバーが自ら公開する診断値は 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 を用いたアラーム設定を推奨している。 パッケージング(SFP から QSFP、QSFP-DD/OSFP、OSFP224 へ)と変調方式(NRZ から PAM4、xQAM へ)の世代交代が、そのまま診断規格の世代交代に対応する。 速度帯ごとの伝送距離命名規則(KR/CR/SR/DR/FR/LR/ER/ZR)とファイバ対数の対応は [[@2024__NADDOD__The Evolution of 400G, 800G, and 1.6T Optical Modules]] に整理がある。 監視設計上は、同じクラスタ内に SFF-8472 世代と CMIS 世代が混在することを前提にラベルを設計する必要がある。 > [!warning] 閾値をそのまま SLO にしない > SFF-8472 系の alarm/warning 閾値はベンダ定義であり、規格が値を決めていない。 > 「まだアラームが出ていない」ことは「マージンがある」ことを意味しない。 > §5 で扱う [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] の運用範囲分析でも、故障間近のモジュールは健全モジュールより分布の裾が広がる形で異常を示しており、単一閾値の越境として現れるとは限らない。 --- ## 4. 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 が低速であるという物理的制約に基づく設計判断である。 この 60 秒がどこまで妥当かは §7 で扱う。 ### 監視スタックの落とし穴 - node_exporter だけでは DOM は取れない。 標準の `ethtool` コレクタは `-m` を含まないため、専用エクスポータ(`wobcom/transceiver-exporter`、`Showmax/prometheus-ethtool-exporter`)か textfile collector が要る。 - 外部校正モジュールの生値は物理量ではない。 SFF-8472 の externally calibrated では係数とオフセットの適用が必須で、自前パーサはもっともらしい嘘の値を出す。 - I2C が詰まると、古い値が最新値として残る。 最終更新時刻をメトリクス化して鮮度を別途監視する必要がある。 - レーン別の偏りが総計に埋もれる。 8 レーン中 1 レーンだけが限界近い状態を捕まえるには、レーンをラベルに保持する。 - 銅 DAC には光パワーが存在しない。 `Identifier` や `cable_type` でラベルを分離しないと、偽陽性か見落としのどちらかになる。 - VF からは `*_phy` 系もモジュール情報も取れない。 ベアメタルの PF 上で動かす前提を明示する必要がある。 - 平均値だけを保持すると、最も効く特徴を捨てることになる。 §5 で示すとおり、故障との関連度が最も高い特徴群は値そのものではなく時間変動の大きさである。 ダウンサンプリング時に平均だけ残す設計は、この情報を系統的に破棄する。 --- ## 5. 故障を予告する観測量 どの観測量が実際に故障を予告するのかは、長らく大規模な実測を欠いていた。 [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]](Notaro、Yu、Haeri、Cardoso、Gerndt、[[Huawei Technologies Duesseldorf GmbH]] ほか、CCGrid 2023)がこれを定量的に埋めた。 350 万台超、131 リージョン、15 か月(405 万デバイス年)の DDM と OS レベルメトリクスを、時系列自己相関、AFR 推定、運用範囲比較、パターン lift、機械学習予測という 5 つの独立な軸で解析している。 光トランシーバー信頼性の大規模研究としては初とされる。 ### 5.1 lift で測った予兆の強さ **lift** は `P(パターン | 故障) / P(パターン)` として定義され、値が大きいほど将来故障との関連が強い。 | 順位 | パターン | lift | |---|---|---| | 1 | エラーレート高値(CRC ミスマッチ/秒) | 9.13x | | 2 | 温度の高分散 | 7.29x | | 3 | バイアス電流の高分散 | 6.71x | | 4 | Rx パワーの高分散 | 6.53x | | 5 | Tx / Rx スループットの高分散 | 6.42x / 6.3x | | 6 | バイアス電流の高値 | 6.24x | | 7 | 温度の高値 | 6.01x | | 8 | Rx / Tx スループットの高値 | 5.73x / 5.7x | | 9 | 低電圧 / 高電圧 | 4.81x / 2.38x | | 圏外 | パケットロス(高値と高分散の両方) | 1.27〜1.28x | ここから読み取れる設計上の含意は 3 つある。 第一に、エラーレートが単独で最強である。 lift、特徴重要度(Mutual Information と Logistic Regression 係数の両方)、自己相関、運用範囲分析の 4 軸すべてで首位を占める。 健全モジュールのエラーレートは常に 0.00 pps であるのに対し、故障モジュールでは最大 0.1325 pps に達する。 すなわち、非ゼロのエラーレートを一度でも観測すること自体が予兆である。 第二に、高分散が高値を上回る。 温度、バイアス電流、Rx パワー、スループットのいずれでも、値そのものの高さより時間変動の大きさのほうが lift が高い。 故障モジュールのバイアス電流の時間変動は健全モジュール比で 52% 大きく(0.5342 mA と 0.3508 mA)、温度は 75% 大きい(1.516℃)。 §4 の最後に挙げた落とし穴は、この結果に直結する。 第三に、パケットロスは使えない。 CRC エラーに起因しないパケットロス(バッファ解放など)が支配的なため、光トランシーバー故障とはほぼ相関しない。 逆に言えば、上位層のロス監視は光トランシーバー監視の代替にならない。 ### 5.2 バイアス電流の物理的機序 バイアス電流の高値と高分散が効くことには、物理的な裏づけがある。 レーザは老朽化するほど、同じ光出力を維持するのに多くのバイアス電流を要する。 したがってバイアス電流はレーザ劣化の直接的な代理変数であり、機械学習が見つけた相関ではなく因果に近い。 DDM 属性の平均値が 80 パーセンタイルを超えるモジュールでは、バイアス電流、温度、Rx/Tx パワーで AFR が最大 8.46 倍に増加する。 ### 5.3 エラーの再発性 エラーレート時系列の自己相関を、ホワイトノイズおよび異なる速度の unit ramp 信号と比較すると、ラグ 24 時間以内で自己相関が急激に増加する。 一度 CRC エラーが出たモジュールは、24 時間以内に再発する確率が高い。 これは「1 回のエラーはノイズとして無視する」という運用慣行への直接的な反証であり、初回観測の時点でチケットを起こす根拠になる。 ### 5.4 予測モデルの精度と再現率 | モデル | Accuracy | Precision | Recall | F1 | |---|---|---|---|---| | Random Forest | 99.4% | 88.9% | 47.1% | 61.5% | | XGBoost | 99.3% | 91.7% | 50.0% | 64.7% | | Logistic Regression | 99.1% | 72.8% | 36.4% | 48.5% | | ERTrendEstimator(24h ローリング窓の傾き閾値 0.15) | 99.6% | 95.7% | 21.2% | 34.6% | precision 72.8〜95.7% に対し recall 21.2〜50.0% という非対称が、本研究の限界を規定する。 DDM と OS メトリクスは、予測が出たら当たるが、故障の半分以下しか捕まえられない。 しかも単純な閾値ベースのトレンド検出器(ERTrendEstimator)が最高の precision を出しつつ recall は最低という、運用上わかりやすいトレードオフを示す。 著者らはデバイスの経年と DDM 警告閾値情報を未活用の残り代として挙げている。 ### 5.5 OptProphet の内部構成 [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](Xia、Ma、Kuang、[[Shenglin Zhang]]、Xie、[[Yongqian Sun]]、[[Nankai University]] と [[Huawei Technologies]]、APNET 2025)の OptProphet は 3 ページの短編論文であり、Abstract だけでは内部構成が読み取れない。 本文まで読むと、次の 4 つの部品からなる。 - 特徴量集約は 2 経路をとる。 Interpretable Feature Extraction(IFE、statistical、temporal、spectrum の 3 種)と、Attention-Enhanced Feature Representation(AEFR、Transformer self-attention でメトリクス間の物理的結合を捉える)である。 IFE 側は、CCGrid が lift 分析で有効性を示した統計量と時間特徴に、ほぼ同じ入力層として対応する。 - データ不均衡は自動処理する。 Information-Aware Undersampling(IAU)と Feature-Weighted Oversampling(FWO)を、分類難易度に応じて自動的に組み合わせる。 - マルチタスク統合は dual-gate MoE による。 予測ゲートが長期トレンドを、分類ゲートがリスク段階内の局所異常を担う。 MoE を XGBoost に置換するアブレーションで D1 Task#1 の Recall が 0.871 から 0.284 へ崩壊し、マルチタスク設計の寄与が裏づけられている。 - 評価は [[Huawei Technologies]] の実運用 LLM 訓練クラスタ 2 系統による。 D1 は 10,804 台で 20 日、D2 は 3,394 台で 30 日、いずれも 5 分間隔の DDM サンプリングである。 予測 F1 0.884、分類 F1 0.855 で、平均 1.11 日前(D1 が 0.93 日、D2 が 1.29 日)にアラームを発火する。 > [!note] CCGrid 2023 と OptProphet 2025 の関係 > 両者はいずれも [[Huawei Technologies]] のデータに基づき、5 分間隔の DDM を入力とする。 > 前者はどの特徴が効くかを 5 軸の統計分析で明らかにし、後者はその特徴をどう組み合わせて予測精度を上げるかを深層学習で解く。 > 2 年の間隔をおいた同じ系譜の前半と後半として読める。 > CCGrid の recall 21.2〜50.0% に対し OptProphet の D1 Task#1 の Recall 0.871 は大きな改善だが、両者は故障定義もデータセットも異なるため、直接比較はできない。 --- ## 6. pre-FEC BER とマージンの分布 400G PAM4 の KP4 FEC(RS(544,514))は、pre-FEC BER およそ 2.4e-4 まで訂正する。 この限界に近づいてもパケットは流れ続け、post-FEC は綺麗なまま、ダッシュボードは緑のままマージンだけが削られる。 そこに汚れたコネクタ、温度変動、クロストークが 1 つ加わると FEC が破綻し、訂正不能コードワードがアプリケーション層に到達する。 図 2 の崖の形が、この節の議論のほぼすべてを説明する。 ![[Attachments/NIC光トランシーバーのモニタリング/figure-02-fec-margin-cliff.png|900]] 図 2 pre-FEC BER と post-FEC BER の関係。訂正限界の手前では post-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設計と運用までの苦悩]]) ### 6.1 RAIL が測ったマージンの分布 [[@2017__NSDI__RAIL - A Case for Redundant Arrays of Inexpensive Links in Data Center Networks]](Zhuo、Ghobadi、Mahajan、Phanishayee、Zou、Guan、Krishnamurthy、Anderson、NSDI 2017)は、20 データセンター超の 30 万リンク(60 万トランシーバ)を 10 か月計測した。 その結果、99.9% のリンクが BER 1e-12 を満たすのに必要な受光レベルを上回り、99% は閾値より 5dB(3 倍)以上、中央値は閾値のおよそ 6 倍の余裕を持つ。 減衰(TxPower から RxPower を引いた値)の中央値はわずか 0.26dB で、時間変動も小さい(78% のリンクで最大と最小の差が 0.2dB 未満)。 これは冒頭の「マージンだけが削られる」と矛盾しない。 両者を合わせると、平時の光リンクは規格要求に対して過剰にマージンを持っており、問題は分布の中央ではなく裾にある、という像になる。 監視が捉えるべきは、絶対値が閾値に届いたかどうかではなく、そのモジュールが自分自身の平常分布からどれだけ外れたかである。 RAIL はこのマージンをコスト削減の原資として使う立場を取る。 伝送距離を仕様の 1.6 倍から 4 倍に引き伸ばし、10Gbps で最大 10%、40Gbps で最大 44%、100Gbps で最大 30% のコストを削減する(トランシーバは DCN 総コストの 48% から 72% を占める)。 マージンを削るとリンクの 1% から 5% が IEEE 標準を下回るグレーな状態になるため、物理トポロジ上に PPER 保証の異なる K 個の仮想トポロジを構築し、アプリケーションの損失耐性に応じて割り当てる。 詳細は [[光リンク過剰設計]] を参照。 > [!important] AI クラスタでは RAIL の前提が崩れる可能性がある > RAIL は、アプリケーションごとに損失耐性が多様であることを前提にし、RDMA は最も厳しい第 1 クラスに置く(著者は脚注で、RDMA は BER 1e-10 で十分と述べる)。 > ところが AI 訓練クラスタのバックエンドネットワークは、ほぼ全トラフィックが RDMA であり、多様性が消える。 > マージンをコスト削減に回す余地はその分だけ小さく、逆に障害マージンとして温存する判断が合理的になりやすい。 ### 6.2 FEC 世代で変わる要求水準 100Gbps 以降のトランシーバは FEC を搭載するため、pre-FEC BER の要求水準が 1e-12 から 5e-5 へ 7 桁緩和される。 すなわち FEC 世代の光リンクでは、BER 1e-12 という古い基準をそのまま持ち込むと、実際には十分に余裕のあるリンクを不良と判定する。 逆に、FEC のマージンを食い潰した状態は post-FEC には出ないため、冒頭で述べた静かな劣化の問題は FEC 世代でこそ深刻になる。 FEC の導入は問題を解決したのではなく、観測点を pre-FEC 側へ移動させたと理解するのが正しい。 ### 6.3 光パワーの物理的な崖 [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]] は、Tx 電力を固定してファイバの伝送損失を段階的に増やす実測を行っている。 そこから、`Rx power(dBm) = Tx power(dBm) − transmission loss(dB)` という線形関係と、−10dBm を上回れば正常、−19dBm を下回ると中断、その間が劣化という分類の物理的根拠が得られる。 閾値をまたぐと、FEC 訂正能力の限界から post-FEC BER と CRC エラーが非線形に急増する。 線形に劣化する物理量(Rx パワー)を監視していれば崖の手前で捕まえられるが、非線形に跳ねる上位層指標(CRC エラー)を監視していると崖を越えた後にしか気づけない。 計装点選択の原則がここに現れる。 --- ## 7. 一過性イベントと収集粒度 SONiC の DOM 60 秒ポーリングは、劣化の早期検知に十分だろうか。 [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]](Miao ほか、[[Tencent]]、[[Tsinghua University]]、[[UC Santa Barbara]]、NSDI 2022)がこれに答えている。 対象は光バックボーンネットワーク(OTU、OLS、アンプ、OSC)であって NIC ではないが、時間粒度と検知可能性の関係は移植可能な知見である。 ### 7.1 光イベントの継続時間分布 Tencent 本番光バックボーンで 6 か月間(2020 年 7 月から 12 月)1 秒粒度で全インジケータを収集した結果、イベントの内訳は次のとおりである。 | 類型 | 割合 | |---|---| | P-I(持続中断) | 44.63% | | P-D(持続劣化) | 4.28% | | E-I(一過性中断) | 16.85% | | E-D(一過性劣化) | 34.24% | 一過性(ephemeral)イベントが全体の 51.09% を占める。 継続時間はロングテール分布で、20% は 1 秒のみ、50% 超は 10 秒未満で終わる。 ### 7.2 収集粒度と検知率 - 1 秒粒度を基準にすると、15 秒、1 分、15 分粒度のシステムは、それぞれ 25%、39%、71% 少なくしかイベントを検知できない。 - 15 秒より粗い粒度では、一過性イベントを一切検知できない。 - 15 分粒度の既存システムは、全イベントの 35.72% しか正しく検知せず、41.40% は未検知、22.88% は誤検知(持続イベントへの誤分類など)である。 図 3 は、この関係を継続時間の異なる 5 つのイベントで示したものである。 粒度を粗くすると、短いイベントから順に観測から落ちる。 ![[Attachments/NIC光トランシーバーのモニタリング/figure-03-sampling-granularity.png|900]] 図 3 イベントの継続時間と収集粒度の関係。サンプリング周期より短いイベントは、原理的に観測できない。 > [!warning] 60 秒 DOM ポーリングでは光イベントの半分は原理的に取れない > SONiC `xcvrd` の 60 秒周期 DOM ポーリングは、I2C の低速性に基づく合理的な設計判断である。 > だが OpTel の測定を素直に当てはめれば、継続 10 秒未満のイベント(全体の 50% 超)は構造的に見えない。 > 一方 `link_down_events_phy` のようなカウンタはサブ秒の事象を積算値として保持するため、60 秒粒度の DOM(状態量)とイベント駆動または積算のカウンタ(事象)を組み合わせる以外に手がない。 > DOM だけを見ている監視は、フラップが毎分数件のオーダーで起きる環境([[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])では原理的に取りこぼす。 ### 7.3 一過性イベントと持続障害の時間相関 E-D(一過性劣化)イベントの後、5 秒の時間窓では P-I(持続中断)の発生確率がおよそ 20%、1 分の窓ではおよそ 40% に上昇する。 逆に、過去の P-I 事象自体は将来の持続イベントをほとんど予測しない(memoryless)。 すなわち予兆は、短くて弱いイベントの側にあり、大きくて目立つイベントの側にはない。 これは §5.3 のエラー再発性と同型の構造であり、時間スケールこそ違え、小さな初回観測を捨てないという同じ運用原則に帰着する。 ### 7.4 高頻度収集のコスト 高頻度収集が現実的かどうかは、収集アーキテクチャに依存する。 収集頻度を 1 秒から 0.1 秒へ上げると、SNMP ベースの pull 型パイプラインではデバイス CPU 使用率が 34% から 96% に急増するのに対し、push 型でデータ管理をコントローラへオフロードした OpTel では 19% から 25% の微増にとどまる。 トラブルシューティング時間も、光ファイバ起因イベント(全体の 89.7%)で既存の 5 分から 10 分に対し数秒、ハードウェア起因(7.8%)で数時間から数日に対し 2 秒から 60 秒へ短縮された。 ただし、NIC 側光トランシーバーに同じ手が使えるとは限らない。 OpTel が乗り越えたのは、デバイス CPU 上の SNMP MIB クエリ処理という計算上のボトルネックである。 NIC 側 DOM のボトルネックは I2C バスの物理的な帯域であり、計算負荷はオフロードできても I2C の転送時間はオフロードできない。 詳細は [[光バックボーンネットワークテレメトリ]] を参照。 --- ## 8. 大規模実測が示す故障率と障害内訳 ### 8.1 光トランシーバー単体の故障率 光トランシーバー単体の AFR を実測で公開した一次資料は少ない。 [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] が、405 万デバイス年に基づく AFR を公開している。 | 故障定義(エラーレート閾値) | 故障数 | AFR | MTBF(時間) | 平均寿命(年) | |---|---|---|---|---| | ER > 5 pps(ハード故障) | 4,809 | 0.1341% | 6.537×10⁶ | 746 | | ER > 1 pps | 6,190 | 0.1726% | 5.079×10⁶ | 579 | | ER > 0.1 pps | 16,263 | 0.4535% | 1.933×10⁶ | 221 | | ER > 0.01 pps(最も緩いソフト故障) | 59,041 | 1.6463% | 5.325×10⁵ | 61 | 他コンポーネントとの比較が示唆に富む。 ハード故障の AFR 0.1341% は DIMM チップ(0.22%)と同程度で、ハードドライブ(1.7% から 8.6%)より有意に低い。 ソフト故障はハード故障の最大 12.22 倍あり、この比率は HDD の latent sector error(ハード故障の 1 倍から 2 倍)ではなく、DIMM の soft error(36 倍)に近い。 > [!important] 光トランシーバーは壊れにくいが頻繁に軽く不調になる部品である > AFR だけを見れば、光トランシーバーは DIMM 並みに壊れにくい。 > にもかかわらず §8.2 の運用報告で光が障害内訳の上位に来るのは、台数が桁違いに多いこと、ソフト故障がハード故障の 10 倍以上の頻度で起きること、ソフト故障は交換チケットにならないため部品 AFR には計上されないが訓練ジョブは止めることの 3 つによる。 > **部品の信頼性指標と運用上の痛みが乖離する典型例**であり、監視設計は AFR ではなくソフト故障の側に照準を合わせるべきである。 ### 8.2 大規模 AI クラスタとデータセンターの運用報告 | 出典 | 規模 | 光関連の数値 | |---|---|---| | [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] | Huawei、350 万台超、131 リージョン、15 か月 | ハード故障 AFR 0.1341%、ソフト故障は最大 12.22 倍。予兆特徴の lift はエラーレート 9.13x が最大(§5) | | [[@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 1 万 GPU 超、7 か月 | `AOC error` 0.9%。ただし光ケーブル関連カウンタの不在により部分的に取りこぼすと原典が自認 | | [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] | ByteDance 1 万 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%) | | [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]] | 15 本番 DCN、35 万リンク、7 か月 | 12.67% のリンクが 1e-3 以上の破損損失率を持つ(輻輳起因は 0.22%)。破損損失の総量は輻輳損失と同規模。修復推薦により初回修復成功率が 50% から 80% へ改善(推薦を無視した技術者を含む実績は 58.0%) | | [[@2017__NSDI__RAIL - A Case for Redundant Arrays of Inexpensive Links in Data Center Networks]] | 20 DCN 超、30 万リンク、10 か月 | 99.9% が BER 1e-12 の受光閾値を超過し、中央値は閾値の 6 倍。減衰の中央値 0.26dB | | [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]] | Tencent 光バックボーン、6 か月 | イベントの 51.09% が一過性で、20% は 1 秒のみ。15 分粒度では全イベントの 35.72% しか正しく検知できない | | [[@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% と印字)なので、引用時に注意が要る。 --- ## 9. 横断的知見 1. 光関連の割合は、その組織が物理層をどこまで観測できているかの関数である。 Meta は `Network Switch/Cable` に丸め込み、Alibaba、Tencent、ByteDance は独立計上する。 そして独立計上した文献はいずれも観測不足を自認している([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] は光ケーブル用カウンタの不在を明記する)。 公開されている光関連の割合は、すべて下限値として扱うのが安全である。 CCGrid が示したソフト故障 12.22 倍という比率は、この下限と実態の乖離幅を初めて定量的に裏づけた。 2. 部品の AFR と運用上の痛みは乖離する。 光トランシーバーのハード故障 AFR 0.1341% は DIMM 並みに低い。 それでも運用が苦しむのは、ソフト故障がハード故障の 10 倍以上あり、かつそれが交換チケットにならないまま訓練ジョブを止めるからである。 監視の設計目標は、AFR の低減ではなくソフト故障の可視化に置くべきである。 3. 障害の主戦場はクラッシュから静かな劣化へ移った。 dual-ToR を入れた Alibaba は、リンク障害をクラッシュから性能劣化(帯域半減)へ移したと明言する。 冗長化が進むほど、光障害は可用性の問題ではなくスループットと尾部レイテンシの問題に転化する。 [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] の「冗長性が性能問題を隠す」も同じ構造である([[グレイ障害]]、[[潜在的障害]])。 4. 予兆は値の高さではなく、ばらつきと小さな初回観測に宿る。 CCGrid の lift 分析では高分散パターンが高値パターンを軒並み上回り、OpTel では一過性の弱いイベントが持続障害を予告する一方、大きな持続中断は将来を何も予告しない。 実装面では、平均値だけを保持するダウンサンプリングと、1 回のエラーをノイズと見なす運用慣行の 2 つが、最も情報量の多いシグナルを系統的に捨てている。 5. 時間粒度がそのまま検知可能性の上限を決める。 OpTel の実測では、15 秒より粗い粒度で一過性イベントが完全に消える。 SONiC の 60 秒 DOM ポーリングは I2C 制約下の合理的判断だが、DOM 単独では光イベントの半分を原理的に観測できない。 状態量を低頻度で取る DOM と、事象を積算するカウンタを役割分担させる二層構成が、最低要件になる。 6. 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]]) ![[Attachments/NIC光トランシーバーのモニタリング/figure-04-nic-vs-switch-asymmetry.png|900]] 図 4 同じ光トランシーバーの故障でも、スイッチ側では他パスへ迂回できるのに対し、NIC 側では分岐先のプレーンをまとめて失う。 この制約は、配線アーキテクチャの側から独立に確認されている。 [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]] は **Fate Sharing**(共通故障点により一緒に落ちる関係)を定義したうえで、800G NIC の各レーンを 4 つの Fabric Plane へ分散しても、その入口となる 4×200G Optics と 800G NIC 自体は単一故障点として残ることを示す。 すなわち、ファブリック側の障害局所化とホスト側の共通故障点排除は別の設計課題であり、プレーン数を増やしても後者は解けない。 トランスポート層(MRC)と物理配線層(Shuffle)という無関係な 2 つの観点が同じ結論に到達している点で、この制約の頑健性は高い([[マルチプレーンClosトポロジ]]、[[光ファイバーシャフル配線]])。 一方 [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]] は、[[光回線交換]](OCS)による動的再構成という救済機構を、物理層そのものに持ち込む設計を採る。 再構成性がない場合、1024 ホストのジョブを成立させるには各ホスト 99.9% の可用性が要るが、OCS を入れると 99% まで要件が緩和される。 光障害を検知して直すのか、トポロジで迂回するのかという設計分岐がここで立ち、後者を選べば個別モジュールの監視精度に対する要求そのものが下がる。 7. 光障害率は、部品固有の AFR ではなく施工品質と設置環境に支配される。 Aegis の建設汚染 10 倍から 20 倍と、SuperBench の熱帯 35 倍は、いずれも部品の信頼性ではなく外部要因である。 CorrOpt が特定した破損の根本原因 5 種(コネクタ汚染、ケーブルの折れ曲がりや損傷、送信機の劣化、トランシーバ不良や緩み、共有コンポーネント故障)のうち、部品固有の劣化は 1 種のみで、残りは施工、取り回し、共有部品に起因する。 監視で捕まえたい対象の大半は、部品が寿命を迎えることではなく、人が触った結果である。 8. 監視には原理的な死角がある。 CorrOpt は、反射(back reflection)によるコネクタ問題はトランシーバがそれを報告しないため、根本原因の正確な識別が常には可能でないと明記する。 CCGrid の recall 21.2% から 50.0% も、同じ現実の別表現である。 DDM と VDM は物理層の完全な観測ではなく、モジュールが公開することにした部分集合である。 監視設計はこの不完全性を前提に、修復の試行錯誤(CorrOpt では平均チケット解決に 2 日、失敗するとさらに 2 日)を織り込む必要がある。 9. 時間軸が反応型と予防型に分岐する。 [[@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]] は、顕在化後に素早く切り分ける反応型である。 CorrOpt はさらに第 3 の型、すなわちフリート全体の修復オペレーションの最適化を占め、個別モジュールの精緻な診断ではなく、どのリンクを安全に切り離せるかを解く。 --- ## 10. 学術文献の系譜 ### 10.1 データセンター光層の大規模実測 次の 4 本は同じ物理対象を異なる目的関数で扱っており、並べて読むと監視設計の選択肢を対比できる。 | 論文 | 規模 | 目的関数 | 主な観測量 | |---|---|---|---| | [[@2017__NSDI__RAIL - A Case for Redundant Arrays of Inexpensive Links in Data Center Networks]] | 20 DCN 超、30 万リンク | コスト削減(マージンを削る) | Tx/Rx パワー(SNMP 5 分) | | [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]] | 15 DCN、35 万リンク | 修復オペレーションの最適化 | Tx/Rx パワーと SNMP カウンタ(15 分) | | [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]] | Tencent 光バックボーン | 検知の高速化(粒度を上げる) | Tx/Rx パワー、SNR、Q-factor、post-FEC BER(1 秒) | | [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] | 350 万台、131 リージョン | 故障の予測(予兆を見つける) | DDM 5 種と OS メトリクス(5 分) | CorrOpt([[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]]、Zhuo、Ghobadi、Mahajan、Förster、Krishnamurthy、Anderson、SIGCOMM 2017)は、本領域の古典である。 破損損失が輻輳損失と質的に異なること、すなわち破損率はリンクごとに時間的に安定し利用率と相関しないこと(平均ピアソン相関 0.19)を示し、輻輳制御的な対処(送信レート抑制)が破損に効かないことを明らかにした。 リンク無効化の意思決定問題が NP-complete であることを 3-SAT への還元で証明し、高速チェッカと厳密最適化の 2 段階で近似する。 根本原因を Tx/Rx パワーのシグネチャで判別する診断表を構築し、70 以上のデータセンターへ推薦エンジンを展開して、初回修復成功率を 50% から 80% に改善した。 光トランシーバー監視を、個々の劣化検知ではなくフリート全体の修復オペレーション最適化として定式化した点で、いまなお参照価値が高い。 > [!warning] CorrOpt の前提は AI クラスタで崩れている > CorrOpt は解析対象をスイッチ間光リンクに限定し、サーバと ToR の間のリンクは「電気信号で短距離であり、破損時は単純にケーブル交換で済む」として明示的に除外した。 > 2017 年には妥当だったこの前提は、NIC 側が 400G から 800G の光トランシーバーになった現在では成立しない。 > 本ページが扱う NIC 側光トランシーバーこそ、CorrOpt が対象外とした領域である。 > 破損の統計的性質(時間的安定性、利用率非相関)や修復推薦の枠組みが NIC 側でもそのまま成り立つかは、誰も検証していない。 そのほかの関連研究として次の 3 本がある。 - **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)という定式化を与える。 光トランシーバーの緩慢な劣化はこの枠組みの典型例である。 ### 10.2 光レイヤの機械学習 データセンターネットワークの文脈とは別に、光通信コミュニティにはソフト障害(soft failure)検知の厚い蓄積がある。 この系譜は、データセンターや AI クラスタの文献とほとんど交差してこなかった。 CCGrid 2023 が部分的に橋を架けたが、後述のとおり空白は残る。 - **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 応用領域に分類したレビュー。 OptProphet が予測と分類を 1 つのモデルに統合したのは、このタクソノミーの 2 領域を跨ぐ設計にあたる。 - **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 マージンが薄い条件下で修理を適時に発火させる問題設定であり、§6 で述べたマージンだけが削られる状況の定式化にあたる。 - **A Data Augmented Bayesian Network for Node Failure Prediction in Optical Networks**(<https://arxiv.org/pdf/2102.03616>)。 ### 10.3 残るギャップ ここまでに挙げた文献が埋めていない領域を整理する。 - 光通信のソフト障害検知と AI クラスタ運用の接続は、部分的にとどまる。 CCGrid 2023 は DDM ベースのソフト障害を大規模データセンターで扱う点で橋渡しに成功しているが、入力は SFF-8472 世代の DDM 5 種(電圧、バイアス電流、温度、Rx/Tx パワー)と OS カウンタであり、CMIS VDM が公開する pre-FEC BER と eSNR を使っていない。 光通信側の手法(pre-FEC BER と OSNR の窓統計による 2 段検知)が入力として使う量と、CCGrid が実際に使った量は重ならない。 400G から 800G の PAM4 NIC 側光トランシーバーについて、VDM の pre-FEC BER と eSNR をフリート規模で収集して劣化を追った研究は、依然として見当たらない。 これが現時点で最も明確な空白である。 - 時間粒度に空白がある。 OpTel は 1 秒粒度が一過性イベント検知に必須であることを光バックボーンで示し、CCGrid と OptProphet はいずれも 5 分間隔の DDM で数日先の故障を予測する。 秒オーダーの事象と日オーダーの劣化の中間、すなわち分オーダーで進行する劣化を扱った研究がない。 NIC 側で毎分数件のフラップが起きる環境([[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])は、まさにこの帯域にある。 - NIC 側とスイッチ側の非対称性を明示的に扱った研究がない。 OptProphet の弱点として、光トランシーバーの物理配線やトポロジ構造(NIC 側かスイッチ側か)を明示的な特徴として組み込むかが記述されないことが挙げられる。 §9 の 6 番目で述べたとおり救済可能性が両者で決定的に異なる以上、同じモデルで同じ扱いをするのは設計として不自然である。 - 60 秒粒度の DOM とサブ秒粒度のカウンタを、実装としてどう組み合わせるか。 OpTel は 1 秒粒度の必要性を光バックボーンで示したが、そこで解いたのはデバイス CPU の処理負荷であり、NIC 側のボトルネックである I2C 帯域ではない。 push 型テレメトリの設計をどこまで移植できるかは検証されていない。 - 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)は算定根拠を示していない。 --- ## 11. 未解決の問い - CMIS VDM の pre-FEC BER と eSNR をフリート収集した実測研究が存在しない。 CCGrid は SFF-8472 世代の DDM 5 種で AFR 0.1341% と lift 9.13x を得たが、VDM 世代の観測量を使えば recall 21.2% から 50.0% という上限を突破できるのか。 VDM の pre-FEC BER は、CCGrid が最強の予兆とした「エラーレート」よりさらに上流の物理量であり、原理的には早期性が上がるはずだが、誰も測っていない。 - CorrOpt がスイッチ間に限定した前提を、NIC 側光トランシーバーで再検証する必要がある。 破損率の時間的安定性、利用率非相関、弱い空間局所性という 3 つの統計的性質は、NIC 側でも成り立つか。 共有コンポーネント(ブレイクアウトケーブル、シャッフル BOX)起因の相関障害は、Shuffle アーキテクチャの普及によりむしろ強まる可能性がある。 - CorrOpt が定式化した「切り離してよいリンクの選択」は、rail-optimized トポロジと dual-ToR とマルチプレーン構成を前提とする AI クラスタでどう変わるか。 冗長パスの前提が違えば、最適な切り離し方針も変わる。 特に NIC 側光トランシーバーは切り離す先がないため、CorrOpt の枠組みがそもそも適用できない。 - RAIL のマージン削減と光トランシーバー故障予測は、同じ物理量を逆向きに使う。 RAIL は Rx パワーの余裕をコスト削減の原資と見なし、予測型監視は同じ余裕を障害マージンと見なす。 RDMA が支配的な AI クラスタでは前者の余地が薄い(§6.1)が、両者を同一の監視基盤上でどう両立させるかは、[[光リンク過剰設計]] でも未解決のままである。 - 分散が値より効くという CCGrid の知見は、どこまで一般化できるか。 これは時系列監視の設計原則(平均だけでなく標準偏差を保持する)に直結するが、CCGrid のサンプリングは 5 分間隔である。 1 秒粒度で見たときの分散は、5 分粒度の分散と同じ意味を持つのか、それとも別の現象(ジッタ)を測ることになるのか。 - 秒オーダーと日オーダーの中間が空白である。 分オーダーで進行する劣化を扱う手法がない(§10.3)。 - NIC トランシーバのフラップを ride out できないという制約に対し、NIC 側の光設計(ポート分割の粒度、AEC や DAC への置き換え、CPO)でどこまで緩和できるか。 Shuffle アーキテクチャの Fate Sharing 分析はこの制約の上限を与えるが、緩和策の効果は定量化されていない。 --- ## 関連 - 概念: [[RDMAネットワーク監視]] / [[データセンターネットワーク信頼性]] / [[データセンター内光配線設計]] / [[光トランシーバー電力方式]] / [[光リンク過剰設計]] / [[光バックボーンネットワークテレメトリ]] / [[光ファイバーシャフル配線]] / [[マルチプレーンClosトポロジ]] / [[グレイ障害]] / [[障害予測]] / [[GPUクラスタ運用]] / [[Rail-Optimizedトポロジ]] - 実務資料: [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]] / [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] / [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]] / [[@2024__NADDOD__The Evolution of 400G, 800G, and 1.6T Optical Modules]] ## 出典 - 規格: [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) - 学術: 各節に wikilink または URL を併記