Modell-Fallback ist das produktive Muster, den Request zu einem sekundären Modell zu routen, wenn das primäre scheitert, unerwartet verweigert, ein Token-Budget verletzt oder malformierten strukturierten Output zurückgibt, der bei Retry nicht recovert. Es ist die kosten-effektivste Verfügbarkeits-Investition, die ein produktives KI-System macht.
Trigger-Bedingungen.
- Provider-Fehler. 5xx, Rate-Limit, Timeout oder Connection-Failure auf dem primären Endpoint.
- Structured-Output-Failure. Das primäre Modell gab Output zurück, der zweimal Schema-Validierung failt.
- Refusal. Das primäre verweigerte unerwartet auf einen Input, den der Workflow zu handhaben erwartet.
- Budget-Verletzung. Das primäre würde das Per-Request-Token-Budget des Workflows überschreiten.
Wie es verdrahtet wird.
Am Modell-Gateway, nicht im Application-Code. Das Vercel AI Gateway, OpenRouter und die meisten produktiven Gateways shippen Fallback-Rules als Configuration. Definieren Sie die Kaskade dort (z.B. Claude → GPT → Gemini), die Trigger- Bedingungen und das Per-Fallback-Budget. Die Application ruft das Gateway und bleibt unwissend darüber, welches Modell tatsächlich geantwortet hat.
Den Fallback-Pfad separat evaluieren.
Ein Fallback-Pfad, den niemand evaluiert, ist eine Liability. Fügen Sie Fixtures hinzu, die den Fallback erzwingen (mock-failed primaries, schema-brechende primaries), und scoren Sie das Fallback-Modell gegen dieselbe Rubrik. Das Release-Gate failt, wenn die Fallback-Pfad-Qualität past Toleranz droppt.
Häufige Fragen.
- Was ist Modell-Fallback?
- Modell-Fallback ist das produktive Muster, zu einem sekundären Modell zu routen, wenn das primäre scheitert, unerwartet verweigert, ein Budget verletzt oder malformierten strukturierten Output zurückgibt. Es ist am Modell-Gateway als Configuration verdrahtet, nicht im Application-Code. Eine einzelne Provider-Ausfall bringt den Workflow nicht mehr zum Stillstand.
- Was triggert einen Fallback?
- Vier gängige Bedingungen: Provider-Fehler (5xx, Rate-Limit, Timeout), Structured-Output-Failure zweimal bei Retry, unerwartete Verweigerung auf einen In-Scope-Input und Budget-Verletzung, bei der das primäre den Per-Request-Token-Cap überschreiten würde. Das Gateway evaluiert die Bedingungen; die Application bleibt unwissend darüber, welches Modell antwortete.
- Braucht das Fallback-Modell seine eigene Eval?
- Ja. Ein Fallback-Pfad, den niemand evaluiert, ist eine Liability. Fügen Sie Fixtures hinzu, die den Fallback erzwingen, und scoren Sie ihn gegen dieselbe Rubrik. Das Release-Gate failt, wenn die Fallback-Pfad-Qualität regressiert. Die meisten produktiven Teams under-evaluieren den Fallback; die meisten produktiven Incidents involvieren den Fallback-Pfad.
- Wo lebt der Fallback, in der App oder im Gateway?
- Das Gateway. Vercel AI Gateway, OpenRouter und ähnliche shipping-grade Gateways tragen Fallback-Rules als Configuration. Application-Code ruft das Gateway und vertraut darauf, dass der Failover transparent passiert. Fallback-Rules im Application-Code spreaden die Policy über die Codebase; im Gateway sitzen sie an einem Ort und sind auditierbar.
Englische Fassung: Modell-Fallback on the EN edition.