Op 4 augustus 2026 registreerde de officiële statuspagina van DeepSeek twee incidenten met verminderde prestaties van de API.
Het eerste incident duurde 1 uur en 18 minuten, van 02:02 tot 03:20 UTC, en had invloed op DeepSeek V4 Flash, V4 Pro en Expert Mode. Het tweede incident duurde 36 minuten, van 03:43 tot 04:20 UTC, en had invloed op de DeepSeek V4 Flash API.
Beide incidenten zijn inmiddels opgelost. OpenCode meldde ook dat DeepSeek Flash te maken had met capaciteitsproblemen door ongekende vraag. Echter, de officiële statuspagina van DeepSeek bevestigde alleen verminderde prestaties en publiceerde geen oorzaak.
TL;DR
- De officiële statuspagina van DeepSeek registreerde twee incidenten met verminderde prestaties die V4 Flash op 4 augustus 2026 beïnvloedden.
- Een directe providerintegratie creëert een enkel punt van falen, zelfs wanneer hetzelfde model elders beschikbaar is.
- AIHubMix kan hetzelfde model opnieuw proberen via meerdere providerkanalen wanneer een upstream-route een herhaalbare fout retourneert.
- Als alle providerkanalen voor het primaire model falen, kan de fallback op modelniveau het verzoek omzetten naar geconfigureerde back-upmodellen.
- Multi-provider routing vermindert de afhankelijkheid van één eindpunt, maar kan niet gecorreleerde storingen of risico's op gateway-niveau elimineren.
Incidenten zoals deze benadrukken een belangrijk infrastructuurprincipe:
Een betrouwbaar model is niet genoeg als het wordt benaderd via een enkel provider-eindpunt.
Één model hoeft niet één provider te betekenen
Wanneer een applicatie rechtstreeks verbinding maakt met één provider, wordt dat eindpunt een enkel punt van falen.
Als de provider een storing ervaart, zijn rate-limiet bereikt of een latentiepieken heeft, heeft de applicatie geen andere plek om het verzoek naartoe te sturen. Gebruikers zien time-outs en fouten, zelfs wanneer hetzelfde model beschikbaar blijft via andere infrastructuurproviders.
AIHubMix scheidt het model van de provider die het levert.
Bijvoorbeeld, DeepSeek V4 Flash is beschikbaar via meerdere providers op AIHubMix, waaronder DeepSeek, Baidu, DeepInfra en Alibaba Cloud. Applicaties blijven één OpenAI-compatibele API-eindpunt gebruiken terwijl AIHubMix de beschikbare upstream-routes beheert.
Dit creëert twee verschillende betrouwbaarheidslagen.
Laag 1: Provider Failover
Provider failover houdt het gevraagde model ongewijzigd terwijl de infrastructuurprovider erachter wordt gewisseld.
Wanneer een verzoek voor DeepSeek V4 Flash AIHubMix bereikt, selecteert de gateway een geschikte providerkanaal. Als dat kanaal een herhaalbare fout retourneert voordat de respons begint, kan AIHubMix een ander beschikbaar kanaal voor hetzelfde model proberen.
Het verzoekpad kan er als volgt uitzien:
- Probeer DeepSeek V4 Flash via Provider A.
- Provider A retourneert een time-out, 5xx-fout of herhaalbare capaciteitsfout.
- Probeer hetzelfde DeepSeek V4 Flash-model via Provider B.
- Ga door totdat het verzoek succesvol is of alle geschikte kanalen zijn uitgeput.
De cliënt hoeft geen meerdere provider-SDK's te integreren, aparte API-sleutels te beheren of zijn eigen herhaal-logica te implementeren.
Dit is failover op provider-niveau: de provider verandert, maar het gevraagde model blijft hetzelfde.
Laag 2: Model Fallback
Een provider failover kan niet helpen als elke beschikbare provider voor het primaire model niet beschikbaar is.
AIHubMix ondersteunt daarom een tweede betrouwbaarheidslaag: model fallback.
Gebruikers kunnen een geordende lijst van back-upmodellen voor elke API-sleutel configureren. Nadat elk geschikt kanaal voor het primaire model een herhaalbare fout heeft geretourneerd, gaat AIHubMix naar het volgende model in de fallback-lijst.
Bijvoorbeeld:
- Primair:
deepseek-v4-flash - Eerste fallback:
gpt-5.4 - Tweede fallback:
gemini-3.1-pro-preview
De fallback wordt uitgevoerd binnen de AIHubMix-gateway. Bestaande applicaties hoeven geen extra routeringsparameters te verzenden of hun clientcode te wijzigen.
Facturering is gebaseerd op het model dat uiteindelijk de succesvolle respons retourneert. Ontwikkelaars kunnen het fallback-gedrag verifiëren via de responsheaders:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
De volledige configuratie en triggerregels zijn gedocumenteerd in AIHubMix Model Mapping and Fallback.
Wat automatische failover kan afhandelen
Provider failover is ontworpen om te herstellen van upstream-infrastructuurproblemen zoals:
- Provider time-outs
- Verbindingsfouten
- Herhaalbare 5xx-responsen
- Provider rate-limieten en capaciteitsfouten
- Tijdelijke onbeschikbaarheid van een upstream-kanaal
Wanneer deze fouten optreden voordat de respons begint, kan AIHubMix transparant een andere route proberen.
Wat failover niet kan oplossen
Multi-provider routing verbetert de beschikbaarheid, maar maakt een gateway niet onfeilbaar.
Fallback wordt niet geactiveerd wanneer:
- De AIHubMix API-sleutel van de gebruiker ongeldig, verlopen of buiten quotum is
- Het verzoek zelf ongeldig is
- De cliënt losgekoppeld is of zijn eigen time-out bereikt
- Een streamingrespons al is begonnen
- Een specifiek providerkanaal expliciet is geselecteerd
- De fout elke provider of de gateway zelf beïnvloedt
Providerfouten kunnen ook gecorreleerd zijn. Meerdere providers kunnen afhankelijk zijn van dezelfde onderliggende infrastructuur, modelrelease of regionale netwerken. Om deze reden moet de beschikbaarheid van meerdere providers worden gemeten met echt verkeer in plaats van alleen aangenomen op basis van het aantal providers.
Waarom een aggregator betrouwbaarder kan zijn dan een direct eindpunt
Een officiële API rechtstreeks aanroepen geeft een applicatie één route naar het model.
Een multi-provider gateway biedt er meerdere.
Als die provider-routes onafhankelijk falen, kan de gateway om een verlaagd eindpunt heen routeren zonder de fout aan de applicatie bloot te stellen. Dit vermindert de afhankelijkheid van een enkele provider en kan een hogere beschikbaarheid bieden dan een directe integratie met één provider.
Het verschil is architectonisch:
- Directe API: één model, één provider, één foutdomein
- AIHubMix: één model, meerdere providers, automatische failover
- AIHubMix met model fallback: meerdere providers plus back-upmodellen
Het doel is niet te voorspellen welke provider als volgende zal falen. Het is om een upstream-incident een intern routeringsevenement te maken in plaats van een klantgerichte storing.
Bouw voor het volgende provider-incident
DeepSeek V4 Flash is hersteld, maar tijdelijke capaciteitsbeperkingen, rate-limieten en upstream-storingen zijn normale onderdelen van productie-AI-infrastructuur.
Applicaties zouden niet elke keer code moeten hoeven wijzigen wanneer een provider onbetrouwbaar wordt.
Met AIHubMix kunnen ontwikkelaars toegang krijgen tot meerdere providers via één API, automatisch hetzelfde model opnieuw proberen via beschikbare kanalen en back-upmodellen configureren voor een extra beschermingslaag.
Ontdek beschikbare modellen en providers op aihubmix.com/models.
FAQ
Wat is multi-provider failover?
Het probeert automatisch hetzelfde model opnieuw via een andere geschikte provider wanneer de huidige route een herhaalbare fout retourneert.
Hoe verschilt model fallback?
Provider failover houdt het model ongewijzigd. Model fallback schakelt over naar een geconfigureerd back-upmodel pas nadat alle geschikte kanalen voor het primaire model zijn mislukt.
Welke fouten kunnen failover activeren?
Typische triggers zijn time-outs, verbindingsfouten, herhaalbare 5xx-responsen, rate-limieten en tijdelijke capaciteitsfouten voordat een respons begint.
Garandeert failover nul downtime?
Nee. Gecorreleerde providerfouten, incidenten op gateway-niveau, niet-herhaalbare fouten en fouten nadat de streaming is begonnen, kunnen nog steeds de cliënt bereiken.
Moet ik mijn applicatiecode wijzigen?
Geen extra routeringslogica is vereist. Applicaties blijven de AIHubMix OpenAI-compatibele eindpunt gebruiken, terwijl back-upmodellen op het niveau van de API-sleutel kunnen worden geconfigureerd.