Rate limit em APIs de LLM: como evitar quebra em produção

Rate limit em APIs de LLM é o teto de requisições ou tokens que o provedor libera por minuto para a sua chave de acesso, e quando esse teto estoura a chamada falha com erro 429 em vez de devolver uma resposta. Acontece com qualquer fornecedor, seja Anthropic, OpenAI ou Google, e costuma pegar o time de surpresa justo quando o produto começa a escalar de verdade. Na prática, dá para evitar que isso quebre seu fluxo com fila de retry, backoff exponencial e um plano B de modelo, sem reescrever a aplicação inteira.

Eu já vi esse erro derrubar demo em produção porque ninguém tinha testado o que acontece quando cem usuários mandam prompt ao mesmo tempo. Funciona liso no ambiente de testes, com uma chamada por vez, e quebra na primeira sexta-feira de tráfego real. Isso não é falha de modelo, é falta de plano para o rate limit.

O que é rate limit e por que ele existe

Todo provedor de LLM aplica algum tipo de limite: requisições por minuto, tokens por minuto, ou os dois somados. Isso protege a infraestrutura deles e também evita que uma chave comprometida gaste um orçamento absurdo em segundos.

Na minha visão, não é frescura do provedor. Rodar inferência de modelo grande custa caro em GPU, e sem limite qualquer bug de loop infinito no seu código viraria fatura de cinco dígitos da noite para o dia.

O limite geralmente varia conforme:

• o plano da conta (free tier, pay as you go, enterprise)
• o modelo específico usado na chamada
• o histórico de uso da chave nos últimos dias

Contas novas costumam ter rate limit bem mais apertado. Se seu produto está crescendo rápido, vale acompanhar o painel do provedor antes de bater no teto sem aviso.

Sinais de que você vai bater no limite

Tem alguns sinais que aparecem antes do erro 429 virar rotina no seu log.

O primeiro é latência crescente sem mudança de prompt ou modelo. O segundo é picos de uso concentrados em horário comercial, típico de produto B2B. O terceiro é múltiplos serviços internos usando a mesma chave de API sem coordenação, cada um achando que tem o limite inteiro para si.

Se você já notou isso, vale revisar como está medindo latência de LLM em produção, porque rate limit e latência costumam aparecer juntos no mesmo incidente.

Como o rate limit aparece na prática

O erro 429

O provedor retorna código 429 (too many requests) quando a chamada estoura o limite. Junto costuma vir um cabeçalho indicando quanto tempo esperar antes de tentar de novo.

O problema não é o erro em si. É o time tratar esse erro como falha genérica de rede e simplesmente tentar de novo na mesma hora, o que só piora a fila e derruba o serviço para todo mundo que usa a mesma chave.

Limite por token vs limite por requisição

Alguns provedores limitam número de chamadas por minuto. Outros limitam tokens processados por minuto, contando entrada e saída juntas. Prompt grande com contexto longo esbarra mais rápido nesse segundo tipo, mesmo fazendo poucas chamadas.

Se seu fluxo usa contexto extenso, vale entender quando contexto longo compensa frente a RAG antes de simplesmente aumentar o prompt e esperar que o rate limit não seja problema.

Estratégias para lidar sem quebrar o fluxo

Não tem mistério aqui, mas tem etapa que engana quem implementa correndo.

Retry com backoff exponencial

Quando a chamada falha por rate limit, o certo é esperar um pouco e tentar de novo, aumentando o tempo de espera a cada nova tentativa. Isso evita que dez chamadas voltem a bater no limite ao mesmo tempo, no exato segundo em que o teto libera de novo.

Você pode pedir para a IA implementar essa lógica descrevendo o comportamento esperado: capturar o erro específico de limite excedido, esperar um tempo crescente entre tentativas, e desistir depois de um número máximo de tentativas, retornando erro claro para quem chamou. Depois, valide olhando os logs: a tentativa seguinte a um erro 429 apareceu depois do intervalo esperado, ou o sistema tentou de novo na hora, sem esperar nada?

Fila em vez de disparo simultâneo

Se seu fluxo dispara várias chamadas de uma vez, tipo processar cem documentos de uma tacada, colocar essas chamadas numa fila com limite de concorrência evita estourar o rate limit logo de cara. Isso é diferente de processar tudo em paralelo sem controle, que parece mais rápido no papel e quebra na prática.

Fallback de modelo ou provedor

Para fluxos críticos, ter um segundo modelo configurado como plano B ajuda bastante. Se o modelo principal está com rate limit estourado, a chamada cai para outro modelo ou outro provedor, mesmo que com qualidade ligeiramente diferente. Melhor responder algo do que travar a aplicação inteira.

Isso conversa direto com o tema de roteamento de LLMs para cada tipo de tarefa, porque o mesmo mecanismo de rotear por custo ou qualidade serve para rotear por disponibilidade.

Rate limit fixo vs dinâmico: quando cada provedor aplica

Alguns provedores aplicam limite fixo por chave, simples de prever. Outros ajustam o limite dinamicamente conforme o histórico de uso, aumentando aos poucos conforme sua conta demonstra consumo estável.

Quando o limite é fixo, o trabalho é dimensionar sua aplicação para caber dentro dele. Quando é dinâmico, o trabalho é crescer o uso de forma gradual, sem picos absurdos, para o próprio provedor liberar mais espaço com o tempo. Confesso que prefiro provedores com limite fixo e documentado, porque dá para planejar sem depender de heurística que o provedor não explica direito.

Documentação oficial costuma trazer os números exatos por modelo e por plano. Vale consultar direto a documentação de rate limits da Anthropic antes de assumir qualquer número de cabeça.

O custo de ignorar o rate limit

Ignorar isso não é neutro. Sem tratamento adequado, o usuário final recebe erro genérico no meio de um fluxo importante, tipo checkout ou geração de relatório. O time de suporte recebe reclamação sem saber a causa raiz. E o pior, muita gente confunde rate limit com instabilidade do modelo, e sai trocando de provedor achando que vai resolver, quando o problema era falta de retry.

Esse tipo de decisão apressada custa caro, e conversa direto com como você está estimando e controlando custo de LLM em produção, porque trocar de modelo no meio do incidente raramente é a resposta certa.

Ferramentas que ajudam a gerenciar isso

Você não precisa construir tudo do zero. Um gateway unificado na frente das chamadas de LLM já cuida de boa parte do retry e do roteamento entre provedores automaticamente. Eu já usei isso em produção e funciona bem para reduzir código repetido em cada serviço.

Se você quer parar de reescrever a mesma lógica de retry em cada projeto, dá uma olhada em como funciona o LiteLLM como gateway unificado para múltiplas APIs de LLM. Resolve? Resolve bem. É a única forma? Não, mas é a mais direta para quem já tem mais de um provedor no fluxo.

Perguntas frequentes

O que causa erro 429 em API de LLM?

O erro 429 acontece quando sua chave excede o número de requisições ou tokens permitidos por minuto pelo provedor. É diferente de erro de servidor: significa que o pedido chegou certo, mas passou do limite combinado no seu plano.

Como evitar rate limit em produção?

Combine retry com backoff exponencial, fila de concorrência limitada e, se possível, um modelo ou provedor de fallback. Monitorar o volume de chamadas por minuto antes de escalar o produto também evita surpresa.

Rate limit é o mesmo em todos os provedores?

Não. Cada provedor define limites próprios, alguns por número de requisições, outros por tokens processados, e o valor muda conforme o plano contratado e o histórico de uso da conta.

Vale a pena pagar plano maior para evitar rate limit?

Depende do volume real do seu produto. Se picos de rate limit já afetam usuário final com frequência, o plano maior costuma sair mais barato que o custo de suporte e retrabalho gerado pelos erros.

Conclusão

Rate limit em APIs de LLM não é bug nem falha do modelo, é regra de negócio do provedor que precisa entrar no seu plano de arquitetura desde cedo. Quem trata isso como exceção rara acaba descobrindo o problema no pior momento possível, com usuário real travado no meio do fluxo.

Se seu produto já roda em produção, vale revisar agora como seu sistema reage a um 429: espera direito, tenta de novo com bom senso, ou simplesmente quebra na cara do usuário?

Próximos passos:

• Revise os logs da última semana procurando por erro 429 e veja se já existe tentativa de retry configurada
• Compare o rate limit do seu plano atual com o volume real de chamadas nos horários de pico
• Leia sobre roteamento de LLMs para montar um plano B de modelo antes do próximo incidente