DEV Community

Cover image for GPT API Ratenbegrenzungen: Stufen, Nutzungslimits und Testen mit Apidog
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

GPT API Ratenbegrenzungen: Stufen, Nutzungslimits und Testen mit Apidog

Sie liefern eine Funktion aus, die die GPT API aufruft. In Staging läuft alles sauber. In Produktion kommen die ersten hundert Benutzer, und Ihre Logs füllen sich mit 429 Too Many Requests. Jetzt müssen Sie schnell herausfinden: Treffen Sie das Limit für Anfragen pro Minute, Token pro Minute oder ein Tageslimit? Sind Sie noch in Stufe 1? Hat das Modell, zu dem Sie letzte Woche gewechselt sind, strengere Limits?

Teste Apidog noch heute

💡 Dieser Artikel zeigt, wie Sie GPT-Ratenlimits praktisch prüfen: Antwort-Header lesen, RPM- und TPM-Grenzen getrennt testen und mit Apidog einen wiederholbaren Testlauf speichern, den Ihr Team bei jedem Verdacht auf Rate Limiting erneut ausführen kann.

Wenn Sie mit OpenAI arbeiten, wird Rate Limiting schnell unübersichtlich. GPT-5.5 hat andere Limits als GPT-4.1, Bildmodelle zählen anders als Textmodelle, und Ihre Nutzungsstufe kann sich ändern, sobald Ihre Ausgaben steigen. Apidog gibt Ihnen einen Arbeitsbereich, um Antwort-Header zu prüfen, parallelen Traffic zu simulieren und zu bestätigen, welches Limit Sie tatsächlich erreichen, bevor Sie Workarounds in Produktionscode einbauen. Der folgende Workflow funktioniert auch mit dem kostenlosen Plan.

Die vier Limits, die wirklich zählen

OpenAI erzwingt mehrere Limits pro API-Schlüssel. Für Produktionssysteme sind vor allem diese Dimensionen relevant:

  • RPM — Requests per minute: wie viele API-Aufrufe pro Minute erlaubt sind.
  • TPM — Tokens per minute: Eingabe- und Ausgabe-Token pro Minute zusammen.
  • RPD — Requests per day: tägliche Obergrenze, vor allem bei kostenlosen Schlüsseln und niedrigen Stufen.
  • IPM / TPD / Batch-Warteschlangenlimits — modellspezifische Limits für Bilder, Audio, Embeddings und Batch-Endpunkte.

Eine abgelehnte Anfrage gibt HTTP 429 zurück, typischerweise mit einem Body wie diesem:

{
  "error": {
    "message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
    "type": "tokens",
    "param": null,
    "code": "rate_limit_exceeded"
  }
}
Enter fullscreen mode Exit fullscreen mode

Lesen Sie zuerst den Fehler-Body. Er sagt Ihnen, welche Dimension Sie überschritten haben, zum Beispiel:

  • tokens
  • requests
  • tokens_usage_based

Eine TPM-Überschreitung erfordert eine andere Lösung als eine RPM-Überschreitung. Eine 429 ist deshalb nicht automatisch ein reines „zu viele Requests“-Problem.

Für die HTTP-Grundlagen siehe die MDN-Dokumentation zu 429 und RFC 6585. Für OpenAI-spezifische Details zu Rate Limits, Retry-Headern und Nutzungsstufen sollten Sie die offizielle OpenAI-Seite zu Ratenbegrenzungen bookmarken.

Wie Stufen funktionieren

Ihr GPT API-Schlüssel gehört zu einer OpenAI-Nutzungsstufe. Diese Stufe bestimmt die konkreten RPM- und TPM-Limits.

Der Aufstieg hängt grob von zwei Faktoren ab:

  1. Gesamtausgaben Ihres Kontos
  2. Zeit seit der ersten Zahlung

Eine vereinfachte Übersicht für Textmodelle:

Stufe Ausgabenschwelle Wartezeit Text RPM Text TPM
Kostenlos keine keine 3 40k
1 $5 bezahlt keine 500 30k–200k je nach Modell
2 $50 bezahlt 7 Tage 5,000 450k
3 $100 bezahlt 7 Tage 5,000 1M
4 $250 bezahlt 14 Tage 10,000 2M
5 $1,000 bezahlt 30 Tage 10,000 2M+

Diese Zahlen sind illustrativ. Die echten Limits können sich ändern und hängen vom Modell ab. Dimensionieren Sie keine Produktionslast nur anhand einer Tabelle in einem Blogpost. Lesen Sie Ihre Live-Limits aus Dashboard oder Antwort-Headern.

Praktische Konsequenzen:

  1. Stufenwechsel passieren automatisch. Wenn Ausgabenschwelle und Wartezeit erfüllt sind, laufen neue Requests gegen die höheren Limits.
  2. Limits können sinken. Bei Inaktivität, Zahlungsproblemen oder Abrechnungsänderungen sollten Sie Ihre Produktionslimits erneut prüfen.

Für Anbieter-Vergleiche siehe den Erklärer zu OpenAI API-Benutzerratenbegrenzungen, den Leitfaden zu Claude API-Ratenbegrenzungen und den Leitfaden zu Grok-3 API-Ratenbegrenzungen.

Live-Limits aus Antwort-Headern lesen

Jede GPT API-Antwort enthält Rate-Limit-Informationen in den Headern. Achten Sie vor allem auf:

  • x-ratelimit-limit-requests
  • x-ratelimit-remaining-requests
  • x-ratelimit-limit-tokens
  • x-ratelimit-remaining-tokens

Häufig sehen Sie zusätzlich:

  • x-ratelimit-reset-requests
  • x-ratelimit-reset-tokens

Diese Header geben an, wann der jeweilige Bucket wieder aufgefüllt wird, zum Beispiel 6s oder 1m30s.

Schritt 1: GPT-Anfrage in Apidog anlegen

Erstellen Sie in Apidog ein neues Projekt und fügen Sie eine neue Anfrage hinzu.

Methode

POST https://api.openai.com/v1/chat/completions
Enter fullscreen mode Exit fullscreen mode

Header

Schlüssel Wert
Authorization Bearer {{OPENAI_API_KEY}}
Content-Type application/json

{{OPENAI_API_KEY}} ist eine Apidog-Umgebungsvariable. Dadurch speichern Sie den Schlüssel nicht direkt in der Anfrage. Legen Sie die Variable einmal pro Umgebung an, zum Beispiel für persönliche Schlüssel, Team-Schlüssel oder verschiedene Organisationen.

Body

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "ping"
    }
  ],
  "max_tokens": 10
}
Enter fullscreen mode Exit fullscreen mode

Senden Sie die Anfrage. Öffnen Sie danach im Antwortbereich den Header-Tab und suchen Sie die x-ratelimit-*-Header.

Notieren Sie mindestens:

x-ratelimit-limit-requests
x-ratelimit-remaining-requests
x-ratelimit-limit-tokens
x-ratelimit-remaining-tokens
Enter fullscreen mode Exit fullscreen mode

Diese Werte sind Ihre aktuelle Basislinie.

Wenn Sie die Einrichtung detaillierter nachvollziehen möchten, behandelt der Leitfaden zum Testen der ChatGPT API mit Apidog Authentifizierung, Streaming und Tool-Aufrufe.

Schritt 2: RPM mit einem kleinen Burst testen

Eine einzelne Anfrage zeigt nur die Header. Sie zeigt nicht, wie sich Ihr System am Limit verhält.

Für einen RPM-Test verwenden Sie kleine Requests und erzeugen viele davon.

In Apidog:

  1. Öffnen Sie die gespeicherte GPT-Anfrage.
  2. Klicken Sie auf das Dropdown neben Senden.
  3. Wählen Sie Im Testszenario ausführen.
  4. Konfigurieren Sie den Lauf: 
Iterationen: 50
Parallelität: 10
Verzögerung zwischen Iterationen: 0 ms
Enter fullscreen mode Exit fullscreen mode

Passen Sie die Anzahl an Ihre Header-Werte an. Ziel ist ein kontrollierter Burst, der knapp über dem erwarteten RPM-Limit liegt.

Mögliche Ergebnisse:

  1. Einige Requests liefern 429.

    Das bestätigt, dass Ihr aktuelles Konto tatsächlich an dieses Limit läuft.

  2. Alle Requests liefern 200.

    Prüfen Sie erneut die Response-Header. Ihr RPM-Limit ist wahrscheinlich höher als erwartet.

Sortieren Sie den Testbericht nach Statuscode und öffnen Sie jede 429-Antwort. Im Body steht, ob Sie requests, tokens oder ein anderes Limit überschritten haben.

Für die nächsten Schritte nach einer Limit-Überschreitung siehe den Leitfaden zur Überschreitung der Ratenbegrenzung.

Schritt 3: TPM separat testen

RPM testen Sie mit vielen kleinen Requests. TPM testen Sie mit weniger, aber größeren Requests.

Ändern Sie den Body zum Beispiel so:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "system",
      "content": "<3,000 Token Kontext hier>"
    },
    {
      "role": "user",
      "content": "Fasse das Obige in einem Satz zusammen."
    }
  ],
  "max_tokens": 200
}
Enter fullscreen mode Exit fullscreen mode

Führen Sie danach ein kleineres Szenario aus:

Iterationen: 20
Parallelität: 5
Verzögerung zwischen Iterationen: 0 ms
Enter fullscreen mode Exit fullscreen mode

Wenn Sie ein niedriges TPM-Limit haben, erreichen Sie jetzt das Token-Limit, bevor das Request-Limit relevant wird.

Die Unterscheidung ist entscheidend:

  • RPM-Problem: Requests staffeln, batchen, Warteschlange einführen, Parallelität begrenzen.
  • TPM-Problem: Prompts kürzen, Kontext reduzieren, Caching nutzen, Anfragen aufteilen.

Schritt 4: Gleichzeitige Benutzer simulieren

Produktionsverkehr besteht selten aus identischen Requests. Typisch sind:

  • kleine Prompts
  • große RAG-Kontexte
  • Bursts durch viele Benutzer
  • stabile Grundlast
  • unterschiedliche max_tokens-Werte

Erstellen Sie in Apidog ein Testszenario mit mehreren Varianten:

  1. Kleine Anfrage
  2. Mittlere Anfrage
  3. Große Anfrage
  4. Optional: Anfrage mit Streaming oder Tool-Aufruf

Nutzen Sie Pre- und Post-Request-Skripte, um realistischere Last zu erzeugen:

  • zufällige Nachrichtenlänge pro Iteration wählen
  • x-ratelimit-remaining-tokens nach jeder Antwort lesen
  • Szenario abbrechen, wenn ein Schwellenwert unterschritten wird
  • Latenz für 200 und 429 getrennt protokollieren

Ein einfacher Schwellenwert für den Abbruch kann so aussehen:

const remainingTokens = Number(response.headers.get("x-ratelimit-remaining-tokens"));

if (!Number.isNaN(remainingTokens) && remainingTokens < 1000) {
  console.log("Token-Budget fast aufgebraucht:", remainingTokens);
}
Enter fullscreen mode Exit fullscreen mode

Am Ende ist das Statuscode-Histogramm das wichtigste Artefakt. Speichern Sie es in Ihrem Runbook. Wenn später jemand fragt „Sind wir gerade rate-limited?“, führen Sie dasselbe Szenario erneut aus und vergleichen die Ergebnisse.

Was tun, wenn Sie gedrosselt werden?

Sobald Sie wissen, welches Limit greift, wählen Sie die passende Gegenmaßnahme.

1. Backoff implementieren

Wickeln Sie GPT-Aufrufe in Retry-Logik mit exponentiellem Backoff.

Beispiel in Python:

import time
import random

def sleep_with_backoff(attempt, reset_seconds=None):
    if reset_seconds is not None:
        time.sleep(reset_seconds)
        return

    delay = min(60, (2 ** attempt) + random.uniform(0, 1))
    time.sleep(delay)
Enter fullscreen mode Exit fullscreen mode

Wenn eine 429-Antwort x-ratelimit-reset-tokens oder x-ratelimit-reset-requests enthält, verwenden Sie diesen Wert als erste Wartezeit. Das ist genauer als ein blindes sleep(2 ** attempt).

2. Warteschlange einführen

Wenn Ihr Traffic bursty ist, legen Sie Requests in eine Queue und verarbeiten Sie diese knapp unterhalb Ihres Limits.

Typisches Muster:

Eingehende Requests
        ↓
Queue
        ↓
Worker-Pool mit begrenzter Parallelität
        ↓
GPT API
Enter fullscreen mode Exit fullscreen mode

Für RPM begrenzen Sie die Anzahl gleichzeitiger Requests. Für TPM brauchen Sie zusätzlich eine grobe Token-Schätzung pro Job.

Mehr zur Implementierung finden Sie in wie man API-Ratenbegrenzung implementiert und Implementierung von Ratenbegrenzung in APIs.

3. Batch API verwenden

Wenn Ihre Arbeitslast keine synchrone Antwort braucht, kann Batch-Verarbeitung sinnvoll sein. Beispiele:

  • nächtliche Datenanreicherung
  • Dokumentenklassifizierung
  • Embedding-Rebuilds
  • große Offline-Auswertungen

Dadurch bleibt Ihr synchrones Kontingent für benutzerorientierten Traffic frei.

Wenn Sie vorher die Begriffe sauber trennen möchten, erklärt Drosselung vs. Ratenbegrenzung die Unterschiede.

Häufige GPT-429-Fehler

Rate limit reached … on requests per min (RPM)

Ihr Code sendet zu viele API-Aufrufe pro Minute.

Typische Ursachen:

  • parallele map über viele Datensätze
  • zu großer Worker-Pool
  • fehlende Queue
  • mehrere Services teilen sich denselben API-Key

Gegenmaßnahmen:

  • Parallelität begrenzen
  • Worker-Pool kleiner wählen
  • Requests staffeln
  • Client-seitigen Rate Limiter einbauen

Rate limit reached … on tokens per min (TPM)

Ihre Requests verbrauchen zu viele Token pro Minute.

Typische Ursachen:

  • zu lange System-Prompts
  • RAG-Pipeline fügt zu viele Dokumente in den Kontext ein
  • max_tokens ist deutlich zu hoch
  • parallele große Requests

Gegenmaßnahmen:

  • Prompts kürzen
  • Kontext chunking-basiert reduzieren
  • Caching nutzen
  • große Aufgaben splitten
  • max_tokens realistisch begrenzen

You exceeded your current quota, please check your plan and billing details

Das sieht wie eine 429 aus, ist aber meist kein klassisches Rate-Limit-Problem.

Mögliche Ursachen:

  • monatliche Ausgabenobergrenze erreicht
  • Zahlungsmethode fehlgeschlagen
  • Prepaid-Guthaben aufgebraucht
  • Abrechnungsproblem im Konto

Die Lösung liegt im Billing-Dashboard, nicht in Retry-Logik.

Praktisches Runbook

Speichern Sie für Ihr Team ein kleines Runbook:

# GPT Rate-Limit Check

## 1. Einzelrequest senden
- Apidog-Anfrage öffnen
- Umgebung wählen
- Request senden
- `x-ratelimit-*` Header notieren

## 2. RPM-Test ausführen
- Szenario: kleine Anfrage
- Iterationen: 50
- Parallelität: 10
- 429-Body prüfen

## 3. TPM-Test ausführen
- Szenario: große Anfrage
- Iterationen: 20
- Parallelität: 5
- 429-Body prüfen

## 4. Ergebnis einordnen
- `requests` → RPM-Problem
- `tokens` → TPM-Problem
- `quota` → Billing prüfen

## 5. Gegenmaßnahme
- RPM → Queue / Parallelität reduzieren
- TPM → Prompt kürzen / Kontext splitten
- Quota → Billing prüfen
Enter fullscreen mode Exit fullscreen mode

So wird aus „Wir bekommen 429“ eine reproduzierbare Diagnose.

FAQ

Kostet Apidog etwas, um GPT-Ratenbegrenzungen zu testen?

Nein. Der kostenlose Plan deckt Einzelanfragen und kleine gleichzeitige Testläufe ab. Für größere Testlasten, Team-Arbeitsbereiche oder geplante Läufe kann ein kostenpflichtiger Plan relevant sein. Details finden Sie unter Apidog Preise.

Kann ich Ratenbegrenzungen testen, ohne echte Token zu verbrauchen?

Teilweise. Ein günstiger Basis-Check ist eine Anfrage mit max_tokens: 1 und einer sehr kurzen Nachricht. Die Header kommen trotzdem zurück.

Burst-Tests verbrauchen echte Token. Halten Sie deshalb die Test-Prompts klein. Wenn Sie nur Ihre Retry-Logik testen möchten, können Sie mit Apidogs Mock-Server eine 429-Antwort simulieren, ohne OpenAI aufzurufen.

Warum fühlt sich mein Schlüssel der Stufe 1 langsamer an als der eines Kollegen?

Limits gelten pro Organisation, nicht nur pro Schlüssel. Wenn mehrere Personen oder Services dieselbe Organisation nutzen, konkurrieren sie um dasselbe Kontingent.

Testen Sie beide Schlüssel nebeneinander in Apidog und vergleichen Sie:

x-ratelimit-remaining-requests
x-ratelimit-remaining-tokens
Enter fullscreen mode Exit fullscreen mode

Woher weiß ich, welches Modell welches Limit hat?

Lesen Sie die Antwort-Header. Verlassen Sie sich nicht auf generische Tabellen. Senden Sie jedem Modell eine günstige Anfrage und speichern Sie die Header-Werte.

Auch Snapshot-Versionen können unterschiedliche Limits haben, zum Beispiel:

gpt-5.5
gpt-5.5-0901
Enter fullscreen mode Exit fullscreen mode

Zählen Streaming-Anfragen anders?

Ja, insbesondere für TPM. Eine Streaming-Anfrage kann Token basierend auf max_tokens reservieren. Ein zu hoher max_tokens-Wert kann Ihr TPM-Budget belasten, auch wenn die tatsächliche Antwort kürzer ist.

Setzen Sie max_tokens deshalb auf die engste realistische Obergrenze. Streaming wird auch im Artikel wie man die ChatGPT API mit Apidog testet behandelt.

Kann ich meinen Apidog Rate-Limit-Test mit meinem Team teilen?

Ja. Speichern Sie Anfrage und Testszenario in einem gemeinsamen Projekt. Teammitglieder können denselben Test mit eigenen Schlüsseln ausführen, indem sie die Umgebung wechseln. Dadurch wird die Frage „Ist mein Schlüssel gedrosselt oder die Organisation?“ schnell überprüfbar.

Top comments (0)