LLM Rate Limits 2026: RPM, TPM und Parallelitätsgrenzen aller großen Provider

Requests pro Minute (RPM) deckelt, wie viele API-Aufrufe Sie in einem 60-Sekunden-Fenster tätigen können. Das Limit setzt sich rollierend zurück – Burst-Verhalten ist innerhalb des Fensters erlaubt, aber anhaltend hohe RPM lösen 429er aus. Die meisten Production-Workloads treffen zuerst RPM-Limits.

Tokens pro Minute (TPM) deckelt die Gesamtmenge der Tokens (Input + Output, bei den meisten Providern; manche zählen nur Input) pro Minute. Long-Context-Aufrufe verbrauchen das TPM-Budget schnell: ein einzelner 200k-Input-Aufruf auf einem 200k-TPM-Limit lässt keine Budgetreste für andere Anfragen in dieser Minute.

Concurrent-Request-Limits deckeln, wie viele Anfragen gleichzeitig in Bearbeitung sein können. OpenAI veröffentlicht kein hartes Concurrency-Limit auf Standard-Tiers (indirekt durch TPM/RPM begrenzt). Together AI veröffentlicht 200–500 parallel auf dem Standard-Tier. Concurrency-Grenzen zu treffen zeigt sich als anderer Fehler als RPM/TPM – typischerweise eine 503 statt 429.

Alle drei Limits setzten sich pro Modell zurück. GPT-5.5 und GPT-5.4-mini haben unabhängige Kontingente; GPT-5.5 an der Grenze zu laufen beeinträchtigt nicht den Spielraum für GPT-5.4-mini. Dies ist nützlich für Fallback-Muster – siehe den Resilienz-Abschnitt unten.

Referenz-Workload: ein Kundenservice-Chatbot mit durchschnittlich 1.500 Input- + 500 Output-Tokens pro Aufruf.

Auf OpenAI Tier 2 (GPT-5.5: 5.000 RPM / 450.000 TPM): 5.000 RPM ist die verbindliche Einschränkung bei dieser Token-Form, da 5.000 Aufrufe × 2.000 Tokens = 10M Tokens/Min – deutlich über TPM. Die Grenze liegt bei 5.000 Aufrufen/Min = 83 Aufrufe/Sekunde. Ein Burst von 100 gleichzeitigen Nutzern, die je eine Nachricht senden, wobei das Modell ~5 Sekunden zum Antworten braucht, liegt komfortabel unter der Grenze.

Gleiche Workload auf Anthropic Tier 2 (Claude Sonnet 4.6: 1.000 RPM / 80.000 Input-TPM / 16.000 Output-TPM): 1.000 RPM ÷ 60 = 17 RPS. Aber Input-TPM ist hier die echte Bremse – 1.000 Aufrufe × 1.500 Input-Tokens = 1,5M Input-Tokens, deutlich über 80k TPM. Die echte Grenze liegt bei 80.000 / 1.500 = 53 Aufrufe/Min beim Input – viel enger als die Schlagzeile 1.000 RPM. Sie müssen entweder auf Tier 3 upgraden oder den Chatbot auf ein Modell mit loseren Limits verschieben.

Auf Google Gemini Paid Tier 1 (Gemini 2.5 Pro: 1.000 RPM / 2.000.000 TPM): 2M TPM / 2k Tokens pro Aufruf = 1.000 Aufrufe/Min – exakt passend zu RPM. Tier 1 sustentiert etwa 17 Aufrufe/Sekunde; ausreichend für eine kleine bis mittlere App.

Planen Sie für die verbindliche Einschränkung, nicht die Schlagzeile. TPM limitiert häufig vor RPM bei Long-Context-Workloads.

Referenz-Workload: Einmalige Anreicherung von 1M Datensätzen, jeder erfordert einen 500-Token-ein / 100-Token-aus Klassifizierungsaufruf.

Synchron auf OpenAI Tier 4 (10.000 RPM / 2.000.000 TPM): 10k RPM ÷ 60 = 167 RPS. 1M Aufrufe / 167 RPS = ~100 Minuten Dauerburst – oder 1 Stunde 40 Minuten, wenn Sie durchgehend laufen können. TPM bei 600 Tokens × 10k Aufrufe = 6M, deutlich über dem 2M TPM-Limit, also ist TPM die Bremse. Echter Durchsatz: 2M TPM / 600 Tokens = 3.333 Aufrufe/Min, also 1M Aufrufe / 3.333 = 300 Minuten = 5 Stunden.

Gleicher Job auf der Batch-API: reichen Sie 1M Aufrufe in einer JSONL-Datei ein, erhalten Sie Ergebnisse in bis zu 24 Stunden, mit 50% Rabatt auf Input und Output. Kein RPM- oder TPM-Problem – die Batch-Queue verwaltet das Drosseln intern. Die Kosten fallen von $0,005 × 1M = $5.000 (GPT-5.4-mini Standard) auf $2.500.

Für einmalige Anreicherungsdurchläufe ist Batch fast immer die richtige Antwort – gleiche Kostenersparnis wie ein synchrones Tier-Upgrade, einfachere Ops, kein Rate-Limit-Engineering. Für kontinuierliche Aufnahme ist Synchron auf einem höheren Tier üblicherweise richtig.

OpenAI befördert automatisch zwischen Tiers basierend auf kumulativem Ausgabeverhalten und Account-Alter. Tier 1 → 2 bei $50 in 7+ Tagen, Tier 2 → 3 bei $100 in 7+ Tagen, Tier 3 → 4 bei $250 in 14+ Tagen, Tier 4 → 5 bei $1.000 in 30+ Tagen. Die Progression ist automatisch; kein Support-Ticket nötig.

Anthropic nutzt Kautionen statt Ausgabeverhalten. Tier 1 → 2 bei $40 Kaution in 7+ Tagen, Tier 2 → 3 bei $200 in 14+ Tagen, Tier 3 → 4 bei $400 in 30+ Tagen. Für höhere Limits kontaktieren Sie Sales für einen Custom-Plan.

Google Gemini nutzt kumulatives Ausgabeverhalten auf dem bezahlten Tier. Kostenlos-Tier ist streng begrenzt (10 RPM auf Flash, 5 auf Pro). Paid Tier 1 wird bei Abrechnung aktiviert. Paid Tier 2 bei $250 kumulativ in 30+ Tagen. Tier 3 erfordert Kontakt zu Sales oder den Wechsel zu Vertex AI.

Die praktische Folgerung: eine Production-Bereitstellung sollte innerhalb des ersten Monats auf Tier 3+ sitzen. Wenn Sie auf Tier 1 oder 2 starten und der Traffic steigt, treffen Sie Limits und 429er, bevor die automatische Tier-Beförderung eintritt. Der schnellste Weg, die Wartezeit zu überspringen, ist, den vollen Betrag vorab einzuzahlen – die meisten Provider respektieren den höheren Tier innerhalb von Stunden der Erkennung.

Alle großen Provider geben HTTP 429 (Too Many Requests) zurück, wenn ein RPM-, TPM- oder Concurrency-Limit überschritten wird. Die Antwort enthält Retry-After in Sekunden, das ist der empfohlene Backoff vor erneutem Versuch. Retry-After zu respektieren ist der Unterschied zwischen elegant degradieren und eine kaskadierende Queue-Stauung.

Schlechtes Retry-Muster: sofortiger Wiederholungsversuch ohne Backoff. Führt dazu, dass derselbe Aufruf wiederholt fehlschlägt und erhöht die Last auf das Rate-Limit-System des Providers. Löst oft temporäre IP-Bans auf aggressive Retry-Stürme aus.

Gutes Retry-Muster: exponentieller Backoff mit Jitter. Starten Sie mit dem Retry-After-Wert (oder 1 Sekunde, falls fehlend), verdoppeln Sie jeden Wiederholungsversuch bis zu einem Maximum (typischerweise 60 Sekunden), addieren Sie 0–25% zufälligen Jitter, um Thundering Herd zu vermeiden. Die meisten Production-HTTP-Clients (das OpenAI SDK, Anthropic SDK, google-generativeai SDK) implementieren dies standardmäßig; verifizieren Sie, dass es aktiviert ist.

Besseres Muster: Rate-Limit-Bewusstsein auf der Queue-Ebene. Wenn Sie 10.000 Aufrufe tätigen müssen und ein 5.000-RPM-Limit haben, verteilen Sie sie proaktiv über 2+ Minuten, statt alle 10k abzufeuern und die Hälfte 429 zu bekommen. Nutzen Sie einen Leaky-Bucket oder Token-Bucket Rate Limiter auf Ihrer API-Client-Schicht.

Bestes Muster im großen Maßstab: eine Multi-Tier-Fallback-Kette. Primäres Modell auf eigenem Kontingent, Secondary (günstigeres) Modell auf eigenem Kontingent für Overflow, Batch-Queue für nicht-dringende Workloads. Wenn primär 429 bekommt, fallback auf secondary; wenn secondary 429 bekommt, auf Batch.

Muster 1: Model Fallback. Jedes Modell hat unabhängige Kontingente. Wenn GPT-5.5 RPM cappt, erneut versuchen auf GPT-5.4. Wenn Claude Sonnet 4.6 cappt, erneut versuchen auf Claude Haiku 4.5. Qualität sinkt leicht, aber die Verfügbarkeit bleibt bei 100%. Implementieren Sie mit einem einfachen Retry-bei-429-Router auf der Client-Seite.

Muster 2: Provider Fallback. Provider-übergreifende Redundanz mit AI Gateway oder Portkey oder Custom Routing. Primär auf OpenAI, secondary auf Anthropic, tertiär auf Gemini. Wenn ein Provider Ausfall hat oder Rate-Limited, routen Sie zum nächsten. Erhöht Eval-Komplexität (jeder Provider antwortet etwas anders), aber eliminiert Single-Provider-Risiko.

Muster 3: Client-seitiges Drosseln. Nutzen Sie einen Leaky-Bucket Rate Limiter (z. B. aiolimiter in Python, bottleneck in Node) auf 80% Ihres Tier-Limits. Verhindert Bursting in 429er.

Muster 4: Spend-Tier-Beschleunigung. Wenn Sie 6 Tage von einer Tier-Beförderung entfernt sind, die Ihr Rate-Problem lösen würde, pre-depositen Sie oder machen Sie einen einmaligen API-Aufruf-Lauf, um die Beförderungsschwelle schneller auszulösen.

Muster 5: Batch, wo möglich. Alles, was nicht synchron-nutzergerichtet ist, gehört zur Batch-API. Sowohl OpenAI- als auch Anthropic-Batch-Endpoints haben separate Kontingent-Pools, die Ihre synchronen Limits nicht beeinflussen.

Für die Kostenseite dieser Muster, siehe GPT vs. Claude vs. Gemini Cost Calculator, das Fallback-Ketten end-to-end vergleicht.

Methode 1: durch die Schwelle ausgeben. Der billigste Weg: echten Traffic laufen, um das kumulativ-Ausgabe-Kriterium zu treffen. Verbrauchen Sie den erforderlichen Dollarbetrag durch legitime Workload über die erforderlichen Tage. Die meisten Teams sitzen innerhalb von 30–60 Tagen nach dem Start auf dem nächsten Tier.

Methode 2: Pre-Deposit. Manche Provider (Anthropic) akzeptieren Pre-Deposits, die sofort auf Tier-Kriterien angerechnet werden, beschleunigen Beförderung ohne auf Nutzung zu warten.

Methode 3: Kontaktieren Sie Sales. Der schnellste Weg für Enterprise-Volume. OpenAI, Anthropic, Google, Mistral und Together haben alle Sales-Teams, die Custom höhere Tier-Limits mit einer Diskussion über erwartetes Volumen, Use Case und Bedingungen authorisieren können. Vorlaufzeit: typischerweise Tage bis Wochen.

Methode 4: Dedicated Endpoints. Together AI, Anthropic (via Bedrock) und Google (via Vertex AI) alle bieten Reserved-Capacity-Endpoints, wo Rate Limits effektiv verschwinden gegen committed monatliche Kapazitätszahlungen. Nützlich bei anhaltend hohem Volumen mit vorhersagbaren Last-Formen.

Methode 5: Cross-Account-Verteilung. Manche Teams sharden Production-Traffic über mehrere Accounts (typischerweise pro-Umgebung oder pro-Feature). Jedes Account erhält sein eigenes Kontingent. Seien Sie vorsichtig – Provider-AGBs verbieten üblicherweise die Nutzung mehrerer Accounts zur Cap-Umgehung; legitime Use Cases (wirklich separate Apps oder Umgebungen) sind okay.

Rate-Limit-Spielraum ist keine einzelne Zahl – es ist eine Zahl pro Region pro Provider. Jeder große LLM-Provider macht seine Flaggschiff-Modelle über mehr als einen Endpoint verfügbar, und jeder Endpoint erzwingt sein eigenes unabhängiges RPM- und TPM-Kontingent. Ein Team, das nur gegen den Standard-Endpoint läuft, lässt 2x bis 3x der nutzbaren Kapazität auf dem Tisch liegen, oft ohne es zu merken. Das Multi-Region-Muster behandelt jeden regionalen Endpoint als parallelen Kontingent-Behälter und routet Traffic über sie mit einer Failover-Richtlinie.

Anthropic ist hier am flexibelsten. Claude ist verfügbar auf der direkten Anthropic-API, auf AWS Bedrock in us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1, ap-northeast-1 und mehreren neueren Regionen, und auf Google Cloud Vertex AI in us-east5, europe-west1 und asia-southeast1. Jeder dieser Endpoints hat ein separates Kontingent. Eine Workload, die die direkte API Tier 3-Decke von 2.000 RPM trifft, kann Overflow zu Bedrock us-east-1 (separates Pro-Account-Kontingent, verhandelt gegen AWS) und Vertex AI us-east5 (verhandelt gegen GCP) routen. Das gleiche zugrunde liegende Claude Sonnet 4.6-Modell bedient alle drei mit dem gleichen Prompt-Schema, also das Eval-Differenz-Risiko, das im Cross-Provider-Fallback besteht, ist effektiv Null.

OpenAI ist auf der direkten API mehr beschränkt – es präsentiert einen globalen Endpoint mit einem einzelnen Kontingent – aber Azure OpenAI Service repliziert GPT-5.x über regionale Bereitstellungen (East US, East US 2, West US, West US 3, North Central US, South Central US, North Europe, West Europe, Sweden Central, France Central, UK South, Japan East, Australia East und andere). Jede Azure-Region hat sein eigenes RPM- und TPM-Kontingent, das bei der Bereitstellungserstellung zugewiesen ist. Ein Team, das auf OpenAI Tier 4's 10.000-RPM-Decke blockiert ist, kann GPT-5.5 in drei Azure-Regionen bei 3.000 RPM jeweils bereitstellen und zwischen ihnen routen und sofort 9.000 RPM von Seiten-Kanal-Kapazität hinzufügen, ohne auf Tier-Auto-Beförderung zu warten.

Google Gemini folgt dem gleichen Muster über Vertex AI. Die AI Studio-API hat ein gemeinsames Kontingent; Vertex AI veröffentlicht regionale Endpoints (us-central1, us-east1, us-east4, us-west1, europe-west1, europe-west4, asia-southeast1, asia-northeast1 und mehr), jeder mit unabhängigen Kontingenten, die pro Projekt konfigurierbar sind. Vertex AI-Kontingente neigen auch dazu, höher zu sein als das AI Studio Paid Tier auf dem gleichen Spend-Niveau, also ist die Migration doppelt wertvoll für High-Volume-Workloads.

Die Mathematik auf einem Three-Region-Setup ergibt selten ein perfektes 3x. Unvollkommenes Load-Balancing – ungleiche Traffic-Formen, Retry-Stürme konzentrieren sich auf die primär, Region-gepinnte Kunden in regulierten Workloads – liefert typischerweise einen 2,6x bis 2,8x effektiven Multiplikator auf den meisten realistischen Chatbot- und Aufnahme-Workloads. Verwenden Sie 2,7x als Planungsregel. Ein funktionierendes Beispiel: ein Chatbot bei einer 30.000-TPM-Decke pro Region, bereitgestellt primär in us-east-1, secondary in eu-west-1, tertiär in ap-southeast-1, sustentiert etwa 80.000 TPM aggregiert, bevor irgendeine Region 429s startet. Das ist äquivalent zu einem vollständigen Tier-Upgrade, erreichbar in Stunden statt der 14 bis 30 Tage, die eine Spend-basierte Beförderung erfordern würde, und ohne Mindestkaution-Verpflichtung.

Monitoring ist der Teil, in den Teams unterinvestieren. Jede Region braucht ihr eigenes Headroom-Dashboard, ihre eigene 429-Rate-Warnung und ihr eigenes, separat verfolgtes Retry-Budget – Aggregieren über Regionen versteckt die Region, die tatsächlich gesättigt ist. Taggen Sie jeden Request mit seinem Ziel-Region auf der Client-Schicht, loggen Sie die regionalen Rate-Limit-Header (Azure gibt x-ratelimit-remaining-requests pro Bereitstellung zurück; Bedrock gibt x-amzn-bedrock-quota-* Header; Vertex gibt Standard-Google-Quota-Header) in Ihren Observability-Stack und graphen Sie jede Region als separate Reihe. Der Failover-Router sollte die Region mit dem höchsten verbleibenden Headroom auswählen statt eines festen Primär, das glättet die Nutzung und drückt den effektiven Multiplikator näher an die theoretische 3x. Für Implementierungen auf Vercel's AI Gateway kann die regionale Routing-Logik in einer dünnen Middleware-Schicht vor dem Gateway sitzen und zum gewählten Endpoint durchgeben.

Die meisten Provider geben Rate-Limit-Header bei jeder erfolgreichen Antwort zurück. OpenAI: x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens. Anthropic: anthropic-ratelimit-requests-remaining, anthropic-ratelimit-tokens-remaining. Google: x-goog-api-client (weniger detailliert; fragen Sie die API nach Quota-Status).

Loggen Sie diese Header pro Request und bauen Sie ein Dashboard, das rollierende 1-Minuten- und 5-Minuten-Spielraum auf RPM und TPM zeigt. Wenn Spielraum regelmäßig unter 20% auf Basis anhaltend fällt, ist der Tier Ihre echte Production-Decke; planen Sie eine Beförderung, bevor Traffic überwächst.

Warnen Sie auf drei Signale: 429-Rate über 0,1% des Gesamtverkehrs, anhaltend unter 20% Spielraum für >5 Minuten und 503 (Parallelität) Fehler. Jedes Signal zeigt eine andere Abhilfe: 429 = Tier Bump oder glätte Burst; anhaltend niedriger Spielraum = Tier-Upgrade erforderlich; 503 = reduzieren Sie Parallelität auf dem Client oder upgraden Sie zu Dedicated.

Cost Monitoring sollte ausgerichtet sein: Wenn Ihr Rate-Limit-Dashboard zeigt, dass Sie regelmäßig die TPM-Decke bumpen, sitzen Sie auf einem Tier, wo die Grenzkosten für Upgrade weit kleiner sind als die Kosten für dropped oder verzögerte Anfragen. Für Provider-Kostenvergleich im großen Maßstab, siehe OpenAI API-Preisgestaltung und Anthropic Claude-Preisgestaltung.