Kubernetes para agentes de IA: como escalar milhares de chamadas de inferência

Enviar uma mensagem para um chatbot tradicional dispara uma única chamada de inferência (o processamento de uma entrada por um modelo treinado para gerar uma resposta), encerrando o trabalho da infraestrutura em poucos instantes, ao passo que entregar uma tarefa a um agente autônomo de programação pode acionar 10 subagentes que executam milhares de chamadas de inferência ao longo de várias horas, segundo relatou Jonathan Bryce, diretor-executivo da Cloud Native Computing Foundation (abre em nova aba) (CNCF), durante a KubeCon + CloudNativeCon North America, em novembro de 2026. Diante dessa multiplicação de requisições, à medida que o orçamento de inteligência artificial nas empresas migra do treinamento de modelos para a execução de agentes em produção, a primeira impressão de muitas equipes de engenharia de plataforma é que o Kubernetes (abre em nova aba) (sistema de código aberto para automação de implantação, dimensionamento e gerenciamento de aplicações em contêineres) já resolve o problema nativamente, bastando adicionar mais nós com GPUs ao cluster e deixar o escalonamento automático criar novos Pods (a menor unidade computacional implantável no Kubernetes, que encapsula um ou mais contêineres de aplicação) conforme a fila aumenta.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌​​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌‌​​​​​‌‌​​‌‌​‌‌​​‌​‌​‌‌​​‌​​​​‌‌​‌​​​​‌​‌‌​‌​​‌‌​​​​​‌‌​​‌‌​​​‌‌​​‌​​​‌‌​​​‌​​‌​‌‌​‌​​‌‌​‌​​​‌‌​​‌​​​​‌‌​​​‌​​‌‌‌​​​​​‌​‌‌​‌​​‌‌‌​​‌​‌‌​​​‌‌​‌‌​​‌​​​‌‌​​​​‌​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌‌​‌‌‌​​‌‌​​​​​​‌‌​​‌‌​‌‌​​‌​​​‌‌​​​‌‌​​‌‌​​‌​​​‌‌​‌‌‌​​‌‌​‌​​​‌‌​​‌​‌​​‌‌​‌​​⁠

Na prática de operação, essa premissa esbarra na própria mecânica de inicialização do orquestrador. Projetado para microsserviços web que permanecem ativos por semanas, o ciclo de criação de um Pod exige que a requisição atravesse o servidor de API, o controle de admissão, o etcd (banco de dados distribuído de chave-valor que guarda o estado do cluster), o agendador, o kubelet (agente que roda em cada nó gerenciando os contêineres), o download da imagem e a configuração de rede, um percurso que leva cerca de um segundo ou mais para ser concluído. Agentes de IA operam sob uma cadência oposta: eles acordam, executam um comando de shell de 10 milissegundos, editam um arquivo ou consultam uma suíte de testes, e voltam a ficar ociosos por milissegundos ou minutos aguardando a resposta de um modelo de linguagem ou de um humano, precisando manter o estado do sistema de arquivos, processos e diretório de trabalho intacto entre cada etapa, conforme detalha a documentação técnica da NVIDIA (abre em nova aba). O Kubernetes até aguenta o tranco sem reclamar quando o serviço fica de pé de forma contínua, mas exigir que toda essa engrenagem suba um ambiente do zero centenas de vezes por segundo, para agentes que esperam respostas abaixo de 200 milissegundos (segundo levantamento do portal The New Stack), já é pedir demais da arquitetura padrão.

Como evitar o desperdício de GPU no roteamento de inferências

O que acontece na camada de aceleração de hardware quando uma única solicitação do usuário se desdobra em 20 ou milhares de passos sequenciais? Nos balanceadores de carga tradicionais para modelos de linguagem, cada chamada de inferência é tratada como uma requisição isolada e sem memória da anterior, o que força as GPUs a reprocessarem repetidamente as mesmas informações de contexto a cada passo do loop de raciocínio do agente. Em um fluxo agêntico real, chamadas consecutivas reutilizam o mesmo prompt de sistema, as mesmas definições de ferramentas disponíveis, o histórico da conversa e as observações coletadas nos passos anteriores.

Para corrigir esse gargalo sem abandonar o ecossistema nativo de nuvem, engenheiros do Google Cloud (abre em nova aba) (como Jaana Dogan, engenheira principal, e Jago Macleod, diretor de engenharia para Kubernetes e GKE) optaram por reequipar o próprio Kubernetes em vez de construir uma pilha paralela do zero. Na arquitetura aberta detalhada pela empresa em novembro de 2026, o controle da inferência distribuída fica a cargo do llm-d (abre em nova aba) (na versão 1.0), um plano de controle especializado que introduz duas mudanças arquiteturais para equipes de infraestrutura:

• Roteamento ciente de cache de prefixo (prefix-cache-aware routing): em vez de distribuir chamadas de um mesmo agente de forma aleatória entre os nós, o plano de controle gerencia o KV-cache (memória de chave-valor que armazena os cálculos intermediários de atenção do modelo) em múltiplas camadas e direciona os passos seguintes do agente para a instância que já retém o início daquele prompt processado.
• Inferência desagregada (disaggregated serving): o processamento inicial do prompt (intensivo em computação paralela) e a geração sequencial de tokens (intensiva em largura de banda de memória) passam a ser separados em pools de capacidade distintos, permitindo alocar hardware diferente para cada fase da resposta.
• Unificação de agendadores e aceleradores: a pilha combina o KubeRay (operador para rodar cargas elásticas do framework Ray no Kubernetes) governado pelo agendador de filas Kueue, enquanto o TorchTPU fornece um backend PyTorch unificado para Cloud TPUs e GPUs diretamente nos motores de inferência vLLM e SGLang.

Execução com estado e declaração de agentes no cluster

Resolver a fila das GPUs ainda deixa em aberto o problema dos ambientes de execução (sandboxes) que precisam preservar estado entre pausas longas sem consumir um Pod inteiro por sessão ociosa. A resposta conjunta liderada pelo Google e com contribuições da NVIDIA foi o desenvolvimento do Agent Substrate, um runtime de código aberto com arquitetura zero-trust (modelo de segurança que exige verificação explícita contínua e não confia em nenhum componente por padrão) doado ao CNCF Sandbox em novembro de 2026. Projetado para sustentar milhões de agentes isolados em execução prolongada, o Agent Substrate mantém a sessão compacta e preserva os processos e arquivos locais entre os turnos de espera, operando em conjunto com o gVisor (abre em nova aba) (kernel de aplicação que intercepta e isola chamadas de sistema para impedir que códigos não confiáveis gerados por agentes afetem o sistema operacional hospedeiro).

Na camada de desenvolvimento e operação diária, a criação desses agentes também deixou de exigir scripts improvisados fora do padrão do cluster graças ao kagent (abre em nova aba), outro projeto aceito no CNCF Sandbox. De acordo com a especificação demonstrada por Antonio Berben, da Solo.io (abre em nova aba), e Felipe Vicens, o kagent transforma agentes em Custom Resources (CRDs, extensões da API do Kubernetes que permitem declarar novos tipos de objetos nos mesmos arquivos YAML usados para Deployments e Services): o desenvolvedor declara o prompt de sistema, o modelo base e a lista de ferramentas permitidas, aplica o manifesto no cluster, e o controlador converte a definição em uma instância ativa capaz de se comunicar via protocolo A2A (comunicação direta entre agentes).

Essa padronização atende aos dois padrões de arquitetura mapeados por Yutaka Ichikawa, arquiteto de soluções de IA da Oracle (abre em nova aba), em apresentação técnica de novembro de 2026:

1. Agentes de operação interna do cluster: o Kubernetes mantém seu laço de reconciliação (reconciliation loop, mecanismo automatizado que compara continuamente o estado atual do cluster com o manifesto declarativo e corrige desvios), enquanto agentes internos leem eventos, logs e relações entre recursos para traduzir pedidos vagos de engenheiros em diagnósticos padronizados e planos de ação.
2. Cluster como plataforma de processos externos: a infraestrutura hospeda agentes voltados ao negócio que acionam sistemas externos em larga escala, como ilustra o caso documentado da Adonis no setor de saúde, cujos agentes investigam negativas de planos de saúde e realizam dezenas de milhares de chamadas de voz semanais para seguradoras em busca de informações de faturamento.

Governança em tempo de execução: quando a identidade não basta

Acostumadas a lidar com Pods que mudam de endereço IP a cada reinicialização, as equipes de plataforma aprenderam na última década a substituir regras baseadas em IP por políticas ancoradas em rótulos (labels) e identidades criptográficas de carga de trabalho. Os agentes autônomos quebram essa garantia: enquanto o código de um microsserviço tradicional define estaticamente quais rotas ele pode chamar, o código de um agente não revela o que ele fará em produção. Mesmo devidamente autenticado e autorizado, com credenciais perfeitamente válidas, o negócio escolhe sozinho, em tempo de execução, qual modelo consultar, qual ferramenta disparar ou qual subagente acionar, podendo executar ações indevidas sem violar nenhuma regra clássica de permissão de acesso, conforme aponta a análise de arquitetura da Tigera (abre em nova aba).⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌​​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌‌​​​​​‌‌​​‌‌​‌‌​​‌​‌​‌‌​​‌​​​​‌‌​‌​​​​‌​‌‌​‌​​‌‌​​​​​‌‌​​‌‌​​​‌‌​​‌​​​‌‌​​​‌​​‌​‌‌​‌​​‌‌​‌​​​‌‌​​‌​​​​‌‌​​​‌​​‌‌‌​​​​​‌​‌‌​‌​​‌‌‌​​‌​‌‌​​​‌‌​‌‌​​‌​​​‌‌​​​​‌​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌‌​‌‌‌​​‌‌​​​​​​‌‌​​‌‌​‌‌​​‌​​​‌‌​​​‌‌​​‌‌​​‌​​​‌‌​‌‌‌​​‌‌​‌​​​‌‌​​‌​‌​​‌‌​‌​​⁠

Para conter esse comportamento dinâmico dentro do Kubernetes, duas abordagens complementares passaram a compor a camada de segurança em novembro de 2026. Pela via comunitária, a NVIDIA doou ao CNCF Sandbox o NVIDIA OpenShell (junto ao lançamento de ferramentas proprietárias da sua plataforma DSX AI Factory, como Kubernetes Engine, Kubernetes Recipes e Snapshot), um runtime aberto que aplica controles determinísticos sobre a atividade do agente, forçando políticas estritas no momento exato em que ele tenta usar ferramentas, acessar provedores de inferência ou ler cofres de credenciais. Pela via de contenção de rede e sistema, ferramentas como o Lynx, da Tigera, rastreiam agentes registrados ou avulsos nos nós, posicionam um gateway no caminho de cada chamada para modelos ou ferramentas e mantêm travas diretamente no kernel do sistema operacional, garantindo que um agente seja contido no nível do processo mesmo que tente contornar o gateway de rede.

Ao planejar a adoção desses componentes em ambientes produtivos, engenheiros devem considerar os limites atuais de maturidade dessa pilha: projetos centrais como Agent Substrate, NVIDIA OpenShell e kagent ingressaram no estágio Sandbox da CNCF (a fase mais inicial de incubação da fundação, voltada à experimentação comunitária), e a documentação pública divulgada pelas empresas até novembro de 2026 não apresenta benchmarks independentes auditando ganhos exatos de latência ou redução financeira em clusters de terceiros. O orquestrador continua o mesmo, mas a carga de trabalho mudou de natureza.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌​​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌‌​​​​​‌‌​​‌‌​‌‌​​‌​‌​‌‌​​‌​​​​‌‌​‌​​​​‌​‌‌​‌​​‌‌​​​​​‌‌​​‌‌​​​‌‌​​‌​​​‌‌​​​‌​​‌​‌‌​‌​​‌‌​‌​​​‌‌​​‌​​​​‌‌​​​‌​​‌‌‌​​​​​‌​‌‌​‌​​‌‌‌​​‌​‌‌​​​‌‌​‌‌​​‌​​​‌‌​​​​‌​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌‌​‌‌‌​​‌‌​​​​​​‌‌​​‌‌​‌‌​​‌​​​‌‌​​​‌‌​​‌‌​​‌​​​‌‌​‌‌‌​​‌‌​‌​​​‌‌​​‌​‌​​‌‌​‌​​⁠