Приборкання ML-пайплайнів: CI/CD, моніторинг і деплой
ML-проєкти ламаються не там, де прийнято думати. Не на етапі навчання моделі — там датасаєнтисти працюють роками і знають що роблять. Ламаються на етапі доставки в production: модель навчена, метрики хороші, а розгорнути її в Kubernetes, налаштувати моніторинг drift'у та вибудувати процес перенавчання — ніхто не знає як. DevOps-інженер дивиться на .pkl файл вагою 2GB і не розуміє, що з ним робити далі. Типова картина: команда витрачає 70% часу на ручний деплой і моніторинг, а не на покращення моделі. Автоматизація пайплайнів дозволяє скоротити time-to-market з 2 тижнів до 2 днів.
Замовте консультацію — ми проаналізуємо вашу інфраструктуру і запропонуємо оптимальний стек за 48 годин. За п'ять років ми впровадили MLOps у 15+ проєктах — від стартапів до enterprise. Автоматизація пайплайнів знижує операційні витрати на 30–50% на місяць. Нижче — розбір пайплайну, стеку та підводних каменів.
Чим ML pipeline відрізняється від звичайного CI/CD
У звичайному CI/CD код детермінований: один і той самий commit на тій самій платформі дає однаковий артефакт. ML-пайплайн — ні. Результат залежить від даних, гіперпараметрів, випадкового seed'у, версії бібліотеки. pip install tensorflow без фіксованої версії в різні дні дає різні результати.
Версіонувати потрібно все:
- Код — як зазвичай, через git
- Дані — через DVC (Data Version Control), lakeFS або Delta Lake
- Конфігурацію — гіперпараметри, preprocessing steps
- Артефакти — ваги моделі, feature encoders, scalers
- Оточення —
requirements.txtз pin'd версіями, або Docker образ
Відтворюваний експеримент — це коли за git commit можна відновити точно таку саму модель з тими самими метриками. Без цього production troubleshooting неможливий.
Як виглядає типовий стек MLOps
Стандартний стек для production ML на Kubernetes:
- Data Storage: S3/GCS (зберігання датасетів до 50TB) → DVC для версіонування
- Experiment Tracking: MLflow Tracking Server (до 1000 експериментів на день)
- Model Registry: MLflow Model Registry або Weights & Biases Registry
- Training Pipeline: Argo Workflows або Kubeflow Pipelines
- Model Serving: Seldon Core, BentoML, або Triton Inference Server
- Monitoring: Evidently AI + Prometheus + Grafana
- Feature Store: Feast (опціонально, для online features)
Офіційна документація MLflow рекомендує версіонувати не лише код, а й оточення.
Чому data drift — головний ворог ML в production?
Після деплою моделі розподіл даних може змінитися — це data drift. Наприклад, модель кредитного скорингу навчалася на даних до пандемії, а після — поведінка позичальників змінилася. Evidently AI заміряє дрейф по кожній фічі: якщо >30% фіч дрейфують, точність падає на 15-20% за тиждень, і запускається перенавчання. Без моніторингу точність падає непомітно, а бізнес втрачає гроші.
Як забезпечити відтворюваність ML-експериментів?
Фіксуйте все: версії коду (git), даних (DVC), конфігурацій (hyperparams.yaml), оточення (Docker з pin'd версіями). Для кожного експерименту зберігайте метадані в MLflow: commit, параметри, seed, метрики. Тільки тоді можливий відкат до робочої версії.
CI/CD для ML-моделей
Приклад пайплайну GitLab CI
---
stages:
- validate
- train
- evaluate
- register
- deploy
validate-data:
stage: validate
image: python:3.11-slim
script:
- pip install -r requirements.txt
- dvc pull data/train
- python scripts/validate_data.py --schema schemas/training_data.json
artifacts:
reports:
junit: validation_report.xml
train-model:
stage: train
image: ${CI_REGISTRY_IMAGE}/ml-training:latest
tags: [gpu]
variables:
MLFLOW_TRACKING_URI: "https://mlflow.internal"
MLFLOW_EXPERIMENT_NAME: ${CI_PROJECT_NAME}
script:
- dvc pull data/
- python scripts/train.py --config configs/model_config.yaml --experiment-id ${CI_PIPELINE_ID} --commit ${CI_COMMIT_SHA}
artifacts:
paths:
- outputs/model/
evaluate-model:
stage: evaluate
script:
- python scripts/evaluate.py --model-path outputs/model/ --test-data data/test/ --threshold-config configs/quality_gates.yaml
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
register-model:
stage: register
script:
- python scripts/register_model.py --model-path outputs/model/ --version ${CI_COMMIT_SHORT_SHA} --stage Staging
only:
- main
deploy-to-production:
stage: deploy
script:
- python scripts/promote_model.py --model-name ${MODEL_NAME} --from-stage Staging --to-stage Production
- kubectl apply -f k8s/model-deployment.yaml
when: manual
only:
- main
Quality gate — ключовий момент. Модель не реєструється якщо метрики нижче порогу. Приклад конфігу configs/quality_gates.yaml:
accuracy: 0.92 f1_score: 0.88 precision: 0.90 recall: 0.86 Перевірка реалізується скриптом evaluate.py, який порівнює фактичні метрики з порогами і повертає статус.
Model Serving в Kubernetes
Seldon Core розгортає моделі як Kubernetes-нативні сервіси і до 3x швидше TensorFlow Serving:
---
apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
name: fraud-detection
namespace: ml-production
spec:
predictors:
- componentSpecs:
- spec:
containers:
- name: fraud-model
image: ${ECR_URL}/fraud-detection:${MODEL_VERSION}
resources:
requests:
memory: "2Gi"
cpu: "500m"
limits:
memory: "4Gi"
cpu: "2"
graph:
name: fraud-model
type: MODEL
name: default
replicas: 3
traffic: 100
A/B testing між версіями — через traffic розподіл між предикторами.
Моніторинг drift і деградації
Evidently AI генерує звіти про data drift і model performance. Якщо частка дрейфуючих фіч перевищує 30%, тригериться пайплайн перенавчання. Grafana дашборд відображає model_accuracy, data_drift_score, prediction_latency_p99, request_count — всі метрики з Prometheus через Seldon Core metrics endpoint.
Як ми впроваджуємо MLOps: покроковий процес
Процес впровадження розбитий на чотири етапи:
- Аудит і проєктування — аналізуємо поточний ML workflow, інфраструктуру, вимоги по SLA. Проектуємо архітектуру: GitOps, версіонування, CI/CD пайплайн. Аудит займає 1-2 дні, проєктування — до тижня.
- Розгортання стеку — інсталюємо MLflow, Seldon Core, налаштовуємо моніторинг (Prometheus, Grafana, Evidently). Навчаємо команду роботі з інструментами.
- Розробка пайплайнів — пишемо CI/CD пайплайни в GitLab CI або Argo Workflows, інтегруємо quality gates, налаштовуємо автоскейлінг (Karpenter, HPA).
- Запуск і оптимізація — деплоїмо першу модель, налаштовуємо alerting в PagerDuty/Slack, документуємо runbook. Передаємо проєкт в експлуатацію.
| Критерій | GitLab CI | Argo Workflows |
|---|---|---|
| Складність налаштування | Низька | Середня |
| Підтримка DAG | Обмежена | Повна |
| Швидкість виконання | Висока | Середня |
| Підходить для | Невеликих команд | Enterprise |
Що входить в роботу
| Етап | Що входить | Терміни |
|---|---|---|
| Базовий MLOps | MLflow, CI/CD пайплайн, model serving, документація | 6-8 тижнів |
| Просунутий | Drift monitoring, auto-retraining, A/B testing, навчання | 3-5 місяців |
| Зріла практика | Feature store, online learning, full automation | 6-12 місяців |
Додатково: аудит безпеки, налаштування RBAC, інтеграція з існуючими системами (Jira, Slack).
Чому варто впровадити MLOps разом з нами
Ми — команда з п'ятирічним досвідом в DevOps і MLOps. На рахунку — понад 15 впроваджень пайплайнів для ML-продуктів. Використовуємо перевірений стек, пишемо документацію, навчаємо вашу команду. Гарантуємо SLA за часом відгуку — підписуємо договір з відповідальністю.
Ключові переваги:
- Сертифікований досвід: Kubernetes, GitOps, ArgoCD, Seldon Core
- Власні шаблони пайплайнів — час запуску скорочується на 40%
- Працюємо з AWS EKS, GCP GKE, Yandex Cloud, Selectel
- Індивідуальний підхід: рішення під ваш стек, а не впарювання готового шаблону
Вартість проєкту розраховується після аудиту. Практичний досвід показує, що автоматизація MLOps знижує операційні витрати на 30-50% за рахунок зменшення ручної праці та інцидентів.
Зв'яжіться з нами для консультації. Отримайте оцінку проєкту за 48 годин.
