CodingBox ドキュメント

AI ファブリックにおけるリンクの信頼性と監視

学習ジョブは、数千基の GPU にまたがる同期計算です。あらゆる集団通信が最も遅いリンクを待ちます。1台のフラップしているトランシーバーは、1台のサーバーをわずかに遅くするだけでは済みません。ジョブ全体を止め、完全に故障すれば直前のチェックポイントからジョブが再開されます。そのため光学部品は、単なる部品ではなく信頼性バジェットになります。このページでは、故障の算数、トラブルを予測する指標、ファブリックが不良リンクをどう監視・切り分けるか、そして故障率を抑える運用手法を扱います。

1本のリンクが重要な理由

イベント学習ジョブへの影響
リンクフラップ（数秒）集団通信がタイムアウトまたは再試行；ステップ時間が急増；NCCL/RCCL では、スタールが十分長引くとジョブが中断される
速度／幅が低下したリンクすべての all-reduce がこのリンクに律速される；クラスター全体のスループットがこのリンクの持ち分まで低下する
前方誤り訂正前 BER の上昇、訂正不能エラーはまだなしまだ影響なし。ただしマージンは失われており、次に暖かい午後が来ればフラップする
訂正不能な FEC エラーパケットロス → RDMA 再送ストーム → スタール
ハード故障チェックポイントからのジョブ再開：クラスター全体で数分から1時間の計算損失

GPU 1 000基のジョブにおけるチェックポイント再開のコストは GPU時間で測られます。これこそが、より良い光学部品とより良い QA のコストと比較すべき数字です。

故障の算数

トランシーバーの信頼性は、FIT（10⁹ デバイス時間あたりの故障数）または MTBF で表されます。

前提値
ファブリック内の光学端点4 000（1 024-GPU の2段クラスター）
端点あたりの FIT（成熟した 400G 光学部品、十分な冷却）200–500
月あたりの予想ハード故障数4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
実際に観測されるリンクフラップ率ハード故障の 5–20 倍 — 汚れ、際どいマージン、熱、ファームウェア

つまり、ハード故障はまれで予測可能です。大半を占めるのはフラップと劣化したリンクであり、その大半は予防可能です。だからこそ、監視と QA はそれ自体で元が取れるのです。

トラブルを予測する指標

指標ソース健全対応
レーンごとの前方誤り訂正前 BERCMIS VDM；ホストの FEC カウンター< 10⁻⁷> 10⁻⁶ で上昇中；> 10⁻⁵ で交換をスケジュール
FEC 訂正不能コードワードホスト0増加が見られればインシデント
レーンごとのシンボルエラーホスト（Ethernet）／perfquery（IB）均等でほぼゼロ1レーンが突出
ベースラインに対するレーンごとの Rx パワーDDM初日から 1 dB 以内、レーン間で互いに 2 dB 以内ベースラインから −2 dB
Tx バイアスの傾向DDM横ばいベースラインから +15–20 %（Tx バイアスと経年劣化）
モジュール温度DDM< 60 °C> 65 °C、または近隣モジュールから +10 °C
eSNR（CMIS）VDM> 18–20 dB1レーンで低下
ポートあたりのリンクフラップスイッチのログ、ファブリックマネージャー01回でも発生したら
ネゴシエートされた速度／幅スイッチ／ibstatフル定格未満

定義と書式についてはVDM と FEC の指標、監視を参照してください。

監視アーキテクチャ

ファブリック収集方法ツール
InfiniBandサブネット／ファブリックマネージャーが全ポートのカウンターとケーブルの EEPROM/DDM をポーリングUFM クラスのマネージャー、ibdiagnet、mlxlink -m
Ethernet（RoCE）トランシーバーと FEC 状態を 10–60 秒間隔で gNMI/OpenConfig ストリーミング；SNMP はフォールバックgnmic → Prometheus/Grafana、ベンダーテレメトリー（ツールで DDM を読み取る）
ホスト側NIC カウンター：再送、CNP、順序逆転；タイムアウトについては NCCL/RCCL のログnode exporter
ジョブ側ステップ時間のばらつき、ストラグラー検出学習フレームワークの指標

3つを相関させます。14:05 のステップ時間の急増、14:04 のリーフ7レーン3における前方誤り訂正前 BER の逸脱、ラック12でのモジュール温度のピーク、これらが揃えば完全な診断になります。

切り分けと対処

  1. 訂正不能エラーやフラップがしきい値を超えたときのポート自動無効化／迂回：ファブリックマネージャーと NOS はリンクエラーポリシーに対応しており、その間はアダプティブルーティングが劣化したリンクを避けてフローを誘導します。
  2. NIC ポートが原因であればノードをドレインし、それを避けてジョブをスケジュールします。
  3. モジュールをベンチで検査：識別情報、初日のベースラインに対するレーンごとの DDM、チェックサム、ファームウェアバージョン（Check transceiver、DDM）。
  4. モジュールを疑う前に、両側の MPO を清掃して再検査します。汚れが最も多い原因です（物理的な不一致）。
  5. 交換して様子を見る：エラーがモジュールについて移動するなら RMA し、ポート側に留まるならケージ、光ファイバー、対向側を確認します。

故障率を下げる運用手法

手法効果
受入検査とバーンイン（負荷と温度をかけて24–72時間）初期不良をジョブに到達する前に除去する
初日にレーンごとの DDM をベースライン化絶対精度（±3 dB）を正確な差分に変える
モジュールを60 °C 未満に保つ：気流、フィン付き／フラットの OSFP を正しく使い分け、吸気を塞がない−10 °C ごとに寿命が倍になる
接続のたびにすべてのコネクターを清掃；未使用ポートにはキャップフラップの大半は汚れが原因
モジュールとホストのファームウェアを最新に維持CMIS の相互接続性の不具合を修正（CMIS の問題）
層ごとに均質で検証済みの光学部品を使用ホスト／モジュール間の DSP 相互接続の不具合が減る
バーンイン・ベースライン化済みの予備品を 3–5 %二次インシデントを起こさずに交換できる
週次でのトレンドレビュー故障を待たず、スケジュールに沿ってレーザーの経年劣化に対処

技術の今後の方向性

レーンレートの高速化（200G/レーン、1.6T）はマージンをさらに圧迫します。リニア（LPO）とコパッケージ光学部品は DSP とその監視機能を取り除き、BER の可視性をホスト側に押し出す一方で、部品点数の削減と発熱の低減を約束します（変調と DSP、AI における光学部品）。どのモジュールであっても、原則は変わりません。ベースラインを取り、差分を監視し、傾向に基づいて対処することです。

CodingBox では

CodingBox は、このループのベンチ側を担います。受入検査とバーンインでの読み取り、シリアル番号ごとにcode databaseに保存される初日のレーンごとのベースライン、そして取り外したモジュールの事後読み取り（識別情報、ファームウェア、チェックサム、DDM を自身の履歴と比較）です。これにより、RMA の判断は、ポートの最後のログ行ではなくデータに基づくものになります。

この記事に不正確な点や誤りを見つけた場合は、該当する箇所を選択して Ctrl+Enter を押すと、できます。