Le 4 août 2026, la page d’état officielle de DeepSeek a enregistré deux incidents de dégradation des performances de l’API.
Le premier incident a duré 1 heure et 18 minutes, de 02h02 à 03h20 UTC, et a affecté DeepSeek V4 Flash, V4 Pro et le mode Expert. Le second incident a duré 36 minutes, de 03h43 à 04h20 UTC, et a affecté l’API DeepSeek V4 Flash.
Les deux incidents ont depuis été résolus. OpenCode a également signalé que DeepSeek Flash connaissait des problèmes de capacité en raison d’une demande sans précédent. Cependant, la page d’état officielle de DeepSeek a seulement confirmé une dégradation des performances et n’a publié aucune cause racine.
En bref
- La page d’état officielle de DeepSeek a enregistré deux incidents de dégradation des performances affectant V4 Flash le 4 août 2026.
- Une intégration directe avec un fournisseur crée un point de défaillance unique, même lorsque le même modèle est disponible ailleurs.
- AIHubMix peut relancer la même requête sur le même modèle via plusieurs canaux de fournisseurs lorsqu’une route amont renvoie une erreur réessayable.
- Si tous les canaux de fournisseurs du modèle principal échouent, le repli au niveau de la clé permet de rediriger la requête vers des modèles de secours configurés.
- Le routage multi-fournisseurs réduit la dépendance à un seul point de terminaison, mais il ne peut pas éliminer les défaillances corrélées ni les risques au niveau de la passerelle.
Des incidents comme celui-ci mettent en évidence un principe d’infrastructure important :
Un modèle fiable ne suffit pas s’il est accessible via un seul point de terminaison fournisseur.
Un modèle ne doit pas forcément correspondre à un seul fournisseur
Lorsqu’une application se connecte directement à un seul fournisseur, ce point de terminaison devient un point de défaillance unique.
Si le fournisseur subit une panne, atteint sa limite de débit ou connaît un pic de latence, l’application n’a nulle part ailleurs où envoyer la requête. Les utilisateurs voient alors des délais d’attente et des erreurs, même lorsque le même modèle reste disponible via d’autres fournisseurs d’infrastructure.
AIHubMix sépare le modèle du fournisseur qui le fait fonctionner.
Par exemple, DeepSeek V4 Flash est disponible via plusieurs fournisseurs sur AIHubMix, notamment DeepSeek, Baidu, DeepInfra et Alibaba Cloud. Les applications continuent d’utiliser un seul point de terminaison API compatible OpenAI, tandis qu’AIHubMix gère les routes amont disponibles.
Cela crée deux couches de fiabilité distinctes.
Couche 1 : basculement entre fournisseurs
Le basculement entre fournisseurs conserve le modèle demandé inchangé tout en changeant le fournisseur d’infrastructure qui le sert.
Lorsqu’une requête pour DeepSeek V4 Flash parvient à AIHubMix, la passerelle sélectionne un canal de fournisseur éligible. Si ce canal renvoie une erreur réessayable avant le début de la réponse, AIHubMix peut tenter un autre canal disponible pour le même modèle.
Le chemin de la requête peut ressembler à ceci :
- Essayer DeepSeek V4 Flash via le fournisseur A.
- Le fournisseur A renvoie un délai d’attente, une erreur 5xx ou une erreur de capacité réessayable.
- Essayer le même modèle DeepSeek V4 Flash via le fournisseur B.
- Continuer jusqu’à ce que la requête aboutisse ou que tous les canaux éligibles soient épuisés.
Le client n’a pas besoin d’intégrer plusieurs SDK de fournisseurs, de gérer des clés API distinctes ni d’implémenter sa propre logique de nouvelle tentative.
Il s’agit d’un basculement au niveau du fournisseur : le fournisseur change, mais le modèle demandé reste le même.
Couche 2 : repli sur un autre modèle
Un basculement entre fournisseurs ne peut rien faire si tous les fournisseurs disponibles pour le modèle principal sont indisponibles.
AIHubMix propose donc une deuxième couche de fiabilité : le repli sur un autre modèle.
Les utilisateurs peuvent configurer une liste ordonnée de modèles de secours pour chaque clé API. Une fois que tous les canaux éligibles du modèle principal ont renvoyé une erreur réessayable, AIHubMix passe au modèle suivant de la liste de repli.
Par exemple :
- Principal :
deepseek-v4-flash - Premier repli :
gpt-5.4 - Second repli :
gemini-3.1-pro-preview
Le repli est effectué au sein de la passerelle AIHubMix. Les applications existantes n’ont pas besoin d’envoyer de paramètres de routage supplémentaires ni de modifier leur code client.
La facturation est basée sur le modèle qui a finalement renvoyé la réponse réussie. Les développeurs peuvent vérifier le comportement de repli via les en-têtes de réponse :
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
La configuration complète et les règles de déclenchement sont documentées dans AIHubMix Model Mapping and Fallback.
Ce que le basculement automatique peut gérer
Le basculement entre fournisseurs est conçu pour se remettre de problèmes d’infrastructure amont tels que :
- Les délais d’attente des fournisseurs
- Les échecs de connexion
- Les réponses 5xx réessayables
- Les limites de débit et erreurs de capacité des fournisseurs
- L’indisponibilité temporaire d’un canal amont
Lorsque ces défaillances surviennent avant le début de la réponse, AIHubMix peut transparemment tenter une autre route.
Ce que le basculement ne peut pas résoudre
Le routage multi-fournisseurs améliore la disponibilité, mais il ne rend pas la passerelle infaillible.
Le repli n’est pas déclenché lorsque :
- La clé API AIHubMix de l’utilisateur est invalide, expirée ou a épuisé son quota
- La requête elle-même est invalide
- Le client se déconnecte ou atteint son propre délai d’attente
- Une réponse en streaming a déjà commencé
- Un canal fournisseur spécifique a été explicitement sélectionné
- La défaillance touche tous les fournisseurs ou la passerelle elle-même
Les défaillances des fournisseurs peuvent aussi être corrélées. Plusieurs fournisseurs peuvent dépendre de la même infrastructure sous-jacente, de la même sortie de modèle ou du même réseau régional. Pour cette raison, la disponibilité multi-fournisseurs doit être mesurée avec du trafic réel plutôt que déduite du seul nombre de fournisseurs.
Pourquoi un agrégateur peut être plus fiable qu’un point de terminaison direct
Appeler directement une API officielle donne à une application une seule route vers le modèle.
Une passerelle multi-fournisseurs en offre plusieurs.
Si ces routes fournisseurs échouent de manière indépendante, la passerelle peut contourner un point de terminaison dégradé sans exposer la panne à l’application. Cela réduit la dépendance à un fournisseur unique et peut offrir une disponibilité supérieure à celle d’une intégration directe avec un seul fournisseur.
La différence est architecturale :
- API directe : un modèle, un fournisseur, un domaine de défaillance
- AIHubMix : un modèle, plusieurs fournisseurs, basculement automatique
- AIHubMix avec repli sur un autre modèle : plusieurs fournisseurs plus des modèles de secours
L’objectif n’est pas de prédire quel fournisseur tombera en panne ensuite. Il s’agit de transformer un incident amont en événement de routage interne plutôt qu’en panne visible par le client.
Se préparer au prochain incident fournisseur
DeepSeek V4 Flash a retrouvé son fonctionnement normal, mais les contraintes de capacité temporaires, les limites de débit et les pannes amont font partie du fonctionnement normal de l’infrastructure d’IA en production.
Les applications ne devraient pas avoir à modifier leur code chaque fois qu’un fournisseur devient instable.
Avec AIHubMix, les développeurs peuvent accéder à plusieurs fournisseurs via une seule API, relancer automatiquement la même requête sur le même modèle via les canaux disponibles, et configurer des modèles de secours pour une couche de protection supplémentaire.
Découvrez les modèles et fournisseurs disponibles sur aihubmix.com/models.
FAQ
Qu’est-ce que le basculement multi-fournisseurs ?
Il relance automatiquement la même requête sur le même modèle via un autre fournisseur éligible lorsque la route actuelle renvoie une erreur réessayable.
En quoi le repli sur un autre modèle est-il différent ?
Le basculement entre fournisseurs conserve le modèle inchangé. Le repli sur un autre modèle ne bascule vers un modèle de secours configuré qu’après l’échec de tous les canaux éligibles du modèle principal.
Quelles défaillances peuvent déclencher le basculement ?
Les déclencheurs typiques incluent les délais d’attente, les échecs de connexion, les réponses 5xx réessayables, les limites de débit et les erreurs de capacité temporaires avant le début d’une réponse.
Le basculement garantit-il une absence totale d’interruption ?
Non. Les défaillances corrélées des fournisseurs, les incidents au niveau de la passerelle, les erreurs non réessayables et les défaillances survenant après le début du streaming peuvent quand même atteindre le client.
Dois-je modifier le code de mon application ?
Aucune logique de routage supplémentaire n’est nécessaire. Les applications continuent d’utiliser le point de terminaison compatible OpenAI d’AIHubMix, tandis que les modèles de secours peuvent être configurés au niveau de la clé API.
