Um agente de IA pode gerar texto rapidamente e ainda assim parecer lento. O motivo está nas pausas entre uma etapa e outra: buscar documentos, chamar uma ferramenta, esperar uma resposta e enviar tudo de volta ao modelo. Em sistemas com RAG e múltiplos módulos, a latência de rede pode representar uma parcela relevante do tempo, em alguns fluxos até maior que a inferência.
Esse detalhe muda a pergunta que o desenvolvedor precisa fazer. Em vez de olhar apenas para tokens por segundo, vale medir quanto tempo o sistema passa esperando o próximo componente.
A resposta pode resultar de uma sequência de esperas
Imagine um agente que recebe uma pergunta, procura trechos relevantes em uma base vetorial, consulta uma API e só então produz a resposta. Cada etapa parece simples. O problema aparece quando elas acontecem em sequência.
Suponha que cada chamada de rede leve um intervalo fixo de latência e que o modelo precise de duas rodadas de inferência com duração definida. Se o fluxo fizer várias chamadas de rede, o tempo total será maior que o tempo de inferência isolado, porque a comunicação acrescenta espera ao processamento. Nesse cenário, a comunicação pode representar uma parcela relevante do tempo total.
Agora suponha que o agente faça mais chamadas de rede. Mantendo as mesmas premissas, a espera aumenta e o tempo total fica maior que no cenário anterior. O modelo continua com a mesma velocidade. A experiência piorou porque a arquitetura criou mais idas e vindas.
Essa conta é ilustrativa, não uma medição universal. A distinção técnica é esta: latência é o intervalo até uma resposta, enquanto largura de banda mede quanto dado pode atravessar a conexão. Maior largura de banda não elimina a latência de cada comunicação.
O desenho do fluxo pode se tornar um gargalo
Um padrão recorrente é encadear componentes. O primeiro chama o segundo, que chama o terceiro, que devolve o resultado ao segundo, e assim por diante. Esse desenho é fácil de entender e testar. Também acumula espera.
Duas razões frequentes são a distância física entre os serviços e o custo fixo de cada chamada. Pacotes atravessam cabos, roteadores e pontos de congestionamento. Além disso, cada comunicação pode envolver resolução de endereço, abertura ou reutilização de conexão, autenticação, serialização do conteúdo e processamento do serviço remoto.
O tempo também varia. Uma chamada pode demorar mais sob congestionamento ou perda de pacotes. Essa variação, chamada jitter, torna a experiência irregular. O usuário não percebe apenas a média. Ele percebe a resposta que demorou demais.
Por isso, medir somente a média esconde o problema. O sistema precisa registrar o tempo de cada etapa e observar também os maiores atrasos. Um fluxo pode ter média aceitável e ainda produzir esperas longas em uma parcela relevante das solicitações.
O que o batch realmente compra
Agrupar chamadas é uma das otimizações mais diretas. Se o agente precisa consultar documentos independentes, pode enviar as consultas em conjunto ou em paralelo, em vez de esperar uma terminar para iniciar a próxima.
Suponha várias consultas independentes, cada uma com um intervalo fixo de latência. Em sequência, as latências se acumulam. Se forem disparadas em paralelo e o serviço suportar isso, o tempo se aproxima da duração da consulta mais lenta, acrescida do custo de coordenação.
O ganho não reduz necessariamente a latência individual da rede. Ele impede que esperas independentes se somem.
Batching também reduz a quantidade de cabeçalhos, autenticações e ciclos de conexão. Mas há um limite importante: agrupar tudo pode aumentar o tamanho da requisição, o uso de memória e o tempo de processamento do serviço. Uma fila enorme também cria espera. Um critério possível é agrupar operações independentes sem criar um novo gargalo.
Paralelo não significa sem ordem
Nem todo fluxo pode ser paralelizado. Uma ferramenta pode depender do resultado da anterior. Se a primeira chamada descobre o identificador necessário para a segunda, as duas continuam sequenciais.
O trabalho então passa a ser separar dependências reais de dependências acidentais. Muitas arquiteturas esperam uma resposta completa quando precisariam apenas de um campo pequeno. Outras enviam o histórico inteiro para cada módulo, aumentando o tempo de transferência e o processamento.
Uma estratégia possível é desenhar o agente como um grafo. Nós representam tarefas. Setas representam dependências. Tudo que não depende da mesma saída pode, em princípio, ser executado em paralelo. O grafo revela onde o sistema está realmente condenado a esperar e onde apenas herdou uma ordem conveniente para o código.
Aproximar componentes muda mais que trocar o modelo
Colocar serviços próximos reduz o caminho percorrido pelos dados. Uma arquitetura pode manter a aplicação, a base vetorial e as ferramentas na mesma região de computação, enquanto deixa armazenamento menos urgente em outro local.
Essa escolha não remove todos os atrasos. O processamento continua existindo, e uma rede próxima ainda pode sofrer congestionamento. Também há custos e restrições operacionais: mover dados, manter redundância e lidar com falhas entre regiões.
Mesmo assim, como regra de projeto, pode ser vantajoso manter próximos os componentes que conversam a cada solicitação, em comparação com componentes acessados raramente. A topologia deve ser avaliada em função do fluxo de dados, não apenas da organização das equipes ou da facilidade inicial de implantação.
O que os tokens por segundo não mostram
A velocidade de geração importa quando a resposta é longa. Ela não descreve o tempo até o primeiro sinal de resposta, nem o tempo gasto antes de o modelo começar a gerar.
Em um agente, o usuário espera por uma cadeia: entrada, recuperação, ferramenta, nova inferência e saída. Se o modelo produz tokens rapidamente, mas precisa aguardar várias chamadas externas, o indicador mais divulgado mede apenas o trecho final da viagem.
Também existe uma troca entre qualidade e latência. Recuperar mais documentos pode melhorar o contexto, mas aumenta transferência e processamento. Usar mais ferramentas pode ampliar a capacidade do agente, mas cria novas dependências. O objetivo não é remover toda etapa. É provar que cada espera compra qualidade suficiente para justificar seu preço.
A medição que vale a pena fazer
Instrumente cada fronteira do sistema. Registre quando uma etapa começa, quando envia a requisição, quando recebe o primeiro byte e quando termina. Separe tempo de rede, fila, processamento e geração.
Depois, compare três números: tempo até o primeiro resultado, tempo total e distribuição dos atrasos. O RTT de uma rede, medido por um teste de ida e volta, ajuda no diagnóstico, mas não representa perfeitamente uma chamada de aplicação. Os caminhos podem ser diferentes, e a aplicação acrescenta seus próprios custos.
Comece pelas etapas que aparecem no caminho crítico. Paralelize consultas independentes, reutilize conexões, reduza dados transportados e aproxime os componentes que conversam com frequência. Só depois avalie trocar o modelo ou aumentar a capacidade de computação.
A hipótese de que a rede será o gargalo dominante não vale para todo agente. Em tarefas com contexto enorme ou raciocínio longo, a inferência pode continuar sendo a maior parcela. A forma mais confiável de decidir é medir o fluxo real.
O próximo salto de desempenho não está necessariamente em um modelo que gera mais tokens por segundo. Pode estar em uma decisão de arquitetura: uma chamada a menos, duas consultas simultâneas ou a aproximação de componentes que se comunicam com frequência. Em sistemas distribuídos, inteligência não é apenas o que cada módulo sabe fazer. É também quanto tempo eles passam esperando uns pelos outros.
