Multi-Provider-Failover und Lastverteilung: Ausfälle von LLM-Anbietern überbrücken

Jeder Modell-Provider hat schlechte Tage – regionale Ausfälle, Rate-Limit-Probleme unter Last oder Latenzen, die schleichend zunehmen, ohne komplett auszufallen. Wenn Ihre Anwendung einen Provider direkt aufruft, wird dessen schlechtester Tag zu Ihrem schlechtesten Tag. Dieser Beitrag beschreibt die Zuverlässigkeitsebene, die genau das verhindert: eine Taxonomie von LLM-Fehlern, Retries, die die Situation nicht verschlimmern, Fallback-Ketten über verschiedene Provider hinweg, zustandsbewusstes Load Balancing, Circuit Breaker für schnelles Fail-Fast und die komplexe Herausforderung des Failovers bei laufenden Streams.

02:14 Uhr bei Northwind. Nadia, eine SRE, wurde durch einen Alarm geweckt: Der kundenorientierte Support-Agent lieferte für alle Nutzer Fehlermeldungen. Nicht nur für einige – für alle. Die eigenen Dienste von Northwind waren stabil; CPU, Arbeitsspeicher und Warteschlangen liefen im Normalbereich. Die Fehler waren identisch: 503-Meldungen vom Modell-Provider. Ein regionaler Vorfall beim Provider hatte dessen Inference-Endpunkt lahmgelegt, und der Agent von Northwind rief diesen Endpunkt direkt auf. Jede Anfrage traf auf den toten Endpunkt, schlug fehl und gab einen Fehler an den Kunden zurück. Vierzig Minuten lang, bis der Provider den Dienst wiederhergestellt hatte, blieb nur das Warten – der Agent hatte genau einen Weg, eine Antwort zu erhalten, und dieser war blockiert.

Das Fazit der Post-Mortem-Analyse lautete nicht: „Wähle einen zuverlässigeren Provider.“ Jeder Provider hat Vorfälle. Es lautete: „Verlasse dich niemals auf einen einzigen Provider für eine Anfrage, die erfolgreich sein muss.“ Das ist ein Gateway-Problem, und dieser Beitrag zeigt die Lösung: Retries, die die Situation nicht verschlimmern, Fallback-Ketten über Provider hinweg, zustandsbewusstes Load Balancing und Circuit Breaker, die schnell abbrechen, anstatt das gesamte System mit dem Provider in den Abgrund zu ziehen.

Was das AI Gateway von TrueFoundry hier bietet

Alles, was in diesem Beitrag beschrieben wird – Retries, Fallback-Ketten, zustandsbewusstes Load Balancing – ist etwas, das das AI Gateway von TrueFoundry über Konfiguration statt über dienstspezifischen Code steuert. Die Routing-Konfiguration definiert Load-Balancing-, Fallback- und Retry-Regeln in YAML, wertet diese der Reihe nach aus, sodass die erste passende Regel greift, und wendet sie zentral auf jede Anfrage an, anstatt sie in jeder Anwendung neu implementieren zu müssen.

Die Komponenten lassen sich der unten aufgeführten Fehlertaxonomie zuordnen. Jedes Ziel verfügt über eine eigene retry_config – Anzahl der Versuche, Verzögerung und die Statuscodes, bei denen ein erneuter Versuch sinnvoll ist (standardmäßig 429/500/502/503) – sowie eine separate fallback_status_codes Liste, die die Anfrage an das nächste Ziel weiterleitet, wenn Retries nicht mehr helfen. Prioritätsbasiertes Routing ermöglicht eine geordnete Failover-Kette; latenzbasiertes Routing bevorzugt das gesunde Ziel mit der geringsten Latenz; ein fehlerhaftes Ziel wird anhand seiner Anfragen, Token und Fehler pro Minute erkannt und für eine Abkühlphase beiseitegeschoben. Die Dokumentation behandelt sogar den schwierigen Streaming-Fall aus Abschnitt 8 – anbieterspezifische Handhabung von Stream-Überlastungen, sodass ein Fallback erfolgen kann, bevor für den Benutzer sichtbare Token ausgegeben werden.

‍