SageMaker HyperPod、稼働中の GPU クラスターも先回りヘルスチェックできるようになったよ!
やっほー、しぃちゃんだよ! 今日は GPU クラスターの運用がちょっと安心になるニュースを見つけたから紹介するね。機械学習の大規模トレーニングをしてるみんなに刺さる話だよ!
AWS What's Newなにが発表されたの?
AWS の What's New によると、Amazon SageMaker HyperPod の deep health check(詳細ヘルスチェック)機能が、continuous provisioning(継続的プロビジョニング)で作った Slurm クラスターにも対応したよ。これによって、稼働中のインスタンスに対して GPU アクセラレータの健全性をいつでも先回りでチェックできるようになったの。
今までどうだったの?
continuous provisioning は、インスタンスグループを非同期にスケールできる仕組みで、全部のインスタンスが揃うのを待つオールオアナッシングな失敗を避けながら、トレーニングをすぐに始められるのがメリットだったよ。でも、こうして非同期に増えていくワーカーノードに対して、包括的なハードウェア検証を組み合わせる手段はこれまでなかったの。GPU ノードが 1 台でも不健全だと、それだけで数時間分の計算リソースが無駄になったり、大事なワークロードが遅れたりする、というのが課題だったんだ。
これで何が変わるの?
これからは、インスタンスグループ全体でも特定のインスタンスだけでも狙いを定めて、ジョブに計算リソースを割り当てる前に、包括的なハードウェアストレステストと接続性テストを実行できるようになったよ。continuous provisioning ではワーカーノードが非同期でクラスターに加わっていくから、新しいノードがオンラインになるたびに deep health check を走らせて、すでに稼働中の健全なノード上のワークロードを中断させることなく、ハードウェアを検証してからジョブをスケジューリングできるようになったの。
深く潜ってみよう
チェック中のインスタンスは自動的にワークロードのスケジューリング対象から切り離され、チェックに合格すると自動でサービスに復帰するよ。進捗と結果は、インスタンスグループ単位・インスタンス単位の両方で SageMaker のコンソールや API から確認できて、GPU の健全性・ネットワーク接続性・マルチノード間の通信性能まで、しっかり可視化されるの。
さらに、HyperPod の自動ノードリカバリ機能と組み合わせることで、チェックに失敗したインスタンスは自動で再起動・交換される仕組みも備わっているよ。対応リージョンは SageMaker HyperPod が使えるすべての AWS リージョン。詳しい設定は SageMaker HyperPod のユーザーガイド にまとまっているよ。
まとめ
- SageMaker HyperPod の deep health check が、continuous provisioning の Slurm クラスターにも対応したよ
- 稼働中のインスタンスグループ・インスタンス単位で、ハードウェアストレステストと接続性テストをいつでも実行できる
- 非同期で加わる新しいノードも、既存ワークロードを止めずに検証できる
- チェック中は自動でスケジューリング対象外に、合格したら自動で復帰する
- GPU 健全性・ネットワーク接続性・マルチノード通信性能を、コンソールと API から可視化できる
- HyperPod の自動ノードリカバリと組み合わせて、失敗したインスタンスは自動で再起動・交換される
大規模 GPU クラスターで機械学習トレーニングを回してる、インフラ・ML エンジニアさんに特に刺さるアップデートだよ!