O que realmente é um limite de taxa
UM limite de taxa é um limite para a rapidez com que você pode usar uma API. Os fornecedores impõem-nas para manter o serviço justo e estável: sem elas, um único loop com erros ou um pico de tráfego de um cliente poderia fazer com que todos os outros passassem fome, pelo que os limites protegem a capacidade, impõem níveis de plano e restringem abusos e ataques de negação de serviço. Quando você ultrapassa um limite, a API para de atendê-lo por um momento e retorna um HTTP 429 “Muitas solicitações” resposta em vez de fazer o trabalho.
Os limites vêm em algumas unidades comuns e você pode atingir qualquer um deles primeiro:
| Unidade | Significado | O que o esgota |
|---|---|---|
| RPM | Solicitações por minuto | Muitas chamadas pequenas e frequentes |
| TPM | Tokens por minuto (APIs LLM) | Algumas chamadas de grande contexto ou de saída longa |
| RPD | Solicitações por dia | Alto volume total em 24 horas (comum em níveis gratuitos) |
| Simultaneidade | Solicitações simultâneas durante o voo | Chamadas lentas que se sobrepõem (longas gerações, grandes uploads) |
Nas APIs LLM, os dois que mordem com mais frequência são RPM e TPM, e eles são independentes. Cinquenta pequenas chamadas de classificação podem ultrapassar o RPM e mal tocar no TPM; um resumo de documento de 100 mil tokens pode ultrapassar o TPM em uma única solicitação. Projete para qualquer teto que sua carga de trabalho alcance primeiro.
Transformar um limite de TPM em “quantos usuários posso atender?”
O planejamento de capacidade é apenas aritmética. Comece pelos tokens um usuário consome por minuto e divida seu limite por ele.
- Tokens por solicitação = tokens de entrada (prompt + mensagem do sistema + contexto) mais tokens de saída que o modelo gera. Ambos contam contra o TPM.
- Solicitações por usuário por minuto = quão falador é um usuário ativo.
- Tokens por usuário por minuto = tokens por solicitação × solicitações por usuário por minuto.
Exemplo: cada turno de bate-papo usa aproximadamente 1.500 entradas + aproximadamente 500 saídas = 2.000 fichas, e um usuário ativo envia aproximadamente 1,5 voltas por minuto → 3.000 tokens/usuário/minuto. Com um 300.000 TPM limite você pode servir aproximadamente 300.000 ÷ 3.000 = 100 usuários ativos simultâneos. Faça a mesma divisão em relação ao seu limite de RPM e pegue o menor das duas respostas - esse é o seu teto real. Nota "ativo" significa envio ativo; um produto com 100 usuários simultâneos geralmente possui milhares de contas conectadas.
Calculadora de capacidade de limite de taxa →Calculadora de limite de taxa →Níveis: gastar mais aumenta seus limites
A maioria dos provedores executa níveis de uso. Novas contas começam com baixo RPM/TPM/RPD; à medida que você gasta mais e sua conta envelhece, você é automaticamente promovido para níveis mais altos com limites muito maiores – às vezes 10× ou 100× os números iniciais. Se você está atingindo os limites, as primeiras perguntas são: em que nível estou e estou qualificado para o próximo? Os acordos empresariais e de gastos comprometidos podem aumentar ainda mais os limites ou adicionar capacidade dedicada.
Técnicas que ampliam seu rendimento efetivo
- Lote — combine muitos itens em menos solicitações maiores para aliviar a pressão de RPM. As APIs em lote dedicadas dos provedores também funcionam com desconto para trabalhos não urgentes.
- Transmissão — o streaming de tokens de volta não aumenta seu orçamento de tokens, mas reduz a latência percebida e libera recursos do cliente mais cedo, de forma que as solicitações sobrepostas sejam resolvidas mais rapidamente.
- Recuo e ritmo - distribuir as chamadas uniformemente ao longo do minuto, em vez de dispará-las todas de uma vez, mantém você sob limites explosivos que, de outra forma, você tropeçaria.
- Corte de tokens — prompts mais curtos, cache de prompts e limites de saída rígidos aumentam diretamente o número de solicitações que cabem em um orçamento fixo de TPM.
Lidando com 429s: espera, novas tentativas e enfileiramento
Atingir um limite é normal – a questão é se o seu aplicativo se recupera normalmente. O padrão padrão é backoff exponencial com jitter: em um 429, espere um pouco e tente novamente; se falhar novamente, aproximadamente dobre o atraso de cada vez (por exemplo, 1s, 2s, 4s, 8s) e adicione um pequeno deslocamento aleatório para que muitos clientes não tentem novamente em sincronia. Sempre respeite um Tentar novamente depois cabeçalho se o provedor enviar um - informa exatamente quanto tempo esperar.
Limite rígido vs limite suave / burst
UM limite rígido é um teto absoluto – exceda-o e todas as solicitações serão rejeitadas até que a janela seja reiniciada. UM soft or burst limit permite picos curtos acima de sua taxa constante (geralmente por meio de um balde de tokens que é recarregado com o tempo), de modo que breves rajadas passam, mas a sobrecarga sustentada ainda é acelerada. Saber o que você enfrenta muda sua estratégia: os limites de estouro recompensam a suavização do tráfego pela janela; limites rígidos exigem um verdadeiro fila que mede as solicitações a uma taxa segura.
- Fila de trabalho não urgente portanto, ele drena em um ritmo controlado, em vez de sobrecarregar a API.
- Distribuir carga uniformemente, em vez de estourar no início de cada minuto.
- Limitar total de tentativas portanto, uma solicitação condenada falha de forma limpa, em vez de ficar em loop para sempre.
O ângulo do custo: limita a arquitetura da forma, não a conta
Os limites de taxa não custam dinheiro diretamente - você nunca é cobrado por um 429. Mas eles influenciam fortemente a forma como você constrói e essas escolhas fazer tem um custo. Quando uma única chave não consegue fornecer a taxa de transferência necessária, as equipes geralmente recorrem a um cadeia de reserva (fazer failover para um segundo modelo ou provedor quando o principal for limitado), múltiplas chaves ou provedores para reunir capacidade, e um API em lote para empurrar empregos não urgentes para vias mais baratas e com limites mais altos. Cada um adiciona resiliência e espaço, mas também complexidade de integração e, às vezes, preços mais altos por token no substituto. A abordagem mais saudável é aumentar seu nível e reduzir os tokens primeiro e, em seguida, adicionar redundância apenas onde um limite rígido realmente o bloquear.
Como funciona o preço da API LLM →Mais guias de aprendizagem →Perguntas frequentes
Qual é a diferença entre RPM e TPM?
O RPM (solicitações por minuto) limita quantas chamadas de API você pode fazer a cada minuto, enquanto o TPM (tokens por minuto) limita a quantidade de texto que essas chamadas podem mover. Você pode atingir qualquer um dos limites primeiro – muitas chamadas pequenas esgotam o RPM, enquanto algumas chamadas de contexto grande esgotam o TPM.
Como transformo um limite de TPM no número de usuários que posso atender?
Estime os tokens que um usuário consome por minuto (os tokens por solicitação multiplicam as solicitações por usuário por minuto, contando a entrada e a saída) e, em seguida, divida seu limite de TPM por esse valor. Se um usuário precisar de 3.000 tokens/minuto e seu limite for 300.000 TPM, você poderá atender cerca de 100 usuários ativos simultâneos.
Como devo lidar com um erro 429 Too Many Requests?
Tente novamente com espera exponencial e jitter – espere progressivamente mais tempo entre as tentativas e respeite qualquer cabeçalho Retry-After que o provedor retornar. Enfileirar trabalhos não urgentes, distribuir a carga uniformemente em vez de estourar e limitar o total de novas tentativas para que uma solicitação acabe falhando de forma limpa, em vez de ficar em loop para sempre.
Apenas para referência educacional – limites exatos, unidades e níveis variam de acordo com o provedor; confirme os valores atuais na documentação de limite de taxa de cada provedor.