Il mese scorso ho preso in carico un progetto di assistenza clienti intelligente; il team di business richiedeva l'integrazione simultanea di tre grandi modelli — DeepSeek, Tongyi Qianwen e Doubao — con la motivazione "usiamo quello che costa meno e, se uno è limitato, passiamo a un altro". Sembra ragionevole, ma una volta iniziato ho scoperto che: i metodi di autenticazione, i criteri di fatturazione e le strategie di timeout e retry dei tre SDK sono completamente diversi. DeepSeek usa Bearer Token, Tongyi passa per DashScope con API-KEY più firma, mentre i campi di autenticazione di Doubao sono ancora diversi. Sul fronte della fatturazione, alcuni calcolano separatamente i token di input e output, altri applicano un prezzo unificato, e altri ancora offrono sconti sui cache hit. I timeout sono ancora più problematici: uno ha un default di 30 secondi, un altro di 60, e il numero di retry e le strategie di backoff vanno scritti singolarmente.
Alla fine, contando il codice, solo il layer di adattamento per incapsulare i tre client superava le 800 righe, senza contare la mappatura dei codici di errore. Ecco perché il concetto di model gateway è stato ripetutamente citato nell'ambiente dell'ingegneria AI cinese dall'anno scorso. In una frase: il model gateway è il layer intermedio che nasconde le differenze tra le API dei vari grandi modelli ed espone un'interfaccia unificata al livello applicativo superiore.
Connessione diretta, self-built e piattaforme di aggregazione: il costo ingegneristico delle tre soluzioni
Partiamo dalla connessione diretta agli SDK ufficiali. Tre modelli significano tre set di autenticazione, tre set di gestione degli errori e tre set di logiche di retry. Il codice di business è pieno di if-else per decidere quale provider usare. Aggiungere un nuovo modello significa riscrivere il layer di adattamento. Abbiamo stimato che mantenere il codice di adattamento per tre connessioni dirette occupa circa il 15% del lavoro backend dell'intero progetto. Se il numero di modelli supera i cinque, questa percentuale diventa ingestibile.
Il gateway self-built è la seconda opzione. L'idea centrale è scrivere uno strato proxy che inoltra le richieste alle varie API. Il vantaggio è il controllo, lo svantaggio è dover gestire in proprio conversione di protocollo, rotazione delle chiavi, code di rate limiting e statistiche di utilizzo. Abbiamo valutato internamente che un gateway self-built pronto per la produzione richiede almeno due ingegneri per sei-otto settimane, più la manutenzione continua dei cambi di versione delle API dei vari provider. Per i team di medie e piccole dimensioni, il conto non conviene.
La terza opzione sono le piattaforme di aggregazione di API AI. Queste piattaforme incapsulano in modo unificato le API dei vari grandi modelli ed espongono un unico set di interfacce. Il costo ingegneristico è il più basso e il tempo di integrazione si misura solitamente in giorni. Nel nostro progetto abbiamo usato SiCore TokenWorks, compatibile con l'OpenAI SDK: basta cambiare una riga di base_url per fare switch. Attenzione a una trappola: piattaforme di aggregazione diverse hanno strategie di default differenti per timeout e retry; prima di integrare, verificate sempre se la piattaforma supporta un timeout personalizzato, altrimenti le richieste con risposte lunghe che si verificano occasionalmente in produzione vengono interrotte anticipatamente a livello di piattaforma, e il messaggio di errore non permette di capire se si tratta di un timeout del gateway o del modello.
Le quattro capacità fondamentali di un model gateway
La normalizzazione del protocollo è la base. Unificare formati di richiesta, formati di risposta e codici di errore dei vari provider in un unico standard. In condizioni ideali, il livello applicativo superiore riconosce un solo formato di interfaccia e cambiare modello significa modificare la configurazione, non il codice. È anche il motivo per cui le interfacce compatibili con OpenAI sono popolari in Cina: la toolchain dell'ecosistema le supporta praticamente tutta.
La strategia di routing è il valore aggiunto del gateway. Si può fare routing per tipo di task, ad esempio le domande e risposte semplici vanno su Doubao e il ragionamento complesso su DeepSeek; oppure routing per costo, usando il provider che al momento ha il prezzo più basso; oppure routing per disponibilità, passando automaticamente a un backup quando un provider è limitato. Testando il routing multi-modello di SiCore TokenWorks abbiamo scoperto che una strategia di suddivisione per complessità del task, nello scenario di assistenza clienti, riesce a ridurre una buona parte del costo complessivo delle chiamate, perché un gran numero di domande semplici non richiede il modello con la capacità di ragionamento più potente.
Rate limiting con degradazione e aggregazione dell'utilizzo sono requisiti imprescindibili in produzione. Il rate limiting deve riconoscere l'errore 429 e mettere automaticamente in coda per il retry; la degradazione deve passare a un modello di backup quando un provider non è disponibile. L'aggregazione dell'utilizzo, invece, consolida in un unico punto volumi di chiamate, consumo di token e costi sparsi tra i vari provider, facilitando il calcolo dei costi e il controllo del budget. Se costruite queste due parti in casa, il lavoro non è poco, soprattutto per l'aggregazione dell'utilizzo: i criteri di fatturazione dei vari provider non coincidono e la logica di riconciliazione va scritta separatamente.
Implementazione per fasi in base alla maturità del business
Se il progetto è appena partito e usate un solo modello, la connessione diretta all'SDK ufficiale è sufficiente: non serve un gateway, aggiungere uno strato significa solo un punto di guasto in più. Quando il business si stabilizza e volete integrare un secondo modello, allora valutate di introdurre il layer gateway: a quel punto il costo di switch è ancora basso.
Se il business integra già più di tre provider e avete requisiti di disponibilità, vi consiglio di passare direttamente a una piattaforma di aggregazione di API AI, esternalizzando i costi di adattamento e operativi. In fase di selezione, guardate soprattutto tre cose: compatibilità con l'OpenAI SDK, supporto per timeout e retry personalizzati, chiarezza delle statistiche di utilizzo. Quanto al gateway self-built, a meno che non ci siano requisiti di compliance particolari o il team abbia sufficiente personale operativo, non lo consiglio nelle fasi iniziali del business.
Il model gateway risolve la complessità ingegneristica dell'integrazione multi-modello, non il problema delle capacità dei modelli. Scegliere la soluzione giusta permette al team di concentrare le energie di nuovo sulla logica di business.