AWS 发布 SageMaker HyperPod 多租户参考架构：用 IAM Identity Center、命名空间与 Task Governance 让多团队共享 GPU 集群
来源AWS Machine Learning查看原文
速览
- AWS 给出在 HyperPod EKS 上做多团队共享 GPU 的完整参考架构，覆盖认证、授权、隔离、配额与成本五层
- 认证统一走 IAM Identity Center，与 Entra ID 等外部 IdP 通过 SCIM + SAML 2.0 联邦，团队归属在原有企业目录中管理
- 每个团队一个 SageMaker AI domain 加一个独立执行角色，是 AWS 已文档化的多团队组织模式
- EKS access entries 把 Studio 角色与 CLI 的 SSO 角色分别映射到 RBAC，并限定在各自命名空间内
- Task Governance 提供算力配额与优先级，可让生产推理抢占实验性训练任务
- 命名空间与 NetworkPolicy 只防误操作，不防恶意租户；强隔离需独立集群、账号或节点池
- POSIX 权限依赖 webhook 在运行时注入 UID/GID，是文件系统隔离能否落地的关键环节
- Kubecost 按命名空间出账，使共享 GPU 的成本可归属到具体团队
- 该方案需要自行组装多个组件，换来的是隔离、合规与运维上的可定制性
AWS 机器学习博客发布了一套在 Amazon SageMaker HyperPod（EKS 编排）上构建多租户环境的参考架构，目标是让同一公司内的多个团队共享昂贵的 GPU 集群，同时保持隔离边界、资源公平与运维独立性。架构由五层组成：用 AWS IAM Identity Center 做集中身份认证并与外部 IdP（示例为 Microsoft Entra ID）通过 SAML 2.0 与 SCIM 联邦；为每个团队配置独立的 SageMaker AI domain 与执行角色；在 EKS 侧用 access entries 把 IAM 角色映射到 Kubernetes RBAC 并限定到各自命名空间；用 HyperPod Task Governance（基于 Kueue）做算力配额与调度优先级；用命名空间级成本分摊（Kubecost）实现按团队的费用可见性与 chargeback。文章同时明确划出边界：命名空间是隔离边界而非硬安全边界，该架构面向同一组织内互相信任的多团队，不适用于互不信任的多客户场景，后者应使用独立集群或账号、专用节点池与运行时沙箱。
关键事实
- 架构面向同一公司内多个团队共享单个 HyperPod EKS 集群，示例中 Team A 与 Team B 各占一个命名空间（hyperpod-ns-team-a、hyperpod-ns-team-b）
- 认证层使用 AWS IAM Identity Center，示例外部 IdP 为 Microsoft Entra ID，通过 SCIM 自动同步用户与组、通过 SAML 2.0 完成联邦认证
- 每个团队配置独立的 SageMaker AI domain（TeamA-domain、TeamB-domain）与独立执行角色（TeamA-role、TeamB-role）
- EKS 侧每个团队需要两条 access entry：一条对应 Studio 的 domain 执行角色，一条对应 Identity Center 为权限集自动创建的 SSO 角色（命名模式 AWSReservedSSO__）
- HyperPod Task Governance 基于 Kueue，通过 kueue.x-k8s.io/queue-name 与 kueue.x-k8s.io/priority-class 标签把作业路由到团队本地队列并赋予调度优先级
- 存储层建议使用 Amazon FSx for Lustre、Amazon FSx for OpenZFS 或 Amazon EFS，按团队划分共享目录（如 /fsx/TeamA）与按用户划分家目录（如 /home/User1）
本站视角
对正在自建或采购 AI 算力平台的中文团队来说，这篇文章的价值不在于 AWS 又发了什么功能，而在于它把「多团队共享 GPU」这个长期靠经验拼凑的问题，拆成了一套可复用的分层结构。具体影响几类人：一是企业内部的 AI 平台团队，他们通常被要求既提高 GPU 利用率又不能让团队之间互相踩踏，这套架构给出了从身份到成本的完整链路，可以直接对照检查自己缺了哪一层；二是使用 SageMaker HyperPod 的团队，文章明确了几个容易踩坑的细节，比如 EKS 需要为 Studio 角色和 CLI 的 SSO 角色分别建 access entry，POSIX 身份必须靠 webhook 在运行时注入，否则文件系统权限形同虚设；三是做多云或自建 K8s 方案的团队，Task Governance 基于 Kueue、成本分摊基于 Kubecost，这两个都是开源组件，意味着这套思路并不绑定 AWS。 我们的判断是：这是一篇工程价值高于新闻价值的参考架构，不是产品发布，也没有性能数字或客户案例支撑。它的实质贡献是把已有组件组合成一套经过梳理的蓝图，并罕见地主动声明了安全边界——明确说命名空间不是硬安全边界、不适用于互不信任的多租户，这种克制在厂商博客里并不常见，反而提升了可信度。需要观察的是：文章没有给出任何量化收益（比如利用率提升多少、成本下降多少），也没有说明这套配置在多大集群规模下经过验证，因此落地时的实际复杂度可能高于阅读时的感受。另外，整套方案依赖 IAM Identity Center、SageMaker domain、EKS access entries、Task Governance、Kubecost 五个组件的正确配置，任何一个环节出错都可能导致隔离失效，对运维能力要求不低。对国内团队而言，最值得借鉴的是分层思路和「命名空间不是安全边界」这一判断，而不是照搬具体组件。
背景与影响
GPU 集群是当前生成式 AI 团队最昂贵也最稀缺的资源。企业内部往往同时存在训练大语言模型的数据科学团队、跑推理的计算机视觉团队和试验新架构的研究团队，它们都需要算力，但各自的工作负载特征、优先级和合规要求并不相同。如果每个团队各建一套集群，利用率低、成本高；如果完全混用一套集群，又会出现资源抢占、互相干扰、成本无法归属、管理开销拖慢迭代等问题。AWS 这篇参考架构正是针对这一矛盾给出的工程答案：把身份、授权、隔离、配额、成本五件事分别交给成熟组件处理，再用命名空间作为统一的组织单元把它们串起来。值得注意的是，文章主动划出了安全边界——命名空间不是硬隔离，这套方案面向的是同一组织内互相信任的团队。这意味着它更适合中大型企业内部平台团队落地，而不是面向外部客户的多租户 SaaS。对国内做 AI 平台的团队来说，这套分层思路（身份联邦 → 域/项目隔离 → RBAC → 配额调度 → 成本分摊）本身具有参考价值，即使不使用 AWS 的具体组件，也可以对应到自建的 K8s + 内部 SSO + 配额系统上。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。