生成AI革命の裏側には、華々しいモデルの性能向上とは対照的な、泥臭く、過酷なハードウェアの現実が存在する。NVIDIA H100をはじめとする最新鋭GPUは、驚異的な演算能力を持つ反面、その運用は極めて不安定だ。

サーバーレスGPUプラットフォームを提供する「Modal」が、20,000基以上のGPUプールを運用する中で得た知見を公開した。それは、Meta（旧Facebook）がLlama 3のトレーニングで直面した過酷な現実と、Modalがマルチクラウド環境（AWS, GCP, Azure, OCI）で実践している信頼性エンジニアリングを統合し、現代のAIインフラストラクチャが抱える「GPUの信頼性」という最大のボトルネックを解き明かすものだった。

AD

AI開発を阻む「シリコンの脆弱性」

多くの開発者は、クラウド上のGPUインスタンスを「起動すれば動くもの」として信頼しすぎている。しかし、現実は異なる。数千、数万のGPUを並列稼働させる環境において、ハードウェア障害は「例外」ではなく「日常」だ。

昨年Metaが公開した「Llama 3 Herd of Models」の研究論文において、衝撃的なデータが示された。16,384基のH100 GPUを使用した54日間のトレーニング期間中、419回の予期せぬ中断が発生し、その58.7%がGPU関連の障害（GPU本体やHBM3メモリの故障）に起因していたという事実だ。これは平均して3時間に1回、システムが停止することを意味する。

この「信頼性の欠如」に対し、Modalはどのように立ち向かっているのか。彼らは400万回以上のインスタンス起動から得たデータを基に、ハイパースケーラー（AWS, GCP等）やネオクラウドの特性を見極め、徹底的な自動化による監視システムを構築したのだ。

ハイパースケーラーの格付け：クラウドごとの「癖」を見抜く

Modalのアプローチで最も興味深いのは、クラウドプロバイダーを単なる「コンピュートリソースの提供者」として無差別に扱わず、それぞれの信頼性とパフォーマンス特性に基づいて厳格に選別・重み付けを行っている点だ。彼らはプロバイダーを匿名化（Cloud A, B, C, D）しているが、その特徴からある程度の実態が透けて見える。

インスタンス選定における残酷な現実

すべてのH100が平等に作られているわけではない。Modalのベンチマークデータは、クラウドプロバイダー間、あるいは同一プロバイダー内でもハードウェア構成によって劇的な性能差が生じることを示している。

  • Cloud A（高信頼・低性能）: APIの信頼性は極めて高く、インスタンス確保（HTTP 201応答）後の起動成功率は99.6%を誇る。しかし、提供されるH100の性能は、他のクラウドに比べてStable Diffusionの推論などで50%も劣ることがある。
  • Cloud C（熱問題）: 2025年の数ヶ月間、H100の冷却管理に失敗し、GPU温度が90℃を超える事態が頻発した。GPUは70℃台半ばからサーマルスロットリング（熱暴走を防ぐための性能抑制）が発生するため、実効性能が著しく低下していた。さらに、システム予約メモリが他社より228MiB多く、ユーザーが利用可能なVRAMが削られている。
  • Cloud D（高コスパ・不安定）: コストパフォーマンスは最強であり、ベアメタルサーバーの性能も高い。しかし、特定のリージョンのA10 GPUにおいて、訂正不可能なECCエラー（メモリ工ラー）が頻発する傾向がある。また、マシンのクロックダウン（HW_SLOWDOWN）も頻繁に観測される。

特に重要なのは、SXM接続（サーバー内直接接続）とPCIe接続のH100の性能差だ。Modalのデータによれば、PCIe版H100はSXM版に比べて行列演算（MatMul）のFLOPSが約40%低く、ホスト-デバイス間の転送帯域幅にも大きな差がある。安易なインスタンス選択は、コストと時間を浪費する結果となる。

AD

マシンイメージ：信頼性の起点は「ビルド」にある

信頼性の高いGPU環境を構築するための最初の防壁は、適切なマシンイメージ（AMI等）の作成にある。Modalは、カーネル、OS、NVIDIAドライバ（記事執筆時点では580.95.05を採用）を一貫して管理し、継続的インテグレーション（CI）によってイメージを更新している。

ネオクラウドの弱点

Modalの指摘によれば、Lambda LabsやNebiusといった新興の「ネオクラウド」は、マシンイメージのカスタマイズ性においてハイパースケーラーに大きく劣る。また、ハイパーバイザーやキャッシュの非効率性から、インスタンスの起動に5分以上かかるケースも珍しくない。対して、大手クラウド（特にCloud C）は2分弱で起動が可能だ。オートスケーリングを前提とするAIワークロードにおいて、この数分の差は致命的となる。

ビルド時の事前検証

Modalは、マシンイメージのビルド段階でNVIDIA DCGM（Data Center GPU Manager）などの診断ツールを実行し、イメージ自体に不具合がないかを確認している。これにより、本番環境でのトラブルを未然に防ぐ「シフトレフト」のアプローチを採用しているのだ。

起動時チェック：スピードと安全性のトレードオフ

インスタンスが確保され、ブートした瞬間に何をすべきか。ここでModalは「過剰なチェックは行わない」という戦略をとる。

完全な診断（dcgmi diag --run 4）を行えばGPUの微細な不具合まで検出できるが、これには約1時間を要する。オートスケーリングによる迅速なリソース提供が価値であるプラットフォームにおいて、起動に1時間かけることは許容されない。また、クラウドプロバイダー側でも提供前に基本的な健全性チェックは行われているはずである。

そのため、Modalは起動時には以下の軽量なチェックに留めている：

  • systemctl によるサービス状態確認
  • nvidia-smi によるGPU認識確認
  • ランダムに選択したGPUに対する基本的な読み書きテスト

これにより、ユーザーへのリソース提供を遅延させることなく、明白な初期不良だけを排除する運用を実現している。

AD

運用中の監視：パッシブとアクティブの二重防壁

インスタンスが稼働し、ユーザーのワークロードが実行されている間こそ、監視の真価が問われる。Modalは「パッシブ（受動的）」と「アクティブ（能動的）」の2つのアプローチを組み合わせている。

パッシブ・ヘルスチェック（常時監視）

これは、ユーザーのワークロードを妨害せずにバックグラウンドで行われる監視だ。主にdcgmi healthやカーネルログ（dmesg）を監視し、以下の兆候を捉える。

  • Xidエラー: NVIDIAドライバが出力するエラーコード。特定のコード（例: Xid 48, 63など）は、訂正不可能なECCエラーやページフォールトを示唆し、即座にハードウェア交換が必要なレベルの障害を意味する。
  • 熱暴走: 温度が88℃を超えた場合や、サーマルスロットリングが発生していないかを監視する。
  • 電力制限: 意図しない電力制限（パワーブレーキ）がかかっていないか。

Modalによれば、労力の20%で実装できるこのパッシブチェックによって、GPUトラブルの80%を検知できるという。

アクティブ・ヘルスチェック（定期的介入）

パッシブチェックでは見抜けない「負荷をかけないと顕在化しない不具合」を検出するため、週に一度、インスタンスの制御を一時的に奪い、高負荷テストを実行する。

  1. DCGM diag level 2: 数分で完了する詳細診断。
  2. GPU-fryer (GPU Burn): 最大負荷をかけて、高負荷時にGPUが落ちないかを検証するストレステスト。
  3. NCCL all-reduceテスト: GPU間の通信（NVLink/NVSwitch）が正常に機能しているかを確認する。

特にLLMの分散学習においては、1つのGPUの通信不良がクラスター全体の速度を低下させるため、通信周りのチェックは今後さらに重要度を増す。Modalはこれに加え、InfiniBandの帯域幅テスト（ib_write_bw）なども導入予定としている。

「修理」ではなく「廃棄」

異常が検知された場合、Modalは該当ノードを修復しようとはしない。自動的に「不健全（Unhealthy）」としてマークし、ドレイン（新規タスクの割り当て停止）を行い、インスタンスを破棄または再インストールする。クラウド環境において、個別のデバッグはコストに見合わないからだ。

GPUは「壊れるもの」として設計せよ

NVIDIAのGPUは人類の英知の結晶であり、驚異的な計算能力を提供するが、同時に「極めて壊れやすい消耗品」である。MetaのLlama 3トレーニングにおける障害記録と、Modalの20,000基運用の知見は、同じ事実を指し示している。

「GPUの信頼性は低い。CPUと同じ感覚で運用してはならない。」

Metaのように数万基のH100を自社で保有・運用する場合でも、Modalのようにクラウド上のリソースを借り受ける場合でも、求められるのは「ハードウェアは必ず故障する」という前提に立った、極めて攻撃的かつ自動化された監視・排除システムである。

AI開発者にとっての教訓は明確だ。インフラレイヤーでこれらの複雑性を隠蔽してくれるマネージドサービスを利用するか、あるいは自社で同等の信頼性エンジニアリングチームを組織するか。中途半端な監視体制で大規模なGPUクラスターを運用することは、砂上の楼閣を築くに等しい行為なのである。

Sources