Ein Fallback klingt nach einer einfachen Zuverlässigkeitsfunktion: Wenn Modell A nicht antwortet, versucht das System Modell B. In Wirklichkeit kann dieser Wechsel Preis, Datenregion, Ausgabeformat, Sicherheitsfilter und Antwortqualität verändern.
Ein Fallback ist deshalb eine neue Route mit eigenen Regeln, nicht nur eine Wiederholung.
Welche Fehler rechtfertigen einen Fallback?
Temporäre Providerfehler, Rate Limits oder regionale Störungen können einen Fallback sinnvoll machen. Inhaltliche Unsicherheit oder eine schlechte Antwort sollten dagegen nicht automatisch einen Providerwechsel auslösen. Sonst wird ein Qualitätsproblem als Verfügbarkeitsproblem behandelt.
Klassifizieren Sie Fehler technisch und fachlich. Ein ungültiges Tool-Schema wird durch ein anderes Modell möglicherweise nicht behoben. Eine fehlende Berechtigung darf nie durch eine alternative Route umgangen werden.
Datenpfad vor Verfügbarkeit
Ein Ausweichprovider muss für die betreffende Datenklasse erlaubt sein. Prüfen Sie Region, Vertragsbedingungen, Logging, Aufbewahrung und Subprozessoren. Wenn kein zulässiger Fallback existiert, muss der Workflow kontrolliert stoppen.
Das gilt auch für lokale Modelle. Eine lokale Route kann sensible Daten schützen, aber nur dann als Fallback dienen, wenn Qualität, Kapazität und Tool-Funktionen vorher getestet wurden.
Kosten sichtbar halten
Ein teureres Ausweichmodell kann während einer Störung grosse Zusatzkosten erzeugen. Setzen Sie Budgets pro Route und alarmieren Sie bei ungewöhnlichem Fallback-Anteil.
Ordnen Sie die Kosten weiterhin dem ursprünglichen Workflow zu. Sonst erscheinen sie nur als Provideranstieg, ohne dass der auslösende Prozess erkennbar ist.
Ausgabe und Tool Calling prüfen
Modelle interpretieren strukturierte Ausgaben und Tools unterschiedlich. Ein Fallback muss denselben Vertrag erfüllen oder eine eigene Adapter- und Testschicht besitzen.
Prüfen Sie mindestens Schemaerfüllung, Tool-Auswahl, Quellenformat, Sicherheitsregeln und Abbruchverhalten. Ein HTTP-200-Resultat bedeutet noch keine funktionale Gleichwertigkeit.
Fallback-Ketten kurz halten
Lange Ketten können Latenz und Kosten vervielfachen. Definieren Sie maximal einen oder zwei erlaubte Alternativen und ein Gesamtzeitlimit. Nach mehreren Providerfehlern ist ein transparenter Abbruch häufig besser als eine weitere unsichere Route.
Vermeiden Sie Zyklen. Das Gateway muss erkennen, wenn Modell A zu B und eine nachgelagerte Komponente wieder zu A zurückfällt.
Regelmässig testen
Ein Fallback, der nie getestet wird, ist keine belastbare Kontrolle. Simulieren Sie Providerfehler und prüfen Sie Datenroute, Kostenalarm, Format, Nutzerhinweis und Wiederanlauf. Dokumentieren Sie, wann auf die Primärroute zurückgeschaltet wird.
Quellen
- Cloudflare AI Gateway, Dynamic Routing: https://developers.cloudflare.com/ai-gateway/features/dynamic-routing/
- LiteLLM, Reliability and Fallbacks: https://docs.litellm.ai/docs/proxy/reliability
- Google SRE Book, Handling Overload: https://sre.google/sre-book/handling-overload/
- OpenTelemetry Semantic Conventions for GenAI: https://opentelemetry.io/docs/specs/semconv/gen-ai/
Nächster Schritt
Listen Sie pro produktiver Route den Primärprovider und jede erlaubte Alternative auf. Ergänzen Sie Datenklasse, Region, Qualitätsgrenze, Mehrkosten und maximale Versuche. Führen Sie danach einen geplanten Ausfalltest durch und prüfen Sie das tatsächlich erzeugte Resultat.