Оптимизация затрат на ML-обучение: Spot и Preemptible VMs

Spot инстансы: почему обучение упирается в простой ускорителей

Выделенные ускорители обычно заказывают впрок и на длинный интервал, поэтому очередь на ускорители измеряется днями, а не минутами ожидания. Пока ресурс закреплён за одним экспериментом, следующий ждёт, хотя сам узел половину окна не считает: подготовка данных, ожидание предыдущего этапа и разбор результатов съедают время, за которое уже заплачено. Простой вычислительных узлов в такой схеме — норма, а не сбой.

Прерываемые инстансы (Spot) снимают ограничение по цене, но добавляют своё: платформа забирает узел по внешнему сигналу, и окно на корректное завершение короткое. Если задача не пишет контрольные точки, обучение откатывается к последнему удачному состоянию или начинается заново. В худшем случае незавершённые задачи обучения просто теряются, и их перезапускают руками, сверяя логи и восстанавливая окружение.

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

Разбираем, как это закрывается: управление очередью и приоритетами между задачами, частое сохранение состояния, автоматический перезапуск прерванных задач на свободных узлах и разделение ресурсов между экспериментами так, чтобы простой не оплачивался.

Что меняется после перехода на прерываемые мощности

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

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

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

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

Spot инстансы, выделенные узлы и гибридный пул

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

Кластер Kubernetes размечает пулы: узлы с метками отзыва принимают только задачи, умеющие сохранять контрольные точки, выделенные несут стабильное ядро обучения, а очередь сама переносит вытесненную работу. Приложение получает сигнал об отзыве заранее и успевает сбросить состояние в объектное хранилище, поэтому доработка кода модели не требуется — только манифесты запуска и политики вытеснения.

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

Как мы разворачиваем обучение на прерываемых узлах

Прерываемый узел может уйти в любой момент — в Spot-пуле это штатное событие, а не авария. Инженерная задача в том, чтобы потеря узла не превращалась в потерянный прогресс обучения и повторные прогоны. Идём последовательно: сначала измеряем профиль нагрузки, потом проектируем размещение, затем проверяем, как система переживает реальные прерывания.

1. Аудит профиля нагрузки. Смотрим длительность шага, потребление памяти, долю времени на обмен данными и терпимость обучения к остановке. На выходе — карта участков, которые можно отдать прерываемой ёмкости без риска для сходимости.

2. Схема размещения задач. Разделяем роли: координация, хранилище контрольных точек и критичные сервисы остаются на стабильных узлах, тяжёлый счёт — на прерываемых. Тогда потеря узла не останавливает весь эксперимент.

3. Механизм контрольных точек. Периодичность сохранения подбираем под длительность шага, состояния пишем атомарно и вне самого узла, версионируем. После прерывания обучение продолжается с ближайшей валидной точки, а не с начала.

4. Регламент реакции на прерывание. Определяем, сколько ждём возврата ёмкости, как переиспользуем освободившиеся узлы и когда переключаемся на стабильный пул, чтобы очередь экспериментов не вставала.

5. Проверка восстановления. Намеренно гасим узлы в ходе прогона и замеряем потерю прогресса, время возврата на прежний темп и долю задач, завершённых без ручного вмешательства.

6. Сопровождение обучения. Передаём регламенты дежурства и настройки политики, дальше корректируем их по факту — по мере изменения профиля моделей и поведения пула.

Конфигурации, политики и регламенты, которые вы получаете

На выходе вы получаете не набор разрозненных скриптов, а описанный контур обучения. Его можно передать другой команде, и она продолжит работу без устных пояснений: артефакты фиксируют, что считается нормой и как действовать, когда прерываемые узлы забирают пачкой.

• Схема пулов — сколько пулов, какие типы узлов в каждом, доли прерываемых и постоянных машин, распределение по зонам. Видно, какие этапы переживут одновременный отзыв узлов.
• Политики выбора узлов — правила, по которым задача попадает на Spot-машины, а критичные шаги остаются на постоянных: приоритеты, ограничения по типу ускорителя, время ожидания в очереди.
• Политики доступа — роли инженеров и сервисных учётных записей, разделение прав на изменение конфигураций и на чтение логов, порядок ротации ключей.
• Схема хранения контрольных точек — интервал сохранения, глубина хранения, разделение быстрого локального и долгого объектного слоя, правило очистки по числу и возрасту.
• Регламент восстановления — как обучение поднимается после отзыва узла, с какой контрольной точки, сколько шагов прогресса теряется и кто подтверждает возврат в работу.
• Документация на инфраструктуру — описания пулов, квот, лимитов и точек отказа, порядок внесения изменений; лежит в том же репозитории, что и описания запусков.
• Наблюдаемость — панель по доле прерываний, времени простоя и загрузке пулов, чтобы схему меняли по данным, а не по ощущениям.

Раз в квартал эти документы пересматриваются вместе с изменениями в доступности типов узлов у провайдера — конфигурация не расходится с реальностью.

Кейс: дообучение модели ранжирования на прерываемых узлах

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

Мы перевели прогоны на прерываемые узлы: чекпоинты пишутся в объектное хранилище каждые несколько сотен шагов, планировщик отслеживает отозванные Spot инстансы и поднимает замену из того же пула, обучение продолжается с последней сохранённой точки. Финальную валидацию и упаковку артефакта оставили на небольшом стабильном резерве — там прерывание недопустимо, а объём работы мал. В Google Cloud такой пул собирается из прерываемых и обычных машин в одной группе.

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

Что делать, если часть мощностей уже занята постоянной нагрузкой?

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

Рабочая схема — разделение пулов на три части. Устойчивый пул под постоянную нагрузку закрывает её с запасом на пик, вытесняемый отдан обучению и не влияет на сервисы, а буферный переключается между ними по расписанию.

Если узлы всё равно общие, вводят приоритеты задач и классы вытеснения: сервисные процессы помечены как непрерываемые, обучающие — как уступающие первыми. Метки и допуски планировщика не пускают обучение на узлы с критичными сервисами, поэтому совместное использование не превращается в драку за память и дисковый ввод-вывод.

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

Так постоянная нагрузка остаётся в предсказуемых условиях, а обучение забирает всё, что действительно свободно: утилизация парка растёт без риска для сервисов.

Технические сомнения и ответы по прерываемым узлам

Отзыв узла — не сбой, а штатное событие с предупреждением: среда получает сигнал, успевает завершить текущий шаг и выгрузить состояние. Частота отзыва зависит от класса ресурса и региона — на практике это единицы процентов суток, а не «узел гаснет каждый час». Планировщик перезапускает задачу на новом узле и подхватывает последнюю контрольную точку, поэтому прогон продолжается, а не начинается заново. Именно на этой механике и строится расчёт, выгодны ли Spot-инстансы под конкретную задачу.

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

Что при дообучении большой модели?

Критично, что именно попадает в контрольную точку. Если сохранять только веса без состояния оптимизатора, после перезапуска сходимость проседает. Мы пишем полное состояние и проверяем восстановление на тестовом прогоне до старта.

Обсудим задачу обучения и вернёмся с планом и оценкой

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

• Постановка задачи. Какие обучения хотите ускорить в первую очередь и где сейчас узкое место — очередь, простой ускорителей или избыточный запас машин.
• Вводные по нагрузке. Профиль задач, требования к памяти, длительность одного запуска, готовность к прерыванию и перезапуску с последней контрольной точки.
• Текущий контур. Как устроены запуски, где лежат данные и артефакты моделей, есть ли наблюдаемость и учёт потребления по командам.
• План внедрения. Покажем, как часть парка переводим на Spot-инстансы с автоматическим возвратом в стабильный пул при нехватке ёмкости.
• Состав работ. Разметка заданий по допуску к прерыванию, политика отбора ёмкости, сохранение контрольных точек, автоматическое масштабирование очереди.
• Оценка сроков. Диапазон по этапам — от пробного перевода одного типа задач до полной раскатки с планом отката.

Дальше — короткий разговор по делу: опишите задачу и текущий профиль обучения, и мы вернёмся с планом, составом работ и сроками.