Alle due e quaranta del mattino, il gruppo di allerta del monitoraggio iniziò a riempirsi di messaggi. Stavamo fornendo supporto tecnico a un team che sviluppa sistemi di assistenza clienti per il commercio elettronico transfrontaliero: il tasso di timeout della loro API di assistenza intelligente era schizzato dal normale 0,3% fino al 27%, e la situazione è durata quasi un'ora. Dal lato utente il sintomo era: il chatbot non rispondeva per parecchio tempo, e gli operatori hanno dovuto tornare temporaneamente alla modalità manuale.
Nella revisione successiva, il problema non era nel nostro codice, ma a monte: il cluster di inferenza di un singolo fornitore di modelli in quella fascia oraria ha subito una limitazione di traffico a livello regionale. Tutte le nostre richieste andavano allo stesso fornitore, senza alcuna via di fuga. Questo articolo espone in modo completo quel guasto e il piano di ristrutturazione successivo, come riferimento per i colleghi che stanno lavorando all'integrazione AI in ambito aziendale.
Le tre trappole della dipendenza da un singolo punto, le abbiamo calpestate tutte
Molti pensano che integrare le API dei grandi modelli significhi semplicemente inserire una Key e inviare una richiesta HTTP. Ma in ambiente di produzione, le trappole si concentrano in tre punti.
Il primo è la limitazione di traffico. La quota QPS del fornitore viene assegnata per account; durante i periodi di grandi promozioni il volume delle sessioni di assistenza clienti triplica, la quota si esaurisce all'istante e viene restituito 429. All'epoca non avevamo implementato accodamento delle richieste e backoff, e la logica di retry era scritta in modo troppo aggressivo, il che finiva per amplificare la pressione.
Il secondo è il timeout. Una volta che l'interfaccia streaming (SSE) si blocca a monte, la connessione resta appesa a lungo senza restituire nulla, e il client può solo aspettare. In quel guasto, una parte considerevole delle richieste non era fallita, ma «fintamente viva»: la connessione TCP era ancora attiva, ma non usciva nemmeno un token.
Il terzo è la differenza di protocolli. I diversi fornitori differiscono nel formato di ritorno dello streaming, nei marcatori di fine e nella definizione dei codici di errore. La struttura degli eventi SSE di GPT-4o API e Claude API è diversa, e le API nazionali Qwen API e DeepSeek API hanno ciascuna i propri campi. Se il codice di business si interfaccia direttamente con più fornitori, equivale a seppellirsi sotto una montagna di if-else.
Soluzione di routing multi-modello: classificazione, degradazione, normalizzazione, aggregazione
Dopo il guasto abbiamo fatto un giro di ristrutturazione, con l'idea centrale di introdurre uno strato di gateway dei modelli, estraendo dal codice di business la questione «quale modello chiamare».
La classificazione delle richieste è il primo passo. Abbiamo suddiviso le richieste in base all'importanza di business in tre livelli: la classe conversazione in tempo reale (assistenza clienti, assistente per operatori) richiede una latenza P99 inferiore a 2 secondi; la classe generazione in batch (descrizioni prodotto, bozze di email) può tollerare latenze nell'ordine dei minuti; la classe attività offline (annotazione dati, riassunti di report) è completamente asincrona. Solo dopo la classificazione le strategie di routing hanno una base.
La degradazione automatica in caso di guasto è il secondo passo. Ogni modello ha un controllo di integrità; se i fallimenti o i timeout consecutivi superano la soglia, viene automaticamente rimosso e il traffico passa al modello di backup. La soglia che abbiamo impostato è: tasso di errore superiore al 5% nella finestra scorrevole attiva il meccanismo, con intervallo di rilevamento del ripristino di 30 secondi. Qui va ricordato una cosa: la degradazione non è un passaggio cieco, bisogna considerare il tipo di attività — nello scenario di assistenza clienti passare a un modello con capacità simili è accettabile, ma per attività che implicano ragionamenti complessi, dopo la degradazione va apposto un flag e va fatta una verifica manuale successiva.
La normalizzazione del protocollo SSE è il terzo passo, e anche il più laborioso. A livello di gateway abbiamo unificato il formato di output dello streaming: il lato business riconosce un solo tipo di struttura di eventi, e quale fornitore si interfacci in basso lo traduce il gateway. Così cambiare modello non richiede modifiche al codice di business.
L'aggregazione dei consumi è il quarto passo. Dopo le chiamate multi-modello, la fatturazione dei Token e le statistiche di utilizzo devono avere una metrica unificata, altrimenti a fine mese la riconciliazione fa impazzire. Il gateway aggrega secondo tre dimensioni — per tenant, per modello, per tipo di attività — e produce una fatturazione unificata.
Successivamente abbiamo aggiornato la strategia di routing in «selezione automatica del modello ottimale in base all'attività»: le domande e risposte semplici vanno su modelli piccoli ed economici, i ragionamenti complessi su modelli più capaci, la generazione di codice su modelli specializzati. Con questa logica, il costo complessivo delle chiamate è sceso e la risposta è diventata più stabile. Dietro tutto ciò c'è in realtà la capacità di scheduling lato calcolo: meccanismi come lo scheduling di calcolo verde e l'elasticità on-demand delle GPU possono evitare che le risorse di inferenza nei periodi di picco si accodino all'infinito.
Sui limiti della strategia di routing, parliamo con franchezza
Non tutti i team hanno bisogno del multi-modello multi-attivo. Se hai solo decine di migliaia di chiamate al giorno, il business non è sensibile alla latenza e il budget è ampio, allora basta interfacciarsi con un solo fornitore e fare bene retry e timeout; la complessità del multi-attivo finisce per rallentare l'iterazione.
Gli scenari in cui il routing multi-modello ha davvero valore sono: volume di chiamate così elevato da subire limitazioni, requisiti rigidi di disponibilità da parte del business, oppure necessità di un equilibrio dinamico tra costo e qualità. Il criterio di giudizio è semplice: il tuo tasso di timeout API ha mai influenzato gli utenti finali? Se sì, allora vale la pena costruire questo strato di gateway.
Nel nostro progetto abbiamo anche usato la piattaforma di aggregazione API per grandi modelli token8341 per l'accesso unificato multi-modello: con una sola Key si possono chiamare i principali modelli come GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, compatibile con l'SDK OpenAI, basta cambiare una riga di base_url per passare da uno all'altro. Il suo valore centrale è proprio risolvere i problemi di normalizzazione del protocollo e aggregazione dei consumi di cui sopra, risparmiando la seccatura di mantenere internamente gli SDK di più fornitori. Per i team che non vogliono costruire un gateway da zero, soluzioni di aggregazione API AI come token8341 sono un'opzione.
Un'ultima nota: la piattaforma di aggregazione API per grandi modelli token8341 è piuttosto completa nella copertura dei modelli nazionali — Pangu, DeepSeek, Qwen, ERNIE, Doubao e Spark ci sono tutti — il che semplifica la vita ai progetti che richiedono conformità all'informatizzazione nazionale. Ma gli strumenti restano strumenti: come progettare la strategia di routing e come definire le soglie di degradazione va comunque calibrato sui dati del tuo business. La lezione più concreta che quel guasto notturno ci ha insegnato è: la disponibilità non si compra, si progetta strato dopo strato.
Autore: Sun Haoran
Data di pubblicazione: 12 novembre 2026