AWS выложила схему для компаний, где несколько команд хотят пилить один дорогой GPU-кластер в SageMaker HyperPod — и при этом не драться за видеокарты, доступы и счёт в конце месяца.
Суть бытовая: один общий «машинный зал», но у каждой команды своя дверь, свои права и свой счётчик. В примере у AWS две команды сидят в одном HyperPod EKS-кластере, но работают в разных Kubernetes namespaces. Вход — через IAM Identity Center, можно с корпоративным провайдером вроде Microsoft Entra ID. Дальше доступ режется ролями: кто пришёл из SageMaker Studio, кто через CLI и kubectl, всё равно должен попасть только в свой namespace.
Главный подвох AWS сама не прячет: namespace — это не бетонная стена. Это скорее разметка на полу и охранник у двери. От случайного бардака помогает, от злого соседа по кластеру — не всегда. Для реально чужих арендаторов или жёсткого комплаенса нужны отдельные кластеры, аккаунты, выделенные node pools или песочницы посерьёзнее.
Зато для одной компании, где команды свои, схема практичная. HyperPod Task Governance задаёт квоты GPU и CPU, приоритеты и честную очередь. Например, inference можно поставить выше экспериментального обучения, чтобы продовая подача модели не ждала, пока соседняя команда доиграет тренировку. Доступ к данным разводится через FSx for Lustre, FSx for OpenZFS, EFS или S3, а расходы предлагается считать по namespace через Kubecost.
Это не запуск новой кнопки и не скидка на GPU. Скорее AWS аккуратно продаёт идею: не покупайте отдельный кластер каждому отделу, соберите общий, но заранее разметьте права, квоты, сеть, хранилища и биллинг. Иначе дорогая инфраструктура быстро превращается в очередь у единственной розетки.
Подтверждён пока один первоисточник — технический разбор AWS. Цен, региональных ограничений и готового шаблона «нажал и всё само» там нет. Это чертёж для платформенной команды, а не коробочное лекарство от GPU-дефицита.