Google меняет подход к балансировке запросов для LLM, учитывая повторное использование контекста
В системах с большими языковыми моделями место, где выполняется запрос, напрямую влияет на стоимость и задержку. Представим два запроса с одинаковым длинным контекстом: блок примерно из 2,000 токенов, где лежат политика, схема вывода, правила ранжирования и примеры. Сначала модель читает этот префикс и формирует KV cache. Такой внутренний кэш нужен, чтобы не пересчитывать уже обработанные токены.
Проблема появляется на уровне балансировки нагрузки. Второй запрос может попасть на другую реплику сервиса, где нужного кэша нет. В итоге те же 2,000 токенов приходится прогонять заново, даже если различия между запросами сводятся к последним 50 токенам пользовательского ввода.
Как отмечается в материале Towards AI, традиционные алгоритмы вроде round robin или least connections рассматривают запросы как взаимозаменяемые. Для многих stateless‑сервисов это нормально. Но у LLM часть вычислений имеет смысл повторно использовать только на том пути обслуживания, где уже появился соответствующий KV cache. Если следующий запрос уходит на другую реплику, ранее выполненная работа фактически пропадает.
В Google предложили учитывать это при маршрутизации. В GKE Inference Gateway запрос можно отправить на ту реплику, где уже существует совпадающий кэш префикса. Это уменьшает объём повторных вычислений на этапе prefill, фазе, когда модель читает промпт перед генерацией первого токена.
Маршрутизацией занимается компонент llm-d Endpoint Picker. Он использует мультицелевую политику и при выборе бэкенда смотрит на несколько параметров: KV cache hit rate, количество inflight‑запросов, глубину очереди.
Выигрыш особенно заметен там, где многие запросы опираются на длинные и стабильные префиксы. Например, в задачах scoring, tagging, extraction или при retrieval‑heavy нагрузках. В таких сценариях значительная часть времени и затрат уходит именно на этап prefill, а не на последующую генерацию токенов.
Ключевые факты
В примере два запроса к LLM содержат одинаковый блок контекста в 2 000 токенов и различаются только последними 50 токенами с пользовательским запросом.
При обработке промпта модель создаёт KV cache, внутреннее состояние, позволяющее не пересчитывать уже обработанные токены при повторном использовании того же префикса.
Обычный балансировщик может отправить второй запрос на другую реплику с более короткой очередью, из‑за чего ей приходится заново обрабатывать те же 2 000 токенов.
Google GKE Inference Gateway маршрутизирует запросы с учётом повторного использования префиксного кэша и использует llm-d Endpoint Picker, который учитывает hit rate KV cache, число inflight‑запросов и глубину очереди при выборе реплики.