Glossareintrag
Wir denken. KI tippt mit.
Failover bei KI (englisch Failover oder Model Fallback, deutsch auch Ausweichmodell oder Fallback-Modell) ist der automatische Wechsel auf ein Ersatzmodell, sobald das genutzte KI-Modell nicht antwortet. Die Anfrage geht dann an ein anderes Modell desselben Anbieters, an einen zweiten Anbieter, in eine andere Cloud-Region oder an ein Modell auf eigener Hardware. Der Begriff stammt aus der Server-Technik. Das US-Normungsinstitut NIST beschreibt Failover als automatisches Umschalten auf ein redundantes oder Standby-System, sobald das aktive System ausfällt (NIST-Glossar zu Failover). Bei Sprachmodellen ist das ausfallende System ein Modell oder die API eines Anbieters.
Die Multi-Provider-Strategie (auch Multi-Model-Strategie) ist der organisatorische Rahmen dazu. Ein Betrieb hält Verträge, Zugänge und geprüfte Prompts bei mindestens zwei Anbietern bereit, damit der Wechsel im Ernstfall technisch und rechtlich möglich ist. Im Alltag vermischen sich die Begriffe. Retry wiederholt dieselbe Anfrage beim selben Modell nach kurzer Wartezeit. Fallback schickt eine einzelne gescheiterte Anfrage an ein Ersatzmodell. Failover leitet den gesamten Verkehr um, bis der Hauptanbieter wieder läuft, und schaltet danach zurück (Failback). In der Praxis der KI-Anbieter laufen die Wörter Fallback und Failover ineinander. Die Gateway-Software LiteLLM nennt ihre Fallback-Funktion ausdrücklich ihren Weg zum automatischen Failover (LiteLLM-Doku zu Fallbacks und Retries).
Fehlermeldungen der Schnittstelle lösen ein Failover aus. Die wichtigsten Codes ähneln sich bei allen großen Anbietern. 429 meldet ein überschrittenes Nutzungslimit, 500 einen internen Fehler, 503 bei OpenAI oder 529 bei Anthropic eine Überlastung des Modells. Hinzu kommen Zeitüberschreitungen (Timeout) ohne jede Antwort. Anthropic und OpenAI dokumentieren diese Codes und empfehlen, mit wachsendem Abstand erneut zu senden (Exponential Backoff). Sie liefern die Wartezeit im Header Retry-After mit (Fehlercodes der Claude-API, Fehlercodes der OpenAI-API). Die offiziellen Anthropic-SDKs wiederholen vorübergehende Fehler von sich aus zweimal. Bei kurzen Aussetzern hilft ein Retry. Beim ChatGPT-Ausfall vom 10. Juni 2025 erreichte die Fehlerquote laut OpenAI in der Spitze rund 35 Prozent. Die stärkste Phase dauerte sechs Stunden (Vorfallsbericht von OpenAI). Für solche Stunden benötigt die Anwendung eine Failover-Regel, die festlegt, wohin die Anfrage stattdessen geht.
Nicht nur Störungen lösen den Wechsel aus. Am 12. Juni 2026 schaltete Anthropic die Modelle Fable 5 und Mythos 5 für alle Kunden ab. Eine Exportkontroll-Anordnung der US-Regierung untersagte den Zugang für alle Nicht-US-Staatsangehörigen innerhalb und außerhalb der USA, und Anthropic sah in der vollständigen Abschaltung den einzigen Weg, die Vorgabe einzuhalten (Stellungnahme von Anthropic zur Abschaltung). Fable 5 kam erst am 1. Juli zurück, Mythos 5 nur für ausgewählte US-Organisationen (Mitteilung zur Wiederfreigabe von Fable 5). Wer seine Abläufe fest auf dieses Modell eingestellt hatte, musste 19 Tage lang ohne es auskommen. Ebenso wirken Abkündigungen älterer Modellversionen (Deprecation), Überschreitungen des Kontextfensters und Ablehnungen durch Sicherheitsfilter. Für den letzten Fall bietet Anthropic seit Juli 2026 einen serverseitigen Fallback-Parameter im Beta-Stadium an, der eine abgelehnte Anfrage automatisch an bis zu drei Ersatzmodelle weiterreicht. Bei Nutzungslimits, Überlastung oder Serverfehlern gilt dieser Parameter ausdrücklich nicht (Anthropic-Doku zu Refusals and Fallback).
Ein Failover-Plan läuft in Stufen:
Ein LLM-Gateway (auch AI Gateway) sitzt als Zwischenschicht zwischen Anwendung und Modellanbietern und übernimmt meist den Anbieterwechsel. Die Anwendung spricht nur mit dem Gateway. Das Gateway hält die Zugangsdaten aller Anbieter und kennt die Reihenfolge der Ersatzmodelle. OpenRouter nimmt dafür eine Modell-Liste entgegen und probiert die Einträge bei Ausfall, Nutzungslimit, Kontextlängen-Fehler oder Moderationssperre der Reihe nach durch. Der Preis richtet sich nach dem Modell, das am Ende geantwortet hat (OpenRouter-Doku zu Model Fallbacks). Die Open-Source-Software LiteLLM sperrt ein Modell nach drei Fehlern pro Minute für fünf Sekunden und leitet in dieser Zeit an die nächste Modellgruppe (LiteLLM-Doku zum Routing). Portkey (inzwischen PRISMA AIRS AI Gateway), Cloudflare AI Gateway, Vercel AI Gateway und Kong bieten dasselbe Muster mit eigenen Regeln für Fehlercodes, Limits und Zeitüberschreitungen (Portkey-Doku zu Fallbacks, Cloudflare-Doku zu Dynamic Routing). Microsoft hat die Funktion direkt in die Cloud eingebaut. Der Modellrouter in Microsoft Foundry leitet eine Anfrage bei Problemen mit einem Modell an das nächstbeste weiter, das Failover ist dort standardmäßig aktiv (Microsoft-Doku zum Modellrouter).
Damit Gateways einen gestörten Anbieter nicht bei jeder Anfrage erneut belasten, nutzen sie einen Circuit Breaker (Sicherungsautomat). Michael Nygard machte das Muster mit seinem Buch „Release It!“ bekannt, Martin Fowler beschreibt es in einem Beitrag von 2014 (Martin Fowler zum Circuit-Breaker-Muster). Nach einer festgelegten Zahl von Fehlern öffnet sich die Sicherung und alle weiteren Aufrufe scheitern sofort. Erst nach einer Wartezeit testet das System den Anbieter vorsichtig wieder an. Bei der Agentforce-Plattform von Salesforce schaltet der Circuit Breaker komplett auf das Ersatzmodell um, sobald die Fehlerquote eines Anbieters 60 Sekunden lang über 40 Prozent liegt. Nach 20 Minuten setzt sich die Sicherung zurück (Salesforce zum Failover-Design bei Agentforce). Ohne Sicherung droht ein Retry-Sturm. Im Benchmark ContinuityBench vom Juli 2026 erzeugten starre Wiederholungsintervalle gegen einen limitierten Ersatzanbieter einen sich selbst erhaltenden Anfrage-Sturm, der den Ersatz dauerhaft sperrte (ContinuityBench-Paper auf arXiv).
Ein solcher Plan schützt nur vor Ausfällen, die den Ersatzanbieter nicht gleichzeitig treffen (korrelierte Ausfälle). Am 3. September 2026 waren ChatGPT, Claude und Grok innerhalb weniger Stunden gestört, dazu kurzzeitig die Gemini-API, ohne dass ein gemeinsamer Cloud-Ausfall gefunden wurde. Mark Tauschek von Info-Tech Research Group zog daraus die Regel, dass eine Multi-Model-Strategie nur belastbar ist, wenn ihre Alternativen unabhängig voneinander ausfallen. Modellanbieter nutzten zwar verschiedene Rechenzentren, hingen aber an denselben Clouds, DNS-Diensten, CDNs, Identitätsanbietern und Software-Bibliotheken (Info-Tech-Analyse zu den überlappenden KI-Ausfällen). Wer Azure OpenAI als Reserve für die OpenAI-API einplant, hat keine zweite Quelle. Beide liefern dasselbe Modell derselben Firma. Ein Fehler im Modell trifft beide. Auch die Hyperscaler fallen aus. Beim AWS-Ausfall in der Region us-east-1 am 20. Oktober 2025 legte ein DNS-Fehler im Datenbankdienst DynamoDB rund 14 Stunden lang zahlreiche Dienste lahm (AWS-Bericht zum Ausfall in us-east-1). Beim Cloudflare-Ausfall vom 18. November 2025 riss eine fehlerhafte Konfigurationsdatei unter anderem ChatGPT mit (CNBC zum Cloudflare-Ausfall). OpenAI selbst schrieb nach dem Weihnachtsausfall 2024, ausgelöst durch einen Stromausfall in einem Cloud-Rechenzentrum, ein regionsweites Failover erfordere derzeit manuelles Eingreifen des Cloud-Anbieters (Vorfallsseite von OpenAI zum 26. Dezember 2024).
Weitere Punkte für jeden Plan:
Andreessen Horowitz befragte im Januar 2026 hundert Führungskräfte aus Großunternehmen. 81 Prozent nutzten drei oder mehr Modellfamilien in Test oder Produktion, ein Jahr zuvor 68 Prozent (a16z-Umfrage zum KI-Einkauf in Unternehmen). Zapier befragte zwischen Ende Januar und Anfang Februar 2026 542 US-Führungskräfte mit bezahlten KI-Verträgen. 44 Prozent nutzen mehrere KI-Anbieter parallel, um das Ausfallrisiko zu streuen. 42 Prozent haben einen Notfallplan. Gut jeder vierte Befragte sieht sich vollständig von seinen KI-Diensten abhängig (Zapier-Umfrage zur Abhängigkeit von KI-Anbietern). Für Deutschland gibt es keine KI-spezifische Zahl. Der Bitkom Cloud Report 2026 fragte nach Cloud-Diensten allgemein. Bei einem längeren Cloud-Ausfall müssten 46 Prozent der Unternehmen ab 20 Beschäftigten den Geschäftsbetrieb einstellen (Bitkom-Presseinformation zum Cloud Report 2026). Eine Verfügbarkeitszusage (SLA) begrenzt das Risiko nur rechnerisch. OpenAI sichert im Scale Tier 99,9 Prozent Verfügbarkeit zu (OpenAI Scale Tier), das entspricht fast neun Stunden erlaubtem Ausfall im Jahr.
Für einen Handwerksbetrieb beginnt Failover mit dem zweiten Zugang. Wer Angebote, Kundenmails und Social-Media-Texte mit ChatGPT schreibt, legt sich einen Zugang bei Claude oder Gemini an. Die bewährten Prompts und Textvorlagen liegen außerhalb des Chatverlaufs, z. B. in einer Notiz-App. Fällt ein Dienst aus, wandert die Vorlage per Kopieren in den anderen. Ein Chat-Client mit Modellwahl erspart den Wechsel. Perplexity Pro, TypingMind, Notion oder das selbst gehostete Open WebUI schalten per Klick zwischen den Modellen mehrerer Anbieter um (Perplexity-Hilfe zu den enthaltenen Modellen, Notion-Hilfe zur Modellwahl im Agenten). Die Gemini-App bietet nur Google-Modelle. Einen anderen Anbieter kann man dort nicht wählen.
Bei KI-Telefonassistenten ist der Failover oft schon eingebaut. ElevenLabs Agents schaltet bei Fehlern automatisch durch eine feste Reihe von Ersatzmodellen (ElevenLabs-Doku zum LLM Cascading). Retell AI leitet bei einem OpenAI-Ausfall selbstständig auf ein Backup-Modell um (Retell AI zum Umgang mit Ausfällen). Für deutsche Anbieter wie fonio.ai oder VITAS ist kein Ersatzmodell dokumentiert. Dort sichert die Telefonanlage ab. Wer die KI per bedingter Rufumleitung statt per absoluter Umleitung anbindet, bekommt den Anruf bei Nichtannahme wieder auf das normale Telefon oder den Anrufbeantworter. Dazu gehört bei jedem Assistenten eine Weiterleitung an einen Menschen, die auch funktioniert, wenn das Sprachmodell nicht antwortet.
n8n bringt im KI-Agenten-Baustein die Option „Enable Fallback Model“ mit, an die man ein zweites Modell eines anderen Anbieters hängt (n8n-Issue zum Fallback-Modell im AI-Agent-Node). Make.com hat kein Ersatzmodell. Dort baut man den Ausweichpfad selbst mit einem Error-Handler, der nach einem gescheiterten OpenAI-Modul ein Anthropic- oder Gemini-Modul aufruft, oder lässt das Bundle per „Retry“ später erneut laufen (Make-Hilfe zu Error-Handlern). Zapier bestätigt in seiner Community, dass ein natives Fallback fehlt, und verweist auf den eigenen Error-Handler und „Autoreplay“, das gescheiterte Schritte bis zu fünfmal wiederholt (Zapier-Community zum fehlenden Fallback, Zapier-Hilfe zu Autoreplay). Requesty liefert den Anbieterwechsel fertig, ohne eine Zeile Code. Dort legt man eine „Fallback Policy“ per Klick an und verwendet ihren Namen als Modellnamen in der Automatisierung (Requesty-Doku zu Fallback Policies). In jeder Plattform gehört ein Fehler-Workflow dazu, der bei Ausfall eine E-Mail an den Chef schickt, statt Bestellungen still zu verlieren.
Als letzte Stufe reicht für Texte ein lokales Modell. LM Studio empfiehlt 16 GB Arbeitsspeicher (Systemanforderungen von LM Studio). Damit laufen Modelle wie Gemma 3 mit 4 Milliarden Parametern (Gemma 3 in der Ollama-Bibliothek) oder gpt-oss mit 20 Milliarden (gpt-oss in der Ollama-Bibliothek) auf einem Büro-PC ohne Internet. Für Telefon-KI oder Recherche reicht das nicht, für Entwürfe und Zusammenfassungen schon. Die Statusseiten von Anthropic, OpenAI und Google lassen sich per RSS abonnieren, bei Anthropic auch per E-Mail. So weiß der Betrieb, ob der Fehler beim Anbieter liegt (Statusseite von Anthropic, Statusseite von OpenAI, Status-Dashboard von Google Workspace). Der Betrieb benötigt außerdem eine Liste der Abläufe, die innerhalb von zwei Stunden ohne KI weiterlaufen müssen, z. B. Angebote von Hand aus der Word-Vorlage. Eine KI-spezifische Empfehlung zur Ausfallvorsorge gibt es von BSI, Bitkom oder Handwerkskammern bisher nicht. Das BSI bietet allgemeine Leitfäden zum Business Continuity Management für kleine Betriebe (BSI-Leitfaden BCM für KMU).
