Databricks AI全体でGPUの信頼性を維持する方法

Databricks AIでは、大規模な分散GPUトレーニングが日常的に行われています。しかし、クラスタ規模が大きくなるにつれて、GPU障害は頻繁かつ不可避になります。本稿では、このような負荷がかかる環境でGPUの信頼性を維持するための体系的なアプローチを詳しく説明します。

大規模トレーニングにおけるGPUの障害モード

大規模GPUトレーニングにおける障害は、主に3つのカテゴリに分類されます。1つ目はジョブクラッシュで、トレーニングジョブが突然停止し、NCCLウォッチドッグタイムアウトが発生します。しかし、タイムアウト自体は根本原因を明らかにしないため、ハードウェア、ネットワーク、ファイルシステム、ソフトウェア層を横断した診断が必要です。2つ目はサイレントスローダウンで、トレーニングは一見正常に進行しますが、最も遅いGPUによって全体のスループットが制限され、計算リソースとコストが無駄になります。これは、熱センサーの作動、相互接続リンクの速度低下、メモリ帯域幅の低下など、ハードウェアの劣化状態に起因します。3つ目は数値破損です。最新のGPUはECCを使用して一時的なメモリ障害を自動修正しますが、すべての障害が回復できるわけではありません。回復できない障害は、NaN損失、不安定な収束、または後で発見されるモデル品質の低下を引き起こす可能性があります。

ストレステストとヘルスチェックシステム

Databricks AIは、これらの課題に対処するために独自の戦略を採用しています。まず、強化学習トレーニング、エージェンティックコーディングモデル、ドキュメントインテリジェンスシステムなど、多様で最先端のワークロードを実行してプラットフォームのストレステストを行います。これらのワークロードはそれぞれ異なる方法でプラットフォームに負荷をかけ、ネットワークの問題、熱ホットスポット、集団通信のエッジケースを早期に発見します。例えば、あるトレーニング実行が7時間後にNCCLタイムアウトで失敗した原因は、単一のInfinibandポートの長時間にわたる1回のダウンでした。この発見により、NCCL_IB_TIMEOUTパラメータを調整し、より耐障害性を高めました。

次に、gpu-monitorと呼ばれる多段階のヘルスチェックシステムを構築しました。これは各GPUノードで実行され、ノードの全ライフサイクルをカバーします。システムは3つの層で構成されています。

• アクティブブートストラップチェック: ノードのプロビジョニング時および各顧客ワークロード間のクリーンアップ時に実行されます。GPU計算速度、GPU間のピア接続、ノード内NCCL通信、RDMA帯域幅、ECCメモリヘルス、PCIeトポロジ、NVIDIA DCGM診断などを検証します。失敗したノードは即座にクラスタから削除され、隔離・再テストされます。
• パッシブ連続チェック: ノードの稼働中に継続的に監視し、非決定的な障害を捕捉します。NVLinkレーン状態、GPUクロックスロットリング理由、RDMAポート状態（フラップ回数ではなく累積ダウンタイムで判定）、XIDエラー、PCIe AERエラー、温度勾配、NVSwitchエラー状態などを監視します。障害が検出されたノードは隔離され、再テストされます。
• 定期的マルチノードアクティブチェック: 顧客ワークロード間のアイドルノードで実行され、ノード間の相互接続動作を検証します。8バイトから2GiBまでのペイロードサイズでNCCL集合通信帯域幅をテストし、異なるコードパス（小メッセージは遅延支配、中メッセージはアルゴリズム切り替え、大メッセージは帯域幅制限）をカバーします。各ペイロードサイズに対して遅延や帯域幅の合格基準が設定されています。

これらの3層が連携して、ワークロード開始前のハードウェア検証、実行中の状態監視、アイドル時のネットワーク全体の検証を行います。新しい障害モードが発見されるたびに、gpu-monitorを更新しフリート全体に展開します。

結論

GPUの信頼性は体系的な取り組みです。Databricks AIはストレステストとヘルスチェックシステムを組み合わせることで、トレーニングへの障害の影響を最小限に抑えています。本稿はシリーズの初回であり、以降ではスケジュール回避やグレースフルリカバリなど、より高度な信頼性戦略を扱う予定です。大規模GPUトレーニングを運用する組織にとって、障害モードの理解と多層的な検出メカニズムの構築は生産性を維持するための鍵です。