Автоматизація MLOps для торгових моделей: CI/CD та моніторинг

Розробка MLOps-інфраструктури для торгових моделей

Ситуація: алгоритмічний трейдер витрачає 8 годин на ручне вивантаження даних, навчання моделі та деплой інференс-сервера. Помилка в конфігу — втрата дня. При обсязі в 50 угод на день кожна хвилина затримки деплою коштує $500, а при середньому чеку угоди в $5000 втрата однієї — відчутний удар по P&L. Це не гіпотетика — ми стикалися з таким не раз. Розроблена нами MLOps-інфраструктура для торгових моделей автоматизує весь пайплайн: від прийому ринкових тіків до видачі торгових сигналів. На одному проєкті скоротили час викатки з 4 годин до 15 хвилин — у 16 разів швидше ручного процесу. Такий підхід дозволяє командам зосередитися на розробці стратегій, а не на інфраструктурних танцях.

Чому MLOps критичний для торгових алгоритмів?

У трейдингу кожна мілісекунда затримки деплою або падіння inference сервера коштують реальних грошей. MLOps-інфраструктура вирішує три головні проблеми:

• Відтворюваність: модель, навчена сьогодні, повинна давати той самий результат завтра. Без версіонування даних і коду це неможливо.
• Швидкість: ручний деплой займає години, автоматизований — хвилини. Ми скоротили час викатки з 4 годин до 15 хвилин на одному з проєктів (на 94%).
• Моніторинг: дрейф фіч або погіршення метрик непомітні без системи алертів. Наші дашборди Grafana показують accuracy (цільовий поріг 95%), latency та volume в реальному часі.

На практиці це означає різницю між прибутковою угодою та збитком. Наприклад, при високочастотній торгівлі затримка в 100 мс може коштувати $10 000 на місяць. Саме тому ми використовуємо перевірені інструменти та best practices.

Як ми будуємо MLOps-пайплайн?

Ми використовуємо перевірений стек: ClickHouse для тікових даних, PostgreSQL для угод, S3/MinIO для сирих даних. Оркестрація — Prefect, версіонування моделей — MLflow, даних — DVC. Інференс на Kubernetes з автскейлінгом. Всі кроки описані в MLflow Documentation. Для стрімінгу ринкових даних використовуємо Kafka, що забезпечує затримку менше 10 мс.

Експерименти з MLflow

import mlflow
import mlflow.sklearn
import mlflow.pytorch
from mlflow.models.signature import infer_signature

def train_with_mlflow_tracking(experiment_name, config, X_train, y_train, X_val, y_val, X_test, y_test):
    mlflow.set_experiment(experiment_name)
    with mlflow.start_run(run_name=f"{config['model_type']}_{config['version']}"):
        mlflow.log_params({
            'model_type': config['model_type'],
            'n_features': X_train.shape[1],
            'train_size': len(X_train),
            'val_size': len(X_val),
            **config.get('hyperparams', {})
        })
        model = train_model(config, X_train, y_train, X_val, y_val)
        val_metrics = evaluate_model(model, X_val, y_val)
        test_metrics = evaluate_model(model, X_test, y_test)
        mlflow.log_metrics({f'val_{k}': v for k, v in val_metrics.items()})
        mlflow.log_metrics({f'test_{k}': v for k, v in test_metrics.items()})
        signature = infer_signature(X_train[:10], model.predict_proba(X_train[:10]))
        mlflow.sklearn.log_model(model, 'model', signature=signature, registered_model_name=f"crypto_{config['symbol']}_predictor")
        import matplotlib.pyplot as plt
        fig = plot_feature_importance(model, X_train.columns)
        mlflow.log_figure(fig, 'feature_importance.png')
        run_id = mlflow.active_run().info.run_id
        return run_id, test_metrics

Версіонування даних з DVC

---
# dvc.yaml — pipeline визначення
stages:
  fetch_data:
    cmd: python src/data/fetch_ohlcv.py --symbol BTC --days 730
    deps:
      - src/data/fetch_ohlcv.py
    outs:
      - data/raw/btc_ohlcv.parquet
  feature_engineering:
    cmd: python src/features/engineer.py
    deps:
      - src/features/engineer.py
      - data/raw/btc_ohlcv.parquet
    outs:
      - data/features/btc_features.parquet
    params:
      - params.yaml:
          - feature_engineering
  train:
    cmd: python src/train.py
    deps:
      - src/train.py
      - data/features/btc_features.parquet
    outs:
      - models/btc_predictor.pkl
    metrics:
      - metrics/train_metrics.json
    params:
      - params.yaml:
          - training

CI/CD для ML з GitHub Actions

---
# .github/workflows/ml_pipeline.yml
name: ML Training Pipeline
on:
  schedule:
    - cron: '0 1 * * 0'
  workflow_dispatch:
    inputs:
      symbol:
        description: 'Trading symbol'
        default: 'BTC'
jobs:
  train:
    runs-on: [self-hosted, gpu]
    steps:
      - uses: actions/checkout@v3
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Pull data with DVC
        run: dvc pull data/
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}
      - name: Run training pipeline
        run: dvc repro
        env:
          MLFLOW_TRACKING_URI: ${{ secrets.MLFLOW_URI }}
      - name: Validate model
        run: python src/validate_model.py --min-accuracy 0.54 --min-sharpe 1.0
      - name: Deploy to production
        if: success()
        run: python src/deploy_model.py
        env:
          TRADING_API_KEY: ${{ secrets.TRADING_API }}

Деплой на Kubernetes

---
# k8s/ml-inference-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: crypto-ml-inference
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ml-inference
  template:
    spec:
      containers:
        - name: inference
          image: crypto-ml-inference:latest
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
            limits:
              cpu: "2000m"
              memory: "4Gi"
          env:
            - name: MLFLOW_TRACKING_URI
              valueFrom:
                secretKeyRef:
                  name: ml-secrets
                  key: mlflow_uri
          livenessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8000
            initialDelaySeconds: 10

Feature Store: єдиний реєстр ознак

Feature Store — це єдина точка доступу до ознак для навчання та інференсу. Використовуємо Feast: визначаємо entities і feature views, online serving видає актуальні значення за мілісекунди. Без Feature Store ознаки розраховуються заново в кожному пайплайні, що призводить до розходження train/serve та помилок. На практиці це дає економію до 40% часу на розробку нових фіч.

Порівняння інструментів: MLflow, DVC, Prefect

Вибір оркестратора залежить від масштабу. MLflow ідеальний для експериментів — логує гіперпараметри, метрики та моделі з мінімальним кодом. DVC доповнює його версіонуванням даних, працюючи поверх Git, що зручно для маленьких команд. Prefect справляється зі складними DAG з ретраями та моніторингом. У трейдингу, де критичний порядок кроків (спочатку fetch_data, потім train), Prefect надійніший за Airflow завдяки вбудованим політикам retry. Ми не використовуємо платні інструменти — весь стек open-source.

Як MLOps скорочує час деплою?

В одному проєкті ми автоматизували пайплайн для крипто-фонду. Раніше дата-сайентист витрачав 4 години на підготовку релізу: вивантаження даних, навчання, перевірка метрик, ручний деплой. Після впровадження MLOps той самий цикл займає 15 хвилин. Всі кроки зафіксовані в DVC-пайплайні та запускаються однією командою. CI/CD перевіряє якість моделі (мінімальний accuracy 0.54, Sharpe ratio 1.0) і при успіху автоматично викочує новий контейнер у Kubernetes. Час простою inference сервера скоротився з 2 годин до 30 секунд, uptime досяг 99.9%. Економія на втратах від простоїв склала до $5000 на місяць.

Що входить у роботу

• Аудит поточного пайплайну та інфраструктури
• Проєктування архітектури MLOps
• Розгортання та налаштування MLflow, DVC, Prefect
• CI/CD pipeline (GitHub Actions / GitLab CI)
• Kubernetes маніфести для inference
• Моніторинг (Prometheus, Grafana, алерти)
• Документація та навчання команди
• Підтримка 1 місяць після запуску

Етапи роботи

1. Аналітика — знайомство з вашим стеком, вимогами щодо затримки та частоти оновлення моделей. Визначаємо SLA.
2. Проєктування — малюємо архітектуру, обираємо інструменти, створюємо proof of concept невеликої моделі.
3. Реалізація — налаштовуємо інфраструктуру, пишемо пайплайни, інтегруємо CI/CD.
4. Тестування — навантажувальне тестування, перевірка відтворюваності, стрес-тест інференсу.
5. Деплой — розгортаємо в production, налаштовуємо моніторинг.
6. Передача — документація, навчання, сесія питань-відповідей.

Строки орієнтовно

3 типові помилки при впровадженні MLOps

1. Ігнорування версіонування даних — модель вчиться на різних зрізах, результат непередбачуваний. DVC вирішує проблему.
2. Відсутність алертів на дрейф — коли розподіл фіч змінюється, модель втрачає точність. Ми ставимо PSI-лічильник у Prometheus.
3. Один бінарник для всіх моделей — різні моделі потребують різного оточення. Використовуємо Docker з тегуванням.

Досвід та експертиза: ми працюємо у сфері MLOps понад 5 років, виконали 50+ проєктів у фінтеху та крипто. Сертифіковані інженери з AWS та Kubernetes. Гарантуємо якість та підтримку після запуску. Зв'яжіться з нами для консультації щодо вашого проєкту. Замовте розробку MLOps-інфраструктури під ключ. Отримайте консультацію — розповімо, як адаптувати best practices під ваш стек.