КабинетПоиск
Системный дизайн ML-сервисов

Serving Architecture

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

актуальноТекущий рабочий стандарт

Направления: Инженерия ИИ · Инференс моделей

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

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

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

Какую задачу решает

Способ доставки предсказаний определяется не моделью, а тем, когда результат нужен. Если решение принимается в действия пользователя — нужен онлайн-сервис. Если результат используется завтра — батчевый расчёт по расписанию на порядки дешевле и проще. Между ними лежат потоковая обработка и предрасчёт популярных случаев.

Выбор влияет на всё: батчевый расчёт снимает требования по задержке и позволяет использовать сколь угодно тяжёлые модели; онлайн-сервис требует в реальном времени, , автомасштабирования и продуманного поведения при отказе. Ошибка в выборе режима обходится дороже, чем ошибка в выборе модели.

Проверка, нужен ли онлайн

Задайте один вопрос: зависит ли предсказание от информации, появившейся за последние минуты? Скоринг оттока по истории за месяц — не зависит, значит . Рекомендация после просмотра трёх товаров в этой сессии — зависит, значит онлайн. Промежуточный случай: предрасчёт базовой части батчем и лёгкая онлайн-корректировка по контексту сессии. Такая гибридная схема часто даёт 90% выигрыша онлайна за 20% его сложности.

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

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

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

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

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 связывает лог сервиса, лог приложения и последующую метку.
  • Отдельный эндпойнт для экономит накладные расходы при массовом скоринге.

Где применяется

  • Скоринг клиентской базы ночью: результат в таблице, никаких требований к задержке.
  • Персонализация выдачиОнлайн: контекст сессии известен только в запроса.
  • АнтифродОнлайн с жёстким : решение нужно до подтверждения операции.
  • Рекомендации в рассылке с предрасчётом: пользователей миллионы, а время не критично.

Плюсы, минусы и альтернативы

Плюсы

  • Правильно выбранный режим кратно упрощает систему.
  • закрывает большую часть задач за малую долю стоимости онлайна.
  • Явный контракт делает возможной независимую разработку и обновление.

Минусы

  • Онлайн требует полноценной инженерии: масштабирование, кэш, отказоустойчивость.
  • не подходит там, где важен свежий контекст.
  • Смена режима на позднем этапе означает переделку.

Брать, если

  • Онлайн — когда контекст известен только в запроса.
  • — когда предсказание можно посчитать заранее.

Не брать, если

  • Не стройте онлайн-сервис, если результат используется раз в сутки: это дороже без выигрыша.

Чем заменяют

Requirements and SLAактуальноТребования и SLA · Системный дизайн ML-сервисовСначала нужны требования: они и определяют режим.Batching and QueuesактуальноБатчинг и очереди · Системный дизайн ML-сервисовОнлайн выбран — дальше вопрос пропускной способности.CachingактуальноКеширование · Системный дизайн ML-сервисовНагрузка велика, а запросы повторяются.
Тема также относится к главам:MLOpsДеплой

Видеолекции

Записи университетских курсов, где эта тема звучит. Где у записи есть тайм-коды, ссылка открывает её с нужной секунды; где их не проставили — с начала.

1:27:04Процесс инференса и результатыГенеративные модели · Лекция «Диффузионные модели» · 1 ч 31 минс началаУскорение вычислений и инференсПрикладной MLOps · Лекция · 2 ч 52 мин

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

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

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

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

Кому эта тема нужна

Профильная компетенция для ролей: ML Engineer, MLOps-инженер, Продуктовый инженер, Инженер рекомендаций.

Усиливает профиль: NLP-инженер, LLM-инженер, CV-инженер, Инженер речи.

Спрашивают на собеседовании: Т-Банк — Рекомендации и персонализация, VK — Лента и рекомендации, Ozon — Поиск и рекомендации, МТС — Речь и разговорный ИИ, Lamoda — Рекомендации и поиск, Самокат — Логистика и сроки доставки, HeadHunter — Матчинг и рекомендации, Циан — Поиск, ранжирование и достоверность, Selectel — Платформа инференса.

Добавить в учебную программу
Проверить себя

Тема встречается в тестах по направлениям — ошибки приведут обратно на эту страницу.

Тест: Рекомендательные системы24Тест: Дизайн ML-систем22
Тема в работе целиком

Разбор архитектуры, где эта тема — один из кирпичей: требования, развилки, цифры и режимы отказа.

Кейс: Рекомендации за 50 мсКейс: Поиск, который находит артикул
Следующий шагПроверить себя: Рекомендательные системыТема встречается в этом тесте 1 раз. Ошибка приведёт обратно на эту страницу — с объяснением, что именно не сошлось.Перейти →
← Requirements and SLAOnline and Offline Features →

Глава «Системный дизайн ML-сервисов» последний раз правилась . Нашли ошибку — напишите.