re:Invent 2025: SageMaker HyperPod CLI/SDKでAIモデル構築とデプロイ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Build, fine-tune & deploy AI models with SageMaker HyperPod CLI & SDK (AIM371)
この動画では、Giuseppe A. PorcelliとArun NagarajanがAmazon SageMaker HyperPodのCLIとSDKを使用したAIモデルの構築、ファインチューニング、デプロイについて解説しています。HyperPodは数千個のアクセラレーターまでスケール可能で、高度な復旧機能を備えた永続的なクラスター管理サービスです。EKSオーケストレーションとSlurmの2つのオプションがあり、本セッションではEKSに焦点を当てています。HyperPod CLIはオープンソースプロジェクトで、kubectlよりも抽象化されたインターフェースを提供します。training operatorは超高速な障害復旧、custom monitoring、task governanceとの統合を特徴とし、inference operatorは簡素化されたデプロイメント、自動スケーリング、ALBやSSL証明書の自動セットアップを提供します。task governance機能により、優先度設定やチーム間のコンピュートリソース割り当て、借用と貸与の設定が可能です。最近リリースされたspaces機能では、SageMaker Code EditorやJupyter LabをHyperPodクラスタ上で実行でき、VS Code remoteやWeb UI経由でアクセスできます。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション開始：SageMaker HyperPodを使ったAIモデル構築の全体像
こんにちは。本日はこのセッションにご参加いただきありがとうございます。SageMaker HyperPod、CLI、SDK を使用した AI モデルの構築、ファインチューニング、デプロイについてのセッションです。私は Giuseppe A. Porcelli で、SageMaker AI サービスチームの Principal ML Solutions Architect として働いています。過去数年間、複数のお客様と協力して、HyperPod 上で LLM のトレーニングとファインチューニングを行い、大規模な推論を実行してきました。本日は、HyperPod の設計に深く関わり、本日お話しする機能の開発に携わった Principal Software Engineer の Arun Nagarajan と一緒にお話しします。
では、このセッションのアジェンダを見ていきましょう。まず SageMaker HyperPod の紹介から始めて、コンテキストを設定し、HyperPod が何であるか、そして製品の主な利点が何であるかを説明します。その後、Amazon SageMaker HyperPod CLI と SDK を見て、なぜこの CLI を構築したのかについて説明します。その後、HyperPod の使い始め方に関する一連のデモとライブコーディングに入ります。クラスターの作成方法、クラスターへの接続方法、AI モデルのトレーニング方法、デプロイ方法、そして HyperPod タスクガバナンスを使用したリソース利用の最適化方法が含まれます。最後に、SageMaker HyperPod 上で IDE とノートブックを実行できる機能もデモンストレーションします。これは数日前にリリースした機能です。最後に、リソースを共有します。本日実行するすべてのコードは、セッション終了時にダウンロードできます。
SageMaker HyperPodの紹介：復旧力とスケーラビリティを備えた永続的クラスター
では、SageMaker HyperPod の紹介を始めましょう。 Amazon SageMaker HyperPod は、ファウンデーションモデルのトレーニングとデプロイのための永続的なクラスターを管理・運用できるサービスです。数千個のアクセラレーターまでスケールアップでき、HyperPod は効率性の向上をもたらします。HyperPod には、クラスター上のコンピュートリソースの利用を最適化するのに役立つ機能があります。全体的にトレーニング時間を削減できます。HyperPod は高度な復旧機能を備えており、障害からの回復に役立ちます。大規模なトレーニングやファインチューニングを実行する場合、ハードウェア側、ネットワーク側、GPU 側で障害が発生する可能性があります。HyperPod には、これらの障害から回復するための組み込み機能があります。全体的な目的は、ファウンデーションモデルの事前トレーニング、ファインチューニング、推論のコストを削減することです。
では、HyperPod の利点についてもう少し詳しく説明しましょう。 HyperPod は復旧力があります。このサービスは、クラスターの一部であるインスタンスに対して継続的なヘルスチェックを実行し、GPU 障害やネットワーク障害などの障害が検出された場合、検出された障害のタイプに応じて、インスタンスの置き換えやインスタンスの再起動などの適切な修復アクションを実行します。HyperPod は高度にスケーラブルです。シングルスパインノードトポロジーでノードをデプロイして低レイテンシーを実現できます。ノードには高いネットワーク接続性のための事前設定済み EFA が付属しており、これは特に集合操作を実行する場合に非常に重要です。全体的に、HyperPod のマネージド自動スケーリングサポートのおかげで、クラスターのスケールイン、スケールアウトの両方を実装でき、自動的に実行することもできます。
HyperPod は非常にカスタマイズ可能です。ハードウェア側からワークロード実行に使用するライブラリとフレームワークまで、HyperPod 上のスタック全体を制御できます。必要に応じてクラスターノードに SSH で接続して、ノード上で必要なことを何でも実行できます。HyperPod は非常に効率的なサービスです。タスクガバナンス機能との統合のおかげで非常に効率的です。この機能は、優先度を定義して、チーム間でコンピュートリソースを割り当てるのに役立ちます。これについてもデモンストレーションします。また、AWS 上のマネージド Prometheus と Grafana スタックのような可観測性ソリューションとも統合されています。
HyperPodのカスタマイズ性とEKSベースのアーキテクチャ
HyperPod のカスタマイズの可能性についてですが、クラスタの設定を本当に自由に変更でき、あらゆるレイヤーでカスタマイズができます。ハードウェア側では、コンピュートオプションの選択肢と、ストレージの選択肢があります。S3 から直接トレーニングしたい場合もあれば、FSx for Lustre のような高性能な分散ファイルシステムを使いたい場合もあるでしょう。PyTorch、TensorFlow、JAX など、好みのフレームワークを選択できます。さらに、好みの実験トラッキングソリューションに接続することもできます。
AWS では管理型の MLflow を提供していますが、Weights and Biases のようなサードパーティのソリューションを使いたい場合は、もちろんそれもできます。重要な点は、HyperPod では 2 つのオーケストレーションオプションから選択できるということです。一方では、Slurm の経験を好む人のために Slurm を使用できます。もう一方では、HyperPod は Amazon EKS と自動的に統合され、ノードに対して Kubernetes ベースのオーケストレーションを提供します。そして、それがこのセッションの焦点です。
EKS でオーケストレーションされたクラスタに焦点を当てます。そのために、私たちは HyperPod Alliance を構築しました。これが重要なポイントです。高レベルでは、HyperPod でオーケストレーションされたクラスタのアーキテクチャは、スライドの右側に見えるようなものです。HyperPod マネージドノードが見えます。つまり、このサービスがコンピュートノードの管理を担当します。HyperPod EKS クラスタをデプロイすると、アカウント内に EKS クラスタも作成されます。これが HyperPod マネージドノードのオーケストレータとして機能します。
ユーザーはこのクラスタが提供する Kubernetes API を使用して相互作用します。その相互作用はどのクライアントからでも発生する可能性があります。SageMaker Studio を使用することもできますし、自分のマシンの自分のターミナルを使用することもできます。実は、今日はそれをやってみようと思っています。一方、管理者側では、Kubernetes API を使用してクラスタを設定し、クラスタをセットアップすることができます。既に述べたように、AWS Systems Manager Session Manager のセキュアな接続をクラスタノードに確立できるので、ノードに SSH で接続して、必要に応じてノードを設定できます。
ストレージの側面では、ストレージはあなたのアカウントで設定されます。なぜなら、そこにあなたのデータが存在するからです。S3 を使用することもできますし、FSx for Lustre を使用することもできます。あるいは、すでに述べたように、あなたのアカウントで実行されている任意のファイルシステムに接続することもできます。HyperPod クラスターがデプロイされると、elastic network interfaces があなたのアカウント内の VPC に作成され、その VPC からは必要に応じて自分のストレージソリューションに接続することができます。
HyperPod CLIとSDKの構築理由：抽象化されたインターフェースの提供
それでは HyperPod CLI と SDK に移りましょう。そして、なぜ私たちが別の CLI と SDK を構築したのかについてです。別の理由というのは、Kubernetes クラスターで作業するには kubectl、つまり Kubernetes CLI を使用して、そこでコマンドを実行することができるからです。しかし、私たちが顧客、データサイエンティスト、研究者から受け取ったフィードバックは、kubectl を使用することは確かに問題ないのですが、非常に複雑だということです。YAML 設定ファイルを管理し、それらのファイルを編集してから、ワークロードを送信する必要があります。
このプロセスに精通している人にとっては非常に簡単かもしれませんが、時々データサイエンティストはより抽象化されたインターフェースを探していました。それは彼らが実行しているワークロードのタイプ、つまり GenAI ワークロードにより近いものです。これは Kubernetes の汎用的なデプロイメントのようなものではありません。それに加えて、SDK ベースのインターフェースでより プログラマティックなインターフェースを好むユーザーもいれば、コマンドラインインターフェースを好むユーザーもいます。そのため、私たちは CLI と SDK を一緒にもたらす新しいソリューションを構築しました。そしてもちろん、HyperPod で利用可能な observability 機能をより活用するためでもあります。
HyperPod CLI はオープンソースプロジェクトであり、GitHub の SageMaker HyperPod CLI リポジトリで利用可能です。hyp コマンドと CD を実行する例を help で見ることができます。これは CLI で実行できるアクションへと導きます。アーキテクチャの側面では、このスライドから重要なのは、それがレイヤード アーキテクチャであるということです。
一番上のレイヤーにはユーザーエクスペリエンスレイヤーがあります。これは CLI でコマンドを実行するための hyp コマンドか、あるいは SDK を使って HyperPod を操作するために import sagemaker.hyperpod を使うかのどちらかです。その下には CLI と SDK のコアモジュールがあります。CLI のコアモジュールは実際の CLI コマンドを実装しています。SDK のモジュールは、その後 Kubernetes クライアントに送信されるリクエストを構築する責任を持っています。
ここで重要なのは、CLI コマンドのために SDK モジュールをどのように再利用しているかということです。CLI は SDK の上に構築されているので、コマンドを実行するために SDK を使用しています。SDK は Kubernetes クライアントを使用して、その後 Kubernetes API に対してコマンドを実行します。
右側のピンク色の部分にはテンプレートが表示されています。テンプレートは、クラスターにインストールされている様々なオペレーターによって定義されたカスタムリソース定義の CLI での表現です。これらのテンプレートはバージョン管理されているので、オペレーターが当社側で更新されても、以前のバージョンのオペレーターで CLI を使い続けることができます。必ずしも最新バージョンにアップグレードする必要はありません。
クラスター作成のデモ：簡略化されたセットアップ体験とCLIの実践
まず、HyperPod クラスターを作成する必要があります。 クラスター作成の体験では、ネットワーク、ストレージレイヤー、セキュリティ、そして実際のコンピュートなど、こうした高度な環境をセットアップするために多くのことを検討する必要があります。このプロセスを簡素化するために、私たちは最近 AWS コンソールから簡略化されたクラスター作成体験をリリースしました。このクラスター作成体験では、クイックセットアップを使用することができます。これはインフラストラクチャ側に対して意見を持ったデフォルト設定が付属しており、例えば VPC をセットアップする方法やクラスターの CIDR レンジをどのように設定するかなど、クラスターのスケールに応じて、マシンに十分な IP アドレスが利用可能であることを確認できます。
これらすべてのことは事前に設定されているため、簡単にクラスターをスピンアップできます。ただし、設定をチューニングしたい場合は、カスタムセットアップに移動することができます。カスタムセットアップでは、クラスターの設定で何を有効にするか、または何を変更するかを決定できます。例えば、デフォルトでインストールされたくない特定のオペレーターがある場合や、ネットワーク設定、ストレージなどを変更したい場合などです。CLI と SDK をインストールするには、環境で pip install sagemaker-hyperpod を実行するだけです。
コードに移りましょう。実際の例に入る前に、今日使用するクラスターをお見せしたいと思います。 SageMaker コンソールにいます。HyperPod クラスターに移動することができます。ここで 3 つのクラスターが実行されています。2 つは EKS オーケストレーション、1 つは FLRM オーケストレーションです。 このクラスターを使用します。ML cluster AIM 371 です。 コンソール画面から、HyperPod ノードのオーケストレーターとして機能している対応する EKS クラスターも確認できます。 ここではすべての設定を確認できます。これには可観測性の設定も含まれており、クラスターから Prometheus と Grafana にエクスポートすることにした メトリクスを示しています。
重要なのは、インスタンスグループの設定も確認することです。 ここに 2 つのインスタンスグループがあります。1 つは G5 12xlarge インスタンスで、各インスタンスに 4 つの NVIDIA A10G GPU が搭載されており、もう 1 つはクラスター内にいくつかのコンピュート CPU ノードもあります。ここの詳細から確認できるように、すべてのノードが実行されています。G5 12xlarge が 4 つと T3 2xlarge インスタンスが 6 つです。
では、VS Code に移りましょう。今からお見せするコードは、後でダウンロードできます。これはモジュール化された例で、まず始めるところから始まり、その後トレーニング、推論、タスクガバナンスの例に進み、その後スペース、つまり HyperPod 上で IDE を実行することに進みます。 まず最初のモジュールの始めるところから始めましょう。 クラスターをセットアップする方法と、これまで説明してきたすべてのことが表示されます。これに時間をかけたくはありませんが、CLI をインストールする方法です。 HyperPod CLI をインストールした仮想環境を作成したこのディレクトリにいます。実際に、hyperpod コマンドを実行すると、CLI に関するさまざまなヘルプ情報が出力として表示されるはずです。
また、hyperpod --version というコマンドを実行して、インストールされている CLI のバージョンを確認することもできます。 先ほど述べたように、CLI で利用可能なテンプレートのバージョン管理は重要です。 では、自分のアカウントにある様々なクラスターを見てみましょう。list cluster オペレーションは、自分のアカウントで利用可能な EKS でオーケストレーションされたクラスターをリストアップします。ご覧のように、AIM 371 と、自分が持っている他の ML クラスターがあります。
このクラスターで作業を始めるために必要なことは、クラスターコンテキストを設定することです。 これは本質的には、ローカルの Kubernetes 設定を更新して、Kubernetes API に対して API コールを正しく実行できるようにすることを意味します。 このコマンドを実行すると、ローカルの Kubernetes 設定が更新され、コマンドを実行する準備が整います。
現在のクラスターコンテキストが何であるかを確認したい場合は、get cluster context コマンドを実行するだけで、どのクラスターで作業しているかが正確にわかります。
クラスターには必要なすべてのオペレーターとアドオンが事前にインストールされているため、training operator のセットアップや task governance のセットアップなど、これらのステップはスキップできます。 ここで言及したいのは、このクラスターには FSX ファイルシステムが接続されており、そこにデータとトレーニングコードが保存されているということです。 これは今後のトレーニング例の参考のためです。このクラスターは Data Repository Association で設定された FSX で構成されており、これは FSX ファイルシステムと S3 バケット間の一種の同期です。S3 に書き込まれたものは FSX ファイルシステムで利用可能になり、その逆も同様です。双方向の同期です。
初期セットアップを確認したので、CLI を使用して HyperPod クラスターを作成するステップに進みましょう。最初にできることは、このコマンドを実行してクラスター作成オペレーション用の作業ディレクトリを作成することです。hyp init cluster-stack コマンドを実行できます。 hyp init オペレーションは、ローカルディレクトリに 2 つのファイルを作成します。1 つは config.yaml で、もう 1 つは CloudFormation テンプレートパラメーター用の Jinja テンプレートです。先ほど述べたように、HyperPod クラスター作成エクスペリエンスは背後で CloudFormation に基づいています。クラスターを作成する場合、AWS コンソールを使用するか CLI を使用するかに関わらず、アカウントに CloudFormation テンプレートをデプロイしています。これは一貫しているため、UI または CLI のどちらのインターフェースを使用しても、同じエクスペリエンスが得られます。
ここで CLI がやっていることは、CloudFormation テンプレートのデプロイに必要な値をダウンロードしていて、これらは Jinja テンプレートでテンプレート化されています。Jinja は本質的にはテンプレーティングフレームワークです。ここのパラメータを見てみましょう。これは非常に複雑なパラメータセットで、アベイラビリティゾーンの設定、VPC 内に NAT ゲートウェイが必要かどうか、デプロイしたいインスタンスグループ、そしてファイルシステムの設定、FSX をどのアベイラビリティゾーンにどのサブネットを通じてデプロイするかなど、といったことが含まれています。
一方、config.yaml があります。config.yaml はより抽象化された設定ファイルで、コンソールで見つかるのとほぼ同じコントロールを提供します。config.yaml ここで利用可能なものがあります。例えば、クラスタで使用したい Kubernetes のバージョンを変更することができます。あるいは、クラスタにインストールされているオペレータを変更することもできます。インスタンスグループの設定を変更することを決定できます。例えば、この例では、単一の T3 medium インスタンスをデプロイしているだけです。インスタンス数は 1 で、インスタンスタイプは ml.t3.medium です。つまり、クラスタ内の 1 つのインスタンスグループに 1 つのインスタンスがあるだけで、以下同様です。VPC の設定なども設定できます。
CLI 側では、2 つのオプションがあります。好みのエディタで config.yaml を編集するか、または hyp configure というコマンドを使用してそのファイルを自動的に編集することができます。例えば、ここでは Kubernetes バージョンを 1.33 に更新しています。更新されたことが確認できます。その後、hyp validate を実行して、設定にエラーが含まれていないことを検証できます。最後に hyp create を実行すると、クラスタ作成がトリガーされます。注意すべき点は、ここで作成される run ディレクトリ内に、評価された CloudFormation パラメータ、つまりパラメータが実際の値に置き換えられたテンプレートも見つかるということです。これは参考用で、例えば、クラスタをどのように設定したかを覚えていない場合に便利です。CLI で作業する際にファイルシステムで利用可能な軽量な実験追跡ソリューションのようなものです。
クラスタ画面に戻ると、実際に新しいクラスタが作成されているのが見えます。ここにあります、HyperpodClusterStack で、作成が進行中です。CloudFormation に移動することで進捗を監視できます。ここにいくつかのテンプレート、いくつかのスタックがデプロイされているのが見えます。これはメインスタックの HyperpodClusterStack で、その後、VPC など、デプロイする必要があるさまざまなコンポーネント用の複数のネストされたスタックがあります。
これでクラスタ作成のデモは終了です。クラスタ作成には時間がかかるため、待つことはしません。次のトピックに進みましょう。それはトレーニングについてです。
Training Operatorによる分散トレーニング：超高速障害復旧とカスタム監視
ありがとうございます、Giuseppe。HyperPod には training operator が付属しており、これは AWS 向けにゼロから構築された高度なエンドツーエンドのトレーニングシステムです。training operator がサポートしている主な機能をいくつかハイライトしたいと思います。
まず1つ目は、超高速な障害復旧です。従来のトレーニングシステムでは、障害が発生するとコンテナとイメージが破棄されてしまい、すべての初期化作業が失われてしまいます。HyperPod の training operator はより賢く設計されており、障害が発生してもコンテナを破棄しません。つまり、GPU の障害が発生したり、ネットワークの問題が起きたりしても、トレーニングジョブが初期化処理で長時間停止することがありません。従来は数分かかっていたものが、数秒で済むようになります。
次に、operator は custom monitoring と呼ばれる機能をサポートしています。これが意味するところは、GPU の問題やネットワークの問題を含むインフラストラクチャの障害を監視することに加えて、operator はトレーニングジョブのログで発生している障害を監視するように設定することができるということです。例えば、ジョブが停止して進行していない状況に遭遇したことがあるかもしれません。あるいは、損失曲線が急激に上昇したり、トレーニングジョブの進行を妨げる他の問題が発生したりすることもあります。operator には、監視したい内容を指定する機能が備わっており、設定を行うだけで operator があなたの代わりに監視してくれます。
3つ目に、operator は task governance system とも統合されており、これについては後ほど少し説明します。これにより、貴重な GPU リソースの利用率を最大化するのに役立ちます。このような背景を踏まえて、これがコードでどのように実現されるのかを見てみましょう。
ここで見ているのはトレーニングデータセットです。テキスト補完だけでなく、ユーザーからのクエリを読み取り、どのようなツールを呼び出す必要があるかを判断し、その後、モデルが経た思考プロセスを音声で読み上げるモデルをトレーニングしようとしています。このトレーニングデータセットは少し読みにくいので、特定の例を1つ取り出してみました。システムプロンプトがあるのが見えます。その後、エージェントが利用可能なツールを紹介しています。
ユーザーがプロンプトを入力すると、アシスタントが特定のツールを呼び出すことにしました。そしてここがツールのレスポンスです、このツールレスポンスに基づいて、アシスタントは要求したさまざまなフィールドを読み取り、ユーザー向けのメッセージを構築してからユーザーに送信します。その後ユーザーがフォローアップの質問をして、このマルチターンのやり取りが続いていきます。これが一つの例で、今日のデモではこのデータセットを使用して Qwen 3 モデルをトレーニングします。
Giuseppe がインフラレベルでクラスタを作成するのがいかに簡単かを示してくれました。しかし分散トレーニングの側面はどうでしょうか。どのようなフレームワークを使用するのか、そのイメージをクラスタにどのようにして取り込むのか、そして Kubernetes でジョブをどのように送信または実行するのかを理解する必要があります。HyperPod operator はすべてをシンプルな単一コマンドに簡略化します。私は以前トレーニングデータセットを S3 にアップロードしておきました。データセットがまだあるかどうか素早く確認させてください。トレーニングデータセットと検証データがあります。
ECR イメージも確認します。ここに ECR イメージがセットアップされています。それでは、このジョブを送信します。このコマンドでジョブを実行します。以上です。このジョブを送信すると、CLI が行うことは適切な Kubernetes スペックファイルを構築してクラスタに送信することです。G5 インスタンスタイプの 2 ノード、ノードあたり 4 タスク、つまり 4 つのトレーニングプロセスを要求したこと、データの取得方法などを指定したことが見えます。では、このジョブに何が起きたかをこのクラスタ内のすべてのジョブをリストして確認しましょう。
送信したジョブが既に実行中であることが見えます。素晴らしいですね。このジョブについてさらに詳しい情報を取得しましょう。このジョブが 2 つのレプリカを要求し、2 つのポッドが実行中で、ノードあたり 4 つのプロセスがあることが見えます。作成され、ポッドが実行を開始し、トレーニングジョブ自体が実行中です。次のレベルの詳細は、ポッド自体を見たい場合です。list pods コマンドを実行できます。これは要求した 2 つのポッドを教えてくれるはずです。
次にポッドログを見ることができます。これは基本的にはトレーニングジョブのログで、そこで何が起きているかを確認できます。初期化が完了し、チェックポイントが読み込まれ、トレーニングが開始されていることが見えます。まとめると、この operator が行ったことは、単一のコマンドで、トレーニングイメージと必要な設定を指定したことです。operator は Kubernetes 上で実行するために必要なさまざまなトレーニングポッドを起動しました。ポッドがヘルスメッセージで大丈夫かどうかを確認することで、多くの重い処理を行っています。ここで見ているこれらのヘルスメッセージはすべて、operator 側からのヘルスチェックが各ポッドに到達して、それらが大丈夫かどうかを確認しているものです。ノードのいずれかが調子悪い場合、システムはそれを修復するのに役立ちます。
フォルト耐性についてお話しすると、本番環境でフォルトが検出された場合に何が起こるかを観察したいとしましょう。HyperPod ノードには health agents が搭載されており、フォルトが発生しているかどうかを自動的に識別し、ノードを交換対象としてフラグを立てます。ただし、このデモでは手動でそれを行おうと思います。実行中のすべてのポッドを見てみましょう。これら 2 つのポッドは、トレーニングジョブを通じて起動したばかりのポッドです。このノードを障害ノードとしてマークしようとしています。Kubernetes ラベルを適用して、このノードを失敗状態で再起動待ちとしてマークします。 繰り返しになりますが、通常はこれはシステムによって自動的に処理されますが、デモの目的のために、オペレーターがどのように対処するかを観察できるようにラベルを付けています。
では、ポッドに何が起こるかを確認してみましょう。917 で終わるこのノードにフラグを立てたことを思い出してください。同じポッドが別のノードにスケジュールされ、既に実行中のステータスになっているのが見えます。ジョブ自体を記述して、記録されたステータスを確認してみましょう。それを行うと、 オペレーターが制御外で発生したノード障害を観察し、6.5 秒以内に修復したことが確認できます。
これがオペレーターが提供する重要な機能です。システムで障害が発生することを心配する必要はありませんし、ランダムな GPU が突然停止してトレーニングジョブが失敗するのを修正するために午前 3 時に起きる必要もありません。
ジョブを送信するための別の初期化方法を見てみましょう。これは Giuseppe も示しました。この場合、 トレーニング用です。これはすべてのオペレーターに共通するパターンで、ディレクトリを作成してから、 作業したい特定のタイプに対して init を呼び出します。CLI はこれらのテンプレートファイルを作成してくれます。 ここを開くと、いくつかの詳細が表示されますが、すべて空白です。 ただし、configure コマンドで入力することも、エディターで直接編集することもできます。
では、このコンフィグファイルを簡単に確認してみましょう。指定した 2 つのフィールド、job name と image は既に入力されています。 validate を実行してから create を実行してジョブを送信できますが、今は実行しません。ここまで、 CLI 抽象化についてお話ししてきました。SDK 抽象化も紹介したいと思います。ここで見えるのは、 CLI インターフェースに加えて、すべてのインターフェースに対して Pythonic SDK 実装も用意されているということです。 例えば、標準的な Python の動作でインポートできます。Notebook を使用することもできますし、 このの上に構築したいオートメーションがある場合は、これに対して標準的な Python コードを書くことができます。
こちらが HyperPod PyTorch ジョブ クラスで、これをインスタンス化して、私たちが話した様々な設定をすべて提供することができます。そして最後に、create を呼び出すだけでジョブを簡単にサブミットできます。 list 操作、status 操作、pod log 操作など、先ほど見たすべての機能は SDK インターフェースを通じても利用できます。
これで training operator のデモは終わりです。inference operator に進む前に、HyperPod CLI または SDK を使ってトレーニングジョブをサブミットするのがいかに簡単だったかをまとめておきたいと思います。そして、フォルトリカバリーについて心配する必要がなかったということです。フォルトリカバリーは本当に高速です。Giuseppe が共有してくれたレイヤー図を思い出してください。これはすべて Kubernetes、例えば kubectl の上に構築されたレイヤーです。もし必要であれば、いつでも Kubernetes レベルのコマンドに落とし込むことができます。例えば、pod を取得したい場合、それはまだ利用可能です。高度なユーザーで kubectl を使いたい場合、それでも問題ありません。
Inference Operatorによるモデルデプロイ：本番規模のエンドポイント構築
しかし、その上に構築できる抽象化が必要な場合は、CLI と SDK を用意しています。では inference operator に進みましょう。機能を示すスライドがありますが、エンドポイントの作成をキックオフしたいと思います。これには数分かかるので、うまくいけば完了するのを見る時間があるでしょう。ですから、作成したジョブを削除して、そのジョブが削除されたことを確認します。もうそのジョブはありません。これで inference デプロイメントをキックオフする準備ができました。
config 方式を使うつもりで、すでに config はブートストラップされているので、validate と create を実行するだけです。これでクリエーションがキックオフされます。これには数分かかるので、後ほど戻ってきます。
HyperPod には inference operator が付属しており、これが AI モデルをデプロイしてスケールする方法です。inference operator が提供する重要な機能をいくつか強調したいと思います。まず 1 つ目は簡素化されたデプロイメントです。HyperPod operator は、あなたがトレーニングしたカスタムモデルや SageMaker JumpStart の事前定義モデルをデプロイするだけでなく、本番規模の inference エンドポイントに必要なすべてのインフラストラクチャも作成します。例えば、ALB をセットアップしてアプリケーションに公開する必要があり、その後 SSL 証明書とターミネーションに対処する必要があり、さらにオートスケーリングポリシーに対処する必要があります。これらすべてが inference operator によって 1 つのコマンドで処理されます。
次に、ヒントを出しましたが、あなたのモデルが FSx や S3 にあるか、それとも訓練済みのモデルか、あるいは SageMaker の組み込みモデルを使いたいのか、そういったオプションはまだあなたが選択できるようになっています。3 番目は自動スケーリングのサポートで、推論オペレーターが CloudWatch や Prometheus のメトリクスと統合されており、スケーリングイベントを監視して自動的にスケールしてくれます。このオペレーターは HyperPod の Karpenter 自動スケーリングとシームレスに連携し、必要に応じてインスタンスをプロビジョニングします。
最後に、異なるオーディエンスに対して異なるフローを用意できるという考え方です。例えば、データサイエンティストと ML エンジニアは HyperPod CLI と SDK を使用できます。これについては少し後でデモを行いますが、エンドポイントを作成できます。これにより SageMaker エンドポイント、ALB コントローラー、KEDA、そして FSx、S3、メトリクスとの統合が作成されます。これらすべてが 1 つのコマンドで処理されます。すべてのセットアップが完了して準備ができたら、アプリケーション開発者は ALB に直接アクセスするか、SageMaker エンドポイント経由でアクセスして、モデルに対して実際の推論を実行できます。
では、デモに切り替えましょう。エンドポイント作成の説明を急いでしまいましたが、少し戻ってみましょう。私たちが行ったのはカスタムモデルをデプロイすることで、そのモデルがデプロイ元の S3 バケットに存在することを示します。これが現在デプロイしているモデルです。私が行ったのは設定ファイルを使ったデプロイ方法で、CLI を使った同等のデプロイ方法も利用可能です。ここではエンドポイント名、モデルの場所、例えば今回は S3 から取得したもの、バケット名、モデルの場所、インスタンスタイプ、そしてイメージ URI を指定できます。このイメージは SageMaker から直接取得したもので、DJL コンテナからのものです。
エンドポイントの準備ができたら、それに対して推論を実行できるようになります。しかし、数分前に作成したエンドポイントで何が起こっているのか確認してみましょう。このクラスター内のすべてのエンドポイントをリストアップしようとしています。デプロイメント完了と表示されています。これはポッドが実行状態にあるはずということを意味しています。推論オペレーター自体の内部オペレーターログも確認できます。メトリクスが有効になっていることが見えます。
メトリクスが有効になっており、推論エンドポイントの設定がすべて設定されているのが見えます。また、カスタムエンドポイントCRD の詳細ログも確認できます。ここで見えるのは、デプロイメントとポッドが正常に完了していますが、フロントエンドエンドポイント、つまり SageMaker エンドポイントはまだ作成中ということです。それが完了するのを待つ間に、いくつかのポッドを見てみましょう。推論を実行する準備ができているポッドがあります。ポッドのログを見ると、初期化が完了してモデルが読み込まれているのが分かります。モデルが読み込まれて、ワーカースレッドが開始されたのが見えます。ポッド側ではエンドポイントの準備ができています。SageMaker エンドポイントが完成するまで待つだけで、その後は推論を実行できます。ほら、SageMaker エンドポイントが作成されました。これで簡単な呼び出しができます。チャット完了が返ってきて、推論エンドポイントが稼働しています。
推論のデモはこれで終わりです。推論デプロイメントのもう一つの方法があります。時間がないかもしれませんが、S3 から推論デプロイメントを行ったのと同じように、SageMaker の JumpStart からも行うことができます。その場合、モデル ID を指定するだけで、システムが自動的にすべてのモデルアーティファクトをダウンロードしてデプロイしてくれます。まとめると、単一のコマンドで、システムがロードバランサー、オートスケーリングコントローラー、メトリクス、ログ、そして Kubernetes へのデプロイメントの開始など、セットアップに必要な重い処理をすべて自動的に処理してくれるということです。すべてがそのままで提供されます。
HyperPodタスクガバナンス：優先度設定とコンピュートリソースの最適化
オートスケーリングイベントを呼び出したり強制したりする例もありますが、今はスキップします。デモの次の部分は Giuseppe が担当します。削除できますか？素晴らしい。では、今回のトークの前半で述べたように、HyperPod はクラスター上のコンピュート利用率を最適化するための組み込み機能を提供しています。これは HyperPod タスクガバナンスのおかげです。HyperPod タスクガバナンスを使うと、クラスターレベルでポリシーを定義し、ワークロードに対して複数の優先度を設定できます。この例では、推論の優先度が実験やトレーニングの優先度よりも高いのが見えます。これにより、ワークロードを異なる方法で処理でき、優先度の高いワークロードは優先度の低いワークロードをプリエンプトするように設定できます。同時に、クラスターで利用可能なコンピュートリソースをさまざまなチームに割り当てる方法を決定できます。
チームは Kubernetes の namespace に対応しています。つまり、「チーム A には一定数のインスタンスが割り当てられている」と言うわけです。インスタンスのコンピュートリソース、例えば X 個の GPU、メモリ、CPU リソースなどです。または、さらに細かく設定することもできます。つまり、特定の数の GPU だけ、または特定の量のメモリ、特定の数の vCPU だけです。両方のオプションが利用可能です。インスタンス全体のリソースと細粒度のリソースの両方です。
このセットアップのおかげで、コンピュート容量の借用と貸与の方法も設定できます。例えば、チーム A がクラスターにアイドル状態のコンピュート容量がある場合、自分のコンピュート容量の 100% を借用できるのが見えます。これは、例えばチーム B がクラスター内のコンピュートリソースを利用していない場合、そのリソースがアイドル状態にあるとき、チーム A がこれらのコンピュートリソースを借用できるということです。チーム B が保証されたコンピュートリクエストで戻ってきて、チーム B に保証されたクォータが必要になると、チーム A のジョブはプリエンプトされます。これから実際にそれをデモンストレーションします。コードに戻りましょう。
タスクガバナンスセクションの例に入っています。いくつかの変数を設定していきましょう。 先ほど実行したのと同じトレーニングジョブを使用しますが、異なる方法で設定して、異なる優先度を割り当て、異なるチームによってジョブを実行します。クラスタをすばやく確認するために戻ると、 クラスタがポリシー側で設定されていることが分かります。画面で見たのとほぼ同じ優先度クラスが設定されているのが見えます。そして、コンピュートアロケーションがあります。
特定のチームのコンピュートアロケーションに移動すると、Team B には チームに割り当てられたインスタンスが1つだけあることが分かります。つまり、ml.g5.12xlarge で、4つの GPU がこのチームに割り当てられています。彼らはコンピュートの100%を借りることができ、Team A は 同じ方法で設定されています。彼らは1つのインスタンスの保証されたコンピュートを持っており、彼らはコンピュートリソースの100%を借りることができます。 つまり、別のインスタンスのコンピュートリソースです。
では、コードに戻りましょう。例を示すことができます。 ご覧のように、コマンドはほぼ同じです。ここで設定しているのは、このワークロードを実行したい namespace を定義しており、これはコンピュートリソースが割り当てられているチームに対応しています。local queue は、task governance が動作し、Karpenter と統合されています。Karpenter は Kubernetes の人気のあるスケジューラで、適切な方法で Karpenter を設定するためのレイヤーを提供しています。そして、このジョブのトレーニング優先度を設定しています。
では、このコードを実行しましょう。 このジョブを実行します。 すべてをコピーしたかどうか確認します。実は、間違っていました。 よかった、ジョブが実行されています。このリストコマンドを実行して、ジョブが実行されていることを確認できます。 ご気づかもしれませんが、2つのインスタンスでジョブを実行しましたが、このチーム Team A には1つのインスタンスだけが割り当てられていました。つまり、この時点で Team B からコンピュートを借りているということです。
それが本当かどうか確認しましょう。 キュー側でこのコマンドを実行できます。まず第一に、必要に応じてジョブを説明し、ジョブの詳細を確認して、ジョブが正しく実行されているかどうかを確認することもできます。はい、実行されています。そして、このキューコマンドを実行することができます。これは クラスタキューを調べ、4つの GPU を借りていることが分かります。先ほど述べたように、このチームは1つ以上のインスタンスにアクセスでき、これは搭載されている4つの GPU なので、このジョブで4つの GPU を借りています。
では、Team B が 1 つのノードだけでジョブ を送信したいというシナリオをシミュレートしてみましょう。これは彼らの保証されたコンピュート、つまり保証されたクォータです。このタスクを実行してみます。これで、期待通りの結果が見えるはずです ：Team A のジョブは先制されたため中断状態にあり、Team B のジョブが作成されて実際に実行されています。もう 1 つできることは 、より低い優先度のタスクを先制することです。Team B 内では、より高い優先度のタスクが開始されます 。これは experimentation 優先度を持っており、training 優先度より高くなっています。つまり、このタスクはクラスタ上でより高い優先度を取得し 、もう 1 つは中断されるということです。見てみましょう。Team A が中断され、Team B の 1 つのジョブが中断されています。より高い優先度でトリガーされたものが 現在実行されています。ここでできることは、例えば、より高い優先度を持つジョブを削除することです。これは私たちが今送信したより高い優先度を持つものであり、Team B のジョブが再開されるのが見えるはずです。つまり Team A は中断されたままで、Team B のものは再度アクティブ化され、再開されます。
その後、例えば Team B からジョブを削除できます。この時点で、私の予想は、このジョブを削除しているのが見えるということです。そして また見えるでしょう。ちょっと確認させてください。Queen Tim B と呼ばれているのかな、それが正しい名前ですか？はい、正しいようです。確認させてください。タイプミスかもしれません。その後、ジョブを確認できます。そして、Team B のジョブはすべて削除されていて、Team A のジョブが再開されているのが見えるはずです。つまり、アイドル状態のコンピュートを再度借用して再開されています。これで、現在のステータスをクリーンアップするためにジョブを削除できます。
HyperPod上でのIDE実行：SageMaker Code EditorとJupyter Labの統合
最後に、HyperPod クラスタで IDE を管理する方法と、HyperPod クラスタで IDE を実行する方法を紹介したいと思います。 私たちは最近、SageMaker Code Editor（Code OSS Visual Studio Code オープンソースに基づいている）や Jupyter Lab を HyperPod クラスタで実行できるようにするこの機能をリリースしました。考え方は、クラスタが起動して実行されており、このクラスタがトレーニングまたは推論に使用されている場合、IDE、インタラクティブな ML ワークロードも実行したい場合があり、特定の時間にクラスタで利用可能な可能性のあるコンピュートを再利用できるということです。また、IDE のコンテナイメージをクラスタに事前キャッシュできるため、非常に高速なスタートアップレイテンシが得られます。環境は非常に短いレイテンシでブートストラップされます。
それに加えて、HyperPod CLI のような同じツールを再利用して IDE を操作できます。HyperPod 上の IDE は、タスクガバナンス機能と統合されています。これは、私たちが今見たのと同じ機能です。つまり、例えば、IDE を特定の優先度で実行できますが、より高い優先度のワークロードが開始された場合、これらのタスクを先制することを決定できます。なぜなら、GPU を他のタスクに使用したい場合があるからです。しかし同時に、ユーザーは、例えば 1 つのノードから 1 つの GPU を取得して、この GPU を使用してノートブックまたは VS Code で作業できます。さらに、NVIDIA MIG テクノロジーを使用した GPU の分割をサポートしているため、GPU の一部を使用することもできます。つまり、GPU をより小さな分割に分割しています。
この機能の詳細については、あまり時間をかけませんが、IDE 用に複数のテンプレートを作成することもできます。各テンプレートは、使用したいイメージ、eastern 側のいくつかの設定、デフォルトの eastern タイプ、およびリクエストされるデフォルトのコンピュートリソースを定義します。
このようにして、ユーザーが環境をスピンアップする際に、コンピュータリソースの指定など、すべてのパラメータを提供する必要なく、テンプレートをそのまま使用できるようになります。管理者は様々なテンプレートを設定でき、ユーザーはそれらを利用して環境をスピンアップできます。
では、これについてのデモに移りましょう。ここに戻す必要があります。最後のモジュール、つまり spaces のモジュールを開きましょう。 では、space に付けたい名前という変数を設定します。そして、ご覧の通り、node selector を使用してこのコマンドを実行しており、これにより ID 環境を CPU インスタンス上に作成できます。このタスクには GPU インスタンスを使用したくないので、この例では単純な CPU インスタンスを使用して環境をスピンアップでき、また FSX ファイルシステムもマウントしています。
その後、CLI を使用して space をリストアップするなどのコマンドを実行できます。実は 2 つ実行中です。私の側で 1 つの space を事前に作成しており、そしてこちらが現在作成されているものです。 また、describe 操作を実行して space の詳細を確認することもできます。 これはこの時点で開始している space ワークスペースに関するすべてのセットアップです。
次に、これらの space にアクセスする方法を説明したいと思います。ここに 2 つのオプションがあります。1 つは VS Code 経由のリモート接続を使用することです。 リモート接続を設定すると、クラスター上で実行されているポッドがありますが、ローカルの VS Code からリモート接続を確立します。これにより、ローカルの VS Code からリモートコンピュートをワークロードに使用できます。これが 1 つのオプションです。そのためには、私の側で既に実行中の space の名前を取得しましょう。
こちらが私の Jupyter Lab space です。つまり space name は my Jupyter Lab space に等しく、その後、create hyp space access というコマンドを使用でき、connection type を VS Code remote に設定します。 これにより、リモート space へのセキュアな接続 URL が得られます。この URL を実行すると、例えばブラウザで実行すると、自動的に VS Code が開きます。 それを開くと、ご覧の通り、VS Code が space へのリモート接続を確立します。
では、リモートスペースで実行しています。これを確認するために、新しいターミナルを開くことができます。LS を実行します。これはスペース上のホームディレクトリですが、FSX も実行できます。つまり、クラスタに接続されている分散ファイルシステムの FSX ファイルシステムに接続しており、スペースにもマウントしています。このようにすることで、チェックポイントを確認するなどのことができます。これは以前実行していたトレーニングの例で、ここにはチェックポイント、モデルアーティファクト、実行していたスクリプトがあります。これがスペースで作業する一つの方法です。
もう一つの方法は Web UI を使う方法です。 このコマンドを実行するだけで Web UI の URL を取得できます。 このリンクをクリックするだけで、このウェブサイトを開くことができ、Web UI 経由でリモートスペースに接続しています。これは Jupyter Lab スペースで、ここで Jupyter Lab サービスに接続しています。
セッション終了：リソース共有とまとめ
これでスペースのデモが終わり、実は本日のセッションも終了です。ここには本日カバーした機能に関するすべてのリソースがあります。 重要なのは、ここに表示されている QR コードで、本日説明したすべての例をダウンロードできます。さらに追加の例もあります。 これを 1 分ほど表示してから、次のスライドに移ります。ご質問がある場合は、ここに留まることができます。時間もちょうどいいようです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion