在 SageMaker Studio 中直接管理 Amazon SageMaker HyperPod Spaces
Manage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio
Amazon SageMaker 推出新功能,可在 SageMaker Studio UI 中直接创建和管理 HyperPod EKS 集群上的 Spaces,数据科学家无需命令行工具即可启动 JupyterLab 和 Code Editor 环境。
我们最近推出了直接从 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,这是一个附加组件,ML 开发者可以用它直接在 HyperPod EKS 集群上创建交互式开发环境。组织随后可以通过在同一基础设施上运行交互式工作负载以及训练作业和模型部署,并支持 GPU 分数分配,从而最大化其 GPU 投资。
此前,创建和管理 Spaces 主要依赖 HyperPod CLI 或 kubectl 命令。虽然这种方法为基础设施管理员提供了强大而精细的控制,但偏好可视化界面的数据科学家现在可以使用这项新的 SageMaker Studio 功能,绕过命令行工具,完全专注于模型开发。
新增内容
借助这项新功能,数据科学家现在可以直接从 SageMaker Studio 创建、配置、启动、停止和打开 Spaces。HyperPod 集群详情页上新增的 IDE and Notebooks 选项卡提供了完整的 Space 管理用户界面,无需再为日常 Space 操作使用 CLI 工具。
通过 Studio 可用的主要功能包括:
- 通过引导式表单创建 Spaces,可配置计算、命名空间、存储、用于计算配额管理的 HyperPod Task Governance 以及镜像设置。
- 在可搜索的表格中查看所有 Spaces,显示名称、应用程序类型、状态、访问类型、存储、GPU 和 vCPU 分配。
- 通过单次选择启动和停止 Spaces,在 Spaces 不使用时释放计算资源。
- 直接在浏览器中打开 Spaces(JupyterLab 或 Code Editor),或通过您选择的远程 IDE(例如 VS Code)连接。
图 1:HyperPod 集群详情页上的 IDE and Notebooks 选项卡显示所有 Spaces 及其状态、计算分配,以及停止、打开或在远程 IDE 中打开的快捷操作
开始使用
设置涉及两种角色:管理员准备集群,数据科学家创建并打开 Spaces。以下各节分别介绍。
对于管理员
管理员在其 HyperPod EKS 集群的 IDE and Notebooks 选项卡中,使用快速安装(一键使用优化默认值)或自定义安装选项(设置 Web UI 访问所必需)在其 HyperPod EKS 集群上安装 SageMaker Spaces 附加组件。安装完成后,管理员可以配置命名空间、创建 Space 模板,并通过 EKS 访问条目管理访问权限。
以下是管理员必须执行的一次性设置:
- 安装 Spaces 附加组件: 在 Amazon SageMaker AI 控制台中,打开您的 HyperPod 集群,转到 IDE and Notebooks 选项卡,然后选择 Quick install 或 Custom install(启用 Web 浏览器访问需要选择 Custom install)。完整说明请参阅 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 中导航到其 HyperPod 集群,路径为 Compute → 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,显示带有可用笔记本内核、控制台和终端访问的 Launcher
在 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 命令、提交训练作业或与集群资源交互。
- 支持语言服务器、linter 和格式化工具的扩展。
- 用于版本控制工作流的 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。
可选能力
以下每项能力都是可选的且可组合。启用任何符合你团队需求的组合。
| 能力 | 描述 |
| Web 浏览器访问 | 通过 AWS Application Load Balancer 和 Amazon Route 53 自定义 DNS 将浏览器流量路由到 Spaces。远程 IDE(通过 SSM 的 VS Code)访问不需要此项。 |
| Space 模板 | 由管理员定义的模板,预先配置计算、镜像、存储和生命周期脚本,以便在各团队之间保持一致的 Space 配置。 |
| 任务治理 | 通过 Kueue 为多租户集群提供命名空间级计算配额、队列和基于优先级的准入。 |
| Karpenter 自动扩缩 | 根据 Space 需求动态扩缩节点。 |
| Karpenter 超额配置 | 预先预热并预拉取镜像的节点,可将 Space 启动时间从 5–7 分钟缩短到约 30–40 秒。请参阅下面的专业提示部分。 |
| 持久卷(EFS / FSx) | 跨 Spaces 持久存在的共享用户目录和团队数据集。 |
| 自定义镜像(ECR) | 团队特定的运行时和库,烘焙到托管在 Amazon Elastic Container Registry(Amazon ECR)中的容器镜像里。 |
| 空闲关闭 | 自动终止不活跃的 Spaces,以防止计算成本失控。 |
| NVIDIA MIG | 在 A100/H100 硬件上为成本高效的交互式工作负载提供分数 GPU 分配。 |
专业提示:通过节点超额配置减少 Space 启动时间
默认情况下,使用 Karpenter 自动扩缩的 HyperPod EKS 集群上的 SageMaker Spaces,在 scale-to-zero 集群上首次创建 Space 时会产生 5–7 分钟的冷启动延迟,主要来自:
- Amazon Elastic Compute Cloud(Amazon EC2)实例启动。
- Kubernetes 节点注册。
- SageMaker Distribution(SMD)镜像拉取。
对于延迟敏感的交互式工作负载(JupyterLab、Code Editor),你可以使用标准的 Kubernetes 超额配置模式维护一组预先预热、已缓存镜像的节点。这可将 Space 启动时间从数分钟缩短到约 30–40 秒。
工作原理
- 一个低优先级(
-1000)的占位 Deployment 在每个预热节点上保留一个 Kubernetes pod。这些 pod 请求与真实 Space 相同的 CPU/内存。 - 每个占位符上的
initContainer会在 Karpenter 配置节点时将 SageMaker Distribution 镜像预拉取到该节点上。 - 当用户创建一个 Space(默认优先级
0)时,Kubernetes 调度器会抢占占位符(优先级-1000)。随后,Space 会在几秒钟内落到已经预热、已缓存镜像的节点上,无需拉取镜像,也无需等待节点启动。 - Karpenter 会在后台为被驱逐的占位符配置一个替换节点。
了解有关 Pro tip 部署的更多信息:为 HyperPod Spaces 超额配置。
在 ml.m5.12xlarge(24 vCPU 可分配,2 vCPU 占位符,8 GiB 占位符内存)上使用 sagemaker-distribution:latest-cpu SMD 镜像(约 3.5 GB)的已验证启动延迟:
| 路径 | 延迟 |
| Space 与占位符共存(共存) | ~14 秒 |
| Space 抢占占位符 | ~35 秒 |
| 冷启动(无预热池) | 5-7 分钟 |
注意:这些数字仅适用于 CPU。GPU Spaces 需要自己的占位符 Deployment,请求 nvidia.com/gpu 并预先拉取 GPU 镜像。否则,GPU 节点会保持冷状态,而且 GPU 镜像大约 10 GB,拉取成本远高于 3.5 GB 的 CPU 镜像。
注意:每个预热节点会保持一个 EC2 实例处于 Running 状态。对于按需节点,这意味着保持预热节点运行会产生额外成本。
有关安装 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 文档。
关于作者
Giuseppe Angelo Porcelli
Giuseppe 是 Amazon Web Services 的首席机器学习专家解决方案架构师。他拥有多年的软件工程和机器学习背景,与各种规模的客户合作,深入了解他们的业务和技术需求,并设计能够充分利用 AWS Cloud 和 Amazon Machine Learning 堆栈的 AI 和机器学习解决方案。他参与过不同领域的项目,包括 MLOps、计算机视觉、NLP,并涉及广泛的 AWS 服务。空闲时间,Giuseppe 喜欢踢足球。
Mayank Gupta
Mayank 是一位资深 AI/ML 专家,在机器学习框架和企业 AI 架构方面拥有深厚专长。他在 AWS AI 服务方面积累了丰富的实践经验,包括 SageMaker AI 和 SageMaker AI HyperPod,并主导端到端 AI 解决方案的设计与交付,涵盖模型开发、分布式训练和生产级部署。凭借在性能优化和可扩展 ML 架构方面的深厚经验,Mayank 与客户合作,将复杂的业务挑战转化为安全、高影响力、生产就绪的 AI 系统,从而带来可衡量的成果。
来源:AWS Machine Learning Blog · aws.amazon.com



