Авито строит отдельную платформу для вывода моделей в производство: почему PaaS не справляется с задачами LLM

# Зачем Авито нужна своя Inference-платформа для ML/LLM-сервисов

Крупные технологические компании часто сталкиваются с дилеммой: использовать универсальную инфраструктуру или создавать специализированные решения. AvitoTech выбрал второй путь, объяснив, почему интеграция сложных моделей искусственного интеллекта в стандартную PaaS-среду привела бы к снижению производительности и стабильности всей системы.

PaaS: эффективность для классических микросервисов

Sреда PaaS (Platform as a Service), разработанная в Авито, была создана для решения задач веб-разработки. Она автоматизирует развертывание, CI/CD, логирование и автоскейлинг. Эта модель идеально подходит для stateless-сервисов, написанных преимущественно на Go, где ресурсы потребления (CPU и оперативная память) предсказуемы и линейны.

Однако попытка «натянуть» эту архитектуру на задачи машинного обучения (ML) и больших языковых моделей (LLM) выявила фундаментальные несоответствия. Для классического веб-сервиса достаточно добавить несколько реплик при росте нагрузки. В случае с инференсом моделей картина кардинально меняется.

Почему ML и LLM — это не просто «ещё один сервис»

Различие между обычным бэкендом и ML-инференсом выходит далеко за рамки необходимости использования графических процессоров (GPU). Это различие затрагивает весь жизненный цикл работы системы и требует специализированного подхода к архитектуре.

1. Динамическое батчинг и эффективность GPU. Экономическая эффективность работы GPU зависит от его загрузки (throughput). При обработке одиночных запросов (batch=1) видеокарта простаивает, так как узким местом становится пропускная способность памяти, а не вычислительная мощность. Динамическое батчинг позволяет объединять запросы разных клиентов в один проход вычислений, что повышает утилизацию оборудования в 5–10 раз. Реализация таких алгоритмов на чистом Python в рамках общей PaaS сталкивается с ограничениями интерпретатора (GIL), что требует переписывания базовых компонентов платформы.

2. Управление очередями и защита от сбоев. Для стабильной работы необходима очередь запросов с механизмом обратного давления (backpressure). Без неё система при пиковой нагрузке либо захлёбывается потоками, либо начинает отвечать с неприемлемой задержкой. Очередь трансформирует перегрузку в управляемую задержку, обеспечивая соблюдение SLA даже в моменты резкого скачка трафика.

3. Сложность управления ресурсами. Модель ML может занимать сотни мегабайт, но в памяти она работает иначе, чем статические веб-приложения. При обновлении модели веса могут достигать десятков гигабайт. Процесс «прогрева» модели — загрузки библиотек на видеокарту, загрузки весов и инициализации движка — занимает десятки минут. Это делает стандартный автоматический скейлинг по CPU/RAM бесполезным для ML-задач, так как добавление реплики не мгновенно не увеличит пропускную способность.

4. Разделение ответственности. В классической архитектуре бизнес-логика и инфраструктура неразрывны. Для ML-сервисов критически важно отделение бизнес-логики от слоя инференса. Это позволяет использовать различные движки (vLLM, Triton, TensorFlow Serving) и архитектуры железа без переписывания кода основного приложения.

Выбор решения: PaaS против отдельной платформы

Команда инженеров Авито проанализировала два сценария: доработка существующей PaaS и создание отдельной специализированной платформы.

| Критерий | Доработка PaaS | Отдельная Inference-платформа | | :--- | :--- | :--- | | Воздействие на систему | Каждая доработка рискует стабильностью всей бэкенд-системы, на которой работают тысячи сервисов. | Ограничивает риски только областью ML/LLM, сохраняя целостность основной платформы. | | Архитектура | Требует создания сложных подмодулей внутри монолитной инфраструктуры, что усложняет поддержку. | Позволяет спроектировать инструменты строго под требования нагрузок ML/LLM. | | Время реализации | Требует нескольких кварталов разработки для внедрения специфичных фич (батчинг, GPU-скейлинг). | Быстрее благодаря использованию готовых open-source решений. | | Экспертность | Разработчики PaaS имеют компетенции в CPU-средах, но не всегда обладают глубоким опытом MLOps. | Позволяет объединить усилия команд ML Platform и экспертов по инференсу. |

Решение было принято в пользу создания отдельной платформы. Это позволяет избежать компромиссов в архитектуре общей системы и фокусироваться на специфических требованиях машинного обучения.

Базовая архитектура на базе open-source

Вместо разработки инфраструктуры с нуля было принято решение использовать open-source ядро KServe. Это популярный оператор Kubernetes, который предоставляет стандартный интерфейс для описания моделей (Custom Resource InferenceService) и автоматизирует запуск, масштабирование и управление ими.

KServe поддерживает интеграцию с различными движками инференса, такими как vLLM, Triton и TorchServe. Выбор открытого решения позволил:

* Использовать уже отлаженное функциональное ядро, которое разрабатывается активным сообществом. * Сократить время выхода продукта на стабильную версию. * Обеспечить быстрое внедрение новых функций, появляющихся в индустрии (например, специфичные механизмы кэширования KV-cache для LLM).

Адаптация KServe под потребности Авито включала разработку собственных операторов для размещения моделей на GPU-пулах с учетом специфики дробления видеокарт (MIG, TimeSlicing) и внедрение сложного механизма автоскейлинга, реагирующего на реальные метрики загрузки GPU, а не только CPU.

Статус проекта

Разработка платформы ведется с начала текущего года. На данный момент система уже используется несколькими внутренними клиентами и проходит обкатку на реальном трафике. Ожидается, что внедрение позволит существенно снизить затраты на вычислительные ресурсы за счет оптимизации использования GPU и сократить время вывода новых моделей в эксплуатацию, сделав процесс инференса столь же простым и предсказуемым, как развертывание обычного веб-сервиса.