Por que adicionar mais agentes de IA deixou nosso sistema mais lento

O diagnóstico: a culpa não era da OpenAI

Você está construindo um produto com agentes de LLM. Implanta os primeiros agentes, tudo parece bem. Mas conforme escala para dezenas deles, a latência começa a subir. Timeouts aparecem. Você culpa o provedor de LLM — “a OpenAI deve estar mentindo sobre a velocidade”. Até que olha os logs e descobre: a OpenAI está respondendo rápido. O problema está no seu código.

Esse foi exatamente o diagnóstico da equipe da Planck, que compartilhou a experiência em um artigo detalhado no Towards Data Science. A arquitetura parecia ideal: um único serviço acionava múltiplos agentes via Python assíncrono, cada um fazendo dezenas de chamadas a sub-agentes, com asyncio.gather orquestrando tudo em paralelo.

5 agentes × 30 chamadas = 150 requisições assíncronas. Onde está o gargalo?

“Quase todo o trabalho é I/O bound, então usar o ecossistema async do Python permite que cada agente execute concorrentemente”, explicava o raciocínio inicial da equipe. A latência deveria ser dominada pela chamada de LLM mais lenta — não pelo número total de agentes. Mas não era.

O problema estava nas pequenas tarefas de CPU que aconteciam entre as chamadas de rede: parsing de JSON, validação de respostas, montagem do próximo prompt. No modelo assíncrono do Python, essas tarefas compartilham o mesmo event loop das requisições de rede. Quando 150 corrotinas estavam competindo, o overhead de troca de contexto e processamento de CPU criava um gargalo silencioso que se manifestava como latência de rede.

A solução: separar CPU-bound de I/O-bound

A equipe resolveu o problema com duas mudanças principais:

• ProcessPoolExecutor para isolar o trabalho pesado de CPU do event loop principal, evitando que o parsing de uma resposta bloqueasse as chamadas de rede de outras.
• Semáforos para limitar a concorrência real — em vez de 150 chamadas simultâneas, um limite controlado (ex: 20 por vez) mantinha o sistema responsivo sem sobrecarregar o processo Python.

O resultado: latência caiu de ~45 segundos para ~8 segundos no pior caso, mantendo a mesma taxa de throughput. A lição principal: em arquiteturas assíncronas com dezenas de agentes de IA, o gargalo raramente está no modelo. Está nas pequenas tarefas de CPU que ninguém está medindo.