Maximale Verfügbarkeit
Wie Kontinent Anfragen am Laufen hält, wenn ein Anbieter ausfällt, und wie Sie jedes Modell ausfallsicher machen.
Kontinent sagt in den Nutzungsbedingungen (Ziffer 7) mindestens 99 % Verfügbarkeit der Plattform im Kalendermonatsmittel zu. Das gilt für Kontinent selbst, nicht für die einzelnen Anbieter und Modelle dahinter. Ob ein Modell weiter antwortet, wenn sein Anbieter ausfällt, hängt von zwei Mechanismen ab: Standby-Routen, die Kontinent für viele Modelle pflegt, und Routing-Policies, die Sie für jedes Modell anlegen, auf das Sie sich verlassen.
Standby-Routen im Katalog
Viele Modelle im Katalog werden von mehr als einem Anbieter bedient. Für diese hält Kontinent eine primäre Route und eine Standby-Route bei einem anderen Anbieter vor. Bei jeder Anfrage versucht Kontinent zuerst die primäre Route und wechselt zur Standby-Route, wenn die primäre nicht antworten kann.
| Modell | Primär | Standby |
|---|---|---|
mistral/mistral-medium-3.5 | Mistral | Scaleway |
Nicht jedes Modell hat eine Standby-Route. Manche Modelle bietet in der EU nur ein Anbieter an, und dann gibt es nichts, wohin umgeschaltet werden könnte. Die meisten Modelle auf AWS Bedrock, darunter Claude, haben keinen zweiten Anbieter, aber Kontinent schaltet zwischen den Bedrock-Regionen Frankfurt und Irland um.
Der Katalog zeigt die Standby-Route eines Modells heute nicht an. Sie sehen sie im Nachhinein: X-Provider und X-Served-Model in der Antwort nennen die Route, die tatsächlich geantwortet hat (siehe Request- & Response-Header), und die Anfrage-Details in den Logs zeigen, welcher Anbieter ausgefallen ist und welcher bedient hat.
Jedes Modell mit einer Routing-Policy ausfallsicher machen
Darf ein Anwendungsfall nicht stehen bleiben, wenn ein Anbieter ausfällt, verlassen Sie sich nicht auf den Katalog. Legen Sie eine Routing-Policy mit eigenen Ausweichmodellen an, am besten bei verschiedenen Anbietern, und senden Sie policy/<slug> als Modell:
- Das funktioniert für jedes Modell, auch für die ohne Standby-Route.
- Sie bestimmen die Reihenfolge und wie oft jedes Modell versucht wird.
- Eine Änderung der Kette in der Konsole wirkt innerhalb von Sekunden, ohne Deployment.
Das ist der verlässliche Weg zu einem Failover für ein Modell, auf das Sie angewiesen sind.
Wann wird umgeschaltet?
Liefert ein Anbieter 429 oder einen 5xx-Fehler, lehnt er die Zugangsdaten von Kontinent mit 401/403 ab oder ist er nicht erreichbar, versucht Kontinent die nächste Route, transparent, bevor irgendwelche Bytes bei Ihnen ankommen. Das gilt für Standby-Routen und für die Modelle einer Routing-Policy gleichermaßen.
Bei Streaming-Anfragen wird vor dem ersten Byte umgeschaltet. Ist das erste Token draußen, zeigt sich ein Fehler beim Anbieter als abschließender Fehler mitten im Stream. Gehen Sie also mit einem abgebrochenen Stream sauber um. Siehe Streaming.
Ist keine Route mehr übrig, schlägt die Anfrage mit dem Fehler des letzten Versuchs fehl: meist 502 upstream_error oder 503 no_provider_available, auch 429 upstream_rate_limited oder 502 upstream_auth_error. Siehe Fehler behandeln.
Was Sie nicht selbst bauen müssen
Kein Failover-Code
Das Umschalten auf die nächste Route liegt im Gateway, nicht in Ihrer App. Es passiert sofort, ohne Wartezeit zwischen den Versuchen.
Kein Anbieter-Jonglieren
Eine ID wird zu der Route aufgelöst, die gerade gesund ist.
Rate-Limiting ist fail-open: Hat der Speicher unseres Limiters Probleme, werden Ihre Anfragen dadurch nie blockiert. Ein separates 429 upstream_rate_limited bedeutet, dass ein Anbieter uns gedrosselt hat. Versuchen Sie es mit Backoff erneut. Siehe Rate-Limits & Guthaben.