MLOps: инфраструктура для обучения, деплоя и мониторинга ML-моделей
Модель обучена, метрики отличные. Через три месяца в продакшене качество упало на 12%. Никто не знает когда именно — нет мониторинга. Нельзя быстро переобучить — обучающий скрипт живёт в ноутбуке у data scientist'а, который уволился. Данные для переобучения надо собирать руками из трёх систем. Это не гипотетическая ситуация — это то, с чем приходят примерно в половине случаев.
MLOps — это инженерная дисциплина, которая делает ML-системы воспроизводимыми, управляемыми и поддерживаемыми в продакшене.
Experiment tracking и воспроизводимость
Без трекинга экспериментов ML-проект быстро превращается в хаос: непонятно, какой чекпоинт лучше, какие гиперпараметры использовались, какой датасет. Воспроизвести результат через месяц — квест.
MLflow — open source стандарт для трекинга. Логирует параметры, метрики, артефакты (модели, графики) и код. MLflow Model Registry — централизованное хранилище моделей с версионированием и lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving или интеграция с внешними системами.
Типичная инициализация в коде:
import mlflow
mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
mlflow.log_metric("val_f1", val_f1, step=epoch)
mlflow.pytorch.log_model(model, "model")
Это минимум. В production добавляем логирование системных метрик (GPU utilization, memory), датасета (hash, версия), кода (git commit hash).
Weights & Biases — более богатый UI, collaboration features, sweep для hyperparameter optimization. Предпочтительнее для команд с активным экспериментированием. MLflow — для on-premise deployment без внешних зависимостей.
DVC (Data Version Control) — версионирование данных и моделей поверх git. Данные хранятся в S3/GCS/Azure Blob, в git — только метаданные (хэши). dvc repro воспроизводит весь пайплайн от сырых данных до метрик. Без этого «датасет версии 3 с аугментациями» — просто надежда на память коллег.
Пайплайны обучения: Kubeflow, Airflow, Prefect
Когда нужен оркестратор. Скрипт обучения на 100 строк в cron — нормально для простых задач. Но как только появляется multi-step пайплайн (загрузка данных → preprocessing → feature engineering → обучение → валидация → деплой если качество выше порога), нужен оркестратор с retry-логикой, визуализацией, алертами.
Kubeflow Pipelines — Kubernetes-native оркестратор для ML. Каждый шаг пайплайна — Docker-контейнер. Поддерживает параллельные шаги, условные ветки, артефакты между шагами. Интегрируется с Katib (AutoML), KServe (serving), Feast (feature store). Высокий порог входа, но масштабируется до сотен параллельных запусков.
Apache Airflow — более общий DAG-оркестратор, не специфичен для ML. Широкая экосистема операторов (S3, Spark, DBT, Kubernetes). Проще развернуть, чем Kubeflow, если уже есть Airflow в компании.
Prefect / Metaflow — более современные альтернативы, меньше boilerplate. Prefect 2.x с декораторами @flow и @task — быстрый старт для небольших команд.
Типичная архитектура обучающего пайплайна на Kubeflow:
- Data ingestion component — забирает данные из S3/БД, валидирует схему через Great Expectations
- Preprocessing component — трансформации, normalization, train/val/test split
- Training component — обучение на GPU, логирование в MLflow
- Evaluation component — вычисление метрик, сравнение с baseline в Model Registry
- Conditional deployment — деплой только если новая модель лучше текущей на >2% F1
Каждый component — отдельный Docker-образ. Пайплайн версионируется в git. Запуск — ручной или по расписанию (ретрейнинг раз в неделю на новых данных).
Model Registry и управление жизненным циклом
Model Registry — не просто хранилище чекпоинтов. Это централизованная система, которая знает:
- Какая модель сейчас в продакшене (и с какими метриками)
- История всех версий с параметрами обучения
- Метаданные: датасет, git commit, результаты валидации
- Lifecycle stage: None → Staging → Production → Archived
MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.
Продвижение модели через стейджи. Автоматически переводим модель в Staging после успешного прохождения eval. Ручное или автоматическое (при A/B тесте) продвижение в Production. Rollback — переключение на предыдущую Production-версию за секунды.
Serving: от Flask до Triton
Простой случай. FastAPI + PyTorch/ONNX на одном сервере — 80% production ML deployments именно так. Достаточно для большинства задач с нагрузкой до 100 req/s.
from fastapi import FastAPI
import onnxruntime as ort
app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])
@app.post("/predict")
async def predict(request: PredictRequest):
inputs = preprocess(request.text)
outputs = session.run(None, {"input_ids": inputs})
return {"label": postprocess(outputs)}
Triton Inference Server — production-стандарт для высоких нагрузок. Dynamic batching (собирает запросы в батч автоматически), concurrent model execution, model ensemble. Поддерживает TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel. При нагрузке 500+ req/s и нескольких моделях одновременно — Triton выигрывает у любого кастомного serving.
KServe (бывший KFServing) — Kubernetes-native ML serving с autoscaling, canary deployments, A/B testing из коробки. Scale-to-zero для неактивных моделей — экономия на инфраструктуре.
vLLM для LLM-serving — отдельная история, описана в разделе про LLM.
Мониторинг: data drift, model drift, инфраструктурные метрики
Мониторинг — то, что обычно делают в последнюю очередь и о чём жалеют в первую. Три уровня.
Инфраструктурный мониторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold или error rate > 1%.
Data drift мониторинг. Распределение входных данных меняется со временем. Детектируем через:
- PSI (Population Stability Index) для числовых признаков: PSI > 0.2 — сильный дрейф
- Chi-squared test для категориальных
- Kolmogorov-Smirnov test для непрерывных
- Evidently AI — open source библиотека с готовыми дрейф-тестами и HTML-репортами
Model drift мониторинг. Если есть ground truth с задержкой (например, через неделю знаем, совершил ли пользователь покупку) — мониторим реальные метрики качества. Если ground truth недоступен — surrogate метрики: распределение prediction scores, доля confident predictions.
Alerting. Три уровня алертов: INFO (небольшой дрейф, логируем), WARNING (значимый дрейф, уведомляем команду), CRITICAL (качество упало ниже порога, автоматическое переключение на fallback-модель или human review).
Feature Store
Feature Store решает проблему рассинхронизации между feature engineering в обучении и в инференсе (training-serving skew). Если preprocessing во время обучения и во время инференса реализован в двух разных местах двумя разными людьми — расхождение неизбежно.
Feast — open source Feature Store. Офлайн store (S3 + Parquet/Delta) для обучения, онлайн store (Redis, DynamoDB) для low-latency инференса. Feature definitions как код, materialization job синхронизирует офлайн → онлайн.
Tecton (коммерческий), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варианты с меньшим ops overhead.
Когда нужен Feature Store: несколько моделей используют одни и те же признаки; признаки вычисляются из потоковых данных (real-time); большая команда с разными людьми на feature engineering и model training.
CI/CD для ML
ML CI/CD — обычный CI/CD плюс специфичные ML-шаги.
ML-специфичные checks в CI:
- Проверка воспроизводимости: запустить обучение с фиксированным seed, результат должен совпадать
- Data validation: Great Expectations или Pandera на schema/distribution checks
- Model performance check: автоматический eval на holdout, блокировать merge если деградация > порога
- Latency regression test: inference должен укладываться в SLA
GitOps для деплоя модели. Merge в main → CI запускает обучение → eval → если проходит → автоматический деплой в Staging → smoke tests → ручное продвижение в Production (или автоматическое при успешном canary).
Инструменты: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплоя на Kubernetes.
Типичные ошибки в MLOps
Нет воспроизводимости обучения. Фиксировать random seeds (torch.manual_seed, numpy.random.seed, random.seed) и записывать в метаданные эксперимента. Без этого дебаггинг нерегулярных результатов — боль.
Training-serving skew. Разный preprocessing в train и inference. Решение: единый preprocessing модуль, используемый и при обучении, и при инференсе. Для sklearn-пайплайнов: Pipeline объект, включающий трансформации.
Нет версионирования данных. «Датасет v3» в имени файла — не версионирование. DVC + S3 — минимум.
Отсутствие fallback. Модель упала или деградировала — нет плана. Всегда иметь fallback: предыдущая версия модели, rule-based логика, или "не отвечать" с graceful degradation.
Сроки и этапы
Базовая MLOps-инфраструктура (трекинг экспериментов, Model Registry, serving, базовый мониторинг): 4-6 недель. Полноценная платформа с Kubeflow, Feature Store, CI/CD и продвинутым мониторингом: 3-5 месяцев. Аудит существующей инфраструктуры и roadmap: 1-2 недели.