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

分散GPUトレーニングは、業界全体で一般的になっています。現在、開発チームは、かつては最先端の研究所だけの領域であった規模で、基盤モデルのトレーニング、最先端スケールのモデルのファインチューニング、大規模なビジョンシステムの構築、ディープなレコメンダーネットワークの実行を行っています。

今日の規模に対応できるGPUインフラストラクチャを構築するには、多くのことを正しく行う必要があります。実行を停止させる障害の検出、表面化しない緩やかなパフォーマンス低下の可視化、数千のリンクにわたるファブリックの健全性の検証、最終的には故障するハードウェアを回避するスケジューリング、そして故障が発生した際のクリーンな復旧などです。これらの多くは基盤となるものであり、スタックの上位にあるより困難な課題はこれらに依存しています。

Databricks AIでは、毎週大規模なトレーニングワークロードを実行しており、ハードウェア、ファブリック、ソフトウェア全体で障害が継続的に発生しています。このシリーズでは、この規模でGPUの信頼性を維持するために必要なことについて説明します。最初の投稿となる本稿では、その基盤として、GPUの実行時に遭遇する障害モード、それらを表面化させる多様なワークロード、そしてそれらを検出する多段階のヘルスチェックシステムについて取り上げます。ここでは最も要求の厳しいワークロードクラスであるトレーニングに焦点を当てますが、同じエンジニアリングがDatabricksにおける推論やその他のGPUワークロードにも役立っています。

トレーニング負荷下におけるGPUの障害パターン

大規模環境におけるGPU障害のほとんどは、ジョブのクラッシュ、サイレントなパフォーマンス低下、数値の破損の3つのカテゴリに分類されます。ジョブのクラッシュは、発生したことがすぐにわかるという意味で、簡単なケースです。より困難な障害は、モデル内の数値が誤った状態で完了するワークロードや、誰にも気づかれずにパフォーマンスが低下した状態で何時間も実行されるワークロードです。

ジョブのクラッシュ。 分散トレーニングジョブがクラッシュする理由は、GPUの劣化やバスからの脱落、RDMAファブリックの問題、I/Oシステムのハング、CPU側のランクが他から乖離することなど、多岐にわたります。ワークロードの観点からは、これらのほとんどすべてが同じ現象として表面化します。つまり、ログに恐ろしい NCCL watchdog timeout メッセージが表示されてジョブがクラッシュするのです。すべてのランクが同じコレクティブ通信でブロックされ、ウォッチドッグが最終的にジョブを強制終了し、最後のチェックポイントから再起動することになります。しかし、タイムアウト自体は根本原因についてほとんど何も教えてくれません。実際に何が問題だったのかを診断するには、症状のみを示すスタックトレースから、ハードウェア、ファブリック、ファイルシステム、ソフトウェアの各レイヤーをトレースしなければならないことがよくあります。

サイレントなパフォーマンス低下。 静かに劣化したGPUでも、ログに問題がなく、損失（loss）が低下し続けているように見えれば、トレーニングを継続できます。しかし、スループットは最も遅いGPUでボトルネックになり、計算リソースとコストが無駄になります。これらの速度低下は、ハードウェアが劣化した状態で動作していることに起因します。例えば、持続的な負荷の下で温度センサーが作動したり、永続的なエラーの後にインターコネクトリンクがダウングレードしたり、障害の蓄積に伴ってメモリ帯域幅が低下したりします。これらはそれぞれ異なるハードウェアレベルのシグナルとして現れます。例えば、熱に関する HW_SLOWDOWN や HW_THERMAL_SLOWDOWN のような DCGM スロットル理由や、インターコネクトのリンク健全性などです。

数値の破損。 現代のGPUは、Error Correction Code（ECC）を使用して、トレーニングを中断することなく、多くの過渡的なメモリ障害を検出して自動的に修正します。しかし、すべての障害を回復できるわけではありません。破損は、メモリ、インターコネクト、カーネル、またはソフトウェアレイヤーで発生し、検出または封じ込められる前に伝播する可能性があります。そのような場合、トレーニングはすぐに停止するか、誤った値のまま継続される可能性があります。障害は、NaN損失、不安定な収束、または後から発見されるモデル品質の低下として現れることがあります。

GPUの信頼性に対する当社のアプローチ

GPUのハードウェア障害発生率は、CPUよりも桁違いに高くなる可能性があります。控えめな大まかな想定として、各GPUの年間障害発生率を1%と仮定します。T日間にわたってN個 of GPUを使用するジョブにおいて、少なくとも1つのイベントが発生する確率は、およそ次のようになります。

256個のGPUを使用するジョブを30日間実行した場合、障害が発生する確率は約19%です。1,024個のGPUでは、その確率は57%に上昇します。この規模では、実行中の障害は例外ではなく、想定内の出来事です。これに対処し、トレーニングの信頼性を維持するための基盤として、2つのエンジニアリング投資を行っています。それは、障害を早期に表面化させる多様で最先端のワークロードによるストレステストと、フリート全体で障害をキャッチする多段階のヘルスチェックシステムです。

最先端のワークロードによるプラットフォームのストレステスト

Databricks AIは、お客様が使用しているものと同じプラットフォーム上で、要求の厳しいさまざまなトレーニングワークロードを実行しています。これには、KARLのようなモデルの強化学習トレーニング、エージェント型コーディングモデル、本番環境でのPDFの背後にあるようなドキュメントインテリジェンスシステムなどが含まれます。これらは一般的なトレーニングジョブではありません。RLワークロードは、多数のGPUにわたる緊密なループ内で、トレーニング、推論、報酬計算を組み合わせます。エージェント型コーディングモデルは、トレーニングと並行して推論負荷の高い評価を実行します。ドキュメントインテリジェンスのパイプラインは、モデルのトレーニングと、画像ベースの重いデータ読み込みを組み合わせます。

それぞれが異なる方法でプラットフォームに負荷をかけるため、ファブリックの不安定さ、熱のホットスポット、コレクティブ通信におけるエッジケースなどの運用上の問題を、より広範な本番ワークロードに影響が及ぶ前に表面化させるのに効果的です。

最近発生した問題の一例をご紹介します。あるトレーニングの実行が、開始から7時間後にNCCLタイムアウトで失敗しました。調査の結果、RDMA NCCLコレクティブ通信に使用されていた単一のInfinibandポートが一度ダウンし、その後復旧していたことが判明しました。その後、フラッピング（状態の頻繁な変化）は発生しませんでした。当社の継続的なヘルスチェックはIBポートのフラッピングを監視していますが、単一の孤立したフラップは通常、ポートの異常を示すものではないため、それだけではしきい値を超えません。

クラッシュの原因は、2つのNCCLタイムアウトのうちどちらが先に作動するかという点にありました。NCCL構成に関する議論の多くは、init_process_group(timeout=...)を介して設定可能なPyTorch NCCLウォッチドッグタイムアウトに焦点を当てています。これは、設定された一定時間（通常は10分）が経過した後に、ハングしたコレクティブ通信を強制終了します。2つ目のタイムアウトはスタックのより低い位置にあり、それよりもはるか前に作動します。InfiniBandトランスポートレイヤーの NCCL_IB_TIMEOUT は、接続を切断する前に、ダウンしたポートが復旧するのを接続が待機する時間を制御します。リトライを考慮した実質的なデフォルト値は約7秒であり、ほとんどの開発チームが認識しているよりもはるかに短い時間です。単一のポートダウンウィンドウがそれを超えると、PyTorchウォッチドッグタイムアウトの設定に関係なく、接続は失われ、コレクティブ通信はすでに停止しています。ウォッチドッグがハングを検知する頃には、実行はすでにクラッシュすることが確定しています。

トレーニングへの影響において重要なシグナルは、フラップ回数ではなく、累積ダウンタイムです。十分に長い単一のフラップは、数日間にわたるトレーニングの実行をクラッシュさせる可能性があり、これは数時間にわたる繰り返しのフラップと同様です。当社は、回復力を高めるために NCCL_IB_TIMEOUT のデフォルト値を調整しました。また、同じポートダウンシグナルを使用することで、ウォッチドッグが作動するまでGPUをアイドル状態のままにすることなく、ジョブをクラッシュさせてチェックポイントから再起動できるようになりました。この調査は、本稿の残りの部分で説明するヘルスチェックシステムに反映されている多くの取り組みの1つです。

ノードのライフサイクル全体にわたるヘルスチェック

当社は、すべてのGPUノードで実行され、ノードのライフサイクル全体をカバーする多段階のヘルスチェックおよびオブザーバビリティサービスとして gpu-monitor を構築しました。異なる障害モードは異なる条件で検出可能であるため、異なるカテゴリのチェックが異なるステージで実行されます。

アクティブなブートストラップチェックは、ノードが最初にプロビジョニングされたとき、および顧客のワークロード間でノードがクリーンアップされるたびに実行されます。すべてのワークロードは、完全なチェックスイートに合格したばかりのノードで開始されます。これらは、事前にターゲットを絞ったテストによって確実に表面化させることができる決定論的な障害をキャッチします。gpu-monitor が実行する代表的なチェック項目は以下の通りです：

• GPUの計算速度とバーンインの検証
• すべてのペア間で検証されたGPU間ピア接続（NVLinkおよびNVSwitchの健全性）
• ノード内NCCL all-reduceの正確性と帯域幅
• ホストローカルループバックを介したRDMA NIC帯域幅
• 行リマップ（row-remap）のヘッドルームを含む、ECCおよびHBMメモリの健全性
• PCIeトポロジとリンクの整合性
• レベル2でのNVIDIA DCGM診断

アクティブチェックに不合格となったノードは、ワークロードが実行される前にただちにフリートから除外されます。異常ノードは隔離され、リセットと徹底的な再テストを行った後、フリートに復帰させるか、あるいは恒久的に除外されます。

パッシブ継続チェックは、前のセクションで説明した非決定的な障害モード、つまり持続的なワークロードの負荷がかかった場合にのみ発生する障害を監視します。これらに対して、gpu-monitorはすべてのアクティブなノード上で、以下のような第2層のチェックを実行します。

• NVLinkのレーンステータス（いずれかのレーンがダウンした場合にフラグを立てる）
• GPUクロックスロットリングの要因（HW_SLOWDOWN、HW_THERMAL_SLOWDOWN、HW_POWER_BRAKE）
• RDMAファブリックポートのダウン検出（フラップ回数ではなく、累積ダウンタイムにしきい値を設定）
• カーネルログからの重大なXIDエラー
• PCIe AERの訂正不可能なエラー
• GPUコアとHBM間の温度勾配
• NVSwitchのエラー状態

継続チェックで失敗を示したノードは、コーダン（隔離設定）およびドレイン（ワークロードの排出）され、アクティブなブートストラップチェックの失敗時と同じ隔離プロセスを実行します。

定期的なマルチノードアクティブチェックは、単一のノードだけでは検出できないノード間のファブリックの動作を検証します。これらは、お客様のワークロードの合間にアイドル状態のノードで定期的に実行され、ブートストラップ層がすでに検出している単一ノードの劣化から、ノード間のファブリックの問題を切り離します。これらはアイドル状態のノードで実行され、お客様のワークロードでノードが必要になった場合にはプリエンプト（一時中断）できるため、プロビジョニング時のアクティブチェックに収まるものよりも、より負荷の高い検証を行うことができます。

テスト自体には、ノードグループ全体でのNCCLコレクティブ帯域幅のプローブが含まれており、ペイロードサイズを8バイトから2 GiBまで変化させます。ペイロードサイズが異なると、NCCLが異なるコードパスをトリガーするため、この違いが重要になります。KB範囲の小さなメッセージは、LLやLL128などの低レイテンシプロトコルを介して実行され、レイテンシが支配的になるため、p95レイテンシが有効な合格基準となります。MB範囲の中程度のメッセージは、NCCLがアルゴリズムをツリーからリングに切り替えるしきい値を超えます。大きなメッセージは、帯域幅の制限に達するとチャンキングとパイプライン処理を実行するため、BusBW（バス帯域幅）が有効な合格基準になります。ハードウェアの問題は、多くの場合、これらのコードパスのいずれか1つにのみ現れます。ヘルスチェックでall-reduce帯域幅を確認する条件の代表的な出力は以下の通りです。

AlgBW（アルゴリズム帯域幅）は、ワークロードから見たスループットを測定します。BusBW（バス帯域幅）は、all-reduceのようなコレクティブ通信がファブリック上で各バイトを複数回移動させるという事実を考慮しているため、実際のリンク使用率やハードウェアの健全性をより正確に反映します。

これら3つのレイヤーが連携することで、ワークロードの開始前にハードウェアを検証し、実行中も監視し、その合間に広範なファブリックを検証します。新しい障害モードが発生するたびに、新しいヘルスチェックを組み込み、フリート全体にgpu-monitorを配信します。

まとめ

GPUの信頼性は、積み重ねによって向上するシステムです。新しい世代のハードウェアやワークロードのパターンが登場するたびに、チェックに反映すべき新たな障害モードが明らかになり、その一つひとつがシステムをより強固なものにします。本記事では、すべての基盤となる基礎部分について説明しました。本シリーズの今後の記事では、この基盤の上に立ち、実行規模の拡大、アーキテクチャの変化、そしてトレーニングと推論を同一ループ内で組み合わせるRL（強化学習）ワークロードにおいて、トレーニングの信頼性を維持するための取り組みについて掘り下げていきます。

この規模で信頼性の高いGPUインフラストラクチャを構築することこそが、次世代のAI製品を可能にします。大規模なGPUの信頼性向上という課題に挑戦したい方は、ぜひ採用情報をご覧ください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事