LLM-Rate-Limits erklärt: RPM, TPM und Retries

LLM-Rate-Limits bestimmen, wie viel Traffic Ihre Anwendung innerhalb eines Zeitfensters an ein Modell senden kann. Die beiden Limits, denen Ingenieure am häufigsten begegnen, sind RPM (Requests pro Minute) und TPM (Tokens pro Minute). Eine Workload kann unter dem einen Limit bleiben und dennoch das andere überschreiten.

Diese Unterscheidung ist wichtig. Wenn Sie jedes 429 als generisches Problem der Anfrageanzahl behandeln, fügen Sie möglicherweise Retries hinzu, die den Token-Druck erhöhen, die Latenz steigern und eine Störung verschlimmern. Ein produktionssicheres Design identifiziert zuerst die knappe Ressource und entscheidet dann zwischen Taktung, Warteschlangen, Retries, Token-Reduktion oder Weiterleitung an anderer Stelle.

Dieser Leitfaden erklärt die Mechanik, liefert Formeln zur Kapazitätsplanung und enthält ein begrenztes TypeScript-Retry-Muster für OpenAI-kompatible APIs.

RPM vs. TPM: die Kurzantwort

RPM steuert die Frequenz. TPM steuert den Durchsatz. Gleichzeitigkeit steuert parallele Arbeit. Sie wirken zusammen, sind aber nicht austauschbar.

Warum eine Anfrage unterhalb des Hauptlimits fehlschlagen kann

Ein veröffentlichtes Limit wie 600 RPM bedeutet nicht zwangsläufig, dass ein Client in der ersten Sekunde jeder Minute 600 Requests senden kann. Anbieter setzen Limits häufig mit rollierenden Fenstern oder Token-Bucket-ähnlichen Mechanismen durch. Ein kurzer Burst kann die unmittelbar verfügbare Kapazität erschöpfen, selbst wenn die Rechnung für die ganze Minute sicher aussieht.

Weitere Gründe, warum ein 429 früh auftreten kann, sind:

• Das Limit gilt für ein Projekt, eine Organisation, ein Konto, eine Modellfamilie oder einen Service-Tier und nicht nur für einen API-Schlüssel.
• Input- und Output-Tokens verwenden separate Buckets.
• Mehrere Worker, Dienste oder Benutzer teilen sich denselben Quotenpool.
• Retries aus vorherigen Fehlern verbrauchen dasselbe Limit.
• Der Anbieter wendet ein Beschleunigungs- oder Burst-Limit an, während der Traffic stark ansteigt.
• Ein modellspezifischer Pool ist voll, obwohl ein anderes Modell noch Kapazität hat.

Deshalb sollte die Anwendung die Ursache nicht allein aus ihrem eigenen Request-Zähler ableiten. Lesen Sie den Response-Body und die Header aus, bewahren Sie die Request-IDs des Anbieters auf und protokollieren Sie das Modell, das Konto, Token-Schätzungen, die Versuchszahl und die Warteschlangenverzögerung.

Eine praktische Kapazitätsformel

Beginnen Sie mit zwei unabhängigen Obergrenzen.

request_ceiling = RPM × safety_factor

token_ceiling = (TPM × safety_factor) ÷ average_tokens_per_request

safe_requests_per_minute = min(request_ceiling, token_ceiling)

Verwenden Sie einen Sicherheitsfaktor unter 1.0—zum Beispiel 0.7 bis 0.9—um Token-Varianz, Retries, gemeinsam genutzte Verbraucher und ungleichmäßige Ankunftsmuster abzufedern.

Beispiel

Angenommen, ein Modellsystem erlaubt:

• 1.000 RPM
• 2.000.000 TPM
• durchschnittlich 4.000 Gesamt-Token pro Anfrage
• 80 % Betriebs-Sicherheitsfaktor

request_ceiling = 1,000 × 0.8 = 800 requests/minute

token_ceiling = (2,000,000 × 0.8) ÷ 4,000
              = 400 requests/minute

safe_requests_per_minute = min(800, 400) = 400

TPM ist der begrenzende Faktor. Mehr Worker erhöhen den nachhaltigen Durchsatz nicht; sie erzeugen nur eine größere Warteschlange oder mehr 429-Antworten.

Für Online-Systeme übersetzen Sie den Durchsatz mit dem Little’s-Law-Gesetz in einen Ausgangswert für die Parallelität:

target_concurrency ≈ requests_per_second × average_request_seconds

Wenn die sichere Rate 400 Anfragen pro Minute beträgt (6,67 pro Sekunde) und die durchschnittliche Modell-Latenz 3 Sekunden beträgt, liegt eine sinnvolle Ausgangs-Parallelität bei etwa 20. Fügen Sie Reserven vorsichtig hinzu und stimmen Sie dann gegen reale p95-Latenzen und Token-Verteilungen ab.

Token-Grenzen sind oft der versteckte Engpass

Teams überwachen häufig die Anzahl der Anfragen, übersehen aber das Token-Volumen. Der TPM-Druck steigt, wenn Sie:

• mehr abgerufene Dokumente zu jedem Prompt hinzufügen.
• lange Gesprächsverläufe beibehalten.
• mehrere Kandidaten-Vervollständigungen pro Aufgabe ausführen.
• Ausgabeobergrenzen erhöhen.
• denselben großen System-Prompt wiederholt senden.
• parallele Evaluierungs-Suites gegen ein Projektkontingent starten.

Messen Sie mindestens vier Token-Werte pro erfolgreicher Anfrage:

1. Eingabe-Token.
2. Ausgabe-Token.
3. Gesamt-Token.
4. Ein gleitendes p50, p95 und Maximum nach Workload und Modell.

Kapazitätsplanung nur mit dem Durchschnitt ist optimistisch. Ein sicherer Scheduler reserviert gegen ein hohes Perzentil oder eine workload-spezifische Schätzung und gleicht die Reservierung nach Abschluss mit der tatsächlichen Nutzung ab.

Was ein 429 bedeutet — und was nicht

HTTP 429 Too Many Requests teilt Ihnen mit, dass der Server die Anfrage unter einer aktiven Limit- oder Kapazitätsrichtlinie abgelehnt hat. Es bedeutet nicht automatisch „eine Sekunde warten und erneut versuchen“.

Klassifizieren Sie ein 429 in einen operativen Bucket:

Der Body und die Header unterscheiden sich je nach Provider. Bevorzuge ein explizites Retry-After oder ein Signal zum Reset des Rate-Limits, wenn es bereitgestellt wird. Andernfalls verwende exponentielles Backoff mit zufälligem Jitter.

Exponentielles Backoff mit Jitter

Exponentielles Backoff erhöht die Wartezeit nach jedem fehlgeschlagenen Versuch. Jitter macht diese Wartezeit zufällig, damit nicht Hunderte von Workern im selben Moment erneut versuchen.

Eine gängige Full-Jitter-Formel lautet:

delay_ms = random(0, min(cap_ms, base_ms × 2^attempt))

Eine Retry-Policy für die Produktion braucht außerdem Grenzen:

• Maximale Versuche: normalerweise eine kleine Zahl, keine Endlosschleife.
• Maximale verstrichene Zeit: stoppen, wenn das Latenzbudget des Aufrufers ausgeschöpft ist.
• Liste retrybarer Statuscodes: üblicherweise 429, ausgewählte 5xx-Antworten und sichere Netzwerkfehler.
• Server-Hinweise: Retry-After beachten, wenn er gültig ist.
• Abbruch: sofort stoppen, wenn die Upstream-Anfrage abgebrochen wird.
• Beobachtbarkeit: Anzahl der Versuche, Wartezeit, Endstatus und Provider-Request-ID erfassen.

Fehlgeschlagene Anfragen können dennoch Rate-Limit-Kapazität verbrauchen. Aggressive Retries können daher den Zeitraum der Drosselung verlängern.

TypeScript: ein begrenzter Retry-Helper

Das folgende Beispiel verwendet die mit OpenAI kompatible Flatkey-Basis-URL. Es versucht nur erneut, bevor ein erfolgreicher Response-Body verarbeitet wird, und stoppt, sobald entweder das Versuchslimit oder das gesamte Zeitbudget ausgeschöpft ist.

type ChatRequest = {
  model: string;
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;
  max_tokens?: number;
};

const sleep = (milliseconds: number) =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

function retryAfterMilliseconds(response: Response): number | null {
  const value = response.headers.get("retry-after");
  if (!value) return null;

  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);

  const date = Date.parse(value);
  return Number.isNaN(date) ? null : Math.max(0, date - Date.now());
}

export async function createChatCompletion(
  apiKey: string,
  request: ChatRequest,
  options: { maxAttempts?: number; maxElapsedMs?: number } = {},
) {
  const maxAttempts = options.maxAttempts ?? 4;
  const maxElapsedMs = options.maxElapsedMs ?? 30_000;
  const startedAt = Date.now();

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(
      "https://router.flatkey.ai/v1/chat/completions",
      {
        method: "POST",
        headers: {
          Authorization: `Bearer ${apiKey}`,
          "Content-Type": "application/json",
        },
        body: JSON.stringify(request),
      },
    );

    if (response.ok) return response.json();

    const retryable = response.status === 429 || response.status >= 500;
    const finalAttempt = attempt === maxAttempts - 1;
    if (!retryable || finalAttempt) {
      throw new Error(`LLM-Anfrage fehlgeschlagen mit ${response.status}: ${await response.text()}`);
    }

    const hintedDelay = retryAfterMilliseconds(response);
    const exponentialCap = Math.min(8_000, 500 * 2 ** attempt);
    const jitteredDelay = Math.random() * exponentialCap;
    const delayMs = hintedDelay ?? jitteredDelay;

    if (Date.now() + delayMs - startedAt >= maxElapsedMs) {
      throw new Error("LLM-Wiederholungsbudget erschöpft");
    }

    await sleep(delayMs);
  }

  throw new Error("Unerreichbarer Retry-Zustand");
}

Für den Produktionseinsatz sollten Sie Request-Timeouts, strukturierte Fehlertypen, Metriken und das Abbruchsignal Ihrer Anwendung hinzufügen. Wenn die Operation externe Nebenwirkungen erzeugen kann — etwa das Senden einer E-Mail oder das Ausführen eines Tools — machen Sie die Geschäftsoperation vor dem erneuten Versuch idempotent.

Erneut versuchen, in die Warteschlange stellen, reduzieren oder weiterleiten?

Nutzen Sie die Ursache und nicht allein den Statuscode, um den Umgang zu wählen.

Retry

Retry, wenn der Fehler transient ist und der Aufrufer noch Zeit hat. Halten Sie ein Retry-Budget pro Anfrage und ein Retry-Budget auf Service-Ebene ein, damit ein Provider-Vorfall den gesamten Traffic nicht vervielfacht.

Queue

Queue, wenn die Ankunftsrate vorübergehend die nachhaltige Service-Rate übersteigt. Eine nützliche Queue bietet:

• Alter des ältesten Elements.
• Geschätzte Startzeit.
• Fairness pro Tenant.
• Abbruch für veraltete Jobs.
• Eine maximale Tiefe mit explizitem Shedding-Verhalten.

Token reduzieren

Wenn TPM bindet, entfernen Sie irrelevanten Kontext, fassen Sie den Verlauf zusammen, reduzieren Sie die Anzahl der Kandidaten, senken Sie Ausgabelimits, cachen Sie wiederverwendbare Prompt-Präfixe, wo unterstützt, und trennen Sie kurze interaktive Last von langen Batch-Jobs.

Anderswohin routen

Routing ist passend, wenn ein anderes Modell oder ein anderer Provider denselben Vertrag erfüllt und ausreichende Kapazität hat. Das Fallback muss erforderliche Fähigkeiten wie strukturierten Output, Tool-Calling, Kontextlänge, Sicherheitsrichtlinie und Latenzziel beibehalten. Für ein tieferes Implementierungs-Framework verwenden Sie das LLM API fallback routing playbook.

Rate Limits in Modell-Evaluierungen

Schlechtes Throttling kann eine Evaluierung ungültig machen.

Nehmen wir an, Modell A wird mit 10 Workern getestet, während Modell B mit 100 getestet wird. Wenn Modell B mehr Zeit im Throttling verbringt, umfasst seine gemessene Latenz Queueing und Retry-Verzögerung, denen Modell A nie ausgesetzt war. Das Ergebnis beschreibt möglicherweise Ihre Harness-Konfiguration und nicht die Modellleistung.

Für belastbare Vergleiche:

1. Trennen Sie Modell-Latenz, Queue-Verzögerung und Retry-Verzögerung.
2. Wenden Sie für jeden Provider denselben Ankunftsprozess oder denselben normalisierten Auslastungsgrad an.
3. Fahren Sie Traffic schrittweise hoch, wenn Provider Beschleunigungskontrollen verwenden.
4. Protokollieren Sie Tokens und Versuche pro abgeschlossenem Task.
5. Berichten Sie sowohl die Erfolgsrate beim ersten Versuch als auch die endgültige Erfolgsrate.
6. Vergleichen Sie die Kosten pro akzeptiertem Task, nicht nur die Kosten pro Token.
7. Führen Sie Überlasttests getrennt von Qualitäts- und Latenz-Benchmarks aus.

Wenn Sie Anbieter sowohl nach Zuverlässigkeit als auch nach Kosten bewerten, kombinieren Sie diesen Prozess mit dem AI API pricing comparison.

Eine Produktions-Architektur für Rate Limits

Ein robuster Request-Pfad umfasst in der Regel fünf Steuerungsebenen:

1. Admission Control weist Arbeit zurück oder verschiebt sie, wenn die Frist nicht eingehalten werden kann.
2. Token-Reservierung schätzt die wahrscheinlichen Quota-Kosten der Anfrage.
3. Rate Limiter taktet jeden Anbieter, jeden Modell-Pool, jeden Mandanten und jede Prioritätsklasse.
4. Retry Controller verbraucht ein begrenztes Retry-Budget mit Jitter.
5. Router wählt nach Ausschöpfung des Retry-Budgets oder wenn die Kapazitätsrichtlinie einen Wechsel verlangt eine vertragskompatible Alternative aus.

client
  → admission control
  → priority queue
  → RPM + token reservation limiter
  → provider/model route
  → bounded retry
  → contract-safe fallback
  → usage and latency logs

Platzieren Sie keine unbegrenzte Retry-Schleife in jedem Anwendung-Worker. Zentralisieren Sie die Richtlinie, damit alle Aufrufer dasselbe Verständnis der verfügbaren Kapazität teilen.

Metriken, auf die sich Alarme lohnen

Verfolgen Sie diese nach Anbieter, Modell, Projekt, Route, Mandant und Workload:

• Requests pro Minute und Tokens pro Minute.
• Geschätzte reservierte Tokens im Vergleich zu tatsächlich verwendeten Tokens.
• Erfolgsrate beim ersten Versuch.
• Retry-Versuche pro erfolgreicher Anfrage.
• 429-Rate nach klassifizierter Ursache.
• Queue-Tiefe und Alter des ältesten Eintrags.
• Zeit, die auf verfügbare Rate-Kapazität gewartet wurde.
• End-to-End-Latenz p50, p95 und p99.
• Fallback-Rate und Fallback-Ergebnis.
• Kosten pro erfolgreicher oder angenommener Aufgabe.

Ein Alarm allein auf die Gesamtzahl der 429 ist verrauscht. Ein besseres Signal kombiniert Drosselungsrate mit Queue-Alter, Retry-Verstärkung und finaler Fehlerrate.

Häufige Fehler

RPM als Concurrency-Limit behandeln

RPM misst Annahmen über die Zeit; Concurrency misst laufende Arbeit. Langsame Requests können bei moderatem RPM eine hohe Concurrency erzeugen.

Jedes 429 sofort erneut versuchen

Unmittelbare Retries synchronisieren Worker und verbrauchen mehr Kapazität. Beachten Sie Server-Timing, wenn verfügbar, und fügen Sie Jitter hinzu.

Einen einzigen Limiter für jedes Modell verwenden

Anbieter können separate oder gemeinsame Pools verwenden. Modellbezogene Richtlinien sollten dem dokumentierten Quota-Scope des Anbieters und den beobachteten Headern folgen.

Gemeinsame Verbraucher ignorieren

Ein Dashboard, ein Batch-Job und eine Produktions-API können sich ein Projekt-Quota teilen. Reservieren Sie Kapazität nach Workload und isolieren Sie kritischen Traffic, wo immer möglich.

Einen Teil-Stream erneut versuchen

Sobald Tokens den Nutzer erreicht haben, kann ein erneutes Abspielen der Anfrage Inhalte oder Tool-Aktionen duplizieren. Definieren Sie explizite Fortsetzungs- oder Neustart-Semantiken, statt stillschweigend erneut zu versuchen.

Wie Flatkey das Betriebsmodell verändert

Flatkey stellt einen API-Schlüssel und eine OpenAI-kompatible Base URL für den Zugriff auf unterstützte Modellanbieter bereit. Das gibt einer Anwendung eine einzige Integrationsoberfläche, während die Routing-Richtlinie weiterhin Modell-Fit, Kapazität, Zuverlässigkeit und Kosten berücksichtigen kann.

Das Gateway entfernt keine Upstream-Limits. Es erleichtert jedoch die Implementierung konsistenter Kontrollen darum herum: eine Client-Integration, zentralisierte Request-Logs und die Option, zulässigen Traffic auf eine andere Route zu verlagern, wenn eine Route eingeschränkt ist. Lesen Sie den Leitfaden zur Architektur eines AI-API-Gateways für das übergeordnete Routing-Design oder sehen Sie sich die aktuellen Flatkey-Preise an, bevor Sie Produktionsrouten auswählen.

FAQ

Was ist der Unterschied zwischen RPM und TPM?

RPM begrenzt, wie viele Requests über die Zeit zugelassen werden. TPM begrenzt, wie viele Input- und/oder Output-Tokens zugelassen werden. Kleine Prompts belasten normalerweise zuerst RPM; Workloads mit großem Kontext oder hoher Ausgabe belasten oft zuerst TPM.

Warum erhalte ich 429-Fehler unterhalb meines RPM-Limits?

Der Anbieter kann kürzere rollierende Zeitfenster, Token-Buckets, gemeinsam genutzte Projektquoten, separate Token-Limits, Beschleunigungsgrenzen oder modellspezifische Pools durchsetzen. Ihr lokaler Request-Zähler bildet möglicherweise nicht den gesamten Umfang der Quote ab.

Sollte ich jeden 429 erneut versuchen?

Nein. Wiederholen Sie kurzzeitiges Throttling mit einem kleinen Budget und Jitter. Versuchen Sie nicht wiederholt, eine tägliche Quota-Erschöpfung, Abrechnungsbeschränkungen oder eine anhaltende Überlastung zu umgehen, bei der keine Zeit zur Erholung bleibt.

Garantiert exponentielles Backoff Erfolg?

Nein. Backoff reduziert Kollisionen und gibt vorübergehender Kapazität Zeit zur Erholung. Es kann keine Quote erzeugen. Anhaltende Erschöpfung erfordert geringere Nachfrage, mehr Kapazität, verzögerte Arbeit oder eine andere zulässige Route.

Wie viele Retries sollte ein LLM-Request verwenden?

Es gibt keine universelle Zahl. Legen Sie die Anzahl der Versuche anhand des für den Benutzer sichtbaren Latenzbudgets und des Fehlermodus fest. Viele interaktive Anwendungen sollten nur wenige kurze Versuche zulassen, bevor sie fehlschlagen oder anderweitig routen; Offline-Jobs können längere Warteschlangen tolerieren.

Zählen Retries gegen Rate Limits?

Das können sie. Anbieter können erfolglose Versuche auf aktive Limits anrechnen, daher muss Retry-Verstärkung überwacht und begrenzt werden.

Abschließende Checkliste

• Modellieren Sie RPM, TPM, Tageslimits und Parallelität getrennt.
• Berechnen Sie die Kapazität aus dem Minimum von Request- und Token-Obergrenzen.
• Betreiben Sie unterhalb des veröffentlichten Maximums mit einem Sicherheitsfaktor.
• Verwenden Sie Warteschlangen und Pacing für anhaltende Last.
• Beachten Sie Retry-After und verwenden Sie exponentielles Backoff mit Jitter.
• Begrenzen Sie Versuche und die gesamte Retry-Zeit.
• Spielen Sie keine teilweisen Streams oder Seiteneffekte automatisch erneut ab.
• Routen Sie nur zu Modellen, die den erforderlichen Vertrag einhalten.
• Trennen Sie Queue- und Retry-Verzögerung von der Modell-Latenz in Evaluierungen.
• Alarmieren Sie bei Retry-Verstärkung und Queue-Alter, nicht nur bei reinen 429-Zahlen.

Rate Limits sind zuerst ein Problem der Kapazitätsplanung und erst danach ein Problem des Retries. Sobald Sie Request-Frequenz, Token-Durchsatz, Parallelität und Retry-Verstärkung unabhängig voneinander messen, werden 429-Fehler zu umsetzbaren Signalen statt zu unvorhersehbarem Produktionsrauschen.