Трехуровневая архитектура маршрутизации LLM от Microsoft для AI-агентов на AKS

Microsoft опубликовала эталонную архитектуру для маршрутизации трафика агентов на Azure Kubernetes Service (AKS). Предложенный подход разбивает задачу на три ключевых решения: какая модель отвечает на запрос, как управляется вызов и какая GPU-реплика его обрабатывает.

01Ключевые компоненты

Архитектура объединяет три открытых компонента:

• Kubernetes Gateway API Inference Extension — для балансировки нагрузки;
• agentgateway — AI-прокси;
• RouteLLM — для семантической маршрутизации.

Все три компонента подключаются к единому OpenAI-совместимому эндпоинту.

02Мотивация: агентные нагрузки, а не чат

Основной стимул — агентные рабочие нагрузки, а не обычные чат-сценарии. Одна задача агента может запускать сотни LLM-вызовов в цикле «планирование — действие — наблюдение». Большинство таких вызовов (заполнение аргументов инструмента, проверка «да/нет», суммаризация) не требуют frontier-модели. Отправка каждого вызова в топовую модель увеличивает затраты и задержки, зависящие от длины цикла.

Простой round-robin балансировщик усугубляет проблему: он может поставить завершение на 200 токенов в очередь за префиллом на 100k токенов на загруженном GPU-поде, в то время как соседний под простаивает.

03Как устроена маршрутизация

Предложенная архитектура разделяет проблемы по типу сигнала:

• RouteLLM анализирует промпт и предсказывает, сможет ли более дешевая модель сравняться по качеству ответа с более сильной. Используется матричный факторизационный роутер, обученный на данных человеческих предпочтений.
• agentgateway — открытый прокси, совместимый с OpenAI. Управляет политиками: аутентификация, rate limits для каждого агента, отслеживание затрат, guardrails. При этом не анализирует смысл промптов.
• Endpoint Picker из Gateway API Inference Extension проверяет состояние GPU в реальном времени: occupancy KV-кэша и глубину очереди vLLM. Это помогает выбрать реплику выбранной модели для обработки запроса.

agentgateway вызывает Endpoint Picker напрямую через ext-proc для self-hosted пути, что позволяет обойти отдельный Gateway API gateway.

04Инфраструктура и наблюдаемость

• KAITO предоставляет GPU-ноды по требованию и запускает vLLM. Он отдает метрики vllm:num_requests_waiting и vllm:kv_cache_usage_perc, которые использует Endpoint Picker.
• Сильный путь идет в Azure OpenAI через AI-бэкенд в agentgateway.
• Слабый путь маршрутизируется к подам KAITO через service-бэкенд с политикой inferenceRouting, направляющей размещение в Endpoint Picker, с destinationMode: passthrough.
• Azure Managed Prometheus и Grafana собирают метрики маршрутизации и затрат agentgateway, а также GPU-метрики vLLM для единой картины.

05Ключевой параметр: порог эскалации RouteLLM

Ключевой параметр всей схемы — порог эскалации RouteLLM. В тестах RouteLLM роутер mf достиг примерно 95% качества MT-Bench от GPT-4, отправляя лишь около 26% вызовов в GPT-4 и экономя до 85% затрат по сравнению с маршрутизацией всех вызовов в сильную модель.

Microsoft предупреждает: эта цифра не применяется автоматически. Она привязана к паре моделей, использованных для обучения RouteLLM, а не к паре phi-4-mini/GPT-5.1. Пользователям нужно калибровать порог под фактический трафик и корректировать его на основе разделения strong/weak в agentgateway, а не полагаться на оценку RouteLLM.

06Нюансы затрат и зрелость компонентов

В посте отмечается, что кэширование промптов усложняет расчет затрат на токены. Кэшированный входной токен получает скидку, а переключение моделей охлаждает оба кэша. Это означает, что реальная стоимость «сильного» вызова ниже, чем кажется.

Автор предупреждает, что компоненты, использованные в посте, молодые:

Несколько компонентов здесь молодые, и имена полей меняются между релизами — Inference Extension переименовал и реструктурировал CRD на пути к v1. Все ниже проверено end-to-end на AKS в середине 2026 года против Inference Extension v1.0.0 и agentgateway v1.3.1. Относитесь к манифестам как к форме решения, фиксируйте версии и сверяйте поля с документацией. Декомпозиция стабильна; конкретные флаги и поля CRD быстро меняются.

Например, InferencePool и InferenceObjective находятся в разных API-группах.

07Развертывание и управляемые альтернативы

Все три открытых слоя работают внутри кластера AKS. При этом KAITO serving, Azure OpenAI и стек наблюдаемости Prometheus/Grafana управляются Azure.

Microsoft отмечает, что Foundry model router — это управляемая версия семантического слоя RouteLLM. Это помогает командам, которые предпочитают не управлять роутером самостоятельно. Однако управляемого варианта для GPU-aware размещения Endpoint Picker пока нет — он должен работать в кластере независимо от используемого gateway.

08Поэтапное внедрение

Команды могут внедрять архитектуру поэтапно:

• Одна hosted-модель за несколькими агентами в основном требует agentgateway для управления, без маршрутизации и GPU-размещения.
• Self-hosting одного класса моделей выигрывает от KAITO и Inference Extension без семантической маршрутизации, так как выбирать не из чего.
• RouteLLM стоит добавлять, когда у сильной модели есть явный ценовой разрыв со слабой и есть достаточный объем простого трафика. Пост предполагает, что это применимо почти к любому агенту, работающему в цикле.