Il 4 agosto 2026, la pagina di stato ufficiale di DeepSeek ha registrato due incidenti di prestazioni degradate dell'API.
Il primo incidente è durato 1 ora e 18 minuti, dalle 02:02 alle 03:20 UTC, e ha interessato DeepSeek V4 Flash, V4 Pro e la Modalità Esperto. Il secondo incidente è durato 36 minuti, dalle 03:43 alle 04:20 UTC, e ha interessato l'API di DeepSeek V4 Flash.
Entrambi gli incidenti sono stati risolti. OpenCode ha anche riportato che DeepSeek Flash stava affrontando problemi di capacità a causa di una domanda senza precedenti. Tuttavia, la pagina di stato ufficiale di DeepSeek ha confermato solo prestazioni degradate e non ha pubblicato una causa principale.
TL;DR
- La pagina di stato ufficiale di DeepSeek ha registrato due incidenti di prestazioni degradate che hanno interessato V4 Flash il 4 agosto 2026.
- Un'integrazione diretta con il provider crea un singolo punto di guasto, anche quando lo stesso modello è disponibile altrove.
- AIHubMix può riprovare lo stesso modello attraverso più canali di provider quando un percorso a monte restituisce un errore ripetibile.
- Se tutti i canali del provider per il modello principale falliscono, il fallback del modello a livello di chiave può cambiare la richiesta ai modelli di backup configurati.
- Il routing multi-provider riduce la dipendenza da un singolo endpoint, ma non può eliminare i guasti correlati o il rischio a livello di gateway.
Incidenti come questo evidenziano un importante principio infrastrutturale:
Un modello affidabile non è sufficiente se viene accesso tramite un singolo endpoint del provider.
Un modello non deve significare un solo provider
Quando un'applicazione si connette direttamente a un provider, quell'endpoint diventa un singolo punto di guasto.
Se il provider subisce un'interruzione, raggiunge il suo limite di velocità o subisce un picco di latenza, l'applicazione non ha altro posto dove inviare la richiesta. Gli utenti vedono timeout ed errori anche quando lo stesso modello rimane disponibile attraverso altri provider infrastrutturali.
AIHubMix separa il modello dal provider che lo serve.
Ad esempio, DeepSeek V4 Flash è disponibile attraverso più provider su AIHubMix, tra cui DeepSeek, Baidu, DeepInfra e Alibaba Cloud. Le applicazioni continuano a utilizzare un endpoint API compatibile con OpenAI mentre AIHubMix gestisce i percorsi a monte disponibili.
Questo crea due distinti livelli di affidabilità.
Livello 1: Failover del provider
Il failover del provider mantiene il modello richiesto invariato mentre cambia il provider infrastrutturale dietro di esso.
Quando una richiesta per DeepSeek V4 Flash raggiunge AIHubMix, il gateway seleziona un canale provider idoneo. Se quel canale restituisce un errore ripetibile prima che inizi la risposta, AIHubMix può provare un altro canale disponibile per lo stesso modello.
Il percorso della richiesta può apparire così:
- Prova DeepSeek V4 Flash attraverso il Provider A.
- Il Provider A restituisce un timeout, un errore 5xx o un errore di capacità ripetibile.
- Prova lo stesso modello DeepSeek V4 Flash attraverso il Provider B.
- Continua fino a quando la richiesta non ha successo o tutti i canali idonei sono esauriti.
Il cliente non ha bisogno di integrare più SDK di provider, gestire chiavi API separate o implementare la propria logica di ripetizione.
Questo è il failover a livello di provider: il provider cambia, ma il modello richiesto rimane lo stesso.
Livello 2: Fallback del modello
Un failover del provider non può aiutare se ogni provider disponibile per il modello principale è non disponibile.
AIHubMix supporta quindi un secondo livello di affidabilità: il fallback del modello.
Gli utenti possono configurare un elenco ordinato di modelli di backup per ogni chiave API. Dopo che ogni canale idoneo per il modello principale ha restituito un errore ripetibile, AIHubMix passa al modello successivo nell'elenco di fallback.
Ad esempio:
- Primario:
deepseek-v4-flash - Primo fallback:
gpt-5.4 - Secondo fallback:
gemini-3.1-pro-preview
Il fallback viene eseguito all'interno del gateway AIHubMix. Le applicazioni esistenti non hanno bisogno di inviare parametri di routing aggiuntivi o modificare il loro codice client.
La fatturazione si basa sul modello che alla fine restituisce la risposta di successo. Gli sviluppatori possono verificare il comportamento di fallback attraverso le intestazioni della risposta:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
La configurazione completa e le regole di attivazione sono documentate in AIHubMix Model Mapping and Fallback.
Cosa può gestire il failover automatico
Il failover del provider è progettato per recuperare da problemi infrastrutturali a monte come:
- Timeout del provider
- Guasti di connessione
- Risposte 5xx ripetibili
- Limiti di velocità e errori di capacità del provider
- Inaccessibilità temporanea di un canale a monte
Quando si verificano questi guasti prima che inizi la risposta, AIHubMix può provare trasparentemente un altro percorso.
Cosa non può risolvere il failover
Il routing multi-provider migliora la disponibilità, ma non rende un gateway infallibile.
Il fallback non viene attivato quando:
- La chiave API di AIHubMix dell'utente è non valida, scaduta o esaurita
- La richiesta stessa è non valida
- Il client si disconnette o raggiunge il proprio timeout
- Una risposta in streaming è già iniziata
- Un canale specifico del provider è stato selezionato esplicitamente
- Il guasto interessa ogni provider o il gateway stesso
I guasti del provider possono anche essere correlati. Più provider possono dipendere dalla stessa infrastruttura sottostante, rilascio del modello o rete regionale. Per questo motivo, la disponibilità multi-provider dovrebbe essere misurata con traffico reale piuttosto che assunta dal numero di provider da solo.
Perché un aggregatore può essere più affidabile di un endpoint diretto
Chiamare direttamente un'API ufficiale fornisce a un'applicazione un percorso verso il modello.
Un gateway multi-provider ne fornisce diversi.
Se quei percorsi del provider falliscono in modo indipendente, il gateway può deviare da un endpoint degradato senza esporre il guasto all'applicazione. Questo riduce la dipendenza da qualsiasi singolo provider e può offrire una disponibilità superiore rispetto a un'integrazione diretta con un singolo provider.
La differenza è architettonica:
- API diretta: un modello, un provider, un dominio di guasto
- AIHubMix: un modello, più provider, failover automatico
- AIHubMix con fallback del modello: più provider più modelli di backup
Lo scopo non è prevedere quale provider fallirà per primo. È rendere un incidente a monte un evento di routing interno invece di un'interruzione visibile al cliente.
Costruisci per il prossimo incidente del provider
DeepSeek V4 Flash si è ripreso, ma le limitazioni temporanee di capacità, i limiti di velocità e le interruzioni a monte sono parti normali dell'infrastruttura AI in produzione.
Le applicazioni non dovrebbero dover cambiare codice ogni volta che un provider diventa instabile.
Con AIHubMix, gli sviluppatori possono accedere a più provider attraverso un'API, riprovare automaticamente lo stesso modello attraverso i canali disponibili e configurare modelli di backup per un ulteriore livello di protezione.
Esplora i modelli e i provider disponibili su aihubmix.com/models.
FAQ
Che cos'è il failover multi-provider?
Ripete automaticamente lo stesso modello attraverso un altro provider idoneo quando il percorso attuale restituisce un errore ripetibile.
In cosa è diverso il fallback del modello?
Il failover del provider mantiene il modello invariato. Il fallback del modello passa a un modello di backup configurato solo dopo che tutti i canali idonei per il modello principale sono falliti.
Quali guasti possono attivare il failover?
I trigger tipici includono timeout, guasti di connessione, risposte 5xx ripetibili, limiti di velocità e errori di capacità temporanei prima che inizi una risposta.
Il failover garantisce zero downtime?
No. I guasti correlati del provider, gli incidenti a livello di gateway, gli errori non ripetibili e i guasti dopo l'inizio dello streaming possono comunque raggiungere il client.
Devo cambiare il codice della mia applicazione?
Non è necessaria alcuna logica di routing aggiuntiva. Le applicazioni continuano a utilizzare l'endpoint compatibile con OpenAI di AIHubMix, mentre i modelli di backup possono essere configurati a livello di chiave API.