要約

  • SoftBank の全リンク NCCL 性能確認では、LED が緑、Link Status が UP、光パワーが正常でも、1本のリンクが通常時の何分の一かのスループットしか出なかった。状態信号は正しかったが、ワークロードの受入れ条件としては不足していた。
  • JANOG58 資料は switch、optics、NIC、fibre、汚れた connector を切り分け候補に挙げる一方、根本原因、正確な性能比、当該リンクの BER／FEC 値、修理後の再測定を公表していない。説明用の数値や optics 交換図を事故記録へ転用してはならない。
  • ラックスケールの受入れには、リンクごとの再現可能なワークロード基準、Layer 1の証拠、構成識別、限定した交換、同一テストの再実行が必要になる。GPU の設置台数、ASN や prefix の可視性は、ラック内部の利用可能性能を証明しない。

SoftBank の Yasuhiro Uchida と Chaocheng Chang は、2026年7月16日の JANOG58 Day 2で、Rack-Scale GPU サーバーの NW 設計と運用までの苦悩を発表した。公式の最終資料は56ページあり、最初のラックスケール GPU 導入を、ネットワーク、電源、液冷、配線、保守単位まで含む一体の運用対象として扱っている。

問題のリンクは、その資料の中で短く報告される。NCCL benchmark で全リンクを検査すると、特定の1本が「本来の数分の一程度」だった。同じページに Green、Link Status UP、光パワー正常という観測が並ぶ。資料は「三分の一」とは書いておらず、割合も示さない。したがって、このケースを三分の一障害と呼ぶことはできない。

この限定は弱点ではない。むしろ、確実に分かることを明確にする。リンクには光が届き、所定の状態へ上がり、状態回路は異常を宣言しなかった。しかし、collective workload が必要とする rate は、基準から大きく外れていた。物理的に存在する経路と、仕事を完了できる容量は同じではない。

最終資料とは別に9ページの事前資料がある。公式 URL のファイル名はj56-lt4.pdfで、液冷 switch、独自の冷却 interface、標準化をめぐる以前の内容を収める。施設依存を理解する背景にはなるが、この性能異常の短縮版報告ではない。そこから事故時の counter や修理結果を補うこともできない。

1本の弱いリンクが高価になる理由は、ラックの構成にある。資料は GB200 NVL72 を18台の compute tray と9台の switch tray で構成し、各 compute tray に4基の B200 GPU、各 switch tray に2基の NVSwitch を搭載すると説明する。合計72 GPU で、ラックの消費電力は100 kW を超える。NVIDIA の資料も72 GPU、36 CPU、18 compute tray、9 switch tray という参照構成を示し、passive cable backplane、power shelf、busbar、液冷 manifold を含める。

ただし、これらは製品構成の証拠であり、異常リンクがどの性能を出したかを示す証拠ではない。ラックの規模が大きいほど、1本のリンクについて曖昧な状態表示を許せるわけでもない。

外部ネットワークは三つの fabric に分けられる。Compute Fabric は GPU の scale-out 通信、Converged Fabric は front-end、storage、NCCL bootstrap、OOB Fabric は switch、server、facility、NVSwitch の管理を担う。役割を分けることは障害境界を理解する助けになる。しかし、ケーブル、電力、冷却、共通管理 process まで自動的に独立するわけではない。

資料は管理 port から leaf switch へ到達する構成が単一障害点になり得るとする。Compute Fabric の underlay を使って loopback へ到達できれば、全ての低速 port へ個別に配線するより低コストで運用可達性を改善できる。一方で、発表者はこれを OOB の代替ではないと明記した。故障した production fabric を調べる経路が、その fabric だけに依存すれば、診断のための制御面まで同じ障害に閉じ込められる。

リンク性能のケースでも、信号が答える範囲を区別する必要がある。緑の LED は、その状態回路が定義された条件を満たしたことを示す。Link Status UP は interface が所定の管理・protocol 状態へ達したことを示す。正常な光パワーは、受光値が設定された alarm 境界を越えていないことを示す。

どれも無意味ではない。ただし、lane ごとの誤り、訂正余力、connector の状態、送受信側の挙動、queue、あるいは NCCL collective が受け取る end-to-end rate までは保証しない。正しい対応は状態表示を捨てることではなく、それが答えていない問いを受入れ試験に追加することだ。

全リンクの NCCL check は、その問いを実際の通信 graph に近い形で投げた。collective の完了は平均的な port 状態ではなく、遅い部分や劣化した部分に制約される。GPU は設置済みで電源も入っていても、必要な通信 rate が得られなければ、tenant へ渡せる compute capacity は少なくなる。帳簿上の accelerator と、実行可能な capacity の間に差が生じる。

資料が示す切り分け候補は、switch、optics、NIC、fibre、そして汚れた connector である。これは根本原因の公表ではなく、確認すべき物理的な連鎖である。異常は transmitter、receiver、lane、module、connector、cable のいずれでも生じ得て、観測される症状は低い workload throughput として現れる。

後続ページは pre-FEC BER、post-FEC BER、FEC histogram を説明し、正常・異常の pattern や optics 交換を例示する。ここに描かれた BER 値や交換作業は、当該リンクの実測履歴ではない。SoftBank は、問題のリンクが例示された bin へ到達したとも、表示された数値を記録したとも、module 交換で回復したとも述べていない。

ここを混ぜると、原因と修理を発明することになる。BER は訂正前の誤りを示し、FEC は訂正能力がどの程度使われているかを示し得る。部品交換は仮説を狭める操作になり得る。しかし、元の性能が戻ったという証拠は、異常を見つけた同じテストを同じ条件で再実行して初めて得られる。

公開資料には before／after の NCCL 結果がない。特定部品の原因認定もない。そのため、この記事が採れる最も強い結論は、SoftBank が状態監視の盲点を発見し、物理層の証拠へ近づく運用変更を提案した、というところまでである。

資料はLink UP = OKだけでは不十分だとし、BER と FEC を含む物理指標を理解すること、interface と optics の log を週次・月次で収集・分析すること、interface down を待つ監視から劣化兆候を見る監視へ移ることを提案する。

これは監視設計であって、予知保全の成果ではない。閾値、保存期間、false positive、障害前に捉えた実例、可用性の改善値は公開されていない。週次・月次の trend が有用かどうかも、どの baseline と owner、修理 trigger へ結びつけるかで決まる。

サービスをどの単位で販売するかによって、同じ物理異常の費用負担は変わる。資料は rack、tray、GPU 単位を比較し、SoftBank は現在 rack と tray 単位を提供しているとまとめる。GPU 単位は検討された設計であり、現在の提供単位と書き換えてはならない。

rack 単位は1社へ NVL72 全体を渡せるため partition が簡潔になる一方、Compute Fabric、CDU、NVSwitch、compute tray、busbar などの共通依存を同じ顧客へ渡す。tray 単位は小規模顧客へ適合しやすいが、NVLink partition が必要になる。さらに資料は、NVSwitch の管理 process が rack 内で共通の単一障害点になるため、高い SLA には rack または SU 単位の冗長化が必要だとする。

この設計では、誰が受入れを決めるかが経済的な権力になる。SoftBank は自社 platform の受入れ、workload admission、監視、顧客への復旧判定を管理する。NVIDIA と switch、NIC、optics の各 vendor は reference design、firmware、診断、qualified parts、support remedy を管理する。facility team は電力、液冷、物理アクセスを管理する。

JANOG には session record を公開する正当な役割がある。それは production network を検査し、link の合否を決める mandate ではない。発表が会議で共有されたことと、別の operator が同じ閾値や設計を採用すべきことも同義ではない。

費用は故障後だけに発生しない。高密度 cable、optics、switch、予備部品、代表性のある lab、100 kW 超の電力、液冷、跨 vendor の切り分け能力に対し、導入前から支払う必要がある。状態検査を通過した劣化リンクが production へ入れば、tenant は job の遅延と idle GPU の費用を負う。小規模な購入者ほど、同じ予備 rack や検証環境を用意する負担が大きく、integrated supplier の判断に依存しやすい。

利益を得るのは、故障境界を越えて証拠を保持できる service owner と、その証拠によって性能を受け取れる tenant である。vendor も統合された support 契約から利益を得る。ただし、診断 tool、benchmark、qualified parts が一社だけの非公開境界へ固定されれば、同じ統合が退出費用を高める。

SoftBank は2025年12月の発表で、1,224基の Blackwell GPU を用いた platform が12月22日に稼働を開始し、将来4,000基超へ拡張する計画だとした。1,224は operator の導入発表、4,000超は計画である。どちらも、その時点で全リンクが受入れ baseline を満たすという測定ではない。

別の benchmark も混ぜられない。TOP500 に掲載された SoftBank の CHIE-4 は DGX B200 と InfiniBand NDR400 を使う別 system である。その順位や performance を、JANOG58 の GB200 NVL72 環境へ移してはならない。

信頼できる反事実は、状態信号を増やすだけのものではない。各必須リンクについて、期待する NCCL 分布または移植可能な workload baseline を保存する。link state、光パワー、lane counter、pre／post-FEC BER、FEC histogram を、module、fibre、switch／NIC 両端、firmware、topology、時刻と結びつける。

偏差が出たら、一度に一つの限定された部品または設定を変更し、その前後の counter を残す。修理後には、最初の異常を見つけた全リンク test を同じ条件で再実行する。trend、alert、ticket、component change、verified restoration は別々の記録でなければならない。

tenant が vendor 固有 counter を全て受け取る必要はない。しかし、service owner は、受入れ時に宣言した rate を満たし、修理後に同じ分布へ戻ったことを証明できなければならない。ticket の close や部品の交換だけでは、capacity の回復を証明しない。

ASN や BGP が見せるのは、さらに外側の層である。management prefix や customer prefix が到達可能でも、rack 内部の collective path は遅いままになり得る。番号資源保有者にとって route identity と edge reachability は必要な証拠だが、prefix の背後にある GPU fabric の rate を認定しない。registry、標準化団体、会議にも、その可視性だけで性能を宣言する権限は生じない。

JANOG58 のケースは、「BER を見ればよい」という単純な教訓ではない。状態、物理 counter、workload の三つを、同じ topology と修理履歴へ結びつける必要があるという教訓である。緑と UP はリンクが存在することを示した。稼働状態ではなく、再現できる性能で受け入れて初めて、そのリンクは利用可能な capacity になる。

出典