AWS、HyperPod InstantStartをオープンソース化――人間の操作とAIエージェントを同一の管理APIで駆動

AWSはHyperPod InstantStartを公開し、SageMaker HyperPodのデプロイで特にエラーが起きやすい部分の解決を試みている。EKSコントロールプレーン、GPU instance group、アドオン、ストレージ、トレーニング、推論エンドポイントの間には、順序への依存があり、時間がかかるうえ、部分的に失敗する可能性のある操作が数多く存在する。このシステムは、顧客のAWSアカウント内にデプロイされるアウトオブバンド管理コンテナとして動作し、Webインターフェース、REST API、MCPツールを提供する。これら3つは、エージェントにAWS CLIコマンドをその場で組み立てさせるのではなく、同一の検証、状態永続化、再試行ロジックを共有する。[AWSのアーキテクチャ解説](https://aws.amazon.com/blogs/machine-learning/run-agent-driven-amazon-sagemaker-hyperpod-operations-with-instantstart/)によると、クラスター作成は、EKSの作成、環境の切り替え、依存関係の調整、HyperPodの作成、ストレージ設定、最終検証といった段階に分割される。各段階では先に状態が保存されるため、ブラウザーを再読み込みした場合やエージェントが再試行した場合でも、完了済みの変更が再実行されることは想定されていない。また、エージェントスキルには、現状を列挙するタイミング、Availability Zoneとcapacity typeを確認するタイミング、変更時に人間の承認が必要となる条件が定められている。

トレーニングにはHyperPod Training OperatorまたはKubeRayを選択できる。前者はプロセスレベルの再起動、ハング検出、分散ジョブの復旧をサポートする。推論ではvLLM、SGLang、任意のコンテナをデプロイできるほか、HyperPod Inference Operatorによるprefix／KV-aware routingと、L1、L2の階層型KV cacheも利用できる。これらの機能の多くは既存のAWS、EKS、Kubernetesコンポーネントに由来しており、InstantStartが新たに提供する価値は、依存関係、immutable field、完了条件をコントロールプレーンへ組み込んだ点にある。[公開リポジトリ](https://github.com/haozhx23/HyperPod-InstantStart)は現時点ではまだ小規模で、エージェントのエントリーポイントとしてKiro CLIを使用している。さらに重要なのは、このコンテナが`kubectl`とAWS認証情報を保持し、サンプルのCloudFormationに含まれるSecurity Groupも、操作を容易にするためUIポートを開放していることだ。AWSは、本番環境で使用する前に設定を厳格化するよう明確に求めている。エンジニアリングチームは、自然言語インターフェースを新たなセキュリティ境界とみなすのではなく、スキルファイルをInfrastructure as Codeとして扱い、バージョンレビュー、権限テスト、コスト制限、障害訓練の対象に含めるべきだ。