AI Gateway: un endpoint, tanti modelli

Un AI gateway è un unico punto di accesso tra le tue applicazioni e i tuoi modelli AI. Ogni richiesta, che sia un comando vocale, una foto, un messaggio in chat o una decisione aziendale, passa dal gateway. Il gateway la controlla, sceglie il modello più adatto al compito e restituisce la risposta attraverso un'unica API coerente.

In Axis Technologies stiamo costruendo il nostro AI gateway su misura, perché i progetti che realizziamo non usano più un solo modello. Un singolo processo aziendale può dover ascoltare una telefonata, leggere un DDT scansionato, scrivere una risposta e decidere se un rimborso richiede un'approvazione. Nessun modello è il migliore, il più economico e il più veloce in tutte e quattro le cose.

Questo articolo spiega cosa fa un AI gateway, come funziona il routing intelligente dei modelli e cosa abbiamo imparato finora costruendone uno per voce, visione, testo e decisioni.

Quando un team inizia con l'AI, di solito collega un'app a un unico grande modello. Funziona, finché non funziona più. Quattro problemi tendono a presentarsi insieme:

• Costi. La maggior parte delle richieste è semplice: "riassumi questo", "classifica quello", "è una fattura?". Mandarle tutte al modello più grande è come assumere un ingegnere senior per smistare la posta.
• Velocità. I modelli grandi impiegano più tempo a rispondere. Per un assistente vocale o una chat dal vivo, due secondi di ritardo sembrano un guasto.
• Tipi di input diversi. I modelli di testo non sentono e molti non vedono. La voce richiede modelli speech-to-text e text-to-speech. Le immagini richiedono un modello di visione. La ricerca nei documenti richiede modelli di embedding e reranking.
• Controllo. Alcuni dati non devono uscire dalla tua rete. Alcuni compiti richiedono una traccia di audit. Alcuni provider hanno disservizi. Ti serve un unico posto per gestire tutto questo.

Un AI gateway risolve questi problemi in un solo livello, invece che in ogni applicazione.

Pensa al gateway come a una reception intelligente. Ogni richiesta arriva allo stesso banco. La reception controlla il badge, verifica che la richiesta sia sicura, capisce di cosa hai bisogno e ti indirizza allo specialista giusto.

Poiché il gateway usa lo stesso formato API di OpenAI, le nostre app non hanno bisogno di codice speciale. Puntano al gateway e chiedono il modello auto:

import OpenAI from 'openai';export const ai = new OpenAI({  baseURL: process.env.AI_GATEWAY_URL, // our gateway, not a provider  apiKey: process.env.AI_GATEWAY_KEY,});const reply = await ai.chat.completions.create({  model: 'auto', // let the gateway choose the right model  messages: [{ role: 'user', content: 'Riassumi questo DDT ed elenca gli articoli mancanti.' }],});

Cambiare un modello, aggiungerne uno nuovo o spostare un compito dal cloud al nostro hardware avviene nel gateway. Nessuna applicazione cambia.

Il routing è il cuore di un AI gateway. Per ogni richiesta, il router risponde a una sola domanda: quale modello deve gestirla?

Il router stesso è un modello piccolo e veloce. Il suo unico compito è prendere quella decisione in pochi millisecondi. Considera:

• Modalità. La richiesta contiene audio, un'immagine o solo testo?
• Difficoltà. Un sì/no veloce o un breve riassunto sono "facili". Ragionamenti in più passaggi, codice o documenti lunghi sono "difficili". Le richieste facili vanno al modello piccolo; tutto il resto a quello grande.
• Capacità. La richiesta richiede la chiamata a tool? È più lunga della finestra di contesto di un modello? La risposta deve essere lunga? Un modello che non soddisfa questi requisiti non viene mai scelto, per quanto economico sia.
• Regole. Alcune app o tipi di dati devono restare sui nostri server. Alcuni compiti richiedono sempre il modello più potente.

Ogni risposta comunica all'app quale modello è stato scelto, così possiamo verificare il router e individuare le decisioni sbagliate. Progetti open source come vLLM Semantic Router hanno reso questo tipo di routing molto più pratico nell'ultimo anno.

La voce è dove un gateway ripaga davvero, perché una sola richiesta parlata usa diversi modelli in sequenza.

Qui la velocità conta più di tutto. Per questo i modelli vocali girano su hardware dedicato vicino all'utente, e le richieste vocali vanno di solito a un modello linguistico piccolo e rapido. Una risposta brillante che arriva con tre secondi di ritardo è peggio di una buona risposta che arriva subito.

Gli usi tipici per cui lo stiamo progettando: assistenti telefonici e di helpdesk, checklist a mani libere per gli operatori in reparto e comandi vocali per gli strumenti interni.

Molti processi aziendali funzionano ancora con le immagini: fatture scansionate, foto di DDT, screenshot di messaggi d'errore, foto del controllo qualità da una linea di produzione.

Quando una richiesta contiene un'immagine, il gateway la fa passare prima da un encoder visivo. L'encoder trasforma l'immagine in qualcosa su cui un modello linguistico può ragionare. Poi il router decide se un modello piccolo può gestire la domanda ("qual è il totale della fattura?") o se serve quello grande ("confronta questo DDT con l'ordine ed elenca cosa manca").

La lezione che continuiamo a reimparare: far descrivere un'immagine a un modello di visione è facile. Fargli leggere l'immagine, usare un tool e compiere l'azione giusta in modo affidabile è un passo diverso, che va testato dall'inizio alla fine.

Non ogni richiesta è una domanda. Molte sono decisioni: questo rimborso va approvato? Questa email è un reclamo? Quale team deve gestire questo ticket?

Per le decisioni, il gateway lavora insieme ai nostri agenti AI. Il gateway fornisce il modello giusto per ogni passaggio. L'agente, costruito con Next.js e Mastra, gestisce la logica: quali tool chiamare, quali regole valgono e quando chiedere a una persona.

Alcune regole che seguiamo per le decisioni:

• Il modello suggerisce, le regole decidono. Tutto ciò che riguarda denaro, sicurezza o aspetti legali passa da un workflow fisso con soglie chiare.
• La sicurezza della risposta conta. Le decisioni con bassa confidenza vanno automaticamente a una persona.
• Tutto è tracciabile. Per ogni decisione possiamo vedere quale modello è stato usato, cosa ha visto e perché ha scelto così.

Far passare tutto il traffico AI da un unico gateway è anche un grande vantaggio per la sicurezza. Invece di proteggere ogni app separatamente, proteggiamo una sola porta.

• Rilevamento della prompt injection. Un classificatore dedicato controlla le richieste per individuare tentativi di aggirare le istruzioni o estrarre dati nascosti. Partiamo in modalità di monitoraggio, quindi registra soltanto ciò che trova. Così misuriamo i falsi allarmi sul traffico reale prima di bloccare qualsiasi cosa.
• Mascheramento dei dati personali. Nomi, email e altri campi sensibili possono essere mascherati prima che una richiesta raggiunga un provider esterno.
• Chiavi e limiti per app. Ogni applicazione ha la sua chiave, il suo budget e il suo limite di traffico. Un bug in un'app non può consumare il budget di tutti.
• Un registro di audit completo. Chi ha chiesto cosa, quale modello ha risposto e quanto è costato.

Uno dei motivi principali per costruire un gateway è la libertà di scegliere dove gira ogni modello.

Un aspetto che sorprende molti: per far girare un'AI utile non serve la GPU più grande e più nuova. Dare a ogni modello un compito mirato permette di abbinarlo a hardware modesto. Un modello piccolo per le risposte veloci, un modello di embedding per la ricerca e modelli vocali su un chip a basso consumo possono condividere un unico server. Il modello grande viene svegliato solo quando serve davvero.

Ci chiedono spesso se il loro API gateway esistente può fare la stessa cosa. In parte sì: autenticazione, limiti di traffico e log sono la stessa idea. La differenza è che un AI gateway capisce la richiesta. Sa se dentro c'è un'immagine, quanto è difficile la domanda, quanti token costerà e quale modello può gestirla. Gestisce inoltre rischi per cui i gateway classici non sono mai stati pensati, come la prompt injection.

In pratica spesso usiamo entrambi: l'API gateway al confine della rete e l'AI gateway dietro, per tutto ciò che coinvolge un modello.

Costruire il nostro AI gateway ci ha insegnato alcune lezioni che condivideremmo con chiunque stia iniziando:

1. Prima un routing corretto, poi i risparmi. Una decisione di routing sbagliata sembra esattamente un modello scadente. Verifica che le richieste vadano dove devono prima di ottimizzare qualsiasi cosa.
2. Le capacità contano più dei prompt ingegnosi. Se un modello supporta i tool, quanto è ampio il suo contesto e quanto possono essere lunghe le risposte conta più di come formuli il prompt.
3. Un buon punteggio di ricerca non è una risposta corretta. Nella ricerca documentale, verifica che i passaggi recuperati siano davvero le prove giuste, non solo testo simile.
4. Testa ogni percorso dall'inizio alla fine. "Il modello di visione gira" non equivale a "il workflow di visione funziona". Ogni modalità ha bisogno dei suoi test reali.
5. Registra la decisione, non solo la risposta. Sapere quale modello ha risposto, e perché, è ciò che rende il sistema diagnosticabile.

Appena la tua azienda usa l'AI per più di una cosa, un AI gateway smette di essere un optional. Dà a ogni app un'unica API semplice, invia ogni richiesta al modello più adatto, tiene i dati sensibili dove devono stare e ti mostra esattamente cosa fa la tua AI e quanto costa.

Stiamo costruendo il nostro per voce, visione, testo e decisioni, e lo usiamo nel software con agenti AI che realizziamo per i clienti. Se stai toccando i limiti di un singolo modello, o vuoi portare l'AI sul tuo hardware, contattaci. Saremo felici di mostrarti come il routing potrebbe funzionare per i tuoi processi.

Da guardare: il video di Techno Tim I Built My Own Intelligent AI Gateway mostra in modo pratico come far girare più modelli self-hosted dietro un unico router intelligente.