Todo serviço com API tem limite de taxa, e o do Jev tem dois. Vale entender os dois separadamente, porque eles apertam em situações diferentes — e porque a resposta certa para um deles não é a mesma para o outro.
Os dois números
A página oficial de modelos declara:
| Limite | Valor |
|---|---|
| Vazão de tokens | 250.000 tokens por segundo |
| Requisições | 1.200 por minuto |
Uma requisição que passa de qualquer um dos dois recebe 429 Too Many Requests.
E vem o aviso, que é parte do fato. A TypeSafe escreve que está atendendo um volume muito grande de demanda e que esses limites podem mudar sem aviso enquanto isso durar, conforme acordos de GPU forem fechados e mais usuários forem admitidos. Ela diz também que limites maiores existem em planos sob medida e empresariais. Ou seja: estes números são o estado de hoje, não um contrato. Qualquer dimensionamento que dependa deles precisa de uma folga deliberada.
Qual dos dois aperta primeiro
Esta é a conta que decide o desenho da sua fila, e ela é simples.
Mil e duzentas requisições por minuto são 20 requisições por segundo. Para consumir 250.000 tokens por segundo com 20 requisições, cada chamada precisaria levar 12.500 tokens.
- Se as suas chamadas são menores que isso — e a maioria é: nas nossas cinco medições de 18 de setembro de 2026, com seis perguntas cada, a média foi de 955 tokens de entrada — quem limita você é o teto de requisições.
- Se você manda documentos longos, o teto de tokens chega primeiro. Com 32.000 tokens por chamada, o limite de vazão corresponde a menos de 8 requisições por segundo.
Saber qual dos dois manda muda o remédio: no primeiro caso, agrupar perguntas
resolve; no segundo, é preciso cortar o state.
Como transformar isso em paralelismo
A fórmula prática é a de Little, aplicada a chamadas: o número de requisições em voo que você sustenta é a taxa desejada multiplicada pela latência média.
Com a latência que medimos — entre 270 e 802 milissegundos de ida e volta, mediana de 538, medida de fora e incluindo rede — uma requisição por trabalhador leva cerca de meio segundo. Para chegar a 20 requisições por segundo com essa latência, você precisa de cerca de 10 trabalhadores em paralelo. Mais do que isso não aumenta a vazão: só produz 429.
Três regras que seguem daí:
Fixe o paralelismo, não deixe crescer. Um pool de tamanho fixo é o mecanismo mais simples e o mais eficaz. Escalar o número de processos sem limitar a concorrência total é como o 429 constante costuma nascer.
Deixe folga. Como os limites mudam sem aviso, dimensionar para 100% do teto é dimensionar para falhar. Trabalhar em torno de 70% dá espaço para uma mudança do outro lado.
Conte tokens, não só chamadas. Se o seu lote mistura documentos curtos e longos, o teto de vazão pode ser atingido por um punhado de chamadas grandes enquanto o contador de requisições está tranquilo.
Agrupar perguntas é a maior economia
Este é o ponto em que o desenho da chamada e o limite de taxa se encontram.
Dez perguntas sobre o mesmo conteúdo podem ir em dez requisições ou em uma. Em
dez, você gasta dez das suas 1.200 requisições por minuto e envia o
state dez vezes, o que multiplica os tokens. Em uma, gasta uma requisição e
envia o state uma vez.
O cookbook oficial de perguntas paralelas mediu o efeito em uma tarefa de 13 perguntas sobre um artigo longo: 12,2 vezes mais barato e 10,0 vezes mais rápido que 13 chamadas separadas, sem mudança nas respostas. O mesmo agrupamento que economiza dinheiro também libera cota. O padrão está em fan-out especulativo e a receita completa em perguntas paralelas.
O que fazer quando o 429 chega
Esporádico: deixe o SDK cuidar. A política padrão repete com backoff e
respeita o Retry-After; no SDK Python, a exceção de limite de taxa expõe
retry_after_ms com o tempo que o servidor pediu. Os detalhes estão em
retentativas e tempo limite.
Constante: retentativa não resolve. Se todos os trabalhadores batem no limite, repetir apenas redistribui a mesma rajada alguns segundos adiante. Reduza o paralelismo, agrupe perguntas e, se o volume for realmente maior que o teto, fale com a TypeSafe — a própria documentação aponta os planos sob medida.
Em pico previsível: enfileire. Uma fila com taxa controlada na saída transforma um pico em um platô, e é a única solução que não depende de o servidor colaborar.
Um exemplo de controle simples
import asyncio
SEMAFORO = asyncio.Semaphore(10) # ~20 req/s com latência de ~0,5 s
async def avaliar(item):
async with SEMAFORO:
return await client.system_one(state=item.state, questions=PERGUNTAS)
Dez permissões, latência de meio segundo, cerca de vinte requisições por segundo. O semáforo é o que impede o resto do código de decidir sozinho quantas chamadas existem ao mesmo tempo.
Para o orçamento de contexto de cada chamada, veja o contexto de 64k. O índice está em como usar.
Perguntas frequentes
Quais são os limites de taxa do Jev?
A página oficial de modelos declara 250.000 tokens por segundo e 1.200 requisições por minuto. Uma requisição que passa de qualquer um dos dois recebe 429 Too Many Requests.
Esses limites são estáveis?
Não, e a TypeSafe avisa isso por escrito. Ela diz que está atendendo um volume muito grande de demanda, que os limites podem mudar sem aviso enquanto isso durar, e que limites maiores existem em planos sob medida e empresariais. Trate os números como o estado de hoje, não como contrato.
Qual dos dois limites aperta primeiro?
Depende do tamanho do state. Com 1.200 requisições por minuto, ou 20 por segundo, você só encosta no teto de 250.000 tokens por segundo se cada chamada levar mais de 12.500 tokens. Abaixo disso, o limite de requisições é o que manda.
Como eu evito o 429 em vez de reagir a ele?
Controlando o paralelismo antes da chamada. Retentativa resolve o caso esporádico; se o 429 é constante, o problema é de dimensionamento da fila e repetir só redistribui a rajada.
Agrupar perguntas ajuda a caber no limite?
Ajuda no limite de requisições e não ajuda no de tokens. Juntar dez perguntas em uma chamada gasta uma requisição em vez de dez, e o state é enviado uma vez só em vez de dez, então economiza nos dois. É o motivo prático do padrão de fan-out.