Drei Anbieter, ein Zeitfenster: Was Ausfallsicherheit im KI-Stack wirklich kostet

Ein Vorfall, der die falsche Frage populär macht

Am Donnerstagvormittag östlicher Zeit lief bei Downdetector innerhalb einer halben Stunde eine Meldungswelle auf: über 35.000 Störungsmeldungen für ChatGPT, rund 1.400 für Claude, etwa 1.200 für Grok. Drei Produkte von drei Wettbewerbern, im selben Zeitfenster nicht erreichbar. Microsoft Azure, das für alle drei Modellfamilien Dienste bereitstellt, meldete zeitgleich eigene Probleme. Einen bestätigten Zusammenhang gibt es bis heute nicht.

Die Reaktion, die man seither in Produktrunden hört, ist reflexhaft und verständlich: Wir brauchen einen zweiten Anbieter. Diese Reaktion ist in den meisten Fällen falsch — nicht weil Ausfallsicherheit unwichtig wäre, sondern weil ein zweiter Anbieter das Problem, das sich am Donnerstag gezeigt hat, nur teilweise löst und dabei erhebliche Kosten an Stellen erzeugt, die in der Entscheidung selten auftauchen.

Es lohnt sich, die Rechnung einmal ordentlich aufzumachen. Sie ist nicht kompliziert, aber sie fällt anders aus, als der Reflex nahelegt.

Warum sich Verfügbarkeiten nicht einfach multiplizieren

Der intuitive Gedanke hinter dem zweiten Anbieter ist eine Multiplikation. Wenn Anbieter A zu 99,9 Prozent verfügbar ist und Anbieter B ebenfalls, dann ist die Wahrscheinlichkeit, dass beide gleichzeitig ausfallen, das Produkt der beiden Ausfallwahrscheinlichkeiten — also 0,1 Prozent mal 0,1 Prozent, ein Millionstel. Aus knapp neun Stunden Ausfall im Jahr würden gut dreißig Sekunden. Das klingt nach dem besten Geschäft der IT-Welt.

Diese Multiplikation gilt allerdings nur unter einer Bedingung, und sie steht selten dabei: Die beiden Ausfälle müssen stochastisch unabhängig sein. Unabhängig heißt, dass der Ausfall des einen nichts über die Wahrscheinlichkeit des anderen aussagt. Genau diese Annahme hat der Donnerstag beschädigt. Wenn zwei Anbieter auf derselben Cloud-Infrastruktur, in derselben Region, hinter denselben Netzbetreibern und teilweise auf denselben Chipgenerationen laufen, gibt es eine ganze Reihe von Ereignissen, die beide gleichzeitig treffen. Fachlich heißt das ein korrelierter Ausfall, und die Erfahrung aus anderen Bereichen der Infrastruktur ist eindeutig: Die seltenen, teuren Ausfälle sind fast immer die korrelierten.

Für die Praxis folgt daraus keine Absage an Mehranbieterstrategien, sondern eine Präzisierung. Ein zweiter Anbieter schützt zuverlässig gegen anbieterspezifische Fehler: ein fehlerhaftes Deployment, ein Kapazitätsengpass, eine Modellabschaltung, ein Vertragsstreit. Gegen die Klasse von Ereignissen, die am Donnerstag im Raum stand, schützt er nur, wenn die beiden Anbieter tatsächlich auf getrennter Infrastruktur laufen. Das ist eine Frage, die man vor der Auswahl stellen muss und die sich nicht aus dem Preisblatt beantworten lässt.

Die Kosten, die nicht in der Tokenrechnung stehen

Der zweite Anbieter wird meistens als Preisfrage diskutiert: Wie viel teurer ist das Ausweichmodell pro Million Token? Diese Zahl ist der kleinste Posten. Die eigentlichen Kosten liegen in vier anderen Bereichen.

Prompts sind nicht portabel. Ein Prompt, der bei einem Modell zuverlässig funktioniert, ist das Ergebnis von Wochen an Feinschliff — Formulierungen, Beispiele, Reihenfolge, Abbruchbedingungen. Bei einem anderen Modell derselben Leistungsklasse funktioniert er meistens auch, aber nicht gleich gut. Der Ausweichpfad, der im Ernstfall einspringt, ist damit ein Pfad, der schlechtere Ergebnisse liefert, und zwar in genau dem Moment, in dem niemand Zeit hat, das zu bemerken.

Die Prüfung verdoppelt sich. Wer zwei Modelle produktiv einsetzt, muss beide bewerten — vor der Einführung und nach jedem Modellwechsel des Anbieters. Wer eine automatisierte Bewertungsstrecke hat, zahlt die doppelten Laufkosten. Wer keine hat, merkt Qualitätsunterschiede erst an Kundenbeschwerden.

Die Schnittstellen sind ähnlich, aber nicht gleich. Werkzeugaufrufe, strukturierte Ausgaben, Bildverarbeitung, Zwischenspeicherung von Kontext, das Verhalten bei Überlast — an all diesen Stellen unterscheiden sich die Anbieter im Detail. Ein Gateway glättet vieles davon, aber nicht alles, und die Reste sind Sonderfälle im eigenen Code.

Das Gateway selbst wird zum Risiko. Damit ein Ausweichmechanismus greift, braucht es eine Stelle, die Fehler erkennt und umschaltet — ein LLM-Gateway. Verbreitete Optionen sind LiteLLM, Bifrost, das Kong AI Gateway, Cloudflare AI Gateway und OpenRouter; alle unterstützen anbieterübergreifende Ausweichketten. Für erste Versuche sind LiteLLM und OpenRouter die zugänglichsten Einstiege, und LiteLLM deckt mit über hundert Anbietern die breiteste Palette ab. Dabei sind zwei Dinge zu beachten. Erstens der Aufwand: Das in Python geschriebene LiteLLM fügt pro Anfrage Hunderte Mikrosekunden bis einige Millisekunden hinzu und verliert bei hoher Nebenläufigkeit spürbar an Leistung — eine Folge der Architektur von Python selbst. Bifrost kommt vergleichsweise auf elf Mikrosekunden bei 5.000 Anfragen pro Sekunde. Zweitens, und wichtiger: Ein selbst betriebenes Gateway ist eine neue zentrale Komponente, durch die jede Anfrage läuft. Man hat den Ausfall des Anbieters gegen den Ausfall der eigenen Umschaltschicht eingetauscht — ein guter Tausch nur dann, wenn diese Schicht auch tatsächlich mit derselben Sorgfalt betrieben wird wie das Produkt selbst.

Was die Verfügbarkeitszusagen wirklich abdecken

Ein Blick in die Verträge lohnt sich, weil er die Erwartung kalibriert. OpenAIs Scale Tier nennt 99,9 Prozent, Enterprise-Rahmenverträge liegen je nach Vereinbarung zwischen 99,9 und 99,99 Prozent. Der Azure OpenAI Service erbt das Azure-Versprechen von 99,9 Prozent im Monat mit den üblichen Gutschriftstufen: 10 Prozent Gutschrift unterhalb von 99,9 Prozent, 25 Prozent unterhalb von 99 Prozent, 100 Prozent unterhalb von 95 Prozent.

Drei Einschränkungen sind entscheidend. Erstens fallen Latenz, Ausfälle der Inhaltsfilter und Änderungen am Tokenizer ausdrücklich nicht unter diesen Gutschriftrahmen — ein Modell, das noch antwortet, aber viermal so langsam, ist im Sinne des Vertrags verfügbar und im Sinne des Produkts nicht. Zweitens ist eine Gutschrift kein Schadenersatz: Zehn Prozent der Monatsrechnung erstatten die nicht erbrachte Leistung, nicht den entgangenen Umsatz. Drittens liegt die gemessene Wirklichkeit unter der Zusage. Für claude.ai wurde über einen jüngeren Dreißigtagezeitraum eine Verfügbarkeit von 99,32 Prozent ermittelt — knapp fünf Stunden im Monat.

Fünf Stunden im Monat ist die Zahl, mit der man planen sollte. Nicht 99,9 Prozent.

Die Abstufung, die tatsächlich funktioniert

Die brauchbare Herangehensweise beginnt nicht bei der Anbieterauswahl, sondern bei einer Sortierung der eigenen Aufrufe. Fast jedes Produkt, das ein Sprachmodell einsetzt, hat drei Sorten davon, und sie verdienen völlig unterschiedliche Antworten.

Asynchrone Aufrufe — nächtliche Auswertungen, Anreicherung von Datensätzen, Zusammenfassungen, Klassifizierung im Hintergrund. Hier ist die richtige Antwort eine Warteschlange mit Wiederholungsversuchen und exponentiell wachsenden Wartezeiten. Ein neunzigminütiger Ausfall verschiebt die Verarbeitung um neunzig Minuten und ist damit erledigt. Diese Maßnahme ist die mit Abstand billigste und wirksamste, sie ist in jedem gängigen Aufgabensystem eingebaut, und sie deckt in den meisten Unternehmen den größten Teil des Verbrauchs ab.

Synchrone, aber unkritische Aufrufe — Vorschläge, Autovervollständigung, optionale Zusammenfassungen im Nutzerinterface. Hier gehört ein definierter eingeschränkter Betrieb hin: die Funktion sichtbar ausblenden statt eine Fehlermeldung zeigen, ein kleineres oder lokales Modell einsetzen, aus dem Zwischenspeicher antworten. Der Nutzer merkt, dass etwas fehlt, aber nichts ist kaputt.

Synchrone, kritische Aufrufe — der Pfad, ohne den das Produkt seinen Zweck verliert. Nur hier lohnt ein zweiter Anbieter, und nur hier rechtfertigen sich die oben beschriebenen Kosten für doppelte Prompts und doppelte Bewertung. In den meisten Produkten ist diese Kategorie deutlich kleiner, als die erste Schätzung im Raum vermuten lässt.

Diese Reihenfolge ist wichtig, weil sie den Aufwand dorthin lenkt, wo er wirkt. Wer mit dem zweiten Anbieter anfängt, hat die teuerste Maßnahme zuerst ergriffen und die billigste — die Warteschlange — womöglich nie.

Drei Fragen für das nächste Quartal

Für die Führungsebene lässt sich der ganze Vorgang auf drei Fragen eindampfen, die sich ohne technische Tiefe stellen und beantworten lassen.

Erstens: Welche unserer Funktionen stehen still, wenn ein Modell neunzig Minuten nicht antwortet — und was sieht der Kunde in diesen neunzig Minuten? Wenn die Antwort „einen hängenden Ladebalken“ lautet, ist das die erste Baustelle, und sie hat mit Anbieterauswahl nichts zu tun.

Zweitens: Auf welcher Infrastruktur laufen unsere Anbieter? Ein Ausweichanbieter, der in derselben Cloud-Region liegt, ist gegen die teuerste Ausfallklasse wirkungslos. Diese Frage gehört in das nächste Anbietergespräch, und die Antwort gehört dokumentiert.

Drittens: Wann haben wir den Ausweichpfad zuletzt benutzt? Ein Ausweichmechanismus, der nie im Normalbetrieb läuft, ist kein Ausweichmechanismus, sondern eine Vermutung. Die Unternehmen, bei denen Umschaltung im Ernstfall funktioniert, sind ausnahmslos die, bei denen ein Teil des regulären Verkehrs dauerhaft über den zweiten Weg läuft.

Der Donnerstag hat keine neue Erkenntnis geliefert. Er hat eine alte sichtbar gemacht: Sprachmodelle sind inzwischen Infrastruktur, und Infrastruktur bewertet man nicht nach dem Verhalten im Normalfall, sondern nach dem Verhalten im Fehlerfall. Der Unterschied zwischen einem Produkt, das einen Anbieterausfall übersteht, und einem, das dabei stehenbleibt, liegt fast nie im Vertrag. Er liegt in der Frage, ob jemand vorher aufgeschrieben hat, was passieren soll, wenn keine Antwort kommt.