Am 4. August 2026 verzeichnete die offizielle Statusseite von DeepSeek zwei Vorfälle mit beeinträchtigter API-Leistung.
Der erste Vorfall dauerte 1 Stunde und 18 Minuten, von 02:02 bis 03:20 UTC, und betraf DeepSeek V4 Flash, V4 Pro und den Expertenmodus. Der zweite Vorfall dauerte 36 Minuten, von 03:43 bis 04:20 UTC, und betraf die DeepSeek V4 Flash API.
Beide Vorfälle sind inzwischen behoben. OpenCode berichtete außerdem, dass DeepSeek Flash aufgrund einer beispiellosen Nachfrage mit Kapazitätsproblemen zu kämpfen hatte. Die offizielle Statusseite von DeepSeek bestätigte jedoch nur die beeinträchtigte Leistung und veröffentlichte keine Ursachenanalyse.
TL;DR
- Die offizielle Statusseite von DeepSeek verzeichnete am 4. August 2026 zwei Vorfälle mit beeinträchtigter Leistung, die V4 Flash betrafen.
- Eine direkte Anbieterintegration schafft einen einzigen Ausfallpunkt, selbst wenn dasselbe Modell anderswo verfügbar ist.
- AIHubMix kann dasselbe Modell über mehrere Anbieterkanäle erneut versuchen, wenn ein upstream-Routing einen wiederholbaren Fehler zurückgibt.
- Wenn alle Anbieterkanäle für das primäre Modell ausfallen, kann der Fallback auf Modelle auf Schlüssel-Ebene die Anfrage auf konfigurierte Backup-Modelle umschalten.
- Multi-Provider-Routing verringert die Abhängigkeit von einem Endpunkt, kann jedoch korrelierte Ausfälle oder Risiken auf Gateway-Ebene nicht beseitigen.
Vorfälle wie dieser heben ein wichtiges Infrastrukturprinzip hervor:
Ein zuverlässiges Modell ist nicht genug, wenn es über einen einzigen Anbieterendpunkt abgerufen wird.
Ein Modell muss nicht einen Anbieter bedeuten
Wenn eine Anwendung direkt mit einem Anbieter verbunden ist, wird dieser Endpunkt zu einem einzigen Ausfallpunkt.
Erlebt der Anbieter einen Ausfall, erreicht sein Kontingent oder leidet unter einem Latenzanstieg, hat die Anwendung keinen anderen Ort, um die Anfrage zu senden. Benutzer sehen Zeitüberschreitungen und Fehler, selbst wenn dasselbe Modell über andere Infrastruktur-Anbieter verfügbar bleibt.
AIHubMix trennt das Modell vom Anbieter, der es bereitstellt.
Zum Beispiel ist DeepSeek V4 Flash über mehrere Anbieter auf AIHubMix verfügbar, darunter DeepSeek, Baidu, DeepInfra und Alibaba Cloud. Anwendungen verwenden weiterhin einen OpenAI-kompatiblen API-Endpunkt, während AIHubMix die verfügbaren upstream-Routen verwaltet.
Dies schafft zwei unterschiedliche Zuverlässigkeitsebenen.
Ebene 1: Anbieter-Failover
Anbieter-Failover hält das angeforderte Modell unverändert, während der Infrastruktur-Anbieter dahinter gewechselt wird.
Wenn eine Anfrage für DeepSeek V4 Flash AIHubMix erreicht, wählt das Gateway einen berechtigten Anbieterkanal aus. Wenn dieser Kanal einen wiederholbaren Fehler zurückgibt, bevor die Antwort beginnt, kann AIHubMix einen anderen verfügbaren Kanal für dasselbe Modell versuchen.
Der Anfragepfad könnte so aussehen:
- Versuche DeepSeek V4 Flash über Anbieter A.
- Anbieter A gibt eine Zeitüberschreitung, einen 5xx-Fehler oder einen wiederholbaren Kapazitätsfehler zurück.
- Versuche dasselbe DeepSeek V4 Flash-Modell über Anbieter B.
- Fahre fort, bis die Anfrage erfolgreich ist oder alle berechtigten Kanäle erschöpft sind.
Der Client muss keine mehreren Anbieter-SDKs integrieren, separate API-Schlüssel verwalten oder seine eigene Wiederholungslogik implementieren.
Dies ist das Anbieter-Failover: der Anbieter ändert sich, aber das angeforderte Modell bleibt gleich.
Ebene 2: Modell-Fallback
Ein Anbieter-Failover kann nicht helfen, wenn jeder verfügbare Anbieter für das primäre Modell nicht verfügbar ist.
AIHubMix unterstützt daher eine zweite Zuverlässigkeitsebene: Modell-Fallback.
Benutzer können eine geordnete Liste von Backup-Modellen für jeden API-Schlüssel konfigurieren. Nachdem jeder berechtigte Kanal für das primäre Modell einen wiederholbaren Fehler zurückgegeben hat, wechselt AIHubMix zum nächsten Modell in der Fallback-Liste.
Zum Beispiel:
- Primär:
deepseek-v4-flash - Erster Fallback:
gpt-5.4 - Zweiter Fallback:
gemini-3.1-pro-preview
Der Fallback erfolgt innerhalb des AIHubMix-Gateways. Bestehende Anwendungen müssen keine zusätzlichen Routing-Parameter senden oder ihren Client-Code ändern.
Die Abrechnung erfolgt basierend auf dem Modell, das letztendlich die erfolgreiche Antwort zurückgibt. Entwickler können das Fallback-Verhalten über die Antwort-Header überprüfen:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
Die vollständige Konfiguration und die Auslösebedingungen sind in AIHubMix Modellzuordnung und Fallback dokumentiert.
Was automatisches Failover bewältigen kann
Anbieter-Failover ist darauf ausgelegt, sich von upstream-Infrastrukturproblemen zu erholen, wie zum Beispiel:
- Anbieter-Zeitüberschreitungen
- Verbindungsfehler
- Wiederholbare 5xx-Antworten
- Rate-Limits und Kapazitätsfehler des Anbieters
- Vorübergehende Nichtverfügbarkeit eines upstream-Kanals
Wenn diese Fehler auftreten, bevor die Antwort beginnt, kann AIHubMix transparent einen anderen Pfad versuchen.
Was Failover nicht lösen kann
Multi-Provider-Routing verbessert die Verfügbarkeit, macht ein Gateway jedoch nicht unfehlbar.
Fallback wird nicht ausgelöst, wenn:
- Der API-Schlüssel von AIHubMix des Benutzers ungültig, abgelaufen oder ohne Kontingent ist
- Die Anfrage selbst ungültig ist
- Der Client die Verbindung trennt oder seine eigene Zeitüberschreitung erreicht
- Eine Streaming-Antwort bereits begonnen hat
- Ein bestimmter Anbieterkanal ausdrücklich ausgewählt wurde
- Der Fehler alle Anbieter oder das Gateway selbst betrifft
Anbieterfehler können auch korreliert sein. Mehrere Anbieter können von derselben zugrunde liegenden Infrastruktur, Modellversion oder regionalem Netzwerk abhängen. Aus diesem Grund sollte die Verfügbarkeit von Multi-Provider mit echtem Verkehr gemessen werden, anstatt nur von der Anzahl der Anbieter auszugehen.
Warum ein Aggregator zuverlässiger sein kann als ein direkter Endpunkt
Die direkte Aufrufung einer offiziellen API gibt einer Anwendung einen Pfad zum Modell.
Ein Multi-Provider-Gateway gibt ihr mehrere.
Wenn diese Anbieterpfade unabhängig ausfallen, kann das Gateway um einen beeinträchtigten Endpunkt herum routen, ohne den Fehler der Anwendung auszusetzen. Dies verringert die Abhängigkeit von einem einzelnen Anbieter und kann eine höhere Verfügbarkeit bieten als eine direkte Integration mit einem einzelnen Anbieter.
Der Unterschied ist architektonisch:
- Direkte API: ein Modell, ein Anbieter, ein Ausfallbereich
- AIHubMix: ein Modell, mehrere Anbieter, automatisches Failover
- AIHubMix mit Modell-Fallback: mehrere Anbieter plus Backup-Modelle
Das Ziel ist nicht vorherzusagen, welcher Anbieter als nächstes ausfällt. Es geht darum, einen upstream-Vorfall zu einem internen Routing-Ereignis anstelle eines kundenorientierten Ausfalls zu machen.
Für den nächsten Anbieter-Vorfall bauen
DeepSeek V4 Flash hat sich erholt, aber vorübergehende Kapazitätsengpässe, Rate-Limits und upstream-Ausfälle sind normale Bestandteile der Produktions-AI-Infrastruktur.
Anwendungen sollten ihren Code nicht jedes Mal ändern müssen, wenn ein Anbieter instabil wird.
Mit AIHubMix können Entwickler über eine API auf mehrere Anbieter zugreifen, dasselbe Modell automatisch über verfügbare Kanäle erneut versuchen und Backup-Modelle für eine zusätzliche Schutzebene konfigurieren.
Erforschen Sie verfügbare Modelle und Anbieter unter aihubmix.com/models.
FAQ
Was ist Multi-Provider-Failover?
Es versucht automatisch, dasselbe Modell über einen anderen berechtigten Anbieter erneut, wenn der aktuelle Pfad einen wiederholbaren Fehler zurückgibt.
Wie unterscheidet sich der Modell-Fallback?
Anbieter-Failover hält das Modell unverändert. Modell-Fallback wechselt nur zu einem konfigurierten Backup-Modell, nachdem alle berechtigten Kanäle für das primäre Modell ausgefallen sind.
Welche Fehler können das Failover auslösen?
Typische Auslöser sind Zeitüberschreitungen, Verbindungsfehler, wiederholbare 5xx-Antworten, Rate-Limits und vorübergehende Kapazitätsfehler, bevor eine Antwort beginnt.
Garantiert Failover null Ausfallzeiten?
Nein. Korrelierte Anbieterfehler, Vorfälle auf Gateway-Ebene, nicht wiederholbare Fehler und Fehler, nachdem das Streaming begonnen hat, können dennoch den Client erreichen.
Muss ich meinen Anwendungscode ändern?
Es sind keine zusätzlichen Routing-Logiken erforderlich. Anwendungen verwenden weiterhin den AIHubMix OpenAI-kompatiblen Endpunkt, während Backup-Modelle auf API-Schlüssel-Ebene konfiguriert werden können.