Стратегии деплоя ML-модели на собеседовании Data Scientist

Зачем это спрашивают

Обучить модель — половина дела. На собесе Data Scientist уровня middle и выше почти всегда проверяют, понимаете ли вы, как модель попадёт в продакшн и начнёт приносить предсказания реальным пользователям. Вопрос звучит примерно так: «Вы обучили модель — как будете её деплоить?» За ним стоит проверка того, умеете ли вы сопоставлять требования задачи (задержка, пропускная способность, приватность, частота обновлений) со способом развёртывания.

Универсально «правильной» стратегии нет — есть выбор под контекст. Ниже пять основных подходов: онлайн через REST API, пакетный (batch), встроенный (embedded), на устройстве (edge/mobile) и потоковый (streaming). Ключевой навык — не перечислить их, а объяснить компромиссы между задержкой и пропускной способностью и обосновать выбор.

REST API

Самый распространённый способ онлайн-инференса: модель заворачивается в HTTP-сервис, который принимает признаки и возвращает предсказание в ответ на запрос.

POST /predict {features: ...} → {prediction: ...}

Инструменты. FastAPI для лёгкого сервиса на Python; специализированные серверы инференса — NVIDIA Triton, TorchServe, TensorFlow Serving, BentoML — когда нужна батч-обработка запросов на сервере, работа с GPU и управление версиями моделей из коробки.

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

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

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

Batch inference

Предсказания считаются не по одному запросу, а пачками, асинхронно, по расписанию.

Spark / dbt-ml / SageMaker Batch Transform.
Читаем 1M записей → предсказываем → пишем результаты в таблицу.

Плюсы. Высокая пропускная способность и эффективность: обработать миллион записей одной задачей дешевле, чем миллион отдельных HTTP-запросов. Проще инфраструктура — не нужен постоянно работающий низколатентный сервис.

Минусы. Не в реальном времени: предсказание доступно только после прогона задачи. Между появлением новых данных и готовым скором проходит время (от минут до суток).

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

Embedded (в приложении)

Модель загружается прямо в процесс приложения и вызывается локально — без обращения к внешнему сервису.

model = load_model('model.pkl')
prediction = model.predict(x)  # инференс в том же процессе

Плюсы. Нет сетевого вызова — минимальная задержка и на одну точку отказа меньше. Не нужно поднимать и обслуживать отдельный сервис инференса.

Минусы. Обновление модели требует передеплоя самого приложения — вы больше не выкатываете модель независимо. Модель занимает ресурсы приложения (память, CPU), и версии модели жёстко связаны с версиями приложения.

Для портируемости часто используют формат ONNX или нативные библиотеки, чтобы модель, обученную на Python, можно было исполнять внутри сервиса на другом языке.

Edge и мобильные устройства

Инференс выполняется прямо на устройстве пользователя — телефоне, IoT-датчике, браузере.

• TensorFlow Lite — облегчённый рантайм для мобильных и встраиваемых устройств.
• Core ML — фреймворк Apple для инференса на iOS с использованием Neural Engine.
• ONNX Runtime Mobile — кросс-платформенный рантайм для запуска ONNX-моделей на разных устройствах.
• llama.cpp — запуск LLM на CPU и на устройствах без мощного GPU.

Плюсы. Работа офлайн без соединения с сервером, приватность (данные не покидают устройство) и минимальная задержка — нет сетевого раунд-трипа.

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

Подходит, когда важны приватность и офлайн: распознавание на камере, голосовые функции, персонализация, которую нежелательно гонять на сервер.

Streaming

Модель встроена в потоковый конвейер и предсказывает по мере поступления событий, а не по запросу и не по расписанию.

Kafka topic → Spark / Flink → предсказание → выходной топик / БД

Плюсы. Непрерывная обработка с низкой задержкой: событие пришло — сразу посчитали и отдали дальше. Хорошо ложится на event-driven архитектуру.

Минусы. Сложная инфраструктура: нужно поднимать и обслуживать стриминговый движок (Spark Structured Streaming, Flink), думать про гарантии доставки, обработку опоздавших событий и состояние.

Классические сценарии — антифрод (решение по транзакции за миллисекунды) и рекомендации в реальном времени, реагирующие на действия пользователя прямо сейчас.

Как выбрать стратегию

На собесе выигрывает тот, кто выбирает осознанно. Опорные вопросы:

• Нужен ли ответ в реальном времени? Да, по запросу пользователя — REST API. Да, по потоку событий — streaming. Нет — batch.
• Каков объём и профиль нагрузки? Много данных редкими прогонами — batch эффективнее. Много одиночных запросов с жёстким SLA по задержке — онлайн-сервис.
• Важны ли приватность и офлайн? Тогда edge/on-device, несмотря на ограничения по размеру модели.
• Как часто обновляется модель? Частые обновления проще катить через отдельный сервис (REST), чем через передеплой приложения (embedded/edge).

Базовый компромисс, который стоит проговорить вслух: онлайн-подходы дают низкую задержку ценой инфраструктурной сложности и стоимости на запрос; batch даёт высокую пропускную способность ценой свежести. Хороший ответ — не «я всегда делаю REST», а «зависит от требований, и вот почему здесь подходит вот это».

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

Предлагать REST API на любую задачу. Для ночного скоринга миллионов записей онлайн-сервис — дорого и бессмысленно; там уместен batch.

Забывать про latency vs throughput. Собеседующий часто именно этот компромисс и проверяет. Ответ без упоминания задержки и пропускной способности звучит поверхностно.

Игнорировать обновление и версионирование модели. Как выкатывать новую версию, как откатываться, как не сломать клиентов — часть деплоя, а не деталь. Про это стоит сказать самому.

Обещать real-time там, где инфраструктуры на это нет. Streaming и низколатентный онлайн стоят денег и усилий; называть их без оценки сложности — красный флаг.

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

• Inference optimization для DS
• ML latency optimization для DS
• Model versioning для DS
• Canary и shadow deployment ML для DS
• Подготовка к собесу Data Scientist

FAQ

Когда batch лучше онлайн-инференса?

Когда бизнес устраивает свежесть предсказания «до следующего прогона»: ночной скоринг, рассылки, регулярные отчёты, предрасчёт рекомендаций. Batch эффективнее по стоимости и пропускной способности — обработать пачку записей одной задачей дешевле, чем гонять миллион отдельных HTTP-запросов. Онлайн нужен только там, где ответ требуется в момент запроса.

В чём разница между embedded и edge-деплоем?

Embedded — модель внутри процесса вашего серверного приложения, чтобы убрать сетевой вызов к внешнему сервису. Edge — модель на устройстве пользователя (телефон, IoT, браузер) ради офлайна и приватности. Оба избегают сетевого раунд-трипа, но edge дополнительно ограничен ресурсами устройства и разбросом железа.

Как деплоить, если нужны и низкая задержка, и офлайн?

Это сценарий для on-device (edge) инференса: TensorFlow Lite, Core ML или ONNX Runtime Mobile. Данные не покидают устройство, соединение не нужно, задержка минимальна. Плата — модель приходится ужимать (квантизация, дистилляция) и учитывать разброс производительности устройств.

Чем streaming-инференс отличается от REST API?

REST API считает предсказание в ответ на запрос — модель пассивна и ждёт вызова. Streaming встроен в конвейер и предсказывает по мере поступления событий из потока (Kafka, Pulsar), обрабатываемого Spark или Flink. Streaming уместен для непрерывных потоков (антифрод, real-time рекомендации), но требует более сложной инфраструктуры.

Это официальная информация?

Нет. Статья основана на общепринятых практиках деплоя ML-моделей. Конкретные формулировки вопросов и ожидаемая глубина зависят от компании, команды и уровня позиции.

Тренируйте Data Science — откройте тренажёр с 1500+ вопросами для собесов.