Resumen

  • La documentación de GroqCloud mide el rendimiento en ocho unidades con nombre propio, a nivel de organización, y luego remite a cada cliente a los ajustes de su propia cuenta para conocer la cifra aplicable: la página pública es una convención de medida antes que un techo.
  • Se publican dos señales de fallo distintas para dos causas distintas — 429 cuando se supera una tasa medida, 498 cuando la capacidad Flex no está disponible — y el documento capaz de convertir cualquiera de las dos en obligación contractual no figuraba entre las páginas recuperadas para esta revisión.

Un límite es una convención de medida antes que una cifra

La página de límites de tasa empieza por nombrar lo que cuenta, no lo que permite. El extracto retenido dice: «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.»

Esa lista informa más que un único número de caudal. Ocho dimensiones y no una significan que el sobre tiene ocho paredes. Dos se expresan en segundos de audio, lo que indica que los modelos de voz se miden con un reloj distinto al de los modelos de texto. Otras dos separan la contabilidad de tokens de entrada y de salida, algo que importa porque una carga dominada por instrucciones y otra dominada por generación consumen presupuestos diferentes. Y dos son diarias en lugar de por minuto: una ráfaga puede ser absorbible a corto plazo y aun así agotar el día.

La misma página fija el nivel de agregación y la regla de desempate con sus propias palabras: «Rate limits apply at the organization level, not individual users. You can hit any limit type depending on which threshold you reach first.» Añade también que «Cached tokens do not count towards your rate limits», una concesión real para quien repite instrucciones con un prefijo estable.

Júntense esos tres enunciados y aparece la forma práctica de la restricción. Diez servicios, cinco equipos y un reproceso por lotes detrás de una sola organización comparten un único sobre. La pared que ata es la que cede primero, y ninguna página publicada dice a un operador concreto cuál será, porque las cifras no están allí.

La cifra aplicable se delega a una página tras autenticación

La documentación no deja al lector sin indicación. Tal como se muestra, la página advierte que los límites pueden tener excepciones y que las cifras exactas vigentes deben consultarse en la página de límites dentro de los ajustes de la cuenta del lector. Esa instrucción es la frase más consecuente de todo el conjunto, y también la razón por la que esta revisión no puede enunciar el umbral de ninguna organización: la página a la que remite está detrás de autenticación y no se leyó aquí.

Lo que queda público es una convención con una instrucción de desvío. Un equipo puede aprender las unidades, el nivel de agregación y la regla de desempate desde la web abierta. No puede aprender su propio techo desde la web abierta, y un tercero que evalúe el servicio —analista de compras, periodista, competidor preparando un argumento de sustitución— tampoco.

Un plan publica una base; el resto de límites solo se describen como superiores

El catálogo de modelos es donde aparecen cifras de verdad, y delimita su alcance con 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.»

De ahí se siguen tres cosas. La tabla publicada es un piso para un plan, no un techo del servicio. Los límites superiores se describen como existentes para cargas seleccionadas sin nombre y casos empresariales, lo que los convierte en un resultado negociado y no publicado. Y la expresión «base limits» concede una variación sin enunciar sus dimensiones.

Esa concesión explica por qué importa el documento de precios, y por qué su silencio es un hallazgo. La página de precios retenida para esta revisión es texto de posicionamiento —«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»— sin tabla de planes, sin cifras de límites y sin especificación de niveles de procesamiento en el texto leído. Quien intente establecer en las páginas públicas de Groq qué plan compra qué sobre no cerrará la pregunta en esa página. La correspondencia entre plan y límite no queda establecida por los documentos de este conjunto.

El techo se mueve con el modelo, y el modelo puede moverse debajo

Como los límites se presentan fila por modelo, el sobre es específico del modelo por construcción. Un plan de capacidad expresado en una sola cifra está, por tanto, subespecificado antes de que algo vaya mal: cambie el modelo servido y la restricción cambia de forma.

Tal como se muestra, la tabla del plan Developer incluye, entre otras filas, openai/gpt-oss-120b a 250K tokens por minuto y 1K solicitudes por minuto. Esa cifra se reporta a partir de la representación del proveedor de una fila de tabla, no se leyó aquí como una tabla completa, y vale como ilustración del formato, no como especificación del servicio.

La misma página añade una segunda forma de movimiento: los modelos en vista previa pueden retirarse con poco aviso. Es un acoplamiento documentado entre el catálogo y el techo. Una carga ajustada a una fila en vista previa hereda el ciclo de vida de esa fila, y ningún documento de límites puede estabilizar un límite atado a un modelo retirable.

Dos códigos de fallo con dos significados

La página de errores entrega la mitad visible para el cliente en una frase: «429 Too Many Requests: Too many requests were sent in a given timeframe. Implement request throttling and respect rate limits.» Según se muestra la página de límites, un 429 es además el único caso en que se establece una cabecera retry-after, y las cabeceras de límites expuestas a los clientes incluyen x-ratelimit-limit-requests para solicitudes por día y x-ratelimit-limit-tokens para tokens por minuto. Esas cabeceras son la única evidencia en ejecución que recibe una aplicación sobre la pared que se aproxima.

La documentación de Flex Processing publica después una segunda señal, muy distinta: «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.» Se reporta que Flex ofrece límites diez veces superiores al nivel bajo demanda, al mismo precio, para clientes de pago, y la página de errores lista 498 como estado personalizado cuya solicitud «no será procesada», sin cargo por solicitudes que devuelven códigos de error de servidor.

Leídos juntos, 429 y 498 responden a preguntas diferentes. 429 dice que quien llama superó una tasa medida y debe reducir el ritmo. 498 dice que al proveedor le faltó capacidad para esa clase de trabajo y que la solicitud nunca se intentó. Una política de reintento escrita solo contra 429 tratará el 498 como ruido, reintentará de inmediato y generará carga que no puede prosperar; el comportamiento honesto de un cliente ante 498 es una decisión de aplazamiento, no un cálculo de espera.

La documentación de Batch afina esa distinción: describe «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». Batch no eleva el techo síncrono. Saca trabajo de ese techo cambiando el contrato temporal con el que se compra —una vía más barata y lenta que rodea una pared que sigue donde estaba.

El documento que convertiría esto en obligación no se leyó

La única página del conjunto que habla en registro de obligación son los términos de servicio, y su lenguaje es una advertencia acotada al sitio: «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.» También se reporta desde esa página un tope de responsabilidad de 100 dólares estadounidenses para reclamaciones relacionadas con los sitios.

Hay que fijar dos fronteras con claridad. Primera: ese extracto rige los sitios web. Trasladar una advertencia de garantía sobre sitios a un compromiso de disponibilidad de API sería un error de categoría, y este artículo no lo comete. Segunda: no se recuperó para esta revisión ni un documento completo de términos, ni una orden de compra, ni un contrato empresarial, ni un acuerdo de nivel de servicio separado. La ausencia de porcentajes de disponibilidad y de créditos de servicio en un extracto es evidencia sobre el texto efectivamente leído, y nada más.

La clase de documento que zanjaría si existe algún compromiso de disponibilidad con remedio es un instrumento de nivel de servicio firmado o una orden de compra: papeles que se negocian más que se publican, y lo primero que un comprador serio debe pedir.

Qué puede planear un equipo y qué no

La superficie de control es mundana y decisiva. Los equipos de ingeniería dimensionan la concurrencia, fijan presupuestos de reintento y escriben su espera del lado cliente contra un límite publicado, que leen como sobre operativo. El texto que realmente los obliga —el procedimiento de cambio, la variación por modelo, los niveles de aplazamiento y la presencia o ausencia de un compromiso con créditos— vive en documentos que casi nunca se leen junto a la tabla de límites.

Cuando una cifra de centro de ayuda se consume como techo contractual, sobrevienen tres fallos en secuencia. La carga se dimensiona sobre una cifra que puede moverse. La lógica de reintento se ajusta a una semántica de error que nadie verificó. Y la brecha aparece en el pico de demanda como una limitación que el modelo de capacidad del equipo no contenía, justo cuando la cola tiene menos margen para absorberla.

Lo que esta revisión puede afirmar con seguridad es más estrecho que el marketing, y más útil. GroqCloud publica las unidades, el nivel de agregación, la regla de desempate, la exclusión de tokens en caché, la base de un plan, una estructura por modelo y dos códigos de fallo con guía de cliente adjunta a uno solo. En las páginas leídas no publica cifra por cuenta, ni procedimiento de cambio, ni tabla cifrada por modelo para cada plan, ni compromiso de disponibilidad con remedio.

Los siete documentos se recuperaron el 19 de octubre de 2026; ninguno llevaba fecha de publicación o de última modificación, así que no puede atribuirse fecha de efecto a ningún límite descrito aquí.

Para la entidad misma, véase la ficha del directorio BTW dedicada a Groq Inc..