- vLLM è la scelta più sicura per impostazione predefinita— supporto per il maggior numero di modelli e hardware, ecosistema più ampio, minori difficoltà di distribuzione.
- Scegli SGLang quando il tuo traffico riutilizza in modo intensivo prefissi di prompt (agenti, chat multi-turno, prompt di sistema molto lunghi) o genera grandi quantità di output strutturato in formato JSON: in questi casi RadixAttention e la decodifica jump-forward offrono prestazioni superiori.
- Il divario prestazionale dipende dal carico di lavoro ed è destinato a ridursi con ogni nuova versione. Entrambi supportano l’API OpenAI, quindi effettuare benchmark su entrambi con il tuo traffico reale è economicamente conveniente.
- Nessuno dei due funziona nativamente su Windows o macOS: usa Linux (o WSL2), oppure uno strumento desktop come Ollama/LM Studio per l’uso locale.
vLLM e SGLang sono i due principali motori open source per il servizio di modelli linguistici su GPU di proprietà, e per la maggior parte dei team vLLM è la scelta più sicura per impostazione predefinita: più modelli supportati, più backend hardware disponibili, ecosistema più vasto. Scegli SGLang quando il tuo traffico è dominato da prefissi di prompt condivisi — agenti, chat multi-turno, prompt di sistema molto estesi — oppure da output strutturati in formato JSON, dove la cache RadixAttention e la decodifica basata su grammatiche ne garantiscono un netto vantaggio. Entrambi espongono un’API compatibile con OpenAI, quindi cambiarli in un secondo momento comporta quasi zero costi.
Questa guida li confronta nel modo in cui effettivamente li sceglieresti: quali obiettivi ciascun progetto privilegia, le differenze pratiche tra RadixAttention e PagedAttention, i punti di forza di ciascuno in termini di throughput e latenza, e una raccomandazione chiara in base al carico di lavoro.
Quali obiettivi privilegia ciascun progetto
vLLM è nato nel 2023 presso l’Università della California a Berkeley come implementazione di riferimento del paper su PagedAttention ed è oggi diventato lo standard de facto per i motori open source di servizio di modelli, nonché progetto della PyTorch Foundation. Le sue priorità sono ampiezza e robustezza: eseguire quasi tutti i modelli open-weight su quasi tutti gli acceleratori disponibili — CUDA NVIDIA, ROCm AMD, Intel, TPU Google, AWS Neuron e persino CPU x86 — garantendo fin da subito un elevato throughput. I nuovi gruppi di modelli ricevono solitamente il supporto di vLLM già al giorno del lancio o poco dopo.
SGLang proviene dal team LMSYS, noto per Chatbot Arena. È ottimizzato per due aspetti specifici: riutilizzo della cache KV (RadixAttention) e generazione strutturata veloce. Il nome è l’acronimo di Structured Generation Language — in origine era distribuito con un DSL Python per concatenare e ramificare le chiamate a modelli linguistici di grandi dimensioni (LLM) — ma oggi la maggior parte degli utenti ne impiega il runtime per il servizio. Ha solide credenziali produttive: è stato tra i motori DeepSeek raccomandati al lancio della versione V3 ed è noto per ottimizzazioni aggressive su più GPU (disaggregazione tra fase di prefill e fase di decode, parallelismo su larga scala tra esperti per modelli MoE).
RadixAttention vs PagedAttention, spiegato in termini semplici
Le due tecniche principali risolvono problemi diversi, e i loro nomi suggeriscono erroneamente una scelta esclusiva.
PagedAttention (vLLM) riguarda la gestione della memoria. Memorizza la cache KV in blocchi di dimensione fissa, analogamente a come un sistema operativo gestisce la memoria virtuale tramite paginazione, anziché allocare un unico blocco contiguo di grandi dimensioni per ogni richiesta. Ciò riduce quasi del tutto la frammentazione, consentendo di eseguire simultaneamente un numero molto maggiore di sequenze nella stessa VRAM; batch più grandi si traducono quindi in un throughput più elevato. Si tratta essenzialmente di farci stare di più.
RadixAttention (SGLang) riguarda invece il riutilizzo della memoria. Organizza la cache KV come un albero radix indicizzato da sequenze di token. Quando arriva una nuova richiesta, il motore attraversa l’albero, individua il prefisso comune più lungo e salta il suo ricalcolo. Prompt di sistema, esempi con pochi esempi (few-shot), cronologia delle conversazioni e aree di lavoro temporanee degli agenti (scratchpad) che si ripetono tra richieste diverse vengono calcolati una sola volta durante la fase di prefill e poi riutilizzati. Si tratta essenzialmente di calcolare di meno.
Nel 2026 i due motori si sono avvicinati più di quanto suggerisca la denominazione: vLLM include ormai una cache automatica dei prefissi (attivata di default nelle versioni recenti), mentre SGLang implementa anch’esso la paginazione della memoria. La differenza pratica residua è che SGLang è stato progettato fin dall’inizio intorno al concetto di riutilizzo — il suo scheduler è consapevole della cache e ordina e instrada le richieste in modo da massimizzare il tasso di hit. Regola empirica: maggiore è la percentuale di prompt tipico che si ripete tra richieste, maggiore sarà il vantaggio offerto dal design di SGLang.
In ogni caso, la cache KV compete con i pesi del modello per lo stesso spazio di memoria GPU, e la capacità di gestire richieste concorrenti è ciò che realmente offre un motore di servizio. Utilizza lo Calcolatore VRAM strumento di stima della memoria
Throughput e latenza: dove ciascuno eccelle
| Carico di lavoro | Generalmente più veloce | Perché |
|---|---|---|
| Chat multiplo, cicli di agenti, prompt di sistema condivisi di grandi dimensioni | SGLang | RadixAttention evita il rifacimento del prefill sui prefissi ripetuti, riducendo il tempo fino al primo token e liberando risorse computazionali |
| Prompt singoli con scarsa sovrapposizione (documenti unici, riassunti in batch) | Roughly even | Entrambi utilizzano l’elaborazione continua (continuous batching) e il prefill suddiviso in blocchi (chunked prefill); il riutilizzo della cache si attiva raramente |
| Output JSON ad alto volume o vincolato | SGLang | La decodifica jump-forward emette token forzati dalla grammatica senza eseguire un passaggio forward del modello |
| Zoo di modelli eterogeneo, quantizzazioni esotiche, hardware non NVIDIA | vLLM | Una copertura più ampia di backend e formati comporta meno percorsi di fallback non ottimizzati |
Considera qualsiasi valore specifico di throughput trovato online come valido solo per quella versione. Entrambi i progetti rilasciano continuamente ottimizzazioni e hanno pubblicato benchmark in cui ciascuno supera l’altro. La risposta onesta è che, su traffico favorevole al riutilizzo della cache, SGLang è generalmente in testa; su traffico con cache fredda le prestazioni sono simili; l’unico benchmark davvero significativo è il tuo: entrambi forniscono strumenti per il test del carico (vLLM vllm bench serve, SGLang python -m sglang.bench_serving) che riproducono flussi di richieste realistici.
Output strutturati e vincolati
Entrambi i motori possono forzare l’output in modo che rispetti uno schema JSON, un’espressione regolare o una grammatica, esposti tramite il parametro OpenAI-style response_format e ulteriori estensioni specifiche del motore.
SGLang ha introdotto per primo questo percorso ottimizzato: compila i vincoli in una macchina a stati finiti compressa e utilizza la decodifica jump-forward — quando la grammatica rende deterministici i prossimi token (parentesi graffe, virgolette, nomi fissi di chiavi), li aggiunge direttamente senza eseguire il modello per ciascuno di essi. Per pipeline di estrazione che producono JSON con molti token, questo rappresenta un miglioramento significativo delle prestazioni.
vLLM supporta la stessa classe di vincoli tramite backend grammaticali plug-in (xgrammar, guidance, outlines); poiché entrambi i progetti hanno adottato xgrammar come backend predefinito, il divario si è notevolmente ridotto. Verdetto: entrambi sono pronti per l’uso in produzione; SGLang mantiene tuttavia un vantaggio su carichi di lavoro altamente strutturati e ad alto volume.
Ecosistema, supporto hardware e facilità di distribuzione
| vLLM | SGLang | |
|---|---|---|
| Origine | UC Berkeley; progetto della PyTorch Foundation | LMSYS (team di Chatbot Arena) |
| Hardware | NVIDIA, AMD ROCm, Intel, Google TPU, AWS Neuron, CPU x86 | Supporto nativo per NVIDIA, supporto per AMD ROCm; altri piattaforme meno mature |
| Copertura modelli | La più ampia tra tutti i motori, inclusi molti modelli multimodali e architetture specializzate | Tutte le principali famiglie (Llama, Qwen, DeepSeek, Mistral, GPT-OSS…), coda più corta |
| Quantizzazione | FP8, AWQ, GPTQ, INT8, bitsandbytes e altri | FP8, AWQ, GPTQ; lista più ristretta |
| API | Compatibile con OpenAI, porta predefinita 8000 | Compatibile con OpenAI, porta predefinita 30000 |
| Immagine Docker | vllm/vllm-openai | lmsysorg/sglang |
Per iniziare basta una singola riga di comando per ciascun motore su una macchina Linux con CUDA:
pip install vllm poi vllm serve Qwen/Qwen2.5-7B-Instruct — espone un’API compatibile con OpenAI sulla porta 8000.
pip install "sglang[all]" poi python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct — stessa forma di API sulla porta 30000.
Il parallelismo tensoriale su più GPU è specificato con --tensor-parallel-size 2 in vLLM e --tp 2 in SGLang. Entrambi caricano direttamente i pesi da Hugging Face. Per scegliere la scheda grafica più adatta, consulta la guida alla le migliori GPU per LLM locali e verifica i requisiti specifici di ciascun modello nella Database di modelli.
Dove le differenze si fanno sentire: la documentazione di vLLM, gli strumenti Kubernetes e le risposte della comunità sono semplicemente più numerose; è quindi più probabile che errori poco comuni abbiano già una soluzione su GitHub. L’installazione di SGLang a volte è più esigente riguardo alle combinazioni di versioni di CUDA/PyTorch; l’immagine Docker rappresenta il percorso a minor attrito.
Supporto per piattaforme
Linux
L’unica piattaforma nativamente supportata da entrambi. Le GPU NVIDIA con un driver recente compatibile con CUDA costituiscono il percorso principale; ROCm di AMD funziona su entrambi i framework con le schede supportate. Per ridurre al minimo i problemi legati alle versioni, utilizza le immagini Docker ufficiali.
Windows
Nessuno dei due motori supporta Windows in modo nativo. Entrambi possono essere eseguiti sotto WSL2 con il driver CUDA per WSL di NVIDIA, una configurazione perfettamente adeguata allo sviluppo. Per ambienti di produzione, invece, utilizza un vero host Linux. Se hai semplicemente bisogno di eseguire un modello localmente su un desktop Windows — senza dover fornire un endpoint di servizio — Ollama è lo strumento più semplice.
macOS
Nessun supporto per il serving su GPU Apple Silicon da parte di nessuno dei due progetti. vLLM può essere compilato da sorgente per inferenza CPU-only su macOS, ma questa funzionalità è pensata esclusivamente come comodità per lo sviluppo, non come target di distribuzione; SGLang non supporta affatto macOS. Per l’inferenza locale su Mac, usa Ollama o LM Studio, che sfruttano l’accelerazione GPU Metal di Apple.
Quale scegliere, in base al carico di lavoro
- Chatbot, assistenti, framework per agenti — prompt di sistema lunghi, strumenti integrati, cronologia multi-turno: SGLang. Questo è esattamente il tipo di traffico per cui è stato progettato RadixAttention.
- Estrazione strutturata ad alto volume — classificazione/estrazione su larga scala in formato JSON: SGLang, per la decodifica con salto in avanti (jump-forward decoding).
- Elaborazione batch di documenti unici — riassunti, pipeline correlate agli embedding con scarsa sovrapposizione tra i prompt: vLLM; il riutilizzo della cache non apporta vantaggi significativi e gli strumenti offerti da vLLM sono più completi.
- Molti modelli diversi o hardware non NVIDIA — AMD, Intel, TPU, Inferentia, checkpoint quantizzati esotici: vLLM, senza alcun dubbio il migliore in termini di copertura.
- Non sei sicuro: inizia con vLLM, quindi effettua un test A/B con SGLang utilizzando i tuoi veri log di richieste. La condivisione dell’API OpenAI rende il passaggio da uno all’altro una semplice modifica dell’URL base.
E prima di impegnarti definitivamente su uno dei due, verifica attentamente se l’auto-hosting risulta conveniente rispetto all’uso diretto di un’API, in base al tuo volume di richieste — il Calcolatore del punto di pareggio tra auto-hosting e utilizzo di API esegue questo calcolo per ogni modello e carico di richieste.
Domande frequenti
SGLang è più veloce di vLLM?
Nei carichi di lavoro con un intenso riutilizzo di prefissi o output strutturati, di solito sì — talvolta in misura significativa. Per prompt isolati e senza cache pre-riscaldata, le prestazioni dei due motori sono molto simili e i risultati possono variare da una versione all’altra. Esegui benchmark con il tuo reale pattern di traffico, anziché fare affidamento su un singolo valore pubblicato.
Posso usare l’SDK Python OpenAI con entrambi?
Sì. Entrambi espongono un endpoint compatibile con l’API OpenAI /v1/chat/completions quindi basta puntare l’SDK ufficiale verso base_url l’indirizzo http://localhost:8000/v1 (vLLM) o http://localhost:30000/v1 (SGLang), utilizzando una qualsiasi chiave API fittizia. È proprio questa compatibilità che rende quasi privo di costi il test A/B.
vLLM non dispone forse anch’esso della cache dei prefissi?
Sì, dispone di una cache automatica dei prefissi, abilitata di default nelle versioni più recenti, che riutilizza i blocchi KV il cui contenuto hashato corrisponde. L’albero radice (radix tree) di SGLang opera con granularità maggiore e il suo scheduler ordina attivamente le richieste per massimizzare il tasso di hit, motivo per cui SGLang mantiene generalmente il vantaggio nei carichi di lavoro intensivi sulla cache.
Quale motore supporta più modelli?
vLLM, senza dubbio — la sua lista di architetture supportate è la più lunga tra tutti i motori open source, specialmente per modelli multimodali e di nicchia. SGLang copre tutte le principali famiglie di modelli open-weight e spesso offre supporto fin dal primo giorno per i rilasci più importanti (le ottimizzazioni per DeepSeek, ad esempio, sono particolarmente efficaci), ma la lunga coda di modelli meno diffusi appartiene a vLLM. Verifica i requisiti specifici di ciascun modello nella Guida ai requisiti di VRAM.
Dove rientrano Ollama e llama.cpp?
Categoria diversa. Ollama e LM Studio sono strumenti locali monoutente, ottimizzati per la praticità su desktop, inclusi i Mac; SGLang e vLLM sono invece motori server ad alta concorrenza, progettati per massimizzare il throughput GPU su molte richieste simultanee. Se devi servire un singolo utente, usa Ollama; se devi servire un’applicazione, scegli uno di questi due.
