Обзор serving-инструментов

От самописного FastAPI до специализированного Triton — спектр инструментов под разные задачи сервинга.

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

Зачем специализированные инструменты

Обернуть модель в HTTP можно и руками. Но в проде нужны батчинг запросов, версионирование, метрики, GPU-эффективность, горячая подмена модели. Писать это с нуля каждый раз — расточительно. Специализированные serving-инструменты дают эту обвязку из коробки; вопрос лишь в том, сколько вам нужно.

Полезно понимать ось выбора: чем тяжелее модель и выше нагрузка, тем больше работы стоит отдать инструменту, а не писать самому. Для одной лёгкой табличной модели с десятком запросов в секунду самодельный FastAPI-эндпоинт идеален — полный контроль, никакой лишней магии, легко отлаживать. Но как только моделей становится десятки, появляется GPU, а трафик измеряется тысячами запросов в секунду, самописный батчинг и версионирование превращаются в источник тонких багов и потерянной производительности. Здесь специализированный сервер окупается: то, на что у вас ушли бы недели, в нём уже отлажено и оптимизировано. Поэтому правильный вопрос не «какой инструмент лучший», а «какой уровень обвязки нужен именно моей задаче».

FastAPI: гибкость и простота

Не ML-инструмент, а быстрый Python-веб-фреймворк. Вы пишете эндпоинт сами: загрузили модель, описали схему запроса, вызвали predict. Максимум контроля и гибкости, минимум магии. Идеален для одной-двух моделей и кастомной логики, но батчинг и метрики придётся добавлять самому.

BentoML: упаковка и стандартизация

Фреймворк, заточенный под сервинг ML. Описываете сервис декларативно, BentoML собирает «бенто» — стандартизированный артефакт с моделью, кодом и зависимостями, который превращается в Docker-образ. Даёт адаптивный батчинг, версии и удобный деплой. Хорош, когда моделей много и нужна единая фабрика образов.

NVIDIA Triton: производительность на GPU

Высокопроизводительный сервер для тяжёлого инференса. Поддерживает много фреймворков (ONNX, TensorRT, PyTorch, TF), динамический батчинг, конкурентное исполнение нескольких моделей на одном GPU, model ensembles. Выбирают, когда важны максимальная пропускная способность и эффективность GPU.

TensorFlow Serving: для экосистемы TF

Зрелый, производительный сервер для моделей в формате TensorFlow SavedModel. Горячая загрузка версий, батчинг, gRPC/REST. Естественный выбор, если стек целиком на TensorFlow.

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

Все эти инструменты решают один контракт: «запрос → препроцессинг → инференс → постпроцессинг → ответ». Различаются глубиной оптимизации. FastAPI оставляет всё на вас. BentoML добавляет адаптивный батчинг (копит запросы несколько мс и шлёт пачкой) и фабрику образов. Triton и TF Serving идут дальше: держат модель в памяти GPU, объединяют запросы в один батч для эффективной матричной математики и обслуживают несколько версий одновременно. Чем тяжелее модель и выше нагрузка, тем больше выигрыш специализированного сервера.

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

• Тащить Triton под одну лёгкую модель. Оверинжиниринг; FastAPI справится проще.
• Писать на FastAPI то, что давно решено в BentoML/Triton. Самописный батчинг и версии — источник багов.
• Игнорировать формат модели. Triton любит ONNX/TensorRT; неоптимизированная модель не раскроет его силу.

Итог

• Serving-инструменты оборачивают модель в сервис, забирая на себя батчинг, версии и метрики в разной степени.
• FastAPI — гибкость и контроль; BentoML — стандартизация и упаковка; Triton — производительность на GPU; TF Serving — экосистема TF.
• Выбор зависит от числа моделей, нагрузки и наличия GPU — не берите тяжёлый сервер под лёгкую задачу.