← Журнал · · Заметка
Почему мы строим отдельную Inference-платформу вместо расширения PaaS
Всем привет! Вышла моя новая статья о том, почему мы не стали допиливать PaaS под ML/LLM, а строим отдельную Inference-платформу на KServe.
Для контекста: PaaS в Авито - это внутренняя платформа, где разработчик выкатывает микросервис в один клик, а CI/CD, базы, логи, метрики и автоскейлинг уже есть из коробки. Заточена она под stateless-сервисы на Go, которым нужны только CPU и RAM. Подробнее про неё - в этой статье.
Коротко о главном:
1️⃣ Модель - это не «ещё один микросервис». Динамический батчинг (разница в утилизации GPU до 5-10x), очередь с backpressure, привязка к железу и FP8 - всё это не должно жить в бизнес-логике рядом с HTTP-роутингом.
2️⃣ GPU плохо дробится и стоит дорого. HPA по CPU/RAM для LLM бесполезен, скейлиться надо по очереди и KV-кэшу. А холодный старт с образом на 15-20 ГБ и весами в десятки ГБ может растянуться на десятки минут.
3️⃣ Допилить PaaS = кварталы разработки и риск для платформы, на которой живёт весь бэкенд. По факту внутри PaaS выросла бы та же отдельная платформа, только запутаннее.
4️⃣ Почему KServe. Сравнили с Seldon (LLM-фичи только в enterprise), Ray Serve и BentoML («k8s внутри k8s»), vLLM Production Stack (завязан на один движок). KServe оказался самым функциональным и для ML, и для LLM, плюс свежий LLMInferenceService на архитектуре llm-d.
5️⃣ Своя абстракция. Берём готовое ядро и добавляем обертку в виде сервиса контроллера: таким образом не завязываемся на конкретный open source и в случае смены ядра пользователи этого не заметят.
Платформа уже крутится на реальном трафике у нескольких команд, а цифры по экономии GPU-часов будут в следующих сериях, так что stay tuned)
Налетайте читать🔥 и пишите в комментах, как у вас: инференс живёт в общем PaaS или отдельно?