Чекпоинты и перезапуск HPC‑задач на GPU

Задача страницы. Дать практический каркас для устойчивого выполнения длительных GPU‑расчётов в облаке: паттерны чекпоинтов (периодические, инкрементальные, координированные), перезапуски после прерываний и по расписанию, схемы для одно‑ и многоузловых задач, метрики и экономика (t_ckpt, MTBF, Loss_expected, Cost_overhead). Страница — опорная для всех HPC‑разделов.

TL;DR

  • Чанк времени ≤ 120 с — базовый паттерн для Interruptible: каждую минуту‑две сохраняем минимальный «срез» состояния, чтобы потеря прогресса была приемлемой. См. https://cloudcompute.ru/solutions/interruptible-patterns/
  • NVMe‑scratch → тёплое → холодное. Чекпоинты пишем локально (NVMe), затем асинхронно выталкиваем в «тёплое»/«холодное» хранилище. См. https://cloudcompute.ru/solutions/storage-data/
  • 1 процесс = 1 GPU, координация по ранкам при многоузловом запуске; глобальный манифест с метаданными и версиями контейнера. См. https://cloudcompute.ru/solutions/multi-gpu/
  • Типовые наборы состояний: iteration/step, RNG‑seed/offset, декомпозиция домена, параметры решателя, инкрементальные суммы (а не «всю матрицу»/траекторию).
  • Атомика записи: *.tmp → fsync → rename (атомарная замена) — никакой частично записанной «грязи».
  • Экономика и частота: оптимальный интервал ∝ sqrt(2 * t_ckpt * MTBF); снижайте t_ckpt сжатием/дельтами — уменьшится общий overhead. См. https://cloudcompute.ru/solutions/cost-planner/
  • Наблюдаемость: checkpoint_write_seconds, last_ckpt_age, retry_total, gpu_utilization, p95 step_time. См. https://cloudcompute.ru/solutions/monitoring-logging/

Сценарии (когда это нужно)

  • Длинные tightly‑coupled прогоны (MD/CFD/оптимизация) — периодические координированные чекпоинты по барьеру.
  • Пакеты независимых задач (HTS‑докинг, Монте‑Карло, граф‑аналитика) — мелкие идемпотентные чанки и «журнал» завершённых партий.
  • Многоузловые MPI‑разгоны — консистентный срез по всем ранкам + манифест соответствия ранк↔файл.
  • Онлайн‑сервисы — деградация до «warm‑start» состояний (кэши, веса, счётчики) с минимальным временем RTO.
  • Гибридные пайплайны — чекпоинты на стыках стадий (подвыборки/срезы данных).

Архитектуры/пайплайны A) Rolling‑чекпоинты на одном узле (GPU‑resident)

[Warm Storage] -> [Prefetch -> NVMe] -> [Compute on GPU] --(every ≤120 s)--> [Write ckpt/*.tmp -> fsync -> rename]
 --------------------------------------> [Async uploader -> Warm/Cold]

Ключи: атомарная запись, версионирование ckpt/<job_id>/<ts>/, журнал ckpt.meta.json с container_digest, gpu_profile, rng_state, last_good.

B) Координированный чекпоинт (многоузловой MPI)

Barrier
Rank0 ──┐ (all ranks reach ckpt) ┌─> write ckpt/rank0.bin -> ack
Rank1 ──┤──────────────┬───────────┤─> write ckpt/rank1.bin -> ack
 ... │ │ │
RankN ──┘ └───────────┘─> write ckpt/rankN.bin -> ack
 ---------------> [Rank0 writes ckpt.manifest.json + OK flag]

Ключи: единый manifest (список файлов, размеры, хэши, версия декомпозиции), барьер до и после записи, опционально incremental/delta.

C) Журнал независимых задач (Interruptible)

[Task Shards] -> [Queue] -> [GPU Worker (chunk ≤120 s)] -> [Append result row to journal.csv + ckpt minimal] -> [Reducer]

Ключи: идемпотентность на уровне ключей задач; перезапуск безопасен; «журнал» — источник истины.

Что чекпоинтить: карта по типам задач

**Класс** **Минимальные состояния** **Дополнительно**
**GROMACS** prod.cpt (встроенный), step, сетка PME -maxh/автосейв, параметры интегратора
**LAMMPS** restart.\*.bin, step, neighbor‑параметры read\_restart + лог смены потенциала
**NAMD/AMBER** \*.rst7/restart, timestep, термостаты/баростаты соответствие версий
**OpenFOAM** time/ слепки, controlDict collated‑I/O, writeNow при сигнале
**Parabricks** стадийные маркеры (align/sort/bqsr/call) Idempotent merge, индексы BAM/CRAM
**Монте‑Карло** seed/base, path\_offset, частичные суммы/квадраты квази‑последоват. параметры
**Граф‑аналитика** iter, residual, renumbering‑map checksum снапшоты PR/Louvain
**Линал/оптимизация** x/z/u, k, предфакторы/скейлы tol/ρ/шаги, состояние RNG
**VRP/MILP** incumbent/bound, журнал узлов фолаут кандидатов

Профили GPU/VRAM и влияние на чекпоинт

**Профиль** **VRAM** **Типичные объёмы ckpt** **Отн. скорость записи (≈)** **Комментарии**
**24 ГБ (Compact)** 24 ГБ 10–200 МБ/шаг 1.0 Мелкие/частые ckpt; отлично для чанков ≤ 120 с
**48 ГБ (Balanced)** 48 ГБ 100–800 МБ/шаг 1.4–1.7 Больше локальный буфер, стабильнее запись
**80 ГБ (HQ)** 80 ГБ 0.5–3 ГБ/шаг 2.0–2.5 Имеет смысл включать **delta**/сжатие

Порядки величин зависят от приложения и формата; NVMe‑скретч обязателен. ## Конфиги и скелеты

1) Универсальный YAML‑профиль чекпоинтов

checkpoint:
 interval_seconds: 120 # целевой интервал
 rotation: 3 # хранить N последних локально
 compression: "zstd" # none|zstd|lz4
 delta: true # инкрементальные сравнения с последним "базовым"
 manifest: "/nvme/ckpt/ckpt.manifest.json"
 write_atomic: true # *.tmp -> fsync -> rename
 uploader:
 enable: true
 to: "warm" # warm|cold
 max_bandwidth_mb_s: 200
 retries: 5
 contents:
 - name: "state.json" # метаданные шага/версий/RNG/размеров
 - name: "rank_{rank}.bin" # бинарные слепки ранков
 - name: "journal.csv" # журнал завершённых подзадач

2) Python‑скелет атомарной записи и манифеста

import os, json, time, hashlib
CKPT = "/nvme/ckpt"
def atom_write(path, data: bytes):
 tmp = path + ".tmp"
 with open(tmp, "wb") as f:
 f.write(data); f.flush(); os.fsync(f.fileno())
 os.replace(tmp, path) # атомарная замена
def write_manifest(step, files):
 meta = {
 "step": step,
 "ts": int(time.time()),
 "container_digest": os.getenv("CONTAINER_DIGEST","unknown"),
 "gpu_profile": os.getenv("GPU_PROFILE","unknown"),
 "files": []
 }
 for p in files:
 h = hashlib.sha256(open(p,"rb").read()).hexdigest()
 meta["files"].append({"path": p, "sha256": h, "size": os.path.getsize(p)})
 atom_write(os.path.join(CKPT,"ckpt.manifest.json"), json.dumps(meta).encode())
# пример: сохраняем состояние решателя
def save_state(step, state_dict: dict, blob_bytes: bytes):
 os.makedirs(CKPT, exist_ok=True)
 atom_write(os.path.join(CKPT, "state.json"), json.dumps(state_dict).encode())
 atom_write(os.path.join(CKPT, f"rank_{os.getenv('RANK','0')}.bin"), blob_bytes)
 write_manifest(step, [os.path.join(CKPT,"state.json"), os.path.join(CKPT, f"rank_{os.getenv('RANK','0')}.bin")])

3) Slurm: перехват сигналов и форс‑чекпоинт

#!/bin/bash
#SBATCH -J hpc_job
#SBATCH -N 2
#SBATCH --gpus-per-node=4
#SBATCH -t 08:00:00
#SBATCH --signal=B:USR1@120 # за 120 с до walltime шлём USR1
#SBATCH --exclusive
handle_signal() {
 echo "[`date`] signal received, forcing checkpoint..."
 python /opt/ckpt/force_ckpt.py || true
}
trap handle_signal USR1 TERM
# старт вашей задачи в фоне
python /opt/app/run.py --resume /nvme/ckpt/ || true &
# периодический rolling-ckpt (подстраховка)
while sleep 120; do python /opt/ckpt/rolling_ckpt.py || true; done &
wait

4) Примеры перезапуска (по приложениям)

# GROMACS
gmx mdrun -s topol.tpr -deffnm prod -cpi prod.cpt -nb gpu -pme gpu -update gpu
# LAMMPS
lmp -in in.lmp # сгенерирует restart.*.bin
lmp -restart2data out.restart.100000 data.new # альтернатива
lmp -in continue_from_restart.lmp
# OpenFOAM
simpleFoam -case /nvme/case -latestTime # старт с последнего времени
# NAMD/AMBER
namd3 +p4 md_gpu.namd +restart
pmemd.cuda.MPI -O -i mdin -c prev.rst7 -r new.rst7 -x traj2.nc
# Монте‑Карло/свои солверы
python run_mc.py --resume-from /nvme/ckpt/state.json

5) Асинхронный uploader (NVMe → тёплое)

#!/bin/bash
set -euo pipefail
SRC=/nvme/ckpt; DST=/warm/jobs/$JOB_ID/ckpt/
while true; do
 find "$SRC" -type f -mmin -1 -name '*.json' -o -name '*.bin' | while read f; do
 # заменить на ваш «тёплый» драйвер хранения
 cp -u "$f" "$DST"/
 done
 sleep 30
done

Наблюдаемость/метрики/алерты

Опорные хабы: https://cloudcompute.ru/solutions/monitoring-logging/ • https://cloudcompute.ru/solutions/llm-inference/observability/

Метрики:

  • Чекпоинты: checkpoint_write_seconds, checkpoint_size_bytes, last_ckpt_age_seconds, ckpt_success_total, ckpt_fail_total.
  • Задача: resume_success_total, resume_time_seconds, lost_work_seconds (оценка), jobs_retried_total.
  • I/O: io_write_mb_s, nvme_usage_bytes, uploader_queue_depth.
  • GPU/кластер: gpu_utilization, mpi_wait_ratio, rdma_rx/tx_mb_s.

Алерты:

  • last_ckpt_age_seconds > 2× целевого интервала.
  • checkpoint_write_seconds > интервала → риск потери прогресса.
  • nvme_usage_bytes > 85% → остановить новые шаги, выгрузить старые ckpt.
  • Всплеск resume_fail_total → повреждения, рассинхронизация версий.

Экономика и формулы

См. https://cloudcompute.ru/solutions/cost-planner/ и https://cloudcompute.ru/solutions/throughput-vs-latency/

Ожидаемая потеря работы и overhead:

Overhead_ckpt ≈ t_ckpt / I

Loss_expected ≈ I / (2 * MTBF)

Total_overhead ≈ Overhead_ckpt + Loss_expected

где I — интервал чекпоинта, t_ckpt — время записи, MTBF — среднее время между отказами/прерываниями.

Оптимальный интервал (оценка):

I_opt ≈ sqrt(2 * t_ckpt * MTBF)

Полная стоимость задачи:

Cost_overhead = (c_gpu * N_gpu / U) * (Overhead_seconds / 3600)

Cost_total = Cost_compute + Cost_overhead + Storage_cost

Снижайте t_ckpt (сжатие/дельты/параллельная запись) — падает I_opt и весь Total_overhead.

Практики и паттерны

  • Atomic‑I/O: *.tmp → fsync → rename. Для множества ранков — манифест с хэшами.
  • Delta/инкрементальные слепки: хранить базовый полный ckpt + дельты (сигнатуры блоков/страниц).
  • Сжатие и бинарные форматы: бинарные структуры, сжатие полей, «тонкие» структуры (не хранить временные буферы).
  • RNG‑дисциплина: записывать base_seed и offset/sequence; детерминированный resume.
  • Сигналы и walltime: ловить USR1/TERM/аналог, форсировать writeNow/-maxh/«save state».
  • Координация: координированный барьер + локальная запись; избегать глобального узкого места.
  • Асинхронная публикация: NVMe→«тёплое» в фоне, запись меток о завершении (OK‑флаг).
  • Версионирование: в каждый ckpt писать container_digest, версии библиотек, параметры запуска. См. https://cloudcompute.ru/solutions/containers-ci-cd/
  • Retenшн: держать N локальных + «золотые» в «холодном»; автоочистка по TTL.
  • Форматы вычислений: безопасные при возобновлении; см. https://cloudcompute.ru/solutions/fp8-bf16/ и https://cloudcompute.ru/solutions/performance-tuning/

Безопасность/политики

См. https://cloudcompute.ru/solutions/security/

  • Секреты: пути бакетов/токены — только из секрет‑хранилища; запрет логирования.
  • PII/конфиденциальное: ckpt может содержать приватные данные/модели — шифровать «на покое», контроль доступа по проектам.
  • Аудит: журнал кто/когда создал/восстановил ckpt, версии контейнеров.
  • Изоляция: отдельные неймспейсы/ACL; egress‑allow‑list до «тёплых» бакетов.
  • Ретеншн: TTL, «золотые» метки, удаление «мусора» (.tmp) при старте.

Траблшутинг (симптом → причина → решение)

**Симптом** **Возможная причина** **Решение**
Повреждённый ckpt/не читается Неатомарная запись/обрыв Включить tmp+fsync+rename; валидировать хэш; не читать без OK‑флага
Долгая запись ckpt Медленный диск/слишком крупный слепок NVMe‑scratch; сжатие/дельты; параллельная запись по ранкам; реже полные ckpt
Высокая потеря прогресса Интервал слишком большой Сократить I до цели ≤ 120 с; уменьшить t\_ckpt; увеличить частоту частичных слепков
Рассинхрон ранков Нет координации/разные версии Барьер; единый контейнер/версии; манифест соответствия ранк↔файл
Частые падения resumers Неполный набор состояний Добавить RNG‑state, параметры решателя, декомпозицию домена
Забит NVMe Нет ротации Включить rotation, автоочистку по TTL, uploader‑drain
Resume даёт иные результаты Нестабильные флаги/версии Зафиксировать контейнер/флаги; писать container\_digest и проверять при resume

Как запустить в cloudcompute.ru

  1. Шаблоны: https://cloudcompute.ru/solutions/templates/ — включают rolling‑чекпоинты и uploader (NVMe→тёплое).
  2. Профиль GPU: выбирайте 24/48/80 ГБ по объёму ckpt и типу задачи; для множества мелких — MIG. См. https://cloudcompute.ru/solutions/mig/
  3. Режим: tightly‑coupled — On‑Demand; независимые чанки — Interruptible (≤ 120 с). См. https://cloudcompute.ru/solutions/interruptible-patterns/
  4. Сеть/диск: локальный NVMe для ckpt, затем фоновая выгрузка; при многоузловом — координация по UCX/RDMA. См. https://cloudcompute.ru/solutions/storage-data/
  5. Контейнеры/CI: зафиксируйте версии и включите smoke‑resume (создать ckpt → восстановиться → сверить контрольные метрики). См. https://cloudcompute.ru/solutions/containers-ci-cd/
  6. Наблюдаемость: дашборды checkpoint_*, last_ckpt_age_seconds, resume_* + GPU/I‑O/сеть. См. https://cloudcompute.ru/solutions/monitoring-logging/

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

  • Определён состав ckpt (минимальный набор состояний) и формат; включена атомарная запись.
  • Интервал чекпоинта выбран (целимся в ≤ 120 с для Interruptible); t_ckpt профилирован.
  • Включена ротация и uploader NVMe→«тёплое/холодное»; есть место на диске.
  • При многоузловом — координация по барьеру, манифест, согласованные версии контейнеров.
  • Тест «создал‑упал‑восстановился» прошёл; контрольные метрики совпали.
  • Дашборды и алерты checkpoint_write_seconds, last_ckpt_age_seconds, resume_fail_total заведены.
  • Политики безопасности/ретенции применены; секреты не попадают в логи.
  • Экономика посчитана: Total_overhead, Cost_overhead, проверен оптимальный I_opt.

Навигация

Готовы запустить?

Запустить GPU-сервер