[re:Invent2023 ざっくre:Cap]Introducing Amazon SageMaker HyperPod

はじめに

みなさんこんばんは！hiropyです。
今回はre:inventで参加したセッションを、英語できないマンなりにざっくり振り返っていこうと思います！

本記事では「Introducing Amazon SageMaker HyperPod」について記載していきます。

翻訳ミス、意図の取り違えがあるかもしれませんが、「こんなことしてたんだ」くらいでご参考にしていただけると幸いです。

セッション概要

• セッション名：AIM362-NEW | [NEW LAUNCH] Introducing Amazon SageMaker HyperPod
• セッションタイプ：Breakout session
• レベル：300

セッションの概要は以下の通りです。

Amazon SageMaker HyperPodは、基盤モデル（FM）のトレーニングを加速させることを目的として作られています。本セッションでは、Amazon SageMaker HyperPodを使用して、数週間から数ヶ月にわたってFMを中断することなくトレーニングする方法をご紹介します。クラスタの健全性を継続的に監視し、障害のあるノードをその場で修復・交換して、進捗を失うことなく自動的にトレーニングを再開する方法をご紹介します。また、SageMakerの分散トレーニングライブラリがあらかじめ設定されており、トレーニングデータとFMを小さな塊に分割してクラスタノード間で並列処理することで、クラスタの計算およびネットワークインフラをフルに活用しながら、FMトレーニングのパフォーマンスを向上させる方法についてもご紹介します。

新しく発表されたAmazon SageMaker HyperPodについて、より詳しく説明していただいたセッションでした！

セッション内容

Amazon SageMaker HyperPodとは

Amazon SageMaker HyperPodは、基盤モデル（FM）をトレーニングするための専用インフラストラクチャで、トレーニングにかかる時間を最大40%削減する。

特徴

• 環境の回復力
  • クラスターは自己修復するため、トレーニング時間を20%以上削減する
  • ハードウェアに異常が発生した時の作業時間を大幅に削減する
• 分散型トレーニングの合理化
  • SageMaker分散型トレーニングのライブラリは、パフォーマンスを20%以上改善する
• リソース利用率の最適化
  • コンピューティング環境やワークロードのスケジュールをコントロールする

活用している事例紹介

Stability AI

オープンソースの生成系AIをリードする会社

ハードウェア異常にかかる数百時間を削減することが課題だった。
これに対しHyperPodは

• 異常を検知した場合は自動でインスタンスを置き換える
• ワークロードは自動的に再開されるので、50%以上のトレーニングにかかる時間とコストを削減できた

Perplaxity AI

初めての会話型QAエンジン

LLMトレーニングのスループットが低いことが課題。

これに対しHyperPodは、

• SageMaker 分散トレーニングライブラリはTensorFlowやPytorchなどの最適化された深層学習モデル用のバックエンドを提供
• スループットを2倍以上に増加させた

クラスターを作成するときのプロセス

1. ネットワークとストレージを作成する
2. ライフサイクルのスクリプトを発行する
3. 必要に応じてカスタマイズする
4. クラスターの設定ファイルを作成する
   • 欲しいコンピュートの種類等
5. クラスターを作成する

HyperPodのアーキテクチャ例

通常の構成は、

• 管理者はエンドポイントからクラスターにアクセスする
• 通常のユーザはsshでクラスタのヘッドノードに接続する
• ヘッドノード配下には、たくさんのEC2インスタンスによるノード群（ウルトラクラスタ？）がある

HyperPod上での分散トレーニング

• トレーニングジョブの送信
  • sbatch を経由してシェルスクリプトを送信することで、長時間のジョブや高コントロールのジョブ、大量のジョブを実行することができる
• 素早く試作
  • sallocを経由してリソースを予約し、コマンドをparallelまたはsrun内でインタラクティブに実行する
• フレームワークやサードパーティのツールを活用することも可能

HyperPodはSlurmによりジョブをスケジューリングすることも可能

ジョブが失敗する原因

• ソフトウェアの問題
  • 設定のミス
  • モデルやコードに問題がある
• ハードウェアの問題
  • ネットワーク
  • コンピュート
  • 基盤そのもの

待機中のジョブを無くしたり、アイドル状態のキャパシティは削減した方がいい

チェックポイントによるジョブの自動修正

定期的にチェックポイントを作成する
問題が発生したらアラートを出し、インスタンスをリストアして再開する

HyperPod上でのソフトウェアの管理

• Docker containerはECRを通じて全てのノードを取得可能である
• Conda?や仮想環境は、共有ファイルシステムにインストールすることで全てのノードからキャッシュなしでアクセスすることができる
• EnrootやPyxisでは、共有ファイルシステムでコンテナをスカッシュファイルに変換する

オブザーバビリティ

CloudWatchやSageMaker Profiler により、モニタリングやプロファイリングが可能。

Hugging face

MLにおけるGithub
モデルやデータセット、ライブラリがたくさんある
https://huggingface.co/

Hugging face上のコンテンツを利用したモデルトレーニングも可能

なぜHyperPodなのか

• クラスターを共有してくれるサイエンティストがたくさんいる
• SLURMパーティションとキューによる100％の利用率
• 自力で回復できる
• 高い修復性
• 自動修復アクション

MLにおいてインフラに時間をかけなくても良いことを紹介した

https://github.com/aws-samples/awsome-distributed-training
AWS ParallelCluster、AWS Batch、Amazon EKSを使った分散モデルトレーニングのリファレンスアーキテクチャとテストケースが公開されているリポジトリ。

さいごに

いかがでしたでしょうか？
少しでも皆様のお役に立てれば幸いです。