Op 4 augustus 2026 registreerde de officiële statuspagina van DeepSeek twee incidenten met gedegradeerde API-prestaties.
Het eerste incident duurde 1 uur en 18 minuten, van 02:02 tot 03:20 UTC, en trof DeepSeek V4 Flash, V4 Pro en Expert Mode. Het tweede incident duurde 36 minuten, van 03:43 tot 04:20 UTC, en trof de DeepSeek V4 Flash API.
Beide incidenten zijn inmiddels opgelost. OpenCode meldde ook dat DeepSeek Flash capaciteitsproblemen had door ongekende vraag. De officiële statuspagina van DeepSeek bevestigde echter alleen gedegradeerde prestaties en publiceerde geen grondoorzaak.
TL;DR
- De officiële statuspagina van DeepSeek registreerde op 4 augustus 2026 twee incidenten met gedegradeerde prestaties die V4 Flash troffen.
- Een directe integratie met één provider creëert een enkelvoudig knelpunt, ook wanneer hetzelfde model elders beschikbaar is.
- AIHubMix kan dezelfde modelaanvraag opnieuw proberen via meerdere providerkanalen wanneer een upstream-route een fout retourneert die opnieuw proberen toelaat.
- Als alle providerkanalen voor het primaire model falen, kan modelfallback op sleutelniveau de aanvraag naar geconfigureerde back-upmodellen omleiden.
- Multi-provider routing vermindert de afhankelijkheid van één endpoint, maar kan gecorreleerde storingen of risico's op gatewayniveau niet uitsluiten.
Incidenten zoals dit benadrukken een belangrijk infrastructuurprincipe:
Een betrouwbaar model is niet genoeg als het via één providerendpoint wordt benaderd.
Eén model hoeft niet één provider te betekenen
Wanneer een applicatie rechtstreeks met één provider verbonden is, wordt dat endpoint een enkelvoudig knelpunt.
Als de provider een storing heeft, de ratelimiet bereikt of een latentiepiek ondervindt, heeft de applicatie geen andere plek om het verzoek naartoe te sturen. Gebruikers zien time-outs en fouten, zelfs wanneer hetzelfde model nog steeds beschikbaar is via andere infrastructuurproviders.
AIHubMix scheidt het model van de provider die het aanbiedt.
DeepSeek V4 Flash is bijvoorbeeld via meerdere providers op AIHubMix beschikbaar, waaronder DeepSeek, Baidu, DeepInfra en Alibaba Cloud. Applicaties blijven één OpenAI-compatibel API-endpoint gebruiken, terwijl AIHubMix de beschikbare upstream-routes beheert.
Dit creëert twee afzonderlijke betrouwbaarheidslagen.
Laag 1: Providerfailover
Providerfailover houdt het gevraagde model ongewijzigd terwijl de infrastructuurprovider erachter wordt gewisseld.
Wanneer een verzoek voor DeepSeek V4 Flash AIHubMix bereikt, kiest de gateway een geschikt providerkanaal. Als dat kanaal een fout retourneert die opnieuw proberen toelaat voordat het antwoord 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, een 5xx-fout of een fout door capaciteit die opnieuw proberen toelaat.
- Probeer hetzelfde DeepSeek V4 Flash-model via Provider B.
- Ga door totdat het verzoek slaagt of alle geschikte kanalen zijn uitgeput.
De client hoeft geen meerdere provider-SDK's te integreren, afzonderlijke API-sleutels te beheren of zijn eigen herhaallogica te implementeren.
Dit is failover op providerniveau: de provider verandert, maar het gevraagde model blijft hetzelfde.
Laag 2: Modelfallback
Providerfailover helpt niet als elke beschikbare provider voor het primaire model onbereikbaar is.
AIHubMix biedt daarom een tweede betrouwbaarheidslaag: modelfallback.
Gebruikers kunnen per API-sleutel een geordende lijst met back-upmodellen configureren. Nadat elk geschikt kanaal voor het primaire model een fout heeft teruggegeven die opnieuw proberen toelaat, schakelt AIHubMix over naar het volgende model in de fallbacklijst.
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 versturen of hun clientcode te wijzigen.
De facturering is gebaseerd op het model dat uiteindelijk het succesvolle antwoord retourneert. Ontwikkelaars kunnen het fallbackgedrag controleren via de responsheaders:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
De volledige configuratie en activeringsregels zijn gedocumenteerd in AIHubMix-modelmapping en fallback.
Wat automatische failover kan opvangen
Providerfailover is ontworpen om te herstellen van problemen met de upstream-infrastructuur, zoals:
- Time-outs van providers
- Verbindingsfouten
- 5xx-responses die opnieuw proberen toelaten
- Ratelimieten van providers en fouten door capaciteit
- Tijdelijke onbeschikbaarheid van een upstream-kanaal
Wanneer deze fouten optreden voordat het antwoord begint, kan AIHubMix transparant een andere route proberen.
Wat failover niet kan oplossen
Multi-provider routing verbetert de beschikbaarheid, maar maakt een gateway niet feilloos.
Fallback wordt niet geactiveerd wanneer:
- De AIHubMix-API-sleutel van de gebruiker ongeldig, verlopen of door het quotum heen is
- Het verzoek zelf ongeldig is
- De client de verbinding verbreekt of zijn eigen time-out bereikt
- Een streamingantwoord al is gestart
- Een specifiek providerkanaal expliciet is geselecteerd
- De storing alle providers of de gateway zelf treft
Storingen bij providers kunnen ook gecorreleerd zijn. Meerdere providers kunnen afhankelijk zijn van dezelfde onderliggende infrastructuur, modelrelease of regionaal netwerk. Daarom moet de beschikbaarheid van meerdere providers worden gemeten met echt verkeer en niet alleen worden aangenomen op basis van het aantal providers.
Waarom een aggregator betrouwbaarder kan zijn dan een rechtstreeks endpoint
Een officiële API rechtstreeks aanroepen geeft een applicatie één route naar het model.
Een multi-provider gateway geeft er meerdere.
Als die providerroutes onafhankelijk van elkaar falen, kan de gateway een gedegradeerd endpoint omzeilen zonder dat de applicatie de storing ziet. Dit vermindert de afhankelijkheid van één 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 storingsdomein
- AIHubMix: één model, meerdere providers, automatische failover
- AIHubMix met modelfallback: meerdere providers plus back-upmodellen
Het doel is niet te voorspellen welke provider de volgende keer uitvalt. Het doel is om een storing bij een upstream-provider een interne routeringsgebeurtenis te maken in plaats van een uitval die klanten merken.
Bouw voor het volgende providerincident
DeepSeek V4 Flash is hersteld, maar tijdelijke capaciteitsbeperkingen, ratelimieten en upstream-storingen zijn normale onderdelen van productie-AI-infrastructuur.
Applicaties zouden niet elke keer code moeten hoeven wijzigen wanneer een provider instabiel wordt.
Met AIHubMix kunnen ontwikkelaars via één API toegang krijgen tot meerdere providers, hetzelfde model automatisch opnieuw proberen via beschikbare kanalen en back-upmodellen configureren voor een extra beschermingslaag.
Bekijk beschikbare modellen en providers op aihubmix.com/models.
Veelgestelde vragen
Wat is multi-provider failover?
Het probeert hetzelfde model automatisch opnieuw via een andere geschikte provider wanneer de huidige route een fout retourneert die opnieuw proberen toelaat.
Hoe verschilt modelfallback?
Providerfailover houdt het model ongewijzigd. Modelfallback schakelt pas over naar een geconfigureerd back-upmodel nadat alle geschikte kanalen voor het primaire model zijn mislukt.
Welke fouten kunnen failover activeren?
Typische triggers zijn time-outs, verbindingsfouten, 5xx-responses die opnieuw proberen toelaten, ratelimieten en tijdelijke capaciteitsfouten voordat een antwoord begint.
Garandeert failover nul downtime?
Nee. Gecorreleerde storingen bij providers, incidenten op gatewayniveau, fouten die niet opnieuw geprobeerd kunnen worden, en fouten nadat streaming is begonnen, kunnen de client nog steeds bereiken.
Moet ik mijn applicatiecode wijzigen?
Er is geen extra routeringslogica nodig. Applicaties blijven het OpenAI-compatibele endpoint van AIHubMix gebruiken, terwijl back-upmodellen op API-sleutelniveau kunnen worden geconfigureerd.
