AWS 详细说明开源 HyperPod InstantStart 控制平面用于代理操作

亚马逊网络服务（Amazon Web Services）在AWS 机器学习博客文章中详细介绍了 HyperPod InstantStart，这是一款开源控制平面，将 Amazon EKS 编排与 Amazon SageMaker HyperPod 的托管能力相结合，文章于2026年9月4日发布。该项目将网页界面与能够通过模型上下文协议（Model Context Protocol）工具规划并执行多阶段集群操作的 AI 代理配对使用。

InstantStart 以单个带外管理容器的形式运行在用户的 AWS 账户中，调用 AWS 服务 API 和 Kubernetes API，却不位于训练作业或推理请求的数据路径中。它创建的每个资源都是标准的 AWS 或 Kubernetes 对象，可通过 AWS 命令行界面和 kubectl 进行检查。网页 UI、REST API 以及代理使用的 MCP 工具都是同一容器的三个面向，因此两个界面都通过同一个后端并接受相同的校验。

单一后端支撑两个界面

文章的核心设计论点是，MCP 工具封装了控制平面的 REST API，而非 AWS CLI 或 SDK，这样一次添加的校验即可同时保护浏览器和代理。 在网页界面中，创建一个已安装依赖、启用自动节点恢复并挂载存储的集群表现为一个表单和进度面板；在终端中，则是向名为 hypd-inst-agent、为 Kiro CLI 构建的代理配置发送的一句自然语言指令。 代理随后按顺序执行以下工作：创建 EKS 控制平面、选择活跃集群、依赖对齐、创建 HyperPod 集群以及设置存储。 AWS 表示，EKS 控制平面的创建大约需要 8 到 12 分钟，每个后续阶段都会记录自身状态，并且可以独立重试。

项目的代理技能中编码了三条工作流规则，文章将其描述为存储库中版本化的 markdown 手册。代理会轮询每个长时间运行的操作直至达到终止状态，而不是仅报告已提交的请求。它仅提出决策层面的问题，例如可用区、实例类型和容量类型，同时将子网 CIDR、路由表和安全组视为控制平面工作。并且在创建之前进行检查，列出已有的集群并查询可用的可用区和实例类型后再提供选择。

托管能力作为调和状态

InstantStart 在创建 HyperPod 集群时默认启用自动节点恢复，届时 HyperPod 可依据其健康监控代理、基本健康检查以及可选的深度健康检查（对 GPU 和弹性网络适配器连接性进行压力测试）在节点接受工作前对故障节点进行重启或替换。当用户添加实例组时，容量类型、网络接口模式和子网位置会作为一次创建操作一起确定；容量类型和仅限 EFA 的接口模式在该组生命周期内保持不变。控制平面通过单一函数将所有容量路径路由至为大规模加速器集群预留的 /20 规模计算子网。

HyperPod 基于 Karpenter 的托管节点自动扩缩决定任意时刻使用多少容量，AWS 负责运行 Karpenter 控制器，节点从零开始从 HyperPod 实例组中启动。文章指出一个范围限制：托管的 Karpenter 只管理 HyperPod 实例组，而不管理通用的 Amazon EC2 容量。

高级功能面板展示了 HyperPod 的托管能力，包括训练操作员、推理操作员、托管分层检查点以及托管自动扩缩，每个切换对应一个具备依赖感知的后端操作。启用分层检查点会配置一条身份链，覆盖 Kubernetes 服务账户、IAM 角色与策略、OpenID Connect 信任关系以及绑定注解；禁用则会移除同样的链路。文章还描述了在早期 bug 之后采用的显式差异（explicit-diff）合约：界面仅提交用户实际更改的字段，后端读取实际集群状态，当请求的状态与实际状态已匹配时则不做任何操作。

训练与推理路径

在训练方面，InstantStart 提供了两条提交路径。作为 EKS 插件安装的 HyperPod 训练操作员加入了进程级别的故障恢复、通过日志模式监控进行的作业卡死检测以及异常检测，工作以携带可见恢复预算的 HyperPodPyTorchJob 资源提交。第二条路径是标准的 KubeRay，面向 Ray 原生工作负载，如强化学习。两者之上还有一个配方层，支持普通的 PyTorch 脚本、LLaMA-Factory、MS-Swift 和 VERL 强化学习，这些配方共享同一数据合约，即在开发环境和容器内部均挂载相同的 Amazon S3 存储桶。作业日志通过 WebSocket 流向浏览器，配方还能将训练吞吐量等指标报告给 Amazon SageMaker AI 上托管的 MLflow。

推理同样提供两条路径。托管路径将生命周期交给 HyperPod 推理操作员，伴随端点一起声明托管的分层 KV 缓存和智能路由策略。自托管路径则部署用户选择的服务容器，如 vLLM 或 SGLang，作为标准的 Kubernetes 部署，服务形态包括外部负载均衡器、集群内部服务以及可通过更改标签重新分配的热 GPU 工作池模型。对于多副本的 SGLang 服务，控制平面可以部署具备缓存感知路由的 SGLang 路由器，并通过 Kubernetes 事件驱动自动扩缩（Event-driven Autoscaling）实现自动扩缩。

代理工具与边界

根据文章，MCP 服务器发布了 38 种工具，涵盖集群生命周期、实例组、托管特性、存储、模型下载、推理部署、作业以及节点操作。每个会改变状态的工具都会指明决定完成的状态工具，且操作在开始轮询前会持久化其阶段，以防代理重试时重新执行变更。项目的 GitHub 仓库将该平台描述为基于 SageMaker HyperPod 与标准 EKS 编排构建的训练与推理一体化系统，其 README 表明 MCP 工具封装了项目后端 API，以符合最佳实践，而代理技能则在无需除代理外的任何本地设置的情况下编排端到端工作流。

文章明确划定了运营边界。针对 NCCL、节点健康以及集群创建失败的捆绑诊断技能会单独进行只读调查，将会改变状态的命令以建议形式呈现，并按调查 → 重启 → 替换的顺序升级。IAM、Kubernetes 授权、网络控制以及后端校验仍是实际的安全边界；代理在不扩大自身权限的前提下拓宽了对控制平面的访问。AWS 还指出，弹性训练目前不支持 Spot 实例、托管分层检查点以及无检查点训练，并且在首次创建集群前，需要先安排 SageMaker HyperPod 的集群使用配额以及高端 GPU 类型的训练计划预留。

部署始于一个 CloudFormation 模板，该模板创建管理环境、共享的 S3 存储桶以及支持的 IAM 角色，网页界面通过容器的 3099 端口提供服务，并通过 AWS Systems Manager 端口转发会话访问。