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

Трейдери часто скаржаться: модель чудово працювала на тренді, але після переходу в боковик почала зливати депозит. Причина не в моделі, а у відсутності MLOps, який адаптується до ринкового режиму. Стандартний MLOps, де latency в 500 мс вважається нормою, для HFT неприйнятний — кожна мікросекунда затримки означає втрачений прибуток. Наша інфраструктура спроектована під жорсткі вимоги фінансової галузі: p99 latency до 5 мс, zero-downtime перемикання моделей та повний audit trail.

За даними дослідження J.P. Morgan, 70% HFT-фірм використовують FPGA для інференсу, що дає до 10-кратного прискорення відносно CPU. Проте FPGA не завжди обов'язковий: для внутрішньоденних стратегій достатньо ONNX Runtime з оптимізаціями. Розберемо, як вибудувати MLOps, який витримує навантаження реального трейдингу.

Чому MLOps для трейдингу — окрема дисципліна?

Стандартний MLOps орієнтований на сервіси з latency в сотні мілісекунд і можливістю ручного перемикання моделей. У трейдингу ціна помилки — втрата прибутку або регуляторні санкції. Ось чотири ключові відмінності:

Latency вимоги: Для HFT моделі повинні видавати передбачення за <1 мс. Для внутрішньоденних стратегій — <100 мс. Стандартні REST API інференс-сервіси часто не підходять. Порівняємо підходи:

Zero-downtime перемикання: заміна моделі в trading hours ризикована. Потрібні механізми hot-swap без переривання торгівлі — наприклад, через shadow deployment з перевіркою agreement rate > 90%. Це в 2-3 рази надійніше, ніж стандартний blue-green деплой з перериванням.

Відтворюваність: при аудиті необхідно точно відтворити передбачення моделі в конкретний момент часу (яка версія моделі працювала, які дані використовувалися). Ми гарантуємо це через повний audit trail — кожне передбачення логується з model_version, data_version та хешем коду.

Market regime awareness: переучування повинно враховувати поточний ринковий режим (trend, mean-reversion, high-volatility). Модель, хороша для трендових ринків, небезпечна на боковику. Наш пайплайн автоматично детектує зміну режиму за волатильністю та кореляціями.

Як забезпечити zero-downtime деплой моделей?

Hot-swap без зупинки торгівлі — головна вимога. Ми використовуємо багатоетапний підхід:

1. Shadow деплой: паралельно основному розгортається нова модель. Протягом 2 годин порівнюємо передбачення — якщо agreement rate > 90%, модель можна просувати.
2. Canary деплой: перемикаємо на нову модель 10% торгового обсягу, спостерігаємо за P&L attribution. При відхиленнях відкочуємо за 1 секунду.
3. Повний rollout: в non-trading hours (02:00-09:00) перемикаємо весь обсяг. Всі дії логуються для аудиту.

Архітектура інфраструктури

┌─────────────────────────────────────────────────────────┐ │ Data Infrastructure │ │ [Market Data Vendor] → [Kafka] → [ClickHouse/TimescaleDB]│ │ [Alternative Data] → [Feature Store] ← [Feature Pipeline]│ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ Training Infrastructure │ │ [Airflow/Prefect] → [GPU Training Cluster] │ │ [MLflow] ← [Experiment Tracking] → [Model Registry] │ │ [DVC] → [Data Versioning] │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ Inference Infrastructure │ │ [Model Loader] → [Low-Latency Inference Server] │ │ [Shadow Model] → [A/B Framework] → [Active Model] │ │ [Risk Management Layer] → [Execution Engine] │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ Monitoring Stack │ │ [Prediction Logger] → [ClickHouse] → [Grafana] │ │ [Drift Detector] → [Alert Manager] → [PagerDuty] │ │ [P&L Attribution] → [Model Performance Dashboard] │ └─────────────────────────────────────────────────────────┘ 

Як забезпечити low-latency інференс?

import onnxruntime as ort import numpy as np import threading class LowLatencyModelServer: """Інференс з цільовою latency < 5мс""" def __init__(self, model_path: str): # ONNX Runtime з оптимізаціями opts = ort.SessionOptions() opts.intra_op_num_threads = 4 opts.inter_op_num_threads = 1 opts.execution_mode = ort.ExecutionMode.ORT_SEQUENTIAL opts.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL self.session = ort.InferenceSession( model_path, sess_options=opts, providers=['CUDAExecutionProvider', 'CPUExecutionProvider'] ) self._lock = threading.RLock() # Warm up dummy_input = np.zeros((1, 50), dtype=np.float32) for _ in range(10): self.predict(dummy_input) def predict(self, features: np.ndarray) -> float: with self._lock: result = self.session.run( None, {'input': features.astype(np.float32)} ) return float(result[0][0]) 

Цей код на ONNX Runtime дає до 3x прискорення відносно PyTorch JIT на тій же GPU. Для HFT ми додатково використовуємо TensorRT і pinned memory.

Pipeline переучування з market regime detection

class TradingModelRetrainingPipeline: def __init__(self, model_registry, risk_manager): self.registry = model_registry self.risk = risk_manager def should_retrain(self, performance_metrics: dict) -> tuple[bool, str]: # Дрифт ознак if performance_metrics['feature_psi'] > 0.2: return True, "Feature drift detected" # Деградація метрик if performance_metrics['sharpe_ratio_7d'] < 0.5: return True, "Sharpe degradation" # Зміна ринкового режиму if self._detect_regime_change(): return True, "Market regime change" return False, None def safe_model_swap(self, new_model_path: str): """Hot-swap моделі без переривання торгівлі""" # 1. Запустити shadow deployment на 2 години self._start_shadow_deployment(new_model_path) # 2. Перевірити agreement rate if self._shadow_agreement_rate() < 0.90: raise ValueError("Shadow model agreement rate too low for safe swap") # 3. Переключити в non-trading hours (02:00-09:00) if not self._is_safe_swap_window(): self._schedule_swap_for_night() return # 4. Swap with self.risk.trading_pause(timeout_seconds=5): self.active_model = load_model(new_model_path) 

Які метрики моніторити, щоб не пропустити деградацію?

Моніторинг повинен покривати не тільки performance моделі, але й інфраструктурні метрики. Ми виділяємо три рівні:

Audit trail та відтворюваність

def log_prediction_for_audit(features, prediction, model_version, timestamp): audit_store.insert({ 'timestamp': timestamp, 'model_version': model_version, 'model_git_hash': get_model_code_hash(model_version), 'data_version': get_feature_data_version(timestamp), 'input_features': features.tolist(), 'prediction': float(prediction), 'prediction_id': str(uuid.uuid4()) }) 

Кожне передбачення зберігається з версією моделі, версією даних та хешем коду — достатньо для точного відтворення в разі регуляторного запиту або investigation.

Що входить в результат

Ми передаємо не просто код, а готову до експлуатації інфраструктуру:

• Розгорнутий CI/CD пайплайн для моделей (GitHub Actions + MLflow + Docker)
• Моніторинг з алертами в PagerDuty/Telegram (p99 latency, дрифт, P&L)
• Повна документація щодо відтворюваності та аудиту
• Навчання вашої команди (2–3 сесії)
• Гарантія стабільності на 6 місяців після запуску

Оцініть проєкт для вашого завдання — зв'яжіться, ми підберемо оптимальне рішення під ваш стек і бюджет. Отримайте консультацію з MLOps для трейдингу — напишіть нам.

Строки реалізації

Базова MLOps-інфраструктура (трекінг, registry, деплой): 4-6 тижнів. Повна система з моніторингом дрифту, автопереучуванням та audit trail: 3-4 місяці. Це інвестиція, яка окупається при першому серйозному інциденті з деградацією моделі. Зв'яжіться — обговоримо деталі та строки для вашого проєкту.