Кэш моделей и постоянный диск без повторной загрузки

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

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

1. Оцените размер весов, кэша, датасета и запас для временных файлов.
2. Выберите persistent volume или объектное хранилище по профилю доступа.

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

1. Смонтируйте volume в каталог кэша Hugging Face.
2. Пиньте revision модели и сохраняйте checksum манифеста.
3. Загружайте артефакты через временное имя и переименовывайте атомарно.

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

1. Повторный инстанс использует кэш и не скачивает веса заново.
2. Удаление compute не удаляет persistent volume без явного действия.

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

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

1. Кэш может содержать закрытые модели — ограничьте доступ.
2. Не храните единственный checkpoint на локальном эфемерном диске.

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

До аренды сформулируйте, что именно должно завершиться в сценарии «Кэш моделей и постоянный диск без повторной загрузки»: один проверочный запрос, пакет данных, обучение до контрольной метрики или стабильный сервис под нагрузкой. Укажите входные данные, допустимое время выполнения, требования к региону и максимальный бюджет. Без этой границы легко оптимизировать цену 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) Выберите persistent volume или объектное хранилище по профилю доступа. До аренды назначьте владельца запуска, подтвердите бюджет и сохраните ссылку на проверенное предложение. Зафиксируйте локальные версии клиента и ожидаемую конфигурацию узла. Секреты создайте отдельно для эксперимента и ограничьте минимальными правами. Подготовка завершена, когда другой инженер может по записи понять исходные данные, ограничения и условие остановки, не обращаясь к автору runbook.

Фаза 2 — выполнение. 1) Смонтируйте volume в каталог кэша Hugging Face. 2) Пиньте revision модели и сохраняйте checksum манифеста. 3) Загружайте артефакты через временное имя и переименовывайте атомарно. Выполняйте шаги последовательно и сохраняйте безопасный вывод после каждого изменения. Не изменяйте одновременно образ, версию runtime и форму входных данных: иначе источник ошибки нельзя будет определить. Долгие операции запускайте в управляемой сессии, добавьте timeout и проверьте свободный диск до загрузки весов. Повторный запуск должен либо безопасно продолжить работу, либо явно потребовать очистку временного состояния.

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

Фаза 4 — риски и откат. 1) Кэш может содержать закрытые модели — ограничьте доступ. 2) Не храните единственный checkpoint на локальном эфемерном диске. Превратите каждое ограничение в наблюдаемый сигнал и конкретное действие: остановить новый трафик, сохранить 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. Если провайдер не подтверждает удаление или итоговую цену, сохраните это как открытый риск.