vLLM o SGLang? Quale motore scegliere per agenti e RAG

vLLM vs SGLang: quale scegliere?

vLLM è la scelta di partenza per il deployment. SGLang è il primo da valutare quando il carico di lavoro ruota attorno al contesto condiviso. Queste raccomandazioni si basano sulle procedure di deployment e sui controlli della cache documentati dai progetti; non implicano che un motore sia sempre più veloce dell'altro.

Per chi gestisce molte chat brevi, un prompt di sistema condiviso è un buon motivo per valutare SGLang, ma non per escludere vLLM: entrambi riutilizzano i calcoli già eseguiti sul prompt. Chi sta lanciando un'API semplice e ha poco tempo da dedicare all'infrastruttura può partire da vLLM, cambiando solo a fronte di un miglioramento dimostrato del servizio o dei costi.

Il RAG, o retrieval-augmented generation, aggiunge al prompt del modello i documenti recuperati. A rendere utile la cache dei prefissi è la parte iniziale del prompt che si ripete, non l'etichetta RAG.

Data di verifica: 14 ottobre 2026. Le ultime versioni stabili individuate durante la verifica sono vLLM 0.31.0, pubblicata il 5 ottobre, e SGLang 0.5.21, pubblicata il 2 ottobre. Le descrizioni delle funzionalità che seguono si basano sulla documentazione corrente dei progetti: la combinazione necessaria va verificata sulla versione fissata per il deployment. Per questo confronto non è stato eseguito alcun benchmark di inferenza.

Le licenze sono state verificate sulla licenza di vLLM e sul repository di SGLang. Le licenze dei pesi dei modelli, l'infrastruttura e il lavoro tecnico sono costi separati. Nessuno dei due motori open source prevede una tariffa hosted per token da confrontare.

Inferenza LLM: cosa fanno i due motori e dove si fermano

vLLM: il punto di partenza per il serving generalista

vLLM è un motore di inferenza e serving che carica i pesi del modello e pianifica l'esecuzione delle richieste sull'hardware disponibile. Tra i componenti documentati ci sono il continuous batching, che ammette nuove richieste man mano che altre terminano, e PagedAttention, che gestisce la cache key-value del modello a blocchi, anziché riservare a ogni richiesta un'unica grande area di memoria contigua. La cache KV conserva lo stato intermedio dell'attenzione, così il modello può continuare a generare senza ricalcolare l'intera cronologia. Documentazione di vLLM

Il motivo per partire da qui è la chiarezza di ciò che va distribuito: un modello, un'immagine ufficiale del server, un'API e istruzioni di installazione esplicite per ciascuna piattaforma. Per un team che sviluppa un endpoint di assistenza clienti, è una base gestibile da cui iniziare a misurare la capacità.

Il limite sta nella configurazione effettivamente validata. Una GPU supportata è solo il primo requisito: architettura del modello, quantizzazione, backend di attenzione e funzionalità richieste devono funzionare insieme. Per i servizi di valutazione conta un'eccezione precisa: secondo vLLM, una richiesta che include le log-probabilità del prompt salta la cache dei prefissi e ricalcola il prompt. Un endpoint di scoring può quindi comportarsi diversamente da un endpoint di chat che usa lo stesso documento. Guida a vLLM V1

Il motore costa $0. È indicato per il serving generalista e per un parco macchine eterogeneo; migrare a vLLM non è necessario se l'installazione SGLang esistente rispetta già gli obiettivi di servizio e offre tutte le funzionalità richieste.

SGLang: da valutare per primo quando gli agenti riusano il contesto

SGLang è un framework open source di inferenza per modelli linguistici e multimodali, che include i carichi di lavoro agentici tra le proprie priorità dichiarate. RadixAttention organizza lo stato riutilizzabile del prompt in base ai prefissi condivisi. L'estensione HiCache affianca alla cache GPU la memoria dell'host e lo storage. L'interesse pratico sta negli strumenti documentati per conservare e riutilizzare il contesto tra richieste ripetute. Repository di SGLang, architettura di HiCache

Si pensi a un agente che rilegge le stesse regole di assistenza e poi affronta domande diverse dei clienti. È un caso molto più convincente per valutare SGLang rispetto a prompt senza relazione tra loro che arrivano semplicemente con un'elevata concorrenza.

I limiti sono la località della cache e la parità delle funzionalità tra backend. I livelli GPU e memoria dell'host di HiCache appartengono a una singola istanza di inferenza. Lo storage diventa condiviso solo se il backend scelto viene configurato a questo scopo. Aumentare la cache dell'host non crea automaticamente una cache condivisa dall'intera infrastruttura. I livelli aggiuntivi comportano anche memoria da allocare, trasferimenti e configurazioni da gestire. Ambito di condivisione di HiCache

Il motore costa $0. È indicato quando il contesto ripetuto incide abbastanza da giustificare un lavoro di ottimizzazione; la sola parola «agenti» non giustifica il passaggio se i prompt condividono raramente un prefisso identico.

Cache dei prefissi e RadixAttention: la prima prova spetta a SGLang

SGLang merita la prima valutazione per carichi con diramazioni e contesto ricorrente; vLLM dispone già della funzionalità di caching essenziale. Non si tratta di scegliere tra PagedAttention e la possibilità di usare una cache. PagedAttention riguarda l'organizzazione della memoria, mentre il prefix caching riguarda il riuso dei calcoli. L'Automatic Prefix Caching di vLLM copre esplicitamente le domande ripetute su documenti lunghi e le conversazioni con più scambi. Cache dei prefissi di vLLM

Il prefill è il lavoro necessario per leggere il prompt prima che inizi la generazione. Il decode è il lavoro di generazione dei nuovi token. Un cache hit può evitare di ripetere il prefill, ma non elimina il decode necessario a scrivere una nuova risposta. Una risposta lunga con poco input condiviso può quindi beneficiare poco del riuso dei prefissi, con entrambi i motori.

Per un prodotto basato su chat brevi, conviene collocare le regole stabili e le descrizioni degli strumenti prima del contenuto variabile della richiesta, quando il formato di prompt previsto dal modello lo consente. Serializzazione e ordine dei documenti devono restare stabili. Un timestamp diverso vicino all'inizio può impedire il riuso di tutto il materiale identico che segue. È come un percorso condiviso: dopo una deviazione, ritrovare lo stesso paesaggio più avanti non rende identico il tragitto già percorso.

Il RAG a contesto lungo richiede una seconda verifica: il contesto è riutilizzabile o è soltanto lungo? Domande ripetute su un manuale invariato sono un ottimo caso d'uso per la cache. Un prodotto di ricerca che compone passaggi diversi, in un ordine diverso a ogni richiesta, potrebbe conservare soltanto il breve prefisso di sistema. I due casi vanno misurati separatamente prima di investire nello storage gerarchico.

Nella documentazione di SGLang, RadixAttention è attivo per impostazione predefinita ed è controllato da --disable-radix-cache; HiCache richiede una scelta di configurazione aggiuntiva. Con entrambi i motori bisogna controllare la configurazione effettiva, senza dedurre il comportamento della cache dal nome del progetto. Argomenti del server SGLang

Funzionalità per agenti: parità sul JSON, adapter e draft da validare

La necessità di produrre JSON, da sola, non fa prevalere nessuno dei due motori. Entrambi supportano la generazione vincolata da uno schema. Il modello sceglie i valori; la struttura va vincolata e il risultato validato prima di eseguire un'azione.

Output JSON strutturato

vLLM supporta JSON Schema attraverso response_format e le opzioni structured_outputs. Anche SGLang supporta JSON Schema e usa XGrammar come backend predefinito per le grammatiche. Si tratta di vincoli applicati alla decodifica, non di semplici istruzioni che chiedono al modello di «restituire JSON». Output strutturati di vLLM, output strutturati di SGLang

Per un agente di assistenza, uno schema può imporre la presenza di un'azione e dell'identificativo di un ticket. Non può stabilire che il ticket appartenga all'utente che invia la richiesta o che l'azione scelta sia giustificata. Questi controlli devono restare nel codice applicativo. Schemi reali, modalità di ragionamento e comportamento dello streaming vanno provati insieme: il supporto separato di ogni elemento non dimostra che la combinazione funzioni correttamente.

Verdetto: parità per le normali esigenze JSON. Conviene mantenere il motore già in uso, a meno che richieste rappresentative con gli schemi effettivi non facciano emergere una differenza concreta.

Decodifica speculativa

La decodifica speculativa è un'opzione di ottimizzazione presente in entrambi i progetti; non garantisce un aumento di velocità. Un meccanismo draft propone token che il modello target verifica. Le proposte utili e accettate possono ridurre il lavoro di generazione sequenziale, ma proposta, verifica e memoria hanno comunque un costo.

vLLM documenta EAGLE, la previsione di più token, modelli draft separati e metodi basati su n-gram e suffissi. Anche SGLang documenta EAGLE, la previsione di più token, modelli draft e NGRAM. La compatibilità tra draft, modello target, hardware e livello di traffico conta più della semplice presenza della funzione. Metodi di vLLM, metodi di SGLang

Verdetto: prevale il motore con una configurazione draft validata per il modello scelto. La decodifica speculativa va abilitata dopo aver misurato una configurazione di riferimento, per poi confrontare latenza delle risposte e capacità complessiva. Se il lavoro aggiuntivo non porta benefici con il carico di produzione, è meglio lasciarla disattivata.

Multi-LoRA per personalizzare il comportamento per cliente

Entrambi possono servire più adapter LoRA: piccole aggiunte ai pesi, ottenute con il fine-tuning, che personalizzano un modello base condiviso. vLLM espone la registrazione degli adapter tramite --lora-modules, con controlli sulla concorrenza e sul rank. SGLang espone --lora-paths e --max-loras-per-batch; il valore predefinito documentato è di 8 adapter per batch. Non è un limite al numero totale di clienti. LoRA in vLLM, LoRA in SGLang

Per un prodotto di scrittura personalizzato per cliente, va provata la distribuzione d'uso prevista degli adapter, inclusi quelli non ancora caricati e i cambi frequenti. L'opzione di caricamento sovrapposto di SGLang può nascondere i tempi di trasferimento, ma la documentazione avverte che può anche ridurre il batching del prefill con più adapter e aumentare la latenza del primo token. Più opzioni non significano automaticamente più capacità.

Verdetto: mantenere il motore di cui si è validata la gestione degli adapter. Il solo multi-LoRA non giustifica un cambio. SGLang merita una prova quando il collo di bottiglia è il caricamento degli adapter o un carico che dipende molto dalla cache. Per le TPU va consultata la matrice delle funzionalità del backend: la guida di SGLang-JAX indica ancora il multi-LoRA come in sviluppo. Matrice TPU di SGLang

Supporto hardware: vLLM è il punto di partenza per un parco macchine eterogeneo

Entrambi i progetti dichiarano il supporto per NVIDIA, AMD, TPU e CPU. I limiti effettivi dipendono dalla combinazione di backend e modello. L'elenco dell'hardware supportato dal progetto non garantisce che ogni configurazione GPU, adapter o metodo di decodifica possa essere trasferito senza modifiche.

• NVIDIA: vLLM documenta l'installazione su GPU CUDA; il repository di SGLang elenca le famiglie datacenter e RTX. Le immagini della versione corrente devono essere compatibili con il driver dell'host. Installazione GPU di vLLM, elenco hardware di SGLang
• AMD: entrambi documentano il deployment con ROCm. SGLang elenca Instinct MI300X, MI325X, MI350X e MI355X, con una guida di installazione separata. Occorre usare l'immagine ROCm e la configurazione del modello corrispondenti. Guida AMD di SGLang
• Google TPU: vLLM rimanda all'installazione separata di tpu-inference. La guida TPU di SGLang usa il backend separato SGLang-JAX ed elenca v6e e v7. Sono percorsi di deployment distinti, ciascuno con funzionalità da verificare. Installazione TPU di vLLM, guida TPU di SGLang
• CPU: tra le opzioni per CPU, vLLM documenta Intel/AMD x86 e ARM AArch64. La guida al server CPU di SGLang si rivolge specificamente a Intel AMX su processori Xeon Scalable di quarta generazione o successivi. «Supporto CPU» non significa copertura identica. Guida CPU di vLLM, guida CPU di SGLang

Una differenza operativa concreta può determinare il prossimo deployment: vLLM 0.31.0 pubblica un'immagine CUDA 12.9 oltre a quella predefinita CUDA 13.0. La guida di installazione corrente di SGLang richiede CUDA 13 e indica che la serie di immagini CUDA 12 si è fermata alla versione 0.5.19. Se il parco macchine non può ancora passare a un ambiente con driver compatibili, questo aspetto va chiarito prima di confrontare qualsiasi risultato di throughput. Artefatti della release di vLLM, installazione di SGLang

Server compatibili con OpenAI: migrare il client è più facile che migrare il carico

Entrambi i motori possono rispondere a un client che usa le chat completions in stile OpenAI. Entrambi documentano /v1/chat/completions e /v1/completions, riducendo le integrazioni applicative da sostituire. Questo non rende intercambiabili tutti gli endpoint, le estensioni, i parser per gli strumenti o i comportamenti dei modelli. Server di vLLM, API di SGLang

Un chat template trasforma i messaggi contrassegnati per ruolo nella sequenza di token attesa dal modello. Nel confronto tra motori deve restare invariato, altrimenti si rischia di confrontare due prompt diversi senza accorgersene. Anche revisione del modello, tokenizer, impostazioni di campionamento e limite di output devono coincidere.

Per un client vLLM già esistente, prima di una migrazione o di un aggiornamento vanno controllati i vecchi campi per l'output vincolato. La documentazione indica che guided_json e i campi correlati sono stati rimossi nella versione 0.12.0; il codice attuale deve usare il formato supportato con structured_outputs o response_format. Il corpo di una richiesta obsoleto può far sembrare incompatibile il motore. Nota di migrazione di vLLM

Verdetto: parità per l'interfaccia client di base; vLLM resta la raccomandazione di partenza sul piano operativo. Il test di accettazione deve coprire turni completi dell'agente, inclusi argomenti degli strumenti trasmessi in streaming, errori e tentativi ripetuti, senza fermarsi alla prima risposta testuale riuscita.

Come eseguire i due motori su una GPU cloud

Conviene partire da un container con versione fissata e da un piccolo modello per uno smoke test, per poi passare al modello di produzione e alla relativa allocazione di memoria. Gli esempi seguenti adattano i comandi Docker e di avvio documentati dai progetti a un host Linux con GPU NVIDIA, Docker, runtime NVIDIA per container e un driver compatibile con l'immagine. Sono stati verificati sulla documentazione, senza eseguirli su una GPU a noleggio. Docker per vLLM, guida rapida di SGLang

Il modello Qwen/Qwen3-0.6B qui sotto serve a verificare che i componenti comunichino correttamente; non è una raccomandazione sulla qualità delle risposte dell'agente. Va eseguito un motore alla volta sulla stessa porta. Il limite di contesto è un'impostazione esplicita dell'esempio, non il massimo dichiarato dal modello.

Container vLLM

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

Container SGLang

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

Dopo l'inizializzazione, eseguire questa richiesta sull'host GPU:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

Gli esempi associano la porta dell'host all'interfaccia di loopback. Prima di servire utenti remoti, occorre anteporre al server il gateway applicativo con autenticazione. Questo è particolarmente rilevante per vLLM: la documentazione specifica che --api-key non autentica tutte le route del server HTTP. Ambito dell'autenticazione di vLLM

Il worker vLLM documentato da Runpod

Runpod offre nel proprio Hub un worker vLLM pronto al deployment, corredato di documentazione. Questa scorciatoia cloud sostiene la raccomandazione di vLLM come scelta operativa iniziale. Il pacchetto del worker è un artefatto di deployment separato: occorre verificare la versione del motore inclusa, senza presumere che coincida con l'ultima release del progetto. Guida al deployment di Runpod

Per SGLang, il percorso cloud riproducibile descritto qui è il container ufficiale su un host GPU compatibile. La scorciatoia Runpod appena illustrata riguarda specificamente il worker vLLM documentato da Runpod.

Differenza di prezzo: a parità di GPU, la spesa è identica

A parità di capacità noleggiata, nessuno dei due motori costa meno. Il 14 ottobre 2026, la pagina dei prezzi di Runpod riportava per i Pods una A100 PCIe da 80 GB a $1.79/ora. È il prezzo di una GPU dedicata, non la tariffa del worker Serverless. È il costo infrastrutturale comune usato nei calcoli seguenti. Prezzi di Runpod

Considerando un mese convenzionale di 730 ore ai fini del budget, una GPU mantenuta sempre allocata costa $1,306.70/mese, sia con vLLM sia con SGLang. Due costano $2,613.40/mese. Sono esclusi storage, costi di rete, ridondanza e lavoro tecnico.

Prendiamo come riferimento un ipotetico carico di assistenza: 50,000 richieste al mese, ciascuna con 2,000 token di input e 200 token di output. In totale sono 100 milioni di token di input e 10 milioni di token di output effettivamente restituiti. Se una sola GPU sostiene il carico entro i tempi di risposta richiesti, la spesa GPU di entrambi i motori è di $0.13067 per 1,000 token di output restituiti. Il denominatore considera i token di output, ma la spesa copre anche la lettura dell'input.

È un calcolo dei costi, non una misura della capacità. Se una GPU non basta a sostenere il carico, il risultato relativo a una sola GPU non è applicabile.

Il punto in cui cambia la convenienza è quello in cui una configurazione richiede una replica aggiuntiva per rispettare lo stesso obiettivo di servizio. Se SGLang richiede una GPU e vLLM due, SGLang fa risparmiare $1,306.70/mese. Se il rapporto tra le capacità misurate si inverte, vLLM fa risparmiare la stessa cifra. Se a entrambi basta una GPU, il risparmio infrastrutturale è zero.

Con un budget di migrazione di 8 ore a una tariffa ipotetica di $100/ora, il costo è di $800. Eliminare una GPU di questo tipo permette di recuperarlo in circa 0.61 mesi, prima di considerare eventuali differenze nella gestione corrente. Senza una replica in meno o un miglioramento del servizio cui si attribuisce valore, «più veloce» può non produrre alcun ritorno economico.

Verdetto sui costi: prevale la configurazione che rispetta l'obiettivo con il costo operativo complessivo più basso. Prima di misurare la capacità sostenibile del proprio carico, non è possibile indicare onestamente una soglia di traffico oltre la quale convenga uno specifico motore.

Throughput: conta il lavoro completato entro la latenza richiesta

Questo confronto non stabilisce un vincitore universale sul throughput. Un risultato pubblicato da un progetto vale per il modello, l'hardware, la precisione, le lunghezze delle richieste e la release con cui è stato ottenuto. Un miglioramento del kernel non equivale a un miglioramento del serving nel suo complesso, e il throughput del prefill non è il throughput dei token di output. Nessuno dei due giustifica affermazioni generiche come «SGLang è più veloce» o «vLLM è più veloce».

Gli strumenti dei progetti sono un buon punto di partenza: CLI per i benchmark di vLLM e guida ai benchmark di serving di SGLang. Il confronto deve includere prove con cache calda e fredda e riprodurre le caratteristiche del carico generato dal prodotto.

Vanno misurate separatamente quattro condizioni: chat brevi con un prompt di sistema stabile e condiviso; domande ripetute sullo stesso documento lungo; prompt RAG lunghi con passaggi recuperati che cambiano; combinazione effettiva di schemi, chiamate agli strumenti e adapter. Oltre alla concorrenza, vanno preservati i tempi di arrivo delle richieste. Un'ondata di richieste simultanee e un flusso costante possono far emergere colli di bottiglia diversi.

Registrare richieste completate, token di output restituiti, errori e latenza del primo token. Controllare anche le latenze p95 e p99, ossia il 95° e il 99° percentile: una buona media può nascondere tempi molto lunghi nella coda della distribuzione. Gli output che non superano i controlli applicativi sullo schema o sulla correttezza vanno conteggiati come errori, non come capacità utile.

Prevale il deployment meno costoso che resta entro questi criteri di accettazione. Un'affermazione di velocità riferita a un altro modello o a una release precedente è un motivo per eseguire il confronto, non la risposta.

Cambiare motore: preservare il contratto applicativo e prevedere il rollback

Il livello di serving va migrato solo quando il beneficio misurato supera i costi di migrazione e gestione. Se cambia soltanto il backend di generazione, i dati applicativi e l'archivio usato per il retrieval possono in genere restare dove sono. Il lavoro riguarda il packaging del modello, le estensioni delle richieste, il parsing dell'output e il comportamento del deployment.

Non serve abbandonare un deployment vLLM che funziona bene soltanto per ottenere cache dei prefissi o vincoli JSON: dispone già di entrambi. Allo stesso modo, non serve abbandonare un deployment SGLang che funziona bene soltanto perché qui vLLM è la raccomandazione di partenza. La competenza operativa già acquisita fa parte del confronto dei costi.

Se resta da capire se serva davvero un server condiviso in produzione, il riferimento è Ollama vs vLLM. Quel confronto affronta la scelta precedente: un comodo flusso di lavoro locale con i modelli oppure un livello di serving per richieste che si sovrappongono.

Il passo successivo è raccogliere traffico di picco rappresentativo, fissare tempi di risposta e tasso di errore massimi accettabili, quindi confrontare i motori nelle versioni scelte sullo stesso hardware prima di ampliare il parco macchine.

Domande frequenti

La checklist per l'audit dei flussi di lavoro aziendali con l'IA aiuta a individuare quale flusso merita un server condiviso per modelli; la newsletter permette di seguire i successivi cambiamenti negli strumenti.