LLM-Fallback: Ausfallsicherheit und Antwortzeit im Chatbot

Ein LLM-Fallback ist die Regel, nach der ein Chatbot auf ein zweites Sprachmodell (LLM, Large Language Model) ausweicht, wenn das erste ausfällt, einen Fehler meldet oder zu langsam antwortet. Im Betrieb braucht er vier Bausteine: eine Reserve bei einem anderen Anbieter, eine Zeitgrenze, ab der die Reserve gewinnen darf, ein hartes Gesamtbudget pro Anfrage und Health-Checks mit echten Probeanfragen. Die Antwortzeit messen Sie als Median, als 95. Perzentil und als Anteil über 10 Sekunden, nicht als Durchschnitt.

Die Zahlen stammen aus unserem eigenen Produkt, einer Videochat-Conversational-AI für Endkunden, die wir selbst entwickeln und betreiben. Den Produktnamen nennen wir hier nicht, weil es sich an Endkunden richtet. Stand Oktober 2026 hat es über 60.000 registrierte Nutzer; vom 8. September bis 5. Oktober 2026 liefen rund 69.000 Videochat- und rund 15.000 Textchat-Sitzungen. Alle Messwerte kommen aus unserem eigenen Monitoring; den Aufbau beschreibt das Praxisbeispiel Videochat-Conversational-AI. Die Wahl des Anbieters behandelt der Artikel KI Build vs. Buy, hier geht es um den Betrieb, also um ein LLM in der Produktion.

Zwei Bedeutungen von Fallback: Wissenslücke und Anbieterausfall

Fallback steht für zwei verschiedene Probleme. Bei einer Wissenslücke kennt der Chatbot die Antwort nicht. Gute Reaktionen sind eine Rückfrage, eine ehrliche Ablehnung oder die Übergabe an einen Menschen; wie Sie das messen, zeigt der Artikel RAG-Antwortqualität messen. Bei Anbieterausfall oder Langsamkeit antwortet das Modell nicht, zu spät, mit einem Fehlercode oder mit unbrauchbarem Text. Um diese technische Ausfallsicherung (Failover) geht es hier.

Zwei Begriffe tauchen dabei oft auf. Ein LLM Router verteilt Anfragen nach Regeln auf mehrere Modelle, ein LLM Gateway ist eine zentrale Zwischenschicht für alle Modellaufrufe. Ob die Fallback-Regeln dort oder direkt im Backend liegen, ist zweitrangig. Mehrere LLM-Anbieter senken nebenbei den Vendor Lock-in, also die Abhängigkeit von einem einzelnen Anbieter.

Was bei einem LLM in der Produktion wirklich ausfällt

Ausfall heißt im Betrieb nicht nur „alles steht“. Jede Störung braucht eine eigene Erkennung und eine eigene Reaktion.

Bedeutung der Statuscodes: MDN, HTTP-Antwortstatuscodes.

Reserve von Anfang an: die Zeitgrenze von 2,5 Sekunden

Die naheliegende Lösung arbeitet nacheinander: erst das Hauptmodell, bei einem Fehler die Reserve. Ein Anbieter, der hängt, liefert aber keinen Fehler, sondern nichts.

Bei uns geht deshalb jede Chat-Anfrage gleichzeitig an das Hauptmodell und an ein Reservemodell beim jeweils anderen Anbieter. Die Reserve darf erst gewinnen, wenn das Hauptmodell nach 2,5 Sekunden noch nicht geantwortet hat; ab dann zählt die erste fertige Antwort. Beim Hauptmodell laufen bis zu drei Versuche. Weil die Reserve von Anfang an mitläuft, kann ihre Antwort an der Zeitgrenze schon fertig sein. Die Grenze muss über der üblichen Antwortzeit des Hauptmodells liegen, sonst gewinnt die Reserve zu oft. Zum Vergleich: Die serverseitige Antwortzeit unseres Textchat-Endpunkts lag vom 8. September bis 6. Oktober 2026 im Tagesmedian bei 1,44 bis 1,98 Sekunden, gemessen nur an erfolgreichen Antworten. Darin steckt mehr als der reine Modellaufruf.

Ein hartes Gesamtbudget pro Anfrage

Für das gesamte Rennen hinter einer Antwort gilt bei uns ein hartes Budget von 20 Sekunden; der Client bricht jeden API-Aufruf nach 30 Sekunden ab. Vorher wartete eine Anfrage bei einem Anbieterausfall bis zu 60 Sekunden und endete als Timeout, obwohl der Client die Antwort längst verworfen hatte. Das Budget des Servers muss also unter der Abbruchgrenze des Clients liegen. In JavaScript setzen Sie solche Grenzen etwa mit AbortSignal.timeout(), siehe MDN-Dokumentation zu AbortSignal.timeout().

Dauerhafte Fehler nicht wiederholen

Die Statuscodes 401, 402 und 403 zeigen etwa einen ungültigen Schlüssel oder ein leeres Prepaid-Guthaben beim Anbieter an. Ein zweiter Versuch ändert daran nichts. Bei uns gibt es deshalb keinen weiteren Versuch beim selben Anbieter, die Reserve übernimmt, und sofort geht eine Alarm-Mail hinaus, höchstens einmal pro Stunde je Anbieter und Status. Jede Server-Instanz merkt sich den abgelehnten Anbieter für 10 Minuten.

Die Reserve gehört zu einem anderen Anbieter

Eine Reserve beim selben Anbieter schützt vor einem langsamen Modell, nicht vor einem Ausfall des Anbieters. In einer früheren Konfiguration lagen bei uns beide Reservemodelle beim selben Anbieter. Als dieser am 30. August 2026 ausfiel, war die ganze Reserveschicht auf einmal weg. Seit dem 2. September 2026 liegt die Reserve immer beim jeweils anderen Anbieter.

Zwei weitere Regeln gehören dazu. Testen Sie jeden Prompt auf beiden Modellen, und legen Sie Ausgabeformate wie JSON so fest, dass beide Anbieter sie zuverlässig liefern. Sonst wird die Reserve im Ernstfall zur Qualitätsfalle. Zeitgrenze, Gesamtbudget, zweiter Anbieter und Alarmwege gehören deshalb schon ins Lastenheft für Software und KI.

Die schnellste Antwort ist nicht die beste

Nach der Zeitgrenze gewinnt die schnellste Antwort, nicht die beste. Bei uns lief ein schwächeres drittes Modell im Rennen mit. Vom 31. Juli bis 2. September 2026 lieferte es 11 Prozent aller Antworten (10.820 von 98.371), obwohl es auf allen Qualitätszählern am schlechtesten abschnitt, etwa mit rund 1,5 Prozent fast leeren Antworten gegenüber 0,1 Prozent. Am 2. September 2026 haben wir es entfernt. Jedes Modell im Rennen muss also für sich gut genug sein.

Zusätzlich bekommt jede Antwort eine regelbasierte Plausibilitätsbewertung, die etwa leere Antworten und Wiederholungen erkennt. Fällt die Gewinnerantwort auf, vergleicht das System sie mit der Antwort des anderen Modells aus demselben Rennen und liefert die bessere aus. Bleibt sie auffällig, entfällt die Sprachausgabe.

Schattentest: Qualität gegen Latenz

Neue Modelle testen wir im Schattenbetrieb. Vom 8. September bis 7. Oktober 2026 ging bei 1 Prozent der Videochat-Antworten dieselbe Anfrage zusätzlich an einen Kandidaten. Seine Antwort wurde nie ausgeliefert und konnte das Rennen nicht gewinnen. So gingen auch langsame Antworten in die Messung ein.

Die Qualität bewertet bei uns ein separates LLM als Prüfmodell nach fester Rubrik: eine Note von 1 (beste Note) bis 6 und genau ein Hauptproblem aus einer geschlossenen Liste. Im laufenden Betrieb prüft es eine Stichprobe der ausgelieferten Videochat-Antworten, seit dem 7. Oktober 2026 sind es 0,3 Prozent. Wichtig ist ein fest versionierter Snapshot des Prüfmodells, also eine Modellversion, die sich nicht unbemerkt ändert; sonst könnte sich der Maßstab unter einer laufenden Kennzahl ändern.

Ein Kandidat war in der Qualität klar besser: Note 2,37 statt 2,68, ein Abstand von rund vier Standardfehlern. Übernommen haben wir ihn trotzdem nicht. Ein Einzelaufruf brauchte im Median 2,3 Sekunden, 33 Prozent lagen über 3 und 13,5 Prozent über 6 Sekunden. Die Live-Modelle antworteten zu 98 bis 99 Prozent unter 3 Sekunden.

Antwortzeit messen: Median, p95 und Anteil über 10 Sekunden

Ein Durchschnitt versteckt die langsamen Antworten, an die sich Nutzer erinnern. Der Median zeigt das normale Erlebnis: Die Hälfte der Antworten ist schneller. Das p95 (95. Perzentil) zeigt die spürbar langsamen Fälle, denn 95 Prozent der Antworten sind schneller. Der Anteil über 10 Sekunden zeigt Ausreißer, die beide Werte nicht mehr erfassen.

Viele Anleitungen nennen zusätzlich Time to First Token (TTFT), die Zeit bis zum ersten ausgegebenen Textbaustein. Sie zählt, wenn ein Chat die Antwort schon während der Erzeugung anzeigt. Unsere Werte sind keine TTFT, sondern serverseitige Antwortzeiten des Textchat-Endpunkts, nur für erfolgreiche Antworten.

Quelle: unser eigenes Monitoring. Der Umbau am 29. September 2026 verlegte die Zusammenfassung langer Verläufe in den Hintergrund (nächster Abschnitt). Das ist nicht die Zeit bis zum Sprechbeginn im Videochat; dort kommen Sprachsynthese und Wiedergabe hinzu. Jede Antwort über 4 Sekunden protokollieren wir als Warnung, über 5 Sekunden als Fehler, und Tagesberichte verfolgen den Anteil über 10 Sekunden.

Der größte Gewinn kam aus der Architektur

Ab 22 Nachrichten fasst bei uns ein LLM den Gesprächsverlauf zusammen. Diese Zusammenfassung lief früher vor der Antwort. Vom 19. bis 22. September 2026 dauerten 58 Antworten länger als 10 Sekunden; 49 davon waren nach 1 bis 3 Sekunden fertig und wurden 10 bis 72 Sekunden aufgehalten. Seit dem 29. September 2026 läuft die Zusammenfassung im Hintergrund. Das p95 sank von 5,40 Sekunden vor dem Umbau auf Tageswerte von 3,54 bis 4,09 Sekunden, der Anteil über 10 Sekunden von 0,93 Prozent auf 0. Ein schnelleres Modell hätte daran wenig geändert. Nach demselben Prinzip laufen bei uns Prüfung der Eingabe, Antwortgenerierung und Sprachsynthese parallel statt nacheinander.

Strukturierte Ausgabe: verlässlicher und nicht langsamer

Soll das Modell aus einer festen Liste wählen, etwa eine Kategorie oder den nächsten Schritt im Dialog, hilft ein JSON-Schema: eine maschinenlesbare Beschreibung der erlaubten Felder und Werte. Ohne Schema lieferte ein Modell bei uns in 294 von 57.043 Antworten (0,52 Prozent) einen Wert außerhalb der Liste, mit Schema in 1 von 30.679. In einer kleinen Messung am 2. September 2026 mit 44 Aufrufen je Variante war das Schema nicht langsamer, eher schneller: Es lag im Median bei 1.128 Millisekunden, 4,5 Prozent der Aufrufe überschritten die Grenze von 2,5 Sekunden. Freies JSON brauchte 1.272 Millisekunden, 11,4 Prozent lagen darüber. Wie ein solches Schema im Videochat die Auswahl des nächsten Clips absichert, zeigt der Artikel Chatbot mit Avatar.

Was Redundanz kostet

Die parallele Reserve erzeugt pro Anfrage zwei LLM-Aufrufe statt einem, und die Eingabe fällt bei beiden an. Ob das ins Gewicht fällt, hängt davon ab, was eine Antwort sonst kostet. In unserem Videochat dominiert die Stimme. Laut unserer Kostenschätzung vom 17.09.2026 (Listenpreise der Anbieter) macht die Sprachausgabe rund 90 Prozent der variablen Kosten einer gesprochenen Antwort aus, etwa das Zehnfache der LLM-Antwort. Ein Prompt umfasst dabei 3.000 bis 4.000 Tokens (Textbausteine, nach denen Modellanbieter abrechnen), die Antwort höchstens 160. Auch mit dem Reserveaufruf bleibt der LLM-Anteil klein gegenüber der Stimme; mehr dazu im Artikel Chatbot mit Sprachausgabe.

Bei einem reinen Text-Chatbot ist das LLM dagegen der wesentliche variable Kostenblock. Dann lohnt der Vergleich von drei Strategien:

Ein kleineres Reservemodell senkt die Zusatzkosten, solange es auf Ihrem Test-Set gut genug antwortet.

Monitoring: echte Probeanfragen statt Katalog

Anbieter warnen nicht vor. Am 25. August 2026 nahm ein Anbieter ein von uns genutztes Prüfmodell ohne Ankündigung aus dem Katalog. Am 30. August 2026 war ein Prepaid-Guthaben leer, und ein Prüfmodell fiel stundenlang aus. Beide Vorfälle führten bei uns zu Health-Checks und Alarmen:

• Alle 30 Minuten prüft ein Health-Check, also eine automatische Erreichbarkeitsprüfung, sämtliche KI-Abhängigkeiten.
• Textmodelle bekommen eine echte Anfrage mit einem Token, die Schlüssel, Guthaben und Modell zugleich prüft. Andere Modelle prüft der Check über den Modellkatalog.
• Alarm gibt es erst nach drei Fehlschlägen in Folge, also frühestens nach einer Stunde.
• Kritische Alarme wiederholen sich alle 6 Stunden, Warnungen wöchentlich. Ein angekündigtes Abschaltdatum unter 30 Tagen gilt als kritisch.

Der Katalog allein reicht nicht. Ein Anbieter lieferte ein Modell wochenlang weiter aus, obwohl es nicht mehr im Katalog stand. Ein fehlender Eintrag ist nur ein Hinweis; ob ein Modell erreichbar ist, entscheidet die echte Probeanfrage.

Die Überwachung überwachen

Ein Health-Check, der nicht läuft, meldet auch nichts. Eine Nachanalyse am 6. Oktober 2026 fand bei uns Lücken von bis zu 55,8 Stunden ohne Lauf. Unsere Lehre und Empfehlung: ein Gesamt-Timeout für jeden Lauf und ein Alarm, wenn zwei Stunden lang kein Lauf protokolliert ist. Dass Monitoring und Betriebsverantwortung vor dem Rollout feststehen sollten, begründet unser Artikel darüber, warum KI-Projekte scheitern und wie der Pilot in die Produktion kommt.

Fallback auch für Prüfmodelle

Neben dem Antwortmodell arbeiten oft Prüfmodelle, die Eingaben oder Antworten bewerten. Auch sie fallen aus, und für unsere Prüfmodelle gelten eigene Regeln:

• Früher Start der Reserve. Es gibt zwei Anbieter. Antwortet der erste nach 1,5 Sekunden nicht, startet der zweite parallel.
• Circuit Breaker. Nach drei Transportfehlern in Folge, also Fehlern bei der Übertragung statt beim Urteil, rückt ein Anbieter für 5 Minuten an die zweite Stelle. Das Muster beschreibt Martin Fowler im Artikel „Circuit Breaker“ (2014).
• Das Urteil ist endgültig. Nur Transportfehler führen zum anderen Anbieter. Ein inhaltliches Urteil fragen wir nicht bei einem zweiten Modell nach, sonst hinge das Ergebnis davon ab, welcher Anbieter gerade antwortet.

Am 6. Oktober 2026 brauchte eines unserer Prüfmodelle im Median 0,7 und im 90. Perzentil 1,6 Sekunden. Der Ersatzanbieter traf in 131 von 147 echten Fällen dasselbe Urteil wie der Hauptanbieter, genauso oft wie der Hauptanbieter selbst bei einer Wiederholung.

Fazit

Ein LLM-Fallback ist mehr als ein zweiter API-Schlüssel. Er braucht eine Reserve bei einem anderen Anbieter, eine Zeitgrenze, ein hartes Gesamtbudget und klare Regeln, welche Fehler einen weiteren Versuch verdienen. Weil nach der Zeitgrenze die schnellste Antwort gewinnt, muss jedes Modell im Rennen für sich gut genug sein. Den größten Gewinn bei der Antwortzeit brachte bei uns die Architektur, nicht das Modell. Und Health-Checks mit echten Probeanfragen brauchen selbst eine Überwachung.

Wenn Sie einen KI-Chatbot für Ihre Kunden planen oder einen bestehenden ausfallsicher machen wollen, finden Sie unser Vorgehen unter KI-Chatbot für Website und Kundenservice. Einen Überblick über das Produkt gibt das Praxisbeispiel Videochat-Conversational-AI. Die Anbindung von Sprachmodellen an Ihre eigenen Systeme übernehmen wir in der KI-Entwicklung. Für eine erste Einschätzung Ihres Vorhabens nehmen Sie Kontakt auf.