Serving Architecture — Архитектура инференса

Модель внутри приложения, отдельный сервис или платформа инференса — три уровня связанности.

Ключевые тезисы

Встроенная модель — минимальная задержка, но релиз модели связан с релизом приложения.
Отдельный сервис даёт независимые релизы и масштабирование ценой сетевого хопа.
Платформы (Triton, TorchServe, KServe) берут на себя батчинг, версии и метрики.

Тема также относится к главам:MLOpsДеплой

Подробный разбор

2 подтем — раскройте любую, чтобы увидеть объяснение, формулы, примеры и интерактивные графики.

Три варианта размещения

Связанность против гибкости.

Вариант	Плюсы	Минусы
В приложении (библиотека)	минимальная задержка, нет сети	релизы связаны, дублирование памяти
Отдельный сервис	независимые релизы и скейлинг	сетевой хоп, ещё один сервис в эксплуатации
Платформа инференса	батчинг, версии, метрики из коробки	новая инфраструктура, кривая обучения

На практике

Практичный путь: начать с отдельного сервиса на FastAPI, а к платформе (Triton, KServe) переходить, когда моделей станет много или потребуется GPU-батчинг.

Контракт API

Что фиксируется между сервисом и потребителем.

POST /v1/score
{
  "request_id": "a3f...",
  "features": {"age": 34, "region": "msk", "orders_30d": 7},
  "model": "churn@2026-08-15"          // явная версия, не "latest"
}
→ {"score": 0.183, "model": "churn@2026-08-15", "latency_ms": 12}

Версия модели указывается явно и возвращается в ответе — иначе разбор инцидента невозможен.
request_id связывает лог сервиса, лог приложения и последующую метку.
Отдельный эндпойнт для батча экономит накладные расходы при массовом скоринге.

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

Доставка модели в прод · Инференс и эксплуатация

Model Deployment98%

Деплой моделей · MLOps

Доставка модели пользователю: онлайн-сервис, батч-скоринг или встраивание в приложение.

CI/CD for ML85%

CI/CD для ML · MLOps

Автоматизация проверок и выката: тесты кода, тесты данных, обучение и релиз модели по одной кнопке.

Model Versioning85%

Версионирование моделей · MLOps

Каждая обученная модель — артефакт с версией, метриками и происхождением.

MLflow85%

MLflow · MLOps

Открытая платформа для трекинга, упаковки и регистрации моделей.

Production ML85%

ML в продакшене · Практика ML

Модель в проде — это сервис с SLA, мониторингом, версионированием и планом отката.

Requirements and SLA85%

Требования и SLA · Системный дизайн ML-сервисов

Числа, которые нужно зафиксировать до архитектуры: задержка, пропускная способность, доступность, стоимость запроса.

Caching85%

Кеширование · Системный дизайн ML-сервисов

Не считать то, что уже посчитано: кеш предсказаний, признаков и эмбеддингов.

Batching and Queues85%

Батчинг и очереди · Системный дизайн ML-сервисов

Собирать запросы в пачки, чтобы загрузить GPU, и сглаживать всплески нагрузки очередью.

Scaling85%

Масштабирование · Системный дизайн ML-сервисов

Горизонтальное и вертикальное масштабирование инференса и правильные метрики автоскейлинга.

GPU Inference85%

GPU-инференс · Системный дизайн ML-сервисов

Как выжать из видеокарты пропускную способность и не переплачивать.

Reliability85%

Отказоустойчивость · Системный дизайн ML-сервисов

Что происходит, когда модель недоступна, отвечает медленно или выдаёт мусор.

Observability85%

Наблюдаемость · Системный дизайн ML-сервисов

Логи, метрики и трассировки, по которым можно восстановить, что произошло с конкретным запросом.

Cost Model85%

Экономика сервиса · Системный дизайн ML-сервисов

Стоимость одного предсказания и точка, где модель перестаёт окупаться.

LLM Serving85%

Обслуживание LLM · Системный дизайн ML-сервисов

Отдельная инженерная дисциплина: KV-кеш, непрерывный батчинг, потоковая отдача и контроль стоимости.

Monitoring85%

Мониторинг · MLOps

Наблюдение за инфраструктурой, данными и качеством предсказаний после релиза.

Docker85%

Docker · MLOps

Контейнеризация фиксирует окружение целиком: код, зависимости, системные библиотеки.

Kubernetes85%

Kubernetes · MLOps

Оркестрация контейнеров: масштабирование, самовосстановление, обновления без простоя.