Перенести модели и датасеты на арендную GPU

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

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

1. Классифицируйте данные и удалите секреты и PII, которые не нужны job.
2. Проверьте ingress, egress и межрегиональные тарифы.

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

1. Для единичной передачи используйте rsync по SSH; для повторной — объектное хранилище.
2. Включите resume и ограничение полосы, чтобы не мешать inference.
3. Проверяйте manifest с размером и SHA-256.

rsync -avP --partial --checksum ./model/ user@HOST:/data/model/

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

1. Количество файлов, общий размер и checksum совпадают.
2. Удалённый процесс читает данные с ожидаемой скоростью.

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

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

1. Не отправляйте закрытый датасет через публичный bucket.
2. Сжатие помогает тексту, но почти не помогает уже сжатым media.

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

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

Фаза 2 — выполнение. 1) Для единичной передачи используйте rsync по SSH; для повторной — объектное хранилище. 2) Включите resume и ограничение полосы, чтобы не мешать inference. 3) Проверяйте manifest с размером и SHA-256. Выполняйте шаги последовательно и сохраняйте безопасный вывод после каждого изменения. Не изменяйте одновременно образ, версию runtime и форму входных данных: иначе источник ошибки нельзя будет определить. Долгие операции запускайте в управляемой сессии, добавьте timeout и проверьте свободный диск до загрузки весов. Повторный запуск должен либо безопасно продолжить работу, либо явно потребовать очистку временного состояния.

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

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