Docker и CUDA на арендной GPU без конфликта драйверов

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

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

1. Зафиксируйте digest контейнера и версию CUDA.
2. Убедитесь, что провайдер разрешает Docker и проброс GPU.

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

1. Проверьте Docker, установите NVIDIA Container Toolkit по официальной инструкции.
2. Запустите тестовый CUDA-контейнер с параметром --gpus all.
3. Соберите рабочий образ из минимальной CUDA runtime-базы и зафиксируйте зависимости.

docker run --rm --gpus all nvidia/cuda:12.8.1-base-ubuntu24.04 nvidia-smi

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

1. nvidia-smi внутри контейнера видит те же GPU, что и хост.
2. Тестовый тензор создаётся на cuda:0 без CPU fallback.

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

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

1. Не устанавливайте другой kernel driver внутрь контейнера.
2. latest делает сборку невоспроизводимой — используйте версию или digest.

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

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

Фаза 2 — выполнение. 1) Проверьте Docker, установите NVIDIA Container Toolkit по официальной инструкции. 2) Запустите тестовый CUDA-контейнер с параметром --gpus all. 3) Соберите рабочий образ из минимальной CUDA runtime-базы и зафиксируйте зависимости. Выполняйте шаги последовательно и сохраняйте безопасный вывод после каждого изменения. Не изменяйте одновременно образ, версию runtime и форму входных данных: иначе источник ошибки нельзя будет определить. Долгие операции запускайте в управляемой сессии, добавьте timeout и проверьте свободный диск до загрузки весов. Повторный запуск должен либо безопасно продолжить работу, либо явно потребовать очистку временного состояния.

Фаза 3 — приёмка. 1) nvidia-smi внутри контейнера видит те же GPU, что и хост. 2) Тестовый тензор создаётся на cuda:0 без CPU fallback. Для каждой проверки заранее укажите ожидаемый диапазон, а не только «работает». Сохраните время, конфигурацию, latency, throughput, пиковую память и число ошибок. Выполните негативный тест: неверный токен, превышение лимита или недоступный файл должны приводить к контролируемому отказу без раскрытия секрета. Приёмка заканчивается сравнением с исходным baseline и решением продолжить, изменить конфигурацию или откатиться.

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