MLOps: Інфраструктура для Навчання, Розгортання та Моніторингу ML-Моделей
Модель навчена, метрики чудові. Через три місяці у production якість впала на 12%. Ніхто не знає коли саме — немає моніторингу. Не можна швидко переучити — навчальний скрипт живе у ноутбуці data scientist'а, який звільнився. Дані для переучення потрібно збирати вручну з трьох систем. Це не гіпотетична ситуація — це те, з чим приходять приблизно в половині випадків.
MLOps — інженерна дисципліна, яка робить ML-системи відтворювальними, управлями та підтримуваними у production.
Experiment Tracking та Відтворюваність
Без трекингу експериментів ML-проект швидко стає хаосом: незрозуміло, який чекпоінт краще, які гіперпараметри використовувались, який датасет. Відтворити результат через місяць — квест.
MLflow — open source стандарт для трекингу. Логує параметри, метрики, артефакти (моделі, графіки) та код. MLflow Model Registry — централізоване сховище моделей з версіонуванням та lifecycle стейджами (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 воспроізводить весь pipeline від сирих даних до метрик. Без цього "датасет версії 3 з augmentations" — просто надія на пам'ять колег.
Training Pipeline'и: Kubeflow, Airflow, Prefect
Коли потрібен оркестратор. Скрипт навчання на 100 рядків у cron — нормально для простих задач. Але як тільки з'являється multi-step pipeline (завантаження даних → preprocessing → feature engineering → навчання → валідація → деплой якщо якість вище порога), потрібен оркестратор з retry-логікою, візуалізацією, alert'ами.
Kubeflow Pipelines — Kubernetes-native оркестратор для ML. Кожен шаг pipeline — Docker-контейнер. Підтримує паралельні шаги, умовні гілки, артефакти між кроками. Інтегрується з Katib (AutoML), KServe (serving), Feast (feature store). Високий поріг входу, але масштабується до сотень паралельних запусків.
Apache Airflow — більш загальний DAG-оркестратор, не специфічний для ML. Широка екосистема операторів (S3, Spark, DBT, Kubernetes). Простіший deploy ніж Kubeflow, якщо компанія вже має Airflow.
Prefect / Metaflow — сучасніші альтернативи, менше boilerplate. Prefect 2.x з декораторами @flow та @task — швидкий старт для малих команд.
Типова архітектура training pipeline на Kubeflow:
- Data ingestion — заходимо дані з S3/БД, валідуємо схему через Great Expectations
- Preprocessing — трансформації, нормалізація, train/val/test split
- Training — навчання на GPU, логування в MLflow
- Evaluation — обчислення метрик, порівняння з baseline у Model Registry
- Conditional deployment — деплой тільки якщо нова модель краща на >2% F1
Кожен компонент — окремий Docker-образ. Pipeline версіонується в git. Запуск — ручний або за розкладом (переучування раз на тиждень на нових даних).
Model Registry та Управління Життєвим Циклом
Model Registry — не просто сховище чекпоїнтів. Централізована система, яка знає:
- Яка модель зараз в production (та її метрики)
- Історія всіх версій з параметрами навчання
- Метадані: датасет, git commit, результати валідації
- Lifecycle: None → Staging → Production → Archived
MLflow Model Registry — стандарт. Для enterprise — Vertex AI (GCP), SageMaker (AWS), Azure ML.
Просування моделі через стейджі. Автоматично переводимо в 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 — стандарт. Alert при P99 latency > порога або error rate > 1%.
Data drift моніторинг. Розподіл вхідних даних змінюється зі часом. Детектуємо через:
- PSI (Population Stability Index) для чисел: PSI > 0.2 — сильний дрейф
- Chi-squared test для категоріальних
- Kolmogorov-Smirnov для неперервних
- Evidently AI — open source бібліотека з готовими drift-тестами та HTML-репортами
Model drift моніторинг. Якщо є ground truth з затримкою — мониримо реальні метрики якості. Якщо нема — surrogate метрики: розподіл prediction scores, доля confident передсказань.
Alerting. Три рівні: INFO (невеликий дрейф, логуємо), WARNING (значимий дрейф, сповіщаємо команду), CRITICAL (якість упала нижче порога, автоматичне переключення на fallback або human review).
Feature Store
Feature Store розв'язує проблему training-serving skew. Якщо feature engineering відрізняється між навчанням та інференсом — розхождення невідворотне.
Feast — open source Feature Store. Offline store (S3 + Parquet/Delta) для навчання, online store (Redis, DynamoDB) для low-latency інференса. Feature definitions як код, materialization job синхронізує offline → online.
Tecton (комерційний), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варіанти з меншим ops overhead.
Коли потрібен: кілька моделей використовують одні й ті ж features; features вичісляються з потокових даних (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) та записувати в метадані експерименту. Без цього debug нерегулярних результатів — мука.
Training-serving skew. Різний preprocessing у train та inference. Рішення: один preprocessing модуль, використовуваний і при навчанні, і при інференсі. Для sklearn: Pipeline об'єкт, що включає трансформації.
Немає версіонування даних. "Датасет v3" у імені файлу — не версіонування. DVC + S3 — мінімум.
Немає fallback. Модель впала або деградувала — немає плану. Завжди мати fallback: попередня версія моделі, rule-based логіка, або graceful "не можемо відповісти".
Терміни та Етапи
Базова MLOps-інфраструктура (трекинг експериментів, Model Registry, serving, базовий моніторинг): 4-6 тижнів. Повнофункціональна платформа з Kubeflow, Feature Store, CI/CD та продвинутим моніторингом: 3-5 місяців. Аудит існуючої інфраструктури та roadmap: 1-2 тижні.