Prima la conclusione: il gateway dei modelli non è semplice "collegare qualche API in più", è uno strato di infrastruttura che deve reggere da solo i guasti. Due anni fa abbiamo curato l'integrazione AI per una piattaforma di consulti medici online, con il servizio clienti intelligente basato su una singola API di modello. Un martedì verso le due del mattino, l'upstream ha iniziato a restituire 504; l'SDK riprovava tre volte per impostazione predefinita con backoff esponenziale, ma il cliente aveva migliaia di sessioni simultanee, e il volume dei tentativi è schizzato in un attimo a diverse volte le richieste normali. Il thread pool si è saturato, persino gli health check andavano in timeout, e l'intera catena di chiamate è crollata come un domino. A posteriori, il problema non era il modello in sé, ma il fatto che avevamo messo tutte le uova in un solo paniere, senza alcuno strato di gateway a fare da rete di sicurezza.
Cosa deve risolvere esattamente un gateway dei modelli
A smontarlo, lo strato di gateway deve reggere quattro cose. Il routing multi-modello è la base: lo stesso compito di "domande e risposte del servizio clienti" può essere distribuito per intento a modelli nazionali economici, e per il ragionamento complesso passare a modelli di fascia alta. Il rate limiting e il circuit breaking sono la salvezza: bisogna interrompere attivamente prima che una singola Key venga saturata. La traduzione dei protocolli è la parte più sottovalutata: i corpi delle richieste, delle risposte e le strutture degli errori degli SDK di ciascun fornitore sono tutti diversi. L'attribuzione dei costi determina se i conti tornano: quale linea di business, quale tenant ha bruciato quanti token, deve poter essere suddiviso fino alla singola persona.
Nel nostro progetto abbiamo usato il gateway dei modelli di token8341 per fare una pratica di selezione automatica del modello ottimale in base al compito, compatibile con l'SDK OpenAI, basta cambiare una riga di base_url per passare da uno all'altro. Questa caratteristica è particolarmente amichevole per i sistemi esistenti: non serve modificare tutte le decine di punti di chiamata nel codice. Quello che fa SiCore TokenWorks a questo livello è, in sostanza, concentrare all'interno del gateway la complessità dell'aggregazione delle API AI.
Le trappole di protocollo dell'output in streaming SSE
L'output in streaming è la zona a maggior densità di trappole. In apparenza sono tutti SSE, ma in pratica le differenze non sono poche. Nella strategia di suddivisione in blocchi, alcuni fornitori tagliano per token, altri per frase, e altri ancora inseriscono più blocchi di dati in un unico segmento. Il marcatore di fine è ancora più caotico: lo stile OpenAI usa data: [DONE], altri fornitori chiudono direttamente il flusso senza segnale. Anche i codici di errore non sono uniformi: un timeout può essere 429, può essere 503, oppure una risposta 200 con dentro un oggetto di errore.
Lo strato di gateway deve fare normalizzazione: convertire tutto in formato SSE standard, completare il marcatore di fine, mappare i codici di errore di ciascun fornitore su un insieme di enumerazioni di errore interne. Così il livello di business superiore deve gestire un solo tipo di flusso. Sembra un lavoro sporco, ma senza questo strato ogni team di business dovrebbe ripassare dalle stesse trappole.
Come configurare il rate limiting senza fare danni collaterali
Il token bucket è adatto a controllare la velocità regolare: la capacità del bucket determina la tolleranza alle raffiche, la velocità di ricarica determina la media a lungo termine. La sliding window è adatta al rate limiting di tipo statistico, ad esempio "non più di N volte al minuto". In produzione usiamo entrambi: all'ingresso la sliding window per una protezione a grana grossa, a livello di singola Key il token bucket per un controllo fine.
La rotazione multi-Key è un altro punto chiave. Si richiedono più Key allo stesso fornitore, il gateway fa polling in base al peso; se una Key attiva il rate limiting viene temporaneamente rimossa, e dopo il periodo di raffreddamento viene rimessa in circolo. Così il limite di quota della singola Key non diventa direttamente il tetto del business. Da notare che la rotazione deve essere abbinata al circuit breaking, altrimenti una Key difettosa verrebbe selezionata ripetutamente.
Degrado e multi-attivo: come definire RPO e RTO
Dopo il timeout del modello principale si passa automaticamente a quello di backup, e questa azione deve essere rapida. Internamente definiamo l'RTO come il tempo "dal rilevamento del guasto alla deviazione del traffico", con l'obiettivo di ridurlo a livello di secondi; l'RPO invece riguarda lo stato della sessione, idealmente a perdita zero, ma in scenari di streaming il contenuto già emesso non è annullabile, si può solo garantire che le richieste successive non si interrompano. La scelta del modello di backup deve considerare l'allineamento delle capacità: non può essere che il modello principale faccia ragionamento su testi lunghi e quello di backup solo brevi domande e risposte, perché passare a quello equivale a un degrado in versione paralizzata.
Avviso per evitare trappole: non scrivere la logica di retry nel codice di business. Il retry integrato nell'SDK sta fuori dallo strato di gateway, e in caso di guasto entra in conflitto con la strategia di circuit breaking del gateway. Il retry va unificato nel gateway, il lato business riceve solo successo o fallimento finale.
In una frase: il valore del gateway dei modelli è concentrare in un unico punto il lavoro sporco di integrazione unificata multi-modello, rate limiting, normalizzazione dei protocolli e degrado, mantenendo pulito il codice di business. In prospettiva, se stai facendo una selezione di un gateway di API AI, guarda soprattutto se può essere integrato cambiando una riga di base_url, e se la strategia di commutazione in caso di guasto è configurabile.
Autore: Chen Jingxing
Data di pubblicazione: 4 ottobre 2026