> ## Content Index > Fetch the complete content index at: https://lucasfogaca.dev.br/llms.txt > Use this file to discover other available public pages before exploring further. # Como o ChatGPT reduz custo e latência no loop de agentes - URL: https://lucasfogaca.dev.br/como-o-chatgpt-reduz-custo-e-latencia-no-loop-de-agentes/ - Published: 2026-07-30T12:06:12.000Z - Updated: 2026-07-30T12:06:12.000Z - Author: Lucas Fogaça - Tags: noticias Quando um agente demora ou fica caro, é tentador olhar apenas para o modelo. Mas uma tarefa como “encontre a regressão, corrija e rode os testes” depende de um sistema inteiro: contexto, execução de ferramentas, transporte de rede, tokenização, filtros de segurança, roteamento e GPUs. O artigo [How ChatGPT Optimizes its Agent Loop](https://blog.bytebytego.com/p/how-chatgpt-optimizes-its-agent-loop?ref=lucasfogaca.dev.br), da ByteByteGo, organiza esse sistema em três camadas — *harness*, API e inferência — e mostra uma ideia útil para quem constrói agentes: quase toda otimização relevante evita refazer trabalho que o sistema já fez. ## O loop de um agente tem três camadas - **Harness:** mantém o histórico, monta o contexto, interpreta chamadas de ferramenta, aplica políticas de aprovação e devolve os resultados ao modelo. - **API:** recebe a conversa estruturada, autentica, aplica limites, tokeniza o conteúdo e encaminha a requisição. - **Inferência:** executa o modelo nos aceleradores, preserva o estado necessário para a geração e produz os próximos tokens. Uma única tarefa pode repetir esse ciclo muitas vezes. Um segundo extra em cada chamada deixa de ser detalhe quando há dezenas de ferramentas, resultados longos e novas rodadas de raciocínio. ## 1\. No harness, transmita apenas o que mudou Em um fluxo HTTP sem estado, cada rodada tende a reenviar instruções, schemas de ferramentas e todo o histórico. A ByteByteGo descreve o uso de WebSockets persistentes e de requisições incrementais: depois da primeira chamada, o cliente pode enviar o resultado novo de uma ferramenta e uma referência à resposta anterior. A conexão e o servidor já conhecem o resto. O mesmo princípio vale para o cache de prompt. O cache só é reaproveitado quando o prefixo é idêntico token a token. Por isso, ordenar definições de ferramentas de forma determinística e tratar o histórico como uma sequência append-only é mais do que capricho de implementação: muda o custo de cada rodada. ## 2\. Menos ferramentas no contexto, mais ferramentas sob demanda Carregar centenas de schemas de integração em toda chamada consome contexto, mesmo quando quase nenhum será usado. Uma alternativa descrita no artigo é deixar no prompt apenas as ferramentas centrais e uma busca de ferramentas. Quando o agente precisa de algo específico, procura o catálogo e recebe a definição relevante. Há um detalhe importante: nessa situação, simplicidade pode vencer sofisticação. O exemplo usa busca lexical BM25 para recuperar ferramentas a partir de suas descrições, em vez de acrescentar outra camada de embeddings ao caminho crítico. Outra redução de rodadas é o *Code Mode*: em vez de emitir várias chamadas independentes e esperar o resultado de cada uma, o modelo escreve um pequeno programa que as executa, paraleliza o que puder e devolve ao contexto só o resultado consolidado. Isso reduz tanto latência quanto ruído acumulado na conversa. ## 3\. Na API, não retokenize a conversa inteira Tokenização é trabalho linear sobre o texto. Se a API retokeniza todo o histórico a cada resultado de ferramenta, ela relê milhares de tokens para acrescentar poucas linhas. Mantendo a conversa tokenizada em memória no lado do servidor, a API tokeniza o delta e o anexa ao estado existente. O artigo também destaca uma forma pragmática de diminuir o tempo até o primeiro token: iniciar verificações de segurança em paralelo à inferência. Se os controles terminam antes de o resultado precisar ser liberado, o usuário não paga duas vezes pelo tempo de espera. O requisito, naturalmente, é preservar a política de bloqueio ou retenção caso a verificação falhe. ## 4\. Na inferência, proteja o estado que já foi calculado Na camada de GPUs, o roteamento não deve olhar apenas para a fila. Ele também deve tentar levar a próxima rodada de uma conversa para uma máquina que ainda guarda seu estado. Mandá-la para outra máquina pode obrigar o sistema a reconstruir um cache que já existia. Esse estado é o **KV cache**, usado pelo transformer para não recalcular toda a atenção a cada token. Como ele cresce com o contexto e com o número de conversas concorrentes, políticas de retenção e transferência precisam ser guiadas por traços reais de uso, não por intuição. O artigo cita ainda duas técnicas conhecidas: - **Decodificação especulativa:** um modelo menor propõe vários tokens; o modelo maior os verifica em paralelo e aceita os corretos, sem alterar a qualidade da saída. - **Separação entre prefill e decode:** processar o prompt inteiro e gerar token a token são cargas diferentes. Separá-las permite configurar recursos para o gargalo de cada fase. ## A métrica certa é custo por tarefa concluída O ponto mais útil não é uma técnica isolada. É observar a cadeia inteira: um prefixo estável ajuda o cache do prompt; o cache reduz trabalho na API e na GPU; uma ferramenta descoberta sob demanda evita contexto inútil; uma execução em lote corta voltas no loop. Para quem opera agentes, a pergunta prática é: **qual trabalho este loop está repetindo?** Meça com tráfego parecido com o de produção, preserve estado quando for seguro e elimine recomputação antes de adicionar complexidade. A soma dessas pequenas decisões é que reduz latência e custo por tarefa que realmente chega ao fim. --- **Fonte:** [ByteByteGo — How ChatGPT Optimizes its Agent Loop: Harness, API, and Inference](https://blog.bytebytego.com/p/how-chatgpt-optimizes-its-agent-loop?ref=lucasfogaca.dev.br) (29 jul. 2026). O texto acima é uma análise original baseada no artigo, não uma reprodução.