Spot GPU без потери работы: checkpoint, preemption и resume

Что подготовить

Сначала зафиксируйте модель GPU, объём VRAM, регион, тип тарифа и полный бюджет. Цена GPU-часа не включает автоматически диск, исходящий трафик, публичный IPv4 и поддержку.

1. Узнайте сигнал и окно предупреждения о прерывании у провайдера.
2. Выберите внешний storage с достаточной скоростью записи.

Пошаговый запуск

1. Сохраняйте model, optimizer, scheduler, scaler, step и RNG state.
2. Пишите checkpoint во временный каталог, проверяйте и переименовывайте.
3. Обработайте SIGTERM и оставьте периодический fallback checkpoint.

Проверка результата

1. Принудительно завершите job и подтвердите точный resume.
2. Повреждённый последний checkpoint откатывается на предыдущий.

Ошибки, стоимость и безопасный откат

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

1. Слишком частые checkpoint могут съесть экономию на storage I/O.
2. Data loader position и seed тоже влияют на воспроизводимость.

Граница задачи и критерий успеха

До аренды сформулируйте, что именно должно завершиться в сценарии «Spot GPU без потери работы: checkpoint, preemption и resume»: один проверочный запрос, пакет данных, обучение до контрольной метрики или стабильный сервис под нагрузкой. Укажите входные данные, допустимое время выполнения, требования к региону и максимальный бюджет. Без этой границы легко оптимизировать цену GPU-часа и одновременно получить более дорогой итог из-за повторов, простоя, медленного диска или передачи данных.

Зафиксируйте baseline на локальной машине или известном инстансе: версию модели, precision, batch size, размер контекста, число обработанных единиц, latency p50/p95, throughput, пиковую VRAM и итоговую стоимость. Сравнивать нужно одинаковые задачи, а не рекламные TFLOPS. Если baseline отсутствует, сначала выполните короткий ограниченный прогон; он дешевле, чем миграция production-нагрузки на несовместимую конфигурацию.

Совместимость и план данных

Проверьте не только название GPU, но и архитектуру, объём VRAM на ускоритель, число ускорителей, наличие нужного interconnect, версию драйвера и поддерживаемые CUDA/ROCm runtime. Для контейнера сохраните digest образа, а для Python — lock-файл зависимостей. Unknown в карточке предложения означает необходимость проверки у провайдера, а не подходящее значение по умолчанию.

До запуска решите, где будут находиться веса, датасет, checkpoints, логи и готовые артефакты. Эфемерный диск удобен для кэша, но не является резервной копией. Оцените время первичной загрузки и повторный egress, задайте контрольные суммы для крупных файлов и не копируйте секреты внутрь образа. При удалении инстанса отдельно проверьте оставшиеся volumes, snapshots и публичные IP.

Эксплуатационный runbook

Фаза 1 — подготовка. 1) Узнайте сигнал и окно предупреждения о прерывании у провайдера. 2) Выберите внешний storage с достаточной скоростью записи. До аренды назначьте владельца запуска, подтвердите бюджет и сохраните ссылку на проверенное предложение. Зафиксируйте локальные версии клиента и ожидаемую конфигурацию узла. Секреты создайте отдельно для эксперимента и ограничьте минимальными правами. Подготовка завершена, когда другой инженер может по записи понять исходные данные, ограничения и условие остановки, не обращаясь к автору runbook.

Фаза 2 — выполнение. 1) Сохраняйте model, optimizer, scheduler, scaler, step и RNG state. 2) Пишите checkpoint во временный каталог, проверяйте и переименовывайте. 3) Обработайте SIGTERM и оставьте периодический fallback checkpoint. Выполняйте шаги последовательно и сохраняйте безопасный вывод после каждого изменения. Не изменяйте одновременно образ, версию runtime и форму входных данных: иначе источник ошибки нельзя будет определить. Долгие операции запускайте в управляемой сессии, добавьте timeout и проверьте свободный диск до загрузки весов. Повторный запуск должен либо безопасно продолжить работу, либо явно потребовать очистку временного состояния.

Фаза 3 — приёмка. 1) Принудительно завершите job и подтвердите точный resume. 2) Повреждённый последний checkpoint откатывается на предыдущий. Для каждой проверки заранее укажите ожидаемый диапазон, а не только «работает». Сохраните время, конфигурацию, latency, throughput, пиковую память и число ошибок. Выполните негативный тест: неверный токен, превышение лимита или недоступный файл должны приводить к контролируемому отказу без раскрытия секрета. Приёмка заканчивается сравнением с исходным baseline и решением продолжить, изменить конфигурацию или откатиться.

Фаза 4 — риски и откат. 1) Слишком частые checkpoint могут съесть экономию на storage I/O. 2) Data loader position и seed тоже влияют на воспроизводимость. Превратите каждое ограничение в наблюдаемый сигнал и конкретное действие: остановить новый трафик, сохранить checkpoint, вернуть прежний образ или удалить ресурс. Откат проверяется до production, пока цена ошибки мала. После задачи выгрузите артефакты, проверьте контрольные суммы, отзовите credentials и отдельно удалите compute, volumes, snapshots и IP. Финальный счёт сверяйте после завершения биллингового окна.

Полная стоимость и наблюдаемость

Считайте compute по фактическому времени биллинга и области цены: node-hour нельзя незаметно сравнивать с accelerator-hour. Затем добавьте постоянные и временные диски, snapshots, исходящий трафик, публичный адрес, поддержку, простой при загрузке модели и неуспешные прогоны. Неизвестный компонент оставляйте неизвестным и показывайте диапазон, а не подставляйте ноль. Для оптимизации используйте стоимость завершённой задачи, токена, изображения или эпохи.

Минимальная телеметрия включает загрузку и память GPU, температуру и throttling, CPU/RAM, чтение и запись диска, сеть, очередь запросов, latency, ошибки и число завершённых единиц. Привяжите метрики к версии модели и конфигурации. Один быстрый benchmark не подтверждает устойчивую производительность: выполните прогрев, ограниченный нагрузочный тест и проверку после нескольких циклов checkpoint или выгрузки результатов.

Безопасность, остановка и доказательство результата

Используйте отдельные короткоживущие credentials с минимальными правами, закрывайте управляющие интерфейсы сетью или VPN и не публикуйте Jupyter, ComfyUI, inference endpoint или метрики без аутентификации и TLS. Секреты передавайте через предназначенный механизм провайдера, регулярно ротируйте их и удаляйте после задачи. Marketplace-host рассматривайте как внешнюю среду: не размещайте там данные, для которых не определены шифрование, удаление и допустимая юрисдикция.

Работа завершена только после сохранения артефактов, проверки контрольных сумм, фиксации метрик и удаления оплачиваемых ресурсов. Снимок панели биллинга и итоговый run report должны показывать время запуска и остановки, конфигурацию, успешность, известные затраты и оставшиеся неизвестные. Для production добавьте владельца, срок действия исключений и понятный rollback. Если провайдер не подтверждает удаление или итоговую цену, сохраните это как открытый риск.