В Amazon SageMaker AI появилась автоматическая замена недоступных GPU-инстансов

Поиск доступных GPU для обучения нейросетей в моменты пикового спроса часто превращается в ручной перебор конфигураций. Когда конкретный тип инстанса недоступен, работа встает: инженеры либо ждут, либо вручную пробуют альтернативы, что тормозит итерации и отвлекает от разработки моделей. Чтобы убрать этот барьер, в Amazon SageMaker AI появились списки предпочтений инстансов (Instance preference lists) для задач обучения (Training Jobs) и обработки данных (Processing Jobs).

Теперь при создании задания можно указать приоритетный список из пяти подходящих типов инстансов. Система автоматически проверяет их по порядку и запускает задачу на первом доступном варианте. Это избавляет от необходимости писать собственные скрипты для мониторинга очереди и повторного запуска заданий (retry loops).

Как меняется сценарий работы:

• Для ночных пайплайнов: Вместо ошибки InsufficientCapacityError в два часа ночи, задача автоматически переключится на альтернативный GPU из списка и начнет выполнение.
• Для владельцев Flexible Training Plans (FTP): Можно поставить зарезервированные мощности на первое место, а On-demand инстансы — в конец списка. Если резерв исчерпан, система сама перейдет к стандартным тарифам без ручного вмешательства.
• Для управления производительностью: Если разные GPU в списке имеют разную мощность, можно задать разное количество узлов для каждого типа, чтобы сохранить общую вычислительную мощность (throughput) на одном уровне.

Ограничения и важные условия:

• Совместимость: SageMaker не проверяет, подходит ли ваш контейнер к выбранным GPU (архитектура, драйверы, поддержка EFA). Ответственность за совместимость кода со всеми типами в списке лежит на пользователе.
• Очередь: Если ни один инстанс из списка не доступен, задача попадает в очередь. Время ожидания можно ограничить параметром MaxPendingTimeInSeconds (актуально только для ускоренных вычислений серий ml.p, ml.g и ml.trn).
• Обработка данных: Для Processing Jobs механизм fallback работает так же, но интеграция с Training Plans (резервированием) здесь недоступна.

Итог внедрения функции — переход от ручного управления инфраструктурой к декларативному подходу: пользователь определяет допустимый диапазон ресурсов, а платформа сама находит кратчайший путь к их получению.