Rate Limits und Ausfälle: Resiliente Architektur für LLM-APIs

Jede Anwendung, die auf eine LLM-API baut, hat eine Abhängigkeit, die sie nicht kontrolliert. Der Anbieter drosselt Anfragen, wenn das Kontingent erschöpft ist, er antwortet in Lastspitzen langsamer, und gelegentlich fällt der Dienst für Minuten oder länger aus. Das ist kein Ausnahmezustand, sondern der Normalbetrieb verteilter Systeme. Die Frage ist nicht, ob es passiert, sondern was die eigene Anwendung dann tut.

In vielen Codebasen lautet die ehrliche Antwort: Sie wirft einen Fehler bis zur Oberfläche durch, oder schlimmer, sie versucht es sofort wieder und verschärft damit genau das Problem, an dem sie gerade scheitert. Resilienz gegenüber Rate Limits und Ausfällen ist keine Frage einzelner Tricks, sondern eine Architekturentscheidung, die sich durch mehrere Schichten zieht: Wiederholungslogik, Lastglättung, Ausweichpfade und Zeitbudgets.

Backoff und Retries ohne Retry-Stürme

Der erste Reflex bei einem fehlgeschlagenen Aufruf ist die Wiederholung, und sie ist grundsätzlich richtig: Viele Fehler bei LLM-APIs sind transient. Falsch wird es, wenn alle Clients gleichzeitig und sofort wiederholen. Dann trifft die geballte Last erneut auf einen ohnehin überlasteten Dienst, und aus einer kurzen Störung wird ein selbstverstärkter Ausfall, der sogenannte Retry-Sturm.

Die Gegenmittel sind bekannt und wirksam. Exponentielles Backoff verdoppelt die Wartezeit nach jedem Fehlversuch, sodass die Last schnell abklingt. Jitter, also ein zufälliger Anteil an der Wartezeit, verhindert, dass alle Clients im Takt wiederholen. Dazu gehört eine harte Obergrenze an Versuchen, typischerweise im niedrigen einstelligen Bereich, und die Unterscheidung nach Fehlertyp: Eine Drosselung ist wiederholbar, ein ungültiger Request ist es nicht, und wer beides gleich behandelt, wiederholt sinnlos.

Wenn die API im Drosselungsfall eine empfohlene Wartezeit mitliefert, sollte man sie respektieren statt eigene Annahmen zu treffen. Und auf einer Ebene darüber lohnt sich ein Circuit Breaker: Häufen sich Fehler über eine Schwelle, werden Aufrufe für eine Weile gar nicht erst versucht, sondern sofort in den Ausweichpfad geleitet. Das schützt den Anbieter, vor allem aber die eigene Anwendung vor blockierten Threads und wachsenden Warteschlangen.

Queues zur Lastglättung

Retries behandeln den Fehlerfall. Besser ist, ihn seltener eintreten zu lassen. Viele Drosselungen entstehen nicht durch zu viel Gesamtlast, sondern durch Spitzen: Ein Batch-Job startet, ein Newsletter geht raus, viele Nutzer tun kurz nacheinander dasselbe. Eine Queue zwischen Anwendung und LLM-Aufruf glättet diese Spitzen, indem sie Anfragen mit kontrollierter Rate abarbeitet.

Der entscheidende Schnitt verläuft zwischen interaktiven und nachgelagerten Aufgaben. Interaktive Anfragen, auf die ein Nutzer wartet, gehören auf den direkten Pfad mit hoher Priorität. Alles andere, Zusammenfassungen, Klassifizierungen, Anreicherungen, Reports, verträgt Verzögerung und gehört in die Queue. Diese Trennung allein löst einen großen Teil der Drosselungsprobleme, weil Hintergrundlast nicht mehr mit Nutzern um dasselbe Kontingent konkurriert. Wichtig ist, die Queue mit einer maximalen Verweildauer zu versehen: Eine Anfrage, die eine Stunde alt ist, ist oft nicht mehr sinnvoll zu beantworten und sollte verworfen oder neu bewertet werden.

Fallback: Zweitmodell und degradierter Modus

Wenn der primäre Pfad länger ausfällt, braucht die Anwendung eine Antwort auf die Frage, was stattdessen passiert. Zwei Muster haben sich bewährt.

Das erste ist der Fallback auf ein Zweitmodell: ein anderes Modell desselben Anbieters, derselbe Modelltyp bei einem zweiten Anbieter oder eine kleinere, günstigere Variante. Das klingt einfacher als es ist, denn Prompts verhalten sich nicht identisch über Modelle hinweg. Ein Fallback-Modell, das nie getestet wurde, ist kein Fallback, sondern eine Hoffnung. Wer diesen Pfad ernst meint, nimmt ihn in die Evals auf und prüft regelmäßig, dass die Qualität im Ausweichfall akzeptabel bleibt.

Das zweite Muster ist der degradierte Modus: Die Anwendung bleibt nutzbar, aber ohne die KI-Funktion. Die Suche liefert dann eben nur die klassische Trefferliste ohne generierte Zusammenfassung, das Formular muss manuell ausgefüllt werden, der Entwurf kommt später per Nachricht. Ehrlich kommuniziert ist das für Nutzer fast immer akzeptabler als eine Fehlermeldung oder eine endlos drehende Ladeanzeige. Voraussetzung ist, dass die Anwendung so gebaut ist, dass die KI-Funktion ausfallen kann, ohne den Kernfluss zu blockieren.

Timeouts: Zeitbudgets statt Geduld

LLM-Aufrufe sind langsam im Vergleich zu klassischen APIs, und ihre Dauer streut stark. Das verführt zu großzügigen oder fehlenden Timeouts, und genau das rächt sich im Störungsfall: Hängende Aufrufe binden Verbindungen und Worker, bis die Anwendung selbst nicht mehr reagiert.

Sinnvoller als ein einzelner Timeout ist ein Zeitbudget pro Anfrage, das sich über die Kette verteilt. Wer dem Nutzer nach einer bestimmten Zeit eine Antwort schuldet, muss davon die Retries, den möglichen Fallback und die eigene Verarbeitung abziehen. Daraus ergibt sich der Timeout des einzelnen Aufrufs, nicht umgekehrt. Bei Streaming-Antworten gehört zusätzlich ein Timeout auf das erste Token und auf Pausen zwischen Tokens, denn ein Stream, der nach der Hälfte verstummt, ist der unangenehmste Fehlerfall: Er sieht lange wie Erfolg aus.

Rate-Limit-Budgets pro Feature

Ein oft übersehener Punkt: Das Kontingent beim Anbieter ist eine geteilte Ressource, und ohne interne Regeln gewinnt einfach der schnellste Verbraucher. Ein neues Feature mit hohem Durchsatz kann dann das wichtigste Feature der Anwendung aushungern, ohne dass jemand eine Entscheidung getroffen hätte.

Die Lösung ist unspektakulär: interne Budgets pro Feature, durchgesetzt an einer zentralen Stelle, durch die alle LLM-Aufrufe laufen. Diese Stelle kennt die Prioritäten, misst den Verbrauch pro Feature und drosselt intern, bevor der Anbieter es extern tut. Der Nebeneffekt ist wertvoll: Man bekommt Kostentransparenz pro Feature gratis dazu und erkennt Verbrauchsanomalien dort, wo sie entstehen.

Fazit

Resilienz gegenüber Rate Limits und Ausfällen entsteht nicht durch eine einzelne Maßnahme, sondern durch das Zusammenspiel mehrerer Schichten: Retries mit Backoff und Jitter gegen transiente Fehler, Queues gegen selbstgemachte Lastspitzen, ein getestetes Zweitmodell oder ein degradierter Modus für längere Störungen, Zeitbudgets statt großzügiger Timeouts und interne Kontingente, damit Features nicht gegeneinander um die API konkurrieren. Nichts davon ist konzeptionell neu, das meiste stammt aus der klassischen Lehre verteilter Systeme. Neu ist nur, dass LLM-APIs diese Disziplin von Anfang an einfordern, weil sie langsamer, teurer und knapper sind als die APIs, an die viele Teams gewöhnt waren.