Umgang mit Ratenlimits und Wiederholungsversuchen bei LLM-APIs

Die beiden entscheidenden Grenzen: RPM und TPM

Die meisten LLM-APIs setzen eine Kombination der folgenden Grenzen durch:

• RPM: Anfragen pro Minute
• TPM: Tokens pro Minute
• RPD / TPD: Anfragen oder Tokens pro Tag
• Grenzen für gleichzeitige Anfragen: maximale Anzahl laufender Aufrufe
• Modellspezifische Grenzen: höhere Grenzen für kleinere Modelle, niedrigere Grenzen für Spitzenmodelle

Der entscheidende Punkt: RPM und TPM führen auf unterschiedliche Weise zu Problemen.

Wenn Sie viele sehr kleine Prompts senden, erreichen Sie zuerst die RPM-Grenze. Wenn Sie weniger, dafür große Prompts senden, erreichen Sie zuerst die TPM-Grenze.

Beispiel:

Limit:
- 600 requests/minute
- 300,000 tokens/minute

Workload A:
- 1,000 short classification calls/minute
- 200 tokens each
- 200,000 tokens/minute total

Result:
- TPM is fine
- RPM fails

Workload B:
- 100 long document analysis calls/minute
- 5,000 tokens each
- 500,000 tokens/minute total

Result:
- RPM is fine
- TPM fails

Ein häufiger Fallstrick: Entwickler drosseln Anfragen, aber nicht Tokens. Das funktioniert in der Staging-Umgebung, wo die Prompts kurz sind. Dann fügen Nutzer im Produktionsbetrieb PDFs, Chatverläufe, Protokolle oder Verträge ein, und das Token-Budget ist im Nu aufgebraucht.

In der Praxis behandle ich jeden LLM-Aufruf so, als würde er zwei Ressourcen reservieren:

cost = {
  requests: 1,
  tokens: estimated_prompt_tokens + max_output_tokens
}

Selbst wenn das Modell weniger Ausgabetokens zurückgibt als max_output_tokens, verhindert die Reservierung der Obergrenze eine Überbuchung.

Was tatsächlich passiert, wenn Sie TPM ignorieren

Angenommen, Sie haben:

TPM limit: 120,000
Average request: 4,000 input tokens + 1,000 max output tokens
Reserved cost: 5,000 tokens

Ihr tatsächlicher maximaler Durchsatz ist nicht „so viele Worker wie möglich“. Er beträgt:

120,000 / 5,000 = 24 requests per minute

Das entspricht im Durchschnitt einer Anfrage alle 2.5 Sekunden.

Wenn Sie 100 Worker betreiben, können alle Anfragen des ersten Durchlaufs erfolgreich starten, sofern der Anbieter kurzfristige Lastspitzen zulässt. Danach stößt das Konto an eine harte Grenze. Jede nachfolgende Anfrage erhält 429, und die Wiederholungsversuche häufen sich.

Die Lösung besteht nicht nur darin, die Anzahl der Worker zu reduzieren. Sie brauchen einen Scheduler, der Token-Reservierungen berücksichtigt.

Ein minimaler Ratenbegrenzer mit Token-Berücksichtigung

Für einen einzelnen Prozess reicht meist ein Token-Bucket aus. Sie füllen die Kapazität im Laufe der Zeit wieder auf und verlangen, dass jede Anfrage sowohl Anfragekapazität als auch Token-Kapazität reserviert.

Hier ist ein vereinfachtes Python-Beispiel:

import asyncio
import time
from dataclasses import dataclass

@dataclass
class Bucket:
    capacity: float
    refill_per_second: float
    tokens: float
    updated_at: float

    def refill(self):
        now = time.monotonic()
        elapsed = now - self.updated_at
        self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_per_second)
        self.updated_at = now

    async def acquire(self, amount: float):
        while True:
            self.refill()
            if self.tokens >= amount:
                self.tokens -= amount
                return

            missing = amount - self.tokens
            sleep_for = missing / self.refill_per_second
            await asyncio.sleep(min(sleep_for, 1.0))


class LLMRateLimiter:
    def __init__(self, rpm: int, tpm: int):
        now = time.monotonic()
        self.request_bucket = Bucket(
            capacity=rpm,
            refill_per_second=rpm / 60,
            tokens=rpm,
            updated_at=now,
        )
        self.token_bucket = Bucket(
            capacity=tpm,
            refill_per_second=tpm / 60,
            tokens=tpm,
            updated_at=now,
        )
        self.lock = asyncio.Lock()

    async def acquire(self, estimated_tokens: int):
        async with self.lock:
            await self.request_bucket.acquire(1)
            await self.token_bucket.acquire(estimated_tokens)

Verwendung:

estimated_tokens = prompt_tokens + max_output_tokens
await limiter.acquire(estimated_tokens)

response = await client.chat.completions.create(
    model="gpt-5.5",
    messages=messages,
    max_tokens=max_output_tokens,
)

Das ist bewusst einfach gehalten. Verwenden Sie in einem verteilten System Redis, Advisory Locks in Postgres oder eine Warteschlange mit zentraler Zuweisung. Das entscheidende Prinzip bleibt gleich: Drosseln Sie sowohl die Anzahl der Anfragen als auch das Token-Budget, bevor Sie die API aufrufen.

Wiederholungsversuche: Backoff ist notwendig, reicht aber nicht aus

Wiederholungsversuche sind sinnvoll bei:

• Vorübergehenden 429 Antworten
• Netzwerk-Zeitüberschreitungen
• Temporären 500, 502, 503, oder 504 Fehlern
• Überlastung auf Anbieterseite
• Verbindungsabbrüchen

Wiederholungsversuche sind riskant bei:

• Validierungsfehlern
• Fehlern aufgrund der Kontextlänge
• Authentifizierungsfehlern
• Ablehnungen aufgrund von Sicherheitsrichtlinien
• Prompts, die deterministisch zu Fehlern führen
• Nicht idempotenten Tool-Aufrufen

Die Richtlinie für Wiederholungsversuche sollte zunächst Fehler klassifizieren.

Das grundlegende Backoff-Schema:

import random

def retry_delay(attempt: int, base=0.5, cap=30.0):
    exponential = min(cap, base * (2 ** attempt))
    return random.uniform(0, exponential)

Das random.uniform(0, exponential) ist Jitter. Lassen Sie ihn nicht weg.

Ohne Jitter:

100 workers fail
100 workers sleep 1s
100 workers retry
100 workers fail
100 workers sleep 2s
100 workers retry

Mit Jitter:

100 workers fail
workers retry across a spread of 0-1s
then 0-2s
then 0-4s

Das zweite Muster gibt dem Anbieter und Ihrer eigenen Warteschlange Spielraum, sich zu erholen.

Retry-Header berücksichtigen, sofern vorhanden

Viele APIs enthalten einen Hinweis wie:

Retry-After: 12

oder anbieterspezifische Reset-Header. Wenn die API eine konkrete Wartezeit vorgibt, verwenden Sie diese als Untergrenze:

delay = max(header_retry_after_seconds, retry_delay(attempt))
await asyncio.sleep(delay)

In der Praxis begrenze ich auch die gesamte Dauer der Wiederholungsversuche. Eine Chat-Anfrage mit direkter Nutzerinteraktion sollte nicht unbemerkt zwei Minuten lang wiederholt werden, während der Nutzer auf eine Ladeanzeige starrt. Ein Batch-Job im Hintergrund kann deutlich länger warten.

Beispiel für eine Richtlinie:

{
  "interactive_chat": {
    "max_attempts": 3,
    "max_total_retry_seconds": 8
  },
  "batch_summarization": {
    "max_attempts": 8,
    "max_total_retry_seconds": 300
  }
}

Warteschlangen sind besser als ein Ansturm von Workern

Wenn mehr Arbeit anfällt, als Ihr Kontingent erlaubt, sollten nicht alle Worker die LLM-API direkt aufrufen. Schalten Sie eine Warteschlange davor.

Eine praktische Architektur:

App/API
  -> Job queue
      -> Rate-aware dispatcher
          -> Provider client
              -> Result store

Der Dispatcher ist zuständig für:

• RPM-Erfassung
• TPM-Erfassung
• Modellauswahl
• Richtlinie für Wiederholungsversuche
• Anbieter-Fallback
• Parallelitätsgrenzen
• Warteschlangenpriorität

Dadurch wird Überlastung sichtbar. Statt Tausender Aufgaben, die mit 429fehlschlagen, sehen Sie, wie die Warteschlange wächst und die geschätzte Wartezeit steigt.

Bei Redis-basierten Systemen trenne ich gerne „ausführungsbereite“ Jobs von Jobs mit „verzögertem Wiederholungsversuch“:

llm:ready
llm:delayed
llm:dead_letter

Ein fehlgeschlagener Job kehrt nicht sofort zurück in ready. Er erhält einen geplanten Zeitstempel für den Wiederholungsversuch. Ein kleiner Scheduler verschiebt fällige Jobs zurück in die Warteschlange der ausführungsbereiten Jobs.

{
  "job_id": "sum_7f13",
  "model": "claude-sonnet-4.6",
  "estimated_tokens": 6200,
  "attempt": 2,
  "not_before": "2026-02-03T09:14:22Z"
}

Das not_before Feld verhindert eine Flut von Wiederholungsversuchen.

Parallelitätssteuerung ist nicht dasselbe wie Ratenbegrenzung

Parallelitätsgrenzen begrenzen die gleichzeitig laufende Arbeit. Ratenbegrenzungen begrenzen die Arbeit pro Zeitfenster.

Sie brauchen beides.

Stellen Sie sich vor, jeder Aufruf dauert 20 Sekunden und Ihr RPM-Limit beträgt 60. Eine reine RPM-Begrenzung erlaubt eine Anfrage pro Sekunde. Nach 20 Sekunden laufen etwa 20 Aufrufe gleichzeitig. Wenn die Latenz auf 90 Sekunden steigt, führt dasselbe RPM-Limit zu 90 gleichzeitigen Aufrufen. Das kann die Grenzen des Anbieters oder der lokalen Ressourcen überschreiten.

Verwenden Sie ein Semaphor zur Parallelitätssteuerung:

provider_concurrency = asyncio.Semaphore(20)

async def call_model(job):
    async with provider_concurrency:
        await limiter.acquire(job.estimated_tokens)
        return await send_request(job)

Ein häufiger Fallstrick: Wenn Sie das Semaphor zu früh belegen, warten Ihre Worker untätig auf Tokens der Ratenbegrenzung und halten dabei knappe Parallelitätsplätze belegt. In der Regel sollten Sie zuerst Ratenkapazität reservieren und dann unmittelbar vor dem Netzwerkaufruf einen Parallelitätsplatz belegen. Wenn die Wartezeit an der Ratenbegrenzung lang sein kann, vermeiden Sie es, währenddessen Worker-Ressourcen zu belegen.

Kontrollierter Leistungsabbau: Qualität dort einsetzen, wo sie zählt

Wenn Ratenbegrenzungen greifen, haben Sie andere Möglichkeiten, als einfach zu scheitern.

Ein Kundensupport-Assistent könnte seine Leistung beispielsweise so reduzieren:

Konkrete Beispiele:

• Leiten Sie die Ticket-Kategorisierung an Haiku 4.5, Qwen oder eine kleine Llama-Variante weiter, statt ein Spitzenmodell zu verwenden.
• Verwenden Sie Sonnet 4.6 für normale Schlussfolgerungsaufgaben und reservieren Sie Opus 4.8 oder GPT-5.5 für Eskalationspfade.
• Verlagern Sie Analysen mit langem Kontext nur dann auf Fable 5 oder Gemini 3, wenn der Prompt dieses Kontextfenster tatsächlich benötigt.
• Pausieren Sie bei Batch-Jobs Mandanten mit niedriger Priorität, bevor der interaktive Datenverkehr beeinträchtigt wird.

Der Preis dafür ist Komplexität. Jeder Fallback-Pfad braucht Tests, Beobachtbarkeit und die Akzeptanz des Produktteams. In manchen Anwendungsbereichen kann eine schlechtere Antwort mehr Schaden anrichten als eine verzögerte Antwort.

Fallback mit mehreren Schlüsseln und Anbietern

Routing über mehrere Schlüssel und Anbieter kann die Ausfallsicherheit verbessern, lässt sich aber leicht schlecht umsetzen.

Es gibt drei unterschiedliche Muster:

Verwenden Sie mehrere Schlüssel nicht, um Limits heimlich zu umgehen. Nutzen Sie sie für eine legitime Trennung: Mandanten, Umgebungen, Produkte oder Abrechnungsgrenzen.

Eine saubere Routing-Richtlinie könnte so aussehen:

{
  "task": "support_ticket_summary",
  "primary": {
    "provider": "anthropic",
    "model": "claude-sonnet-4.6"
  },
  "fallbacks": [
    {
      "provider": "openai",
      "model": "gpt-5.5",
      "when": ["provider_5xx", "rate_limit_after_retry_budget"]
    },
    {
      "provider": "google",
      "model": "gemini-3",
      "when": ["context_length_needed", "primary_unavailable"]
    }
  ],
  "degrade_to": {
    "provider": "open_model_cluster",
    "model": "qwen",
    "when": ["batch_low_priority"]
  }
}

Wenn Sie einen Aggregator oder eine Plattform wie AI Prime Tech für den Zugriff auf mehrere Modelle verwenden, gelten weiterhin dieselben technischen Regeln: Erfassen Sie Idempotenz, Budgets, Fallback-Bedingungen und die endgültige Abrechnungslogik ausdrücklich.

Doppelte Abrechnung beim Fallback vermeiden

Die Schwierigkeit beim Fallback besteht darin, zu wissen, ob die erste Anfrage abgeschlossen wurde.

Betrachten Sie diese Abfolge:

Client sends request to Provider A
Provider A processes it successfully
Network connection drops before client receives response
Client retries with Provider B
Both providers bill
Two completions may exist

Auf Clientseite lässt sich das nicht vollständig lösen, sofern der Anbieter keine Idempotenzschlüssel oder Abfragen zum Status einer Anfrage unterstützt. Sie können den Schaden jedoch begrenzen.

Idempotenzschlüssel verwenden, sofern verfügbar

Erzeugen Sie einen stabilen Schlüssel pro logischem Vorgang:

import hashlib
import json

def idempotency_key(task_name, tenant_id, input_payload):
    canonical = json.dumps(input_payload, sort_keys=True, separators=(",", ":"))
    digest = hashlib.sha256(canonical.encode()).hexdigest()
    return f"{tenant_id}:{task_name}:{digest}"

Speichern Sie den Vorgang vor dem Senden:

{
  "operation_id": "acme:summarize:9d2a...",
  "status": "in_flight",
  "provider": "anthropic",
  "model": "claude-sonnet-4.6",
  "created_at": "2026-02-03T09:12:01Z"
}

Aktualisieren Sie ihn dann nach Abschluss:

{
  "operation_id": "acme:summarize:9d2a...",
  "status": "completed",
  "provider_request_id": "req_abc123",
  "usage": {
    "input_tokens": 4180,
    "output_tokens": 612
  }
}

Prüfen Sie die Vorgangstabelle, bevor Sie die Anfrage anderswo erneut versuchen. Wenn ein anderer Worker den Vorgang bereits abgeschlossen hat, geben Sie das gespeicherte Ergebnis zurück.

Timeout-Arten unterscheiden

Nicht alle Timeouts sind gleich:

• Verbindungs-Timeout: Die Anfrage hat den Anbieter wahrscheinlich nie erreicht
• Lese-Timeout vor Empfang der Header: ungewiss
• Timeout während des Token-Streamings: Der Anbieter hat die Anfrage mit ziemlicher Sicherheit verarbeitet
• Abbruch durch den Client: hängt davon ab, ob der Abbruch weitergegeben wurde

Für ungewisse Fälle bevorzuge ich eine vorsichtige Richtlinie für Wiederholungsversuche:

interactive:
- retry connect timeout
- do not cross-provider retry after partial stream
- show recoverable error if status unknown

batch:
- retry after reconciliation delay
- prefer same provider with idempotency key
- fallback only after retry budget expires

Mit Bedacht streamen

Streaming verbessert die wahrgenommene Latenz, erschwert aber Wiederholungsversuche. Sobald Sie dem Nutzer einen Teil der Ausgabe gesendet haben, kann ein erneuter Versuch mit einem anderen Modell zu einer anderen Fortsetzung führen.

Beim Chat-Streaming betrachte ich „erstes Token empfangen“ in der Regel als den Punkt, ab dem kein transparenter Wiederholungsversuch mehr möglich ist. Danach werden Fehler für den Nutzer sichtbar:

"The response was interrupted. Retry?"

Das ist weniger elegant als eine unbemerkte Wiederherstellung, verhindert aber, dass inkompatible Ausgaben verschiedener Modelle zusammengesetzt werden.

Beobachtbarkeit: Die Metriken, die tatsächlich helfen

Sie brauchen mehr als die Erfolgsquote.

Erfassen Sie mindestens:

llm_requests_total{provider,model,status}
llm_tokens_reserved_total{provider,model}
llm_tokens_used_total{provider,model}
llm_retries_total{provider,model,error_type}
llm_queue_depth{priority,task_type}
llm_queue_wait_seconds{priority,task_type}
llm_rate_limit_hits_total{provider,model,limit_type}
llm_fallbacks_total{from_provider,to_provider,reason}
llm_duplicate_suppressed_total{task_type}

Das nützlichste Dashboard-Panel bei tatsächlichen Störungen zeigt oft nicht die Latenz. Es zeigt:

queue_wait_seconds p50 / p95
rate_limit_hits by provider and model
tokens_reserved vs tokens_used
fallback rate by reason

Wenn tokens_reserved durchgehend deutlich höher ist als tokens_used, sind Ihre Reservierungen zu konservativ. Liegt der Wert zu nahe am tatsächlichen Verbrauch oder darunter, überbuchen Sie Ihre Kapazität und stoßen unerwartet an das TPM-Limit.

Ein praktischer Wrapper für Wiederholungsversuche

Hier ist ein kompaktes Muster, um Anfragen nur bei geeigneten Fehlern zu wiederholen:

import asyncio
import random
import time

RETRYABLE_STATUS = {429, 500, 502, 503, 504}

class LLMError(Exception):
    def __init__(self, status, message="", retry_after=None):
        self.status = status
        self.retry_after = retry_after
        super().__init__(message)

def jittered_backoff(attempt, base=0.5, cap=20):
    return random.uniform(0, min(cap, base * (2 ** attempt)))

async def call_with_retries(fn, max_attempts=4, max_elapsed=20):
    started = time.monotonic()

    for attempt in range(max_attempts):
        try:
            return await fn()
        except LLMError as error:
            elapsed = time.monotonic() - started
            if error.status not in RETRYABLE_STATUS:
                raise
            if attempt == max_attempts - 1 or elapsed >= max_elapsed:
                raise

            delay = jittered_backoff(attempt)
            if error.retry_after is not None:
                delay = max(delay, error.retry_after)

            remaining = max_elapsed - elapsed
            await asyncio.sleep(min(delay, remaining))

Der Wrapper ist bewusst unspektakulär. Die ausgefeilte Logik gehört in die Klassifizierung, Warteschlangenverwaltung, Idempotenz und das Routing – nicht in eine magische Wiederholungsschleife, die es endlos weiter versucht.

Praktische Empfehlungen

• Modellieren Sie Ratenlimits sowohl als RPM als auch als TPM. Eine Drosselung, die den Tokenverbrauch berücksichtigt, verhindert Überraschungen durch große Prompts.
• Verwenden Sie exponentielles Backoff mit zufälliger Streuung, und beachten Sie die Header für Wiederholungsversuche, wenn der Anbieter sie bereitstellt.
• Platzieren Sie eine Warteschlange und einen Dispatcher zwischen Ihrer Anwendung und den LLM-Anbietern, wenn Sie Batch-Verarbeitung oder hohe Anfragevolumen bewältigen müssen.
• Maßnahme Parallelität getrennt von Ratenlimits; andernfalls können Latenzspitzen zu viele gleichzeitig laufende Aufrufe verursachen.
• Design kontrollierte Funktionseinschränkungen gezielt: kleinere Modelle, kürzerer Kontext, Hintergrundaufgaben in der Warteschlange oder zwischengespeicherte Antworten.
• Behandeln Sie Fallback über mehrere Anbieter als Funktion zur Verbesserung der Zuverlässigkeit, nicht als Freibrief, wahllos doppelte Anfragen zu versenden.
• Verwenden Sie Idempotenzschlüssel und Vorgangsprotokolle um doppelte Abrechnungen zu reduzieren und doppelte Generierungen zu unterdrücken.
• Seien Sie gegenüber Nutzern ehrlich, wenn eine Streaming-Antwort fehlschlägt, nachdem bereits Tokens ausgegeben wurden.
• Richten Sie Dashboards auf folgende Kennzahlen aus: Wartezeit in der Warteschlange, Tokenreservierung, erreichte Ratenlimits, Wiederholungsversuche und Gründe für Fallbacks.
• Halten Sie die Wiederholungslogik einfach; die eigentliche Arbeit im Produktivbetrieb besteht in der Budgetierung, Ablaufplanung und darin, zu wissen, wann keine Wiederholung sinnvoll ist.