Один HyperPod на несколько команд: изоляция, квоты и kubectl без чужих namespace

SageMaker HyperPod на Amazon EKS можно отдать нескольким командам без общего «коммунального» кластера: AWS выложила референс, где Team A и Team B делят один HyperPod, но каждая живёт в своём Kubernetes namespace , от входа до хранилища и учёта затрат. В посте перечисляют типичные провалы без мультитенантности: неконтролируемый расход GPU, слабая изоляция, нельзя списать затраты на команду и растёт админка. Схема рассчитана на gen AI , распределённое обучение, интерактивная разработка и инференс на одной железной базе; HyperPod сам следит за здоровьем нод, восстановлением после сбоев и жизненным циклом кластера. Вход и граница кластера Оба пути , CLI и Studio , идут через портал AWS IAM Identity Center с федерацией во внешний IdP; в примере это Microsoft Entra ID по SAML 2.0, группы TeamA, TeamB и Admin подтягиваются в Identity Center через SCIM. С терминала: aws sso login , временные credentials permission set команды, дальше задачи в EKS через kubectl . Из портала , вход в SageMaker Studio в отдельный SageMaker AI domain команды со своей execution role. На границе EKS access entries связывают IAM-роли Studio и CLI/console-роли из Identity Center с RBAC и режут доступ по namespace , из GUI или терминала нельзя трогать чужие ресурсы. Что внутри namespace HyperPod Task Governance , квоты и приоритеты планировщика HyperPod Observability , мониторинг и дашборды HyperPod Spaces, PyTorch jobs и Inference endpoints , среды, обучение и serving в своём namespace Файловое хранилище , POSIX на Amazon FSx for Lustre или FSx for OpenZFS: общие каталоги /fsx/TeamA и /fsx/TeamB , домашние /home/User1 и /home/User2 . Объектное , S3 с префиксами под политики execution role команды. Затраты привязаны к namespace, чтобы chargeback шёл по командам, а не одной строкой на весь кластер. Источник: Share GPU clusters across teams with isolation and fairness using Amazon SageMaker HyperPod .