Amazon SageMaker HyperPod の運用をエージェントが自動実行

Amazon SageMaker HyperPod でファウンデーションモデル（FM）のワークロードを運用している方ならご存知の通り、その作業は単一のタスクではありません。依存関係を持つ一連の連鎖なのです。

インフラチームは、ネットワークとコントロールプレーンを構築し、アクセラレータ容量を追加し、クラスター依存関係を正しい順序でインストールします。さらにストレージとアイデンティティの準備を行い、ハードウェア障害の間も分散ジョブを稼働させ続け、モデルサーバーを展開し、全体を見守る必要があります。各工程には独自の API と失敗モード、そして待機時間が存在します。運用上の大きな痛みは、これらの工程間の引き継ぎ部分に集中しています。

Amazon SageMaker HyperPod は、こうした負担の多くを解消します。管理された耐性のあるコンピューティングと、ヘルスモニタリング、ノードの自動スケーリング、トレーニングの回復、推論のための Amazon EKS 統合機能を提供します。

ただし、Amazon Elastic Kubernetes Service (Amazon EKS) はユーザーが管理するオーケストレーションの表面として残ります。これによりチームは直接 Kubernetes にアクセスできます。一方で、AWS リソースやアドオン、ワークロード、2 日目の運用を統合された全体へと構成する責任もチームに課されます。

HyperPod InstantStart は、構成の複雑さを解決するために設計されたオープンソースの制御プレーンです。このツールは、同じ制御プレーンを操作する 2 つの方法を提供しています。

Web インターフェースでは、依存関係がインストールされ、ノードの自動回復機能が有効になり、ストレージがマウントされたクラスターの作成が、フォームと進行状況パネル、そして更新ボタンで完結します。一方、ターミナルからはたった 1 行のコマンドで同じことができます。

[hypd-inst-agent] > Help me create a new HyperPod cluster

AI エージェントはその後、多段階のワークフローを計画し、各ステージを開始して非同期の AWS オペレーションが完了するまでポーリングを行います。ただし、アベイラビリティゾーンやインスタンスタイプ、キャパシティタイプなど、ユーザー自身が決定すべき事項については一時停止します。そして、ストレージがマウントされた実行中のクラスターを引き渡します。

両方のインターフェースは同じバックエンド API を呼び出し、同一のバリデーション処理を経て、保存された操作状態を読み取ります。どちらかのインターフェースにしか存在しない独自のロジックはありません。

本稿では、これらの 2 つのインターフェースを支えるシステムの詳細を解説します。クラスターのブートストラップ、キャパシティ管理、トレーニング、推論、ストレージがどのようにして安全かつ再試行可能なオペレーションに変換されるかを示します。また、どの部分が HyperPod のマネージド機能で、どの部分が本プロジェクトによって追加された機能なのかについても触れます。さらに、生きた CLI をエージェントに渡すのではなく、運用ルールを制御プレーン API に組み込むことが、なぜエージェント駆動型インフラの信頼性を高めるのかについて説明します。

Solution overview

HyperPod InstantStart は、お客様の AWS アカウント内で単一のアウト・オブ・バンド管理コンテナとして動作します。AWS サービス API や Kubernetes API を呼び出しますが、トレーニングジョブや推論リクエストのデータパス上に位置するわけではありません。InstantStart が作成するのはすべて標準的な AWS リソースまたは Kubernetes リソースです。これらのリソースは、AWS Command Line Interface (AWS CLI) や kubectl を用いて確認できます。

以下の図は、ソリューションアーキテクチャと責任範囲が移る箇所を示しています。

図は左から右へ読み進めてください。インフラチームが単一のエントリーポイントを管理します。Web UI、REST API、そして AI エージェントが使用する Model Context Protocol (MCP) ツールは、同じコンテナの異なる側面であり、いずれも一つの入口を通じてアクセスされます。その背後には、本記事で詳述する段階的なプロビジョニングと整合性のある再調整ロジックが存在します。ここから制御プレーンが 2 つの API サフェースを呼び出します。

Kubernetes 側はユーザーが管理する Amazon EKS です。ここには Kubernetes API と、EKS アドオンとしてインストールされた HyperPod のトレーニングおよび推論オペレーターが含まれており、これらが HyperPodPyTorchJob や InferenceEndpointConfig リソースを調整して、トレーニング用や推論用のポッドを作成します。

AWS 側は AWS が管理する Amazon SageMaker HyperPod です。その機能は主に 4 つのグループに分類されます。インフラストラクチャでは、ヘルスモニタリング、詳細な健康チェック、自動ノード復旧が行われます。キャパシティでは、継続的なプロビジョニングと管理された Karpenter によるオートスケーリングが提供されます。トレーニングでは、プロセスレベルでの回復と管理された階層型チェックポイント機能が利用可能です。推論では、インテリジェントなルーティングと階層型 KV キャッシングが実現されています。

これら 2 つの領域は HyperPod インスタンスグループで接続されます。Kubernetes がポッドをここにスケジューリングし、HyperPod が管理を担当します。これが最も重要なポイントです。何か問題が発生した際、この境界線を知ることで、AWS がユーザーの介入なしに運用・修復する範囲が明確になります。

その周辺には AWS の統合機能が配置されており、図ではストレージと観測性の関連部分が示されています。Amazon Simple Storage Service (Amazon S3) や Amazon FSx for Lustre、Amazon Elastic Container Registry (Amazon ECR) は、イメージ、データ、チェックポイントの保存を担当します。また、Amazon Managed Service for Prometheus と Amazon Managed Grafana がヘルスステータスとリソース利用率を受信し、SageMaker AI 上の管理された MLflow もメトリクスやアーティファクトを受け取ります。

InstantStart はこの環境を 4 つのレイヤーに整理して構成しています。

2 つのインターフェースを結びつける設計原則があります。MCP ツールは、AWS CLI や SDK ではなく、ブラウザが呼び出すのと同じコードパスであるバックエンド独自の REST API をラップしています。そのため、一度検証を追加すれば両方を保護できます。これがエージェントにとってなぜ重要なのかについて振り返りましょう。まずは制御プレーンがその主要な役割を果たす様子を見てみましょう。

前提条件

デプロイと運用には、最小限の権限を持つ IAM ロールを使用してください。AWS のガイドラインに従い、CloudFormation アクセス制御 と SageMaker HyperPod の IAM、そして Amazon S3 アクセス を指定されたプロジェクトバケットに制限してください。2 つの容量項目には AWS の処理時間がかかるため、早めに開始する必要があります。実行予定の各インスタンスタイプに対して「Cluster Usage」の Amazon SageMaker サービスクォータ増額をリクエストし、ハイエンドアクセラレータータイプについては、Amazon SageMaker Flexible Training Plan を購入して容量を確保してください。また、デフォルトではクラスターごとに VPC が作成されるため、VPC のクォータも確認しておいてください。

コンテナを実行するための管理環境が必要です。本プロジェクトでは、この環境と共有 S3 バケット、および必要な IAM ロールを作成する AWS CloudFormation テンプレートを提供しています。

AWS CloudFormation テンプレート は、AWS マネジメントコンソールまたは AWS CLI を使用してデプロイできます。スタックによって作成されたインスタンスで リポジトリ をクローンし、ui-panel/start-prod.sh スクリプトを実行します。このスクリプトは、パブリック Amazon ECR から事前構築されたコンテナイメージを取得し、kubectl と AWS 認証情報をマウントして起動します。これにより、ポート 3099 で Web インターフェースが提供されます。

インターネットに公開するのではなく、AWS Systems Manager のポート転送セッションを通じてこのポートにアクセスしてください。テンプレートのセキュリティグループは利便性のため一時的にパブリックアクセスを許可していますが、実際の運用環境で使用する前に制限を設ける必要があります。

エージェントインターフェースには、Kiro CLI のインストールと認証が必要です。MCP サーバーとエージェントのスキルは同じコンテナ内に含まれているため、ローカルでの追加インストールは不要です。

クラスターの作成：会話とコンソール

空のアカウントから利用可能な HyperPod 容量を確保するには、複数の長時間実行される順序依存ステージを経る必要があります。InstantStart はこれらを意図的に分離し、EKS コントロールプレーンの作成、アクティブなクラスターの選択、依存関係の整合性確認、HyperPod クラスターの新規作成、ストレージ設定という 5 つの段階に分割しています。この分離により、後続のステージで失敗が発生しても、すでに完了した前期のステージが巻き戻されることはありません。EKS コントロールプレーンの作成には約 8〜12 分かかります。その後の各ステージは独自の状態を記録し、独立して再試行が可能です。

Web インターフェースでは「クラスター管理」ページで操作を行います。クラスターのタグを入力して作成ボタンを押すと、段階ごとの進行状況インジケーターが確認できます。エージェント経由では、このパイプライン全体が対話形式で進みます。以下は、プロジェクトの MCP サーバーとスキルを読み込む Kiro CLI 用のエージェント設定である hypd-inst-agent との実セッションから抜粋した要約です。

[hypd-inst-agent] > Help me create a new HyperPod cluster

> Creating a HyperPod cluster is a multi-step process:
1. Create EKS cluster (approximately 8-12 minutes)
2. Switch to the new cluster and verify
3. Install dependencies
4. Create HyperPod cluster
5. Configure S3 storage
6. Final verification
Let me first check the existing cluster situation:

Running tool cluster_list_all (from mcp server: hypd-inst)

> There are currently 2 existing clusters. Would you like to give the new cluster a tag name, or should I auto-generate one?

[hypd-inst-agent] > Go ahead

Running tool cluster_create_eks {"clusterTag": "hypd-0304b"}

> EKS cluster creation has started. I'll check progress every 2 minutes.

Running tool wait_seconds {"seconds": 120}
Running tool cluster_get_eks_creation_status

> Still creating (about 4 minutes elapsed). Continuing to wait...
...
> Step 1 complete! EKS cluster hypd-0304b created successfully.
...
> Step 3 complete! All dependencies installed successfully.

Now I need the following information from you to create HyperPod:
Availability Zone, GPU instance type, instance count, and capacity type (On-Demand or Training Plan)?

[hypd-inst-agent] > us-west-2c, one g6.4xl

Running tool hyperpod_create {"AcceleratedInstanceType": "ml.g6.4xlarge", "AcceleratedInstanceCount": 1, "availabilityZone": "us-west-2c", ...}
...
> HyperPod cluster creation fully complete! Summary:
| EKS Cluster      | eks-cluster-hypd-0304b       |
| HyperPod Cluster | hp-cluster-hypd-0304b        |
| Node             | 1x ml.g6.4xlarge (On-Demand) |
| Node Status      | Ready / Schedulable          |
| S3 Storage       | s3-claim mounted             |

このトランスクリプトに現れる 3 つの行動は、即興的なものではなく、プロジェクトのエージェントスキルに組み込まれたワークフロールールに基づいています。

• エージェントは完了までポーリングします。長時間実行される操作の後には必ず wait_seconds が設定され、ステータスツールが呼び出されてターミナル状態に達するまで待機されます。エージェントは途中で停止して「後で確認してください」と伝えることはできません。対話は検証済みのクラスターの存在をもって終了し、単なるリクエストの提出で終わることはありません。

エージェントが問うのは、意思決定に必要な質問だけです。クラスタータグ、アベイラビリティゾーン、インスタンスタイプ、キャパシティタイプはあなたが決めるべき事項です。一方、サブネット CIDR、ルートテーブル、セキュリティグループ、インストール順序は制御プレーンの作業に過ぎません。

エージェントは作成前に必ず確認を行います。既存のクラスターをまず一覧表示し、選択肢を提供する前に有効なアベイラビリティゾーンとインスタンスタイプを検索します。これにより、あなたが目にするオプションは、そのアカウントとリージョンで実際に満たせる条件のみになります。

会話の中で言及されていないネットワーク構成こそが、制御プレーンがどのようにエンコードされているかを示しています。AWS CloudFormation パスでは、VPC の作成または再利用が可能です。EKS の制御プレーン用サブネットと HyperPod 計算用サブネットは分離されており、両者のアドレス空間の要件には桁違いの違いがあります。計算用サブネットは /20 で設計され、大規模なアクセラレータ群を収容できるように sizing されています。すべてのキャパシティパスは ensureComputeSubnet() という単一の関数を経由し、固定された優先順位に従って実行されます。この関数は明示的に指定されたサブネットを使用するか、互換性のあるアベイラビリティゾーンごとの既存のサブネットを再利用するか、ルートテーブルと S3 ゲートウェイエンドポイントの関連付けを含む新しいサブネットを作成します。クラスター作成と後のキャパシティ拡張は同じロジックを共有するため、ネットワーク構成が正しいか間違っているかを決定する箇所は唯一つです。

回復力をデフォルトとしたキャパシティ選択

コントロールプレーンが構築された後、次は容量管理という継続的な運用フェーズに入ります。新しいワークロードのためにインスタンスグループを追加し、課金方法を選択すれば、あとはコントロールプレーンが自動的に健全性を維持してくれます。

InstantStart は、自動ノード回復機能を有効にした状態で HyperPod クラスターを構築します。HyperPod は、ヘルスモニタリングエージェントからの検知結果や基本的な健康チェック、さらに設定された場合は深層健康チェックに基づいて、故障したノードの再起動または置換を行います。深層健康チェックでは、ノードがワークロードを受け付ける前に GPU や Elastic Fabric Adapter (EFA) の接続性を負荷テストで検証します。これらのヘルス検知結果は Kubernetes のラベル、タイント、注釈として反映されるため、スケジューラーやツールは AWS への直接呼び出しを行わずとも、Kubernetes API を介して自動的に反応できます。

インスタンスグループを追加する際、システムは容量に関する判断を散発的な後続設定ではなく、作成時の一貫したオペレーションとして扱います。

インスタンスグループの構成オプション

容量タイプ

オンデマンド、Amazon Elastic Compute Cloud (Amazon EC2) スポットインスタンス、または Amazon SageMaker 学習プラン を通じた予約済み容量から選択できます。耐障害性が求められるワークロードにはスポットインスタンスが適しています。学習プランを使用すると、その容量は特定の可用性ゾーンに固定されます。制御プレーンでは、ユーザーのゾーン選定をプランと照合して整合性を保つため、不整合による分かりにくいエラーが発生するのを防ぎます。なお、グループ作成後は容量タイプを変更できません。

ネットワークインターフェースモード

複数のネットワークカードを搭載したインスタンスタイプでは、EFA（Elastic Fabric Adapter）専用インターフェースをリクエストできます。これにより VPC の IP アドレスを節約できます。この設定はインスタンスグループ作成後に固定され、変更できません。InstantStart では、更新拒否から不変性を発見する手間を省くため、この項目を作成時のフィールドとして表示します。

サブネット配置

デフォルトでは、各可用性ゾーン（AZ）ごとの計算用サブネットが共有されます。大規模なグループでは IP アドレス枯渇を防ぐために専用サブネットをリクエストできます。この専用サブネットは意図的にグループの寿命を超えて維持され、後継グループで再利用できるようになっています。

以下のスクリーンショットは「インスタンスグループの追加」フォームを示しています。ここでは上記の選択肢が、一度に設定できる作成ステップとして統合されています。

Figure 2: The Add instance group form, where capacity choices become one create-time step

インスタンスグループのフィールドには、変更不可のものもあれば、設定を失いやすいものもあります。そのため、コントロールプレーンは更新リクエストを手動で組み立てるのではなく、明示的なフィールド許可リストを通じてグループを正規化します。OnStartDeepHealthChecksやNetworkInterfaceなどの設定は継承されるため、無関係なスケーリング操作によってグループのヘルスチェックやEFA構成が静かにリセットされることはありません。この正規化処理は、WebインターフェースからのリクエストかMCPツール呼び出しかの別なく実行されます。

Managed Karpenter: Karpenterの運用なしで自動スケーリング

静的なインスタンスグループは、あなたが所有するキャパシティの量を定義します。一方、HyperPod が管理する Karpenter ベースのノード自動スケーリング（HyperPod managed Karpenter-based node autoscaling）は、そのうちどの程度を同時に稼働させるかを決定します。AWS は Karpenter コントローラー自体を運用しており、ノードは生の Amazon EC2 ではなく、ゼロからスケーリングされた HyperPod インスタンスグループから起動されます。これにより、自動スケーリングされたキャパシティは、前述のヘルスモニタリングと自動ノード回復機能を継承し、管理されていないインスタンスとして現れることはありません。

スケジューリングは標準的な Karpenter の NodePool を使用し、これは HyperpodNodeClass にバインドされます。InstantStart は、アイドル状態のグループをゼロに近づける統合機能など、動作するデフォルト設定を含むこの構成を提供します。制御プレーンがすでに継続的なプロビジョニングと自動回復をデフォルトとしているため、管理された Karpenter の有効化は検証済みのトグル操作であり、マニュアル手順書のような複雑な作業にはなりません。ただし注意すべき点として、HyperPod が管理する Karpenter は汎用の Amazon EC2 キャパシティではなく、HyperPod インスタンスグループを管理するものです。

実行可能な機能はマニュアルではなく整合された状態として

HyperPod には複数の管理機能が搭載されており、それぞれに文書化された多段階の設定手順が存在します。これらにはトレーニングオペレーター、推論オペレーター、管理型ティアードチェックポイント、そして管理型自動スケーリングが含まれます。InstantStart は、これらの機能を「高度な機能」パネル内で一元化して提供しています。その価値は単なるチェックボックスの存在にあるのではなく、各チェックボックスが依存関係 Aware なバックエンド操作にマッピングされている点にあります。

以下のスクリーンショットは、Advanced Features（高度な機能）を示しています。