要約

  • 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になる。

出典