A latência de um agente de AI resulta da soma do tempo de inferência, das chamadas a ferramentas, da recuperação de contexto e das operações de estado. Ela pode ser reduzida aproximando esses componentes, evitando serviços externos desnecessários, paralelizando operações independentes e medindo cada etapa separadamente.
Cada etapa de um agente (chamar um modelo, executar uma ferramenta, recuperar contexto ou persistir estado) pode adicionar processamento e uma ou mais viagens de rede. Em loops com várias iterações, esses custos se acumulam e passam a afetar diretamente o tempo de resposta.
De onde vem a latência, etapa por etapa
Um agente que decide, age e observa normalmente passa por pelo menos quatro tipos de operação em uma única interação, embora nem toda etapa gere necessariamente uma chamada de rede: o estado pode estar em memória durante a mesma execução, incluído no próprio contexto do modelo, ou buscado em lote em vez de chamada por chamada.
Chamada ao modelo: o prompt sai da aplicação, vai até o endpoint de inferência e a resposta volta. Se o endpoint estiver em uma região distante, o round trip adiciona latência antes mesmo de considerar fila, processamento do modelo e geração dos tokens.
Chamada de ferramenta (tool call): quando o modelo decide usar uma tool, essa chamada pode ir para uma API interna, um servidor MCP ou outro serviço externo.
Consulta de memória ou contexto: buscar histórico de conversa ou fazer busca semântica para RAG é outra operação, geralmente contra um banco diferente do resto da aplicação.
Leitura e escrita de estado: contadores de etapa, flags de controle e resultado intermediário de tool calls.
Um exemplo concreto
Considere um agente respondendo a uma pergunta de suporte técnico:
- O usuário envia a pergunta. O agente chama o modelo para decidir o que fazer, chamada de rede até o endpoint de inferência, mais fila e geração de tokens.
- O modelo decide que precisa de contexto. O agente busca histórico de conversa e faz uma busca semântica (RAG) — segunda chamada de rede, geralmente contra um banco diferente.
- Com o contexto em mãos, o modelo decide chamar uma ferramenta (por exemplo, consultar o status de um pedido). Essa tool call vai a uma API interna ou a um servidor MCP, terceira chamada de rede.
- O resultado da ferramenta volta para o modelo, que gera a resposta final, quarta chamada de rede até o endpoint de inferência.
Cada uma dessas quatro chamadas pode levar de dezenas a poucas centenas de milissegundos, dependendo da distância até cada serviço. Se o endpoint de inferência, o banco de contexto e a API da ferramenta estiverem em três lugares diferentes, o tempo de rede sozinho, sem contar processamento já soma várias rodadas de ida e volta. E isso é só uma iteração: se o modelo decidir chamar mais uma ferramenta antes de responder, o ciclo se repete.
Por que isso não aparece no protótipo
Em um protótipo com um único usuário, poucas ferramentas e condições controladas, alguns segundos de espera podem parecer aceitáveis. O problema fica mais evidente em produção, quando aumentam o número de iterações, a concorrência, a dispersão geográfica dos serviços e a variabilidade de cada dependência.
Esse é o tipo de problema que arquiteturas distribuídas tentam resolver há anos, independentemente da AI: reduzir a distância entre a execução e os dados que ela precisa. A diferença é que, em um agente, o número de operações por interação do usuário é maior e menos previsível do que em uma aplicação web tradicional, porque depende de quantas vezes o modelo decide chamar uma ferramenta antes de parar.
Como reduzir cada etapa na Azion Platform
Nenhuma das operações acima desaparece. O que pode mudar é a distância entre elas, quando os componentes são posicionados de forma adequada dentro de uma arquitetura distribuída integrada.
Inferência com menos distância de rede: Azion AI Inference roda modelos (LLMs, VLMs, embeddings, reranking) em infraestrutura distribuída e serverless, com API compatível com OpenAI e escalonamento automático sem provisionar cluster de GPU.
Loop do agente sem custo de inicialização repetido: Azion Functions tem tempo de execução total de até 5 minutos por invocação (incluindo espera por I/O, chamadas de rede e operações assíncronas), com até 2 segundos de tempo de CPU ativa por invocação. O Azion Runtime é projetado para minimizar cold starts em toda a infraestrutura distribuída, com um teto de 2 segundos no pior caso. Um limite que importa mais para esse loop específico é o de sub-requisições: cada invocação pode fazer até 50 chamadas fetch().
Um agente que encadeia várias tool calls dentro da mesma invocação pode esbarrar nesse teto antes do limite de tempo — vale desenhar o loop em torno desse número, seja encadeando invocações, agrupando chamadas ou usando cache para tool calls repetidas.
Ferramentas no mesmo ambiente de execução: é possível rodar um servidor MCP diretamente em uma Function, na mesma infraestrutura que já executa o restante da lógica do agente, reduzindo o salto até o servidor de ferramentas.
Estado de trabalho sem datastore externo: KV Store mantém sessões, contadores e flags com réplicas de leitura distribuídas e integração nativa com Functions.
Memória persistente com busca vetorial no mesmo banco: SQL Database pode armazenar memória persistente e embeddings no mesmo banco, com busca vetorial integrada, reduzindo a necessidade de operar um banco vetorial separado para RAG.
Outras formas de reduzir a latência
Aproximar componentes é uma técnica, não a única:
- Streaming da resposta do modelo para reduzir o tempo percebido pelo usuário.
- Cache de prompts, embeddings ou resultados de tool calls repetidas.
- Paralelização de chamadas independentes dentro de uma mesma etapa do loop.
- Redução do número de iterações e tool calls necessárias, ajustando o prompt ou a lógica de decisão do agente.
- Timeouts, retries e circuit breakers para conter a variabilidade de dependências externas.
- Modelos menores para etapas intermediárias, reservando o modelo maior para a decisão final.
- Observabilidade por etapa, medindo tempo até o primeiro token (TTFT) e duração de cada tool call separadamente.
Reduzir a latência entre componentes, aliás, não é o mesmo que orquestrar múltiplos agentes coordenados , um padrão diferente, em que um agente delega tarefas a subagentes especializados rodando em paralelo, com custo de tokens muito mais alto (pesquisa da Anthropic sobre sistemas multiagente). A arquitetura distribuída da Azion aproxima execução, inferência e dados; orquestração multiagente é lógica de aplicação, não um produto que a Azion vende hoje.
Conclusão
Latência em um agente de AI não é um problema de uma etapa lenta. É um problema de operações que se acumulam ao longo de um loop, com variabilidade que cresce a cada iteração.
Antes de otimizar o prompt ou trocar de modelo, vale mapear quantas operações o agente executa em uma única interação e medir cada uma separadamente. Esse mapeamento, mais do que a velocidade de qualquer componente isolado, costuma explicar por que um agente que funciona bem em teste fica lento em produção.
Perguntas frequentes
Por que um agente de AI é mais sensível à latência do que uma aplicação web comum? Porque uma interação do usuário pode disparar várias operações em sequência (inferência, tool calls, memória, estado) em vez de uma única requisição-resposta. Cada componente de latência se multiplica pelo número de vezes que o loop do agente o executa.
Rodar tudo na mesma plataforma elimina completamente a latência? Não. Não elimina o tempo de rede entre a execução e o usuário final, nem o tempo de processamento do próprio modelo. A arquitetura da aplicação (iterações, cache, paralelização) continua determinando boa parte do resultado.
O que é um servidor MCP e por que a localização dele importa? Model Context Protocol é uma especificação aberta que padroniza como aplicações e agentes chamam ferramentas externas via JSON-RPC. Rodá-lo próximo da execução do agente reduz o salto até esse ponto de entrada, mas não elimina a latência de uma chamada externa que a ferramenta precise fazer.
Isso é uma forma de orquestração multiagente? Não. O foco aqui é a infraestrutura de um agente único; orquestrar múltiplos agentes é um padrão de arquitetura diferente, implementado na aplicação.
O tempo de execução de 5 minutos da Azion Functions significa 5 minutos de processamento do agente? Não. É tempo total (wall-clock), incluindo espera de rede. O tempo de CPU ativa, que mede processamento de fato, tem limite separado de 2 segundos por invocação.
Quantas tool calls um agente pode fazer dentro de uma única invocação? Até 50 chamadas fetch() por invocação, contando tool calls locais e repasses externos. Loops longos podem esbarrar nesse teto antes do limite de tempo.
Preciso reescrever meu agente para rodar assim? Depende do ponto de partida. Se já usa uma API compatível com OpenAI, migrar a inferência costuma exigir só a troca de endpoint e credenciais. Adotar KV Store, SQL Database ou um servidor MCP na Function pode ser feito de forma incremental.
