Приходилось ли писать Docker файлы и работать с контейнерами

Что проверяют

Доводили ли вы модель до состояния, когда её можно запустить не на своём ноутбуке. В ML контейнеризация болезненнее обычной бэкендовой: тяжёлые зависимости, GPU, веса модели, данные. Интервьюер хочет понять, отличаете ли вы образ для обучения от образа для инференса и что вы кладёте внутрь, а что оставляете снаружи.

Как отвечать

Расскажите про структуру образа и границу между кодом и артефактами.

• База: python:*-slim для CPU-инференса, официальный образ с CUDA, когда нужна видеокарта. GPU внутри контейнера появляется не сам по себе: нужны совместимый драйвер на хосте и nvidia-container-toolkit, запуск с --gpus all.
• Зависимости: фиксируются полностью, включая сборку torch под конкретную версию CUDA. Установка из дефолтного индекса легко даёт CPU-вариант, и это выясняется уже на сервере.
• Веса и данные: в образ не попадают. Модель едет из объектного хранилища или реестра моделей по версии, датасеты монтируются томом. Иначе образ распухает до десятков гигабайт и перестаёт возить по сети.
• Два образа: тренировочный с ноутбуками и инструментами профилирования, инференсный минимальный, с сервером предсказаний и healthcheck.
• Воспроизводимость: версия кода, версия весов и версия образа связаны тегом, чтобы по ответу сервиса можно было понять, что именно считало.

Где спотыкаются

Запекают датасет и чекпойнты в образ. Сборка идёт полчаса, реестр забивается, а обновление одной строки кода перекачивает гигабайты весов.

Не фиксируют версии библиотек. Модель, сохранённая через pickle или joblib, ломается при несовпадении версий scikit-learn или numpy, причём иногда молча: объект грузится, а предсказания меняются.

Третье: считают, что Docker сам решает вопрос с видеокартой. Без toolkit и подходящего драйвера контейнер просто не видит устройство, а собранный на рабочей станции образ с другой версией CUDA на сервере не стартует.