В этом материале
Уведомление Spot помогает завершению, но основой устойчивости служит регулярное сохранение и проверенный повторный запуск.
GPU-задачу в AWS Spot нужно проектировать так, чтобы она продолжалась после потери экземпляра. Регулярно сохраняйте контрольные точки вне временного ресурса и проверяйте повторный запуск. Уведомление о прерывании полезно, но не должно быть единственным моментом сохранения результата.
Что означает прерываемый ресурс
Документация Spot interruptions объясняет возврат свободной ёмкости EC2 по потребности облака. Ускоритель подходит для такой схемы только тогда, когда приложение переносит паузу и умеет восстановить прогресс. Успешный непрерывный тест этого свойства не подтверждает.
Сначала определите единицу повторной работы. Для независимых файлов это может быть один входной объект; для длительного расчёта — состояние очередного этапа. Не используйте общее слово checkpoint без описания, какие файлы и параметры действительно нужны для продолжения.
Используйте уведомления как дополнительный сигнал
Официальное описание interruption notices указывает EventBridge и metadata экземпляра. Уведомления предоставляются по принципу best effort. Для stop и terminate описано короткое окно предупреждения, а hibernation имеет отличающееся поведение.
Путь обработки события должен быть простым: перестать брать новые задачи, завершить допустимый маленький шаг, зафиксировать состояние и записать причину остановки. Нельзя рассчитывать, что в последний момент удастся впервые выгрузить весь большой датасет или сохранить неопределённый объём памяти процесса.
Пример обработки набора документов
Команда делит входные документы на независимые задания. Результат каждого записывается с идентификатором исходного файла и версией обработки. Отдельный журнал отмечает завершённые элементы. После перезапуска задача выбирает только отсутствующие или явно неудачные результаты.
| Проверка | Ожидаемое поведение |
|---|---|
| Повтор одного задания | Не создаёт незаметный дубликат |
| Неполный файл | Не считается готовым результатом |
| Потеря процесса | Прогресс находится вне его памяти |
| Новый экземпляр | Читает журнал и продолжает очередь |
| Отсутствие уведомления | Последняя регулярная копия всё равно доступна |
Такой тест оценивает архитектуру приложения, а не качество конкретной языковой модели. Частота сохранения зависит от стоимости повторной работы и размера артефактов.
Проверьте хранение отдельно
Укажите, куда записывается контрольная точка и переживёт ли этот ресурс выбранный тип прерывания. Для EBS важны настройки удаления и размещение; для внешнего хранилища — доступ роли и подтверждение завершённой записи. Файл в локальной директории не доказывает независимую сохранность.
При восстановлении нужны также версия кода, конфигурация и входные данные. Если они изменились, продолжение может дать смешанный результат. Помечайте контрольную точку идентификатором запуска и не перезаписывайте её молча несовместимым экспериментом.
В журнале восстановления фиксируйте идентификатор контрольной точки и число принятых результатов. Это позволяет проверить, что новая попытка действительно продолжила работу, а не незаметно начала всё заново. Для больших серий такая запись помогает отделить повторяемые расходы от полезного прогресса.
Измерьте цену восстановления
В ограниченном пилоте специально остановите задачу и запустите её на новой разрешённой среде. Измерьте время загрузки, число повторно обработанных элементов и целостность итогов. Только после этого сравнивайте полный расход Spot с альтернативой по одинаковому результату.
Далее полезны квоты GPU в AWS и жизненный цикл EBS. Проверяемое сохранение состояния поможет обсудить, какие задачи можно разумно планировать в эти окна.