Zusammenfassung

  • Die eigene Dokumentation von GroqCloud misst den Durchsatz in acht benannten Einheiten auf Organisationsebene und verweist anschließend jeden Kunden auf die Einstellungen seines eigenen Kontos für die tatsächlich geltende Zahl: Die öffentliche Seite ist eine Messkonvention, bevor sie eine Obergrenze ist.
  • Zwei unterschiedliche Fehlersignale stehen für zwei unterschiedliche Ursachen — 429 bei Überschreitung einer gemessenen Rate, 498 bei fehlender Flex-Kapazität — und das Dokument, das eines davon in eine vertragliche Pflicht verwandeln könnte, war unter den für diese Prüfung abgerufenen Seiten nicht.

Ein Limit ist eine Messkonvention, bevor es eine Zahl ist

Die Seite zu den Ratenlimits beginnt damit, zu benennen, was gezählt wird, nicht was erlaubt ist. Der überlieferte Auszug lautet: „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.“

Diese Liste sagt mehr als eine einzelne Durchsatzzahl. Acht Dimensionen statt einer bedeuten, dass die Hülle acht Wände hat. Zwei davon lauten auf Audiosekunden, was zeigt, dass Sprachmodelle an einer anderen Uhr gemessen werden als Textmodelle. Zwei weitere trennen die Token-Abrechnung in Eingabe und Ausgabe, was zählt, weil promptlastige und generierungslastige Arbeitslasten aus unterschiedlichen Budgets schöpfen. Und zwei sind täglich statt minütlich: Ein Schub kann kurzfristig tragbar sein und den Tag dennoch erschöpfen.

Dieselbe Seite legt Aggregationsebene und Stichentscheid in eigenen Worten fest: „Rate limits apply at the organization level, not individual users. You can hit any limit type depending on which threshold you reach first.“ Sie hält außerdem fest: „Cached tokens do not count towards your rate limits“ — eine echte Erleichterung für alle, die Eingaben mit stabilem Präfix wiederholen.

Setzt man diese drei Aussagen zusammen, erscheint die praktische Form der Beschränkung. Zehn Dienste, fünf Teams und eine Batch-Nachberechnung unter einer einzigen Organisation teilen eine einzige Hülle. Die bindende Wand ist jene, die zuerst nachgibt, und keine veröffentlichte Seite sagt einem bestimmten Betreiber, welche das sein wird, weil die Zahlen dort nicht stehen.

Die geltende Zahl ist an eine Seite hinter Anmeldung delegiert

Die Dokumentation lässt den Leser nicht ohne Hinweis. So wie die Seite dargestellt wird, heißt es dort, Limits könnten Ausnahmen haben, und die aktuell exakten Werte seien auf der Limits-Seite in den Einstellungen des eigenen Kontos zu lesen. Dieser Satz ist der folgenreichste des ganzen Satzes, und er ist zugleich der Grund, warum diese Prüfung keine Schwelle einer Organisation nennen kann: Die Seite, auf die er verweist, liegt hinter einer Anmeldung und wurde hier nicht gelesen.

Öffentlich bleibt eine Konvention samt Weiterverweisung. Ein Team kann Einheiten, Aggregationsebene und Stichentscheid aus dem offenen Netz lernen. Es kann seine eigene Obergrenze nicht aus dem offenen Netz lernen, und ein Dritter, der den Dienst bewertet — Einkaufsanalyst, Journalist, Wettbewerber mit einem Ablöseargument — ebenso wenig.

Ein Tarif veröffentlicht einen Grundwert, alle anderen Limits gelten nur als höher

Der Modellkatalog ist der Ort, an dem tatsächlich Zahlen erscheinen, und er grenzt sie sorgfältig ein: „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.“

Drei Folgerungen. Die veröffentlichte Tabelle ist ein Boden für einen Tarif, keine Obergrenze des Dienstes. Höhere Limits werden als vorhanden für unbenannte ausgewählte Arbeitslasten und Unternehmensfälle beschrieben, was sie zu einem ausgehandelten statt veröffentlichten Ergebnis macht. Und die Formulierung „base limits“ räumt eine Varianz ein, ohne deren Dimensionen zu nennen.

Dieses Zugeständnis erklärt, warum das Preisdokument zählt und warum sein Schweigen ein Befund ist. Die für diese Prüfung überlieferte Preisseite ist Positionierungstext — „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“ — ohne Tariftabelle, ohne Limitwerte und ohne Angabe der Verarbeitungsstufen im gelesenen Text. Wer aus Groqs öffentlichen Seiten ableiten will, welcher Tarif welche Hülle kauft, wird die Frage dort nicht schließen. Die Zuordnung von Tarif und Limit ist durch die Dokumente dieses Satzes nicht belegt.

Die Obergrenze wandert mit dem Modell, und das Modell kann sich unter Ihnen bewegen

Weil Limits je Modellzeile dargestellt werden, ist die Hülle konstruktionsbedingt modellspezifisch. Ein Kapazitätsplan in einer einzigen Zahl ist damit unterbestimmt, bevor irgendetwas schiefgeht: Tauschen Sie das bediente Modell, ändert sich die Form der Beschränkung.

So wie die Tabelle dargestellt wird, führt die Developer-Tabelle unter anderem openai/gpt-oss-120b mit 250K Token pro Minute und 1K Anfragen pro Minute. Dieser Wert ist aus der Darstellung des Anbieters einer Tabellenzeile berichtet, hier nicht als vollständige Tabelle gelesen, und taugt als Illustration des Formats, nicht als Spezifikation des Dienstes.

Dieselbe Seite fügt eine zweite Art von Bewegung hinzu: Vorschaumodelle können mit kurzer Ankündigung eingestellt werden. Das ist eine dokumentierte Kopplung zwischen Katalog und Obergrenze. Eine an einer Vorschauzeile kalibrierte Arbeitslast erbt deren Lebenszyklus, und kein Limitdokument kann ein Limit stabilisieren, das an einem zurückziehbaren Modell hängt.

Zwei Fehlercodes tragen zwei Bedeutungen

Die Fehlerseite liefert die clientseitig sichtbare Hälfte in einem Satz: „429 Too Many Requests: Too many requests were sent in a given timeframe. Implement request throttling and respect rate limits.“ So wie die Limits-Seite dargestellt wird, ist 429 zugleich der einzige Fall, in dem ein retry-after-Header gesetzt wird, und die den Clients offengelegten Limit-Header umfassen x-ratelimit-limit-requests für Anfragen pro Tag und x-ratelimit-limit-tokens für Token pro Minute. Diese Header sind der einzige Laufzeitbeleg, den eine Anwendung darüber erhält, welcher Wand sie sich nähert.

Die Dokumentation zu Flex Processing veröffentlicht dann ein zweites, ganz anderes Signal: „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.“ Flex wird als zehnfach höhere Ratenlimits zum gleichen Preis für zahlende Kunden berichtet, und die Fehlerseite führt 498 als eigenen Status, dessen Anfrage „nicht verarbeitet wird“, ohne Berechnung für Anfragen, die Serverfehlercodes zurückgeben.

Zusammengelesen beantworten 429 und 498 verschiedene Fragen. 429 sagt, der Aufrufer habe eine gemessene Rate überschritten und solle langsamer werden. 498 sagt, dem Anbieter fehlte Kapazität für diese Arbeitsklasse und die Anfrage wurde nie versucht. Eine Retry-Richtlinie, die nur gegen 429 geschrieben ist, behandelt 498 als Rauschen, wiederholt sofort und erzeugt Last, die nicht gelingen kann; ehrliches Clientverhalten bei 498 ist eine Aufschubentscheidung, keine Backoff-Rechnung.

Die Batch-Dokumentation schärft diese Unterscheidung: Sie beschreibt „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 hebt die synchrone Obergrenze nicht an. Es nimmt Arbeit aus dieser Grenze heraus, indem es den Zeitvertrag ändert, unter dem die Arbeit gekauft wird — eine billigere, langsamere Spur um eine Wand herum, die stehen bleibt.

Das Dokument, das daraus eine Pflicht machen würde, wurde nicht gelesen

Die einzige Seite dieses Satzes, die im Register der Verpflichtung spricht, sind die Nutzungsbedingungen, und ihre Sprache ist ein auf die Website begrenzter Haftungsausschluss: „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.“ Von derselben Seite wird zudem eine Haftungsobergrenze von 100 US-Dollar für Ansprüche im Zusammenhang mit den Websites berichtet.

Zwei Grenzen sind hier klar zu ziehen. Erstens: Dieser Auszug regelt die Websites. Einen Website-Gewährleistungsausschluss auf eine API-Verfügbarkeitszusage zu übertragen, wäre ein Kategorienfehler, und dieser Artikel begeht ihn nicht. Zweitens: Weder ein vollständiges Bedingungswerk noch eine Bestellung, ein Unternehmensvertrag oder eine gesonderte Service-Level-Vereinbarung wurde für diese Prüfung abgerufen. Das Fehlen von Verfügbarkeitsprozenten und Servicegutschriften in einem Auszug ist ein Beleg über den tatsächlich gelesenen Text und über nichts sonst.

Die Dokumentklasse, die klären würde, ob eine Verfügbarkeitszusage mit Rechtsfolge an GroqCloud geknüpft ist, ist ein unterzeichnetes Service-Level-Instrument oder eine Bestellung — Papiere, die verhandelt statt veröffentlicht werden und die ein ernsthafter Käufer zuerst verlangen sollte.

Was ein Team planen kann und was nicht

Die Steuerungsfläche ist unspektakulär und folgenreich. Engineering-Teams dimensionieren Nebenläufigkeit, setzen Retry-Budgets und schreiben clientseitiges Backoff gegen ein veröffentlichtes Limit, das sie als Betriebshülle lesen. Der Text, der sie tatsächlich bindet — das Änderungsverfahren, die Variation je Modell, die Aufschubstufen und das Vorhandensein oder Fehlen einer gutschriftbewehrten Zusage —, steht in Dokumenten, die fast nie neben der Limittabelle gelesen werden.

Wird eine Help-Center-Zahl als vertragliche Obergrenze konsumiert, folgen drei Fehler in Serie. Die Arbeitslast wird auf eine Zahl dimensioniert, die sich bewegen kann. Die Retry-Logik wird auf eine Fehlersemantik abgestimmt, die niemand geprüft hat. Und die Lücke zeigt sich in der Lastspitze als Drosselung, die das Kapazitätsmodell des Teams nicht enthielt, genau dann, wenn die Warteschlange am wenigsten Spielraum hat, sie aufzunehmen.

Was diese Prüfung belastbar sagen kann, ist enger als das Marketing und nützlicher. GroqCloud veröffentlicht die Einheiten, die Aggregationsebene, den Stichentscheid, die Ausnahme für zwischengespeicherte Token, den Grundwert eines Tarifs, eine Struktur je Modell und zwei Fehlercodes, wobei nur einer eine Client-Anweisung trägt. In den gelesenen Seiten veröffentlicht es keine kontobezogene Zahl, kein Änderungsverfahren, keine Zahlentabelle je Modell für jeden Tarif und keine Verfügbarkeitszusage mit Rechtsfolge. Alle sieben Dokumente wurden am 19.

Oktober 2026 abgerufen; keines trug ein Veröffentlichungs- oder Änderungsdatum, sodass keinem hier beschriebenen Limit ein Geltungsdatum zugeordnet werden kann.

Zur Entität selbst siehe den BTW-Verzeichniseintrag zu Groq Inc..