Resumo

  • A documentação da própria GroqCloud mede a vazão em oito unidades nomeadas, no nível da organização, e em seguida remete cada cliente às configurações da própria conta para saber o número que de fato se aplica: a página pública é uma convenção de medição antes de ser um teto.
  • Dois sinais de falha distintos correspondem a duas causas distintas — 429 quando uma taxa medida é excedida, 498 quando a capacidade Flex não está disponível — e o documento capaz de transformar qualquer um deles em obrigação contratual não estava entre as páginas recuperadas para esta revisão.

Um limite é uma convenção de medição antes de ser um número

A página de limites de taxa começa nomeando o que conta, e não o que permite. O trecho retido diz: “Rate limits are measured in: RPM: Requests per minute RPD: Requests per day TPM: Tokens per minute TPD: Tokens per day ASH: Audio seconds per hour ASD: Audio seconds per day ITPM: Input tokens per minute OTPM: Output tokens per minute.”

Essa lista informa mais do que um único número de vazão. Oito dimensões em vez de uma significam que o envelope tem oito paredes. Duas delas são expressas em segundos de áudio, o que indica que modelos de voz são medidos por um relógio diferente do usado para texto. Outras duas separam a contabilidade de tokens entre entrada e saída, o que importa porque cargas dominadas por instruções e cargas dominadas por geração consomem orçamentos diferentes. E duas são diárias em vez de por minuto: uma rajada pode ser suportável no curto prazo e ainda assim esgotar o dia.

A mesma página fixa o nível de agregação e a regra de desempate com palavras próprias: “Rate limits apply at the organization level, not individual users. You can hit any limit type depending on which threshold you reach first.” Acrescenta também que “Cached tokens do not count towards your rate limits”, uma concessão real para quem repete instruções com prefixo estável.

Junte essas três afirmações e a forma prática da restrição aparece. Dez serviços, cinco equipes e um reprocessamento em lote atrás de uma única organização compartilham um só envelope. A parede que ata é a que cede primeiro, e nenhuma página publicada diz a um operador específico qual será, porque os números não estão lá.

O número aplicável é delegado a uma página atrás de autenticação

A documentação não deixa o leitor sem direção. Tal como é apresentada, a página avisa que os limites podem ter exceções e que os valores exatos vigentes devem ser consultados na página de limites dentro das configurações da conta do leitor. Essa instrução é a frase de maior consequência de todo o conjunto, e é também a razão pela qual esta revisão não pode enunciar o limiar de nenhuma organização: a página para a qual ela aponta está atrás de autenticação e não foi lida aqui.

O que permanece público é uma convenção com uma instrução de encaminhamento. Uma equipe pode aprender as unidades, o nível de agregação e a regra de desempate na web aberta. Não pode aprender o próprio teto na web aberta, e um terceiro avaliando o serviço — analista de compras, jornalista, concorrente preparando um argumento de substituição — também não.

Um plano publica uma base; os demais limites só são descritos como maiores

O catálogo de modelos é onde números de fato aparecem, e delimita o alcance com cuidado: “Need higher rate limits? Upgrade to Developer plan to access higher limits, Batch and Flex processing, and more. Note that the limits shown below are the base limits for the Developer plan, and higher limits are available for select workloads and enterprise use cases.”

Três consequências se seguem. A tabela publicada é um piso para um plano, não um teto do serviço. Limites maiores são descritos como existentes para cargas de trabalho selecionadas e não nomeadas e para casos empresariais, o que os torna um resultado negociado em vez de publicado. E a expressão “base limits” admite variação sem enunciar suas dimensões.

Essa concessão explica por que o documento de preços importa, e por que o silêncio dele é um achado. A página de preços retida para esta revisão é texto de posicionamento — “Groq is the premier neocloud for fast inference … Fast or affordable is no longer a tradeoff. We're building hundreds of megawatts of capacity, with many more on the way” — sem tabela de planos, sem valores de limite e sem especificação de camadas de processamento no texto lido. Quem tentar estabelecer nas páginas públicas da Groq qual plano compra qual envelope não fechará a questão nessa página. A correspondência entre plano e limite não é estabelecida pelos documentos deste conjunto.

O teto se move com o modelo, e o modelo pode se mover sob seus pés

Como os limites são apresentados linha por modelo, o envelope é específico do modelo por construção. Um plano de capacidade expresso em um único número está, portanto, subespecificado antes mesmo de algo dar errado: troque o modelo servido e a restrição muda de forma.

Tal como é apresentada, a tabela do plano Developer traz, entre outras linhas, openai/gpt-oss-120b a 250K tokens por minuto e 1K requisições por minuto. Esse valor é relatado a partir da renderização do fornecedor de uma linha de tabela, não lido aqui como uma tabela completa, e vale como ilustração do formato, não como especificação do serviço.

A mesma página acrescenta uma segunda forma de movimento: modelos em prévia podem ser descontinuados com aviso curto. É um acoplamento documentado entre o catálogo e o teto. Uma carga ajustada a uma linha de prévia herda o ciclo de vida dessa linha, e nenhum documento de limites consegue estabilizar um limite preso a um modelo que pode ser retirado.

Dois códigos de falha carregam dois significados

A página de erros entrega a metade visível ao cliente em uma frase: “429 Too Many Requests: Too many requests were sent in a given timeframe. Implement request throttling and respect rate limits.” Conforme a página de limites é apresentada, um 429 é também o único caso em que um cabeçalho retry-after é definido, e os cabeçalhos de limite expostos aos clientes incluem x-ratelimit-limit-requests para requisições por dia e x-ratelimit-limit-tokens para tokens por minuto. Esses cabeçalhos são a única evidência em tempo de execução que uma aplicação recebe sobre qual parede está se aproximando.

A documentação de Flex Processing então publica um segundo sinal, bastante diferente: “Flex Processing is a service tier optimized for high-throughput workloads that prioritizes fast inference and can handle occasional request failures. … If flex capacity is unavailable, requests will fail quickly with status 498 and error capacity_exceeded.” O Flex é relatado como oferecendo dez vezes mais limites de taxa que a camada sob demanda, pelo mesmo preço, para clientes pagos, e a página de erros lista 498 como um status personalizado cuja requisição “não será processada”, sem cobrança para requisições que devolvem códigos de erro de servidor.

Lidos juntos, 429 e 498 respondem a perguntas diferentes. O 429 diz que quem chamou excedeu uma taxa medida e deve reduzir o ritmo. O 498 diz que o provedor não tinha capacidade para aquela classe de trabalho e que a requisição nunca foi tentada. Uma política de nova tentativa escrita apenas contra o 429 tratará o 498 como ruído, tentará de novo imediatamente e gerará carga que não pode ter sucesso; o comportamento honesto de um cliente diante do 498 é uma decisão de adiamento, não um cálculo de espera.

A documentação de Batch afina essa distinção: descreve “an asynchronous batch of requests to Groq with 50% lower cost, no impact to your standard rate limits, and 24-hour to 7 day processing window”. O Batch não eleva o teto síncrono. Ele retira trabalho desse teto mudando o contrato temporal sob o qual o trabalho é comprado — um caminho mais barato e mais lento contornando uma parede que continua onde estava.

O documento que tornaria isto uma obrigação não foi lido

A única página do conjunto que fala no registro da obrigação são os termos de serviço, e a linguagem é uma ressalva limitada ao site: “YOUR USE OF THE WEBSITES (INCLUDING ANY THIRD-PARTY MATERIALS) IS AT YOUR SOLE RISK. THE WEBSITES … ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS. … GROQ MAKES NO WARRANTY THAT (A) THE WEBSITES WILL MEET YOUR REQUIREMENTS, (B) THE WEBSITES WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE.” Dessa mesma página também se relata um teto de responsabilidade de 100 dólares para reclamações relacionadas aos sites.

Duas fronteiras precisam ser ditas com clareza. Primeira: esse trecho rege os sites. Transportar uma ressalva de garantia sobre sites para um compromisso de disponibilidade de API seria um erro de categoria, e este artigo não o comete. Segunda: não foram obtidos para esta revisão nem o documento completo de termos, nem ordem de compra, nem contrato empresarial, nem acordo de nível de serviço separado. A ausência de percentuais de disponibilidade e de créditos de serviço em um trecho é evidência sobre o texto efetivamente lido, e sobre nada mais.

A classe de documento que decidiria se existe algum compromisso de disponibilidade com remédio é o instrumento de nível de serviço assinado ou a ordem de compra: papéis que se negociam mais do que se publicam, e a primeira coisa que um comprador sério deve pedir.

O que uma equipe pode planejar, e o que não pode

A superfície de controle é banal e decisiva. Equipes de engenharia dimensionam concorrência, fixam orçamentos de nova tentativa e escrevem a espera do lado do cliente contra um limite publicado, que leem como envelope operacional. O texto que de fato as obriga — o procedimento de mudança, a variação por modelo, as camadas de postergação e a presença ou ausência de um compromisso com créditos — está em documentos que quase nunca são lidos ao lado da tabela de limites.

Quando um número de central de ajuda é consumido como teto contratual, três falhas se seguem em sequência. A carga é dimensionada sobre um valor que pode se mover. A lógica de nova tentativa é ajustada a uma semântica de erro que ninguém verificou. E a lacuna aparece no pico de demanda como limitação que o modelo de capacidade da equipe não continha, justamente quando a fila tem menos folga para absorvê-la.

O que esta revisão pode afirmar com segurança é mais estreito que o marketing, e mais útil. A GroqCloud publica as unidades, o nível de agregação, a regra de desempate, a exclusão de tokens em cache, a base de um plano, uma estrutura por modelo e dois códigos de falha, com orientação ao cliente anexada a apenas um deles. Nas páginas lidas, não publica valor por conta, nem procedimento de mudança, nem tabela numérica por modelo para cada plano, nem compromisso de disponibilidade com remédio.

Os sete documentos foram recuperados em 19 de outubro de 2026; nenhum trazia data de publicação ou de última modificação, de modo que nenhuma data de efeito pode ser atribuída a qualquer limite aqui descrito.

Para a entidade em si, ver a ficha do diretório BTW para a Groq Inc..