Inference Extension для Kubernetes Gateway API ускоряет и оптимизирует маршрутизацию LLM‑запросов

Kubernetes Gateway API получил практическое расширение для маршрутизации, ориентированной на состояние инференса: Inference Extension. Оно выбирает целевой под для LLM‑запроса не по круговому распределению, а по набору сигналов готовности, что обещает более эффективное использование GPU/CPU и более предсказуемую пропускную способность при обслуживании моделей. При обработке запроса шлюз Gateway API сначала валидирует его согласно правилам HTTPRoute и извлекает имя целевой модели — из пути, заголовков или с помощью Body‑Based Router (BBR), когда модель указана в JSON‑поле тела запроса. После определения модели шлюз соотносит её с объектом InferencePool, который представляет набор подов‑серверов для этой модели.

Точная подборка пода возлагается на отдельный компонент Endpoint Picker (EPP). Шлюз приостанавливает маршрутизацию и запрашивает EPP; тот опрашивает состояние бэкенд‑подов и применяет flow control, учитывая целый набор сигналов перед выбором конечной точки. Таким образом запрос направляется на наиболее подготовленный под, а не на любой доступный сервер. В качестве ключевых сигналов для принятия решения авторы выделяют состояние KV‑кэша, доступность LoRA‑адаптеров и длину очереди на поде. Эти показатели позволяют определить, понадобится ли дополнительная подготовка модели (например, заполнение кэша или подключение адаптера) — и тем самым избежать лишних задержек и перерасхода ресурсов.

Авторы разбивают жизненный цикл запроса на три фазы — начальная маршрутизация шлюзом, выбор конечной точки EPP и фактическое обслуживание модели — и настаивают на мониторинге каждой фазы отдельно. Рекомендации включают слежение за метриками KV‑кэша, доступностью LoRA, длиной очереди и показателями flow control, чтобы оперативно выявлять узкие места. Переход на Gateway API предоставляет более мощную платформу для таких inference‑aware паттернов, тогда как стандартные HTTP‑балансировщики, ориентированные на равномерное распределение (например, round‑robin), могут «слепо» направлять трафик и терять преимущества предсказуемой загрузки. Для команд, разворачивающих LLM в Kubernetes, это путь к снижению простаивания оборудования и повышению плотности использования кластера.

Практическое значение для инженеров — снижение латентности и рост пропускной способности без изменения моделей: если запрос попадает на под с готовым KV‑кешем или подключённым LoRA‑адаптером, не требуется повторная подготовка, что сокращает время ответа. Для надёжной эксплуатации необходимо корректно настроить Inference Extension и систему мониторинга по всем упомянутым сигналам и фазам.