LLM-Fallback-Muster: KI-Features am Leben halten, wenn der Modellanbieter ausfällt

Ein Logistikkunde rief uns an einem Dienstagnachmittag an, weil sein KI-gestützter Sendungsklassifizierer aufgehört hatte zu antworten. An seinem Code hatte sich nichts geändert. Sein Modellanbieter hatte einen regionalen Vorfall, Anfragen liefen nach dreißig Sekunden in einen Timeout, und das Feature, das eingehende Bestellungen sortierte, war schlicht dunkel geworden. Support-Tickets stapelten sich, während ein Entwickler eine Statusseite aktualisierte. Die Lösung war kein besseres Modell und kein größeres Budget. Es war ein Satz von LLM-Fallback-Mustern, mit denen das Feature vom ersten Tag an hätte ausgeliefert werden sollen, damit ein Anbieter mit einem schlechten Nachmittag zu einer langsameren Erfahrung wird statt zu einer toten.

Das ist die unbequeme Wahrheit beim Bauen auf großen Sprachmodellen: Du bist eine harte Abhängigkeit von einem externen System eingegangen, das irgendwann Fehler zurückgibt, dich drosselt oder so langsam antwortet, dass die Antwort nutzlos ist. Das als Randfall zu behandeln, ist der Weg, an dessen Ende du einen Ausfall erklärst, den du nicht verursacht hast. Es von Anfang an als Design-Constraint zu behandeln, ist der Weg, KI-Features zu bauen, die nutzbar bleiben, wenn das, worauf sie stehen, wackelt.

Warum LLM-Fallback-Muster nicht optional sind

Traditionelle APIs scheitern auf Arten, die die meisten Teams bereits handhaben. Ein Zahlungsgateway läuft in einen Timeout, du wiederholst, du zeigst einen freundlichen Fehler. LLM-Anbieter fügen Fehlermodi hinzu, die leicht unterschätzt werden. Rate-Limits kommen in Schüben, wenn dein Traffic Spitzen hat, was genau der Moment ist, in dem du am wenigsten Anfragen verwerfen willst. Latenz ist per Design variabel, sodass ein Aufruf, der normalerweise in zwei Sekunden zurückkehrt, unter Last zwanzig dauern kann. Kontextfenster und Token-Limits weisen Anfragen ab, die gestern noch funktionierten, weil die heutige Eingabe länger ist. Und ganze Regionen oder Modellversionen können mit wenig Vorwarnung abgekündigt oder offline genommen werden.

Auch der Wirkungsradius ist anders. Wenn ein KI-Feature zentral für einen Workflow ist, ist sein Ausfall nicht kosmetisch. Der Sendungsklassifizierer oben war keine nette Zusammenfassungsbox in einer Ecke des Bildschirms. Er saß im kritischen Pfad der Auftragsannahme, sodass sein Ausfall zu einem operativen Ausfall wurde. Je zentraler das Feature, desto mehr muss seine Zuverlässigkeit bewusst konstruiert statt angenommen werden. Diese Ingenieursarbeit trennt eine Demo von einem Produktionssystem, und es ist dieselbe Disziplin, die wir in jedes Custom-Software-Development-Projekt einbringen, bei dem eine externe Abhängigkeit im kritischen Pfad sitzt.

Die Fallback-Kette: primär, sekundär, degradiert

Das Kernmuster ist eine Kette von Optionen, geordnet vom besten zum akzeptablen. Dein Code versucht die erste und wechselt bei einem Fehler zur nächsten, bis er eine Option erreicht, die immer funktioniert, weil sie überhaupt nicht vom Anbieter abhängt.

Eine typische Kette hat drei Stufen. Die primäre ist dein bevorzugtes Modell, gewählt wegen der Qualität. Die sekundäre ist ein anderes Modell, idealerweise von einem anderen Anbieter, damit ein einzelner Vorfall bei einem Anbieter nicht beide Glieder ausschaltet. Die letzte Stufe ist ein Nicht-KI-Fallback: eine gecachte vorherige Antwort, ein einfacheres regelbasiertes Ergebnis oder eine ehrliche Nachricht, die die Kontrolle an den Nutzer zurückgibt. Der Sinn der letzten Stufe ist, dass sie keine externe Abhängigkeit hat, sodass die Kette immer in etwas enden kann, mit dem der Nutzer etwas anfangen kann.

Anbieter-Diversität macht die mittlere Stufe erst wertvoll. Wenn dein primäres und sekundäres Modell beide vom selben Anbieter gehostet werden, nimmt ein regionaler Ausfall beide zusammen mit, und deine Kette kollabiert sofort auf die degradierte Stufe. Die sekundäre über einen unabhängigen Anbieter zu routen, selbst einen mit etwas schwächerem Modell, bedeutet, dass die meisten Vorfälle für Nutzer unsichtbar sind, weil die sekundäre sie leise abfängt. Welche Anbieter man paart und wie man Prompts über sie hinweg portabel hält, ist eine Tech-Stack-Strategie-Entscheidung, die es sich lohnt zu treffen, bevor du mitten in einem Vorfall steckst.

Eine Warnung: Prompts sind nicht perfekt portabel. Ein auf die Eigenheiten eines Modells getunter Prompt kann bei einem anderen schwächere Ausgaben produzieren. Halte eine anbieterneutrale Version jedes Prompts bereit und teste sie gegen jedes Modell in der Kette, damit die sekundäre tatsächlich nutzbare Ergebnisse liefert statt selbstbewusst falscher. Validiere die Struktur dessen, was zurückkommt, auf jeder Stufe, denn ein Fallback, der fehlerhaftes JSON zurückgibt, ist kein echter Fallback.

Retry-Logik, die hilft statt schadet

Wiederholen ist der erste Instinkt, wenn ein Aufruf scheitert, und schlecht gemacht verschlimmert es Ausfälle. Sofortige Retries gegen einen bereits überlasteten Anbieter fügen einem strauchelnden System Last hinzu und können den Vorfall verlängern. Die Disziplin, die das verhindert, ist exponentielles Backoff mit Jitter: Warte ein kurzes Intervall vor dem ersten Retry, verdopple es bei jedem weiteren Versuch und füge einen kleinen zufälligen Versatz hinzu, damit nicht Tausende Clients im Gleichschritt wiederholen und eine synchronisierte Thundering Herd erzeugen.

Genauso wichtig ist zu wissen, was man nicht wiederholt. Eine Rate-Limit-Antwort oder ein vorübergehender Timeout ist es wert, wiederholt zu werden, weil der nächste Versuch durchaus gelingen kann. Ein Fehler wegen fehlerhafter Anfrage oder eine Authentifizierungs-Störung ist es nicht, weil dieselbe Eingabe jedes Mal gleich scheitert, und Wiederholen verschwendet nur die Zeit des Nutzers und dein Budget. Lies den Fehler, klassifiziere ihn als vorübergehend oder dauerhaft und schleife nur über die vorübergehende Klasse. Begrenze die Anzahl der Versuche und die Gesamtzeit, die du bereit bist aufzuwenden, denn eine Retry-Schleife, die länger läuft, als der Nutzer wartet, ist gescheitert, selbst wenn sie am Ende erfolgreich ist.

Ein Circuit Breaker sitzt über all dem. Wenn ein Anbieter in einem kurzen Zeitfenster wiederholt versagt hat, hör auf, ihm Traffic zu schicken, für eine Abkühlphase, und route direkt auf die nächste Stufe der Kette. Das schützt beide Seiten. Es hindert dich daran, auf einen ausgefallenen Anbieter einzuhämmern, und es hindert deine Nutzer daran, bei jeder Anfrage eine zum Scheitern verurteilte Retry-Sequenz zu durchwarten. Nach der Abkühlung lass eine kleine Zahl von Testanfragen durch, um zu prüfen, ob sich der Anbieter erholt hat, bevor du die Schleusen wieder öffnest.

Graceful Degradation ist eine Produktentscheidung

Der wichtigste Teil von Resilienz ist zu entscheiden, vor einem Vorfall, was "funktioniert noch" für jedes Feature bedeutet, wenn die KI-Schicht nicht verfügbar ist. Das ist ebenso eine Produkt- wie eine Ingenieursfrage, und sie verdient eine echte Antwort statt einer generischen Fehlerseite.

Graceful Degradation nimmt meist eine von wenigen Formen an. Ein gecachtes oder aktuelles Ergebnis kann einspringen, wenn Aktualität nicht kritisch ist, sodass ein Nutzer die gestrige Zusammenfassung sieht statt nichts. Ein einfacherer deterministischer Pfad kann das Modell komplett ersetzen, etwa Stichwortregeln, wo ein LLM normalerweise klassifiziert, und nimmt geringere Genauigkeit in Kauf im Tausch gegen garantierte Verfügbarkeit. Oder das Feature kann sauber beiseitetreten und den Nutzer die Aufgabe manuell erledigen lassen, was weit besser ist als ein Spinner, der sich nie auflöst. Der Klassifizierer-Kunde landete bei einer manuellen Queue: Wenn das Modell nicht verfügbar ist, fallen neue Bestellungen in eine Liste, die ein Mensch sortieren kann, und das System sagt dem Operator genau das. Der Durchsatz sinkt, aber das Geschäft läuft weiter.

Welche Form du auch wählst, sei ehrlich in der Oberfläche. Eine kurze, spezifische Nachricht, dass die KI-Unterstützung vorübergehend nicht verfügbar ist, gepaart mit einem funktionierenden manuellen Pfad, bewahrt Vertrauen. Stille Fehler und endlose Spinner zerstören es. Die Teams, die das gut handhaben, entscheiden die degradierte Erfahrung bewusst und entwerfen dafür, so wie sie jeden anderen Webanwendungs-Zustand entwerfen würden, statt ihn live während eines Ausfalls zu entdecken.

Mach Fehler beobachtbar, bevor sie passieren

Du kannst keine Fehler managen, die du nicht sehen kannst. Instrumentiere jeden Aufruf an den Anbieter mit seinem Ausgang, der Latenz, welcher Stufe der Kette die Antwort bediente und den beteiligten Token-Zahlen. Das verwandelt ein vages Gefühl, dass "die KI sich heute langsam anfühlt", in ein konkretes Signal, auf das du alarmieren kannst. Wenn Fallbacks häufiger als üblich zu feuern beginnen, ist das deine Frühwarnung, dass ein Anbieter degradiert, oft bevor die eigene Statusseite es zugibt.

Setze Schwellenwerte, die bei erhöhten Fehlerraten, steigender Latenz und ungewöhnlicher Fallback-Häufigkeit Alarme auslösen, und logge genug Kontext, um im Nachhinein zu rekonstruieren, was passiert ist. Ein kurzes Runbook, das benennt, wer reagiert, wie man Traffic auf den sekundären Anbieter zwingt und wie man die Erholung verifiziert, verwandelt ein hektisches Gewusel in eine Prozedur. Diese Observability und die Resilienzmuster darunter aufzubauen, ist genau die Art Arbeit, die ein Code-Quality-Consulting-Engagement zutage fördert, denn die Lücken sind selten im Happy Path und fast immer in der Fehlerbehandlung, die niemand unter echtem Ausfall getestet hat.

Wo anfangen

Wenn dein KI-Feature heute keinen Fallback hat, musst du nicht alles auf einmal bauen. Fang mit dem einzelnen wirkungsstärksten Schritt an: Füge eine Nicht-KI-degradierte Stufe hinzu, damit das Feature nie vollständig sterben kann, selbst wenn diese Stufe nur eine klare Nachricht und ein manueller Pfad ist. Dann füge Retry-Logik mit Backoff für vorübergehende Fehler hinzu, denn allein das fängt einen überraschenden Anteil realer Aussetzer ab. Füge einen zweiten Anbieter hinzu, sobald das Feature wichtig genug ist, um die Kosten für portable Prompts zu rechtfertigen. Ergänze Circuit Breaking und Observability, während der Traffic wächst. Jeder Schritt ist eigenständig wertvoll, und die Reihenfolge schützt dich zuerst vor dem schlimmsten Ausgang.

Das Ziel ist kein perfektes System, das nie einen Anbieter scheitern sieht. Anbieter werden scheitern, und das liegt außerhalb deiner Kontrolle. Das Ziel ist, dass deine Nutzer, wenn sie es tun, eine langsamere oder einfachere Version des Features erleben statt eines Ausfalls, und dein Team einen ruhigen Alarm bekommt statt einer Support-Flut.

Wenn du KI-Features in ein Produkt einbaust und ein zweites Paar Augen auf das Resilienz-Design möchtest, oder wenn du bereits den oben beschriebenen Nachmittag durchlebst, helfen wir gern. Melde dich unter hello@wolf-tech.io oder lies mehr darüber, wie wir arbeiten, auf wolf-tech.io.