一句话结论
AWS 推出 SageMaker Studio 界面集成 HyperPod Spaces 功能，数据科学家可在浏览器中直接创建、配置和启动环境，无需使用命令行工具。
关键要点
- 新增功能允许在 Amazon SageMaker Studio UI 中直接创建和管理运行在 Amazon EKS 上的 Amazon SageMaker Spaces，此前主要依赖 CLI 或 kubectl 命令。
- 数据科学家可在浏览器中启动 JupyterLab 和代码编辑器环境；Space 停止并重启后，数据会持久化在附加的 Amazon EBS 卷上，不会丢失进度。
- 使用 Karpenter 过度配置预热节点后，冷启动时间从默认的 5-7 分钟显著降低；在 ml.m5.12xlarge 实例上，CPU 镜像启动约 14 秒，抢占场景约 35 秒。
- 管理员需安装 SageMaker Spaces 附加组件，并配置特定的 IAM 策略（如 AmazonSagemakerHyperpodSpacePolicy）及访问条目，以赋予数据科学家创建权限。
- “Open in VS Code” 功能通过 SSH-over-SSM 隧道连接本地编辑器，无需管理 SSH 密钥或暴露端口 22，但产生 AWS Systems Manager 每小时连接费用。
背景与事实
Amazon Web Services (AWS) 机器学习博客发布了一项功能更新，允许开发人员通过 Amazon SageMaker Studio 用户界面直接管理 Amazon SageMaker HyperPod Spaces。这一变化解决了此前数据科学家和机器学习工程师在管理基础设施时需要频繁切换至命令行工具（如 HyperPod CLI 或 kubectl）的痛点。HyperPod 旨在为大规模基础模型训练和推理提供基础设施，通过 Amazon EKS 编排，支持跨数百个加速器运行分布式训练，并具备内置弹性和自动故障恢复功能。此前，虽然推出了支持分数 GPU 分配的 Spaces 附加组件，但其管理界面主要位于 HyperPod 集群详情页的底部，且操作流程较为底层。
在新功能下，HyperPod 集群详情页新增了“IDE 和 Notebooks”标签页，提供完整的 Space 管理用户界面。设置过程涉及两种角色：管理员和数据科学家。管理员负责准备集群，通过“快速安装”或“自定义安装”选项在 HyperPod EKS 集群上安装 SageMaker Spaces 附加组件。安装后，管理员需配置命名空间、创建 Space 模板，并通过 EKS 访问条目管理访问权限。此外，必须将 AmazonSagemakerHyperpodSpacePolicy、AmazonSagemakerHyperpodUserClusterPolicy 和 AmazonSagemakerHyperpodSpaceTemplatePolicy 附加到数据科学家使用的 AWS Identity and Access Management (IAM) 角色。每个 Studio 域需运行一次验证命令以确认“USER_IDENTITY”。
数据科学家在 SageMaker Studio 的 Compute → HyperPod 路径下选择“IDE 和 Notebooks”标签页即可访问管理界面。当 Space 状态显示为 Running 后，用户可选择“Open”在浏览器中启动 JupyterLab 或代码编辑器。JupyterLab Space 提供完全配置的开发环境，工作数据持久化在附加的 Amazon Elastic Block Store (Amazon EBS) 卷上；代码编辑器 Space 则提供轻量级基于 Web 的 IDE，适合编写调试脚本和管理配置。对于偏好本地工具的用户，可通过“Open in VS Code”使用 SSH-over-SSM 连接，本地 VS Code 环境保留扩展和主题，而代码在 HyperPod 集群计算资源上执行。也可使用 AWS Toolkit for Visual Studio Code 连接，在 SageMaker AI > HyperPod 下列出并操作 Spaces。
影响分析
对于中文开发者与从业者而言，此次更新显著降低了使用大规模高性能计算集群的技术门槛。此前，配置 Kueue 进行命名空间级配额管理、使用 Karpenter 进行动态扩缩容以及配置 Amazon EFS/FSx 持久卷等操作通常需要深入的 Kubernetes 专业知识。现在，通过 Studio 的图形化界面和预配置的 Space 模板（包含计算、镜像、存储及生命周期脚本），数据科学家可以更专注于模型实验而非基础设施管理。特别是对于使用 NVIDIA MIG 技术进行 A100/H100 分数 GPU 分配的场景，简化后的界面使得资源利用更直观。然而，管理员仍需承担集群初始化和 IAM 策略配置的责任，这意味着团队内部的职责划分将更加明确：管理员负责底层稳定性与安全性，数据科学家负责上层应用开发。
此外，启动速度的优化对迭代效率有直接帮助。默认冷启动延迟为 5-7 分钟，但利用 Karpenter 过度配置预热节点并预拉取镜像后，在 ml.m5.12xlarge 实例（24 vCPU，CPU 镜像约 3.5 GB）上，共存场景启动时间约为 14 秒，抢占场景约为 35 秒。GPU 镜像约 10 GB，需单独配置占位 Deployment。这一改进意味着频繁启动和停止开发环境（以节约成本）变得可行，空闲自动终止功能可防止成本失控。虽然配置插件本身无额外收费，但需支付 HyperPod 集群计算费及 SSH-over-SSM 连接费，团队需据此调整成本预算模型。
适用边界
该结论适用于已部署 Amazon SageMaker HyperPod EKS 集群且安装了相应附加组件的环境。对于仅使用 Amazon SageMaker 标准容器实例、未启用 HyperPod 基础设施的用户，此功能不可用。此外，远程 IDE（VS Code over SSM）功能不依赖于 AWS Application Load Balancer 和 Amazon Route 53 的配置（这些用于路由浏览器流量至 Spaces），但需要 AWS Systems Manager 权限。若用户所在的网络环境严格限制出站流量或无法访问 AWS 端点，SSH-over-SSM 隧道可能受限。预热节点策略产生的额外 EC2 实例运行费用在低成本敏感度场景下可能不推荐默认启用。
孤本观察
从编辑视角判断，AWS 通过将底层 Kubernetes 抽象封装进 Studio UI，实质上是将“基础设施管理”与“应用开发”在工具层面进行了物理隔离，这预示着云原生机器学习工作流正进一步向低代码/无代码界面倾斜，但前提是用户愿意承担管理员侧的复杂配置职责。
常见问题
数据科学家在 SageMaker Studio 中管理 HyperPod Spaces 需要哪些 IAM 策略？
需附加 AmazonSagemakerHyperpodSpacePolicy、AmazonSagemakerHyperpodUserClusterPolicy 和 AmazonSagemakerHyperpodSpaceTemplatePolicy。
使用 Karpenter 预热节点后，ml.m5.12xlarge 实例启动 CPU 镜像需多久？
共存场景约 14 秒，抢占场景约 35 秒。
Space 停止并重启后，数据是否丢失？
不会。工作数据持久化在附加的 Amazon EBS 卷上，重启后进度不会丢失。
“Open in VS Code” 功能产生什么额外费用？
产生 AWS Systems Manager 每小时连接费用，插件本身无额外收费。
哪些用户无法使用该集成功能？
仅使用 Amazon SageMaker 标准容器实例、未部署 HyperPod EKS 集群或未安装相应附加组件的用户不可用。