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

分散GPUトレーニングは、業界全体で一般的になっています。現在、開発チームは、かつては最先端の研究所だけの領域であった規模で、基盤モデルのトレーニング、最先端スケールのモデルのファインチューニング、大規模なビジョンシステムの構築、ディープなレコメンダーネットワークの実行を行っています。 今日の規模に対応できるGPUインフラストラクチャを構築するには、多くのことを正しく行う必要があります。実行を停止させる障害の検出、表面化しない緩やかなパフォーマンス低下の可視化、数千のリンクにわたるファブリックの健全性の検証、最終的には故障するハードウェアを回避するスケジューリング、そして故障が発生した際のクリーンな復旧などです。これらの多くは基盤となるものであり、スタックの上位にあるより困難な課題はこれらに依存しています。 Databricks AIでは、毎週大規模なトレーニングワークロードを実行しており、ハードウェア、ファブリック、ソフトウェア全体で障害が継続的に発生しています。このシリーズでは、この規模でGPUの信頼性を維持するために必要なことについて説明します。最初の投稿となる本稿では、その基盤として、GPUの実行時に遭遇する障害モード、それらを表面化させる多様なワークロード、そしてそれらを検出する多段階のヘルスチェックシステムについて取り上げます。ここでは最も要求の厳しいワークロードクラスであるトレーニングに焦点を当てますが、同じエンジニアリングがDatabricksにおける推論やその他のGPUワークロードにも役立っています。 トレーニング負荷下におけるGPUの障害パターン 大規模環境におけるGPU障害のほとんどは、ジョブのクラッシュ、サイレントなパフォーマンス低下、数値の破損の3つのカテゴリに分類されます。ジョブのクラッシュは、発生したことがすぐにわかるという意味で、簡単なケースです。より困難な障害は、モデル内の数値が誤った状態で完了するワークロードや、誰にも気づかれずにパフォーマンスが低下した状態で何時間も実行されるワークロードです。 ジョブのクラッシュ。 分散トレーニングジョブがクラッシュする理由は、GPUの劣化やバスからの脱落、RDMAファブリックの問題、I/Oシステムのハング、CPU側のランクが他から乖離することなど、多岐にわたります。ワークロードの観点からは、これらのほとんどすべてが同じ現象として表面化します。つまり、ログに恐ろしい NCCL watchdog timeout メッセージが表示されてジョブがクラッシュするのです。すべてのランクが同じコレクティブ通信でブロックされ、ウォッチドッグが最終的にジョブを強制終了し、最後のチェックポイントから再起動することになります。しかし、タイムアウト自体は根本原因についてほとんど何も教えてくれません。実際に何が問題だったのかを診断するには、症状のみを示すスタックトレースから、ハードウェア、ファブリック、ファイルシステム、ソフトウェアの各レイヤーをトレースしなければならないことがよくあります。 [rank40]:[E528 07:41:00.999322155 ProcessGroupNCCL.cpp:688] [Rank 40] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=8...