В этом материале
Режим аренды выбирают по переносимости задачи и горизонту работы; низкий приоритет требует проверенного сохранения состояния.
В Vast.ai on-demand и reserved дают высокий приоритет, а interruptible может приостанавливаться из-за более приоритетного спроса. Reserved оформляется через преобразование on-demand с предоплатой. Выбор зависит от допустимости пауз и длительности задачи, а не только от видимой цены.
Сравните реальные механизмы аренды
Документация instance types описывает три варианта. Она также указывает, что переключение между on-demand и interruptible требует нового экземпляра. Нельзя планировать такой переход как простой тумблер уже работающей среды.
| Режим | Приоритет и механизм | Что важно для проекта |
|---|---|---|
| On-demand | Высокий приоритет, условия предложения хоста | Максимальная длительность аренды |
| Reserved | On-demand с предоплатой и скидкой | Привязка кредита к экземпляру |
| Interruptible | Приоритет ставок, возможна пауза | Сохранение и продолжение задачи |
Таблица описывает продуктовые различия. Она не является измерением доступности и не обещает, что любой ресурс подойдёт для непрерывного внешнего сервиса.
Когда пауза действительно допустима
Для пакетной обработки документов можно сохранять завершённые элементы и продолжать с первого необработанного. Для интерактивной демонстрации с назначенным временем ожидание ресурса может оказаться неприемлемым. Одинаковая GPU в этих сценариях не делает подходящим одинаковый режим аренды.
Проверьте, где хранится прогресс. Сохранённые файлы и переменные процесса имеют разный жизненный цикл. Если задача продолжает работу только из памяти старого процесса, формальное наличие диска не доказывает устойчивость к паузе. Нужен явный механизм восстановления на уровне приложения.
Пример расчёта с повторными попытками
Команда обрабатывает тысячу независимых изображений. Она сохраняет отдельный результат для каждого файла и журнал завершённых входов. В тесте специально останавливает рабочую сессию, запускает её заново и проверяет, что уже выполненные элементы не обрабатываются повторно без необходимости.
Только после такого опыта имеет смысл сравнивать interruptible с непрерываемым вариантом. В расчёт включают повторную загрузку среды, потерянную работу и ожидание. Нельзя заранее считать разницу опубликованных ставок чистой экономией всего проекта: время восстановления зависит от собственной организации задачи.
Что проверить перед резервом
Описание reserved instances раскрывает оформление и правила предоплаты. Проверьте срок, связь кредита с конкретным экземпляром и действующие условия досрочного завершения. Не переносите общее значение слова reserved на условия другого облака.
Перед обязательством выполните короткий пилот на той же конфигурации. Убедитесь, что памяти, диска и сети хватает, а срок аренды покрывает рабочее окно. Удачная загрузка контейнера ещё не доказывает пригодность ресурса на несколько недель, особенно если данные и набор задач будут расти.
Для reserved заранее оцените вероятность изменения требований проекта. Если через неделю понадобится другой хост или размер ресурса, привязка предоплаты имеет практическое значение. Такой вопрос лучше решить до обязательства, используя подтверждённый план работы. Ожидаемую скидку нельзя считать полученной экономией, пока выбранная конфигурация не проверена на реальной задаче и горизонте.
Зафиксируйте решение по задаче
В карточке выбора укажите допустимый простой, способ восстановления, полный горизонт и причину выбранного режима. Если позже меняется требование к сроку ответа, решение пересматривают вместе с типом аренды. Это понятнее коллегам, чем универсальное правило всегда выбирать самый дешёвый час.
Продолжите с жизненного цикла экземпляра и разбора расходов передачи данных.