«Один запрос вместо цикла ретраев»: Amazon SageMaker AI сам выбирает GPU из списка до пяти типов

Что объявили

Пост вышел 15 сентября 2026 года в блоге AWS Machine Learning; его подписали Канвалджит Кхурми (Kanwaljit Khurmi), Дип Шах (Deep Shah), Майкл Огуике (Michael Oguike), Мона Мона (Mona Mona) и Сафир Алви (Safir Alvi). Объявление — Instance preference lists для Amazon SageMaker AI Training Jobs и Amazon SageMaker Processing Jobs.

Механика такая: при создании обучающего или обрабатывающего задания вы указываете упорядоченный список до пяти приемлемых типов инстансов, а SageMaker AI оценивает список в порядке приоритета и запускается на первом типе со свободной ёмкостью. Заявленная цель — быстрее получать GPU-ресурсы и убрать ручные циклы ретраев, скрипты слежения за ёмкостью и сборку систем управления отправкой заданий для нагрузок, которые могут работать на нескольких типах.

Проблема описана на сценариях: задание, привязанное к одному типу, ждёт ёмкость, пока на других типах она есть; ночной конвейер обработки, прибитый к одному типу, падает в два часа ночи с ошибкой InsufficientCapacityError, хотя при оценке альтернатив он бы стартовал. Третий случай — организация с Training Plan, которой нужно сначала оценить резерв и только потом уйти на on-demand, не пересобирая запрос.

Как проходит выбор инстанса

Документация формулирует то же короче: обучающее задание может принимать упорядоченный список до 5 типов вместо одного, SageMaker AI запускает его на первом типе с ёмкостью, а дальше задание выполняется, мониторится и тарифицируется так же, как если бы этот тип указали напрямую.

Порядок из поста: вы отправляете задание со списком; SageMaker проверяет конфигурацию и список на соответствие поддерживаемым типам и лимитам ресурсов; планировщик выполняет один проход по упорядоченным типам в памяти и находит первый с доступной ёмкостью; победивший тип немедленно провижинится, и задание начинает выполняться.

Если ёмкости нет ни на одном типе, задание попадает в событийную очередь и автоматически повторяет попытки по мере освобождения ресурсов; окно ожидания ограничено параметром MaxPendingTimeInSeconds, и лимит покрывает суммарное время работы по всему списку, а не по каждому типу отдельно. Включается он только тогда, когда в списке есть хотя бы один тип ускоренных вычислений — ml.p, ml.g или ml.trn; список только из CPU-типов ожидания не получает, он оценивается один раз, и если ёмкости нет, задание падает с ошибкой ёмкости без повторной оценки.

Flexible Training Plans: резерв первым, on-demand следом

Instance preference lists расширяют логику зарезервированной ёмкости: Flexible Training Plans (FTP) резервируют GPU на определённый срок по сниженной цене, и TrainingPlanArn можно добавить к конкретному пункту списка, а остальные оставить на on-demand. Проход сначала оценивает резерв, и если он не может быть выделен, система переходит к следующему типу — как правило, уже из on-demand ёмкости.

Технические условия названы жёстко: тип инстанса в пункте с планом обязан совпадать с типом самого плана, а пункты без плана используют On-Demand; план-пункт рекомендуется ставить первым, чтобы зарезервированную ёмкость пробовали до альтернатив. У Processing Jobs интеграции с планами нет: поле TrainingPlanArns предназначено только для обучающих заданий.

Квоты и совместимость: чего проверка не делает

Число инстансов задаётся одним из двух способов: единый InstanceCount в ResourceConfig для всех типов или собственный InstanceCount в каждом пункте списка — для типов с разным количеством ускорителей. Запрос, где счётчики указаны и там и там, или нигде, или только у части пунктов, отклоняется.

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

Ограничения комбинирования перечислены прямо: InstancePreferences нельзя сочетать с InstanceType, InstanceGroups, InstancePlacementConfig и EnableManagedSpotTraining, а каждый тип может встречаться в списке только один раз. Если используется встроенный алгоритм, все перечисленные типы должны им поддерживаться, иначе запрос отклоняется.

И главное предупреждение: SageMaker AI выбирает только по ёмкости и не сравнивает GPU-архитектуру, объём памяти ускорителя, поддержку Elastic Fabric Adapter (EFA) и версии драйверов, поэтому контейнер должен работать со всеми типами из списка — задание, стартовавшее на несовместимом типе, может упасть. Параметры VolumeSizeInGB, VolumeKmsKeyId и KeepAlivePeriodInSeconds при этом применяются к тому типу, который в итоге выбран.

Примеры из поста

Первый пример — на Amazon SageMaker Python SDK v3 и классе ModelTrainer: ml.p5.48xlarge ставят приоритетом 1 как H100, ml.p4d.24xlarge — приоритетом 2, ml.p4de.24xlarge — приоритетом 3 как A100; счётчик инстансов при этом один и тот же, потому что не зависит от того, какой тип победит.

Второй пример — про эквивалентность вычислений: два ml.g6.48xlarge (8 GPU L40S каждый, 16 суммарно) идут первым пунктом, четыре ml.g5.48xlarge (32 A10G, но с меньшей производительностью на GPU) — вторым, чтобы суммарная пропускная способность была сопоставимой. AWS советует использовать счётчики по пунктам, когда скрипт обучения умеет адаптироваться к разному числу GPU, например через torchrun с --nproc_per_node=auto.

Третий пример — гибрид: первым пунктом резервный ml.p5.48xlarge с TrainingPlanArn, затем on-demand P4d и P4de как подстраховка. Для Processing Jobs тот же механизм задаётся в ClusterConfig, и в примере список выглядит так: ml.g5.12xlarge, ml.g5.4xlarge и CPU-тип ml.m5.12xlarge как третий вариант.

Что значит это для команд

AWS предлагает обновить SDK командой pip install --upgrade sagemaker, добавить instance_preferences в конфигурацию Compute по руководству разработчика и указать 2–5 совместимых типов в порядке приоритета, а затем отправить задание из консоли Amazon SageMaker AI.

Контекст, который объясняет смысл фичи: до неё команды лечили нехватку ёмкости внешними скриптами, которые опрашивают статус задания, отменяют зависшие заявки и пересобирают их с другими типами; такие обходные пути не интегрируются с зарезервированной ёмкостью и накапливают операционные издержки с каждым запуском. Списки убирают эту работу, но перекладывают на автора списка две новые обязанности — следить за совместимостью всех перечисленных типов и держать открытыми квоты по каждому из них.