Amazon SageMaker HyperPod 为机器学习（ML）团队提供用于训练和微调模型的大型加速计算资源池。当多个团队共享一个集群时，技术设置通常比较简单。具有挑战性的部分是治理。您必须决定哪些团队可以使用集群、每个团队获得多少容量、当一个团队的工作负载与另一个团队竞争时该如何处理，以及当使用偏离政策时由谁负责。 Amazon SageMaker Unified Studio 带来了另一个考量：您可以将 SageMaker HyperPod 集群连接到项目，使团队成员可以从其项目工作区启动工作负载。这种便利性很有价值，但在多个团队共享对同一集群的可见性之后，管理谁能做什么的控制就变得更加重要。在本文中，我们将展示如何在保持底层治理控制的同时，通过 SageMaker Unified Studio 管理 SageMaker HyperPod。我们涵盖四个控制层：组织、项目、集群和工作负载。我们还解释了如何在这些层之间设计身份、容量和可观测性策略。到最后，您将拥有一个可重复的模型，用于在项目环境中向 ML 团队提供经过批准的 SageMaker HyperPod 计算，同时将集群运营保留在基础设施团队手中。
Amazon SageMaker HyperPod 是 Amazon SageMaker AI的一项功能。Amazon SageMaker Unified Studio 是数据与 AI 开发环境，团队在其中使用他们的数据和工具进行构建。通过 SageMaker Unified Studio，您可以将项目连接到现有的 SageMaker HyperPod 集群。成员随后可以启动机器学习工作负载、查看集群和任务信息，并打开 JupyterLab 工作流。您仍然通过 Amazon SageMaker AI 界面和 API 管理集群。
这种分离为基础设施团队提供了一个有用的运营模式。您可以通过既有的云运营流程管理集群基础设施。同时，您可以在项目环境中向机器学习团队提供经过批准的计算资源。在本文中，我们描述了如何设计基础设施边界、治理访问权限、分配共享容量，并通过 SageMaker Unified Studio 一致地运营 SageMaker HyperPod。
了解管理边界
一个治理良好的环境会将组织管理、项目访问和集群运营分开。每一层回答不同的问题，并使用不同的控制。下表总结了每个边界、其主要控制及其管理目的。
| 边界 | 主要控制 | 管理目的 |
| 组织 | SageMaker Unified Studio 域、域单元、关联账户、项目配置文件和授权策略 | 决定谁可以创建项目、项目可以使用哪些账户和区域，以及可用的工具 |
| 项目 | 项目成员资格、项目角色和 SageMaker HyperPod 连接 | 定义协作环境以及项目成员可以访问的 AWS 资源 |
| 集群 | SageMaker HyperPod 集群管理员角色、Amazon EKS 访问条目、基于角色的访问控制（RBAC）和 EKS Pod Identity，或 Slurm 控制 | 管理集群配置、调度器访问、命名空间、任务和基础设施运营 |
| 工作负载 | 计算分配、优先级类、借入借出策略和任务权限 | 控制谁可以提交工作以及如何分配共享容量 |
将这些控制视为多个层次。SageMaker HyperPod 连接会将一个经过批准的集群添加到项目中。它不会取代集群的 AWS Identity and Access Management（IAM）、Amazon Elastic Kubernetes Service（Amazon EKS）或 Slurm 控制。应综合审查项目角色、连接访问角色、EKS 访问条目和 RBAC 或 Slurm 控制、工作负载身份、数据和 AWS Key Management Service（AWS KMS）密钥 策略、网络策略、任务视图限制以及调度器策略。只有在这些控制保持一致之后，才使集群可用。
这些控制构成四个层次，如下图所示。
图 1：四个控制层：组织、项目、集群和工作负载。每一层回答不同的问题并使用不同的控制措施，因此应在各自的边界处进行审查。
SageMaker Unified Studio 项目是协作边界，而不是强大的运行时安全边界。请将 SageMaker HyperPod 集群、调度器以及稀缺的加速器容量保留在一个指定的容量账户之下。经批准的用户和数据集可以留在同一账户中，也可以分别位于消费者账户和数据账户中。AWS 记录了 Amazon EKS 集群上 SageMaker HyperPod 任务治理的多账户支持。尽管按需容量预留可以在多个账户之间共享，但应将 SageMaker HyperPod 集群所有权和容量管理集中到容量账户中。请使用经批准的跨账户访问，而不是让每个消费者账户都成为独立的容量管理员。
- 对于 Amazon EKS，可为每个租户使用一个命名空间，并结合 RBAC、按租户的服务账户和 EKS Pod Identity 角色、默认拒绝的网络策略，以及租户特定的存储和 AWS KMS 权限。对于 Slurm，可使用带有层级账户和关联的 Slurm 计费、服务质量 (QoS)、优先级与公平份额策略以及分区。还应使用操作系统身份和文件权限、网络控制以及租户特定的数据路径。
- 使用 IAM 角色和资源策略，而不仅仅依靠项目成员资格，来控制对 Amazon Simple Storage Service (Amazon S3) 存储桶、AWS KMS 密钥、密钥机密、容器注册表和其他数据服务的访问。使用项目和域单元策略来实现协作与委托。
- 对于 Amazon EKS 集群，可使用 SageMaker HyperPod 任务治理（包括配额、优先级类、借还机制和抢占）来公平地共享中央加速器池。对于 Slurm 集群，可使用原生的分区、服务质量 (QoS)、优先级、公平份额和抢占控制。Slurm 不提供相同的借还模型。这些调度控制决定已授权的工作负载何时获得计算资源。它们不会授予命名空间或数据访问权限。
若要在集群内部实现更强的隔离，可在适当情况下使用专用节点或节点组以及准入控制。当法律、法规或安全要求需要硬性基础设施隔离时，可使用单独的集群或账户。跨账户消费者访问可以在不复制中央 SageMaker HyperPod 集群的情况下保留账户级所有权。在容量账户内，使用 项目配置文件 和 域单元 以及项目授权策略来委托项目创建和所有权。
下图展示了集中式容量以及租户特定的工作负载、身份、数据、网络和可见性控制。
图 2：集中式 SageMaker HyperPod 容量。集群和调度器保留在一个容量账户中。每个租户获得工作负载、身份、数据、网络和任务可见性控制。硬性隔离需求使用专用基础设施。
图 3 展示了当 SageMaker Unified Studio 向项目成员公开已批准的 SageMaker HyperPod 计算资源时，这些边界是如何连接的。
图 3：推荐的 SageMaker HyperPod 管理模型。SageMaker Unified Studio 管理协作上下文，而集群身份、工作负载授权、调度器策略和运维控制保持独立。
确定 SageMaker Unified Studio 何时是合适的管理体验
借助 SageMaker Unified Studio，已经在项目中工作的机器学习团队可以通过一条已批准的路径使用共享的 SageMaker HyperPod 计算资源。成员可以查找已连接的集群、查看状态和元数据、检查支持的任务和指标，并直接进入 JupyterLab，无需使用单独的基础设施清单。
这种体验并不能取代集群管理。下表显示了每种角色应如何在使用服务专属界面的同时使用 SageMaker Unified Studio。
| 角色 | 使用 SageMaker Unified Studio 进行 | 继续使用服务专属工具进行 |
| 域或基础设施管理员 | 域单元、项目创建策略、项目配置文件、成员资格策略和账户放置 | 组织级控制、账户预置和基础设施自动化 |
| SageMaker HyperPod 集群管理员 | 呈现已批准的集群连接，并查看集群、任务、设置和元数据视图 | 集群创建、更新、韧性配置、附加组件、EKS 或 Slurm 管理以及事件响应 |
| 项目所有者 | 管理项目成员资格，并为用户提供针对已批准计算资源的一致项目上下文 | 请求基础设施变更并批准业务特定的访问要求 |
| 机器学习工程师或数据科学家 | 查找已批准的计算资源、查看工作负载状态并打开 JupyterLab 工作流 | 通过 SageMaker HyperPod CLI, kubectl、Slurm 工具或其他适当的工具提交和管理详细的工作负载 |
当项目成员资格、数据访问、开发工具和计算需要共享一个统一上下文时，请使用 SageMaker Unified Studio。对于集群变更和可重复的自动化，请继续使用 SageMaker AI API、基础设施即代码和编排工具。有关参考实现和集成，请参阅 AI on SageMaker HyperPod 网站。
在连接集群之前做出基础设施决策
在批准连接之前，请记录容量账户、所有消费者或数据账户、AWS 区域、网络路径、身份、所有者、工作负载边界以及隔离要求。如果您需要创建集群的指导，请参阅 Amazon SageMaker HyperPod 文档 或 AI on SageMaker HyperPod 网站.
将管理工作身份与工作负载身份分离。在创建项目和访问角色时，保留 SageMaker HyperPod 对集群管理员与数据科学家用户的区分。项目相关角色不应仅因其用户运行工作负载而获得集群生命周期权限。请参阅 AWS Identity and Access Management for SageMaker HyperPod 以了解受支持的权限模型。
将网络视为端到端控制。将 Amazon EKS Kubernetes API 端点访问限制在经批准的管理网络路径上，控制 Pod 的入站和出站流量，并验证项目、连接角色、工作负载角色和集群网络仅支持预期的数据路径。有关编排器特定的配置，请参阅 Orchestrating SageMaker HyperPod clusters with Amazon EKS.
例如，将 Amazon EKS API 端点配置为私有访问，并仅允许来自经批准的管理员或工作负载子网的访问。应用默认拒绝（default-deny）的 Kubernetes NetworkPolicy 策略，并显式允许所需的服务间通信和出站路径。在适当的情况下，为 Amazon S3、Amazon Elastic Container Registry（Amazon ECR）和 Amazon CloudWatch 等服务使用虚拟私有云（VPC）端点，并为每个租户分配专用的数据访问工作负载角色。
创建连接契约。连接契约是客户管理的治理记录，例如 wiki 页面、工单、服务目录记录或在基础设施即代码仓库中跟踪的文件。它不是平台功能。为每个经批准的项目到集群的连接记录以下信息：
- 业务负责人、运营负责人和成本负责人。
- SageMaker Unified Studio 域单元和项目。
- 集群账户、Region、名称和编排器。
- 项目角色以及该连接使用的访问角色 Amazon Resource Name（ARN）。
- 经批准的工作负载类型和数据分类。
- EKS 命名空间或 Slurm 访问范围。
- 调度策略和例外负责人。
- 监控、支持和停用预期。
该契约为评审者提供单一记录，用于评估和批准完整的访问路径。
治理身份和任务可见性
同时控制操作和可见性。任务名称、命名空间、资源请求和使用模式的不当设置可能泄露其他团队工作的信息。
在可能的情况下，使用组而非单个授权来管理项目成员资格和集群访问。应在各自的边界内审查每个角色，而不是创建一个跨越域、项目、集群和工作负载策略的宽泛角色。
以下工作流程展示了如何将用户的可见范围与用户的操作能力分离。
图 4：治理身份和任务可见性。通过组分配访问权限，将每个角色限定在其边界内，限制任务可见性，并将查看工作的能力与对工作采取行动的能力分开。
在引入用户之前审查默认任务可见性。 SageMaker AI Studio 中 SageMaker HyperPod 的文档 说明，SageMaker AI Studio 用户默认可以看到所有 Amazon EKS 集群任务。对于 Slurm 集群，每个 SageMaker AI Studio 用户都可以查看、管理可用任务并与之交互。在引入多个团队之前配置任务视图限制：Amazon EKS 请参阅 Restrict task view in Studio for EKS clusters ，Slurm 请参阅 Restrict task view in Studio for Slurm clusters 。项目成员资格并不是集群级别的安全边界。
对于 Amazon EKS 集群，将每个团队映射到经批准的命名空间和 RBAC 权限，并将每个工作负载服务账户映射到租户专用的 IAM 角色。对于跨账户数据访问，将服务账户与容量（集群）账户中的 EKS Pod Identity 角色关联，并在该关联上设置目标 IAM 角色（targetRoleArn）。EKS Pod Identity 随后会自动执行跨账户角色代入，因此应用程序代码无需调用 AssumeRole。目标角色位于使用者账户或数据账户中。将只读可见性与创建、更新或删除工作负载的权限分开。对于 Slurm 集群，定义等效的用户、账户、分区、文件系统和任务可见性控制。
例如，以下 Kubernetes RBAC Role 仅授予某团队对其自身命名空间中作业的只读访问权限。创建或删除工作负载需要单独的角色，从而将“查看”与“操作”分开。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-research
name: research-job-viewer
rules:
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["kubeflow.org"]
resources: ["pytorchjobs"]
verbs: ["get", "list", "watch"]将业务优先级转化为调度策略
对于 Amazon EKS 集群，应仅在身份和工作负载访问控制到位后再应用任务治理。
下图将其中涉及的两个决策区分开来。
图 5：保持授权与调度策略分离。EKS RBAC 或 Slurm ACL 决定用户是否可以提交工作负载。适用于 Amazon EKS 的 SageMaker HyperPod 任务治理或原生 Slurm 调度控制决定其何时获得计算资源。
文档化保证容量与共享容量、优先级类，以及一个团队是否可以使用另一团队的空闲分配。为每个例外分配负责人。任务治理也适用于 SageMaker HyperPod spaces （直接在集群上运行的独立 JupyterLab 或 Code Editor 环境），因此请将这些交互式开发工作负载纳入分配策略。
例如，在 Amazon EKS 集群上，你可以给生产训练团队保证 60% 的分配和高优先级类，让研究团队以较低优先级借用空闲容量，并在生产团队提交工作时允许抢占该借用的容量。指定一名负责人来审批此策略的任何例外，以免一次性请求悄然成为常态。
将授权与调度策略分开。EKS RBAC 或 Slurm ACL 决定用户能否提交工作负载。Amazon EKS 的 SageMaker HyperPod 任务治理或原生 Slurm 调度控制，决定该已获授权的工作负载何时获得计算资源。将调度器配额用作访问控制，或将授权控制用作调度策略，都会产生不明确的行为并使事故更难诊断。
文章 《Amazon SageMaker HyperPod 任务治理最佳实践》 解释了公平共享权重、配额、借出与借用、优先级类以及常见分配场景。对于 Amazon EKS 集群，在定义分配策略时使用这些模式。对于 Slurm 集群，使用前文所述的原生调度器控制。
将可观测性用作治理反馈环
借助 SageMaker Unified Studio，你可以查看任务的 SageMaker HyperPod 集群详细信息、指标、设置和元数据。对于 Amazon EKS 集群，任务治理指标包括硬件、团队和任务视图。这些视图帮助你将策略意图与实际消耗进行比较。
将可观测性视为一个循环，如下图所示。
图 6：作为治理反馈环的可观测性。监控信号，将其与策略意图进行比较，决定响应，并调整策略和分配，为每个信号指定负责人和响应。
为你监控的每个信号定义负责人和响应。以下示例将仪表板数据转化为管理决策。
| 信号 | 管理决策 |
| 集群容量与加速器利用率 | 判断低利用率是临时性的、策略驱动的，还是由工作负载约束造成的 |
| 团队分配与利用率 | 审查保留容量和共享容量是否仍反映业务需求 |
| 任务运行时间与等待时间 | 调查优先级策略、工作负载规模或容量争用 |
| 挂起与被抢占的任务 | 确认调度器结果符合已批准的优先级模型 |
| 节点健康状况与恢复事件 | 启动集群事故流程并验证恢复目标 |
对于 Amazon EKS 集群，任务表显示 Kubeflow 任务（PyTorch、MPI 和 TensorFlow），默认显示 PyTorch 任务。通过其他机制提交的工作负载可能不会出现在其中。对于 Slurm 集群，任务表显示当前调度器队列中的作业，而 Slurm 记账通过诸如 sacct之类的工具提供历史作业数据。明确你从何处获取历史任务数据、审计证据和事故详情。
文档所述的指标视图需要 Amazon CloudWatch Observability EKS 附加组件。该附加组件有其自身的前提条件：2.4.0 或更高版本，以及附加到 Kubernetes 工作节点角色的 CloudWatchAgentServerPolicy IAM 策略。提供任务治理视图的 Kueue 指标在超出免费额度后可能产生 CloudWatch 指标费用。当前的设置和定价注意事项请参阅 SageMaker HyperPod 仪表板文档 。
在整个生命周期内审查连接
为每个连接设置定期审查计划。同时针对项目所有权、访问角色、账户或 Region、集群容量、编排器版本、数据分类或监控覆盖范围的变化定义事件驱动的审查。使用连接契约记录每项决策。
下图展示了生命周期阶段。
图 7：连接生命周期。通过记录在案的连接契约批准连接，对其进行运维和监控，按计划和定义的事件进行审查，然后续期或撤销。
在能减少人工工作的地方自动化清单和证据收集，但保留由负责任的管理员进行审批。撤销不再有业务目的或责任所有者的连接。
结论
借助 Amazon SageMaker Unified Studio，机器学习团队可以遵循以项目为中心的路径来使用经过审批的 SageMaker HyperPod 计算，同时基础设施团队仍保留对集中式集群的控制。从一个非生产集群和一个测试项目开始。在添加成员之前，为 Amazon EKS 配置工作负载身份、命名空间或 Slurm 范围、数据权限、网络策略、任务视图限制和任务治理，或为 Slurm 配置原生调度控制。安装 Amazon CloudWatch Observability EKS 插件，以便填充指标视图，并在连接契约中记录完整的审批。对经过审批的使用者账户使用跨账户角色，在需要硬隔离时使用专用基础设施。按照 SageMaker HyperPod 连接流程 中的实施步骤操作。