AWS показала схему, как делить один кластер HyperPod EKS между командами

AWS опубликовала референсную архитектуру, по которой один кластер Amazon SageMaker HyperPod с оркестрацией через EKS можно безопасно отдать сразу нескольким командам. Схема состоит из пяти слоёв: единый вход через AWS IAM Identity Center, отдельные SageMaker Domains и пространства имён Kubernetes для изоляции, HyperPod Task Governance для справедливого распределения ускорителей и учёт затрат на уровне namespace для внутренних счетов. Это ответ на типовую проблему: GPU дорогие и дефицитные, а выделять каждой команде собственный кластер расточительно.

Зачем делить один кластер

Когда у каждой ML-команды свой кластер, возникает перекос. У одних ускорители простаивают по ночам и в паузах между экспериментами, у других очередь на обучение растягивается на дни. Платформенные инженеры при этом администрируют несколько окружений вместо одного. Общий кластер решает обе проблемы, но создаёт три новых вопроса. Как не допустить доступа одной команды к данным и задачам другой? Как не дать одной команде занять всё? Кто платит за что?

Архитектура AWS отвечает на каждый вопрос отдельным компонентом.

Как устроена изоляция

Точка входа — AWS IAM Identity Center. Пользователи и группы приходят из корпоративного каталога, и каждая группа соответствует команде. Отдельные учётные записи в AWS заводить не нужно, права отзываются в одном месте.

Дальше работает двойная граница. Каждая команда получает собственный SageMaker Domain, то есть свою рабочую среду с профилями пользователей и ролями исполнения. Параллельно для неё создаётся пространство имён Kubernetes в общем кластере EKS, где живут её задачи. Domain отвечает за то, что видит и запускает человек. Namespace отвечает за то, где и с какими ограничениями эти задачи выполняются на общем железе.

Справедливость и деньги

Изоляции недостаточно: без правил распределения вычислений общий кластер превращается в борьбу за ресурсы. Здесь подключается HyperPod Task Governance. Он позволяет задавать каждой команде квоту вычислительных ресурсов и приоритеты задач. Простаивающую ёмкость соседей можно временно занимать, а при возвращении владельца менее приоритетные задачи уступают место. Так загрузка кластера растёт, а гарантированная доля каждой команды сохраняется.

Последний слой — финансовый. Затраты привязываются к namespace, а значит, к конкретной команде. Это основа chargeback: бухгалтерия и руководители подразделений видят, кто сколько потребил, и могут выставлять внутренние счета без ручных таблиц.

Ключевые элементы схемы:

• Кластер: один Amazon SageMaker HyperPod с оркестрацией через EKS.
• Аутентификация: AWS IAM Identity Center, группы соответствуют командам.
• Изоляция: отдельные SageMaker Domain и namespace Kubernetes на каждую команду.
• Справедливость: HyperPod Task Governance с квотами и приоритетами.
• Финансы: распределение затрат на уровне namespace.

С чего начать внедрение

В источнике описана только архитектура, поэтому ниже мои практические выводы, а не данные AWS.

Начните с карты команд и их реального потребления. Квоты лучше выводить из истории загрузки, а не из пожеланий руководителей, иначе перераспределение придётся делать сразу после запуска. Затем договоритесь о классах приоритетов: что считается продуктивным обучением, что экспериментами, что интерактивной работой. Вытеснение задач безболезненно только при регулярных чекпоинтах, так что требование сохранять состояние стоит ввести заранее.

Отдельно оцените уровень изоляции. Namespace и Domain разделяют команды логически, но физически они остаются на общем кластере. Для данных с жёсткими требованиями регуляторов может понадобиться дополнительный контроль или отдельный кластер. Наконец, согласуйте с финансовым отделом модель chargeback до запуска: что именно считается стоимостью команды, как делятся общие расходы на простой и администрирование. Технически учёт по namespace настроить проще, чем договориться об этом внутри компании.