Leitfaden für Multi-Model-Fallbacks zuverlässiger KI-APIs

Wichtigste Erkenntnisse

Wiederholen Sie dieselbe Route nur bei transienten Fehlern wie Timeouts und 429-Antworten.

Wechseln Sie zu einem Modell, das dieselben Anforderungen an Fähigkeiten und Ausgabevertrag erfüllt.

Legen Sie ein maximales Kosten- und Latenzbudget für die gesamte Anfrage fest, nicht für jeden einzelnen Versuch.

Protokollieren Sie für jede Anfrage Provider, Modell, Fehlerklasse, Anzahl der Wiederholungsversuche und die endgültige Route.

Wiederholungsversuche und Fallbacks trennen

Bei einem Wiederholungsversuch wird die Anfrage erneut an dieselbe Route gesendet, weil der Fehler möglicherweise nur vorübergehend ist. Ein Fallback ändert den Provider oder das Modell, weil die ursprüngliche Route nicht verfügbar oder nicht geeignet ist.

Wenn beide Aktionen als eine allgemeine Wiederholungsschleife behandelt werden, lassen sich Vorfälle schwerer diagnostizieren. Außerdem können sich die Kosten vervielfachen, ohne dass sich die Erfolgsrate verbessert.

Wiederholen: Timeout, Verbindungsabbruch, 429 oder temporäre 5xx-Antwort.
Fallback: wiederholter Provider-Fehler, Kapazitätsproblem des Modells oder Richtlinienbeschränkung.
Beenden: ungültige Anfrage, nicht unterstützter Parameter oder fehlgeschlagene Ausgabenvalidierung.

Eine nach Fähigkeiten kompatible Routentabelle erstellen

Fallback-Modelle sollten nach Fähigkeiten und nicht nach Marke gruppiert werden. Eine Anfrage zur Bildverarbeitung kann nicht auf ein reines Textmodell zurückfallen, und ein strikt auf JSON basierender Workflow sollte nicht an ein Modell geroutet werden, das das Schema regelmäßig verletzt.

Erforderliche Eingabe- und Ausgabemodalitäten.
Mindestgröße von Kontext und Ausgabe.
Unterstützung für Tool-Aufrufe und strukturierte Ausgaben.
Maximal akzeptabler Preis und maximale akzeptable Latenz.

Ein anfrageweites Budget anwenden

Das Anfragebudget sollte jeden Wiederholungsversuch und jeden Fallback-Versuch abdecken. Prüfen Sie vor dem Start eines weiteren Versuchs, ob das verbleibende Latenz- und Kostenbudget diesen noch unterstützt.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Die Fallback-Qualität messen, nicht nur die Verfügbarkeit

Eine erfolgreich beantwortete Anfrage kann trotzdem zu einem Produktfehler führen. Erfassen Sie nach einem Fallback-Ereignis die Ausgabenvalidierung, die Rate manueller Benutzerkorrekturen und den Aufgabenabschluss.

Empfohlenes Dashboard: Erfolg der Route, Fallback-Rate, p95-Latenz, geschätzte Kosten, Erfolgsrate der Validierung und Qualitätsscore nach Modell.

Häufig gestellte Fragen

Sollte jede fehlgeschlagene KI-Anfrage ein Fallback-Modell verwenden?

Nein. Ungültige Parameter, nicht unterstützte Eingaben und fehlgeschlagene Sicherheitsprüfungen sollten sofort zum Abbruch führen. Ein Fallback ist sinnvoll, wenn eine andere kompatible Route dieselbe Aufgabe realistisch abschließen kann.

Wie viele Fallback-Versuche sollte eine KI-Anfrage zulassen?

Die meisten interaktiven Workflows sollten die Gesamtzahl auf zwei oder drei Versuche begrenzen. Das richtige Limit hängt vom verbleibenden Latenzbudget, dem Wert der Aufgabe und den geschätzten Kosten ab.