---
title: "Microsoft lança arquitetura de referência para rotear tráfego de agentes de IA no AKS"
author: "Gabriela P. Torres"
date: "2026-07-31 07:30:00-03"
category: "Inteligência Artificial & Dados"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/07/31/microsoft-lanca-arquitetura-de-referencia-para-rotear-trafego-de-agentes-de-ia-no-aks/md"
---

## Resumo
- A arquitetura resolve três problemas simultâneos: qual modelo atende a requisição, como gerenciar a chamada e qual réplica de GPU a recebe.
- O RouteLLM avalia o prompt e decide se um modelo mais barato pode substituir um mais potente com qualidade similar, usando um roteador treinado com dados de preferência humana.
- O agentgateway atua como proxy central para políticas de autenticação, limites de taxa, rastreamento de custos e guardrails de segurança.
- O Gateway API Inference Extension usa o Endpoint Picker para selecionar a réplica de GPU com base no estado em tempo real, como ocupação do cache e profundidade da fila.
- Os componentes de código aberto (RouteLLM, agentgateway, Inference Extension) rodam no cluster AKS e se conectam a um único endpoint compatível com a API da OpenAI.
- A infraestrutura gerenciada da Azure inclui o KAITO para servir modelos self-hosted e o Azure OpenAI para o caminho de modelos de fronteira como o GPT-5.1.
- A arquitetura foi validada no AKS em meados de 2026, com as versões específicas Inference Extension v1.0.0 e agentgateway v1.3.1.

---

Um agente de IA que precisa pesquisar informações, analisar dados e gerar um relatório pode facilmente disparar centenas de chamadas a modelos de linguagem em um único ciclo de "planejar-observar-agir". Cada uma dessas chamadas é uma decisão: vale a pena usar o modelo mais caro e poderoso, ou um mais barato resolve? E, independentemente da escolha, qual servidor com GPU deve receber essa requisição? Para quem constrói sistemas agênticos em larga escala na nuvem da Microsoft, a resposta até agora era uma complicada costura manual. No dia 29 de junho de 2026, a equipe de engenharia do Azure Kubernetes Service (AKS) publicou uma arquitetura de referência que transforma essas três perguntas em três camadas distintas e automatizadas de uma mesma infraestrutura, prometendo reduzir custos em até 85% sem sacrificar a qualidade das respostas.

## O primeiro nó da decisão: qual modelo deve responder?

A primeira e mais visível das três camadas é a que decide para qual modelo de linguagem a requisição será enviada. Em vez de tratar todas as chamadas de forma igual, a arquitetura utiliza o **RouteLLM**, uma ferramenta de código aberto que atua como um "roteador semântico". Pense nisso como um triador em um hospital: ele não encaminha todos os pacientes para o cirurgião-chefe. Ele primeiro avalia a complexidade do caso. Se for um curativo simples, um enfermeiro experiente resolve. Da mesma forma, o RouteLLM analisa o conteúdo do prompt do usuário e prevê se um modelo de linguagem menor e mais barato, hospedado localmente no cluster, consegue entregar uma resposta com qualidade comparável a um modelo de fronteira como o GPT-4.

Essa decisão não é baseada em regras simples de palavras-chave. Segundo o post do blog de engenharia do AKS, escrito por **Fuyuan Bie**, o RouteLLM utiliza um "roteador de fatorização de matriz" (matrix-factorization router) treinado com dados de preferência humana. Na prática, isso significa que o sistema aprendeu, a partir de avaliações reais de humanos, quais características de um prompt indicam que uma resposta de um modelo mais simples será suficiente. Os testes realizados pela Microsoft com um par específico de modelos mostraram que essa abordagem alcançou **aproximadamente 95% da qualidade do GPT-4 no benchmark MT-Bench**, enquanto direcionava apenas **cerca de 26% das chamadas para o modelo mais caro**. O restante, a grande maioria do tráfego, foi para o modelo mais leve. O resultado prático, conforme apontado no resumo publicado pelo InfoQ em 29 de julho de 2026, é uma **economia de até 85% nos custos de inferência**. Vale notar, porém, que esse percentil de economia está diretamente ligado ao par de modelos usado para o treinamento do roteador; em produção, cada equipe precisará calibrar o sistema para seus próprios modelos e níveis de qualidade aceitáveis.

## O segundo nó: quem controla a porta de entrada e as regras do jogo?

A segunda camada da arquitetura não se preocupa com a inteligência da resposta, mas sim com a governança do tráfego que a solicita. É aqui que entra o **agentgateway**, que funciona como um proxy de IA e uma central de políticas. Ele é o porteiro que verifica as credenciais, controla a taxa de acesso e garante que ninguém ultrapasse os limites. A necessidade dessa camada ficou evidente em uma publicação anterior do blog do AKS, de 17 de abril de 2026, que descrevia justamente a integração do agentgateway com a **Application Network (AppNet)** da Azure para controle de gastos. A publicação, assinada por **Mitch Connors, John Howard e Zhewei Hu**, explicava como usar a identidade mTLS automática do AppNet para implementar limites de taxa baseados em tokens por aplicação, sem a necessidade de distribuir chaves de API para cada serviço.

Dentro da arquitetura de três camadas, o agentgateway assume um papel ainda mais centralizado. Ele define as regras para todo o tráfego de agentes que passa pelo cluster, independentemente de qual modelo foi escolhido pelo RouteLLM. Suas responsabilidades incluem a autenticação das requisições, o estabelecimento de limites de taxa (rate limits) para evitar picos de custo inesperados, o rastreamento detalhado de gastos e a aplicação de guardrails de segurança para impedir respostas inadequadas ou perigosas. Em outras palavras, se o RouteLLM é o triador que decide qual médico atende, o agentgateway é a administração do hospital, que define as regras de visitação, os protocolos de segurança e o controle de acesso às alas. Toda essa política é configurada e aplicada de forma centralizada, oferecendo uma camada de governança indispensável para ambientes corporativos onde múltiplos agentes, de diferentes equipes, compartilham a mesma infraestrutura de IA.

## O terceiro nó: qual máquina física vai executar o trabalho?

Uma vez que o RouteLLM escolheu o modelo e o agentgateway validou e governou a requisição, a arquitetura enfrenta uma última decisão crucial: para qual servidor físico, com sua preciosa GPU, a chamada deve ser enviada? É aqui que a arquitetura se apoia no **Gateway API Inference Extension**, um projeto de código aberto para o Kubernetes que foi criado, segundo seu anúncio no blog oficial do Kubernetes em 5 de junho de 2025, para preencher lacunas nas capacidades de roteamento específicas para inferência. A peça-chave dessa camada é o chamado **Endpoint Picker**. Em vez de simplesmente distribuir as requisições de forma aleatória (round-robin), o Endpoint Picker consulta o estado em tempo real das GPUs no cluster.

Os dados que ele utiliza são altamente granulares e específicos para workloads de modelos de linguagem. A postagem do blog do AKS detalha que o Endpoint Picker verifica a **ocupação do KV-cache** — que é a memória que o modelo usa para armazenar o contexto da conversa e evitar recalcular informações anteriores — e a **profundidade da fila de espera** de cada réplica do modelo. Para servir os modelos self-hosted (os modelos menores e mais baratos que o RouteLLM pode selecionar), a arquitetura utiliza o **KAITO** (Kubernetes AI Toolchain Operator), que provisiona automaticamente pools de nós com GPUs (como instâncias **Standard_NC24ads_A100_v4**) e executa o motor de inferência **vLLM**. O vLLM expõe métricas essenciais, como **vllm:num_requests_waiting** e **vllm:kv_cache_usage_perc**, que alimentam a inteligência do Endpoint Picker. Para o caminho dos modelos de fronteira, como o **Azure OpenAI**, o roteamento é direcionado para os recursos gerenciados pela Microsoft. O resultado é um balanceamento de carga que responde não apenas à disponibilidade, mas à real capacidade de processamento de cada réplica de GPU, evitando gargalos e otimizando a latência.

## Um único ponto de entrada para um sistema complexo

Uma das maiores virtudes da arquitetura proposta pela Microsoft é a forma como essas três camadas complexas são apresentadas ao desenvolvedor. Segundo o post de **Fuyuan Bie**, todos os componentes se conectam em um **único endpoint compatível com a API da OpenAI**. Isso significa que um aplicativo cliente ou um framework de agentes não precisa saber nada sobre RouteLLM, agentgateway ou o Endpoint Picker. Ele simplesmente envia uma requisição para um endereço, como faria normalmente com a API da OpenAI, e a infraestrutura no AKS cuida de todas as três decisões em cascata, de forma transparente. Essa abordagem reduz drasticamente a complexidade do lado do cliente e permite que a otimização de custos e desempenho aconteça na camada de infraestrutura, sem exigir mudanças no código da aplicação.

É importante destacar que a arquitetura não é um produto fechado da Microsoft, mas uma referência construída com uma combinação de serviços gerenciados da Azure e projetos de código aberto que rodam no cluster. Os serviços gerenciados incluem o **KAITO** para servir os modelos self-hosted e o **Azure OpenAI** para o caminho dos modelos de fronteira, além do **Azure Managed Prometheus** e **Grafana** para observabilidade. As três camadas de roteamento — **RouteLLM**, **agentgateway** e o **Gateway API Inference Extension** — são todas de código aberto e são instaladas diretamente no cluster AKS. A própria Microsoft observa em sua documentação que o **Foundry model router**, parte de sua plataforma gerenciada, é uma versão administrada da camada semântica do RouteLLM, indicando uma clara estratégia de integrar projetos de código aberto em sua oferta de nuvem.

## Próximos passos e maturidade da solução

A publicação original de **Fuyuan Bie** no blog do AKS contém uma nota de cautela importante: "as peças são jovens; os nomes dos campos mudam". A arquitetura foi validada de ponta a ponta no AKS em meados de 2026, contra versões específicas: **Inference Extension v1.0.0** e **agentgateway v1.3.1**. Isso indica que, embora funcional e promissora, a solução ainda está em um estágio onde detalhes de implementação podem evoluir rapidamente. Para os desenvolvedores e engenheiros de plataforma que desejam explorar essa arquitetura, o caminho prático começa com a preparação do ambiente: uma assinatura Azure com cota de GPU, as ferramentas de linha de comando Azure CLI e kubectl atualizadas, e um recurso do Azure OpenAI com um deployment de fronteira, como o **gpt-5.1**.

A criação do cluster AKS requer a habilitação de flags específicas, como **--enable-ai-toolchain-operator** e **--enable-azure-monitor-metrics**, para garantir que o KAITO e a stack de observabilidade estejam disponíveis. A configuração de cada camada — desde a definição de um Workspace do KAITO com tipo de instância e preset do modelo, até a instalação do Inference Extension via manifesto e a configuração dos binds, listeners e backends do agentgateway — envolve múltiplos passos que a documentação oficial detalha. A mensagem central é que a Microsoft não está apenas vendendo uma solução pronta, mas fornecendo um mapa detalhado de como construir, dentro do ecossistema AKS, um sistema de roteamento de agentes de IA que equilibra custo, qualidade e desempenho de forma granular e automatizada, transformando uma operação complexa em uma infraestrutura gerenciável.