Способы развёртывания моделей

Одна и та же модель доставляется пользователю четырьмя принципиально разными способами.

Способ развёртывания — это паттерн доставки предсказаний: синхронно по запросу (REST), пачкой по расписанию (батч), на потоке событий (стриминг) или прямо на устройстве (edge).

Почему способ важен

Выбор паттерна определяет латентность, стоимость и сложность. Рекомендации в реальном времени и ночной скоринг всей базы — это разные миры, и пытаться решить второе через первое — дорого и бессмысленно. Сначала определите требование к задержке и частоте, потом выбирайте паттерн.

1. Онлайн (REST API)

Модель за HTTP-эндпоинтом отвечает синхронно на каждый запрос за миллисекунды. Подходит, когда предсказание нужно «здесь и сейчас»: антифрод в момент платежа, рекомендация при заходе на страницу.

клиент --(HTTP POST {features})--> [сервис модели] --(JSON {prediction})--> клиент
                                       ~10-50 мс

2. Батч (offline)

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

[cron 03:00] --> читаем всю таблицу --> predict() пачкой --> пишем в БД --> утром готово

3. Стриминг

Модель подключена к потоку событий (Kafka, Kinesis) и скорит их по мере поступления. Подходит для непрерывных потоков: детекция аномалий в логах, обогащение событий в реальном времени без явного запроса от клиента.

4. Edge

Модель работает прямо на устройстве пользователя: телефон, камера, IoT. Подходит, когда нельзя гонять данные в облако (приватность, нет сети) или нужна нулевая сетевая задержка: распознавание лиц на телефоне, дефекты на конвейере. Требует лёгких моделей (квантизация, дистилляция) и форматов вроде TFLite/ONNX Runtime.

Сравнение

Как работает под капотом

Под капотом различие — в том, кто инициирует инференс и где живёт модель. В онлайне инициатор — клиентский запрос, модель в облаке за балансировщиком. В батче — планировщик, модель в задании-обработчике. В стриминге — событие из брокера, модель в консьюмере. На edge — само устройство, модель локально. От этого зависит вся инфраструктура: REST требует автоскейлинга под пики, батч — оркестратора заданий, стриминг — consumer-группы, edge — пайплайна доставки моделей на устройства.

Частые ошибки

• Делать REST там, где хватит батча. Реальное время дорого; если ответ нужен «к утру» — считайте пачкой.
• Гнать тяжёлую модель на edge без оптимизации. Без квантизации/дистилляции она не влезет в устройство.
• Игнорировать пики в онлайне. Без автоскейлинга сервис ляжет в час нагрузки.

Итог

• Четыре паттерна: онлайн REST (синхронно), батч (по расписанию), стриминг (по событию), edge (на устройстве).
• Выбор диктуют требования к задержке, частоте и приватности, а не мода.
• Каждый паттерн тянет за собой свою инфраструктуру — это решают заранее, а не после.