Решения

Планировщик стоимости GPU: On‑Demand vs Interruptible

Цель страницы. Помогает выбрать режим аренды, оценить бюджет задачи и понять, где экономия безопасна. Ниже — простая методика расчёта, чек‑лист параметров и рекомендации по профилям нагрузок.

Ключевой выбор: режим аренды

On‑Demand
(высокий приоритет)

Фиксированная цена от хоста, высокий приоритет; инстанс работает столько, сколько нужно (в пределах лимита «maximum duration», заданного хостом на карточке оффера). Подходит для интерактива, длительных и чувствительных к прерываниям задач.
После остановки по инициативе пользователя/хоста данные остаются доступны на машине.

Interruptible
(низкий приоритет, по ставке/аукцион)

Ставка (bid) определяет приоритет; если кто‑то поставит выше или появится on‑demand на эти же ресурсы, ваш инстанс будет приостановлен (процессы завершаются). Данные сохраняются на диске; возобновление — когда ресурс снова станет доступен по вашей ставке. Требует устойчивого пайплайна с автосейвом/чекпоинтингом.
Переключить уже запущенный инстанс между on‑demand/interruptible нельзя — режим выбирается при создании.

Решение в двух шагах

Если нужен гарантированный непрерывный прогон или критичный дедлайн — берите On‑Demand.
Если задача масштабируется горизонтально, допускает остановки и у вас есть чекпоинтинг — Interruptible даст существенную экономию. (Для устойчивых паттернов см. /solutions/interruptible-patterns/.)

Из чего складывается стоимость

Cписывается, пока инстанс в состоянии active/connected.

Тарифицируется помесячно/помесячно‑в‑часовом эквиваленте за каждый ГБ во всех состояниях, кроме offline; это значит, что за остановленные инстансы хранение тоже платное.

$/ТБ (вход/выход), тарифицируется по факту.

Базовая формула бюджета

				
					R_gpu — ставка GPU ($/час)
H_active — суммарные часы активной работы
R_storage — ставка хранения ($/ГБ/мес. или эквивалент $/час)
GB — размер диска
D — дни существования инстанса (пока он не offline)
R_bw — ставка трафика ($/ТБ)
TB_in, TB_out — объёмы входящего/исходящего трафика (ТБ)
Total = (R_gpu × H_active) + (R_storage × GB × D/30) + (R_bw × (TB_in + TB_out))

Ключевой выбор: режим аренды

Где экономить без потери результата

Безопасно на interruptible, если:

Задача батчевая и разбивается на шардированные куски (эмбеддинги, пакетный инференс, транскод).
Есть чекпоинтинг/автосейвы и быстрая перезагрузка пайплайна.
Легко поднять несколько маленьких инстансов вместо одного большого (горизонтальное масштабирование).
Подробнее — /solutions/interruptible-patterns/.

Лучше on‑demand, если:

Интерактив (Jupyter, удалённые рабочие места), строгие SLA, одноузловые долгие тренировки без надёжного чекпоинтинга.

Быстрый алгоритм планирования (5 шагов)

Классифицируйте нагрузку: обучение / инференс / рендер / ETL / HPC.
Определите допуск к прерываниям: да (берём interruptible) / нет (on‑demand).
Оцените ресурсы: VRAM (модель/батч), объём диска (датасеты/чекпоинты), трафик.
Подберите GPU‑класс:
- инференс/графика — чаще L4/L40S; крупное обучение — A100 80 GB/H100 (ориентиры).
- для выбора смотрите профиль решения из разделов /solutions/.

Посчитайте бюджет формулой и добавьте запас (например, +10–20% на повторные прогоны и трафик).

Типовые сценарии (как считать)

Инференс LLM‑сервера (24/7):
On‑Demand: R_gpu × 24 × 30 + R_storage × GB × 30/30 + R_bw × TB
Interruptible: та же формула, но берите H_active с учётом возможных простоев и запасом на повторный разогрев модели.
Пакетная генерация изображений (ночами):
Interruptible, несколько маленьких инстансов, каждый считает свою часть датасета; диск — минимально достаточный, чекпоинты и артефакты выгружать.
LoRA‑дотренировка (по вечерам, 3–4 часа): Interruptible с жёстким чекпоинтингом каждые N шагов; планируйте H_active как суммарные часы по всем перезапускам.

Резервирование (опционально)

Есть режим Reserved (предоплата на длительный период) — высокая приоритетность и существенные скидки (в доках указано «до 50%», уровень зависит от провайдера/условий). Подходит, если у вас стабильная долгоживущая нагрузка.

Чек‑лист параметров