Rate limit e queda de API de LLM: como manter o agente de pé

Rate limit e queda de API de LLM: como manter o agente de pé

Para manter um agente de IA de pé quando o provedor limita ou cai, combine quatro camadas: uma fila que absorve picos, retentativas com backoff exponencial e jitter, um modelo de reserva para as tarefas que toleram troca e uma mensagem honesta de degradação com transbordo para uma pessoa. O erro mais comum é tratar toda falha como igual e repetir a chamada sem critério, o que piora o limite e pode duplicar ações. O desenho abaixo serve para agentes de atendimento, operação interna e automações com IA.

Principais pontos

• Limite de taxa e queda do provedor são problemas diferentes e pedem respostas diferentes: o primeiro se resolve com ritmo, o segundo com alternativa.
• Toda chamada ao modelo deve passar por uma fila, para que picos virem espera controlada e não mensagens perdidas.
• Retentativa só é segura com backoff, jitter, teto de tentativas e idempotência nas ações que alteram sistemas.
• Fallback de modelo é decisão de negócio: algumas tarefas aceitam um modelo menor, outras devem esperar ou ir para uma pessoa.
• O cliente precisa receber uma mensagem clara de degradação, e a equipe precisa de métricas e alertas para saber que o agente está operando fora do normal.

Qual a diferença entre limite de taxa e queda do provedor?

Limite de taxa significa que o provedor está funcionando, mas recusou a chamada porque a conta passou do volume permitido em uma janela de tempo. Esses limites costumam ser medidos em requisições e em tokens, e variam conforme o plano e a conta, então o ponto de partida é ler a documentação do seu provedor e confirmar os valores no painel da conta. A resposta típica é o status HTTP 429, muitas vezes acompanhado de um cabeçalho que indica quando tentar de novo.

Queda ou degradação é outra situação: o serviço responde com erro de servidor, demora demais ou simplesmente não responde. Aqui, insistir no mesmo modelo por muito tempo não adianta. Pode haver uma indisponibilidade parcial, restrita a um modelo ou a uma região, e nesse caso existe alternativa dentro do próprio provedor ou em outro.

Separar os dois casos evita dois desastres opostos. O primeiro é trocar de modelo por causa de um simples pico, o que muda a qualidade da resposta sem necessidade. O segundo é ficar esperando um modelo que está fora do ar, enquanto clientes aguardam sem resposta.

Como classificar o erro antes de decidir o que fazer

O primeiro componente é uma camada única que recebe o erro do provedor e o classifica. Sem isso, cada fluxo reage de um jeito e o comportamento do agente fica imprevisível. Um guia de decisão simples cobre a maior parte dos casos:

• Limite de taxa (429): não troque de modelo de imediato. Respeite o tempo de espera informado pelo provedor, se houver, e recoloque a tarefa na fila com atraso.
• Erro temporário de servidor ou tempo esgotado: tente de novo com backoff, com poucas tentativas. Se persistir, acione o fallback.
• Sobrecarga do provedor: trate como temporário, mas reduza a vazão do seu lado em vez de aumentar a pressão.
• Erro de requisição inválida (contexto grande demais, parâmetro errado): não repita. Isso é bug ou limite de entrada, e retentar só gasta capacidade. Registre e corrija.
• Erro de autenticação ou permissão: não repita e não use fallback às cegas. Alerte a equipe, porque pode ser chave expirada ou revogada.
• Resposta recebida, mas reprovada pela validação de saída: isso não é falha de infraestrutura. Siga a regra de guardrails para validar saídas e decida entre nova tentativa controlada e transbordo.

Os códigos exatos e o formato dos cabeçalhos mudam de provedor para provedor. Por isso a classificação deve ficar em um único módulo, fácil de ajustar quando você trocar ou acrescentar um fornecedor.

Filas: como absorver picos sem perder mensagens

Em um agente no WhatsApp, a mensagem do cliente chega por webhook e o modelo é chamado em seguida. Se a chamada ao modelo acontece dentro do próprio webhook, qualquer lentidão ou limite vira mensagem perdida ou duplicada. A solução é separar as etapas: o webhook apenas valida, grava a mensagem e a coloca em uma fila. Um processo à parte consome a fila no ritmo que o provedor permite.

Alguns cuidados fazem diferença na prática:

• Limite de concorrência: defina quantas chamadas ao modelo podem estar em andamento ao mesmo tempo e mantenha esse valor abaixo do que a conta suporta.
• Prioridade: mensagens de clientes aguardando resposta ao vivo passam na frente de tarefas em lote, como resumos noturnos ou classificações em massa.
• Ordem por conversa: mensagens da mesma conversa devem ser processadas em sequência, para o agente não responder fora de ordem.
• Prazo de validade: uma resposta que ficou tempo demais na fila pode já não fazer sentido. Defina até quando vale tentar e o que acontece depois (transbordo ou aviso).
• Fila de mensagens mortas: tarefas que esgotaram as tentativas vão para um lugar visível, com o contexto necessário para uma pessoa assumir.

A fila também é o ponto natural para controlar custo, porque você enxerga o volume antes de ele chegar ao provedor. Para reduzir consumo, vale combinar com as técnicas de cache, roteamento e compactação de tokens, que diminuem a pressão sobre o limite.

Backoff com jitter e retentativa segura

Backoff exponencial significa esperar mais a cada nova tentativa: um intervalo curto na primeira, maior na segunda, maior ainda na terceira. Jitter é um pouco de aleatoriedade nesse intervalo. Sem ele, todas as tarefas que falharam juntas tentam de novo juntas, e o pico se repete em ondas. Com jitter, as tentativas se espalham no tempo.

Uma política de retentativa responsável tem estes elementos:

• Respeitar o tempo de espera informado pelo provedor, quando existir, em vez de usar apenas o cálculo local.
• Ter um número máximo de tentativas e um tempo total máximo por tarefa.
• Tentar de novo apenas os erros classificados como temporários.
• Usar um limitador do seu lado, para não depender só do erro do provedor para desacelerar.
• Interromper as tentativas de forma coletiva quando muitos erros acontecem em sequência (disjuntor ou circuit breaker), dando tempo para o provedor se recuperar.

O ponto mais negligenciado é a idempotência. Se o agente chamou o modelo, decidiu criar um pedido no ERP e a resposta se perdeu no caminho, uma nova tentativa pode criar o pedido duas vezes. A regra é que ações com efeito externo carreguem uma chave de idempotência, de modo que repetir a mesma operação não gere um segundo efeito. A documentação de requisições idempotentes da Stripe é um exemplo claro de como um provedor define esse contrato, e o mesmo raciocínio vale para os seus sistemas internos. Separe também a chamada ao modelo (que pode ser repetida) da execução da ação (que precisa de chave e, em casos sensíveis, de aprovação humana).

Fallback de modelo: quando trocar e quando avisar

Fallback é ter um plano B quando o modelo principal não responde. Ele pode ser outro modelo do mesmo provedor, um modelo menor, um segundo provedor ou, em alguns casos, um modelo hospedado por você. Cada opção tem custo de manutenção: prompts que funcionam bem em um modelo podem se comportar diferente em outro, e dados passam a trafegar por mais um fornecedor, o que importa para a LGPD e para o contrato.

Por isso, a pergunta certa não é qual modelo usar no fallback, e sim quais tarefas aceitam fallback. Um jeito prático de decidir:

• Tarefas de baixo risco e formato rígido, como classificar o assunto de uma mensagem ou extrair um número de pedido: aceitam um modelo menor ou alternativo, desde que a saída passe pela mesma validação.
• Tarefas de resposta livre ao cliente: aceitam fallback apenas se o modelo reserva foi testado com os mesmos casos de avaliação do principal. Caso contrário, prefira esperar na fila ou fazer transbordo.
• Tarefas que executam ações (cancelar, reembolsar, alterar cadastro): em modo degradado, devem ir para aprovação humana ou ficar pausadas, não ser delegadas a um modelo não testado.
• Tarefas com dados sensíveis: só use um segundo provedor se ele já estiver avaliado e coberto pelo registro de operações e pelo contrato. Em dúvida, não use.

Antes de ativar qualquer reserva, rode o mesmo conjunto de casos de teste nos dois modelos e compare. Esse conjunto também mostra o que muda de comportamento, como tom, tamanho da resposta e uso de ferramentas. Se a decisão envolve comparar modelos, o artigo sobre como comparar Kimi K2.5 e Claude Opus 4.5 mostra um método de teste que pode ser adaptado ao seu caso.

Para estruturar o agente de modo que a troca seja simples, o texto da Anthropic sobre construção de agentes eficazes defende começar com padrões simples e componíveis, o que facilita isolar a chamada ao modelo atrás de uma interface única e trocá-la quando necessário.

O que dizer ao cliente quando o agente está degradado

Mesmo com fila e fallback, haverá momentos em que a resposta demora ou não vem. O que o cliente vê nessa hora define se ele espera ou desiste. Uma mensagem de degradação boa é curta, não inventa causa técnica, diz o que acontece a seguir e oferece um caminho.

Um exemplo de texto para um atendimento no WhatsApp:

Estamos com lentidão no atendimento automático agora. Sua mensagem foi recebida e uma pessoa da equipe vai responder em horário comercial, ou você pode continuar por aqui que retomamos assim que possível.

Boas práticas para essas mensagens:

• Enviar o aviso uma vez por conversa, não a cada mensagem do cliente.
• Nunca prometer prazo que a operação não consegue cumprir.
• Não fingir que a resposta é normal quando veio de um modelo reserva em tarefa sensível.
• Registrar que a conversa foi marcada como degradada, para a equipe priorizar depois.
• Para pedidos urgentes (cancelamento, problema com pagamento, saúde), acionar o transbordo imediatamente, seguindo o playbook de transbordo humano no WhatsApp.

A mensagem também precisa de um modo de operação definido: normal, degradado e pausado. No modo degradado, o agente responde apenas o que é seguro e encaminha o resto. No modo pausado, só recebe e organiza. Quem decide a mudança de modo deve ser uma regra explícita (por exemplo, erros em sequência acima de um limite), com alerta para a equipe, e não uma improvisação durante o incidente.

Cenário ilustrativo e plano de implantação

Cenário ilustrativo: uma loja online tem um agente que responde dúvidas de pedido e troca no WhatsApp. Após uma campanha, o volume de mensagens cresce de repente e o provedor começa a devolver limite de taxa. Sem fila, o webhook falha, o WhatsApp reenvia mensagens e o agente responde duas vezes a alguns clientes. Com o desenho descrito aqui, as mensagens entram na fila, o agente processa no ritmo permitido, consultas de rastreio (baixo risco) usam um modelo menor quando a espera cresce, pedidos de troca aguardam o modelo principal ou vão para a equipe, e os clientes recebem um único aviso de lentidão. Ao fim do dia, a equipe vê quantas conversas ficaram degradadas e quantas foram para transbordo.

Para chegar a esse ponto, um plano em etapas funciona bem:

• Passo um: liste todos os pontos do fluxo que chamam o modelo e classifique cada tarefa por risco (leitura, resposta, ação).
• Passo dois: centralize a chamada ao modelo em um único módulo, com classificação de erros e registro de cada tentativa.
• Passo três: coloque a fila entre o canal e o modelo, com limite de concorrência, prioridade e prazo de validade.
• Passo quatro: implemente backoff com jitter, teto de tentativas, disjuntor e chaves de idempotência para ações.
• Passo cinco: defina quais tarefas aceitam fallback, teste o modelo reserva com os mesmos casos de avaliação e documente as diferenças.
• Passo seis: escreva as mensagens de degradação, os modos de operação e as regras de transbordo.
• Passo sete: instrumente o fluxo com métricas de erro, tempo de espera na fila, uso de fallback e conversas degradadas, e crie alertas.
• Passo oito: simule falhas de propósito (limite artificial, provedor indisponível) antes de ir para produção.

Sobre observabilidade, as convenções semânticas do OpenTelemetry para IA generativa ajudam a padronizar o que registrar em cada chamada, como modelo usado, erro e duração, sem inventar um formato próprio.

No método que adotamos, isso se encaixa em mapear, limitar, pilotar e transferir. Mapear é descobrir quais fluxos dependem do modelo e o que acontece com o negócio se cada um parar. Limitar é decidir o que o agente pode fazer em modo degradado. Pilotar é testar um fluxo real com registros e uma métrica combinada, como o piloto de automação com métricas e gates de decisão descreve. Transferir é entregar para a equipe o runbook, os alertas e a decisão de expandir, ajustar ou parar.

Perguntas frequentes

Devo ter um segundo provedor de LLM desde o início? Não necessariamente. Comece com fila, backoff e transbordo, que resolvem a maioria dos incidentes curtos. Um segundo provedor faz sentido quando a indisponibilidade custa caro ao negócio, e deve vir acompanhado de testes, revisão de contrato e verificação de como os dados pessoais serão tratados.

Quantas vezes posso tentar de novo uma chamada que falhou? Não há número universal. Defina um teto baixo de tentativas e um tempo total máximo por tarefa, de acordo com o quanto o cliente aguenta esperar. Depois disso, a tarefa deve ir para fallback, para uma pessoa ou para a fila de mensagens mortas, e não ficar repetindo indefinidamente.

O fallback para um modelo menor pode piorar a resposta ao cliente? Pode, e por isso ele deve ser limitado a tarefas testadas e de baixo risco. Rode os mesmos casos de avaliação nos dois modelos, valide a saída com as mesmas regras e, para respostas sensíveis ou ações, prefira esperar ou encaminhar para uma pessoa.

Como saber que o agente está operando em modo degradado? Registre cada tentativa, erro e troca de modelo, e crie alertas para sequências de falhas, fila crescendo e uso frequente do fallback. Assim a equipe é avisada antes de o cliente reclamar, e consegue revisar depois quais conversas foram afetadas.

Fontes

• Stripe: requisições idempotentes
• Anthropic: Building effective agents
• OpenTelemetry: convenções semânticas para IA generativa