Что такое списки предпочтений инстансов в SageMaker AI
Списки предпочтений инстансов (instance preference lists) в Amazon SageMaker AI позволяют передать в конфигурацию тренировочной или processing-задачи упорядоченный список до пяти типов инстансов. Платформа проходит по этому списку сверху вниз и запускает задачу на первом типе, для которого есть свободная ёмкость. Никакого внешнего кода, опроса API и повторных запусков: выбор делает сам сервис.
Механика работает для двух классов задач: обучения моделей и обработки данных. Раньше цепочку «сначала попробуй p4d, если не вышло, возьми g5» приходилось описывать самому в виде цикла с паузами, ловить ошибку нехватки ёмкости и запускать джобу заново. Теперь та же логика задаётся одним параметром в описании задачи.
Коротко о главном: до пяти типов инстансов в одном списке, автоматический перебор по доступности, приоритет зарезервированной ёмкости Flexible Training Plans и параметр MaxPendingTimeInSeconds, который ограничивает время ожидания в очереди для задач с ускоренными вычислениями.
Какую проблему решают списки предпочтений
Боль знакома каждому, кто гонял обучение на дефицитных ускорителях. Нужен ml.p3.2xlarge, в выбранном регионе его нет, задача падает через несколько минут после старта. Дальше вариантов немного: сидеть и вручную перезапускать джобу, пока ёмкость не освободится, или написать скрипт-обёртку.
Скрипт умеет три вещи: перехватить ошибку, подождать и повторить запуск на другом типе. Проблемы начинаются на масштабе. Если у вас десяток экспериментов и несколько человек в команде, обёртка обрастает флагами, логами и исключениями, а её состояние живёт вне SageMaker. Плюс типовой набор граблей: скрипт перезапускает задачу целиком, теряет промежуточные артефакты, если они не сохранены, и не знает ничего о зарезервированной ёмкости.
Списки предпочтений переносят эту логику внутрь сервиса. Вы описываете приоритет: сначала ml.p3.2xlarge, затем ml.p3.8xlarge, затем ml.g4dn.xlarge. SageMaker проверяет доступность в заданном порядке и стартует там, где есть место. Отдельный процесс-наблюдатель не нужен.
Ключевые возможности и ограничения
- До пяти типов инстансов в одном списке, порядок задаёт приоритет.
- Автоматический выбор первого типа с доступной ёмкостью.
- Поддержка тренировочных и processing-задач.
- Совместимость с Flexible Training Plans: зарезервированная ёмкость проверяется раньше on-demand.
- MaxPendingTimeInSeconds ограничивает суммарное время ожидания в очереди для задач с ускоренными вычислениями.
Ограничения тоже есть, и о них честнее сказать сразу. Не любые типы инстансов разумно ставить в одну цепочку: у них разное число ускорителей, объём видеопамяти и архитектура. Поведение системы в случае, когда все пять вариантов заняты, в открытых описаниях не детализировано, поэтому рассчитывать на конкретный сценарий «задача сама себя приостановит» без проверки документации не стоит. Наконец, MaxPendingTimeInSeconds описан для задач с ускоренными вычислениями, а не для произвольных CPU-джоб.
Как настроить instance_preferences в SageMaker Python SDK v3
Настройка выполняется в момент создания объекта задачи. Список передаётся параметром instance_preferences, а сам параметр instance_type остаётся как базовый тип. Общая логика для SDK v3 такая же, как для остальных конфигурационных полей: вы описываете задачу декларативно, а не управляете перезапусками вручную. Если вы уже работали с автоматическим подбором конфигурации в этом SDK, механика покажется знакомой: разбор оптимизации инференса генеративных моделей в Amazon SageMaker показывает похожий подход на стороне развёртывания.
Пример кода для тренировочной задачи
Ниже иллюстративная форма вызова: три типа инстансов по убыванию приоритета и лимит ожидания в очереди. Точные имена аргументов и их регистр сверяйте с документацией той версии SDK v3, которая установлена у вас, потому что написание может отличаться между релизами.
from sagemaker.estimator import Estimator
estimator = Estimator(
image_uri=training_image,
role=role,
instance_count=1,
instance_type="ml.p3.2xlarge", # базовый тип
instance_preferences=[ # порядок обхода, до 5 типов
"ml.p3.2xlarge",
"ml.p3.8xlarge",
"ml.g4dn.xlarge",
],
max_pending_time_in_seconds=1800, # 30 минут ожидания в очереди
output_path="s3://bucket/output",
)
estimator.fit({"train": "s3://bucket/train"})
Читается это так: сначала платформа пытается получить ml.p3.2xlarge, при нехватке ёмкости идёт к ml.p3.8xlarge, затем к ml.g4dn.xlarge. Порядок в списке полностью определяет поведение, поэтому первый элемент обычно совпадает с instance_type и соответствует самому выгодному или самому производительному варианту.
Настройка для processing-задач
Для обработки данных механизм тот же, меняется только класс объекта. Практический смысл здесь часто выше, чем в обучении: processing-джобы короткие, их много, и ждать освобождения конкретного инстанса по десять минут каждую просто невыгодно.
from sagemaker.processing import Processor, ProcessingInput
processor = Processor(
image_uri=processing_image,
role=role,
instance_count=1,
instance_type="ml.m5.2xlarge",
instance_preferences=[
"ml.m5.2xlarge",
"ml.m5.4xlarge",
"ml.c5.4xlarge",
],
)
processor.run(
inputs=[
ProcessingInput(
source="s3://bucket/raw",
destination="/opt/ml/processing/input",
)
],
outputs=[],
)
Обратите внимание на состав списка: все три типа имеют сопоставимый объём памяти на CPU, поэтому подготовка данных не упрётся в нехватку RAM при переходе на альтернативу. Если задача требовательна к памяти, а fallback-инстанс слабее, вы получите уже не ожидание, а падение по Out Of Memory.
Как SageMaker выбирает инстанс: логика перебора и MaxPendingTimeInSeconds
Алгоритм простой и предсказуемый: список обходится в заданном порядке, для каждого типа проверяется доступность ёмкости, задача стартует на первом подходящем. Пока подходящего нет, джоба остаётся в очереди со статусом ожидания. Никаких параллельных попыток запуска на нескольких типах одновременно не происходит, так что переплаты за лишние ресурсы не возникает.
Именно для управления этим ожиданием нужен MaxPendingTimeInSeconds. Параметр задаёт суммарное время, которое задача может провести в очереди, перебирая варианты. Речь идёт о задачах с ускоренными вычислениями: обучение на GPU, Trainium и Inferentia, где ожидание свободного ускорителя может длиться часами.
Что происходит, если все инстансы недоступны
Открытые описания функции не содержат детального сценария на случай, когда все пять вариантов заняты и лимит времени исчерпан. Разумная практика: считать, что задача завершится с ошибкой ожидания, и строить пайплайн так, чтобы он это переживал. Оркестратор над SageMaker должен уметь увидеть неуспешный статус шага и принять решение, а не полагаться на то, что платформа сама подберёт шестой тип из ниоткуда.
Практический вывод из этой неопределённости: держите в списке хотя бы один тип, который доступен в регионе почти всегда, даже если он слабее основного. Лишний fallback-вариант стоит дешевле, чем разбор причин упавшей ночной тренировки.
Ограничение времени ожидания для ускоренных вычислений
Значение MaxPendingTimeInSeconds задаёт верхнюю границу ожидания. Пример: MaxPendingTimeInSeconds=1800 значит, что если за 30 минут свободный инстанс из списка так и не появился, дальше ждать бессмысленно, и задача не будет висеть в очереди до утра, занимая место в расписании и создавая иллюзию работающего пайплайна.
Как выбирать значение. Для интерактивных сценариев, где результат нужен «сейчас», хватает нескольких минут. Для фонового дообучения, которое может постоять, разумные границы шире. Слишком маленькое значение превращает fallback-цепочку в формальность: платформа не успевает дойти до третьего типа и роняет задачу. Слишком большое возвращает исходную проблему, только теперь вы ждёте не вручную, а молча.
Интеграция с Flexible Training Plans: приоритет зарезервированной ёмкости
Flexible Training Plans дают зарезервированную ёмкость под обучение. Списки предпочтений стыкуются с этим механизмом так, чтобы сначала использовался оплаченный резерв, а не ресурсы по требованию. Для команд с долгосрочными планами обучения это прямая экономия: простой резерва и одновременная оплата on-demand инстансов, пожалуй, самый неприятный вид расходов в облачном бюджете.
Порядок проверки: резерв, затем on-demand
Логика такая. Система смотрит, есть ли свободная зарезервированная ёмкость под первый тип инстанса в списке. Если резерв доступен, задача идёт на нём. Если занят, проверяется следующий тип, снова с приоритетом резерва. Когда ни один вариант из списка не имеет свободного резерва, начинается переход к on-demand инстансам в том же порядке предпочтения.
Пример: у вас есть резерв на ml.p3.8xlarge, но он занят другой задачей. Список выглядит как ml.p3.2xlarge, затем ml.p3.8xlarge. Резерва под p3.2xlarge нет, поэтому при недоступности p3.8xlarge платформа перейдёт к on-demand вариантам из списка, а не будет ждать освобождения резерва бесконечно.
Граница между «подождать резерв» и «уйти в on-demand» задаётся тем же лимитом ожидания. Если для вас критично не выходить за пределы зарезервированной ёмкости, ставьте небольшой MaxPendingTimeInSeconds: лучше упасть и перезапустить позже, чем тихо набрать счёт за on-demand. Если важнее завершить обучение в срок, увеличивайте лимит осознанно и отслеживайте, сколько задач реально уходит на on-demand.
Ограничения и совместимость типов инстансов
Главное ограничение списка состоит не в количестве элементов, а в их сочетаемости. Пять типов в одной цепочке имеют смысл только тогда, когда задача запустится на любом из них без изменения кода и гиперпараметров.
Какие типы инстансов можно комбинировать
Смешивать семейства технически можно, но только с поправкой на требования задачи. Ориентир по семействам выглядит так:
| Семейство | Ускоритель | Что учесть при смешивании |
|---|---|---|
| ml.p3 | NVIDIA V100 | Число карт отличается внутри семейства: у p3.2xlarge одна, у p3.8xlarge четыре |
| ml.p4d, ml.p5 | NVIDIA A100, H100 | Большие объёмы видеопамяти, обычно под крупные модели и распределённое обучение |
| ml.g4dn, ml.g5 | NVIDIA T4, A10G | Меньше видеопамяти, годятся как fallback для задач с небольшим бюджетом VRAM |
| ml.trn1 | AWS Trainium | Своя архитектура, нужна совместимая сборка фреймворка и адаптированный код |
| ml.inf2 | AWS Inferentia | Ориентированы на инференс, для обучения как альтернатива не подходят |
Про ускорители AWS стоит помнить отдельно: партнёрство Hugging Face и AWS сделало обучение и инференс open-source моделей на Trainium и Inferentia вполне рабочим сценарием, но переход между NVIDIA и собственными чипами AWS это не прозрачная замена одного типа инстанса на другой. Такой вариант в списке требует, чтобы задача и контейнер были готовы к обеим платформам.
На что обратить внимание при составлении списка
- Требования к видеопамяти: fallback-инстанс не должен иметь меньше VRAM, чем нужно модели, иначе вы обменяете ожидание на Out Of Memory.
- Число ускорителей и стратегия распределения: при переходе с одной карты на четыре меняется смысл параметров распределённого обучения.
- Региональная доступность: тип, которого нет в вашем регионе, бесполезен в списке.
- Совместимость образа и фреймворка: сборка, собранная под конкретную архитектуру, может не запуститься на другом ускорителе.
- Цена за час: смешивание дешёвого и дорогого типов без учёта приоритета приводит к запускам на дорогом инстансе, когда это не нужно.
Точный перечень совместимых комбинаций в публичных материалах не приводится, поэтому проверять его стоит по документации сервиса для вашего региона и типа задачи, а не по интуиции.
Практические сценарии: где это упрощает жизнь
Очередь из множества коротких processing-задач. Подготовка датасетов идёт десятками запусков в сутки. Раньше один занятый тип инстанса тормозил весь конвейер. Со списком из трёх сопоставимых по памяти типов задачи проходят почти без простоев, а код пайплайна не содержит блоков обработки ошибок ёмкости.
Обучение при пиковой нагрузке в кластере. Если популярный тип инстанса периодически выбит, можно поставить первым желаемый вариант, а следом более мощный и более дешёвый. Ночной запуск переживёт отсутствие основного типа без участия дежурного инженера.
Работа с Flexible Training Plans. Резерв используется в первую очередь, а при его занятости задача уходит на on-demand по заданному порядку. Переключение происходит автоматически, и вам не нужно вручную решать, что делать с простоем резерва.
Чем это отличается от самописного перебора: состояние очереди живёт в SageMaker, а не в вашей обёртке, логи попыток не нужно собирать по крошкам из отдельных запусков, и нет риска, что скрипт-наблюдатель умрёт вместе с ноутбуком, с которого его запустили. Самописный вариант остаётся оправданным там, где нужна логика, которой у сервиса нет: например, переключение между разными регионами или разными аккаунтами.
Итоги: кому стоит использовать списки предпочтений
Списки предпочтений инстансов окупаются в трёх ситуациях: вы регулярно упираетесь в недоступность нужного типа инстанса, у вас много коротких processing-задач или вы используете зарезервированную ёмкость Flexible Training Plans и хотите, чтобы она выбиралась первой. В этих случаях настройка сводится к одному параметру в конфигурации задачи, а выигрыш измеряется в упавших и перезапущенных вручную джобах.
Если вы запускаете одну небольшую задачу в неделю на инстансе, который всегда доступен, выигрыш нулевой, и усложнять конфигурацию смысла нет. Ограничения тоже стоит держать в голове: до пяти типов, требования к совместимости ускорителей и памяти, отсутствие публичных деталей о поведении при исчерпании списка.
Практический шаг: соберите список из двух-трёх типов для самой частой задачи, поставьте лимит ожидания в очереди осознанно и посмотрите, на каком типе она стартует в реальности. Если задач много и они дорогие, этот же подход стоит сочетать с общей оценкой платформы под нагрузку, например по критериям из разбора Forrester Wave по AI-инфраструктуре. Перед переносом конфигурации в продакшен сверьтесь с официальной документацией AWS: синтаксис параметров в SDK v3 может отличаться между версиями.