Bei einem Ausfall den Modellanbieter wechseln, ohne die Zusagen des Produkts zu ändern

Failover ändert mehr als den Endpunkt

Ein zweites Modell unterscheidet sich vom ersten nicht nur durch die URL. Befolgen von Anweisungen, Format von Tool-Aufrufen, Zuverlässigkeit strukturierter Ausgaben, Ablehnungen, Kontextgrenzen, Tokenisierung und damit Kosten und Latenz können sich ändern. Das Ausweichmodell läuft womöglich unter einem anderen Anbietervertrag, in einer anderen Region und mit anderer Aufbewahrung. Geht es über ein anderes Gateway oder einen anderen API-Schlüssel, hat es vielleicht sogar andere Berechtigungen. Jeder dieser Punkte ist eine Zusage des Produkts, die nie jemand aufgeschrieben hat.

Für jede Route einen Ausweichvertrag schreiben

• Qualität: besteht das Evaluierungsset der Funktion mit einer vereinbarten Schwelle und einer eigenen Prompt-Variante
• Ausgabe: Strukturierte Ergebnisse bestehen die Prüfung gegen dieselben Schemas, und nachgelagerter Code lehnt alles andere ab
• Tools und Berechtigungen: dieselbe Tool-Liste und derselbe Umfang der Zugangsdaten, ohne Zusätzliches, das das Framework der Ausweichroute aktiviert
• Datenbedingungen: Anbieter, Region und Aufbewahrung von Ihren Datenverantwortlichen für das freigegeben, was diese Funktion sendet
• Kapazität und Kosten: die Rate Limits der Ausweichroute bei Failover-Volumen und die erwarteten Kosten pro Anfrage
• Hinweis: ob Betrieb oder Nutzer erfahren, dass eine Ausweichroute aktiv ist

Erfüllt keine Route den Vertrag, ist ein Notbetrieb die ehrliche Ausweichlösung: der bisherige Ablauf ohne KI, eine Anfrage in der Warteschlange oder eine klare Meldung.

Was ein Umschalten auslösen sollte

Nicht jeder Fehler rechtfertigt ein Failover. Die API-Referenz von Anthropic unterscheidet zum Beispiel Rate Limiting (429), interne Fehler (500) und vorübergehende Überlastung (529). Ungültige Anfragen und abgelehnte Zugangsdaten deuten meist auf ein Problem auf Ihrer Seite hin, wobei sich unterscheiden kann, was ein Anbieter ablehnt. Ordnen Sie jeden Fehler ein und legen Sie fest, wie darauf reagiert wird, und schalten Sie nicht automatisch um bei Fehlern, die eine Ausweichroute nicht behebt oder die Sie selbst untersuchen müssen. Das SRE-Buch von Google ergänzt die Regeln für Wiederholungen: wiederholbare von dauerhaften Fehlern trennen, zufälliges exponentielles Backoff nutzen, Wiederholungen pro Anfrage begrenzen und nicht auf mehreren Ebenen wiederholen, denn drei Ebenen mit je drei Wiederholungen machen aus einer Nutzeraktion 64 Versuche. Liegen Fehler oder Latenz beim primären Modell über eine vereinbarte Zeit über einer Schwelle, schalten Sie die ganze Funktion um statt einzelner Anfragen, damit ein Gespräch nicht zwischen Modellen hin und her springt.

Gleichwertiges Verhalten vor dem Ausfall nachweisen

Führen Sie das Evaluierungsset für jede Ausweichroute im selben Rhythmus aus wie für die primäre und nach jeder Änderung an Prompts, Modellen oder Tools. Vergleichen Sie die Art der Fehler, nicht nur die Bestehensquote. Ein Ausweichmodell, das etwas häufiger ablehnt, kann akzeptabel sein; eines, das ein schreibendes Tool mit falschen Argumenten aufruft, nicht. Halten Sie je Modell eine Prompt-Variante in der Versionsverwaltung und testen Sie sie gegen dieselben Tool-Schemas.

Ein hypothetisches Beispiel: Bei einem Set von 300 Fällen für einen Support-Assistenten besteht das primäre Modell 282 Fälle und das Ausweichmodell 270, doch das Ausweichmodell beantwortet 6 der 20 Erstattungsfälle falsch, weil es eine veraltete Richtlinie zitiert. Die Entscheidung: Während des Failovers ist das Erstattungs-Tool abgeschaltet und Erstattungsfragen gehen an eine Person, alles andere bleibt auf dem Ausweichmodell.

Die Ausweichroute üben, bevor man sie braucht

Das SRE-Buch von Google warnt, dass ein im Normalbetrieb selten genutzter Notbetrieb ein Codepfad ist, der oft nicht funktioniert, und rät, ihn gezielt zu üben. Für ein Ausweichmodell heißt das, regelmäßig einen kleinen Teil des Verkehrs oder Schattenverkehr dorthin zu leiten oder geplante Übungen durchzuführen, damit Schlüssel, Kontingente, Prompts und Monitoring nachweislich funktionieren. Schattenläufe müssen schreibende Tools isolieren, durch Attrappen ersetzen oder unterdrücken, damit sie nie eine echte Erstattung, E-Mail oder andere Geschäftsaktion wiederholen, unabhängig davon, was die Datenbedingungen des Anbieters erlauben. Klären Sie vorab, ob die Rate Limits der Ausweichroute das Volumen tragen, das dort ankommen wird.

Zurückschalten und abgekündigte Modelle

Kehren Sie bewusst zurück: wenn das primäre Modell eine vereinbarte Zeit stabil läuft, schrittweise und unter Beobachtung derselben Signale. Halten Sie fest, welche Anfragen über welche Route liefen, damit Qualitätsprüfungen und Kostenberichte stimmen. Geplante Änderungen brauchen dieselbe Disziplin. Die Abkündigungsrichtlinie von Anthropic etwa gibt abgekündigten Modellen ein Datum, nach dem Anfragen scheitern, und weist darauf hin, dass Partnerplattformen eigene Termine setzen. Behandeln Sie eine Abkündigung als geplantes Failover und wenden Sie denselben Vertrag an. Ein praktischer nächster Schritt: Schreiben Sie den Vertrag für eine Funktion und führen Sie ihr Evaluierungsset vor dem nächsten Release gegen die Ausweichroute aus.

KI-Engineering und -Architektur