生活分享

AWS：SageMaker Studio 可直接管理 HyperPod Spaces，日常操作无需命令行

AWS 于 2026 年 10 月 6 日发文表示，数据科学家可直接在 SageMaker Studio 网页界面创建、启动和停止 HyperPod 集群上的 Spaces（交互式开发环境），无需再输入命令。本文整理 AWS 介绍的功能、管理员须先完成的设置、启动时间与费用。

阅读时间约 7 分钟

AWS：SageMaker Studio 可直接管理 HyperPod Spaces，日常操作无需命令行
图片：Mokaair (Original editorial artwork)

AWS 宣布了什么

根据 AWS 于 2026 年 10 月 6 日发布的博客文章，该公司近期推出一项新功能：用户可以直接从 Amazon SageMaker Studio 的界面，在 SageMaker HyperPod EKS 集群上创建和管理 SageMaker Spaces。Spaces 指的是直接在集群上运行的交互式开发环境，例如 JupyterLab 笔记本或 Code Editor 代码编辑器。AWS 表示，数据科学家现在可以在 Studio 中创建、配置、启动、停止和打开 Spaces，而 HyperPod 集群详情页新增的“IDE and Notebooks”选项卡提供完整的管理界面。

AWS 介绍，SageMaker HyperPod 是为基础模型大规模训练与推理打造的基础设施，配合 Amazon EKS（Amazon Elastic Kubernetes Service）编排后，可在数百个加速器上运行分布式训练，并内置弹性与自动故障恢复能力。AWS 还提到，今年早些时候已推出 SageMaker Spaces for HyperPod 附加组件，让交互式开发工作可以与训练任务、模型部署共用同一套基础设施，并支持部分 GPU 分配，即只将一部分 GPU 分配给某个环境使用。

  • 据 AWS 介绍，可通过引导式表单配置计算、命名空间、存储、镜像，以及用于管理计算配额的 HyperPod Task Governance。
  • 可用可搜索的表格查看所有 Spaces 的名称、应用类型、状态、访问类型、存储、GPU 与 vCPU 分配。
  • 可启动和停止 Spaces，在不使用时释放计算资源。
  • 可在浏览器中打开 JupyterLab 或 Code Editor，或通过 VS Code 等远程 IDE（安装在自己电脑上的开发工具）连接。

对用户的实际影响

AWS 表示，过去创建和管理 Spaces 主要依赖 HyperPod CLI 或 kubectl 这类命令行指令，这种方式为基础设施管理员提供了细粒度控制。按 AWS 的说法，偏好可视化界面的数据科学家现在可以借助这项 Studio 功能绕过命令行工具，专注于模型开发。AWS 在文章结论中称，团队现在可以在数分钟内从获得集群访问权限推进到运行中的 JupyterLab 或 Code Editor 环境，无需学习 CLI 工具或 Kubernetes 概念。

对共用 HyperPod 集群的团队来说，日常打开开发环境的步骤可能变得更接近普通网页操作。AWS 还说明，工作内容保存在挂载的 Amazon EBS 卷中，因此停止后再重新启动 Space 不会丢失进度。至于远程连接，AWS 表示“Open in VS Code”在内部使用 SSH-over-SSM 隧道，无需管理 SSH 密钥或开放 22 端口。

管理员需要先完成的设置

这项功能并非开箱即用。据 AWS 介绍，设置分为两个角色：管理员准备集群，数据科学家创建并打开 Spaces。管理员需要完成的一次性设置如下。

  1. 安装 SageMaker Spaces 附加组件：AWS 表示可选择 Quick install 或 Custom install，其中 Custom install 是启用网页浏览器访问的必要选项。
  2. 配置 EKS access entries（集群的访问权限）：AWS 表示需将 AmazonSagemakerHyperpodSpacePolicy、AmazonSagemakerHyperpodUserClusterPolicy 和 AmazonSagemakerHyperpodSpaceTemplatePolicy 三项托管策略，附加到数据科学家使用的 IAM（AWS Identity and Access Management）角色。
  3. 启用逐用户身份传递：AWS 表示，若 Studio 域创建于此集成推出之前，必须启用这项设置，使每位用户在集群上的操作归属到其在 EKS access entries 与 AWS CloudTrail 中的用户配置文件，并落实 Space 所有权，即记录每个 Space 由谁创建、属于私有还是共享。

AWS 表示，更新域设置后，现有运行中的应用不受影响，用户下次登录时才会应用新设置。此外，AWS 列出了多项可选功能，包括由管理员预先定义配置的 Space 模板、通过 Kueue 实现的 Task Governance 配额与队列、按 Space 需求动态增减节点的 Karpenter 自动扩缩、空闲自动关闭、适用于 A100/H100 硬件的 NVIDIA MIG 部分 GPU 分配、EFS/FSx 持久卷，以及托管于 Amazon ECR 的自定义镜像。

启动时间与费用

AWS 表示，在使用 Karpenter 自动扩缩且缩容至零（没有任何待命节点）的集群上，首次创建 Space 默认会有 5–7 分钟的冷启动延迟，主要来自 Amazon EC2 实例启动、Kubernetes 节点注册和 SageMaker Distribution 镜像拉取。AWS 介绍的超额预置做法，是预先让一批节点保持运行并下载好镜像：用低优先级的占位 Deployment 在每个预热节点上放置一个“占位 Pod”，用户创建 Space 时再由调度器让 Space 取代（抢占）占位 Pod，据称可将启动时间缩短至约 30–40 秒。

AWS 公布的启动延迟，测试条件为 ml.m5.12xlarge 搭配约 3.5 GB 的 CPU 版 SageMaker Distribution 镜像
启动路径AWS 公布的延迟
Space 与占位 Pod 共存于同一节点约 14 秒
Space 抢占占位 Pod约 35 秒
冷启动（无预热池）5–7 分钟

费用方面，AWS 表示设置 SageMaker Spaces 附加组件不会产生额外费用，但用户需支付 Spaces 消耗的 HyperPod 集群计算资源，以及用于 SSH-over-SSM 远程连接的 AWS Systems Manager Advanced On-Premises Instance 按小时费用。

常见问题

这项功能和以前有什么不同？

AWS 表示，此前创建和管理 Spaces 主要依赖 HyperPod CLI 或 kubectl 命令；现在数据科学家可直接在 SageMaker Studio 的“IDE and Notebooks”选项卡中创建、配置、启动、停止和打开 Spaces。

数据科学家可以马上使用吗？

不一定。据 AWS 介绍，管理员必须先在 HyperPod EKS 集群上安装 SageMaker Spaces 附加组件、将三项托管策略附加到相关 IAM 角色；若 Studio 域创建于此集成推出之前，还须启用逐用户身份传递。

启动一个 Space 要等多久？

AWS 表示，在缩容至零的集群上冷启动约需 5–7 分钟；采用超额预置并预热节点后约 30–40 秒。AWS 注明这些数据仅适用于 CPU，GPU Spaces 需要另外配置。

使用这项功能会额外收费吗？

AWS 表示设置附加组件本身不另收费，但需支付 Spaces 消耗的 HyperPod 集群计算资源，以及 SSH-over-SSM 远程连接所用的 AWS Systems Manager Advanced On-Premises Instance 按小时费用。若采用超额预置，预热节点也会产生额外成本。

这些信息经过独立验证吗？

没有。本文所有内容均来自 AWS 官方博客单一来源，包括启动延迟数据在内，均为 AWS 自行公布。

查看同分类最新消息

同主题延伸阅读

资料来源

生活分享