Батч или real-time: выбор, который делают до того, как обучили модель
Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻
Обучить модель — это в лучшем случае половина работы ML-инженера. Дальше возникает вопрос, от которого многие новички просто отмахиваются: а как эта модель будет работать в проде?
Про сам факт деплоя обычно все помнят: «завернём в докер и поднимем сервис». А вот про то, что архитектура инференса модели — это отдельное инженерное решение с кучей нюансов, задумываются далеко не сразу. Разберём два типа инференса: real-time vs батч.
Батч-предсказания: посчитали заранее и положили в хранилище
Идея простая: раз в сутки (или в час, или в неделю) прогоняем модель на всей базе пользователей/объектов, складываем предсказания в таблицу или кэш — и когда они понадобятся, просто достаём готовое.
Где это отлично работает:
➖ Скоринг оттока клиентов раз в неделю;
➖ Ежедневные рассылки и запланированные рекламные кампании;
➖ Сегментация клиентов раз в месяц.
Обратите внимание, что в каждом из перечисленных кейсов задано некоторое регулярное расписание обновления — ничего не происходит в режиме онлайн.
✅ Плюсы такого подхода очевидны: дёшево, просто эксплуатировать, легко переобучать, никаких проблем со скоростью ответа сервиса — предсказание уже готово и ждёт где-нибудь в базе данных.
❌ Минус тоже очевиден: это свежесть предсказаний. Если пользователь зарегистрировался час назад, а батч прогонится только ночью, до утра его для системы «не существует». Также невозможно учитывать контекст «в прямом эфире»: что человек только что положил в корзину, что накликал, с какого устройства сейчас зашёл.
Real-time инференс: модель отвечает на запрос здесь и сейчас
Противоположный подход — модель поднята сервисом, к нему летят запросы, и на каждый нужно выдать предсказание за десятки, максимум сотни, миллисекунд. Именно так работают антифрод, поисковое ранжирование, онлайн-рекомендации или динамическое ценообразование.
И вот тут начинаются те самые «нюансы, о которых не рассказывают в курсах по ML»:
➖ Скорость ответа бьётся на бюджеты. У вас есть, скажем, 200 мс на весь ответ пользователю. Из них съест сеть 30 мс, бизнес-логика — 50 мс, достать фичи из feature store — 40 мс. И на саму модель остаётся 80 мс, а это уже жёсткое ограничение на архитектуру: тяжёлый бустинг на 5000 деревьях сюда просто не влезет.
➖ Фичи должны быть доступны онлайн. Если в трейне вы использовали «средний чек пользователя за последние 30 дней», в проде эту фичу надо где-то оперативно считать и хранить. Отсюда снова вырастает целый слой инфраструктуры.
➖ Динамическое разбиение на батчи. Отдельная история для нейросетей на GPU: запросы приходят по одному, но обрабатывать их так же по одному — сильное расточительство. Поэтому сервис копит их в очереди несколько миллисекунд и прогоняет через модель сразу пачкой. Это уже не про ML, а про инженерию, но без этого GPU-инференс просто нерентабелен.
➖ Отказоустойчивость. Модель может упасть, быть перегруженной, отвечать слишком долго. Что показывать пользователю в этом случае? Fallback на популярное или более простую эвристику? А может, закэшированное предсказание? Это тоже часть архитектуры, а не «додумаем потом».
Гибрид: чаще всего в проде именно он
В реальности чистый real-time и чистый батч встречаются реже, чем гибриды. Классика жанра — двухстадийные системы: тяжёлая модель раз в сутки считает эмбеддинги и отбирает кандидатов (батч), а лёгкий ранкер переставляет их онлайн с учётом свежего контекста (real-time). Или есть near-real-time: например, когда фичи обновляются через потоковые системы с задержкой в секунды (допустим, по триггеру), а предсказание считается по запросу.
Такой подход даёт лучшее из двух миров: тяжёлую логику выносим в офлайн, а онлайн оставляем ровно столько, сколько нужно для свежести.
Как выбирать?
Стоит задать себе несколько вопросов ещё до обучения модели:
❓ Насколько быстро предсказание должно реагировать на новые события? Если разница между «сейчас» и «через сутки» для бизнеса не важна, берите батч и не усложняйте.
❓ Сколько объектов надо скорить? Если базу в 100 млн пользователей раз в день, выбирайте батч; а если это редкие входящие запросы — можно и real-time.
❓ Какая пиковая нагрузка на сервис (RPS — количество запросов в секунду)? Порядка 10 запросов в секунду и порядка 10 000 — это разные архитектуры и разные затраты.
Сохраняйте, чтобы не потерять! ❤️
Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻
Обучить модель — это в лучшем случае половина работы ML-инженера. Дальше возникает вопрос, от которого многие новички просто отмахиваются: а как эта модель будет работать в проде?
Про сам факт деплоя обычно все помнят: «завернём в докер и поднимем сервис». А вот про то, что архитектура инференса модели — это отдельное инженерное решение с кучей нюансов, задумываются далеко не сразу. Разберём два типа инференса: real-time vs батч.
Батч-предсказания: посчитали заранее и положили в хранилище
Идея простая: раз в сутки (или в час, или в неделю) прогоняем модель на всей базе пользователей/объектов, складываем предсказания в таблицу или кэш — и когда они понадобятся, просто достаём готовое.
Где это отлично работает:
➖ Скоринг оттока клиентов раз в неделю;
➖ Ежедневные рассылки и запланированные рекламные кампании;
➖ Сегментация клиентов раз в месяц.
Обратите внимание, что в каждом из перечисленных кейсов задано некоторое регулярное расписание обновления — ничего не происходит в режиме онлайн.
✅ Плюсы такого подхода очевидны: дёшево, просто эксплуатировать, легко переобучать, никаких проблем со скоростью ответа сервиса — предсказание уже готово и ждёт где-нибудь в базе данных.
❌ Минус тоже очевиден: это свежесть предсказаний. Если пользователь зарегистрировался час назад, а батч прогонится только ночью, до утра его для системы «не существует». Также невозможно учитывать контекст «в прямом эфире»: что человек только что положил в корзину, что накликал, с какого устройства сейчас зашёл.
Real-time инференс: модель отвечает на запрос здесь и сейчас
Противоположный подход — модель поднята сервисом, к нему летят запросы, и на каждый нужно выдать предсказание за десятки, максимум сотни, миллисекунд. Именно так работают антифрод, поисковое ранжирование, онлайн-рекомендации или динамическое ценообразование.
И вот тут начинаются те самые «нюансы, о которых не рассказывают в курсах по ML»:
➖ Скорость ответа бьётся на бюджеты. У вас есть, скажем, 200 мс на весь ответ пользователю. Из них съест сеть 30 мс, бизнес-логика — 50 мс, достать фичи из feature store — 40 мс. И на саму модель остаётся 80 мс, а это уже жёсткое ограничение на архитектуру: тяжёлый бустинг на 5000 деревьях сюда просто не влезет.
➖ Фичи должны быть доступны онлайн. Если в трейне вы использовали «средний чек пользователя за последние 30 дней», в проде эту фичу надо где-то оперативно считать и хранить. Отсюда снова вырастает целый слой инфраструктуры.
➖ Динамическое разбиение на батчи. Отдельная история для нейросетей на GPU: запросы приходят по одному, но обрабатывать их так же по одному — сильное расточительство. Поэтому сервис копит их в очереди несколько миллисекунд и прогоняет через модель сразу пачкой. Это уже не про ML, а про инженерию, но без этого GPU-инференс просто нерентабелен.
➖ Отказоустойчивость. Модель может упасть, быть перегруженной, отвечать слишком долго. Что показывать пользователю в этом случае? Fallback на популярное или более простую эвристику? А может, закэшированное предсказание? Это тоже часть архитектуры, а не «додумаем потом».
Гибрид: чаще всего в проде именно он
В реальности чистый real-time и чистый батч встречаются реже, чем гибриды. Классика жанра — двухстадийные системы: тяжёлая модель раз в сутки считает эмбеддинги и отбирает кандидатов (батч), а лёгкий ранкер переставляет их онлайн с учётом свежего контекста (real-time). Или есть near-real-time: например, когда фичи обновляются через потоковые системы с задержкой в секунды (допустим, по триггеру), а предсказание считается по запросу.
Такой подход даёт лучшее из двух миров: тяжёлую логику выносим в офлайн, а онлайн оставляем ровно столько, сколько нужно для свежести.
Как выбирать?
Стоит задать себе несколько вопросов ещё до обучения модели:
❓ Насколько быстро предсказание должно реагировать на новые события? Если разница между «сейчас» и «через сутки» для бизнеса не важна, берите батч и не усложняйте.
❓ Сколько объектов надо скорить? Если базу в 100 млн пользователей раз в день, выбирайте батч; а если это редкие входящие запросы — можно и real-time.
❓ Какая пиковая нагрузка на сервис (RPS — количество запросов в секунду)? Порядка 10 запросов в секунду и порядка 10 000 — это разные архитектуры и разные затраты.
Понимание всего этого — то, что отличает ML-инженера от «человека, который умеет обучать модели». У нас на курсе есть отдельный модуль как раз про фишки production — тема сильно недооценённая, а без неё модель так и остаётся ноутбуком.
Сохраняйте, чтобы не потерять! ❤️