# 光トランシーバーのモニタリング NIC（ホスト側ネットワークインターフェース）に挿さる光トランシーバーを、どのメトリクスで、どの計装点から、どの時間軸で監視するか。 規格と実装のレイヤ、大規模実測の一次資料、学術文献の系譜を突き合わせて整理する。 --- ## 光トランシーバーという部品 **光トランシーバー**は、電気信号と光信号を相互に変換する着脱可能な部品である。 スイッチやNICのポートに挿し込んで使い、故障すれば挿し替えられる。 この着脱できる性質を**プラガブル**と呼ぶ。 内部は送信と受信の2系統に分かれる（図1）。 送信側は、ホストから来た電気信号を変調器で光の強弱に変え、レーザから送り出す。 受信側は、届いた光をフォトディテクタで電気に戻し、増幅器を通してホストへ渡す。 監視で読む値の大半は、この4つの部品の状態を間接的に表している。 たとえばレーザが劣化すれば、それを光らせるための電流が増える。  図1　光トランシーバーの内部構造と、各部品から取り出せる観測量。値はI2Cバス越しに読むため、読み出し頻度に物理的な上限がある。 モジュールの外形と端子の規格を**フォームファクタ**と呼ぶ。 速度が上がるにつれてSFP、QSFP、QSFP-DDやOSFPへと世代が進み、1つのモジュールが収める**レーン**（並列の信号路）の本数も増えた。 たとえば800Gbpsのモジュールは、200Gbpsのレーン4本、あるいは100Gbpsのレーン8本として終端される。 レーンごとに独立した光パワーとエラーカウンタを持つため、監視ではレーンを区別して保持できるかどうかが精度を左右する。 同じポートに挿さるものが、すべて光であるとは限らない。 - **DAC**（Direct Attach Cable）：銅線の直結ケーブル。光を使わないため、光パワーという観測量がそもそも存在しない。 - **AOC**（Active Optical Cable）：両端にトランシーバを固定した光ケーブル。片端だけを交換できない。 - 光トランシーバー：着脱可能で、任意の光ファイバと組み合わせられる。 本稿が主題とするのは、NIC側に挿さる光トランシーバーである。 スイッチ側のトランシーバと物理的には同じ部品だが、障害が起きたときに救済できるかどうかは両者で大きく異なる（後述する）。 --- ## 監視で使う用語 以降で繰り返し使う語をまとめる。 - **光パワー**：送受信する光の強さ。dBmという対数の単位で表し、0dBmが1mWにあたる。3dB下がるごとに強さが半分になる。送信側を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世代の規格に分かれる。 | 規格 | 対象 | 主な観測量 | アクセス方式 | |---|---|---|---| | SFF-8472（DDM/DOM）[1] | 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）[2] | QSFP-DD/OSFP/QSFP112 | 上記に加えModule State、レーン別Data Path State、そしてVDM | Lower/UpperページとCDB | 規格レイヤの世代差を決めるのは、CMISが導入したVDM（Versatile Diagnostics Monitoring）[3]である。 モジュールが最大256個のobservableと64個の閾値を定義でき、observableにはメディア側pre-FEC BER、eSNR（推定SNR）、エラードフレーム数、レーザ温度が含まれる。 コヒーレント向けのC-CMIS[4]は、eSNRがベンダ非依存であることを理由に、eSNRを用いたアラーム設定を推奨している。 パッケージング（SFPからQSFP、QSFP-DD/OSFP、OSFP224へ）と変調方式（NRZからPAM4、xQAMへ）の世代交代が、そのまま診断規格の世代交代に対応する。 速度帯ごとの伝送距離命名規則（KR/CR/SR/DR/FR/LR/ER/ZR）とファイバ対数の対応は、光トランシーバーベンダーNADDODの技術解説[5]に整理がある。 監視設計上は、同じクラスタ内にSFF-8472世代とCMIS世代が混在することを前提にラベルを設計する必要がある。 SFF-8472系のalarm/warning閾値はベンダ定義であり、規格が値を決めていない。 「まだアラームが出ていない」ことは「マージンがある」ことを意味しない。 Notaroらの大規模運用範囲分析[6]（Huawei Technologies Duesseldorf GmbHほか、CCGrid 2023）でも、故障間近のモジュールは健全モジュールより分布の裾が広がる形で異常を示しており、単一閾値の越境として現れるとは限らない。 --- ## LinuxとNICからの取得経路 | 取得経路 | 得られるもの | 制約 | |---|---|---| | [`ethtool -m`](https://docs.kernel.org/networking/ethtool-netlink.html)（`ETHTOOL_MSG_MODULE_EEPROM_GET`） | 温度、電圧、レーザバイアス電流、レーザ出力、平均受光レベルと各閾値 | 1回128バイトで半ページ境界をまたげない。ドライバがページ読み出しを実装していないとCMISの閾値ページとVDMに到達できない | | [`ethtool -I --show-fec`](https://man7.org/linux/man-pages/man8/ethtool.8.html) | `corrected_blocks`、`uncorrectable_blocks`、`corrected_bits`（総計とレーン別） | BERにするには時間窓と総ビット数が要る | | [`ethtool -S`（mlx5）](https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/counters.html) | `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`](https://networking-docs.nvidia.com/mftswum/422/mlxlink+utility) | 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`](https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/api/public/cmis.py)）が最良の参照になる。 `prefec_ber_curr/min/max/avg_media_input{lane}`、`esnr_media_input{lane}`、`errored_frames_*`がレーン別かつmedia/host別に並ぶ。 SONiCの`xcvrd`は挿抜をイベント駆動で扱い、DOMは60秒周期でポーリングする（[SONiC transceiver-monitor HLD](https://github.com/sonic-net/SONiC/blob/master/doc/xrcvd/transceiver-monitor-hld.md)）。 I2Cが低速であるという物理的制約に基づく設計判断である。 この60秒がどこまで妥当かは後述する。 #### 監視スタックの落とし穴 - node_exporterだけではDOMは取れない。標準の`ethtool`コレクタは`-m`を含まないため、専用エクスポータ（[wobcom/transceiver-exporter](https://github.com/wobcom/transceiver-exporter)、[Showmax/prometheus-ethtool-exporter](https://github.com/Showmax/prometheus-ethtool-exporter)）かtextfile collectorが要る。 - 外部校正モジュールの生値は物理量ではない。SFF-8472のexternally calibratedでは係数とオフセットの適用が必須で、自前パーサはもっともらしい嘘の値を出す。 - I2Cが詰まると、古い値が最新値として残る。最終更新時刻をメトリクス化して鮮度を別途監視する必要がある。 - レーン別の偏りが総計に埋もれる。8レーン中1レーンだけが限界近い状態を捕まえるには、レーンをラベルに保持する。 - 銅DACには光パワーが存在しない。`Identifier`や`cable_type`でラベルを分離しないと、偽陽性か見落としのどちらかになる。 - VFからは`*_phy`系もモジュール情報も取れない。ベアメタルのPF上で動かす前提を明示する必要がある。 - 平均値だけを保持すると、最も効く特徴を捨てることになる。後述するとおり、故障との関連度が最も高い特徴群は値そのものではなく時間変動の大きさである。ダウンサンプリング時に平均だけ残す設計は、この情報を系統的に破棄する。 --- ## 故障を予告する観測量 どの観測量が実際に故障を予告するのかは、長らく大規模な実測を欠いていた。 Notaroらの研究[6]がこれを定量的に埋めた。 350万台超、131リージョン、15か月（405万デバイス年）のDDMとOSレベルメトリクスを、時系列自己相関、AFR推定、運用範囲比較、パターンlift、機械学習予測という5つの独立な軸で解析している。 光トランシーバー信頼性の大規模研究としては初とされる。 #### 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.00ppsであるのに対し、故障モジュールでは最大0.1325ppsに達する。 すなわち、非ゼロのエラーレートを一度でも観測すること自体が予兆である。 第二に、高分散が高値を上回る。 温度、バイアス電流、Rxパワー、スループットのいずれでも、値そのものの高さより時間変動の大きさのほうがliftが高い。 故障モジュールのバイアス電流の時間変動は健全モジュール比で52%大きく（0.5342mAと0.3508mA）、温度は75%大きい（1.516℃）。 前節末で挙げた監視スタックの落とし穴は、この結果に直結する。 第三に、パケットロスは使えない。 CRCエラーに起因しないパケットロス（バッファ解放など）が支配的なため、光トランシーバー故障とはほぼ相関しない。 逆に言えば、上位層のロス監視は光トランシーバー監視の代替にならない。 #### バイアス電流の物理的機序 バイアス電流の高値と高分散が効くことには、物理的な裏づけがある。 レーザは老朽化するほど、同じ光出力を維持するのに多くのバイアス電流を要する。 したがってバイアス電流はレーザ劣化の直接的な代理変数であり、機械学習が見つけた相関ではなく因果に近い。 DDM属性の平均値が80パーセンタイルを超えるモジュールでは、バイアス電流、温度、Rx/Txパワーで AFR が最大8.46倍に増加する。 #### エラーの再発性 エラーレート時系列の自己相関を、ホワイトノイズおよび異なる速度のunit ramp信号と比較すると、ラグ24時間以内で自己相関が急激に増加する。 一度CRCエラーが出たモジュールは、24時間以内に再発する確率が高い。 これは「1回のエラーはノイズとして無視する」という運用慣行への直接的な反証であり、初回観測の時点でチケットを起こす根拠になる。 #### 予測モデルの精度と再現率 | モデル | 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警告閾値情報を未活用の残り代として挙げている。 #### OptProphetの内部構成 Xiaらによる**OptProphet**[7]（Nankai UniversityとHuawei Technologies、APNET 2025）は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日）にアラームを発火する。 両論文はいずれもHuawei Technologiesのデータに基づき、5分間隔のDDMを入力とする。 前者（CCGrid）はどの特徴が効くかを5軸の統計分析で明らかにし、後者（OptProphet）はその特徴をどう組み合わせて予測精度を上げるかを深層学習で解く。 2年の間隔をおいた同じ系譜の前半と後半として読める。 CCGridのrecall 21.2〜50.0%に対しOptProphetのD1 Task#1のRecall 0.871は大きな改善だが、両者は故障定義もデータセットも異なるため、直接比較はできない。 --- ## pre-FEC BERとマージンの分布 400G PAM4のKP4 FEC（RS(544,514)）は、pre-FEC BERおよそ2.4e-4まで訂正する。 この限界に近づいてもパケットは流れ続け、post-FECは綺麗なまま、ダッシュボードは緑のままマージンだけが削られる。 そこに汚れたコネクタ、温度変動、クロストークが1つ加わるとFECが破綻し、訂正不能コードワードがアプリケーション層に到達する。 次の図の崖の形が、この節の議論のほぼすべてを説明する。  図2　pre-FEC BERとpost-FEC BERの関係。訂正限界の手前ではpost-FECがほぼ変化しないため、劣化の進行が上位層からは見えない。 したがってアラームは、post-FECの訂正不能カウンタではなく、pre-FEC BERのトレンドとレーン別の偏り、およびeSNRに置く。 これはC-CMIS[4]がeSNRをアラーム指標として推奨する思想と整合する。 JANOG58のRack-Scale GPUサーバ運用報告[8]（ソフトバンク株式会社）も、Pre-FEC/Post-FEC BERとFEC Symbol Error Binsを用いた光リンク劣化の切り分け手順を示している。 #### RAILが測ったマージンの分布 Zhuoらによる**RAIL**[9]（University of Washington / Microsoft Research、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個の仮想トポロジを構築し、アプリケーションの損失耐性に応じて割り当てる。 RAILは、アプリケーションごとに損失耐性が多様であることを前提にし、RDMAは最も厳しい第1クラスに置く（著者は脚注で、RDMAはBER 1e-10で十分と述べる）。 ところがAI訓練クラスタのバックエンドネットワークは、ほぼ全トラフィックがRDMAであり、多様性が消える。 マージンをコスト削減に回す余地はその分だけ小さく、逆に障害マージンとして温存する判断が合理的になりやすい。 #### FEC世代で変わる要求水準 100Gbps以降のトランシーバはFECを搭載するため、pre-FEC BERの要求水準が1e-12から5e-5へ7桁緩和される。 すなわちFEC世代の光リンクでは、BER 1e-12という古い基準をそのまま持ち込むと、実際には十分に余裕のあるリンクを不良と判定する。 逆に、FECのマージンを食い潰した状態はpost-FECには出ないため、冒頭で述べた静かな劣化の問題はFEC世代でこそ深刻になる。 FECの導入は問題を解決したのではなく、観測点をpre-FEC側へ移動させたと理解するのが正しい。 #### 光パワーの物理的な崖 Miaoらによる**OpTel**[10]（Tencent、Tsinghua University、UC Santa Barbara、NSDI 2022）は、Tx電力を固定してファイバの伝送損失を段階的に増やす実測を行っている。 そこから、`Rx power(dBm) = Tx power(dBm) − transmission loss(dB)`という線形関係と、−10dBmを上回れば正常、−19dBmを下回ると中断、その間が劣化という分類の物理的根拠が得られる。 閾値をまたぐと、FEC訂正能力の限界からpost-FEC BERとCRCエラーが非線形に急増する。 線形に劣化する物理量（Rxパワー）を監視していれば崖の手前で捕まえられるが、非線形に跳ねる上位層指標（CRCエラー）を監視していると崖を越えた後にしか気づけない。 計装点選択の原則がここに現れる。 --- ## 一過性イベントと収集粒度 SONiCのDOM 60秒ポーリングは、劣化の早期検知に十分だろうか。 OpTel[10]がこれに答えている。 対象は光バックボーンネットワーク（OTU、OLS、アンプ、OSC）であってNICではないが、時間粒度と検知可能性の関係は移植可能な知見である。 #### 光イベントの継続時間分布 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秒未満で終わる。 #### 収集粒度と検知率 - 1秒粒度を基準にすると、15秒、1分、15分粒度のシステムは、それぞれ25%、39%、71%少なくしかイベントを検知できない。 - 15秒より粗い粒度では、一過性イベントを一切検知できない。 - 15分粒度の既存システムは、全イベントの35.72%しか正しく検知せず、41.40%は未検知、22.88%は誤検知（持続イベントへの誤分類など）である。 図3は、この関係を継続時間の異なる5つのイベントで示したものである。 粒度を粗くすると、短いイベントから順に観測から落ちる。  図3　イベントの継続時間と収集粒度の関係。サンプリング周期より短いイベントは、原理的に観測できない。 SONiC `xcvrd`の60秒周期DOMポーリングは、I2Cの低速性に基づく合理的な設計判断である。 だがOpTelの測定を素直に当てはめれば、継続10秒未満のイベント（全体の50%超）は構造的に見えない。 一方`link_down_events_phy`のようなカウンタはサブ秒の事象を積算値として保持するため、60秒粒度のDOM（状態量）とイベント駆動または積算のカウンタ（事象）を組み合わせる以外に手がない。 DOMだけを見ている監視は、フラップが毎分数件のオーダーで起きる環境[11]（OpenAI・Microsoft・AMD・Broadcom・NVIDIA共著、arXiv 2026）では原理的に取りこぼす。 #### 一過性イベントと持続障害の時間相関 E-D（一過性劣化）イベントの後、5秒の時間窓ではP-I（持続中断）の発生確率がおよそ20%、1分の窓ではおよそ40%に上昇する。 逆に、過去のP-I事象自体は将来の持続イベントをほとんど予測しない（memoryless）。 すなわち予兆は、短くて弱いイベントの側にあり、大きくて目立つイベントの側にはない。 これは前節のエラー再発性と同型の構造であり、時間スケールこそ違え、小さな初回観測を捨てないという同じ運用原則に帰着する。 #### 高頻度収集のコスト 高頻度収集が現実的かどうかは、収集アーキテクチャに依存する。 収集頻度を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の転送時間はオフロードできない。 --- ## 大規模実測が示す故障率と障害内訳 #### 光トランシーバー単体の故障率 光トランシーバー単体のAFRを実測で公開した一次資料は少ない。 Notaroらの研究[6]が、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倍）に近い。 AFRだけを見れば、光トランシーバーはDIMM並みに壊れにくい。 にもかかわらず後述の運用報告で光が障害内訳の上位に来るのは、台数が桁違いに多いこと、ソフト故障がハード故障の10倍以上の頻度で起きること、ソフト故障は交換チケットにならないため部品AFRには計上されないが訓練ジョブは止めることの3つによる。 **部品の信頼性指標と運用上の痛みが乖離する典型例**であり、監視設計はAFRではなくソフト故障の側に照準を合わせるべきである。 #### 大規模AIクラスタとデータセンターの運用報告 | 出典 | 規模 | 光関連の数値 | |---|---|---| | Notaroらの研究[6] | Huawei、350万台超、131リージョン、15か月 | ハード故障AFR 0.1341%、ソフト故障は最大12.22倍。予兆特徴のliftはエラーレート9.13xが最大 | | Dongらによる**Aegis**[12]（Alibaba Cloud、NSDI 2025） | Alibaba本番AI訓練クラウド | `Optic module & fiber error` 6.7%。光はDAC比1.2倍から10倍の障害率。納品時の汚染で通常の10倍から20倍（徹底清掃を数十回）。リンク修理チケット週数十件、累計O(10K)件のホットフィックス | | Qianらによる**Alibaba HPN**[13]（Alibaba Cloud、SIGCOMM 2024） | 15K GPU目標 | NIC-ToRリンクが月0.057%故障、ToRスイッチ0.051%/月。訓練ジョブ1本が月1回から2回クラッシュ。リンクフラップ5Kから60K件/日 | | Mengらによる**Astral**[14]（Tencent、SIGCOMM 2025） | Tencent 512K GPU | `Optical Fiber` 7%、`Link Flap` 2%、`Wire conn.` 3%。fail-slow 13%、fail-hang 17% | | Kokolisらによる**Revisiting Reliability**[15]（Meta、HPCA 2025） | Meta RSC-1/2計28K GPU | レモンノード40台の根本原因のうち`Optics` 2.6%（母数が小さい） | | Dengらによる**Minder**[16]（ByteDance / Tsinghua University / Harvard University、NSDI 2025） | ByteDance 1万GPU超、7か月 | `AOC error` 0.9%。ただし光ケーブル関連カウンタの不在により部分的に取りこぼすと原典が自認 | | Jiangらによる**MegaScale**[17]（ByteDance / Peking University、NSDI 2024） | ByteDance 1万GPU超 | 割合は原典に数値なし。フラップのdown-up間隔は数秒。根本原因はNIC、AOCケーブル、スイッチ間のリンク品質で、信号強度の品質管理により改善 | | Xiongらによる**SuperBench**[18]（Microsoft Research、USENIX ATC 2024） | Azure A100 | MTBI 17.5時間。BER > 1e-12の欠陥InfiniBandリンクが熱帯地域DCで35倍 | | Liuらによる**R-Pingmesh**[19]（BUPT / Purple Mountain Laboratories / Douyin Vision、SIGCOMM 2024） | ByteDance本番RoCE | 割合は原典に数値なし。光ファイバの損傷と経年劣化、光トランシーバー内の埃がパケット破損を起こし、スイッチとRNICでドロップすると定性記述 | | Araujo、Handleyらの研究[11]（OpenAI・Microsoft・AMD・Broadcom・NVIDIA共著、arXiv 2026） | OpenAIとMicrosoft、50K / 75K GPUの本番事前訓練 | T0-T1リンクフラップが常時毎分数件。T0スイッチの光トランシーバー1個のグリッチで4リンク同時フラップが起き、1分間スループットがおよそ25%低下する（ジョブは落ちず即回復）。NIC側800G光トランシーバーのフラップは全ポート喪失で救済不能 | | Zuらによる**TPUv4**[20]（Google、NSDI 2024） | 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%） | | Zhuoらによる**CorrOpt**[21]（University of Washington / Microsoft Research、SIGCOMM 2017） | 15本番DCN、35万リンク、7か月 | 12.67%のリンクが1e-3以上の破損損失率を持つ（輻輳起因は0.22%）。破損損失の総量は輻輳損失と同規模。修復推薦により初回修復成功率が50%から80%へ改善（推薦を無視した技術者を含む実績は58.0%） | | RAIL[9] | 20DCN超、30万リンク、10か月 | 99.9%がBER 1e-12の受光閾値を超過し、中央値は閾値の6倍。減衰の中央値0.26dB | | OpTel[10] | Tencent光バックボーン、6か月 | イベントの51.09%が一過性で、20%は1秒のみ。15分粒度では全イベントの35.72%しか正しく検知できない | | Mezaらの調査[22]（Facebook、IMC 2018） | Facebookバックボーン光ファイバ、7年 | ベンダの90%でリンク障害は5,709時間に1回未満（広域バックボーンであり、クラスタ内光トランシーバーではない） | Metaのモデル開発側報告は光を独立計上しない。 Llama 3[23]（Meta、16K GPU、54日、419件の予期せぬ中断、`Network Switch/Cable` 8.4%）も、その後継のHSDP報告[24]（Meta Platforms、arXiv 2026、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%と印字）なので、引用時に注意が要る。 --- ## 横断的知見 1. 光関連の割合は、その組織が物理層をどこまで観測できているかの関数である。Metaは`Network Switch/Cable`に丸め込み、Alibaba、Tencent、ByteDanceは独立計上する。そして独立計上した文献はいずれも観測不足を自認している（Minder[16]は光ケーブル用カウンタの不在を明記する）。公開されている光関連の割合は、すべて下限値として扱うのが安全である。CCGridが示したソフト故障12.22倍という比率は、この下限と実態の乖離幅を初めて定量的に裏づけた。 2. 部品のAFRと運用上の痛みは乖離する。光トランシーバーのハード故障AFR 0.1341%はDIMM並みに低い。それでも運用が苦しむのは、ソフト故障がハード故障の10倍以上あり、かつそれが交換チケットにならないまま訓練ジョブを止めるからである。監視の設計目標は、AFRの低減ではなくソフト故障の可視化に置くべきである。 3. 障害の主戦場はクラッシュから静かな劣化へ移った。dual-ToRを入れたAlibabaは、リンク障害をクラッシュから性能劣化（帯域半減）へ移したと明言する。冗長化が進むほど、光障害は可用性の問題ではなくスループットと尾部レイテンシの問題に転化する。SuperBench[18]の「冗長性が性能問題を隠す」も同じ構造である（グレイ障害[25]と潜在的障害[26]という2つの概念が指す事態である）。 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層で見る整理[11]において、NIC側の物理部品層だけがアーキテクチャによる救済を受けられない。  図4　同じ光トランシーバーの故障でも、スイッチ側では他パスへ迂回できるのに対し、NIC側では分岐先のプレーンをまとめて失う。 この制約は、配線アーキテクチャの側から独立に確認されている。 KobayashiによるSpeakerDeck資料[27]は**Fate Sharing**（共通故障点により一緒に落ちる関係）を定義したうえで、800G NICの各レーンを4つのFabric Planeへ分散しても、その入口となる4×200G Opticsと800G NIC自体は単一故障点として残ることを示す。 JANOG58の光配線実践知[28]（さくらインターネット株式会社、TWCCパートナーズ合同会社）も同じ構造を報告する。 すなわち、ファブリック側の障害局所化とホスト側の共通故障点排除は別の設計課題であり、プレーン数を増やしても後者は解けない。 トランスポート層（MRC）と物理配線層（Shuffle）という無関係な2つの観点が同じ結論に到達している点で、この制約の頑健性は高い。 一方GoogleのTPUv4報告[20]は、光回線交換（OCS）による動的再構成という救済機構を、物理層そのものに持ち込む設計を採る。 再構成性がない場合、1024ホストのジョブを成立させるには各ホスト99.9%の可用性が要るが、OCSを入れると99%まで要件が緩和される。 光障害を検知して直すのか、トポロジで迂回するのかという設計分岐がここで立ち、後者を選べば個別モジュールの監視精度に対する要求そのものが下がる。 7. 光障害率は、部品固有のAFRではなく施工品質と設置環境に支配される。Aegisの建設汚染10倍から20倍と、SuperBenchの熱帯35倍は、いずれも部品の信頼性ではなく外部要因である。CorrOpt[21]が特定した破損の根本原因5種（コネクタ汚染、ケーブルの折れ曲がりや損傷、送信機の劣化、トランシーバ不良や緩み、共有コンポーネント故障）のうち、部品固有の劣化は1種のみで、残りは施工、取り回し、共有部品に起因する。監視で捕まえたい対象の大半は、部品が寿命を迎えることではなく、人が触った結果である。 8. 監視には原理的な死角がある。CorrOptは、反射（back reflection）によるコネクタ問題はトランシーバがそれを報告しないため、根本原因の正確な識別が常には可能でないと明記する。CCGridのrecall 21.2%から50.0%も、同じ現実の別表現である。DDMとVDMは物理層の完全な観測ではなく、モジュールが公開することにした部分集合である。監視設計はこの不完全性を前提に、修復の試行錯誤(CorrOptでは平均チケット解決に2日、失敗するとさらに2日)を織り込む必要がある。 9. 時間軸が反応型と予防型に分岐する。OptProphet[7]は、光トランシーバー故障を平均1.11日前に予測する予防型である（予測F1 0.884、分類F1 0.855）。対してHawkeye[29]（Tsinghua University / Beihang University / Infrawaves、SIGCOMM 2025）やSkeletonHunter[30]（Tsinghua University / Alibaba Cloud / UIUC、SIGCOMM 2025）は、顕在化後に素早く切り分ける反応型である。CorrOptはさらに第3の型、すなわちフリート全体の修復オペレーションの最適化を占め、個別モジュールの精緻な診断ではなく、どのリンクを安全に切り離せるかを解く。 --- ## 学術文献の系譜 #### データセンター光層の大規模実測 次の4本は同じ物理対象を異なる目的関数で扱っており、並べて読むと監視設計の選択肢を対比できる。 | 論文 | 規模 | 目的関数 | 主な観測量 | |---|---|---|---| | RAIL[9] | 20DCN超、30万リンク | コスト削減（マージンを削る） | Tx/Rxパワー（SNMP 5分） | | CorrOpt[21] | 15DCN、35万リンク | 修復オペレーションの最適化 | Tx/Rxパワーと SNMPカウンタ（15分） | | OpTel[10] | Tencent光バックボーン | 検知の高速化（粒度を上げる） | Tx/Rxパワー、SNR、Q-factor、post-FEC BER（1秒） | | CCGrid[6] | 350万台、131リージョン | 故障の予測（予兆を見つける） | DDM 5種とOSメトリクス（5分） | CorrOpt[21]（Zhuo、Ghobadi、Mahajan、Förster、Krishnamurthy、Anderson、University of Washington / Microsoft Research、SIGCOMM 2017）は、本領域の古典である。 破損損失が輻輳損失と質的に異なること、すなわち破損率はリンクごとに時間的に安定し利用率と相関しないこと（平均ピアソン相関0.19）を示し、輻輳制御的な対処（送信レート抑制）が破損に効かないことを明らかにした。 リンク無効化の意思決定問題がNP-completeであることを3-SATへの還元で証明し、高速チェッカと厳密最適化の2段階で近似する。 根本原因をTx/Rxパワーのシグネチャで判別する診断表を構築し、70以上のデータセンターへ推薦エンジンを展開して、初回修復成功率を50%から80%に改善した。 光トランシーバー監視を、個々の劣化検知ではなくフリート全体の修復オペレーション最適化として定式化した点で、いまなお参照価値が高い。 CorrOptは解析対象をスイッチ間光リンクに限定し、サーバとToRの間のリンクは「電気信号で短距離であり、破損時は単純にケーブル交換で済む」として明示的に除外した。 2017年には妥当だったこの前提は、NIC側が400Gから800Gの光トランシーバーになった現在では成立しない。 本稿が扱うNIC側光トランシーバーこそ、CorrOptが対象外とした領域である。 破損の統計的性質（時間的安定性、利用率非相関）や修復推薦の枠組みがNIC側でもそのまま成り立つかは、誰も検証していない。 そのほかの関連研究として次の3本がある。 - Arzaniらによる**007: Democratically Finding the Cause of Packet Drops**[31]（Microsoft / University of Pennsylvania、NSDI 2018）。TCP再送を投票に見立ててドロップ箇所を特定する。 - Costa Molero、Vissicchio、Vanbeverによる**FANcY: FAst in-network GraY failure detection for ISPs**[32]（ETH Zurich / UCL、SIGCOMM 2022）。既存の監視ツールで検知できない、故障ハードウェアによる長時間のパケットドロップをデータプレーンで検知して箇所特定する。 - Huangらによる**Gray Failure: The Achilles' Heel of Cloud-Scale Systems**[25]（Microsoft Research / Johns Hopkins University、HotOS 2017）。差分観測可能性（differential observability）という定式化を与える。光トランシーバーの緩慢な劣化はこの枠組みの典型例である。 #### 光レイヤの機械学習 データセンターネットワークの文脈とは別に、光通信コミュニティにはソフト障害（soft failure）検知の厚い蓄積がある。 この系譜は、データセンターやAIクラスタの文献とほとんど交差してこなかった。 CCGrid[6]が部分的に橋を架けたが、以下のとおり空白は残る。 - Musumeci、Rottondi、Nagらによる**An Overview on Application of Machine Learning Techniques in Optical Networks**[33]（Politecnico di Milanoほか、IEEE Communications Surveys & Tutorials 21(2):1383-1408、2019）。光通信と光ネットワークへの機械学習応用の基本サーベイ。 - Wang、Zhang、Chen、Yang、Zhang、Lauによる**A Review of Machine Learning-based Failure Management in Optical Networks**[34]（Beijing University of Posts and Telecommunicationsほか、2022）。障害管理をアラーム解析、故障予測、故障検知、故障箇所特定、故障種別同定の5応用領域に分類したレビュー。OptProphet[7]が予測と分類を1つのモデルに統合したのは、このタクソノミーの2領域を跨ぐ設計にあたる。 - Shahkarami、Musumeci、Cugini、Tornatoreによる**Machine-Learning-Based Soft-Failure Detection and Identification in Optical Networks**[35]（Politecnico di Milano / CNIT、OFC 2018, M3A.5）。 - San Martín、Leiva、Melo、Saavedraによる**Two-stage machine learning for modulation-robust soft-failure detection and localization in optical fiber transmission links**[36]（Universidad de Concepciónほか、JOCN 18(7):674）。段1で受信pre-FEC BERとOSNRの窓統計から異常を検知する。NIC側VDMが公開するobservableとほぼ同じ入力を使う点で、実装との接続が具体的に見える。 - Behera、Panayiotou、Ellinasによる**Modeling Soft-Failure Evolution for Triggering Timely Repair with Low QoT Margins**[37]（University of Cyprus）。QoTマージンが薄い条件下で修理を適時に発火させる問題設定であり、前節で述べたマージンだけが削られる状況の定式化にあたる。 - Das、Imteyaz、Bapat、Dasによる**A Data Augmented Bayesian Network for Node Failure Prediction in Optical Networks**[38]（IIIT Bangaloreほか）。 #### 残るギャップ ここまでに挙げた文献が埋めていない領域を整理する。 - 光通信のソフト障害検知とAIクラスタ運用の接続は、部分的にとどまる。CCGrid[6]はDDMベースのソフト障害を大規模データセンターで扱う点で橋渡しに成功しているが、入力はSFF-8472世代のDDM5種（電圧、バイアス電流、温度、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[10]は1秒粒度が一過性イベント検知に必須であることを光バックボーンで示し、CCGrid[6]とOptProphet[7]はいずれも5分間隔のDDMで数日先の故障を予測する。秒オーダーの事象と日オーダーの劣化の中間、すなわち分オーダーで進行する劣化を扱った研究がない。NIC側で毎分数件のフラップが起きる環境[11]は、まさにこの帯域にある。 - NIC側とスイッチ側の非対称性を明示的に扱った研究がない。OptProphet[7]の弱点として、光トランシーバーの物理配線やトポロジ構造（NIC側かスイッチ側か）を明示的な特徴として組み込むかが記述されないことが挙げられる。救済可能性が両者で決定的に異なる以上、同じモデルで同じ扱いをするのは設計として不自然である。 - 60秒粒度のDOMとサブ秒粒度のカウンタを、実装としてどう組み合わせるか。OpTel[10]は1秒粒度の必要性を光バックボーンで示したが、そこで解いたのはデバイスCPUの処理負荷であり、NIC側のボトルネックであるI2C帯域ではない。push型テレメトリの設計をどこまで移植できるかは検証されていない。 - Redfish `PortMetrics`のトランシーバ関連プロパティ、OpenBMCのDOM公開実装、Meta FBOSS `qsfp_service`の一次ドキュメントは未確認である[^unreliable-numbers]。 --- ## 未解決の問い - CMIS VDMのpre-FEC BERとeSNRをフリート収集した実測研究が存在しない。CCGrid[6]はSFF-8472世代のDDM5種でAFR 0.1341%とlift 9.13xを得たが、VDM世代の観測量を使えばrecall 21.2%から50.0%という上限を突破できるのか。VDMのpre-FEC BERは、CCGridが最強の予兆とした「エラーレート」よりさらに上流の物理量であり、原理的には早期性が上がるはずだが、誰も測っていない。 - CorrOpt[21]がスイッチ間に限定した前提を、NIC側光トランシーバーで再検証する必要がある。破損率の時間的安定性、利用率非相関、弱い空間局所性という3つの統計的性質は、NIC側でも成り立つか。共有コンポーネント（ブレイクアウトケーブル、シャッフルBOX）起因の相関障害は、シャッフル配線アーキテクチャの普及によりむしろ強まる可能性がある。 - CorrOpt[21]が定式化した「切り離してよいリンクの選択」は、rail-optimizedトポロジとdual-ToRとマルチプレーン構成を前提とするAIクラスタでどう変わるか。冗長パスの前提が違えば、最適な切り離し方針も変わる。特にNIC側光トランシーバーは切り離す先がないため、CorrOptの枠組みがそもそも適用できない。 - RAIL[9]のマージン削減と光トランシーバー故障予測は、同じ物理量を逆向きに使う。RAILはRxパワーの余裕をコスト削減の原資と見なし、予測型監視は同じ余裕を障害マージンと見なす。RDMAが支配的なAIクラスタでは前者の余地が薄いが、両者を同一の監視基盤上でどう両立させるかは未解決のままである。 - 分散が値より効くというCCGrid[6]の知見は、どこまで一般化できるか。これは時系列監視の設計原則（平均だけでなく標準偏差を保持する）に直結するが、CCGridのサンプリングは5分間隔である。1秒粒度で見たときの分散は、5分粒度の分散と同じ意味を持つのか、それとも別の現象（ジッタ）を測ることになるのか。 - 秒オーダーと日オーダーの中間が空白である。分オーダーで進行する劣化を扱う手法がない。 - NICトランシーバのフラップをride outできないという制約に対し、NIC側の光設計（ポート分割の粒度、AECやDACへの置き換え、CPO）でどこまで緩和できるか。Fate Sharing分析[27][28]はこの制約の上限を与えるが、緩和策の効果は定量化されていない。 --- ## 付録 ### A. 用語集 - **光トランシーバー**：電気信号と光信号を相互に変換する着脱可能な部品 - **プラガブル**：着脱可能である性質 - **フォームファクタ**：モジュールの外形と端子の規格（SFP、QSFP、QSFP-DD、OSFPなど） - **レーン**：1つのモジュールが収める並列の信号路 - **DAC**（Direct Attach Cable）：銅線の直結ケーブル。光パワーという観測量が存在しない - **AOC**（Active Optical Cable）：両端にトランシーバを固定した光ケーブル - **光パワー**：送受信する光の強さ（dBm）。送信側をTxパワー、受信側をRxパワーと呼ぶ - **バイアス電流**：レーザを発光させるために流す直流電流。レーザの老朽化とともに増加する - **BER**（Bit Error Rate、ビット誤り率）：受信ビットのうち誤っていた割合 - **FEC**（Forward Error Correction、前方誤り訂正）：冗長ビットで誤りを訂正する仕組み - **pre-FEC BERとpost-FEC BER**：訂正前と訂正後の誤り率。訂正能力の範囲内ではpre-FEC BERが悪化してもpost-FEC BERはゼロのままである - **eSNR**：モジュールが自ら推定する信号対雑音比 - **DDM**（Digital Diagnostic Monitoring、DOM）：モジュールが自身の状態量を内部に書き出し、外部から読めるようにする仕組み - **VDM**（Versatile Diagnostics Monitoring）：CMISが導入した拡張診断機能。pre-FEC BER、eSNRなど最大256個のobservableを定義できる - **I2C**：モジュールとホストをつなぐ低速なシリアルバス - **リンクフラップ**：リンクが短時間落ちて、すぐ復帰する現象 - **AFR**（annualized failure rate、年次故障率）：1年あたりに故障する部品の割合。MTBF（平均故障間隔）は同じ情報を時間の側から表す - **グレイ障害**：動いているように見えるのに性能だけが落ちている状態 - **Fate Sharing**：共通故障点により複数の構成要素が一緒に落ちる関係 - **光回線交換**（OCS、Optical Circuit Switching）：物理層で動的に光経路を再構成する仕組み ### B. 参考文献 [1] SFF Committee. "SFF-8472: Diagnostic Monitoring Interface for Optical Transceivers." Rev 12.3. https://modultech.ru/wp-content/uploads/2019/09/SFF-8472.pdf [2] Optical Internetworking Forum (OIF). "Common Management Interface Specification (CMIS)." Rev 5.3. https://www.oiforum.com/wp-content/uploads/OIF-CMIS-05.3.pdf [3] Optical Internetworking Forum (OIF). "Versatile Diagnostics Monitoring (VDM) Webinar." https://www.oiforum.com/wp-content/uploads/VDM_CMIS_Webinar.pdf [4] Optical Internetworking Forum (OIF). "Coherent Common Management Interface Specification (C-CMIS)." Rev 1.3. https://www.oiforum.com/wp-content/uploads/OIF-C-CMIS-01.3.pdf [5] NADDOD. "The Evolution of 400G, 800G, and 1.6T Optical Modules." NADDOD Blog, 2024. https://www.naddod.com/blog/the-evolution-of-400g-800g-and-1-6t-optical-modules [6] Paolo Notaro, Chenghao Yu, Vahid Haeri, Diogo Cardoso, Michael Gerndt ほか. "An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data." *CCGrid 2023*, IEEE, 2023. https://doi.org/10.1109/CCGrid57682.2023.00011 [7] Sibo Xia, Yifan Ma, Peng Kuang, Shenglin Zhang, Xie ほか. "Forewarned is Forearmed: Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters." *APNET 2025*, ACM, 2025. https://dl.acm.org/doi/abs/10.1145/3735358.3737815 [8] 内田泰広、張朝程（ソフトバンク株式会社）. "Rack-Scale GPUサーバーのNW設計と運用までの苦悩." JANOG58, 2026. https://www.janog.gr.jp/meeting/janog58/pr-rack-scale-gpu/ [9] Danyang Zhuo, Monia Ghobadi, Ratul Mahajan, Amar Phanishayee, Yibo Zou, Hao Guan, Arvind Krishnamurthy, Thomas Anderson. "RAIL: A Case for Redundant Arrays of Inexpensive Links in Data Center Networks." *NSDI 2017*, USENIX, 2017. https://www.usenix.org/conference/nsdi17/technical-sessions/presentation/zhuo [10] Congcong Miao ほか（Tencent, Tsinghua University, UC Santa Barbara）. "Detecting Ephemeral Optical Events with OpTel." *NSDI 2022*, USENIX, 2022. https://www.usenix.org/conference/nsdi22/presentation/miao [11] Joao Araujo, Mark Handley ほか（OpenAI・Microsoft・AMD・Broadcom・NVIDIA共著、58名）. "Resilient AI Supercomputer Networking using MRC and SRv6." arXiv:2605.04333, 2026. https://arxiv.org/abs/2605.04333 [12] Jianbo Dong, Kun Qian, Pengcheng Zhang ほか（Alibaba Cloud）. "Evolution of Aegis: Fault Diagnosis for AI Model Training Service in Production." *NSDI 2025*, USENIX, 2025. https://www.usenix.org/conference/nsdi25/presentation/dong [13] Kun Qian ほか（Alibaba Cloud）. "Alibaba HPN: A Data Center Network for Large Language Model Training." *SIGCOMM 2024*, ACM, 2024. https://doi.org/10.1145/3651890.3672265 [14] Qingkai Meng, Hao Zheng, Zhenhui Zhang ほか（Tencent）. "Astral: A Datacenter Infrastructure for Large Language Model Training at Scale." *SIGCOMM 2025*, ACM, 2025. https://dl.acm.org/doi/10.1145/3718958.3750521 [15] Apostolos Kokolis ほか（Meta）. "Revisiting Reliability in Large-Scale Machine Learning Research Clusters." *HPCA 2025*, IEEE, 2025. https://ieeexplore.ieee.org/document/10946752 [16] Yangtao Deng, Xiang Shi, Zhuo Jiang ほか（ByteDance / Tsinghua University / Harvard University）. "Minder: Faulty Machine Detection for Large-scale Distributed Model Training." *NSDI 2025*, USENIX, 2025. https://www.usenix.org/conference/nsdi25/presentation/deng [17] Ziheng Jiang, Haibin Lin, Yinmin Zhong ほか（ByteDance / Peking University）. "MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs." *NSDI 2024*, USENIX, 2024. https://www.usenix.org/conference/nsdi24/presentation/jiang-ziheng [18] Yifan Xiong, Yuting Jiang, Ziyue Yang, Lei Qu ほか（Microsoft Research / Microsoft）. "SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation." *USENIX ATC 2024*, USENIX, 2024. https://www.usenix.org/conference/atc24/presentation/xiong [19] Kefei Liu, Zhuo Jiang, Jiao Zhang ほか（BUPT / Purple Mountain Laboratories / Douyin Vision）. "R-Pingmesh: A Service-Aware RoCE Network Monitoring and Diagnostic System." *SIGCOMM 2024*, ACM, 2024. https://doi.org/10.1145/3651890.3672264 [20] Yazhou Zu ほか（Google）. "Resiliency at Scale: Managing Google's TPUv4 Machine Learning Supercomputer." *NSDI 2024*, USENIX, 2024. https://www.usenix.org/system/files/nsdi24-zu.pdf [21] Danyang Zhuo, Monia Ghobadi, Ratul Mahajan, Klaus-Tycho Förster, Arvind Krishnamurthy, Thomas Anderson. "Understanding and Mitigating Packet Corruption in Data Center Networks." *SIGCOMM 2017*, ACM, 2017. https://doi.org/10.1145/3098822.3098849 [22] Justin Meza, Tianyin Xu, Kaushik Veeraraghavan, Onur Mutlu（Facebook）. "A Large Scale Study of Data Center Network Reliability." *IMC 2018*, ACM, 2018. https://people.inf.ethz.ch/omutlu/pub/data-center-network-errors-at-facebook_imc18.pdf [23] Meta AI. "The Llama 3 Herd of Models." arXiv:2407.21783, 2024. https://arxiv.org/abs/2407.21783 [24] Omkar Salpekar ほか（Meta Platforms）. "Training LLMs with Fault Tolerant HSDP on 100,000 GPUs." arXiv:2602.00277, 2026. https://arxiv.org/abs/2602.00277 [25] Peng Huang, Chuanxiong Guo, Lidong Zhou, Jacob R. Lorch ほか（Microsoft Research / Johns Hopkins University）. "Gray Failure: The Achilles' Heel of Cloud-Scale Systems." *HotOS 2017*, ACM, 2017. https://doi.org/10.1145/3102980.3103005 [26] Richard I. Cook（University of Chicago, Cognitive Technologies Laboratory）. "How Complex Systems Fail." 1998. https://how.complexsystems.fail/ [27] Masayuki Kobayashi（markunet）. "マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察." SpeakerDeck, 2026. https://speakerdeck.com/markunet/marutipurengpunetutowakuwoshi-xian-surusiyatuhuruakitekutiyanozheng-li-tokao-cha [28] 井上喬視（さくらインターネット株式会社）、菊地秀夫（TWCCパートナーズ合同会社）. "AIインフラ時代のデータセンター内光配線の実践知." JANOG58, 2026. https://www.janog.gr.jp/meeting/janog58/pr-dc-optical-cabling/ [29] Shicheng Wang, Menghao Zhang, Xiao Li ほか（Tsinghua University / Beihang University / Infrawaves）. "Hawkeye: Diagnosing RDMA Network Performance Anomalies with PFC Provenance." *SIGCOMM 2025*, ACM, 2025. https://doi.org/10.1145/3718958.3750490 [30] Wei Liu, Kun Qian, Zhenhua Li ほか（Tsinghua University / Alibaba Cloud / University of Illinois Urbana-Champaign）. "SkeletonHunter: Diagnosing and Localizing Network Failures in Containerized Large Model Training." *SIGCOMM 2025*, ACM, 2025. https://doi.org/10.1145/3718958.3750513 [31] Behnaz Arzani, Selim Ciraci, Luiz Chamon, Yibo Zhu, Hongqiang Liu, Jitu Padhye, Boon Thau Loo, Geoff Outhred（Microsoft / University of Pennsylvania）. "007: Democratically Finding the Cause of Packet Drops." *NSDI 2018*, USENIX, 2018. https://arxiv.org/pdf/1802.07222 [32] Edgar Costa Molero, Stefano Vissicchio, Laurent Vanbever（ETH Zurich / University College London）. "FANcY: FAst in-network GraY failure detection for ISPs." *SIGCOMM 2022*, ACM, 2022. https://dl.acm.org/doi/10.1145/3544216.3544242 [33] Francesco Musumeci, Cristina Rottondi, Avishek Nag ほか（Politecnico di Milano, Politecnico di Torino, University College Dublin）. "An Overview on Application of Machine Learning Techniques in Optical Networks." *IEEE Communications Surveys & Tutorials* 21(2):1383-1408, 2019. https://arxiv.org/abs/1803.07976 [34] Danshi Wang, Chunyu Zhang, Wenbin Chen, Hui Yang, Min Zhang, Alan Pak Tao Lau（Beijing University of Posts and Telecommunications, The Hong Kong Polytechnic University）. "A Review of Machine Learning-based Failure Management in Optical Networks." 2022. https://arxiv.org/abs/2208.10677 [35] Shahin Shahkarami, Francesco Musumeci, Filippo Cugini, Massimo Tornatore（Politecnico di Milano, CNIT）. "Machine-Learning-Based Soft-Failure Detection and Identification in Optical Networks." *OFC 2018*, Optica, M3A.5. https://opg.optica.org/abstract.cfm?uri=ofc-2018-M3A.5 [36] Efraín San Martín, Ariel Leiva, Cristóbal Melo, Gabriel Saavedra（Universidad de Concepción, Pontificia Universidad Católica de Valparaíso）. "Two-stage machine learning for modulation-robust soft-failure detection and localization in optical fiber transmission links." *Journal of Optical Communications and Networking* 18(7):674. [37] Sadananda Behera, Tania Panayiotou, Georgios Ellinas（University of Cyprus, KIOS Research and Innovation Center of Excellence）. "Modeling Soft-Failure Evolution for Triggering Timely Repair with Low QoT Margins." arXiv:2208.14535. https://arxiv.org/pdf/2208.14535 [38] Dibakar Das, Mohammad Fahad Imteyaz, Jyotsna Bapat, Debabrata Das（IIIT Bangalore, Tejas Networks）. "A Data Augmented Bayesian Network for Node Failure Prediction in Optical Networks." arXiv:2102.03616. https://arxiv.org/pdf/2102.03616 [^unreliable-numbers]: 「10M光トランシーバーのクラスタでは48秒に1回リンクフラップ」（arXiv:2603.03736）は、MTBF 1e7時間とフラップMTTF 3e5時間を仮定した著者自身によるモデル推計であって、実測ではない。「AIクラスタ障害の90%が光トランシーバー起因」は一次資料を特定できなかった。ベンダ白書（Clockwork、Credo、Cisco）は算定根拠を示していない。いずれも本稿の数値としては引用していない。