AWS、エージェント操作向けオープンソース HyperPod InstantStart コントロールプレーンの詳細

Amazon Web Services は、Amazon EKS オーケストレーションと Amazon SageMaker HyperPod のマネージド機能を組み合わせたオープンソースのコントロールプレーンである HyperPod InstantStart を、2026年9月4日に公開された AWS Machine Learning Blog 投稿で詳述しました。本プロジェクトは、Web インターフェイスと、Model Context Protocol ツールを通じてマルチステージのクラスター操作を計画・実行する AI エージェントを組み合わせています。

InstantStart は、ユーザーの AWS アカウント内で単一のアウトオブバンド管理コンテナとして実行され、トレーニングジョブや推論リクエストのデータパスに介在せずに AWS サービス API と Kubernetes API を呼び出します。作成されるすべてのリソースは標準的な AWS または Kubernetes オブジェクトであり、AWS Command Line Interface および kubectl で検査可能です。Web UI、REST API、エージェントが使用する MCP ツールは同一コンテナの三つのフェースであり、両インターフェイスは同一バックエンドを通り、同じ検証を受けます。

二つのインターフェイスの背後にある単一バックエンド

この記事の中心的な設計論点は、MCP ツールが AWS CLI や SDK ではなくコントロールプレーン自身の REST API をラップしている点であり、一度追加した検証がブラウザとエージェントの両方を保護します。Web インターフェイスでは、依存関係のインストール、ノード自動復旧の有効化、ストレージのマウントを伴うクラスター作成がフォームと進捗パネルで表現されますが、ターミナルでは Kiro CLI 用に構築された hypd-inst-agent というエージェント設定への単一の自然言語文として扱われます。エージェントは作業を順序付けます: EKS コントロールプレーンの作成、アクティブクラスターの選択、依存関係の調整、HyperPod クラスターの作成、そしてストレージ設定です。AWS は EKS コントロールプレーンの作成に約 8〜12 分かかり、以降の各ステージは独自のステータスを記録し、個別に再試行可能であると述べています。

プロジェクトのエージェントスキルには、リポジトリでバージョン管理されている markdown プレイブックとして記述された 3 つのワークフロールールが組み込まれています。エージェントは、送信されたリクエストを報告するのではなく、すべての長時間実行操作をターミナル状態になるまでポーリングします。可用性ゾーン、インスタンスタイプ、キャパシティタイプといった意思決定レベルの質問のみを行い、サブネット CIDR、ルートテーブル、セキュリティグループはコントロールプレーンの作業として扱います。また、作成前に検査を行い、既存クラスターの一覧表示や有効なゾーン・インスタンスタイプの照会を行ってから選択肢を提示します。

調整された状態としてのマネージド機能

InstantStart は、自動ノード復旧が有効化された HyperPod クラスターを作成します。この状態では、ヘルスモニタリングエージェント、基本的なヘルスチェック、そしてオプションのディープヘルスチェック（GPU と Elastic Fabric Adapter の接続性をストレステスト）に基づき、故障したノードを再起動または置換できます。ユーザーがインスタンスグループを追加すると、キャパシティタイプ、ネットワークインターフェイスモード、サブネット配置が一つの作成時操作として確定され、キャパシティタイプと EFA 専用インターフェイスモードはグループの存続期間中固定されます。コントロールプレーンは、すべてのキャパシティパスを単一の関数を通じてルーティングし、大規模アクセラレーターフリート向けに /20 サイズのコンピュートサブネットをプロビジョニングします。

HyperPod が管理する Karpenter ベースのノード自動スケーリングは、任意の時点でどれだけのキャパシティを稼働させるかを決定します。AWS が Karpenter コントローラ自体を運用し、ノードはゼロからスケールアップされた HyperPod インスタンスグループから起動します。記事では、スコープの制限として、管理対象の Karpenter は HyperPod インスタンスグループのみを管理し、汎用的な Amazon EC2 キャパシティは対象外であることが指摘されています。

Advanced Features パネルは、トレーニングオペレーター、推論オペレーター、マネージド階層チェックポイント、マネージドオートスケーリングなど、HyperPod のマネージド機能を公開し、各トグルは依存関係を考慮したバックエンド操作にマッピングされています。階層チェックポイントを有効化すると、Kubernetes サービスアカウント、IAM ロールとポリシー、OpenID Connect 信頼関係、バインディングアノテーションにまたがるアイデンティティチェーンがプロビジョニングされ、無効化すると同じチェーンが削除されます。記事では、初期バグの後に採用された explicit-diff 契約も説明されており、インターフェイスはユーザーが実際に変更したフィールドのみを送信し、バックエンドは実際のクラスター状態を読み取り、要求された状態と実際の状態が一致している場合は何もしません。

トレーニングと推論のパス

トレーニングにおいて、InstantStart は 2 つの提出パスを提供します。EKS アドオンとしてインストールされる HyperPod トレーニングオペレーターは、プロセスレベルの障害回復、ログパターン監視によるハングジョブ検出、異常検出を追加し、作業は HyperPodPyTorchJob リソースとして提出され、可視的なリカバリ予算を持ちます。第 2 のパスは標準的な KubeRay で、強化学習など Ray ネイティブのワークロードを対象としています。これらの上位には、プレーンな PyTorch スクリプト、LLaMA-Factory、MS-Swift、VERL 強化学習用のレシピ層があり、すべて同一のデータ契約を共有し、同じ Amazon S3 バケットが開発環境およびポッド内にマウントされます。ジョブログは WebSocket を介してブラウザにストリーミングされ、レシピはトレーニングスループットなどの指標を Amazon SageMaker AI 上のマネージド MLflow に報告できます。

推論にも同様に 2 つのパスがあります。マネージドパスはライフサイクルを HyperPod 推論オペレーターに委ね、エンドポイントと共にマネージド階層 KV キャッシュとインテリジェントなルーティング戦略が宣言されます。セルフマネージドパスは、vLLM や SGLang などユーザーが選択したサービングコンテナを標準的な Kubernetes デプロイメントとして展開し、外部ロードバランサー、クラスター内部サービス、ラベル変更で再割り当て可能な温かい GPU ワーカーのモデルプールといったサービス形態を提供します。マルチレプリカの SGLang サービングの場合、コントロールプレーンはキャッシュ認識ルーティングを備えた SGLang ルータをデプロイし、Kubernetes のイベント駆動オートスケーリングを通じてオートスケーリングを実行できます。

エージェントツールと境界

MCP サーバーは、記事によれば、クラスターライフサイクル、インスタンスグループ、マネージド機能、ストレージ、モデルダウンロード、推論デプロイ、ジョブ、ノード操作の 38 種類のツールを公開しています。すべての変更系ツールは完了を判断するステータスツールを名前に持ち、ポーリング開始前に操作のフェーズを永続化するため、エージェントの再試行で変更が再実行されることはありません。プロジェクトの GitHub リポジトリでは、プラットフォームを SageMaker HyperPod と標準的な EKS オーケストレーション上に構築されたトレーニング・推論統合システムと説明し、README では MCP ツールがベストプラクティス遵守のためにプロジェクトのバックエンド API をラップし、エージェントスキルがエージェント以外のローカルセットアップなしでエンドツーエンドのワークフローをオーケストレーションすると記載しています。

記事では明確な運用境界が示されています。NCCL、ノードヘルス、クラスター作成失敗に対するバンドル診断スキルは、単独で読み取り専用の調査を行い、状態変更コマンドを提案として提示し、調査 → 再起動 → 置換の順にエスカレーションします。IAM、Kubernetes 認可、ネットワーク制御、バックエンド検証が実際のセキュリティ境界を構成し、エージェントは権限を拡大せずにコントロールプレーンへのアクセスを広げます。また、AWS は、エラスティックトレーニングが現在 Spot インスタンス、マネージド階層チェックポイント、チェックポイントなしトレーニングを除外していること、そして高性能 GPU タイプ向けの SageMaker HyperPod クラスター使用クォータとトレーニングプラン予約は最初のクラスター開始前に調整が必要であると助言しています。

デプロイは、管理環境、共有 S3 バケット、サポート IAM ロールを作成する CloudFormation テンプレートから開始され、Web インターフェイスはコンテナのポート 3099 で提供され、AWS Systems Manager のポートフォワーディングセッションを通じてアクセスされます。