Deep Learning System Design

Обучить модель на датасете - это 5% работы по созданию production ML системы. Остальные 95% - data pipelines, feature stores, serving infrastructure, monitoring, A/B testing, retraining automation. Google, Meta и Airbnb потратили годы, строя эти системы. Сегодня их подходы - индустриальный стандарт, описанный в десятках публичных engineering blogs.

• **Netflix персонализация** - 300+ ML моделей в production с continuous training: каждый день модели переобучаются на свежих данных через автоматизированный ML pipeline
• **Uber Michelangelo** - internal ML platform, обрабатывает миллионы предсказаний в секунду: ETA, surge pricing, fraud detection - единая serving infrastructure
• **Airbnb Bighead** - ML platform с feature store, автоматическим monitoring и A/B testing: 600+ активных ML моделей, обновляемых командой из 50 инженеров
• **Meta PyTorch Serve** - обслуживает триллионы инференсов в день для ranking, recommendations, content understanding на Facebook/Instagram

The paper that named ML's hidden costs

В 2015 D. Sculley с коллегами в Google опубликовал 'Hidden Technical Debt in Machine Learning Systems', утверждая, что код модели - крошечная доля реальной ML системы, окружённая конфигурацией, data pipelines, управлением фичами, мониторингом и serving-обвязкой. Статья назвала анти-паттерны, которые инженеры ощущали, но не формулировали: glue code, pipeline jungles, undeclared consumers и feedback loops. Она стала интеллектуальным фундаментом дисциплины MLOps, переосмыслив production ML как задачу системной инженерии, а не моделирования.

Предварительные знания

• Distributed Training: масштабирование на кластер
• Quantization и Pruning

Training Infrastructure

**Distributed training** - основа обучения современных больших моделей. Три парадигмы: Data Parallel (один батч делится по GPU), Model Parallel (слои модели делятся по GPU), Tensor Parallel (отдельные матрицы делятся по GPU). GPT-4 обучался на тысячах A100 с комбинацией всех трёх - 3D parallelism.

Gradient checkpointing (activation recomputation) обменивает compute на память: промежуточные активации не хранятся, а пересчитываются при backward pass. Увеличивает время обучения на ~30%, но позволяет обучать модели в 8-10x большего размера на том же GPU. Используется при обучении всех LLM.

Model Serving в Production

**Model serving** решает задачу: как подать модель пользователям с минимальной latency и максимальным throughput. Ключевые компоненты: inference server (TorchServe, Triton Inference Server, TensorFlow Serving), batching стратегия, hardware выбор (GPU vs CPU vs специализированные чипы), и caching.

vLLM (UC Berkeley, 2023) переосмыслил serving для LLM. PagedAttention хранит KV cache в несмежных блоках памяти (как виртуальная память в OS). Это устраняет внутреннюю фрагментацию - 100% GPU memory utilization vs 20-40% у наивного подхода. Результат: в 24x больший throughput при той же latency по сравнению с HuggingFace naive serving.

Data Pipeline и Feature Store

**Data pipeline** - часто самый сложный компонент ML системы. Исследование Sculley et al. «Hidden Technical Debt in ML Systems» показало: ML код составляет только 5% production системы. Остальные 95% - data collection, feature engineering, validation, serving infrastructure, monitoring. Хорошо структурированный data pipeline сокращает time-to-train и предотвращает data leakage.

Training-serving skew - критическая проблема: модель получает на serving другие features, чем видела при обучении. Причины: разные preprocessing библиотеки (numpy на training vs C++ на serving), временные фильтры, data leakage. Feature Store устраняет это - один и тот же код вычисляет features и офлайн, и онлайн.

ML Мониторинг и Model Drift

**Deployed модель деградирует со временем** - это не баг, это feature реального мира. Data drift: распределение входных данных изменяется (COVID изменил паттерны покупок → рекомендательные системы Amazon деградировали в 2020). Concept drift: само отношение input→output меняется (мошеннические схемы эволюционируют → fraud detection теряет точность).

Shadow deployment и canary releases - стандартные подходы для безопасного развёртывания. Shadow: новая модель получает все запросы, результаты логируются, но пользователю отдаётся ответ старой. Canary: 5% трафика идёт на новую модель, метрики сравниваются. Только при успехе - полный rollout. Netflix, Airbnb и Uber публично описали эти подходы в своих ML blogs.

Ключевые идеи

• **Distributed Training:** DDP для data parallel, DeepSpeed ZeRO для memory optimization; gradient checkpointing обменивает 30% compute на 8x меньше памяти
• **Serving:** Triton Inference Server + dynamic batching + TensorRT оптимизация; vLLM PagedAttention - 24x throughput для LLM
• **Feature Store:** единый источник фичей для training и serving предотвращает training-serving skew - главную причину тихой деградации
• **Monitoring:** data drift (PSI), concept drift, business metrics; shadow deployment и canary releases для безопасного rollout

Связанные темы

ML System Design объединяет все компоненты DL стека:

• Quantization и Pruning — Compression - обязательный шаг перед production deployment: INT8, TensorRT оптимизация снижают cost и latency serving
• Neural Architecture Search — Hardware-aware NAS встраивается в ML pipeline как автоматизированный шаг выбора архитектуры под production hardware constraints
• DL на собеседовании (FAANG) — System design для ML - одна из ключевых тем на senior ML engineer интервью в Google, Meta, Uber

Вопросы для размышления

• Feature Store разделяет offline (training) и online (serving) feature computation. Какие фичи сложно вычислять online (< 10ms), и как компании решают эту проблему через precomputation и approximate real-time?
• Shadow deployment позволяет тестировать новую модель без риска. Но что если тест требует пользовательского взаимодействия (рекомендации, которые пользователь кликает)? Как тогда A/B testing и multi-armed bandits решают эту проблему?
• Continuous training (переобучение на свежих данных ежедневно) решает concept drift, но создаёт новый риск: катастрофическое забывание и training instability. Какие механизмы защиты используют Netflix и Airbnb?

Связанные уроки

• dl-12 — Тренировочная инфраструктура строится на распределённом обучении
• dl-19 — Serving опирается на квантизацию для снижения задержки
• dl-21 — Знание дизайна систем помогает на собеседованиях по масштабированию
• ml-55-ml-system-design — Та же дисциплина сквозного дизайна ML-систем
• ml-47-model-monitoring — Мониторинг в проде ловит дрейф и деградацию
• ml-45-mlops-pipeline — Пайплайны и трекинг экспериментов структурируют процесс