Scegliere un gateway API per l’IA non è più il problema di due anni fa. Nel 2024, la maggior parte degli sviluppatori chiamava direttamente OpenAI oppure avviava LiteLLM in locale. Oggi esistono opzioni ospitate con dashboard dei prezzi, limiti di credito per chiave e cataloghi di modelli che coprono decine di provider. La categoria si è espansa al punto che scegliere male significa dover disfare vero lavoro d’integrazione in seguito.
Questo articolo confronta quattro gateway che ricorrono spesso nelle discussioni tra sviluppatori: CometAPI, Portkey, LiteLLM e Cloudflare AI Gateway. L’obiettivo non è decretare un vincitore — ognuno ha senso in situazioni diverse — bensì chiarire cosa fa realmente ciascuno, così da abbinare lo strumento al tuo caso d’uso.
Nota sui nomi dei modelli: gli identificatori di modello usati in questo articolo (come
gpt-5.4,claude-opus-4-7) sono identificatori della piattaforma CometAPI. Non sono nomi ufficiali di OpenAI o Anthropic, che usano convenzioni diverse.
Cosa fanno davvero questi strumenti
Prima di confrontare le funzionalità, è utile chiarire cosa fa un gateway API per l’IA. Nel minimo: si colloca tra la tua applicazione e uno o più provider di IA, inoltrando le richieste e restituendo le risposte. Oltre a questo minimo, i gateway divergono in modo significativo.
Alcuni gateway — ad esempio Cloudflare AI Gateway — sono principalmente uno strato di pass-through che aggiunge logging e caching senza toccare la tua API key o il pricing. Altri, come CometAPI, agiscono da rivenditore: paghi loro, loro pagano il provider sottostante, e la differenza di prezzo fa parte della proposta di valore. LiteLLM è ancora diverso: è software che esegui tu stesso, non un servizio ospitato.
Comprendere questa distinzione conta prima di valutare qualunque funzionalità specifica.
Confronto delle funzionalità
La tabella seguente usa informazioni tratte dalla documentazione ufficiale o dalle dashboard pubbliche di ciascun prodotto a maggio 2026. Le funzionalità contrassegnate con un trattino (—) non erano confermate da fonti ufficiali al momento della stesura.
| Funzionalità | CometAPI | Portkey | LiteLLM | Cloudflare AI Gateway |
|---|---|---|---|---|
| Distribuzione | Ospitato (SaaS) | Ospitato + self-host | Auto-ospitato (open source) | Ospitato (edge di Cloudflare) |
| Catalogo modelli | 500+ modelli tra provider | 1.600+ LLM via API unificata | Dipende dalla tua configurazione | OpenAI, Anthropic, Workers AI |
| Modello di pricing | Rivenditore (paghi CometAPI) | Pass-through + commissione piattaforma | Solo costi infrastrutturali | Pass-through (piano gratuito disponibile) |
| API compatibile con OpenAI | Sì (api.cometapi.com/v1) | Sì (api.portkey.ai/v1) | Sì (locale o remoto) | Sì (via URL del gateway) |
| Limiti di credito per chiave | Sì (dashboard) | Sì | Sì (tramite configurazione) | — |
| Rapporti di prezzo basati su gruppi | Sì (0.8x predefinito, 0.1x interno) | — | — | — |
| Logging delle richieste | Sì (4 tipi di log) | Sì | Sì | Sì |
| Monitoraggio del tasso di successo | Sì (vista uptime a 30 giorni) | Sì | Sì | Sì |
| Piano gratuito | Sì (nuovi account) | Sì | Open source (costi infrastrutturali) | Sì |
| Opzione self-hosting | No (enterprise: server dedicato) | Sì | Sì (caso d’uso principale) | No |
Fonti: Dashboard CometAPI, Homepage Portkey, GitHub di LiteLLM, Documentazione di Cloudflare AI Gateway
Connessione a ciascun gateway
Tutti e quattro i gateway espongono un endpoint compatibile con OpenAI, il che significa che la stessa struttura di client funziona per tutti — cambi il base_url, le credenziali e, nel caso di Portkey, come specifichi il modello.
Python
import osfrom openai import OpenAIdef require_env(name: str) -> str: """Raise a clear error if a required environment variable is missing.""" val = os.environ.get(name) if not val: raise ValueError(f"Missing required environment variable: {name}") return val# ── CometAPI ────────────────────────────────────────────────────────────────# Hosted reseller with 500+ models. Use CometAPI model identifiers (e.g. "gpt-5.4").cometapi_client = OpenAI( base_url="https://api.cometapi.com/v1", api_key=require_env("COMETAPI_KEY"),)# ── Portkey ─────────────────────────────────────────────────────────────────# Hosted gateway with observability and 1,600+ LLMs.# Route to a provider by prefixing the model name: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc.# x-portkey-api-key is required; it authenticates requests to Portkey's gateway.portkey_client = OpenAI( base_url="https://api.portkey.ai/v1", api_key=require_env("PORTKEY_API_KEY"), default_headers={ "x-portkey-api-key": require_env("PORTKEY_API_KEY"), },)# ── LiteLLM ──────────────────────────────────────────────────────────────────# Self-hosted proxy. Provider credentials (OPENAI_API_KEY etc.) are set server-side.# By default the proxy does not validate the client API key — "anything" works.# If you have enabled virtual keys on your LiteLLM instance, pass a virtual key instead.litellm_client = OpenAI( base_url=os.environ.get("LITELLM_BASE_URL", "http://localhost:4000"), api_key=os.environ.get("LITELLM_API_KEY", "anything"),)# ── Cloudflare AI Gateway ───────────────────────────────────────────────────# URL-based pass-through. Keep your real provider API key — Cloudflare does not replace it.cf_account_id = require_env("CF_ACCOUNT_ID")cf_gateway_id = require_env("CF_GATEWAY_ID")cloudflare_client = OpenAI( base_url=( f"https://gateway.ai.cloudflare.com/v1" f"/{cf_account_id}/{cf_gateway_id}/openai" ), api_key=require_env("OPENAI_API_KEY"),)def ask(client: OpenAI, model: str, question: str) -> str: """ Minimal wrapper showing the common call pattern across all four gateways. Model format varies by gateway: CometAPI: "gpt-5.4", "claude-opus-4-7", etc. (CometAPI identifiers) Portkey: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc. LiteLLM: whatever model names you configured in your proxy Cloudflare: standard OpenAI model names, e.g. "gpt-4o" This function does not handle finish_reason, tool_calls, or provider errors. For production error handling, see: How to Debug Failed AI API Generations. """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": question}], ) return response.choices[0].message.content or ""
Node.js
import OpenAI from "openai";function requireEnv(name) { const val = process.env[name]; if (!val) throw new Error(`Missing required environment variable: ${name}`); return val;}// ── CometAPI ────────────────────────────────────────────────────────────────const cometClient = new OpenAI({ baseURL: "https://api.cometapi.com/v1", apiKey: requireEnv("COMETAPI_KEY"),});// ── Portkey ─────────────────────────────────────────────────────────────────// Route to a provider by prefixing the model: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet"const portkeyClient = new OpenAI({ baseURL: "https://api.portkey.ai/v1", apiKey: requireEnv("PORTKEY_API_KEY"), defaultHeaders: { "x-portkey-api-key": requireEnv("PORTKEY_API_KEY"), },});// ── LiteLLM ──────────────────────────────────────────────────────────────────// Self-hosted. Default mode accepts any API key value.// Set LITELLM_BASE_URL if your server runs on a different host or port.const litellmClient = new OpenAI({ baseURL: process.env.LITELLM_BASE_URL ?? "http://localhost:4000", apiKey: process.env.LITELLM_API_KEY ?? "anything",});// ── Cloudflare AI Gateway ───────────────────────────────────────────────────const cfClient = new OpenAI({ baseURL: `https://gateway.ai.cloudflare.com/v1/${requireEnv("CF_ACCOUNT_ID")}/${requireEnv("CF_GATEWAY_ID")}/openai`, apiKey: requireEnv("OPENAI_API_KEY"),});/** * Minimal wrapper showing the common call pattern. * Model format varies by gateway — see Python example above for details. * Does not handle finish_reason or error recovery; add those for production use. */async function ask(client, model, question) { const response = await client.chat.completions.create({ model, messages: [{ role: "user", content: question }], }); return response.choices[0].message.content ?? "";}
Lo schema di connessione è lo stesso per tutti e quattro. Le differenze significative emergono altrove: cosa puoi osservare, cosa puoi controllare e cosa accade quando qualcosa si rompe.
A cosa è realmente adatto ciascuno strumento
CometAPI
L’offerta principale di CometAPI è un catalogo ospitato con oltre 500 endpoint di modelli, inclusi modelli di generazione di immagini e video oltre ai modelli di testo. Il pricing si basa su un sistema di rapporti per gruppi — il gruppo predefinito applica un moltiplicatore di 0.8x alle tariffe base di CometAPI. Puoi configurare gruppi di rapporto diversi per uso interno (0.1x) rispetto ai clienti paganti, rendendo pratico costruire un prodotto a livelli senza gestire account separati.
La dashboard offre quattro tipi di log (chiamate API standard, generazione immagini, generazione video, Midjourney), una vista di uptime a 30 giorni e limiti di credito per chiave. I limiti di credito ti consentono di dare API key a clienti o contractor con un tetto di spesa rigido, risolvendo un problema reale quando distribuisci accesso a un account condiviso.
Cosa non offre CometAPI: self-hosting (i clienti enterprise possono richiedere un server dedicato, ma non è un’opzione self-hosted standard), rate limiting a livello di gateway o SSO.
Più adatto a: sviluppatori indie e piccoli team che vogliono instradare tra molti modelli — inclusi immagine e video — con una sola API key e una sola relazione di fatturazione, e che hanno bisogno di controlli di budget per chiave.
Portkey
Portkey è un gateway ospitato incentrato sull’osservabilità. Ti dà accesso a oltre 1.600 LLM tramite un’API unificata, con l’instradamento gestito anteponendo il nome del provider al modello (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). Ciò significa che non ti servono configurazioni client separate per ogni provider — un solo client Portkey li gestisce tutti, e cambi la stringa del modello.
Oltre all’instradamento, Portkey fornisce tracciamento delle richieste, versionamento dei prompt e instradamento di fallback che configuri dalla dashboard anziché nel codice. L’opzione self-hosting ti consente di eseguire Portkey sulla tua infrastruttura se la conformità lo richiede.
Il repository GitHub del gateway open source di Portkey è attivamente mantenuto — verifica direttamente il conteggio stelle corrente anziché affidarti a numeri riportati qui, poiché cambia spesso.
Più adatto a: team che necessitano di audit trail, instradamento multi-provider da un’unica configurazione del client, o che vogliono gestire l’esposizione delle API key tra sviluppatori.
LiteLLM
LiteLLM è un pacchetto Python e un server proxy, non un servizio ospitato. Lo gestisci tu. Questa è una distinzione importante: non c’è una terza parte che gestisce le tue richieste o detiene le tue API key. Le credenziali dei provider (la tua chiave OpenAI, la chiave Anthropic, ecc.) sono impostate come variabili d’ambiente lato server; il client punta semplicemente al proxy locale.
Per impostazione predefinita, LiteLLM non valida la API key inviata dai client — qualunque valore funziona. Se abiliti la gestione delle chiavi virtuali, i client passano chiavi virtuali che LiteLLM valida rispetto al proprio database. In ogni caso, il proxy traduce le richieste in formato OpenAI nel formato atteso dal provider upstream, così il tuo codice applicativo non cambia quando aggiungi un nuovo provider.
Il compromesso è l’onere operativo: sei tu a essere responsabile dell’esecuzione, della scalabilità e dell’aggiornamento del server.
Più adatto a: team con capacità devops, organizzazioni con vincoli di conformità che vietano proxy API di terze parti, o chiunque voglia instradamento tra provider senza affidare il contenuto delle richieste a un vendor SaaS.
Cloudflare AI Gateway
Cloudflare AI Gateway è strutturalmente diverso dagli altri tre. Non cambi la tua API key né paghi Cloudflare per l’accesso ai modelli. Invece, sostituisci la base URL del provider con un URL gestito da Cloudflare che aggiunge logging, caching e rate limiting all’edge.
Poiché Cloudflare si interpone tra la tua applicazione e il provider, può mettere in cache richieste identiche — utile se la tua applicazione invia ripetutamente gli stessi prompt. Il piano gratuito copre la maggior parte dei casi d’uso degli sviluppatori indie. La limitazione è di ambito: Cloudflare non aggrega i modelli tra i provider. Ti servono comunque account e chiavi separati per ogni provider che utilizzi.
Più adatto a: sviluppatori già sull’infrastruttura Cloudflare, o chiunque desideri caching e logging sopra gli account dei provider esistenti senza introdurre una nuova relazione di fatturazione o cambiare API key.
Abbinamento agli scenari
| Scenario | Strumento consigliato | Motivazione |
|---|---|---|
| App indie, vuoi provare 10+ modelli con una sola API key | CometAPI | Ampio catalogo, setup semplice, limiti di credito per chiave |
| Serve generazione di immagini + video nella stessa integrazione | CometAPI | Endpoint unificato per modelli di testo, immagine e video |
| Team di 5, bisogno di tracciare chi usa quale modello | Portkey | Tracciamento delle richieste, gestione team |
| Instradare verso oltre 1.600 LLM con una sola configurazione client | Portkey | Instradamento @provider/model, nessuna configurazione per provider |
| Vuoi fallback tra provider senza modifiche al codice | Portkey | Configurazione di fallback dichiarativa in dashboard |
| Impresa con requisiti di residenza dei dati | LiteLLM (self-hosted) | Nessuna gestione del traffico da parte di terzi |
| Budget pari a zero, a proprio agio con l’auto-gestione | LiteLLM | Open source, nessun costo di piattaforma |
| Già usi OpenAI direttamente, vuoi caching | Cloudflare AI Gateway | Solo sostituzione dell’URL, nessuna nuova relazione di fatturazione |
| Serve RBAC per più team | Portkey o LiteLLM | Entrambi hanno gestione di team/ruoli; CometAPI e Cloudflare no |
Cosa non coprono questi quattro
Questo confronto copre i gateway che compaiono più spesso nelle discussioni degli sviluppatori indie. Il mercato include altre opzioni da conoscere: Helicone è focalizzato sull’osservabilità senza agire da proxy, OpenRouter è specializzato nell’instradamento verso modelli open-weight e di ricerca, e AWS Bedrock è il servizio gestito di Amazon rivolto ai carichi enterprise. Se i tuoi requisiti non rientrano in nessuno dei quattro sopra, questi sono i prossimi posti da guardare.
Effettuare la transizione
Se attualmente chiami un provider direttamente e stai valutando un gateway, il cambiamento di codice è minimo. Per CometAPI, aggiungi una variabile d’ambiente e cambi il base_url. Per Portkey, aggiungi un header e cambi come specifichi il modello (@openai/gpt-4o invece di gpt-4o). Per Cloudflare, cambi l’URL senza toccare la tua API key del provider. Per LiteLLM, prima esegui un server locale, poi punti il tuo client a quello.
La domanda più grande non è come effettuare il passaggio, ma se ti serve davvero. Se chiami un solo provider, non hai problemi di visibilità dei costi e non ti serve l’instradamento tra modelli, un gateway aggiunge complessità senza beneficio. Se utilizzi più provider, distribuisci chiavi a contractor o scopri che fatture inattese sono un problema ricorrente, l’onere d’integrazione vale la pena.
FAQ
Posso usare questi gateway insieme?
Sì. Alcuni team eseguono LiteLLM self-hosted per carichi sensibili e CometAPI per tutto il resto. Cloudflare AI Gateway può porsi davanti alle richieste verso CometAPI se vuoi lo strato di caching di Cloudflare — anche se questo aggiunge un hop di rete.
Questi gateway memorizzano i miei prompt?
Dipende dallo strumento e dalla tua configurazione. Portkey e CometAPI registrano le richieste per impostazione predefinita; entrambi hanno impostazioni di retention. LiteLLM memorizza solo ciò che configuri, sulla tua infrastruttura. Il comportamento di logging di Cloudflare è descritto nella loro documentazione di AI Gateway. Leggi i termini sulla privacy di qualunque servizio ospitato prima di inviare contenuti sensibili.
Cosa succede se il gateway va giù?
Per i gateway ospitati (CometAPI, Portkey, Cloudflare), un downtime del gateway significa che la tua applicazione non può raggiungere il provider di IA tramite quel percorso. LiteLLM in esecuzione localmente ha le stesse caratteristiche di disponibilità del tuo server. Prima di impegnarti con un gateway ospitato per l’uso in produzione, verifica il suo SLA e se offre fallback diretto verso il provider nel caso in cui il gateway stesso non sia disponibile.
Esiste un modo gratuito per valutare ciascuno prima di impegnarsi?
Sì. CometAPI e Portkey hanno piani gratuiti. LiteLLM è open source e costa solo l’infrastruttura su cui lo esegui. Cloudflare AI Gateway è gratuito entro limiti generosi. Puoi eseguire tutti e quattro contro gli stessi prompt di test prima di decidere.
Come scelgo i nomi dei modelli giusti per ciascun gateway?
Ogni gateway ha la sua convenzione. CometAPI usa propri identificatori (gpt-5.4, claude-opus-4-7). Portkey usa il formato @provider/model-name (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). LiteLLM usa i nomi dei modelli che definisci nella configurazione del tuo proxy. Cloudflare lascia immutati i nomi dei modelli standard del provider. Controlla la documentazione di ciascun gateway per l’elenco aggiornato dei modelli prima di scrivere codice.
Il passaggio a un altro gateway influisce sui miei rate limit esistenti?
Sì. Se passi da chiamate dirette a OpenAI a un gateway che gestisce la relazione con il provider (come CometAPI), i tuoi rate limit effettivi sono determinati dall’account del gateway presso OpenAI, non dal tuo account personale. Verifica il comportamento dei rate limit con il gateway prima di migrare traffico di produzione.