Rate limits de APIs de LLM: 13 provedores e 2 SDKs sem retry
Conteúdo
Das treze APIs de LLM analisadas aqui (dez fornecedores, além de Bedrock, Vertex AI e Azure OpenAI), quatro informam o saldo restante em todas as respostas, a Mistral envia apenas um contador e oito não dizem nada até a chamada falhar. Um “429” pode representar quatro situações diferentes: throttling que deve ser repetido, limite de aceleração que exige reduzir o ritmo, cota ou teto de gastos que não deve ser repetido e sobrecarga, informada como 429, 503 ou 529 conforme o fornecedor. O cliente também tem mais influência do que parece: os SDKs da OpenAI, Anthropic e Groq repetem um 429 duas vezes e desistem se o Retry-After passar de 60 ou 120 segundos, enquanto os SDKs Google GenAI e Mistral vêm com retries desativados. Esta é uma referência comparativa entre fornecedores, baseada no código-fonte: dimensões, tokens contabilizados, headers, semântica do 429 e comportamento de cada SDK oficial.
TL;DR
- APIs de LLM aplicam throttling por requisições e tokens por minuto. A Anthropic separa entrada e saída; a DeepSeek limita apenas a concorrência.
- OpenAI, Azure e Bedrock debitam
max_tokensantecipadamente. A Anthropic isenta leituras de cache, a xAI conta reasoning e o Bedrock consome 10 tokens de cota por token de saída do Claude 5. - OpenAI, Anthropic, Groq e Azure retornam headers de saldo restante e reset em todo 200. Oito APIs não documentam nenhum.
- Os SDKs google-genai e Mistral não repetem um 429 por padrão. OpenAI, Anthropic e Groq repetem duas vezes e limitam o Retry-After a 60 ou 120 segundos.
O que significam RPM, TPM e os outros limites?
Todos definem o volume máximo permitido em uma janela. Cada provedor escolhe seu próprio conjunto:
| Grupo | Termos | O que significam e quem os utiliza |
|---|---|---|
| Medidores de requisições | RPM, RPD, RPS, concorrência | Requisições por minuto ou por dia, contando uma por chamada independentemente do tamanho. Em geral, RPS é o RPM dividido por 60 e funciona como proteção contra rajadas (xAI, Alibaba, Mistral, Azure). A concorrência mede chamadas em andamento, não chamadas por janela, e é o único limite da DeepSeek |
| Medidores de tokens | TPM, TPD, ITPM, OTPM, burndown rate | Tokens por minuto ou por dia. Alguns provedores separam entrada (ITPM) e saída (OTPM). O burndown rate multiplica os tokens de saída antes de debitá-los da cota (Bedrock). Cada provedor também decide quais tokens entram na conta, como veremos a seguir |
| Medidores de outras unidades | IPM, segundos de áudio, páginas de OCR | Imagens por minuto em modelos de imagem (OpenAI, Gemini), segundos de áudio por hora ou dia (Groq, Mistral) e páginas por minuto para OCR de documentos (Mistral) |
| Como a janela é aplicada | Token bucket, limite de aceleração | Um token bucket é reabastecido continuamente, em vez de ser zerado a cada minuto. Por isso, uma rajada pode esvaziá-lo mesmo sem ultrapassar o total por minuto (Anthropic; Alibaba e Azure descrevem o mesmo efeito). O limite de aceleração verifica separadamente a velocidade de crescimento do uso e pode ser atingido por um aumento repentino mesmo abaixo do limite (Anthropic, slow_down da OpenAI) |
| O que define seus números | Tier, teto de gastos ou cota, capacidade provisionada | O tier define os medidores acima e aumenta conforme o uso pago ou o histórico, não com recargas de crédito. Um teto de gastos ou uma cota diária limita dinheiro ou volume, não taxa, portanto esperar um minuto não resolve. Capacidade provisionada é throughput reservado, cobrado por unidade por hora (Bedrock e Vertex AI Provisioned Throughput, Azure PTU). Nesse caso, um 429 indica que a reserva está cheia, não que a cota acabou |
O número exibido é o teto da janela, não uma franquia. A Anthropic avisa que 60 RPM “podem ser aplicados como 1 requisição por segundo”. A Azure diz que “uma rajada dentro de uma janela de 1 segundo ou 10 segundos pode gerar um 429 mesmo que o total por minuto esteja dentro dos limites”.
O que as APIs de LLM limitam?
Quase todas limitam requisições e tokens por minuto. As três clouds não apenas repassam as regras dos fornecedores. As definições abaixo são dos próprios provedores, conforme as páginas vinculadas em 2026-09-03 e 2026-09-04.
| Provedor | Dimensões | Como os limites aumentam | Fonte |
|---|---|---|---|
| OpenAI | RPM, RPD, TPM, TPD, IPM, minutos de áudio por minuto; fila da Batch API por tokens de entrada enfileirados | Tiers 1 a 5 por pagamento acumulado | limites de uso |
| Anthropic | RPM, ITPM e OTPM por classe de modelo; token bucket; limites de aceleração | Tiers Start, Build e Scale por histórico de uso | limites de uso |
| Google Gemini | RPM, TPM (entrada), RPD; IPM em modelos de imagem | Gratuito, depois Tiers 1 a 3 com limites de gastos por 10 minutos | limites de uso |
| xAI | RPS (RPM / 60) e TPM por modelo | Tiers 0 a 4, além do Enterprise | limites de uso |
| Alibaba Model Studio | RPM e TPM por modelo, com RPS = RPM / 60 e TPS = TPM / 60 como proteção contra rajadas | Por modelo; batch isento em alguns modelos | limites de uso |
| DeepSeek | Apenas concorrência: 500 conexões no V4 Pro, 2,500 no V4 Flash | Fixo por modelo | limite de uso |
| Mistral | RPS, tokens por minuto e tokens por mês, por modelo e workspace | Tiers 1 a 4 por faturamento acumulado; “Adicionar créditos não aumenta seus limites de uso” | uso e limites, central de ajuda |
| MiniMax | RPM e TPM por modelo; MiniMax M3 com 200 RPM e 10M TPM | Contate a equipe comercial | limites de uso |
| Moonshot Kimi | Concorrência, RPM, TPM, TPD; Tier 0 com 1 chamada concorrente e 3 RPM, Tier 5 com 100 e 300 | Seis tiers por recarga acumulada, $1 a $3,000 | limites |
| Groq | RPM, RPD, TPM, TPD, ITPM, OTPM, segundos de áudio por hora e dia | Por modelo | limites de uso |
| Amazon Bedrock | RPM, TPM e TPD por modelo e região; TPD padrão igual a TPM x 1,440 | Service Quotas, aumentadas sob solicitação; contas novas começam com limites menores | cotas |
| Google Vertex AI | Nenhum valor por projeto no pay-as-you-go: um pool compartilhado em que “o histórico de gastos da organização determina o Usage Tier e o throughput base (TPM)”, com rajadas em modo best effort | Usage tier por gastos; Provisioned Throughput “isola do pool PayGo compartilhado” | blog do Google Cloud |
| Azure OpenAI | TPM atribuído por deployment, com RPM derivado dele (6 RPM por 1,000 TPM em modelos antigos, 1 RPM por 1,000 TPM nos atuais); deployments PTU limitados pela utilização | Tiers de cota 0 a 6, com upgrade automático | cotas e limites, gerenciamento de cotas |
Duas linhas nem sequer usam janelas por minuto. A DeepSeek limita conexões abertas e, sob carga, mantém a requisição aberta com linhas vazias (ou comentários : keep-alive em streaming) por até 10 minutos, em vez de rejeitá-la. No pay-as-you-go da Vertex AI, não há um valor de cota disponível: um 429 significa que faltou capacidade no pool compartilhado naquele momento.
Quais tokens entram no limite?
Nem sempre são os mesmos tokens faturados. Essa diferença pode reduzir a capacidade real a uma fração do valor anunciado ou multiplicá-la:
| Provedor | O que entra no limite de tokens | Consequência |
|---|---|---|
| OpenAI | O maior valor entre max_tokens e uma estimativa baseada no prompt, debitado na chegada: “Se você definir max_tokens alto demais, seu uso pode ser superestimado, mesmo que a resposta real seja muito menor” (cookbook) | Um max_tokens de 4,000 tokens para uma resposta de 50 tokens consome 4,000 do seu TPM |
| Azure OpenAI | Uma estimativa baseada em “texto e quantidade do prompt, configuração do parâmetro max_tokens, configuração do parâmetro best_of”, calculada parcialmente pela quantidade de caracteres; em deployments PTU, “tokens em cache recebem 100% de desconto” (guia de cotas) | “Um limite pode ser acionado antes do esperado”; quando max_tokens não é definido, o serviço faz a estimativa |
| Amazon Bedrock | ”Total de tokens de entrada + max_tokens” debitado no início, com correção ao final para InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate), sem contar leituras de cache. O burndown é 5x no Claude 4.7 e anteriores, 10x no Sonnet 5, Opus 5, Fable 5.1 e nos modelos GPT-5.6, e 15x no Claude 4.8 (contagem de tokens) | No exemplo documentado, 1,000 tokens de entrada e 100 de saída em um modelo 5x consomem 1,500 tokens de cota e faturam 1,100 |
| Anthropic | ITPM conta input_tokens e cache_creation_input_tokens; cache_read_input_tokens “NÃO entram no ITPM”. OTPM conta a saída real; “max_tokens não entra no cálculo de OTPM” (documentação) | No exemplo documentado, 2M ITPM com 80% de cache hit processam 10M tokens de entrada por minuto |
| xAI | ”Todos os tokens consumidos por uma requisição entram no limite de TPM: tokens do prompt (texto, imagem e áudio), tokens de completion, tokens de reasoning (em modelos de reasoning) e tokens de prompt em cache” | Reasoning consome TPM com tokens que você não vê; o cache não aumenta o throughput |
| Google Gemini | Tokens de entrada | O tamanho da saída não reduz o limite |
| Alibaba, Mistral, MiniMax | Entrada mais saída | |
| Kimi, Groq, DeepSeek, Vertex AI | Não informado | A Groq mede ITPM e OTPM separadamente; a DeepSeek não tem limite de tokens; a Vertex AI publica apenas uma base por usage tier |
A mesma requisição tem um tamanho diferente em cada limite, de 800 a 6,000 tokens no exemplo acima. Um roteador que distribui uma carga entre fornecedores precisa manter um medidor para cada um.
Quais headers cada provedor retorna?
Quatro APIs incluem o estado dos limites em todas as respostas, a Mistral envia um campo e as outras oito deixam a contagem por sua conta.
| Provedor | Headers em uma resposta normal | Observações de formato |
|---|---|---|
| OpenAI | x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens, além do trio -project-tokens | Reset é “o tempo até o limite ser redefinido”; Retry-After no 429 |
| Azure OpenAI | Os mesmos seis nomes x-ratelimit-* em todas as chamadas; retry-after-ms e retry-after no 429 | Um x-ratelimit-limit-tokens abaixo do TPM configurado indica que um “ajuste temporário do limite” está ativo |
| Anthropic | anthropic-ratelimit-requests-{limit,remaining,reset}, o mesmo trio para tokens, input-tokens e output-tokens, além de anthropic-priority-* e anthropic-fast-* quando esses tiers se aplicam | Reset em RFC 3339; saldo restante arredondado para o milhar mais próximo; o trio tokens-* mostra “o limite mais restritivo em vigor no momento” |
| Groq | x-ratelimit-limit-requests (diário), x-ratelimit-limit-tokens (por minuto), x-ratelimit-remaining-*, x-ratelimit-reset-*; “sempre incluídos” | Reset como duração, "2m59.56s", "7.66s"; retry-after em segundos, apenas no 429 |
| Mistral | X-RateLimit-Remaining | |
| Gemini, xAI, Alibaba, DeepSeek, MiniMax, Kimi, Bedrock, Vertex AI | Nenhum documentado | Gemini, Alibaba e Bedrock informam o motivo no corpo do erro; a Kimi documenta Retry-After em caso de sobrecarga; os SDKs da AWS leem x-amz-retry-after em milissegundos quando o serviço o envia |
O problema prático é haver três formatos para o mesmo campo: a duração da OpenAI, o timestamp da Anthropic e o 2m59.56s da Groq exigem três parsers. Esse é um dos motivos para os SDKs lerem apenas retry-after. Dois intermediários foram medidos em 2026-09-03, com uma requisição para cada um. Um grande agregador multiprovedor não retornou nenhum header de limite em um 200, reservando-os para respostas 429. O gateway Synthorai retornou x-ratelimit-remaining-requests e x-ratelimit-reset-requests junto com o custo da requisição.
O que significa um 429 e quando repetir?
Depende de qual das quatro situações ocorreu. Só duas justificam retry:
| Significado | Repetir? | Como cada provedor identifica |
|---|---|---|
| Throttling: você ultrapassou um limite | Sim, depois de Retry-After ou backoff | OpenAI e Anthropic com 429 rate_limit_error, a Anthropic com retry-after; Gemini e Vertex AI com 429 RESOURCE_EXHAUSTED, que na Vertex AI indica falta momentânea no pool compartilhado; Kimi rate_limit_reached_error; Bedrock ThrottlingException, além de ModelNotReadyException, repetido pelo SDK até 5 vezes; Azure “Rate limit is exceeded”; xAI RateLimitError; Alibaba “Requests rate limit exceeded”; DeepSeek e Mistral com 429 |
| Aceleração: o volume cresceu rápido demais | Reduza o ritmo e depois repita | OpenAI slow_down; Anthropic com “limites de aceleração”; Alibaba “Request rate increased too quickly”; Azure, uma rajada dentro de uma janela de 1 segundo ou 10 segundos |
| Cota ou teto de gastos: esperar não libera capacidade | Não; corrija o faturamento ou aguarde a data de reset | OpenAI insufficient_quota, credit_balance_exhausted, organization_spend_limit_exceeded; Anthropic enforced_spend_limit_reached sem retry-after, enquanto o teto definido por você retorna 400; Gemini quota_exceeded (diário); Kimi exceeded_current_quota_error; Bedrock 400 ServiceQuotaExceededException; agregador e DeepSeek com 402. Na Azure, a cota é atribuída no momento do deployment, portanto esgotá-la não gera 429 |
| Sobrecarga: falta de capacidade do provedor, não sua | Sim, com backoff | OpenAI 503 server_is_overloaded; Anthropic 529 overloaded_error; Gemini 503 UNAVAILABLE; Kimi 429 engine_overloaded_error com Retry-After; Bedrock 503 ServiceUnavailableException e 529 overloaded_error; Azure “System is experiencing high demand”, um “ajuste temporário do limite” no pool compartilhado ou PTU com 100% de utilização e retry-after-ms; DeepSeek 503 |
A armadilha está na terceira linha. O 429 de teto de gastos da Anthropic usa o mesmo tipo rate_limit_error de um throttling, e a documentação diz: “As novas tentativas, inclusive as automáticas dos SDKs, falham até o acesso ser retomado.” O insufficient_quota da OpenAI também é um 429. Um cliente que decide apenas pelo status code repete ambos, assim como todos os SDKs oficiais, como mostra a próxima seção. Decida pelo código do erro e trate um 429 sem Retry-After como indício de que esperar não resolverá.
A quarta linha mostra onde as clouds divergem. O guia de troubleshooting da Azure é direto: “Muitos clientes interpretam incorretamente 429s relacionados à capacidade como problemas de cota, o que leva à correção errada.” Na Azure, um 429 com x-ratelimit-limit-tokens abaixo do limite configurado significa que o pool compartilhado está se protegendo. Na Vertex AI, todo 429 de pay-as-you-go significa isso. No Bedrock, a mesma condição retorna 503 ou 529, nunca ThrottlingException. Por um agregador, o motivo aparece no corpo: durante a medição dos headers, um 429 chegou encapsulado como provider_error_code: insufficient_quota, limit_source: upstream_provider_shared_pool. O status indicava throttling; o corpo indicava a cota de outra pessoa.
O que seu SDK faz com um 429?
Depende do SDK, e dois dos mais usados não fazem nada. Os dados abaixo vêm do código-fonte de cada cliente oficial em 2026-09-04, não da documentação:
| SDK | Retries por padrão | Status repetidos | Backoff | Tratamento de Retry-After |
|---|---|---|---|---|
| openai-python (também Azure OpenAI) | 2 | 408, 409, 429, 5xx ou qualquer indicação de x-should-retry | min(0.5 × 2^n, 8) s com jitter | Lê retry-after-ms, depois retry-after como segundos ou data; acima de 120 s, não repete |
| anthropic-sdk-python, groq-python | 2 | os mesmos | o mesmo | Mesmo parsing; acima de 60 s, o header é ignorado e a fórmula de backoff é usada |
| openai-node, anthropic-sdk-typescript | 2 | os mesmos | o mesmo | O mesmo; acima de 60 s, volta ao backoff padrão |
| google-genai (Python, Gemini API e Vertex AI) | 0: retry_options usa None por padrão, o que resulta em uma única tentativa | Quando ativado: 408, 429, 500, 502, 503, 504 | Quando ativado: 5 tentativas, começando em 1 s e dobrando até 60 s, com jitter | Não lê Retry-After |
| mistralai (Python) | 0: retry_config não vem definido | Quando configurado: 429, 500, 502, 503, 504 | Quando configurado: 500 ms × 1.5^n até 60 s, 1 h no total | Respeita qualquer Retry-After, em segundos ou como data |
| boto3 (Bedrock) | Modo legacy: 5 tentativas incluindo a primeira; modo standard: 3 | ThrottlingException e similares, 429, 5xx | Fator base 2, limite de 20 s no modo standard. O comportamento de 2026 (opt-in com AWS_NEW_RETRIES_2026=true) usa full jitter, base de 1,000 ms para throttling e um retry token bucket | Sem Retry-After; o comportamento de 2026 lê x-amz-retry-after em milissegundos, limitado ao backoff mais 5 s |
| xai-sdk (Python, gRPC) | 5 tentativas, apenas para UNAVAILABLE | RESOURCE_EXHAUSTED, o equivalente gRPC do 429, não é repetido | 0.1 s, dobrando até 1 s | n/a |
| dashscope (Alibaba) | 0 por status HTTP; um reenvio se uma conexão do pool cair antes da chegada de qualquer byte | |||
| DeepSeek, Kimi, MiniMax | Sem SDK próprio para chat; a documentação da DeepSeek orienta a “usar o SDK da OpenAI/Anthropic” com outra base URL |
Daí saem três conclusões. Primeiro, um 429 do Gemini, Vertex AI ou Mistral chega ao seu código na primeira ocorrência, a menos que você configure retries. O comentário no código do google-genai dizendo que o cliente “tentará novamente 4 vezes” descreve a configuração ativada, não o padrão. Segundo, os limites aplicados ao Retry-After entram em conflito com esperas longas realmente solicitadas pelos fornecedores: se a Anthropic pedir 90 segundos, seu SDK ignora o header e volta em menos de 8; se a OpenAI pedir 150, seu SDK não repete. Terceiro, os SDKs gerados pela Stainless (o gerador de código usado pelos clientes da OpenAI, Anthropic e Groq) obedecem ao header não documentado x-should-retry antes de verificar o status code, e a retry-after-ms antes de retry-after. Assim, um fornecedor ou gateway consegue controlar os retries sem alterar o status code.
Nenhum deles diferencia um 429 de teto de gastos de um throttling. Duas repetições de uma resposta insufficient_quota custam poucos segundos cada, mas uma frota fazendo isso em escala cria sua própria rajada.
Como um gateway muda esse cenário?
O gateway é o único ponto em que tudo isso pode ser resolvido uma vez. Do lado upstream, ele lê o header específico de cada fornecedor, portanto os três formatos de reset e os quatro significados de 429 deixam de ser problema de cada cliente. Do lado downstream, ele expõe um conjunto único de headers e um formato único de erro, como nos headers medidos da Synthorai acima. O gateway não consegue mudar a contabilização do fornecedor: por trás da OpenAI, o max_tokens do cliente ainda debita TPM antecipadamente; por trás do Bedrock, cada token de saída do Claude ainda consome dez. Além disso, quando um gateway reúne muitos clientes sob uma única chave do fornecedor, atinge o limite de aceleração antes de qualquer cliente isolado. Esse é um caso para buckets por chave, não para um contador compartilhado.
Perguntas frequentes
max_tokens entra no limite?
Na OpenAI, Azure OpenAI e Bedrock, sim: max_tokens é debitado quando a requisição chega, portanto um valor superdimensionado desperdiça TPM mesmo com uma resposta curta. O Bedrock corrige o débito quando a resposta termina. Na Anthropic, não: OTPM conta os tokens efetivamente gerados e max_tokens “não entra no cálculo”.
Tokens em cache entram no limite?
Não na Anthropic, no Bedrock nem em deployments Azure PTU, onde as leituras de cache são excluídas. Na xAI, entram integralmente. OpenAI e Gemini não informam.
Retry-After sempre acompanha um 429?
Não. OpenAI, Azure (como retry-after-ms) e Groq enviam em throttling. A Anthropic envia em throttling, mas não no teto de gastos. Kimi e Bedrock enviam apenas em sobrecarga. Gemini, Vertex AI, xAI, Alibaba, DeepSeek e MiniMax não documentam nenhum, portanto o cliente precisa implementar seu próprio backoff nesses casos.
Por que meu SDK não repetiu um 429?
Se for o SDK Python do Google GenAI ou da Mistral, retries vêm desativados por padrão: passe retry_options ou um RetryConfig. Se for o SDK Python da OpenAI e o servidor pediu mais de 120 segundos, o SDK deliberadamente não repete. Se o 429 indicar cota ou teto de gastos, e não throttling, não repetir foi a decisão correta.
Relacionado: guia de unidades de cobrança, faixas de preço para contexto longo, anatomia do uso de tokens, auditoria de cache do gateway.