Prima la risposta: quale gateway multi-LLM copre lo stack completo?
Un gateway multi-LLM di produzione deve fare più che inoltrare lo stesso prompt a un modello diverso. Deve permetterti di cambiare modello senza riscrivere il client, decidere quando un’altra rotta è sicura, registrare ogni tentativo, attribuire token e costo, e fermare un loop di errore prima che diventi un incidente di budget.
Ognuno dei cinque gateway ottimizza per un diverso confine di responsabilità. Portkey attualmente offre la combinazione gestita più chiara di politiche di routing, fallback nativi, trace, budget e rate limit. LiteLLM espone una superficie di controllo altrettanto ampia per i team disposti a operare il proxy da sé. CometAPI adotta un approccio più leggero: un’unica base URL compatibile con OpenAI e il parametro model coprono un ampio catalogo hosted, mentre la sua guida ufficiale ai fallback mantiene nel codice dell’applicazione le decisioni di retry e fallback.
Confronto rapido dei gateway multi-LLM
| Gateway | Cambio modello | Fallback | Utilizzo | Log | Controlli dei costi | Miglior utilizzo |
|---|---|---|---|---|---|---|
| CometAPI | Sì — una base URL; cambia il modello | Pattern controllato dall’applicazione | Dati di utilizzo nella risposta più query di quota e utilizzo giornaliero | Log delle richieste e dashboard | Quote per chiave e limiti di output a livello di richiesta | Accesso hosted a più modelli con lavoro di integrazione minimo |
| Portkey | Sì — API universale e configurazioni | Fallback prioritizzati nativi, retry e circuit breaker | Attribuzione di token e costi per richiesta | Catena dei tentativi con Config ID e Trace ID | Budget, rate limit e guardrail di policy | Instradamento gestito più osservabilità profonda |
| OpenRouter | Sì — routing per modello e provider | Fallback automatico del provider; routing dei modelli configurabile | Analytics e cronologia attività | Cronologia attività; meno tracing applicativo rispetto a Portkey | Ordinamento per prezzo, regole di prezzo massimo e limiti per chiave | Selezione dei provider in stile marketplace |
| LiteLLM | Sì — proxy compatibile con OpenAI per molti provider | Retry e fallback del router | Tracciamento di spesa e token per utente, chiave o progetto | Hook integrati e callback di logging esterni | Budget e rate limit | Controllo e personalizzazione self-hosted |
| Cloudflare AI Gateway | Sì — route unificate e dinamiche | Nodi di fallback nelle route dinamiche | Dashboard di analytics | Log di richieste persistenti | Limiti di spesa, rate limit e fallback a modelli più economici | Operazioni edge nativamente Cloudflare |
Evidenze: Cambio modello su CometAPI, query di utilizzo e quota e pattern di fallback; Gateway Portkey, fallback e gestione dei costi; Routing dei provider su OpenRouter e analytics di utilizzo; Proxy e router LiteLLM; Funzionalità di Cloudflare AI Gateway, routing dinamico e limiti di spesa.
Il fallback controllato dall’applicazione funziona in produzione. La guida di CometAPI documenta un pattern funzionante, ma implica che la logica di retry, lo stato del circuit breaker e i budget per rotta vivano nel tuo codebase e debbano essere reimplementati per ogni servizio, invece di essere configurati una volta nel gateway e applicati a tutti i client.
Le 5 capacità che un gateway LLM di produzione deve avere
Cambio di modello
Il cambio di modello mantiene un contratto client stabile — tipicamente un endpoint /chat/completions compatibile con OpenAI — e seleziona il modello tramite configurazione, policy o parametro per richiesta, così puoi cambiare modello senza aggiornare ogni client.
Tutti e cinque i gateway lo supportano, ma la superficie di controllo differisce: CometAPI e OpenRouter usano un endpoint hosted con un campo model; Portkey aggiunge routing guidato da config; LiteLLM mappa alias in una configurazione self-hosted; Cloudflare vincola la selezione a una route edge.
Routing di fallback
Il routing di fallback è una sequenza ordinata di modelli o provider provati quando la rotta primaria fallisce, con una distinzione critica: ritentare su errori di connessione, timeout, 408, 429 e 5xx temporanei; fallire immediatamente su 400, 401, 403 e 404 di modello sconosciuto, così la misconfigurazione non si nasconde come un fallback costoso.
Portkey, LiteLLM, OpenRouter e Cloudflare espongono configurazioni di fallback lato gateway; il pattern documentato di CometAPI mantiene la sequenza nel codice dell’applicazione.
Tracciamento dell’utilizzo
Il tracciamento dell’utilizzo cattura token di prompt, token di output, conteggi delle richieste e attribuzione del modello per ogni chiamata — non solo quelle riuscite — ed è ciò che rende possibile la contabilità dei costi e la fatturazione per tenant. Senza dati per tentativo, un picco di costo potrebbe derivare da traffico legittimo, da un loop di retry o da un fallback verso un modello più caro; e i tentativi falliti che hanno consumato token parziali sono comunque fatturati a monte.
Portkey e LiteLLM offrono attribuzione a livello di richiesta e di tentativo; CometAPI restituisce l’utilizzo per risposta più un endpoint di query delle quote; OpenRouter e Cloudflare forniscono dashboard di analytics.
Log e trace
Log e trace registrano ogni tentativo — latenza, codice di stato, decisione di routing, modello e provider — sotto un unico ID di richiesta, così una catena di fallback è debuggabile end-to-end. Una risposta finale 200 da sola non prova nulla: se i tentativi falliti non sono registrati sotto lo stesso ID, un loop di fallback silente può durare settimane prima di emergere nel report dei costi.
Portkey offre il tracing più profondo con Config ID e Trace ID per tentativo; LiteLLM supporta hook di logging e callback; l’Activity history di OpenRouter copre l’utilizzo ma con meno tracing end-to-end; Cloudflare e CometAPI forniscono log e dashboard delle richieste.
Controllo dei costi
Il controllo dei costi significa guardrail di spesa applicabili — budget, quote, rate limit, regole di prezzo massimo o cap per tenant — che fermano un loop di errore prima che diventi un incidente di budget. Una dashboard di utilizzo senza limiti è reporting, non controllo: un retry mal configurato senza backoff può moltiplicare una richiesta in centinaia di tentativi fatturabili, e un fallback silente verso un modello 10× più caro può raddoppiare la spesa mensile in un pomeriggio.
Portkey supporta budget e guardrail di policy; LiteLLM applica limiti per chiave e per modello; OpenRouter offre regole di prezzo massimo; Cloudflare fornisce limiti di spesa sulle route edge; CometAPI applica quote per chiave e limiti di output.
I migliori gateway multi-LLM nel 2026
CometAPI
Scegli CometAPI quando l’integrazione semplice conta di più. La rotta compatibile con OpenAI usa https://api.cometapi.com/v1, e lo stesso client può selezionare un altro modello del catalogo cambiando il campo model. La API pubblica della directory dei modelli offre anche ai team un modo machine-readable per validare gli ID modello, le capacità, i prezzi e gli endpoint prima della messa in produzione. Il compromesso è che la policy di retry e fallback resta una tua responsabilità.
Portkey
Scegli Portkey quando policy e osservabilità devono essere gestite insieme. Il gateway documentato supporta routing condizionale, fallback, retry, circuit breaker, bilanciamento del carico, budget e visibilità a livello di tentativo nei trace. Questo riduce il codice del control plane personalizzato, sebbene tu debba comunque testare i comportamenti specifici del provider.
OpenRouter
Scegli OpenRouter quando il routing orientato al marketplace dei provider è il requisito principale. Ordinamento dei provider, preferenze di prezzo o latenza, compatibilità dei parametri e fallback automatico del provider sono controlli di prima classe. La vista Activity è utile per la cronologia di utilizzo, ma i team che necessitano di trace applicativi end-to-end possono ancora affiancare un altro livello di osservabilità.
LiteLLM
Scegli LiteLLM quando vuoi possedere il gateway. Il suo proxy e router espongono fallback, budget, tracciamento della spesa e callback di logging su molti provider. Il vantaggio è il controllo; il costo è operare il proxy, lo storage, gli aggiornamenti, i segreti e la configurazione di policy.
Cloudflare AI Gateway
Cloudflare AI Gateway è particolarmente interessante per i team che già usano l’infrastruttura Cloudflare. Il sistema di Dynamic Routing attuale può instradare le richieste in base a condizioni, applicare rate o limiti di budget e inviare le richieste fallite o oltre i limiti a modelli di fallback. I team dovrebbero comunque verificare l’API supportata e il percorso di autenticazione per la loro distribuzione prima di standardizzarvi.
Come confrontare in pratica i gateway multi-LLM
Per una panoramica più ampia della piattaforma, vedi il confronto dei gateway AI di CometAPI. Questo articolo resta più stretto: se ciascuna opzione può cambiare modello, osservare, fare failover e controllare i costi in un unico workflow di produzione.
Come testare i fallback dei gateway LLM
Non valutare il fallback solo leggendo una pagina di funzionalità. Esegui un test scriptato unico contro ogni gateway: una richiesta normale, una richiesta deliberatamente soggetta a rate limit, un timeout, una chiave API non valida e un ID modello non valido. Un default sicuro è ritentare o fare fallback su errori di connessione, timeout, HTTP 408, 429 e risposte 5xx temporanee. Tratta 400, 401, 403 e un 404 di modello sconosciuto come failure hard così la cattiva configurazione non si nasconde silenziosamente.
La forma di log attesa è {"request_id": "...", "model": "...", "status": 200, "latency_ms": <measured>, "usage": {...}}. Il tuo test passa solo se il gateway o l’applicazione registra anche i tentativi falliti sotto lo stesso ID di richiesta. Una risposta finale 200 da sola non può provare che il fallback abbia funzionato correttamente.
Come misurare il costo del gateway LLM
Tieni traccia del costo per tentativo, non solo per risposta finale. Per ogni rotta, calcola:
attempt cost = (input tokens × input price + output tokens × output price) / 1,000,000
Al 2 settembre 2026, la API pubblica della directory dei modelli di CometAPI elencava Gemini 3.7 Flash a $0.75 per milione di token di input e $3.75 per milione di token di output, e Claude Opus 5 a $5 e $25 rispettivamente. Con 1.000 richieste Gemini riuscite con una media di 2.000 token di input e 500 di output, il costo modellato è $3.375. Se il 5% di tali richieste viene eseguito anche su Claude Opus 5 come fallback orientato alla qualità con lo stesso volume di token, il fallback aggiunge $1.125, portando il totale modellato a $4.50 prima di qualsiasi tentativo primario parziale fatturabile.
Ecco perché una dashboard del gateway dovrebbe esporre separatamente tentativi primari, tentativi di fallback, token, latenza e costo. Riconcilia quei record con la query di quota e utilizzo giornaliero di CometAPI, non solo con il conteggio delle risposte con esito positivo.
Quale gateway multi-LLM scegliere?
- Percorso più rapido verso molti modelli hosted: CometAPI, con fallback controllato dall’applicazione.
- Politica di routing gestita più completa: Portkey.
- Marketplace dei provider e selezione automatica dei provider: OpenRouter.
- Gateway self-hosted con policy personalizzabile: LiteLLM.
- Logging, limiti e routing nativi edge: Cloudflare AI Gateway.
La decisione si riduce a una domanda: dove vivono le policy di fallback e retry? In CometAPI vivono nel tuo codice applicativo. In Portkey e OpenRouter vivono in una configurazione hosted. In LiteLLM vivono in una configurazione self-hosted che operi tu. In Cloudflare vivono in una route edge legata al tuo account Cloudflare.
Tabella decisionale：
| La tua esigenza | Raccomandato |
|---|---|
| Accedere a molti modelli con una sola API | CometAPI |
| Policy di routing gestite | Portkey |
| Routing a livello di provider | OpenRouter |
| Gateway self-hosted | LiteLLM |
| Infrastruttura Cloudflare | Cloudflare AI Gateway |
| Fallback controllato dall’applicazione | CometAPI |
| Policy di fallback centralizzate | Portkey / LiteLLM / Cloudflare |
Checklist di produzione per gateway multi-LLM
- Definisci quali codici di stato attivano retry, fallback e failure hard.
- Limita i retry e aggiungi un circuit breaker affinché un outage di un provider non moltiplichi la spesa.
- Verifica chiamate agli strumenti, output strutturato, streaming e comportamento di safety su ogni modello di fallback.
- Collega un unico ID di richiesta a tutti i tentativi e registra modello, provider, stato, latenza, token e costo.
- Imposta quote o budget per tenant e avvisa prima del limite hard.
- Valida gli ID modello correnti contro un catalogo live prima del deployment.
- Rivedi conservazione dei dati, routing dei provider e requisiti regionali prima di abilitare i log.
Una rotta di fallback che restituisce testo può comunque fallire il task in modo silente se rifiuta le chiamate agli strumenti, restituisce uno schema JSON diverso, trasmette in un formato incompatibile o applica una policy sui contenuti diversa. Verifica tutte e quattro su ogni modello di fallback prima di considerare la rotta sicura.
Domande frequenti
Quale gateway multi-LLM supporta cambio di modello, tracciamento dell’utilizzo e routing di fallback?
Tutte e cinque le opzioni nella matrice supportano questi risultati, ma non allo stesso modo. Portkey, LiteLLM, OpenRouter e Cloudflare espongono funzionalità di routing lato gateway. CometAPI fornisce cambio di modello, visibilità di utilizzo e accesso con una chiave, mentre il pattern di fallback documentato gira nel codice dell’applicazione.
CometAPI effettua automaticamente il fallback verso un altro modello?
La guida ufficiale attuale documenta una sequenza gestita dall’applicazione: chiama un modello CometAPI primario, passa a un altro modello CometAPI su failure ritentabile e, facoltativamente, chiama un provider ufficiale per ultimo. La stessa chiave API e base URL di CometAPI possono essere riutilizzate per lo switch interno del modello.
Posso cambiare modello senza modificare la mia infrastruttura client?
Di solito sì, quando il gateway espone un contratto compatibile con OpenAI. Con CometAPI, mantieni la base URL su https://api.cometapi.com/v1 e cambia il valore model. Verifica i parametri specifici del modello prima di presumere l’intercambiabilità totale.
Quando una richiesta dovrebbe fare fallback invece di fallire?
Il fallback è generalmente appropriato per timeout, errori di connessione, 408, 429 e risposte 5xx temporanee. Errori di autenticazione, richieste non valide, parametri non supportati e ID modello sconosciuti dovrebbero normalmente fallire immediatamente.
Come verifico il tracciamento dell’utilizzo?
Confronta l’utilizzo dei token nella risposta dell’API, nei log delle richieste del gateway, nei report di utilizzo giornaliero o quota e nella fattura finale. I record dovrebbero concordare su modello, numero di tentativi e volume di token.
Un gateway riduce automaticamente il costo dell’LLM?
No. Un gateway crea i controlli necessari per instradare in modo economico, limitare la spesa e osservare i retry. I risparmi dipendono dalla tua policy di rotta, dal mix di modelli, dal tasso di failure e dal fatto che i tentativi falliti abbiano consumato token fatturabili.
Costruisci il test del gateway basandoti sulle evidenze
Una valutazione utile del gateway multi-LLM si conclude con artefatti: una matrice di funzionalità datata, un test di failure ripetibile, log a livello di tentativo e una riconciliazione dei costi. CometAPI è un punto di partenza pratico quando vuoi un ampio accesso a modelli hosted tramite un’unica base URL compatibile con OpenAI. I team che necessitano di policy gestite dal gateway o di controllo self-hosted dovrebbero confrontare Portkey e LiteLLM con lo stesso test invece di affidarsi alle etichette di funzionalità.
Per il prossimo passo di implementazione, leggi come instradare le richieste tra più modelli e la guida al failover e al fallback di CometAPI.