Le 4 août 2026, la page de statut officielle de DeepSeek a enregistré deux incidents de dégradation de performance de l'API.
Le premier incident a duré 1 heure et 18 minutes, de 02:02 à 03:20 UTC, et a affecté DeepSeek V4 Flash, V4 Pro et le Mode Expert. Le deuxième incident a duré 36 minutes, de 03:43 à 04:20 UTC, et a affecté l'API DeepSeek V4 Flash.
Les deux incidents ont depuis été résolus. OpenCode a également signalé que DeepSeek Flash rencontrait des problèmes de capacité en raison d'une demande sans précédent. Cependant, la page de statut officielle de DeepSeek n'a confirmé que la dégradation de performance et n'a pas publié de cause racine.
TL;DR
- La page de statut officielle de DeepSeek a enregistré deux incidents de dégradation de performance 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 réessayer le même modèle à travers plusieurs canaux de fournisseurs lorsque qu'une route en amont retourne une erreur réessayable.
- Si tous les canaux de fournisseurs pour le modèle principal échouent, la bascule au niveau du modèle peut changer la demande vers des modèles de secours configurés.
- Le routage multi-fournisseurs réduit la dépendance à un seul point de terminaison, mais ne peut pas éliminer les défaillances corrélées ou le risque 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 nécessairement signifier un fournisseur
Lorsqu'une application se connecte directement à un fournisseur, ce point de terminaison devient un point de défaillance unique.
Si le fournisseur subit une panne, atteint sa limite de taux ou souffre d'un pic de latence, l'application n'a nulle part d'autre où envoyer la demande. Les utilisateurs voient 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 sert.
Par exemple, DeepSeek V4 Flash est disponible via plusieurs fournisseurs sur AIHubMix, y compris DeepSeek, Baidu, DeepInfra et Alibaba Cloud. Les applications continuent d'utiliser un point de terminaison API compatible OpenAI tandis qu'AIHubMix gère les routes disponibles en amont.
Cela crée deux couches de fiabilité distinctes.
Couche 1 : Bascule fournisseur
La bascule fournisseur maintient le modèle demandé inchangé tout en changeant le fournisseur d'infrastructure derrière lui.
Lorsque une demande pour DeepSeek V4 Flash atteint AIHubMix, la passerelle sélectionne un canal fournisseur éligible. Si ce canal retourne une erreur réessayable avant que la réponse ne commence, AIHubMix peut essayer un autre canal disponible pour le même modèle.
Le chemin de la demande peut ressembler à ceci :
- Essayer DeepSeek V4 Flash via le Fournisseur A.
- Le Fournisseur A retourne 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 demande réussisse 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 séparées ou de mettre en œuvre sa propre logique de réessai.
C'est la bascule au niveau du fournisseur : le fournisseur change, mais le modèle demandé reste le même.
Couche 2 : Bascule de modèle
Une bascule fournisseur ne peut pas aider si chaque fournisseur disponible pour le modèle principal est indisponible.
AIHubMix prend donc en charge une deuxième couche de fiabilité : la bascule de modèle.
Les utilisateurs peuvent configurer une liste ordonnée de modèles de secours pour chaque clé API. Après que chaque canal éligible pour le modèle principal ait retourné un échec réessayable, AIHubMix passe au modèle suivant dans la liste de secours.
Par exemple :
- Principal :
deepseek-v4-flash - Premier secours :
gpt-5.4 - Deuxième secours :
gemini-3.1-pro-preview
La bascule est effectuée à l'intérieur de la passerelle AIHubMix. Les applications existantes n'ont pas besoin d'envoyer des paramètres de routage supplémentaires ou de modifier leur code client.
La facturation est basée sur le modèle qui retourne finalement la réponse réussie. Les développeurs peuvent vérifier le comportement de bascule à travers 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 la bascule automatique peut gérer
La bascule fournisseur est conçue pour récupérer des problèmes d'infrastructure en amont tels que :
- Délais d'attente fournisseur
- Échecs de connexion
- Réponses 5xx réessayables
- Limites de taux et erreurs de capacité fournisseur
- Indisponibilité temporaire d'un canal en amont
Lorsque ces échecs se produisent avant le début de la réponse, AIHubMix peut essayer de manière transparente une autre route.
Ce que la bascule ne peut pas résoudre
Le routage multi-fournisseurs améliore la disponibilité, mais ne rend pas une passerelle infaillible.
La bascule n'est pas déclenchée lorsque :
- La clé API AIHubMix de l'utilisateur est invalide, expirée ou hors quota
- La demande 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é
- L'échec affecte chaque fournisseur ou la passerelle elle-même
Les échecs de fournisseur peuvent également être corrélés. Plusieurs fournisseurs peuvent dépendre de la même infrastructure sous-jacente, de la version du modèle ou du réseau régional. Pour cette raison, la disponibilité multi-fournisseurs doit être mesurée avec un trafic réel plutôt que supposée à partir du nombre de fournisseurs seulement.
Pourquoi un agrégateur peut être plus fiable qu'un point de terminaison direct
Appeler une API officielle directement donne à une application une route vers le modèle.
Une passerelle multi-fournisseurs lui en donne plusieurs.
Si ces routes de fournisseur échouent indépendamment, la passerelle peut contourner un point de terminaison dégradé sans exposer l'échec à l'application. Cela réduit la dépendance à un fournisseur unique et peut offrir une disponibilité plus élevée qu'une intégration directe avec un fournisseur unique.
La différence est architecturale :
- API directe : un modèle, un fournisseur, un domaine de défaillance
- AIHubMix : un modèle, plusieurs fournisseurs, bascule automatique
- AIHubMix avec bascule de modèle : plusieurs fournisseurs plus des modèles de secours
L'objectif n'est pas de prédire quel fournisseur échouera ensuite. Il s'agit de faire d'un incident en amont un événement de routage interne plutôt qu'une panne visible par le client.
Préparez-vous pour le prochain incident fournisseur
DeepSeek V4 Flash s'est rétabli, mais les contraintes de capacité temporaires, les limites de taux et les pannes en amont sont des parties normales de l'infrastructure AI en production.
Les applications ne devraient pas avoir à changer de code chaque fois qu'un fournisseur devient instable.
Avec AIHubMix, les développeurs peuvent accéder à plusieurs fournisseurs via une API, réessayer automatiquement le même modèle à travers les canaux disponibles et configurer des modèles de secours pour une couche de protection supplémentaire.
Explorez les modèles et fournisseurs disponibles sur aihubmix.com/models.
FAQ
Qu'est-ce que la bascule multi-fournisseurs ?
Elle réessaie automatiquement le même modèle via un autre fournisseur éligible lorsque la route actuelle retourne un échec réessayable.
En quoi la bascule de modèle est-elle différente ?
La bascule fournisseur maintient le modèle inchangé. La bascule de modèle passe à un modèle de secours configuré uniquement après que tous les canaux éligibles pour le modèle principal aient échoué.
Quelles défaillances peuvent déclencher la bascule ?
Les déclencheurs typiques incluent les délais d'attente, les échecs de connexion, les réponses 5xx réessayables, les limites de taux et les erreurs de capacité temporaires avant le début d'une réponse.
La bascule garantit-elle zéro temps d'arrêt ?
Non. Les échecs de fournisseur corrélés, les incidents au niveau de la passerelle, les erreurs non réessayables et les échecs après le début du streaming peuvent encore atteindre le client.
Dois-je changer le code de mon application ?
Aucune logique de routage supplémentaire n'est requise. Les applications continuent d'utiliser le point de terminaison compatible OpenAI d'AIHubMix, tandis que des modèles de secours peuvent être configurés au niveau de la clé API.