LLM serving платформа на vLLM и Triton решает задачу унификации инференса и снижает разрыв между экспериментом и продакшеном.
Система упёрлась в классическую проблему масштабирования ML в продакшене. Большинство команд используют hosted API, но при росте нагрузки и требований к latency и контролю это становится узким местом. В данном случае инференс встроен прямо в существующую JVM-based serving систему. Она уже обрабатывает routing, A/B тесты, feature fetching и post-processing. Добавление LLM в этот контур создало давление на архитектуру: разные модели, разные требования к ресурсам, и необходимость сохранять единый API без «особых случаев».
Решение было прагматичным: унифицировать весь инференс через общий слой и разделить выполнение по типу модели. Лёгкие CPU-модели запускаются in-process, чтобы избежать сетевых задержек (latency). Тяжёлые модели выносятся в GPU-backed сервис Model Scoring Service. В качестве backend используется Triton Inference Server, который отвечает за batching и GPU scheduling. Поверх него — Java control plane с управлением деплоями, версионированием и autoscaling. Ключевой выбор — переход на vLLM как основной inference engine. Причина — не только производительность, но и соответствие реальному workload: embedding, prefill-only inference, autoregressive decoding и кастомные ограничения генерации.
На уровне реализации архитектура строится вокруг единого API. Все модели, включая LLM, доступны через gRPC интерфейс. Параллельно добавлен OpenAI-compatible API для интеграции с экосистемой. Это снижает стоимость миграции: переход от hosted моделей к self-hosted почти не требует изменений кода. Однако интеграция выявила скрытую проблему. Параметр response_format, заявленный в API, терялся до уровня vLLM. В результате система могла возвращать некорректный JSON без ошибок. Это устранили патчем frontend-слоя, прокидывая параметры в guided decoding. Этот кейс показывает типичный риск: API-совместимость не гарантирует семантическую корректность.
Отдельный слой сложности — packaging и rollout. Triton поддерживает разные способы упаковки моделей, и выбор влияет на связность системы. Сильная связка между моделью и frontend усложняет обновления. Для деплоя используется zero-downtime стратегия с учётом того, что GPU-инстансы поднимаются медленнее. Рекомендуется делать модели version-agnostic, чтобы использовать более дешёвые стратегии rollout. Versioned-подход остаётся только для breaking changes. Это компромисс между гибкостью и операционной стабильностью.
В продакшене проявились проблемы, которые не видны на этапе дизайна. Первая — observability. vLLM и Triton публикуют метрики раздельно, и часть ключевых сигналов теряется. Например, token throughput и KV cache utilization. Решение — объединяющий proxy, который агрегирует метрики в единый endpoint. Это позволяет сохранить существующие dashboards без изменений. Вторая проблема — constrained decoding. Перенос бизнес-логики внутрь decode loop снижает издержки на повторные запросы, но создаёт нагрузку на CPU.
Изначальная реализация constrained decoding на Python упёрлась в GIL. Логика выполнялась последовательно для каждого запроса, и latency рос линейно с размером batch. Это типичный пример, когда GPU эффективно батчит вычисления, но CPU становится bottleneck. Решение стало возможным только после перехода на vLLM V1. Обработка logits переместилась на уровень batch. Критический код переписан на C++ с multi-threading. Это устранило зависимость latency от размера batch и стабилизировало throughput.
В результате система стала более предсказуемой под нагрузкой, хотя точные метрики не раскрываются. Главный эффект — выравнивание пути от эксперимента к продакшену и снижение количества архитектурных исключений. Однако цена — рост сложности control plane и tighter coupling с инфраструктурой Triton и vLLM. Это осознанный trade-off: меньше гибкости на уровне компонентов, больше — на уровне всей платформы.
Такой подход отражает общий тренд индустрии. Компании переходят от использования внешних LLM API к self-hosted inference, чтобы контролировать latency, стоимость и данные. Но ключевые сложности лежат не в модели, а в деталях: API-совместимость, метрики, rollout и поведение под реальной нагрузкой.