A IA agêntica vai bater em um limite de infraestrutura antes de chegar a um limite de inteligência

Os modelos estão melhorando mais rápido do que nossa capacidade de atender ao que lhes pedem.

A maior parte do debate sobre o rumo dos agentes de IA gira em torno de suas capacidades. O modelo consegue planejar de forma confiável? Consegue corrigir os próprios erros? É possível confiar a ele uma ação com consequências?

Essas são perguntas legítimas. Mas não são elas que vão determinar se os agentes serão implantados em larga escala nos próximos anos, porque há um obstáculo mais próximo — e ele está chegando mais rápido. É economicamente difícil atender às demandas dos agentes, e essa dificuldade aumenta justamente com as capacidades que todos querem acrescentar.

Um chatbot e um agente representam cargas de trabalho diferentes

Uma solicitação conversacional envolve uma única ida e volta: o prompt entra, os tokens saem e a conexão é encerrada. É possível processar solicitações em lotes, armazenar o prefixo em cache e avaliar a capacidade de processamento com base em um único número.

Uma solicitação a um agente é uma sessão. Ele chama uma ferramenta, espera, lê o resultado, decide o que fazer em seguida, chama outra ferramenta e, por fim, responde. Uma tarefa simples pode envolver seis ou oito chamadas ao modelo, com períodos de espera entre elas.

Essa diferença importa por uma razão que não tem nada a ver com inteligência. Entre uma etapa e outra, o agente mantém um estado — a conversa, as saídas das ferramentas e o raciocínio acumulado. No sistema que atende às solicitações, esse estado fica na memória da GPU como cache KV e ocupa espaço durante toda a sessão, inclusive nos segundos em que o agente espera por uma API que não é sua.

Assim, a capacidade deixa de ser medida em “solicitações por segundo” e passa a ser medida em “sessões simultâneas residentes na memória”. Um sistema que atendia confortavelmente a mil solicitações conversacionais por segundo talvez consiga atender a apenas algumas dezenas de sessões simultâneas de agentes no mesmo hardware.

A espera é a parte mais cara

Eis o aspecto incômodo: durante uma chamada a uma ferramenta, o agente não faz nada. Nenhum token é gerado. Nenhum poder computacional é consumido. Ainda assim, a memória da GPU continua ocupada, porque liberar esse contexto e recalculá-lo custaria mais do que mantê-lo ali.

Seu hardware mais caro fica reservado para uma solicitação que, naquele momento, está esperando uma consulta ao banco de dados.

Nos sistemas distribuídos convencionais, resolvemos esse problema há muito tempo: liberamos o recurso e retomamos o trabalho quando chega a resposta. Fazer o mesmo no atendimento a modelos significa transferir o cache KV para a memória do host ou para o disco e restaurá-lo depois; o custo da transferência é tão alto que a maioria dos sistemas nem tenta. Há pesquisas em andamento exatamente sobre isso, porque o problema é caro.

A execução sequencial piora a situação sem necessidade

Quase todas as estruturas de agentes executam as chamadas a ferramentas uma após a outra. O modelo solicita uma consulta meteorológica e recebe o resultado; depois, pede uma verificação da agenda e recebe o resultado; em seguida, solicita uma busca de voos e recebe o resultado.

Muitas vezes, essas três chamadas não dependem umas das outras. Poderiam ter sido feitas ao mesmo tempo. Quando são executadas em sequência, a latência corresponde à soma dos tempos. Quando são executadas em paralelo, corresponde ao tempo da mais demorada.

Essa não é uma observação nova sobre agentes: é o mesmo princípio estrutural que se aplica a qualquer sistema que execute vários modelos ou serviços dentro de um único orçamento de latência. A latência total deve corresponder ao caminho mais longo no grafo de dependências, e não à soma de todas as etapas. Isso importa ainda mais para os agentes porque a sessão permanece na memória da GPU durante todo o processo. Portanto, reduzir o tempo total não melhora apenas a experiência do usuário: também aumenta diretamente o número de sessões que cabem no hardware.

Reduza a duração das sessões pela metade e a capacidade simultânea praticamente dobrará, com as mesmas GPUs e sem mudar o modelo.

As novas tentativas se acumulam de uma forma que ninguém planejou

As estruturas de agentes herdam das bibliotecas HTTP subjacentes as configurações padrão de novas tentativas. Em geral, são três tentativas.

O modelo também tenta de novo, à sua maneira. Quando uma ferramenta retorna algo inútil, um modelo de raciocínio muitas vezes experimenta outra abordagem — o que equivale a uma nova tentativa, só que ninguém a configurou.

Combine os dois comportamentos: uma política de três tentativas aplicada a um modelo que, por conta própria, chega a outras três abordagens resulta em uma política de nove tentativas que ninguém registrou. Cada tentativa exige uma chamada completa ao modelo, com seus próprios tokens e segundos de uso da GPU.

Quando uma dependência fica lenta, essa amplificação transforma a degradação em uma interrupção do serviço — e o custo de cada tentativa é várias ordens de grandeza maior do que o de repetir uma chamada REST.

Como é o limite na prática

Não é um teto de capacidade. É algo mais prosaico: um problema de viabilidade econômica que interrompe projetos na passagem da fase piloto para a produção.

O piloto funciona. São dez usuários, a latência é aceitável e a conta é praticamente insignificante. Então, alguém calcula o cenário para dez mil usuários e conclui que a quantidade de GPUs necessária é inviável — não porque o modelo seja lento, mas porque cada sessão simultânea ocupa memória durante toda a sua duração, inclusive enquanto espera.

É nesta etapa que muitas demonstrações internas promissoras simplesmente deixam de avançar, sem alarde.

O que faz esse limite avançar

Nada de extraordinário; tudo isso diz respeito à infraestrutura, não à modelagem:

Execute chamadas independentes a ferramentas em paralelo. É o maior ganho individual disponível hoje e não exige novo hardware.

Considere a duração da sessão como métrica de capacidade. Não os tokens por segundo. Nem a utilização da GPU. O que importa é por quanto tempo o estado permanece na memória e quantas sessões cabem.

Defina o orçamento de novas tentativas para o sistema todo, não para cada chamada. Um limite global — com as novas tentativas representando uma pequena porcentagem do tráfego total — evita o efeito cumulativo descrito acima. Tanto a prática de SRE do Google para lidar com sobrecarga quanto os orçamentos de novas tentativas do Envoy implementam essa ideia fora da pilha de IA.

Separe o raciocínio da execução. Use um modelo grande para planejar e outro bem menor para as etapas mecânicas. A maior parte do que um agente faz não exige um modelo de ponta.

Torne barato descartar o contexto. Cache KV quantizado, atenção paginada e caminhos de transferência para sessões ociosas. É nessa área que acontece o trabalho mais interessante de disponibilização de modelos neste momento.

Os modelos continuarão melhorando. Essa parte parece certa. Se os agentes se tornarão infraestrutura ou continuarão sendo demonstrações depende de algo menos glamoroso: se conseguiremos atender a uma carga de trabalho que mantém memória cara ocupada enquanto aguarda e se deixaremos de pagar pela soma de uma sequência quando poderíamos pagar apenas pelo seu caminho mais longo.

Publiquei o modelo de execução que fundamenta esse último ponto — a execução simultânea de chamadas dependentes a modelos dentro de um único orçamento de latência — em “Execução assíncrona de grafos de inferência para roteamento de modelos em sistemas de aprendizado de máquina”, International Journal of Computer Trends and Technology 72(10), outubro de 2024. Sobre a integração de modelos generativos especificamente a sistemas de decisão sujeitos a limites de latência, consulte “Plataformas de negociação e tomada de decisão ampliadas por modelos de linguagem de grande porte: conectando inteligência generativa a sistemas de decisão financeira”, Journal of Information Systems Engineering and Management 11(1s), 2026.