Come funziona un gateway LLM? Una guida pratica per i team di ingegneria

Un gateway LLM si colloca tra le tue applicazioni e i provider di modelli che colleghi attraverso di esso, offrendoti un unico punto in cui gestire le credenziali e monitorare l’utilizzo.

“Al momento è una m***a totale”, ha scritto su Reddit in r/LLMDevs un ingegnere a settembre 2026.

“Ognuno ha il proprio set di chiavi per Claude, OpenAI, AWS Bedrock e tutti gli altri provider di inferenza che usiamo.”

L’articolo di BigGo su llm-proxy-tk, un gateway FastAPI leggero, paragona questa configurazione a una trasformazione degli LLM in “acqua del rubinetto aziendale”, con il gateway nel ruolo di valvola principale dell’edificio.

Ma prima di riporre così tanta fiducia nell’impianto idraulico, vediamo cosa stai installando.

Che cos’è un gateway LLM?

Un gateway LLM è un reverse proxy per le chiamate ai modelli. Le tue applicazioni inviano le richieste al gateway anziché direttamente a OpenAI, Anthropic, Google o a qualsiasi altro provider di LLM tu utilizzi. Il gateway inoltra queste richieste, applicando le tue regole lungo il percorso.

Ogni provider di LLM ha la propria API, con una propria struttura delle richieste, un proprio sistema di autenticazione e un proprio modo di restituire gli errori. Ognuno ha anche limiti di frequenza e modalità di errore distinti. Ora, se davanti a loro non c’è un livello condiviso, ogni applicazione che chiama un provider fa tutto da sé, e lo fa in modo leggermente diverso.

L’analogia dell’acqua del rubinetto ha i suoi limiti, ma fino a questo punto regge: i provider vengono allacciati una sola volta, al gateway. Da quel momento in poi, ogni applicazione ottiene la propria connessione con contatore, così puoi vedere chi usa cosa e chiudere una singola linea senza toccare le altre.

Gateway LLM, AI, MCP e API: qual è la differenza?

Come funziona un gateway LLM?

Segui il percorso di andata e ritorno di una richiesta tra la tua applicazione e il modello.

1. La richiesta arriva al gateway: la tua applicazione invia una richiesta di chat dall’aspetto normale, spesso in un formato compatibile con OpenAI, all’endpoint del gateway. Dal punto di vista dell’applicazione, questo è l’indirizzo da chiamare per raggiungere il modello.
2. Il gateway verifica chi sta facendo la richiesta e cosa può fare: prima di inoltrare la richiesta, convalida le credenziali. Spesso si tratta di una chiave virtuale assegnata a un team o a un prodotto. Se hai configurato dei guardrail sugli input, i prompt possono anche essere analizzati alla ricerca di dati sensibili o di tentativi di scavalcare le istruzioni del modello.
3. Il gateway verifica se ha già la risposta: se il caching è attivo, una richiesta corrispondente idonea può ricevere una risposta salvata, senza un’altra chiamata al provider. Alcuni gateway offrono anche il caching semantico, che cerca richieste ritenute abbastanza simili anziché identiche. Può essere adatto al traffico di tipo FAQ.
4. Il gateway sceglie dove inviare la richiesta: la richiesta potrebbe indicare un modello specifico o un alias. Il gateway cerca il percorso corrispondente nella tua configurazione. Puoi anche configurare un percorso di riserva: se il provider A va in timeout, il gateway può provare il provider B.
5. Il gateway prepara la chiamata e restituisce la risposta: un gateway converte la tua richiesta nel formato del provider scelto e autentica la chiamata in uscita. Non appena riceve la risposta, la converte nel formato richiesto dalla tua applicazione.
6. Il gateway registra cosa è successo: quando il logging è attivo, il gateway registra dettagli come chi ha effettuato la chiamata, quale modello l’ha servita, il numero di token, la latenza e il costo. È proprio il log che mancava all’ingegnere di Reddit citato nell’introduzione.

Le 4 cose da sapere prima di mettere in produzione un gateway

Tutto ciò che è descritto nella sezione precedente è possibile perché il gateway vede ogni richiesta che lo attraversa. È questo il suo punto di forza. Ma è anche una descrizione della superficie di attacco e della dipendenza dal fornitore che devi mettere in conto.

Il gateway è ora l’elemento più prezioso del tuo stack AI

Il gateway centralizza l’accesso. Di conseguenza, mette anche molte credenziali alla portata di un unico servizio. Il team di sicurezza di Microsoft elenca ciò che un deployment di LiteLLM può contenere o recuperare: le chiavi API dei provider, la sua master key, i record delle chiavi virtuali, le stringhe di connessione ai database, le impostazioni di routing e le policy dei tenant.

Nell’ottobre 2026, Check Point Research ha reso note due vulnerabilità ad alto rischio in LiteLLM:

• La CVE-2026-35029 consentiva agli utenti autenticati, compresi quelli con accesso in sola lettura, di raggiungere le funzioni amministrative e assumere il controllo dell’istanza.
• La CVE-2026-59823 consentiva agli utenti di reindirizzare le richieste verso un server sotto il loro controllo e di intercettare le chiavi dei provider.

Entrambe sono state risolte nella versione 1.83.9. Un’applicazione che usa il gateway non dovrebbe poterne modificare le impostazioni.

I tuoi guardrail hanno bisogno di una policy in caso di errore

Un’analisi pubblicata da Pillar Security il 4 ottobre 2026 documenta le integrazioni di guardrail di terze parti nei principali gateway, tra cui LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management e Apigee. (Pillar vende guardrail, quindi tienilo presente quando leggi i suoi consigli.)

Un hook è un punto del percorso della richiesta, in genere prima che il prompt arrivi al modello o dopo che la risposta è tornata, in cui il gateway può passare il contenuto a uno scanner esterno per ottenere un verdetto. Un controllo bloccante attende quel verdetto prima di lasciar proseguire il traffico. La documentazione di Portkey li chiama before_request_hooks e after_request_hooks; TrueFoundry ne esegue quattro, aggiungendo controlli prima e dopo le chiamate agli strumenti MCP.

Ora, due aspetti da verificare:

• Cosa succede se è lo scanner stesso a non funzionare? Se blocchi la richiesta, fermi il traffico non controllato ma rischi di interrompere la tua applicazione. Se la lasci passare, la tua applicazione può continuare senza quel controllo. Il log degli errori ti mostra a posteriori che il controllo è mancato, il che è utile, ma non equivale ad averlo eseguito.
• Puoi sostituire lo scanner? Se un altro provider non è supportato, potresti dover aggiornare la tua applicazione o usare un altro proxy per collegarlo.

Gli hook MCP di TrueFoundry estendono la portata del gateway dalle richieste ai modelli alle chiamate agli strumenti. Ma il gateway può ispezionare solo il traffico che lo attraversa. Un agente di programmazione che esegue un comando sul computer di uno sviluppatore potrebbe sfuggire a questa visibilità.

Il progetto open source Numbat di Perplexity opera proprio su questo fronte. Numbat si connette agli agenti supportati tramite hook locali e può ispezionare le azioni pianificate, come comandi shell o scritture di file, prima che vengano eseguite. La funzione di blocco è facoltativa ed è disattivata per impostazione predefinita. Il gateway vede il traffico verso i modelli che lo attraversa. Numbat aggiunge visibilità su ciò che l’agente fa con la risposta.

Devi sapere dove finisce il controllo del gateway

Forkast News individua tre filoni che si avvicinano al gateway da direzioni diverse:

• Gateway incentrati sugli LLM: LiteLLM e Portkey sono nati per le chiamate ai modelli: traduzione tra provider, instradamento delle richieste e monitoraggio dei token. Ora stanno aggiungendo controlli per le chiamate agli strumenti.
• Piattaforme di gestione delle API: Kong, Apigee di Google e Azure API Management sono nati con autenticazione, autorizzazioni e gestione del traffico, per poi aggiungere il supporto ai modelli e regole specifiche per l’AI.
• Infrastruttura nativa per agenti: agentgateway, ad esempio, è stato progettato attorno alla comunicazione degli agenti con modelli, strumenti e altri agenti, anche tramite MCP e A2A.

Il criterio di scelta è cosa stai instradando:

• Solo chiamate ai modelli? Un gateway pensato principalmente per gli LLM è un buon punto di partenza.
• Chiamate ai modelli in un’azienda già piena di regole per le API? Parti dalla piattaforma che hai già.
• Agenti che chiamano strumenti che chiamano modelli? Verifica che anche quelle connessioni siano coperte.

Introduci un punto di guasto condiviso

Supponiamo che il tuo chatbot di assistenza usi OpenAI e il tuo strumento di ricerca usi Anthropic, ed entrambi si connettano tramite lo stesso gateway. Se quel gateway smette di funzionare, entrambi gli strumenti perdono l’accesso ai rispettivi modelli, anche se OpenAI e Anthropic funzionano normalmente.

È successo davvero. Durante l’interruzione del 12 giugno 2025, il tasso di errore di AI Gateway di Cloudflare ha raggiunto un picco del 97%. Il gateway si affidava al servizio di archiviazione Workers KV di Cloudflare per le impostazioni, e quel servizio non funzionava.

Se gestisci il gateway in autonomia, mantieni in esecuzione un’altra copia in grado di subentrare in caso di guasto. Se il tuo gateway è ospitato da terzi, chiedi come lo mantengono operativo durante i guasti e cosa succede alle tue richieste durante il ripristino.

Le funzionalità chiave da cercare in un gateway LLM

Darai al gateway accesso alle credenziali di tutti, quindi dovresti essere esigente su ciò che offre in cambio.

• Un’unica API davanti a più provider: il tuo codice usa un solo formato, spesso compatibile con OpenAI, e il gateway si occupa della traduzione. I provider di LLM vengono incontro a questo approccio. Ad esempio, l’Agent API di Perplexity supporta l’interfaccia Responses API di OpenAI, così i team possono riutilizzare le librerie client OpenAI esistenti.
• Chiavi virtuali con regole associate: ogni team o prodotto riceve la propria chiave, con regole che stabiliscono i modelli consentiti, i limiti di richieste e la spesa.
• Routing e fallback: il gateway invia le richieste ai modelli in base alle tue impostazioni, che potrebbero privilegiare il costo, la velocità o un determinato provider. Se una chiamata non va a buon fine, può provarne un’altra. L’Agent API di Perplexity ti permette di indicare fino a cinque modelli, anche di provider diversi, nell’ordine che preferisci.
• Caching: una risposta salvata può risparmiarti un’altra chiamata al provider. Alcuni gateway individuano le richieste identiche; altri possono individuare anche richieste dal significato simile. Verifica se le risposte in cache possono essere separate per utente o per team e se puoi disattivare il caching per le risposte personalizzate o che dipendono dal momento.
• Streaming ed errori coerenti: le risposte arrivano man mano che vengono generate e gli errori dei provider vengono tradotti in un formato che la tua applicazione può gestire. Verifica cosa succede quando aggiungi i guardrail AI.
• Log e attribuzione dei costi: il gateway registra chi ha effettuato una chiamata, quale modello l’ha servita, quanti token ha usato, quanto tempo ha richiesto e il suo costo stimato. Verifica se i log includono prompt e risposte e per quanto tempo vengono conservati.
• Hook per i guardrail: sono punti del percorso della richiesta in cui il gateway può inviare contenuti a uno scanner esterno per ottenere un verdetto. Di solito si trovano prima di una richiesta al modello o dopo la sua risposta. Verifica se le richieste si fermano o proseguono quando lo scanner non funziona e se puoi collegare uno scanner diverso.
• Un’interfaccia di amministrazione che puoi blindare: il gateway gestisce l’accesso alle credenziali dei provider e alle regole usate da tutti. Verifica di poter limitare l’accesso amministrativo separatamente dal traffico delle applicazioni e che gli utenti in sola lettura non possano modificare le impostazioni. La valvola principale ha bisogno di un lucchetto.

Quali strumenti puoi usare per creare il tuo gateway LLM?

Gli elenchi di funzionalità si sovrappongono in tutto il mercato. In un thread di Reddit sull’accesso interno ai modelli, l’autore chiedeva: quale gateway non richiede un ingegnere dedicato?

Secondo noi è la domanda giusta, e ha quattro risposte, a seconda di quanta parte del lavoro sei disposto a gestire in prima persona.

Sviluppalo in proprio

Un gateway minimale svolge un breve elenco di compiti: accettare le richieste, verificare la chiave del chiamante, aggiungere la credenziale del provider, inoltrare la chiamata e registrare il risultato. Ma supportare i diversi formati dei provider richiede lavoro aggiuntivo. Così come mantenere il tutto in funzione.

Se usi già Envoy, il suo filtro di elaborazione esterna ti consente di collegare un servizio che ispeziona e modifica richieste e risposte. Quel servizio, però, devi comunque crearlo e gestirlo tu.

In un thread di r/LLMDevs sulla possibilità che un gateway riduca i costi, u/QuanTradin ha raccontato che registrare i token e un flag di cache hit per ogni chiamata gli ha permesso di individuare due job che pagavano il prezzo pieno per prompt identici.

“...risolvere quel problema valeva più di qualsiasi livello di routing.”

È l’esperienza riferita da un utente, ma è un buon punto di partenza. Scopri per cosa stai pagando prima di costruire sistemi elaborati per instradare quel traffico.

Ospita in autonomia un gateway open source

LiteLLM è una scelta comune in questo caso: è compatibile con OpenAI, supporta un’ampia gamma di provider e ha una grande community. Bifrost è un’alternativa, progettata per un basso overhead per richiesta. Helicone merita un’occhiata se l’osservabilità è in cima alla tua lista di funzionalità.

LiteLLM, come qualsiasi prodotto, ha dei limiti per alcuni team. In un thread di r/aiagents sulle alternative allo sviluppo in proprio, u/Own_Bar_920 ha detto che LiteLLM gestiva bene il routing, ma non era all’altezza per il versioning dei prompt tra team e per le valutazioni continue durante il cambio di modello, il che li ha spinti verso uno strumento separato.

Queste esigenze vanno oltre il routing di base di un gateway, ed è proprio questo il punto: se il routing è l’esigenza principale, per loro LiteLLM si è dimostrato all’altezza.

Ottieni un elenco di funzionalità già pronto, con alcune funzionalità che dipendono dall’edizione, e mantieni il gateway all’interno della tua rete. Ma diventa tua anche la responsabilità delle patch, come hanno reso evidente le segnalazioni di Check Point citate in precedenza, e della disponibilità del gateway, come ha mostrato la sezione sul punto di guasto unico.

Ma metti in conto che qualcuno dovrà esserne responsabile. In un thread di r/LLMDevs sui gateway per l’accesso interno, una delle preoccupazioni era la manutenzione. u/Informal-Writer9685 voleva qualcosa che “non richieda un ingegnere dedicato alla manutenzione” e chiedeva se l’instabilità durante gli aggiornamenti segnalata per LiteLLM fosse un problema reale alla loro scala o una preoccupazione limitata agli ambienti di produzione.

Usa un gateway gestito

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter e il gateway ospitato di Portkey gestiscono il servizio per te. Per un’applicazione compatibile, far passare la prima richiesta può richiedere poco più di una modifica dell’URL e una chiave API.

Il compromesso, in questo caso, è che ogni prompt passa ora attraverso una terza parte prima di raggiungere il provider. È un responsabile del trattamento dei dati in più nella tua documentazione di conformità, e un’interruzione del gateway è un incidente del fornitore: non spetta a te risolverlo.

Ad esempio, il 17 e il 19 febbraio 2026 OpenRouter ha subito interruzioni durate 38 e 35 minuti rispettivamente, in seguito al guasto di una dipendenza di caching. Alcuni clienti hanno ricevuto errori “User not found” e hanno perso tempo a fare il debug di chiavi API perfettamente valide. Il problema era nell’infrastruttura del gateway.

Va detto, a suo merito, che OpenRouter ha pubblicato un postmortem dettagliato e aggiunto protezioni per evitare che un guasto della cache sovraccarichi il suo database. Un gateway gestito come OpenRouter può semplificare l’accesso, ma, come sottolinea u/QuanTradin su r/LLMDevs, consolidare le fatture non riduce automaticamente la spesa.

Estendi il gateway API che hai già

Se Kong, Apigee o Azure API Management gestiscono già l’accesso ai tuoi servizi, ognuno offre funzionalità specifiche per l’AI: Kong AI Gateway, le policy di AI gateway di Apigee e l’AI gateway di Azure API Management. Puoi basarti sull’autenticazione, sulle regole di rete e sulle procedure operative che hai già, aggiungendo controlli sui modelli tramite plugin o policy.

In una grande azienda, questa può essere la strada che incontra meno resistenze organizzative. Le funzionalità AI sono più recenti di quelle dei gateway standalone. Assicurati di testare la limitazione della frequenza basata sui token e lo streaming attraverso l’intero insieme di plugin o policy che intendi usare.

Quindi installa pure la valvola principale, l’onnipotente gateway. L’ingegnere citato nell’introduzione, però, non ha tutti i torti: l’accesso di un’azienda ai modelli non dovrebbe dipendere da chi, per caso, tiene la chiave giusta in un cassetto.

Un gateway risolve il problema mettendo quelle chiavi sotto un controllo centralizzato, il che però alza la posta in gioco se si lascia il cassetto aperto. Bisogna sapere di chi è il cassetto.

Domande frequenti sui gateway LLM

Il gateway LLM è gratuito?

Se intendi la categoria in generale, alcuni gateway LLM offrono versioni gratuite.

I gateway LLM spaziano dal software open source gratuito ai piani a pagamento a partire da circa 50 dollari al mese, con prezzi personalizzati per le implementazioni aziendali. Alcuni, invece, applicano una percentuale: ad esempio, il piano Standard di OpenRouter aggiunge il 5,5% agli acquisti di crediti.

Qual è il miglior gateway LLM?

Quale parte del lavoro sei disposto a gestire in prima persona?

• Se vuoi un gateway in self-hosting e il pieno controllo della configurazione, dai un’occhiata a Bifrost o Helicone.
• Un’opzione gestita come OpenRouter o Vercel AI Gateway è adatta ai team che preferiscono affidare a qualcun altro la gestione del servizio.
• Se usi già Kong o Azure API Management, verifica prima le loro funzionalità di IA.

Testa le soluzioni della tua rosa ristretta con le tue richieste, verificando anche cosa succede quando un provider va in errore.

AWS ha un gateway LLM?

Sì. Amazon Bedrock AgentCore Gateway supporta le chiamate ai modelli tramite quelli che AWS chiama “inference target”. Questi consentono alle applicazioni di usare un unico endpoint per raggiungere provider come Amazon Bedrock, OpenAI e Anthropic, mentre il gateway gestisce le credenziali dei provider e il routing.