El 4 de agosto de 2026, la página de estado oficial de DeepSeek registró dos incidentes de rendimiento degradado en la API.
El primer incidente duró 1 hora y 18 minutos, de 02:02 a 03:20 UTC, y afectó a DeepSeek V4 Flash, V4 Pro y al modo experto. El segundo incidente duró 36 minutos, de 03:43 a 04:20 UTC, y afectó a la API de DeepSeek V4 Flash.
Ambos incidentes ya se han resuelto. OpenCode también informó de que DeepSeek Flash tenía problemas de capacidad debido a una demanda sin precedentes. Sin embargo, la página de estado oficial de DeepSeek solo confirmó un rendimiento degradado y no publicó la causa raíz.
Resumen
- La página de estado oficial de DeepSeek registró dos incidentes de rendimiento degradado que afectaron a V4 Flash el 4 de agosto de 2026.
- Una integración directa con un solo proveedor crea un punto único de fallo, incluso cuando el mismo modelo está disponible en otros lugares.
- AIHubMix puede reintentar el mismo modelo a través de varios canales de proveedores cuando una ruta upstream devuelve un error reintentable.
- Si fallan todos los canales de proveedores del modelo principal, la alternativa de modelo a nivel de clave puede dirigir la solicitud a modelos de respaldo configurados.
- El enrutamiento entre varios proveedores reduce la dependencia de un solo endpoint, pero no puede eliminar los fallos correlacionados ni los riesgos a nivel de la pasarela.
Incidentes como este ponen de relieve un principio importante de infraestructura:
Un modelo fiable no basta si se accede a él a través de un único endpoint de proveedor.
Un modelo no tiene por qué significar un solo proveedor
Cuando una aplicación se conecta directamente a un solo proveedor, ese endpoint se convierte en un punto único de fallo.
Si el proveedor sufre una caída, alcanza su límite de tasa o registra un pico de latencia, la aplicación no tiene a dónde más enviar la solicitud. Los usuarios ven tiempos de espera y errores, aunque el mismo modelo siga disponible a través de otras infraestructuras de proveedores.
AIHubMix separa el modelo del proveedor que lo sirve.
Por ejemplo, DeepSeek V4 Flash está disponible a través de varios proveedores en AIHubMix, entre ellos DeepSeek, Baidu, DeepInfra y Alibaba Cloud. Las aplicaciones siguen usando un único endpoint de API compatible con OpenAI mientras AIHubMix gestiona las rutas upstream disponibles.
Esto crea dos capas de fiabilidad diferenciadas.
Capa 1: conmutación por error de proveedor
La conmutación por error de proveedor mantiene sin cambios el modelo solicitado mientras cambia el proveedor de infraestructura que lo sirve.
Cuando una solicitud para DeepSeek V4 Flash llega a AIHubMix, la pasarela selecciona un canal de proveedor elegible. Si ese canal devuelve un error reintentable antes de que comience la respuesta, AIHubMix puede probar otro canal disponible para el mismo modelo.
La ruta de la solicitud podría ser así:
- Probar DeepSeek V4 Flash a través del Proveedor A.
- El Proveedor A devuelve un tiempo de espera agotado, un error 5xx o un error reintentable por capacidad.
- Probar el mismo modelo DeepSeek V4 Flash a través del Proveedor B.
- Continuar hasta que la solicitud tenga éxito o se agoten todos los canales elegibles.
El cliente no necesita integrar varios SDK de proveedores, gestionar claves de API separadas ni implementar su propia lógica de reintentos.
Esto es conmutación por error a nivel de proveedor: cambia el proveedor, pero el modelo solicitado sigue siendo el mismo.
Capa 2: alternativa de modelo
La conmutación por error de proveedor no sirve de nada si todos los proveedores disponibles para el modelo principal están caídos.
Por ello, AIHubMix ofrece una segunda capa de fiabilidad: la alternativa de modelo.
Los usuarios pueden configurar una lista ordenada de modelos de respaldo para cada clave de API. Una vez que todos los canales elegibles del modelo principal han devuelto un fallo reintentable, AIHubMix pasa al siguiente modelo de la lista de alternativas.
Por ejemplo:
- Principal:
deepseek-v4-flash - Primera alternativa:
gpt-5.4 - Segunda alternativa:
gemini-3.1-pro-preview
La alternativa se ejecuta dentro de la pasarela de AIHubMix. Las aplicaciones existentes no necesitan enviar parámetros de enrutamiento adicionales ni cambiar su código de cliente.
La facturación se basa en el modelo que finalmente devuelve la respuesta correcta. Los desarrolladores pueden verificar el comportamiento de la alternativa a través de las cabeceras de respuesta:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
La configuración completa y las reglas de activación están documentadas en AIHubMix Model Mapping and Fallback.
Qué puede gestionar la conmutación automática
La conmutación por error de proveedor está diseñada para recuperarse de problemas de infraestructura upstream como:
- Tiempos de espera de proveedores
- Fallos de conexión
- Respuestas 5xx reintentables
- Límites de tasa del proveedor y errores de capacidad
- Indisponibilidad temporal de un canal upstream
Cuando estos fallos ocurren antes de que comience la respuesta, AIHubMix puede probar otra ruta de forma transparente.
Qué no puede resolver la conmutación por error
El enrutamiento entre varios proveedores mejora la disponibilidad, pero no hace que la pasarela sea infalible.
La alternativa no se activa cuando:
- La clave de API de AIHubMix del usuario no es válida, ha caducado o se ha agotado la cuota
- La solicitud en sí no es válida
- El cliente se desconecta o alcanza su propio tiempo de espera
- Una respuesta en streaming ya ha comenzado
- Se ha seleccionado explícitamente un canal de proveedor concreto
- El fallo afecta a todos los proveedores o a la propia pasarela
Los fallos de los proveedores también pueden estar correlacionados. Varios proveedores pueden depender de la misma infraestructura subyacente, de la misma publicación de modelo o de la misma red regional. Por ello, la disponibilidad de varios proveedores debe medirse con tráfico real y no suponerse solo a partir del número de proveedores.
Por qué un agregador puede ser más fiable que un endpoint directo
Llamar directamente a una API oficial da a una aplicación una única ruta hacia el modelo.
Una pasarela multiproveedor le ofrece varias.
Si esas rutas de proveedores fallan de forma independiente, la pasarela puede desviar el tráfico de un endpoint degradado sin exponer el fallo a la aplicación. Esto reduce la dependencia de cualquier proveedor individual y puede ofrecer una disponibilidad mayor que una integración directa con un solo proveedor.
La diferencia es arquitectónica:
- API directa: un modelo, un proveedor, un dominio de fallo
- AIHubMix: un modelo, varios proveedores, conmutación automática por error
- AIHubMix con alternativa de modelo: varios proveedores más modelos de respaldo
El objetivo no es predecir qué proveedor fallará a continuación. Se trata de convertir un incidente upstream en un evento de enrutamiento interno en lugar de una caída visible para el cliente.
Diseñar para el próximo incidente de un proveedor
DeepSeek V4 Flash se ha recuperado, pero las limitaciones temporales de capacidad, los límites de tasa y las caídas upstream son situaciones normales en la infraestructura de IA en producción.
Las aplicaciones no deberían tener que cambiar de código cada vez que un proveedor se vuelve inestable.
Con AIHubMix, los desarrolladores pueden acceder a varios proveedores a través de una sola API, reintentar automáticamente el mismo modelo en los canales disponibles y configurar modelos de respaldo para una capa adicional de protección.
Explora los modelos y proveedores disponibles en aihubmix.com/models.
Preguntas frecuentes
¿Qué es la conmutación por error entre varios proveedores?
Reintenta automáticamente el mismo modelo a través de otro proveedor elegible cuando la ruta actual devuelve un fallo reintentable.
¿En qué se diferencia la alternativa de modelo?
La conmutación por error de proveedor mantiene el modelo sin cambios. La alternativa de modelo cambia a un modelo de respaldo configurado solo después de que fallen todos los canales elegibles del modelo principal.
¿Qué fallos pueden activar la conmutación por error?
Los desencadenantes habituales incluyen tiempos de espera, fallos de conexión, respuestas 5xx reintentables, límites de tasa y errores temporales de capacidad antes de que comience una respuesta.
¿La conmutación por error garantiza cero tiempo de inactividad?
No. Los fallos correlacionados de proveedores, los incidentes a nivel de la pasarela, los errores no reintentables y los fallos después de que comience el streaming aún pueden llegar al cliente.
¿Necesito cambiar el código de mi aplicación?
No se requiere lógica de enrutamiento adicional. Las aplicaciones siguen usando el endpoint compatible con OpenAI de AIHubMix, mientras que los modelos de respaldo pueden configurarse a nivel de clave de API.
