AWS介绍通过SageMaker Unified Studio管理HyperPod的四层治理实践
AWS机器学习团队发布博客，说明如何让ML团队在SageMaker Unified Studio项目中接入已批准的SageMaker HyperPod集群，同时保留集群原有的IAM、EKS或Slurm管控。
AI解读：博客提出组织、项目、集群、工作负载四层控制边界，各层回答不同问题、使用不同控制手段。
文章强调SageMaker HyperPod连接不会替代集群的IAM、EKS或Slurm控制；SageMaker Unified Studio项目是协作边界，不是强运行时安全边界。
在身份与可见性方面，文章引用文档称SageMaker AI Studio用户默认可以看到全部Amazon EKS集群任务，Slurm集群用户默认可查看、管理并交互所有可用任务，建议在接入多团队前配置任务可见性限制。
在容量调度方面，文章建议把EKS RBAC或Slurm ACL所决定的“能否提交”与任务治理或Slurm调度所决定的“何时获得算力”分开处理；Slurm不提供与EKS相同的借用与出借模型。
AWS机器学习博客发布一篇关于Amazon SageMaker HyperPod管理与治理的实践文章，作者为Geethanjali Banoth。文章说明如何通过Amazon SageMaker Unified Studio管理SageMaker HyperPod，同时保留集群原有的治理控制。
文章将管理划分为组织、项目、集群、工作负载四层控制边界，每层回答不同问题并使用不同控制手段。作者称，这套模型可以让基础设施团队继续通过既有云运维流程管理集群，同时把已批准的算力以项目上下文的形式提供给机器学习团队。
SageMaker Unified Studio与HyperPod的连接关系
文章介绍，通过SageMaker Unified Studio可以把一个项目连接到已有的SageMaker HyperPod集群，项目成员随后可以启动机器学习工作负载、查看集群与任务信息，并打开JupyterLab工作流。集群本身仍通过Amazon SageMaker AI的界面和API管理。
作者指出，SageMaker HyperPod连接只是把已批准的集群加入项目，不会替代集群的AWS Identity and Access Management、Amazon Elastic Kubernetes Service或Slurm控制。建议把项目角色、连接访问角色、EKS访问条目与RBAC或Slurm控制、工作负载身份、数据与AWS KMS密钥策略、网络策略、任务查看限制和调度策略放在一起审查，对齐后再向项目开放集群。
- 连接方式：在SageMaker Unified Studio项目与已有SageMaker HyperPod集群之间建立连接
- 项目成员可执行的操作：启动ML工作负载、查看集群与任务信息、打开JupyterLab
- 集群管理入口：仍为Amazon SageMaker AI界面与API
四层控制边界与容量归属
文章列出四层控制边界及其用途：组织层使用SageMaker Unified Studio域、域单元、关联账户、项目配置文件和授权策略，决定谁能创建项目、可用哪些账户与区域和工具；项目层使用项目成员、项目角色和SageMaker HyperPod连接，定义协作上下文与可访问的AWS资源；集群层使用HyperPod集群管理员角色、EKS访问条目、RBAC、EKS Pod Identity或Slurm控制，管理集群配置、调度器访问、命名空间、任务和基础设施操作；工作负载层使用算力分配、优先级类、借出与借用策略和任务权限，控制谁能提交工作以及共享容量如何分配。
文章建议把SageMaker HyperPod集群、调度器和稀缺加速器容量集中放在一个指定的容量账户下，已批准的用户和数据集可以留在同一账户，也可以放在独立的消费者账户和数据账户。对于Amazon EKS，建议每个租户一个命名空间，配合RBAC、每租户服务账户与EKS Pod Identity角色、默认拒绝的网络策略，以及租户专属存储和AWS KMS权限；对于Slurm，建议使用带层级账户与关联的Slurm accounting、QoS、优先级与公平共享策略以及分区。
- 组织层控制：域、域单元、关联账户、项目配置文件、授权策略
- 项目层控制：项目成员、项目角色、HyperPod连接
- 集群层控制：集群管理员角色、EKS访问条目、RBAC、EKS Pod Identity或Slurm
- 工作负载层控制：算力分配、优先级类、借出借用策略、任务权限
- 硬隔离需求：文章建议使用独立集群或账户
身份、可见性与调度策略的划分
在身份与任务可见性方面，文章引用文档称，SageMaker AI Studio用户默认可以看到全部Amazon EKS集群任务；对于Slurm集群，每个SageMaker AI Studio用户都可以查看、管理和交互可用任务。文章建议在接入多个团队之前配置任务查看限制，并给出针对EKS与Slurm集群的两份限制说明链接。
文章建议使用组而非按个人授予项目成员资格和集群访问，每个角色只在其边界内定义，而不是用一个宽泛角色横跨域、项目、集群和工作负载策略。文章还建议把只读可见性与创建、更新或删除工作负载的权限分开。
在调度方面，文章区分两个决定：EKS RBAC或Slurm ACL决定用户能否提交工作负载，SageMaker HyperPod任务治理（用于EKS）或原生Slurm调度控制决定已授权的工作负载何时获得算力。文章称，把调度器配额当作访问控制、或把授权控制当作调度策略，会造成行为不清晰，并增加事故诊断难度。
文章举例说明分配策略：在Amazon EKS集群上，可以给生产训练团队 60% 的保证配额和高优先级类，允许研究团队以较低优先级借用空闲容量，并在生产团队提交工作时抢占这些借用的容量。文章建议为策略的每个例外指定一名审批负责人。文章还提到，任务治理同样适用于直接在集群上运行的自包含JupyterLab或Code Editor环境的SageMaker HyperPod spaces，因此这类交互式开发工作负载也应纳入分配策略。
- 默认可见性：EKS集群任务默认对SageMaker AI Studio用户全部可见；Slurm集群用户默认可查看、管理并交互所有可用任务
- 建议做法：接入多团队前配置任务查看限制；用组授权；按边界拆分角色；把“可见”与“可操作”分开
- 调度与授权分离：RBAC或ACL管能否提交，任务治理或Slurm调度管何时获得算力
- 文章举例：生产训练团队 60% 保证配额加高优先级，研究团队低优先级借用空闲容量，生产团队提交时抢占
- Slurm差异：Slurm不提供与EKS相同的借出与借用模型