なぜ100万GPUクラスターで「信頼性」が最重要になるのか
Metaがオハイオ州ニューアルバニーに構築したPrometheusスーパークラスターは、単なるデータセンターではありません。数十万のGPUが一つのマシンのように動作するギガワット級のAIトレーニング基盤であり、最終的には約100万GPUを接続することを目指しています。
ここで重要なのは「性能」ではなく**「goodput（実効有効演算率）」です。大規模トレーニングでは、たった1台のホスト障害でもジョブ全体が遅延・停止する可能性があります。Metaは初期段階で8,000GPUあたり日次約1,000件の中断が発生していましたが、1年間のエンジニアリングにより99%削減**を達成しました。本記事では、その安定性確保の手法と実務に活かせるインサイトを整理します。
核心設計：72-GPU障害ドメインと冗長化戦略
Prometheusの最大の構造変化はNVL8からNVL72への移行です。H100世代では8GPUがNVLinkで結合されていましたが、GB200/GB300 NVL72では72GPUが1ドメインを形成します。帯域幅の利点がある一方、障害のブラストラディウス（影響範囲）が9倍になるリスクを伴います。
Metaの解決策は以下の通りです。
- 64+8スライス構造：72GPUのうち64GPUでトレーニングスライスを構成し、残り8GPUはラック内スペアとして保持します。GPU障害時はスペアが即座に代替し、ジョブは最後のチェックポイントから再開されます。
- ラックスペア約2%：ラック全体の障害に備えて追加ラックを確保します。32,768アクティブGPUのトレーニングでは523ラック（37,656GPU）をプロビジョニングし、約13%の余裕を確保します。
- PAFT（Parallelism-Aware Fault Tolerance）：データ並列レプリカ単位で障害を分離し、1つのレプリカのみオフラインにして残りのクラスターはトレーニングを継続します。
# PAFTスライス再起動の概念的疑似コード
def handle_fault(fault_domain, replicas, spares):
if fault_domain in replicas:
# 障害レプリカのみ隔離
failed = replicas.pop(fault_domain)
# スペアホストで再起動・再同期
new_replica = spares.allocate()
new_replica.restore_from_checkpoint(failed.last_checkpoint)
replicas.add(new_replica)
return "partial_recovery"
else:
# ジョブ全体をチェックポイントから復元
return "full_restart"
この構造の核心は**「障害を許容しつつ、ジョブ全体を止めない」**ことです。実務でも大規模分散システムを設計する際は、障害単位を明確に定義し、復旧戦略を階層化することが重要です。
信頼性確保のための具体的エンジニアリング
Metaは中断原因を細分化し、それぞれに対策を適用しました。
| 中断原因 | 問題 | 解決戦略 |
|---|---|---|
| NVLink信号整合性 | 60万以上のNVLink接続の微細な信号劣化 | L11診断バーンで生産前に弱リンクを事前隔離、継続的テレメトリ |
| HBM/LPDDRメモリ | GB300拡張時のメモリ障害急増 | HBMファームウェア調整、メモリスキャラビング、LPDDR誤り訂正アルゴリズム改善 |
| NVLinkスイッチ | 単一スイッチ障害がドメイン全体に影響 | ミリ秒単位のファブリック状態監視、自動復旧パス |
| バックエンドネットワーク | BAGスーパースパインのリンクイベント | ハードウェアベースの障害検知、プラナートポロジによる迂回 |
特に注目すべきは**「帰属ベースの責任モデル（attribution-driven accountability）」**です。MetaとNVIDIAがリアルタイムテレメトリを共有し、すべてのシステム停止を根本原因別に分解して各組織が担当部分を改善します。これは単なるベンダー関係を超えた共同エンジニアリングモデルです。
またDynamo Dimmerというクラスター電力管理フレームワークで30〜40%の電力変動（トランジエント）を緩和します。ラック単位バッテリ（BBU）、キャパシタトレイ（CBU）、施設BESSを組み合わせて電力ピークを平準化します。
注意：本記事で紹介したNVL72構造はラックあたり約120〜135kWの電力を消費します。日本のデータセンター環境では、電力インフラと液冷設備が整っていなければ導入は困難です。最新GPUの導入だけでなく、電力・冷却・ネットワークトポロジーを一体で設計する必要があります。
結論：「安定性」こそがAI競争力
Prometheusの事例から得られる実務教訓は明確です。
- goodputをKPIにする：単純な稼働率ではなく、実際の有効トレーニング時間を測定すべきです。
- 障害ドメインを設計する：ハードウェアトポロジーが障害分離単位を決定します。NVL72のようにドメインが大きくなるほど、スペアリソースと復旧戦略を精緻化する必要があります。
- テレメトリと自動化に投資する：60万のリンクを手動管理することは不可能です。自動診断と事前隔離が必須です。
Metaはこの経験を基に、ルイジアナ州の次世代スーパークラスターHyperionを設計中です。AIインフラ競争は今や「どれだけGPUを買うか」ではなく、**「どれだけ安定して長く稼働させるか」**へと移行しています。
次のステップとして、分散トレーニングのチェックポインティング戦略とネットワークトポロジー最適化を学習されることをお勧めします。