Аннотация. Данный модуль посвящён практическому переводу обученных ML-моделей из исследовательской среды в продакшен. Рассматриваются сервинг моделей через REST API, контейнеризация с помощью Docker, а также базовые аспекты мониторинга и версионирования. Материал опирается на реальные инструменты и рабочие процессы, используемые в индустрии.

Цель. Сформировать навыки упаковки ML-модели в воспроизводимый сервис, доступный по API и готовый к развёртыванию в облачной или серверной инфраструктуре.

Результаты обучения. По завершении модуля слушатель сможет:

• объяснять разницу между образом и контейнером Docker;
• писать Dockerfile для ML-сервиса;
• создавать API на FastAPI с эндпоинтами /predict и /health;
• выполнять сериализацию моделей (joblib, safetensors);
• настраивать базовый мониторинг (логирование, health check).

Целевая аудитория. ML-инженеры, Data Scientist'ы, MLOps-специалисты, знакомые с Python и основами машинного обучения, но нуждающиеся в системном понимании процесса деплоя.

Docker решает ключевую проблему ML-развёртывания — невоспроизводимость окружения. Код, работающий на машине разработчика, может падать на сервере из-за различий в версиях Python, NumPy или CUDA. Контейнеризация позволяет упаковать приложение вместе со всеми зависимостями в изолированный образ.

Образ (image) — это неизменяемый шаблон, содержащий операционную систему (обычно легковесный Linux), код приложения, библиотеки и конфигурации. Образ можно сравнить с классом в ООП или чертежом. Контейнер (container) — это запущенный экземпляр образа, подобно объекту, созданному по классу. На основе одного образа можно запустить множество контейнеров.

Базовые команды:

docker build -t my-ml-model:v1 .
docker run --name experiment-1 my-ml-model:v1
docker ps
docker images

Для ML-проектов особенно важно, что Docker изолирует зависимости: библиотека TensorFlow может требовать конкретную версию CUDA, а PyTorch — конфликтовать с определёнными релизами NumPy. Контейнеры предотвращают эти конфликты на уровне окружения.

Dockerfile — текстовый файл с инструкциями для сборки образа. Типичная структура для ML-сервиса на FastAPI:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .
COPY model.pkl .

EXPOSE 8000

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

Разбор инструкций:

• FROM задаёт базовый образ. python:3.11-slim — минимальный образ с Python 3.11.
• WORKDIR устанавливает рабочую директорию внутри контейнера.
• COPY копирует файлы с хоста в образ. Сначала копируются только requirements.txt, затем выполняется pip install, и только потом — остальной код. Это использует кэширование слоёв: при изменении кода зависимости переустанавливаться не будут.
• EXPOSE документирует порт, который слушает приложение (сам по себе порт не открывает).
• CMD задаёт команду запуска: Uvicorn запускает FastAPI-приложение на порту 8000.

После создания Dockerfile образ собирается командой docker build -t my-model-api:v1 . и запускается через docker run -p 8000:8000 my-model-api:v1.

FastAPI — современный асинхронный веб-фреймворк для Python, хорошо подходящий для ML-сервинга. Он обеспечивает автоматическую валидацию входных данных через Pydantic, генерирует документацию Swagger (/docs) и поддерживает высокую производительность за счёт ASGI.

Минимальный сервер для инференса модели включает:

• загрузку модели при старте приложения;
• эндпоинт /predict для приёма данных и возврата предсказания;
• эндпоинт /health для проверки работоспособности сервиса;
• логирование запросов и ошибок.

Пример с joblib для scikit-learn модели:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import joblib

app = FastAPI()
model = joblib.load('model.pkl')

class PredictionRequest(BaseModel):
    features: list[float]

@app.get('/health')
def health():
    return {'status': 'healthy'}

@app.post('/predict')
def predict(request: PredictionRequest):
    try:
        features = [request.features]
        prediction = model.predict(features)[0]
        return {'prediction': prediction}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Для глубоких моделей вместо joblib используется safetensors — более безопасный формат, предотвращающий выполнение произвольного кода при загрузке.

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

• Scikit-learn, XGBoost, LightGBM — joblib.dump(model, 'model.pkl') и joblib.load('model.pkl'). Joblib эффективен для объектов с большими NumPy-массивами.
• PyTorch, TensorFlow — предпочтительно safetensors вместо pickle, так как pickle уязвим к исполнению вредоносного кода. Пример: save_file(model.state_dict(), 'model.safetensors').
• ONNX — переносимый формат для кросс-фреймворкового инференса, часто используется с onnxruntime.

При деплое модель загружается один раз при старте приложения и кэшируется в памяти. Это устраняет накладные расходы на чтение с диска при каждом запросе.

MLflow — инструмент для управления жизненным циклом ML-моделей: трекинг экспериментов, регистрация моделей (Model Registry) и развёртывание. В контексте VK Cloud MLflow может работать в двух режимах: в связке с JupyterHub (аутентификация через JupyterHub) или Standalone (отдельный инстанс со встроенной аутентификацией и ролевой моделью).

Для деплоя модели в прод используется MLflow Deploy — отдельный инстанс, который создаётся только в связке с MLflow. Процесс:

1. Модель регистрируется в MLflow Model Registry.
2. Создаётся инстанс MLflow Deploy (через личный кабинет VK Cloud, Terraform или библиотеку Cloud ML Platform).
3. Сервер развёртывания получает модель из MLflow.
4. Модель поднимается в Docker-контейнере, прокси Traefik открывает доступ во внешнюю сеть.

После развёртывания модель доступна по REST API. Пример запроса:

data = {"inputs": [0.045341, 0.050680]}

Пользователь отправляет данные и получает предсказание. Инфраструктурные задачи (контейнеры, сеть, масштабирование) берёт на себя облачная платформа, что снижает порог входа для Data Scientist'ов без глубоких знаний DevOps.

Для production-развёртывания ML-модели полезно следовать чек-листу:

• Валидация модели на отложенной выборке до деплоя.
• Health check эндпоинт для оркестратора.
• Логирование входных данных, предсказаний, задержек и ошибок.
• Аутентификация — API-ключи, OAuth или базовая аутентификация.
• Версионирование модели — возможность отката к предыдущей версии.
• Мониторинг дрейфа — отслеживание изменения распределения входных данных.
• Ограничения ресурсов — лимиты CPU/GPU и памяти для контейнера.

Игнорирование health check приводит к тому, что балансировщик отправляет трафик на нездоровые контейнеры, вызывая ошибки 503. Игнорирование логирования делает невозможной диагностику деградации качества модели в проде.

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

Анализ рынка вакансий (600+ позиций ML Engineer / Data Scientist на HH, декабрь 2025) показывает четыре типичных сценария требований к навыкам деплоя:

• Навыки деплоя не требуются — деплоем занимается отдельная команда или платформа.
• «Будет плюсом» — в компании есть готовый процесс выкатки, от ML-инженера требуется собрать Docker-образ или поправить конфигурацию.
• Деплой — часть обязанностей — ML-инженер сам отвечает за развёртывание модели и её обновление.
• Полноценный MLOps — чаще в стартапах, где один человек закрывает несколько ролей.

Статистика по вакансиям: навыки деплоя упоминаются примерно в 15–25% позиций. Лишь для 5–10% вакансий деплой критичен — его отсутствие может стать причиной отказа до технического этапа.

Топ технологий, встречающихся в вакансиях: Docker (~36%), Kubernetes (~19%), CI/CD (~18%), FastAPI (~16%), Flask (~6%), Triton (~5%), TensorRT (~4%), Jenkins (~3%), GitLab CI (~2%).