Piattaforme di model serving nel 2026: la guida all'acquisto
Gateway, routing e inference engine per servire LLM in produzione: architetture, costi e criteri di selezione per team che vanno oltre il prototipo.
Daniel Nikulshyn
Editor
Dal prototipo alla produzione
Perché il serving è il collo di bottiglia del 2026
Nel 2023 e 2024 la conversazione ruotava attorno all'addestramento dei modelli e al prompt engineering. Nel 2026 il centro di gravità si è spostato: il vero problema per la maggior parte dei team non è avere un modello capace, ma servirlo in modo affidabile, economico e osservabile. Il model serving è la disciplina che copre tutto ciò che accade dopo l'addestramento — dal caricamento dei pesi in memoria alla risposta di un token via API — ed è qui che i progetti falliscono o scalano. Un LLM inference server, come ricorda la documentazione dei principali framework open source, deve risolvere problemi non banali: batching dinamico delle richieste, gestione della cache KV (key-value), quantizzazione per ridurre l'occupazione di memoria, e streaming dei token verso il client. Progetti come vLLM hanno reso popolare la tecnica del PagedAttention, che tratta la cache KV in modo simile alla paginazione della memoria virtuale dei sistemi operativi, riducendo lo spreco e aumentando il throughput. Parallelamente è emerso un secondo livello architetturale: il gateway. Man mano che i team hanno iniziato a usare più provider — OpenAI, Anthropic, modelli open source self-hosted — è nata la necessità di uno strato di routing unificato che astragga le differenze tra API, applichi policy di costo e sicurezza, e centralizzi logging e fatturazione. Questo strato è oggi tanto importante quanto l'inference engine sottostante. La distinzione tra questi due livelli è la chiave per capire il mercato. L'inference engine (vLLM, TGI, SGLang, TensorRT-LLM) esegue effettivamente il modello sulla GPU. Il gateway (LiteLLM, gli strumenti che vedremo più avanti) siede davanti e orchestra molteplici backend. Un team maturo di solito adotta entrambi. Capire dove si trovano i costi, la latenza e i rischi lungo questa catena è il primo passo per fare una scelta d'acquisto informata, invece di seguire l'hype del framework del mese.
- vLLM — Documentazione ufficiale — Inference engine con PagedAttention, riferimento per il throughput.
- Inference server (Wikipedia) — Contesto generale sui modelli linguistici di grandi dimensioni.
I componenti che contano
Anatomia di una piattaforma di serving
Una piattaforma di serving completa si compone di livelli ben identificabili, e valutarli separatamente evita di comprare una soluzione che risolve solo metà del problema. Il primo livello è l'esecuzione: il motore che carica i pesi, gestisce la cache KV e produce token. Qui contano metriche come time-to-first-token (TTFT), tokens-per-second (TPS) e utilizzo della GPU. La quantizzazione (INT8, FP8, GPTQ, AWQ) permette di far girare modelli grandi su hardware più economico a costo di una perdita minima di qualità. Il secondo livello è il routing e l'astrazione. Un buon gateway espone un'unica API — di solito compatibile con lo standard di fatto di OpenAI — verso decine di modelli e provider diversi. Questo consente il failover automatico (se un provider è down, si passa a un altro), il load balancing, e il routing intelligente (mandare le richieste semplici a un modello economico e quelle complesse a uno più capace). Secondo la documentazione di progetti come LiteLLM, questa compatibilità con l'API OpenAI è ciò che rende il gateway drop-in per il codice esistente. Il terzo livello è la governance: rate limiting, budget per team o utente, chiavi virtuali, redazione dei dati sensibili e policy di sicurezza. In un contesto enterprise questo livello non è opzionale: determina se puoi dare accesso agli LLM a decine di team senza perdere il controllo della spesa. Il quarto livello è l'osservabilità: logging strutturato di ogni richiesta, tracciamento dei costi per token, metriche di latenza e tracce distribuite. Senza questo strato è impossibile fare capacity planning o debug in produzione, e i costi tendono a esplodere silenziosamente. Infine c'è il livello agentico. Nel 2026 molte piattaforme di serving aggiungono supporto nativo per tool-use, function calling e il Model Context Protocol (MCP), riconoscendo che il consumatore tipico dell'inference non è più un chatbot ma un agente autonomo che fa molte chiamate in loop. Questa evoluzione cambia i requisiti: caching aggressivo, gestione dei retry e budget per sessione diventano critici.
- LiteLLM — Documentazione — Gateway open source compatibile con l'API OpenAI per 100+ provider.
- Model Context Protocol — Standard aperto per collegare modelli a strumenti e dati esterni.
Il grande bivio decisionale
Cloud gestito, self-hosted o ibrido?
La prima decisione strategica non è quale strumento comprare, ma quale modello operativo adottare. Le API gestite dei laboratori (OpenAI, Anthropic, Google) offrono il time-to-market più rapido: nessuna GPU da gestire, scaling automatico, aggiornamenti trasparenti. Il prezzo è il costo per token, la dipendenza dal fornitore e limiti sulla residenza dei dati. Il self-hosting di modelli open source su GPU proprie o affittate offre il controllo opposto: dati che non lasciano mai la tua infrastruttura, costi prevedibili al variare del volume, e la libertà di fare fine-tuning. Il rovescio della medaglia è la complessità operativa — gestire cluster GPU, monitorare l'utilizzo, dimensionare la capacità — che richiede competenze MLOps reali. Con modelli open source di qualità sempre più alta, come la famiglia GLM e i modelli Llama, il self-hosting è diventato competitivo anche in termini di qualità, non solo di costo. L'approccio ibrido, sempre più comune nel 2026, combina i due: un gateway che instrada le richieste sensibili o ad alto volume verso modelli self-hosted e quelle che richiedono la massima capacità verso le API commerciali. Questo pattern richiede uno strato di routing solido — ed è esattamente il caso d'uso che i gateway moderni sono progettati per servire. Un errore comune è sottostimare il costo totale del self-hosting. Una GPU H100 in cloud può costare diversi dollari all'ora, e un'istanza sottoutilizzata brucia budget anche quando non serve richieste. Il break-even rispetto alle API gestite arriva solo con volumi sostenuti e continui; per traffico sporadico, le API pay-per-token restano più economiche. La regola pratica: self-hosta quando hai volume prevedibile, requisiti di data residency, o bisogno di modelli custom. La buona notizia è che grazie alla standardizzazione sull'API OpenAI, la scelta non è irreversibile. Con un gateway davanti, puoi iniziare con API gestite e migrare gradualmente verso il self-hosting senza riscrivere il codice applicativo.
- Anthropic — API e modelli — Esempio di provider di API gestite ad alta capacità.
- OpenAI — Piattaforma — Lo standard di fatto per l'API di completion e chat.
Astrolabe, GLM-4.5 e New API a confronto
Tre strumenti dal nostro directory
Passando dal panorama generale agli strumenti concreti, esaminiamo tre voci del nostro directory che rappresentano bene le diverse angolazioni del serving nel 2026: un gateway focalizzato sugli agenti, un modello foundation open source, e un gateway multi-provider generalista. Astrolabe è un gateway di routing self-hosted e compatibile con l'API OpenAI, pensato specificamente per gli agenti OpenClaw. Il suo punto di forza è l'applicazione di policy di costo e sicurezza direttamente nel percorso della richiesta: è la scelta per team che eseguono agenti autonomi in loop e hanno bisogno di tenere sotto controllo la spesa e i comportamenti a rischio senza rinunciare all'infrastruttura on-premise. Chi costruisce sistemi agentici multi-step lo troverà particolarmente allineato ai propri bisogni. GLM-4.5 è un modello foundation open source con architettura Mixture-of-Experts (MoE) e ragionamento ibrido, progettato esplicitamente per compiti agentici, di coding e di tool-use. Non è un gateway ma il modello che si serve: rappresenta la categoria di modelli open source di alta qualità che rendono il self-hosting una scelta credibile. È adatto a team che vogliono un modello capace di ragionamento e uso di strumenti senza dipendere da API proprietarie, e che hanno l'infrastruttura per servirlo. New API è un gateway LLM open source che unifica le API di molteplici provider AI con routing, fatturazione e analytics integrati. È lo strumento giusto per organizzazioni che vogliono un pannello di controllo centralizzato sui consumi: gestione delle chiavi, distribuzione dei budget tra team e visibilità sui costi. Si posiziona come alternativa self-hosted ai gateway commerciali, ideale per chi ha bisogno di governance e reporting oltre al semplice routing. Messi insieme, questi tre strumenti illustrano lo stack tipico: un modello open source (GLM-4.5) servito su infrastruttura propria, dietro un gateway di governance (New API) o di policy agentiche (Astrolabe). Valutarli non in isolamento ma come tessere di un'architettura coerente è il modo corretto di leggere la categoria.
Come misurare prima di comprare
Metriche, costi e SLA che contano davvero
Nessuna decisione di serving dovrebbe essere presa senza benchmark sui propri carichi reali. Le metriche di riferimento sono quattro: il time-to-first-token (TTFT), che misura la reattività percepita ed è critico per le esperienze streaming; i tokens-per-second (TPS), che determinano il throughput; la latenza end-to-end sotto carico concorrente; e il costo per milione di token, che consolida tutto in una cifra confrontabile. Un errore frequente è testare con una singola richiesta invece che sotto carico. Le prestazioni di un inference engine cambiano radicalmente quando il batching entra in gioco: vLLM e SGLang, ad esempio, aumentano drasticamente il throughput aggregato con richieste concorrenti, ma la latenza per singola richiesta può degradarsi. Il profilo di traffico — poche richieste lunghe o molte richieste brevi — cambia completamente quale engine è ottimale. Sul fronte dei costi, bisogna guardare oltre il prezzo per token pubblicizzato. Nel self-hosting il costo reale è dato dall'ora-GPU divisa per il numero di token effettivamente serviti: un cluster sottoutilizzato può risultare più caro delle API gestite. Il caching (sia della cache KV che dei prompt ripetuti) è una leva enorme: Anthropic e OpenAI offrono prompt caching che riduce i costi delle porzioni ripetute del contesto, e i gateway self-hosted possono implementare caching semantico per evitare chiamate duplicate. Gli SLA meritano attenzione contrattuale. Le API gestite pubblicano garanzie di uptime, ma i rate limit dinamici possono causare degradi durante i picchi. Un gateway con failover automatico verso backend alternativi è la difesa pratica contro questi vincoli: quando un provider è saturo, la richiesta viene reindirizzata trasparentemente. Infine, l'osservabilità va considerata parte della metrica di successo. Senza logging per richiesta, tracciamento dei costi e alerting sui budget, i problemi emergono solo a fine mese sulla fattura. Una piattaforma di serving matura tratta l'osservabilità come funzionalità di prima classe, non come aggiunta successiva.
- SGLang — Progetto — Inference engine focalizzato su throughput e programmazione strutturata.
- OpenAI — Prompt caching — Documentazione sul caching dei prompt per ridurre costi e latenza.
Dal requisito alla decisione
Una checklist di selezione per il 2026
Riassumiamo il processo in una checklist operativa che qualsiasi team può applicare prima di impegnarsi con una piattaforma. Primo: definisci il profilo di traffico. Volume prevedibile e sostenuto spinge verso il self-hosting; traffico sporadico o imprevedibile favorisce le API gestite pay-per-token. Questo singolo fattore determina gran parte dell'architettura. Secondo: valuta i requisiti di dato e conformità. Se i dati non possono lasciare la tua infrastruttura per motivi normativi (GDPR, requisiti di settore), il self-hosting con un gateway come New API o Astrolabe diventa quasi obbligato. Terzo: quantifica il bisogno di governance. Più team e utenti consumano gli LLM, più conta uno strato di chiavi virtuali, budget e reporting centralizzato — feature che distinguono un gateway maturo da un semplice proxy. Quarto: considera il carico di lavoro agentico. Se stai costruendo agenti autonomi che fanno molte chiamate in loop, hai bisogno di caching aggressivo, gestione dei retry, policy di sicurezza e supporto per tool-use e MCP. Non tutte le piattaforme trattano bene questo pattern, ed è qui che strumenti pensati per gli agenti fanno la differenza. Quinto: proteggi l'opzionalità con la compatibilità API. Standardizzare sull'API OpenAI-compatibile mantiene basso il costo di cambiare provider o modello in futuro. È la polizza assicurativa più economica contro il lock-in in un mercato che si muove velocemente. Sesto e ultimo: fai un proof-of-concept prima di scalare. Esegui i tuoi carichi reali su due o tre candidati, misura TTFT, TPS e costo per milione di token, e verifica l'osservabilità. La differenza tra una scelta basata sui benchmark ufficiali e una basata sui tuoi dati può valere migliaia di dollari al mese e la stabilità della produzione. Nel 2026 il serving è una decisione ingegneristica, non di marketing: trattalo come tale.
- MLOps (Wikipedia) — Contesto sulle pratiche operative per il machine learning in produzione.
- GLM — Modelli open source (GitHub) — Repository dei modelli GLM per il self-hosting.
リソース
- Large language model (Wikipedia)
Panoramica generale sui modelli linguistici di grandi dimensioni e la loro esecuzione.
- vLLM — Documentazione ufficiale
Inference engine ad alto throughput con PagedAttention.
- LiteLLM — Documentazione
Gateway open source compatibile con l'API OpenAI per oltre 100 provider.
- Model Context Protocol
Standard aperto per collegare modelli a strumenti e dati esterni.
- Anthropic
Provider di API gestite ad alta capacità con prompt caching.
よくある質問
Qual è la differenza tra un inference engine e un gateway LLM?
L'inference engine (vLLM, TGI, SGLang) esegue effettivamente il modello sulla GPU, gestendo cache KV, batching e generazione di token. Il gateway (LiteLLM, New API, Astrolabe) siede davanti a uno o più engine/provider, offrendo routing, failover, governance e osservabilità dietro un'unica API. Un team maturo tipicamente usa entrambi.
Quando conviene fare self-hosting invece di usare API gestite?
Il self-hosting conviene con volume di traffico prevedibile e sostenuto, requisiti di data residency o conformità, o bisogno di modelli custom tramite fine-tuning. Per traffico sporadico, le API pay-per-token restano più economiche perché evitano il costo di GPU sottoutilizzate.
Perché la compatibilità con l'API OpenAI è così importante?
L'API OpenAI è diventata lo standard di fatto. Standardizzare su di essa rende il tuo codice portabile: puoi cambiare provider o passare da API gestite al self-hosting senza riscrivere l'applicazione, riducendo drasticamente il rischio di lock-in.
Cosa cambia nel serving quando eseguo agenti autonomi?
Gli agenti fanno molte chiamate in loop, quindi caching aggressivo, gestione dei retry, budget per sessione, policy di sicurezza e supporto per tool-use e MCP diventano critici. Strumenti pensati per gli agenti, come Astrolabe, applicano queste policy direttamente nel percorso della richiesta.
Come misuro correttamente le prestazioni di serving?
Testa sui tuoi carichi reali e sotto carico concorrente, non con una singola richiesta. Le metriche chiave sono time-to-first-token (TTFT), tokens-per-second (TPS), latenza end-to-end e costo per milione di token. Il batching cambia radicalmente i risultati rispetto ai test isolati.
I modelli open source come GLM-4.5 sono competitivi con quelli commerciali?
Nel 2026, per molti compiti agentici, di coding e tool-use, i modelli open source di alta qualità con architetture MoE e ragionamento ibrido sono competitivi in termini di qualità, non solo di costo. Rendono il self-hosting una scelta credibile per team con l'infrastruttura adeguata.
Come tengo sotto controllo i costi con più team che usano LLM?
Serve un gateway con governance: chiavi virtuali per team, budget e rate limit configurabili, tracciamento dei costi per token e analytics. Strumenti come New API centralizzano routing, billing e reporting in un unico pannello, evitando sorprese a fine mese.
L'osservabilità è davvero necessaria per il serving?
Sì. Senza logging per richiesta, tracciamento dei costi e alerting sui budget, i problemi di latenza e i costi imprevisti emergono solo dalla fattura mensile. Una piattaforma matura tratta l'osservabilità come funzionalità di prima classe, essenziale per capacity planning e debug.