vLLM vs SGLang 2026: Benchmark su H100 a Confronto

vLLM vs SGLang: Scegliere il server di inferenza LLM giusto nel 2026

Hugging Face ha messo TGI in modalità manutenzione a dicembre 2025 e ora indirizza i team verso vLLM o SGLang per i nuovi deployment. Se stai costruendo un'infrastruttura di inferenza oggi, la vera domanda non è "dovrei passare da TGI?" -- è quale di questi due motori si adatta davvero al tuo workload.

Riepilogo rapido

Scegli vLLM se vuoi il supporto hardware più ampio, la comunità più grande e un percorso collaudato verso la produzione su AWS, GCP e Azure.

Scegli SGLang se il tuo workload è intenso in conversazioni multi-turno, output strutturati o pipeline con molti prefissi come il RAG -- e sei a tuo agio con un ecosistema più piccolo.

Vediamo ora dove ogni motore prende davvero il sopravvento.

Come siamo arrivati qui? L'uscita di TGI

Text Generation Inference (TGI) ha sostenuto l'ecosistema Hugging Face per anni, ma da dicembre 2025 accetta solo correzioni di bug -- nessuna nuova funzionalità. I propri Inference Endpoints di Hugging Face ora usano vLLM come predefinito, con SGLang come alternativa.

Questo lascia due veri contendenti per il serving LLM self-hosted. Entrambi sono open-source, entrambi parlano l'API OpenAI e entrambi girano su GPU NVIDIA. Le differenze emergono sotto carico.

Verdetto: Sia vLLM che SGLang sono sostituzioni di TGI pronte per la produzione. Se stai migrando, entrambi sono una scelta sicura -- il resto di questa guida ti aiuta a scegliere quale.

Benchmark di throughput e latenza

I benchmark variano in base al modello, alla GPU e alla concorrenza, quindi ecco numeri da test indipendenti sullo stesso hardware. I dati seguenti provengono dai benchmark H100 di Spheron con Llama 3.3 70B Instruct in FP8 e dai test di PremAI con Llama 3.1 8B.

Llama 3.3 70B su H100 (FP8)

Llama 3.1 8B su H100

Sui modelli più piccoli il divario si allarga. PremAI ha misurato SGLang a circa 16.200 tok/s contro i 12.500 tok/s di vLLM -- un vantaggio di throughput del 29% per SGLang. LMDeploy ha eguagliato SGLang qui, ma questo è un discorso separato.

Cosa significano i numeri

Alla scala 70B il delta è modesto (3-5%). Alla scala 8B è significativo. Il pattern ha senso: il RadixAttention di SGLang rende di più quando il prefill rappresenta una frazione maggiore del costo totale, che accade con modelli più piccoli e output più corti.

La latenza di coda racconta una storia simile. Il TTFT p95 di SGLang era costantemente 5-8% inferiore a vLLM a ogni livello di concorrenza testato. Se stai costruendo un'interfaccia chat in tempo reale dove ogni 50ms conta, quel divario si accumula tra gli utenti.

Verdetto: SGLang vince sul throughput grezzo, specialmente per modelli più piccoli. vLLM è vicino alla scala 70B+. Per la maggior parte dei workload in produzione la differenza è a singola cifra -- significativa su larga scala, ma non determinante da sola.

Prefix caching: RadixAttention vs. Automatic Prefix Caching

Entrambi i motori memorizzano nella cache i calcoli KV per i prefissi ripetuti, ma i meccanismi differiscono in modi che contano per certi workload. Se hai già familiarità con il caching dei prompt a livello API, pensa a questo come alla versione lato server.

vLLM usa l'hashing a livello di blocco. Divide la cache KV in blocchi di dimensione fissa, li hash e cerca corrispondenze nelle nuove richieste. Prevedibile, efficiente e facile da ragionare -- ma hai bisogno di confini di blocco coerenti per i cache hit.

SGLang usa un albero radix indicizzato a livello di token. Scopre automaticamente i prefissi condivisi tra le richieste senza configurazione manuale. Se 50 utenti inviano messaggi nello stesso thread di conversazione, SGLang trova e riutilizza automaticamente il prefisso comune.

Dove fa davvero la differenza

RunPod ha benchmarkato le conversazioni multi-turno e ha scoperto che SGLang consegnava ~30-31 tok/s in modo costante sotto alta concorrenza, mentre vLLM scendeva da 22 a 16 tok/s man mano che la pressione sulla cache aumentava. Questo è un divario significativo per i workload di chatbot e agenti.

Per l'inferenza batch su prompt con template -- dove ogni richiesta usa lo stesso prompt di sistema -- l'approccio di vLLM funziona bene. I confini della cache si allineano naturalmente con la struttura del template.

Verdetto: SGLang vince per i workload dinamici e multi-turno. vLLM è perfettamente adeguato per l'inferenza batch e i prompt con template dove i prefissi sono prevedibili.

Output strutturati

Se hai bisogno di enforcement dello schema JSON o di generazione vincolata, questa sezione è molto importante. Entrambi i motori supportano gli output strutturati attraverso backend grammaticali come XGrammar e LLGuidance, ma la storia delle prestazioni è molto diversa.

SqueezeBits ha eseguito benchmark dettagliati e ha trovato che vLLM mostra un significativo degrado del throughput con la decodifica guidata abilitata, specialmente a batch size 8 e oltre. SGLang, al contrario, sovrappone la generazione di maschere al passaggio di inferenza GPU, mantenendo l'overhead minimo.

Schemi ripetitivi vs. dinamici

La scelta del backend conta anche:

Senza enforcement strutturato, gli output scendono a ~61% di correttezza su schemi complessi. Con esso, la correttezza sale di 20-25 punti percentuali. Quindi questo non è opzionale per i workflow di agenti in produzione -- e il motore che scegli determina quanto throughput sacrifichi.

Verdetto: SGLang vince per gli output strutturati. Se la tua pipeline dipende dall'enforcement dello schema JSON (e la maggior parte dei workflow di agenti lo fa), l'approccio sovrapposto di SGLang significa che non paghi una tassa di throughput.

Serving multi-LoRA e modelli fine-tuned

Entrambi i motori supportano il serving di più adattatori LoRA da un singolo modello base, il che è essenziale se fai fine-tuning dei modelli per diversi tenant o attività.

SGLang tratta il multi-LoRA come una funzionalità di prima classe con batching nativo -- le richieste che puntano a diversi adattatori possono condividere lo stesso batch. vLLM lo supporta anche, ma l'implementazione di SGLang è stata leggermente più rifinita nelle versioni recenti.

La differenza pratica? Se servi 5-10 adattatori LoRA da un modello base Llama 70B, entrambi funzionano. Se gestisci 50+ adattatori con pattern di traffico eterogenei, il batching nativo di SGLang gestisce lo scheduling in modo più elegante.

Verdetto: SGLang ha un leggero vantaggio per il multi-LoRA su larga scala. Per una manciata di adattatori, entrambi i motori funzionano ugualmente bene.

Decodifica speculativa

Entrambi i motori supportano la decodifica speculativa, che usa un piccolo modello "bozza" per predire i token che il modello principale verifica poi in parallelo. Il risultato è un'inferenza 2-3x più veloce per gli scenari limitati dalla memoria.

vLLM ha recentemente introdotto l'Unified Parallel Drafting, e la decodifica speculativa ora funziona insieme agli output strutturati. L'implementazione di SGLang è simile in capacità, con prestazioni leggermente migliori a livelli di concorrenza moderati.

Il vero differenziatore non è il motore -- è se la decodifica speculativa si adatta al tuo workload. Aiuta di più con gli output lunghi di modelli grandi dove il collo di bottiglia è la larghezza di banda della memoria, non il calcolo.

Verdetto: Pareggio. Entrambi i motori forniscono accelerazioni comparabili con la decodifica speculativa.

Supporto hardware e deployment

Qui è dove vLLM prende un vantaggio significativo.

vLLM

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI250, MI300X)
• GPU Intel (tramite vllm-xpu-kernels)
• AWS Trainium e Inferentia
• Google TPU
• Docs Kubernetes mature con chart Helm, probe startup/readiness/liveness
• Integrazione NVIDIA Container Toolkit out of the box

SGLang

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI300X, tramite ROCm)
• Deployment Docker-first
• Kubernetes è possibile ma meno documentato

Se stai effettuando il deployment su qualcosa di diverso da NVIDIA o AMD, vLLM è la tua unica opzione. Su AWS specificamente, il supporto Trainium significa che puoi ridurre significativamente i costi di inferenza -- e SGLang non può toccare quell'hardware.

Per i team che girano su GPU NVIDIA standard, la storia del deployment è simile. Entrambi forniscono immagini Docker e endpoint compatibili OpenAI. vLLM ha semplicemente più guide di produzione collaudate e chart Helm contribuiti dalla comunità.

Se stai esplorando strumenti per eseguire LLM localmente o vuoi una visione più ampia dell'inferenza self-hosted, entrambi i motori supportano anche il deployment locale su GPU consumer -- sebbene siano progettati per hardware datacenter.

Verdetto: vLLM vince sull'ampiezza hardware e la maturità del deployment. SGLang va bene se sei su NVIDIA o AMD. Ovunque altro, vLLM è l'unica scelta.

Serving disaggregato

Entrambi i motori supportano la separazione del prefill (intensivo in calcolo) dal decode (intensivo in memoria) in pool di worker diversi. Questo ti permette di scalare ogni fase in modo indipendente -- più worker di prefill durante i burst intensi di prompt, più worker di decode per la generazione lunga.

SGLang supporta Mooncake e NIXL come backend di trasferimento per la disaggregazione e ha pubblicato risultati che mostrano un throughput di decodifica 2,7x maggiore su cluster NVIDIA GB200 NVL72. Il serving disaggregato di vLLM è anch'esso funzionale, sebbene meno documentato in evidenza.

Questa funzionalità conta di più su scala molto grande (96+ GPU). Se stai gestendo una manciata di GPU, probabilmente non ne hai ancora bisogno.

Verdetto: SGLang ha un leggero vantaggio sulla maturità del serving disaggregato. Entrambi lo supportano; SGLang ha pubblicato più risultati reali.

Quando usare ciascuno: framework decisionale

La risposta onesta per molti team: prova entrambi. Sono entrambi open-source, entrambi espongono la stessa API OpenAI, e passare dall'uno all'altro è un semplice swap di container. Esegui il tuo workload reale contro ciascuno per un giorno e confronta le metriche che contano per te.

Se stai instradando traffico su più backend di inferenza, un gateway LLM può stare di fronte a entrambi i motori e gestire failover, rate limiting e osservabilità.

Come Techsy affronta la selezione del server di inferenza

Quando aiutiamo i team a deployare funzionalità alimentate da LLM, la scelta del motore di inferenza si riduce a tre domande:

1. A quale hardware sei vincolato? Se è Trainium o TPU, è vLLM. Tutto il resto, entrambi funzionano.
2. Qual è la forma del tuo workload? Chat multi-turno e cicli di agenti favoriscono il prefix caching di SGLang. Elaborazione batch e completamenti semplici vanno bene su entrambi.
3. Quanta capacità operativa hai? La comunità più grande di vLLM significa più risposte StackOverflow e chart Helm quando qualcosa si rompe alle 3 di notte.

Abbiamo eseguito workload di produzione su entrambi. Sono genuinamente vicini. La risposta giusta dipende dai tuoi vincoli, non dal fatto che uno sia "migliore" in astratto.

Hai bisogno di aiuto per scegliere o deployare un server di inferenza? Contattaci -- valuteremo il tuo workload e raccomanderemo il giusto stack.

Scegliere uno strumento è la parte facile. Farlo funzionare in modo affidabile dentro un prodotto reale è il punto in cui la maggior parte dei team si blocca, ed è esattamente ciò che il nostro team di integrazione AI costruisce per i clienti, dalle pipeline RAG agli agenti su misura.

Domande frequenti

SGLang è più veloce di vLLM?

Sui modelli più piccoli (7B-8B), SGLang mostra un throughput circa il 29% più alto su GPU H100. Sui modelli 70B+, il divario si riduce al 3-5%. SGLang ha anche una latenza di coda inferiore (TTFT p95) a tutti i livelli di concorrenza testati.

Posso usare vLLM e SGLang con il formato API OpenAI?

Sì. Entrambi espongono endpoint compatibili OpenAI out of the box. Puoi sostituirli l'uno con l'altro senza cambiare il codice client. Le tue chiamate /v1/chat/completions funzionano in modo identico su entrambi.

Perché Hugging Face ha deprecato TGI?

TGI è entrato in modalità manutenzione a dicembre 2025. Hugging Face ha deciso di contribuire a vLLM e SGLang invece di mantenere un motore di inferenza separato. TGI funziona ancora per i deployment esistenti, ma non arriveranno nuove funzionalità.

SGLang supporta le GPU NVIDIA e AMD?

SGLang supporta le GPU NVIDIA (A100, H100, H200, B200) e le GPU AMD (MI300X tramite ROCm). Non supporta le GPU Intel, AWS Trainium, Inferentia o Google TPU. vLLM ha una copertura hardware più ampia.

Cos'è RadixAttention e perché è importante?

RadixAttention è il meccanismo di prefix caching di SGLang. Memorizza le voci della cache KV in un albero radix indicizzato a livello di token, scoprendo automaticamente i prefissi condivisi tra le richieste. Questo rende le conversazioni multi-turno e le pipeline RAG significativamente più veloci perché il contesto ripetuto non deve essere ricalcolato.

Quale motore è migliore per gli output JSON strutturati?

SGLang. Sovrappone la generazione di maschere grammaticali all'inferenza GPU, quindi l'enforcement degli output strutturati non impatta quasi il throughput. vLLM mostra un degrado notevole a batch size di 8 e oltre quando la decodifica guidata è abilitata.

Posso servire più adattatori LoRA da un modello base?

Entrambi i motori supportano il serving multi-LoRA. SGLang lo tratta come una funzionalità nativa con batching su diversi adattatori nello stesso batch di richieste. vLLM lo supporta anche, ma lo scheduling di SGLang è più efficiente con un alto numero di adattatori.

Cos'è il serving prefill/decode disaggregato?

Significa eseguire la fase di prefill (elaborazione del prompt) su worker GPU separati dalla fase di decode (generazione di token). Il prefill è limitato dal calcolo; il decode è limitato dalla memoria. Separarli ti permette di scalare ogni fase in modo indipendente. Entrambi i motori lo supportano, con SGLang che ha più risultati di produzione pubblicati.

Come migro da TGI a vLLM o SGLang?

Poiché tutti e tre espongono API compatibili OpenAI, la migrazione è principalmente uno swap di container. Punta il tuo Docker Compose o deployment Kubernetes alla nuova immagine, regola i flag di caricamento del modello e aggiorna gli endpoint di health check. Il codice client rimane lo stesso.

Dovrei usare vLLM o SGLang per una pipeline RAG?

SGLang è la scelta più forte per RAG. Il suo RadixAttention memorizza automaticamente nella cache e riutilizza i lunghi prompt di sistema e i contesti di documenti che le pipeline RAG inviano ripetutamente. Il caching a livello di blocco di vLLM funziona anche, ma vedrai tassi di cache hit migliori con l'approccio a livello di token di SGLang quando i chunk di documenti variano leggermente tra le richieste.

Verdetto finale

SGLang vince più categorie, ma i vantaggi di vLLM -- ampiezza hardware e maturità dell'ecosistema -- sono il tipo di cose che contano alle 3 di notte quando un nodo cade.

Se sei su hardware NVIDIA e il tuo workload implica conversazioni multi-turno, agenti con output strutturati o pipeline RAG con prefissi condivisi, inizia con SGLang. Otterrai un throughput migliore e una latenza inferiore dove conta.

Se hai bisogno di flessibilità multi-cloud, supporto per hardware non-NVIDIA o il conforto della comunità open-source di serving LLM più grande, inizia con vLLM. È il default più sicuro che servirà bene la maggior parte dei team.

In ogni caso, entrambi i motori sono eccellenti e migliorano rapidamente. Scegline uno, esegui il deployment, misura il tuo workload reale e cambia se i numeri te lo dicono. L'API compatibile OpenAI rende quel cambio indolore.

Fonti

• Benchmark H100 Spheron: vLLM vs TensorRT-LLM vs SGLang
• PremAI: Benchmark vLLM vs SGLang vs LMDeploy
• SqueezeBits: Prestazioni di Guided Decoding su vLLM e SGLang
• RunPod: Riutilizzo della cache KV SGLang vs vLLM
• Documentazione ufficiale SGLang
• Documentazione ufficiale vLLM