直接在 SageMaker Studio 中管理 Amazon SageMaker HyperPod Spaces

我们最近推出了直接在 Amazon SageMaker Studio UI 中创建和管理 Amazon SageMaker HyperPod EKS 集群上的 Amazon SageMaker Spaces 的功能。数据科学家和机器学习 (ML) 工程师现在无需离开浏览器或使用命令行工具，即可在 HyperPod 集群上启动 JupyterLab 和 Code Editor 环境，将他从获得集群访问权限到开始高效开发的时间缩短到只需几次点击。

背景

Amazon SageMaker HyperPod 为大规模基础模型 (FM) 训练和推理提供专用基础设施。借助 Amazon Elastic Kubernetes Service (Amazon EKS) 编排，团队可以在数百个加速器上运行分布式训练任务，并享有内置的弹性能力和自动故障恢复。除训练之外，HyperPod 还将这种 EKS 编排的基础设施扩展到为数十亿参数的基础模型提供低延迟、可扩展的推理服务。

今年早些时候，我们推出了 Amazon SageMaker Spaces for HyperPod，这是一个附加组件，机器学习开发人员可以用它直接在 HyperPod EKS 集群上创建交互式开发环境。这样，组织可以通过在同一基础设施上、与训练任务和模型部署一起运行交互式工作负载来最大化其 GPU 投资，并支持部分 GPU 分配。

此前，创建和管理 Spaces 主要依赖于 HyperPod CLI 或 kubectl 命令。虽然这种方式为基础设施管理员提供了强大且精细的控制，但偏好可视化界面的数据科学家现在可以使用这项新的 SageMaker Studio 功能，绕过命令行工具，完全专注于模型开发。

新增功能

借助这项新功能，数据科学家现在可以直接从 SageMaker Studio 创建、配置、启动、停止和打开 Spaces。HyperPod 集群详情页面上新增的 IDE and Notebooks 标签页为 Space 管理提供了完整的用户界面，免除了日常 Space 操作对 CLI 工具的需求。

通过 Studio 可用的关键功能包括：

• 通过引导式表单创建具有可配置计算资源、命名空间、存储、 HyperPod Task Governance （用于计算配额管理）和镜像设置的 Spaces。
• 在可搜索的表格中查看所有 Spaces，显示名称、应用程序类型、状态、访问类型、存储、GPU 和 vCPU 分配。
• 通过单次选择启动和停止 Spaces，以便在 Spaces 未使用时释放计算资源。
• 直接在浏览器中打开 Spaces（JupyterLab 或 Code Editor），或通过您选择的远程 IDE（例如 VS Code）进行连接。

图 1：HyperPod 集群详情页面上的 IDE and Notebooks 标签页显示了所有 Spaces 及其状态、计算分配，以及用于停止、打开或在远程 IDE 中打开的快捷操作

入门指南

设置涉及两种角色： 管理员 准备集群， 数据科学家 创建并打开 Spaces。以下章节将分别介绍。

面向管理员

管理员 安装 SageMaker Spaces 插件 到他们的 HyperPod EKS 集群上，可以使用的 快速安装 （一键式且采用优化默认设置）或 自定义安装 选项（设置 Web UI 访问所必需），该操作可在其 SageMaker HyperPod EKS 集群的 IDE and Notebooks 标签页中完成。安装完成后，管理员可以配置命名空间、创建 Space 模板，并通过 EKS 访问条目管理访问权限。

以下是管理员必须执行的一次性设置：

• 安装 Spaces 插件： 在 Amazon SageMaker AI 控制台中，打开您的 HyperPod 集群，前往 IDE and Notebooks 标签页，然后选择 快速安装 或 自定义安装 （必须使用自定义安装才能启用 Web 浏览器访问）。完整说明请参阅 AWS 文档 。
• 配置 EKS 访问条目： 将以下三个托管策略 AmazonSagemakerHyperpodSpacePolicy, AmazonSagemakerHyperpodUserClusterPolicy、 AmazonSagemakerHyperpodSpaceTemplatePolicy 附加到您的数据科学家所使用的 AWS Identity and Access Management (IAM) 角色。
• 在 Studio 域上启用按用户身份传播： 如果您的 Studio 域是在 SageMaker Studio 和 HyperPod Spaces 集成推出之前创建的，则必须启用到 HyperPod EKS 集群的按用户身份传播。这可确保每个 Studio 用户在集群上的操作（创建、停止或删除 Space）在 EKS 访问条目和 AWS CloudTrail 中都归因于其用户配置文件。此外，这种身份映射强制执行严格的 Space 所有权。它会跟踪哪个用户创建了环境，并确定 Space 是私有的还是在 SageMaker Studio 域内共享的。

对每个 Studio 域运行一次以下命令：

aws sagemaker update-domain \
    --domain-id $DOMAIN_ID \
    --default-user-settings '{
  "StudioWebPortalSettings": {
    "ExecutionRoleSessionNameMode": "USER_IDENTITY"
  }
}'

更新域后，验证以下命令是否返回“USER_IDENTITY”：

aws sagemaker describe-domain --domain-id $DOMAIN_ID \
    --query 'DefaultUserSettings.StudioWebPortalSettings.ExecutionRoleSessionNameMode'

现有正在运行的应用程序不受影响。用户将在下次登录时获取新设置。

• （可选）开启其他功能： 从下面的可选功能表中启用任意功能。

面向数据科学家

在安装附加组件并配置访问权限后，数据科学家在 SageMaker Studio 的 Compute 下导航到其 HyperPod 集群 → HyperPod，并选择 IDE and Notebooks 选项卡以查看 Spaces 管理界面（见图 1）。了解有关创建和管理 Spaces 的更多信息： 在 HyperPod 上创建和管理 Spaces.

当 Space 状态显示为 Running （在冷集群上通常需要几分钟，通过超额预配大约需要 30–40 秒）后，选择 Open 以在浏览器中启动 JupyterLab 或 Code Editor（图 2 和图 3），或选择 Open in VS Code 以通过 SSH-over-SSM 从本地编辑器连接（图 4）。

图 2：通过 Web 浏览器访问的 JupyterLab Space，显示包含可用笔记本内核、控制台和终端访问权限的启动器

在 JupyterLab Space 中工作

打开 JupyterLab Space 后，您将获得一个完全配置好的开发环境，并可以访问：

• 带有 ipykernel 的 Python 3 笔记本。
• Glue PySpark 和 Glue Spark 控制台。
• SparkMagic PySpark 和 Spark 内核。
• 用于运行命令的终端访问权限。
• 带有持久存储的文件浏览器。
• 内置聊天和上下文帮助。

您的工作会保存在所挂载的 Amazon Elastic Block Store (Amazon EBS) 卷上，因此您可以在不丢失进度的情况下停止和重新启动 Spaces。

图 3：在 HyperPod 上运行的 Code Editor Space，显示带有文件资源管理器、编辑器和集成终端的 VS Code 风格 Web 界面

在 Code Editor Space 中工作

对于喜欢浏览器中 VS Code 风格体验的开发人员，Code Editor Spaces 提供了一个轻量级的基于 Web 的 IDE，具有：

• 完整的文件编辑，支持语法突出显示和 IntelliSense。
• 集成终端，用于运行 shell 命令、提交训练任务或与集群资源交互。
• 扩展支持，包括语言服务器、代码检查器和格式化工具。
• Git 集成，用于版本控制工作流。
• 直接访问集群文件系统和挂载的 Amazon FSx 卷。

Code Editor Spaces 非常适合编写和调试训练脚本、管理实验配置以及处理代码仓库，而且全程无需离开浏览器。

图 4：本地 VS Code 实例远程连接到 HyperPod Space，显示远程连接指示器以及在集群算力上运行的完整 IDE 功能

远程 IDE 连接（VS Code）

在 Spaces 表中选择 Open in VS Code，将本地 Visual Studio Code 连接到 HyperPod 上运行的 Space。这内部使用 SSH-over-SSM 隧道，提供安全连接，无需您管理 SSH 密钥或暴露端口 22。

您可以获得本地 VS Code 环境的全部功能，包括扩展、主题和键绑定，同时在 HyperPod 集群算力上执行代码。

您也可以使用 AWS Toolkit for Visual Studio Code 进行连接，它会在 SageMaker AI > HyperPod 下列出您的 Spaces，您可以直接从工具包面板启动、停止和连接到 Spaces。

可选能力

以下每一项能力都是可选的且可组合。可启用符合团队需求的任意组合。

专业提示:通过节点超额预置减少 Space 启动时间

默认情况下,在使用 Karpenter 自动扩缩容的 HyperPod EKS 集群上的 SageMaker Spaces 会有一个 冷启动延迟,即 5–7 分钟 这是在扩容至零(scale-to-zero)的集群上首次创建 Space 时的延迟,主要由以下部分构成:

• Amazon Elastic Compute Cloud(Amazon EC2)实例启动。
• Kubernetes 节点注册。
• SageMaker Distribution(SMD)镜像拉取。

对于延迟敏感的交互式工作负载(JupyterLab、Code Editor),您可以维护一个 预热且缓存了镜像的节点池 使用标准的 Kubernetes 过度预配（over-provisioning）模式。这将 Space 的启动时间从数分钟缩短到大约 30–40 秒。

工作原理

1. 一个低优先级（-1000）占位 Deployment 在每个温备节点上保留一个 Kubernetes pod。这些 pod 申请的资源（CPU/内存）与真实 Space 所需的相同。
2. 每个占位 pod 上的一个 initContainer 在 Karpenter 预配节点时，将 SageMaker Distribution 镜像预拉取到节点上。
3. 当用户创建 Space（默认优先级 0）时，Kubernetes 调度器会抢占占位 pod（优先级 -1000）。于是 Space 在几秒内落到已经预热且镜像已缓存的节点上，无需拉取镜像，也无需等待节点启动。
4. Karpenter 在后台为被替换的占位符预置一个替代节点。

了解更多关于专业技巧部署的信息： HyperPod Spaces 的超额预置.

已验证的启动延迟 在 ml.m5.12xlarge （24 个可分配 vCPU，2 个 vCPU 占位符，8 GiB 占位符内存）上，使用 sagemaker-distribution:latest-cpu SMD 镜像，该镜像大小约为 3.5 GB：

注意： 这些数字仅适用于 CPU。GPU Spaces 需要自己的占位符 Deployment，请求 nvidia.com/gpu 并预拉取 GPU 镜像。否则，GPU 节点将保持冷状态，而且 GPU 镜像大小约为 10 GB，其拉取成本远高于 3.5 GB 的 CPU 镜像。

注意： 每个温节点都保持一个处于 Running 状态的 EC2 实例。对于按需节点，这意味着保持温节点运行会产生额外成本。

有关安装 HyperPod Spaces 附加组件和入门的更多信息，请参阅 AWS 文档.

定价

配置 SageMaker Spaces 附加组件不会产生额外费用。您需要为您的 Spaces 消耗的底层 HyperPod 集群计算资源付费，并为用于基于 SSH-over-SSM 远程连接的 AWS Systems Manager Advanced On-Premises Instance 按小时付费。详情请参阅 AWS Systems Manager 定价 。

如果您使用前文所述的超额预置，请注意温节点会产生额外成本。根据实例类型和大小，这些节点会保持在运行状态以等待预置 Spaces。

结论

通过 SageMaker Studio 管理 HyperPod Spaces 弥合了数据科学家与高性能计算基础设施之间的鸿沟。团队现在可以在几分钟内从集群访问进入运行中的 JupyterLab 或 Code Editor 环境，而无需学习 CLI 工具或 Kubernetes 概念。结合 HyperPod Task Governance、分数 GPU 支持和空闲关机等功能，组织可以在保持成本控制和资源公平性的同时，为共享集群提供自助访问。

要开始使用，请在 SageMaker AI 控制台中导航到您的 HyperPod EKS 集群，并选择 IDE and Notebooks 选项卡。更多信息请参阅 SageMaker HyperPod Spaces 文档。

关于作者