La prima funzionalità LLM va in produzione come chiamata diretta da un servizio a Bedrock. La decima va in produzione allo stesso modo, da dieci servizi, con dieci set di credenziali, dieci policy di retry, e nessun posto unico dove vedere quanto sta spendendo ciascuno. È il momento in cui un platform team scopre di aver bisogno di un gateway LLM, di solito un trimestre dopo il momento in cui sarebbe stato economico costruirne uno. Un gateway è la porta d'ingresso condivisa attraverso cui passa ogni chiamata al modello, ed esiste per possedere le quattro cose che i singoli team continuano a reinventare male: autenticazione, quota, routing e audit.

Il modo utile di vederla è che un gateway non è una funzionalità AI. È lo stesso control plane che metti già davanti a qualsiasi dipendenza condivisa, misurata e costosa. Non lasceresti che ogni servizio porti con sé la propria password admin del database e scelga il proprio limite di connessioni. L'accesso ai modelli non è diverso, solo che la bolletta cresce più in fretta e i modi di fallire sono più rumorosi.

Cosa centralizza davvero il gateway

Il valore non sta nel fare da proxy alla richiesta. Sta nel possedere le quattro responsabilità trasversali che non appartengono al codice applicativo:

  • Autenticazione. I chiamanti presentano un'identità di servizio al gateway. Il gateway detiene l'unica credenziale che parla con Bedrock. Nessuna applicazione vede mai una chiave del modello a lunga durata, e ruotare quella chiave è una modifica sola, non venti.
  • Quota. I budget di token per team e per modello vivono in un unico posto. Un loop fuori controllo in un servizio raggiunge il proprio tetto invece di consumare il limite condiviso di token al minuto e throttlare tutti gli altri.
  • Routing. Il gateway mappa un nome logico di modello su un deployment concreto: quale regione, quale provider, quale fallback quando il primario va in throttling. Le applicazioni chiedono "il summarizer", non un ID modello specifico in una regione specifica.
  • Audit. Ogni richiesta e risposta passa da un unico collo di bottiglia, così l'attribuzione dei costi, il logging dei prompt e il rilevamento degli abusi hanno tutti un unico punto a cui agganciarsi. Senza, il costo per funzionalità diventa un progetto di archeologia.

Nota che nessuno di questi è un problema di qualità del modello. Sono problemi di piattaforma che sembrano nuovi solo perché la dipendenza è un modello.

Build vs LiteLLM vs API Gateway

Ci sono tre pattern onesti, e quello giusto dipende da quanto di tutto questo ti serve davvero al primo giorno.

Adotta LiteLLM (o un proxy simile)

Un proxy open source come LiteLLM ti dà di serie un'API unificata tra provider, budget per chiave e routing di base. È il modo più veloce per avere un gateway vero che conosce già le quattro responsabilità. Il compromesso è che ora gestisci e aggiorni un servizio stateful che sta sul percorso critico di ogni funzionalità AI, e le sue opinioni su routing e logging diventano le tue opinioni. Per la maggior parte dei team che sta mettendo in piedi la seconda o terza funzionalità LLM, questa è la scelta di default corretta. Compri il control plane invece di costruirlo.

Mettilo su API Gateway più Lambda

Se sei già profondamente dentro AWS, Amazon API Gateway davanti a un piccolo Lambda authorizer e a una funzione proxy ti dà auth, usage plan, throttling e access log usando primitive che già gestisci. Gli usage plan si occupano dei rate limit per chiave, l'authorizer si occupa dell'identità, CloudWatch si occupa dell'audit trail. Il costo è che la logica specifica del modello, lo streaming, il conteggio dei token e il fallback tra provider sono codice che scrivi e mantieni tu. Questo pattern vince quando i tuoi requisiti di governance hanno una forma AWS e preferisci estendere una piattaforma esistente piuttosto che introdurre una nuova dipendenza.

Costruisci un servizio su misura

Costruire il proprio è giusto solo quando i tuoi requisiti di routing o audit sono davvero fuori dal comune: policy complesse di selezione del modello, decisioni di data residency per singola richiesta, o logging che deve soddisfare un regolatore in una forma specifica. La maggior parte dei team che costruisce da zero sta in realtà ricostruendo LiteLLM più lentamente. Scegli questa strada per ultima, e solo quando riesci a nominare il requisito che l'opzione pronta all'uso non può soddisfare.

Il modo di fallire che un gateway previene

Senza un gateway, il fallimento non è drammatico, è lento. Le credenziali si diffondono. Ogni team imposta il proprio timeout e il proprio retry, così un intoppo del provider diventa una tempesta di retry che ti spinge oltre la quota di token. Nessuno riesce a rispondere a "quanto è costata la funzionalità support-summarizer il mese scorso" senza fare grep nei log di tutti i servizi. Poi una revisione di sicurezza chiede chi può chiamare quale modello con quali dati, e la risposta onesta è "non siamo sicuri", che è la risposta che blocca un lancio.

Un gateway trasforma tutto questo in configurazione. È tutto qui il senso: spostare le decisioni trasversali fuori da venti codebase e dentro una sola su cui puoi ragionare.

Traccia il confine nel posto giusto

Mantieni il gateway sottile. Deve gestire identità, quota, routing e logging, e restare fuori dalla costruzione dei prompt e dalla logica di business. Nel momento in cui il gateway inizia a possedere i prompt, diventa una libreria condivisa con un salto di rete in mezzo, e ogni team resta bloccato dal suo ciclo di rilascio. Il design che dura è un proxy noioso con opinioni forti sulla governance e nessuna opinione su cosa chiedi al modello.

Il punto chiave

Ogni platform team che rilascia più di una funzionalità LLM finisce per costruire un gateway, prima o poi. L'unica scelta è se costruirlo deliberatamente, presto, quando è ancora un piccolo proxy, oppure per caso, tardi, come progetto di bonifica dopo che le credenziali si sono diffuse e la bolletta è diventata un mistero. Adotta un proxy se puoi, estendi API Gateway se sei nativo AWS, e costruisci da zero solo contro un requisito che sai nominare. Il gateway non è dove succede l'AI. È dove la governance di cui avevi comunque bisogno trova finalmente una casa.

Leggi questo dopo

Per il lato platform e infrastruttura di gestire un control plane condiviso come questo, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.