Zuletzt aktualisiert: 2026-06-22

Planung von LLM-Ratenbegrenzungen erklärt

Die Planung von LLM-Ratenbegrenzungen ist der Vorgang, die nachhaltige Anfragerate – und die damit verbundene Anzahl gleichzeitig laufender Anfragen – zu bestimmen, die die API-Grenzen eines Anbieters für eine gegebene Arbeitslast zulassen. Gehostete Inferenz-APIs eines großen Sprachmodells (LLM) begrenzen den Durchsatz auf zwei voneinander unabhängigen Achsen: Token pro Minute (TPM), die Zahl der Token – Eingabe plus Ausgabe –, die das Konto je Minute verarbeiten darf, und Anfragen pro Minute (RPM), die Zahl der API-Aufrufe, die je Minute unabhängig von ihrer Größe erlaubt sind. Welche Grenze zuerst erreicht wird, setzt die Obergrenze.

Welche Grenze bindet

Eine Arbeitslast mit durchschnittlichen Token-Kosten je Aufruf übersetzt die TPM-Grenze in eine äquivalente Anfragegrenze. Die Division des Tokenbudgets pro Minute durch die je Anfrage verbrauchten Token ergibt die Anfragen pro Minute, die allein die Tokengrenze zulässt:

Dabei ist $L_t$ die TPM-Grenze und $n$ die Token je Anfrage. Die nachhaltige Rate ist der kleinere Wert aus dieser tokenbasierten Grenze und der expliziten RPM-Grenze $L_r$:

Gilt $R_t < L_r$, so bindet die Tokengrenze; gilt $R_t \ge L_r$, so bindet die Anfragegrenze. Tokenintensive Arbeit (langer Kontext, umfangreiche Vervollständigungen) ist tendenziell tokengebunden; viele kleine Aufrufe mit hoher Frequenz sind tendenziell anfragegebunden.

Parallelität nach dem Gesetz von Little

Die nachhaltige Rate pro Sekunde beträgt $R_s = R / 60$. Das Gesetz von Little, ein Ergebnis der Warteschlangentheorie, das besagt, dass die durchschnittliche Anzahl der Elemente in einem System gleich der Ankunftsrate multipliziert mit der durchschnittlichen Verweildauer jedes Elements ist, überführt diese Rate und die mittlere Anfragelatenz $t_L$ in die Parallelität $C$, die parallel laufen muss, um die Leitung ausgelastet zu halten:

Rechenbeispiel

Betrachtet werden eine TPM-Grenze von $L_t = 2\,000\,000$, eine RPM-Grenze von $L_r = 10\,000$ und durchschnittlich n = 2,000 Token je Anfrage. Die tokenbasierte Grenze beträgt

Da 1,000 < 10,000, bindet die Tokengrenze: Der Durchsatz ist auf 1.000 Anfragen pro Minute begrenzt, nicht auf die genannten 10.000. Bei einer durchschnittlichen Latenz von $t_L = 20$ Sekunden beträgt die Rate pro Sekunde $R_s = 1\,000 / 60 \approx 16.7$, sodass die erforderliche Parallelität

beträgt. Die Aufrechterhaltung der Rate bedeutet somit, etwa 333 Anfragen gleichzeitig in Bearbeitung zu halten. Da die Arbeitslast tokengebunden ist, würde eine Anhebung der RPM-Grenze nicht helfen; eine Verringerung der Token je Anfrage – durch kürzere Prompts, kleinere Vervollständigungen oder Rechner für Einsparungen durch Prompt-Caching – oder die Beantragung einer höheren TPM-Zuteilung hingegen schon.

Varianten und Anwendung

Sind die Anfragen stattdessen anfragegebunden, erhöht das Bündeln mehrerer Elemente je Aufruf den effektiven Durchsatz, während eine Reduktion der Token nichts bewirkt. Die Latenz wirkt nur über das Gesetz von Little: Eine Verdopplung von $t_L$ verdoppelt die Parallelität, die eine feste Rate erfordert, sodass schnellere Modelle die Dimensionierung von Verbindungspool und Warteschlange entspannen. Der Wert für die Parallelität fließt in die Client-Konfiguration ein – Anzahl der Worker, Semaphor-Grenzen, Verbindungspools –, und die nachhaltige Rate fließt über Rechner für monatliche LLM-Kosten in Kostenprognosen ein. Da die Tokenzahlen je Anfrage schwanken und Anbieter Anfragen in eine Warteschlange stellen oder im Burst verarbeiten können, sind die Werte für den eingeschwungenen Zustand eine Planungsgrundlage, die am realen Verkehr zu überprüfen ist.