AWS Machine Learning Blog

Manage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio

6.9内容质量
Manage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio

TL;DR · AI 摘要

Manage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio Artificial Intelligence Manage Amazon SageMaker H...

核心要点

  • 主题聚焦:Manage Amazon SageMaker HyperPod Spaces directly
  • 来源:AWS Machine Learning Blog,建议结合原文判断细节。
  • AI 分析暂不可用,本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

直接从 SageMaker Studio 管理 Amazon SageMaker HyperPod 空间 | 人工智能

直接从 SageMaker Studio 管理 Amazon SageMaker HyperPod 空间

我们最近推出了新功能,允许用户直接通过 Amazon SageMaker Studio 界面在 Amazon SageMaker HyperPod EKS 集群上创建和管理 Amazon SageMaker 空间。数据科学家和机器学习(ML)工程师现在可以在不离开浏览器或使用命令行工具的情况下,在 HyperPod 集群上启动 JupyterLab 和代码编辑器环境,将从集群访问到高效开发的时间缩短至几次点击。

背景

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

今年早些时候,我们推出了面向 HyperPod 的 Amazon SageMaker 空间,这是一个附加功能,开发者可以直接在 HyperPod EKS 集群上创建交互式开发环境。组织可以通过在相同基础设施上并行运行交互式工作负载、训练任务和模型部署,从而最大化 GPU 投资,同时支持分数 GPU 分配。

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

新功能

通过这项新功能,数据科学家现在可以直接从 SageMaker Studio 创建、配置、启动、停止和打开空间。HyperPod 集群详情页面上的新 IDE 和笔记本选项卡提供了完整的空间管理用户界面,消除了日常空间操作对 CLI 工具的依赖。

Studio 提供的关键功能包括:

  • 通过向导式表单配置计算资源、命名空间、存储、HyperPod 任务治理(用于计算配额管理和镜像设置)来创建空间。
  • 在可搜索的表格中查看所有空间,显示名称、应用类型、状态、访问类型、存储、GPU 和 vCPU 分配情况。
  • 通过单次选择启动或停止空间,当空间未使用时释放计算资源。
  • 直接在浏览器中打开空间(JupyterLab 或代码编辑器),或通过您选择的远程 IDE(例如 VS Code)进行连接。

图 1:HyperPod 集群详情页面上的 IDE 和笔记本选项卡展示了所有空间的状态、计算分配以及停止、打开或在远程 IDE 中打开的快速操作按钮

入门指南

设置涉及两个角色:管理员准备集群,数据科学家创建和打开空间。以下部分将分别介绍这两个角色的操作流程。

对于管理员

管理员通过 SageMaker HyperPod EKS 集群的 IDE 和 Notebooks 选项卡,使用快速安装(一键操作,使用优化后的默认设置)或自定义安装选项(需要设置 Web UI 访问权限)来安装 SageMaker Spaces 插件。安装完成后,管理员可以配置命名空间、创建 Space 模板,并通过 EKS 访问条目管理访问权限。

以下是一次性设置步骤,管理员必须完成:

  • 安装 Spaces 插件:通过 Amazon SageMaker AI 控制台打开您的 HyperPod 集群,进入 IDE 和 Notebooks 选项卡,选择快速安装或自定义安装(自定义安装是启用浏览器访问的必要条件)。详见 AWS 官方文档的完整操作指南。
  • 配置 EKS 访问条目:将三个托管策略 AmazonSagemakerHyperpodSpacePolicy、AmazonSagemakerHyperpodUserClusterPolicy 和 AmazonSagemakerHyperpodSpaceTemplatePolicy 附加到数据科学家使用的 AWS 身份和访问管理(IAM)角色。
  • 在 Studio 域上启用用户身份传播:如果 Studio 域在 SageMaker Studio 与 HyperPod Spaces 集成推出之前已创建,必须启用用户身份传播到 HyperPod EKS 集群。这确保每个 Studio 用户在集群上的操作(创建、停止或删除 Space)会记录到 EKS 访问条目和 AWS CloudTrail 中的用户档案。此外,这种身份映射强制实施严格的 Space 所有权规则,可追踪环境创建者,并确定 Space 是私有还是跨 SageMaker Studio 域共享。

每个 Studio 域仅需运行一次以下命令:

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

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

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

现有运行中的应用不受影响。用户在下次登录时会自动应用新设置。

  • 可选地启用其他功能:从下表中启用任意可选功能。

对于数据科学家

插件安装并配置访问权限后,数据科学家在 SageMaker Studio 的 Compute → HyperPod 中导航到其 HyperPod 集群,选择 IDE 和 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:通过浏览器访问的 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 风格网页界面

#### 在 Code Editor Space 中工作

对于偏好在浏览器中使用 VS Code 风格体验的开发者,Code Editor Spaces 提供了功能齐全的基于网页的轻量级 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。

可选功能

以下所有功能均为可选且可组合的。根据团队需求启用任意组合的功能。

| 功能 | 描述 | |------|------| | 浏览器访问 | 通过 Amazon Route 53 的 AWS 应用负载均衡器和自定义 DNS 将浏览器流量路由到 Spaces。远程 IDE(通过 SSM 的 VS Code)访问不需要此功能。 | | Space 模板 | 由管理员定义的模板,预先配置计算资源、镜像、存储和生命周期脚本,以实现跨团队的一致 Space 配置。 | | 任务治理 | 通过 Kueue 在命名空间级别设置计算配额、队列和基于优先级的准入控制,适用于多租户集群。 | | Karpenter 自动扩展 | 基于 Space 需求动态扩展/缩减节点。 | | Karpenter 预分配 | 预加载镜像的预热节点,将 Space 启动时间从 5-7 分钟缩短至约 30-40 秒。详见下文的 Pro tip 部分。 | | 持久化卷(EFS/FSx) | 跨 Spaces 持久化的共享用户目录和团队数据集。 | | 自定义镜像(ECR) | 团队特定的运行时和库,烘焙到托管在 Amazon Elastic Container Registry (Amazon ECR) 中的容器镜像。 | | 空闲关机 | 自动终止不活动的 Spaces 以防止计算成本失控。 | | NVIDIA MIG | 在 A100/H100 硬件上通过分段 GPU 分配实现成本高效的交互式工作负载。 |

Pro tip:通过节点预分配减少 Space 启动时间

默认情况下,使用 Karpenter 自动扩展的 SageMaker Spaces 在 HyperPod EKS 集群上首次在 scale-to-zero 集群创建 Space 时,会经历 5-7 分钟的冷启动延迟,主要由以下因素导致:

  • Amazon 弹性计算云(Amazon EC2)实例启动。
  • Kubernetes 节点注册。
  • SageMaker Distribution(SMD)镜像拉取。

对于对延迟敏感的交互式工作负载(如 JupyterLab、代码编辑器),可以使用标准的 Kubernetes 超配模式,通过维护一组预热且镜像缓存的节点池来优化性能。这可将 Space 启动时间从分钟级缩短至约 30-40 秒。

#### 实现原理

  • 一个低优先级(-1000)的占位符 Deployment 在每个预热节点上保持一个 Kubernetes Pod。这些 Pod 请求的 CPU/内存与真实 Space 相同。
  • 每个占位符 Pod 的 initContainer 在 Karpenter 为其分配节点时,预先将 SageMaker Distribution 镜像拉取到节点上。
  • 当用户创建 Space(默认优先级 0)时,Kubernetes 调度器会抢占占位符 Pod(优先级 -1000)。Space 随后会在已预热且镜像缓存的节点上快速启动(仅需数秒),无需镜像拉取和节点启动等待。
  • Karpenter 在后台为被抢占的占位符 Pod 提供替代节点。

了解更多关于 Pro tip 部署的技巧:HyperPod Spaces 的超配策略。

经验证的启动延迟数据基于 ml.m5.12xlarge 实例(24 vCPU 可分配,2 vCPU 占位符,8 GiB 占位符内存)和 sagemaker-distribution:latest-cpu SMD 镜像(约 3.5 GB):

| 路径 | 延迟 | |------|------| | Space 与占位符共存(coexist) | ~14 秒 | | Space 抢占占位符 | ~35 秒 | | 冷启动(无预热池) | 5-7 分钟 |

注意:这些数据仅针对 CPU。GPU Space 需要单独的占位符 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 高级本地实例支付每小时费用。详细信息请参阅 AWS Systems Manager 定价页面。

如果使用前述的超配方案,请注意预热节点会产生额外成本。根据实例类型和规模,这些节点会保持运行状态等待分配 Space。

结论

通过 SageMaker Studio 管理 HyperPod Spaces,弥合了数据科学家与高性能计算基础设施之间的差距。团队现在可以在几分钟内从集群访问过渡到运行中的 JupyterLab 或代码编辑器环境,无需学习 CLI 工具或 Kubernetes 概念。结合 HyperPod 任务治理、分体 GPU 支持和空闲关机等功能,组织可以在保持成本控制和资源公平性的同时,为共享集群提供自助服务访问。

要开始使用,请在 SageMaker AI 控制台中导航到您的 HyperPod EKS 集群,并选择 IDE 和笔记本选项卡。有关更多信息,请参阅 SageMaker HyperPod Spaces 文档。

作者简介

'"`