AWS 開源 HyperPod InstantStart，以同一組受控 API 驅動人工作業與 AI 代理

AWS 公開 HyperPod InstantStart，嘗試解決 SageMaker HyperPod 部署中最容易出錯的部分：EKS 控制平面、GPU instance group、附加元件、儲存、訓練與推論端點之間存在大量有順序、耗時且可能部分失敗的操作。系統以一個部署在客戶 AWS 帳戶內的帶外管理容器運作，同時提供網頁介面、REST API 與 MCP 工具；三者共用同一套驗證、狀態保存及重試邏輯，而不是讓代理臨時拼接 AWS CLI 指令。[AWS 的架構說明](https://aws.amazon.com/blogs/machine-learning/run-agent-driven-amazon-sagemaker-hyperpod-operations-with-instantstart/)顯示，建立叢集被拆成 EKS 建立、環境切換、相依項目調和、HyperPod 建立、儲存設定與最終驗證等階段。每一階段先保存狀態，因此瀏覽器重新整理或代理重試不應重播已完成的變更。代理技能則規定何時列舉現況、詢問可用區與容量類型，以及哪些修改需要人員確認。

訓練端可選 HyperPod Training Operator 或 KubeRay，前者支援程序級重啟、掛起偵測與分散式工作復原；推論端可部署 vLLM、SGLang 或任意容器，也能使用 HyperPod Inference Operator 的 prefix／KV-aware routing 與 L1、L2 分層 KV cache。這些功能大多來自既有 AWS、EKS 與 Kubernetes 元件，InstantStart 的新增價值是把相依關係、不可變欄位及完成條件編碼進控制平面。[公開儲存庫](https://github.com/haozhx23/HyperPod-InstantStart)目前規模仍小，且以 Kiro CLI 作為代理入口。更重要的是，容器會持有 `kubectl` 與 AWS 憑證，範例 CloudFormation 的安全群組也為方便操作開放 UI 連接埠；官方明確要求正式使用前收緊設定。工程團隊應把技能檔視為基礎設施程式碼，納入版本審查、權限測試、成本限制與故障演練，而不是把自然語言介面當成新的安全邊界。