vLLM: servire modelli veloci

Ollama ha reso facile eseguire l'IA in locale: un comando, un modello, una conversazione. Ma esiste un limite oltre il quale non basta più — e sapere dove sta quel limite è un sapere. Lo noti quando più persone usano lo stesso modello, quando ti serve il modello dentro un'applicazione e non in una chat, quando una GPU deve fare più lavoro di una richiesta alla volta.

È qui che entra in scena vLLM. vLLM è un motore open source di inferenza e serving per i grandi modelli linguistici, nato al laboratorio UC Berkeley e oggi mantenuto da una comunità di oltre 2.000 contribuenti. È il motore che sta dietro a molte installazioni in produzione, locali e nel cloud. In questa guida ti spiego cos'è, quando conviene usarlo, come si installa e quali sono i concetti di base — throughput, quantizzazione, KV cache — che servono per dimensionare un'installazione.

Cos'è vLLM

vLLM è una libreria Python. Gli dai un modello (scaricato da Hugging Face) e lui lo serve come server HTTP con un'API compatibile con OpenAI: gli stessi endpoint, lo stesso formato delle richieste, le stesse risposte che ottieni dall'API ufficiale. Questo dettaglio conta: tutti gli strumenti costruiti per OpenAI (chat, applicazioni, librerie) funzionano con vLLM semplicemente cambiando l'indirizzo.

Due tecnologie rendono vLLM veloce.

PagedAttention. Per generare una risposta, il modello tiene un conto di tutto ciò che ha visto finora: per ogni token, le chiavi e i valori dell'attenzione (il cosiddetto KV cache). Questo conto cresce con la lunghezza del contesto e consuma molta memoria. PagedAttention gestisce questa memoria in piccoli blocchi, come fa un sistema operativo con la memoria virtuale. Risultato: nessuna memoria riservata e lasciata inutilizzata, e un contesto che può crescere senza frammentazioni.

Continuous batching (batching continuo). Quando arrivano più richieste, vLLM le tratta insieme in un batch. E non si ferma quando una richiesta finisce: la successiva in coda entra a metà passo, al posto di quella terminata. La GPU non resta mai ferma, nemmeno mentre aspetta che la risposta più lunga si completi.

L'effetto pratico è la differenza tra un server che tratta le richieste una alla volta e uno che ne gestisce molte insieme: con la stessa GPU, vLLM può moltiplicare di molte volte il numero di utenti simultanei e la produzione totale.

Quando usare vLLM, e quando basta Ollama

vLLM non è il successore di Ollama, e non è "migliore" in assoluto. Risolve un problema diverso.

Caso d'uso	Strumento
Un utente, una conversazione alla volta, zero configurazione	Ollama o LM Studio
Più persone usano lo stesso modello in rete	vLLM
Un'applicazione che chiama il modello via API (assistente, documenti, servizio interno)	vLLM
Vuoi output strutturato (JSON) e tool calling dentro le tue app	vLLM
Vuoi misurare e massimizzare il throughput di una GPU	vLLM
Vuoi solo chattare con un modello, in fretta	Ollama

La regola pratica: un utente, Ollama; più utenti o un'applicazione, vLLM. Ollama vince in semplicità (un comando, libreria di modelli integrata, gira anche su CPU); vLLM vince in throughput e integrazione. I due possono coesistere: Ollama per provare un modello, vLLM per metterlo al lavoro.

Una nota hardware: vLLM si aspetta una GPU NVIDIA con CUDA (e da recenti versioni gira anche su AMD, Intel e TPU, e supporta Apple Silicon e CPU, ma con prestazioni e caratteristiche diverse). Per l'uso locale classico, una GPU NVIDIA con almeno 12-16GB di VRAM è un punto di partenza ragionevole.

Installazione

vLLM si installa come pacchetto Python. Il metodo raccomandato è con uv, il gestore di pacchetti Python veloce:

uv pip install vllm

Oppure con pip, se già lo usi:

pip install vllm

Se non vuoi toccare Python sulla macchina, c'è un'immagine Docker ufficiale:

docker run --gpus all -p 8000:8000 vllm/vllm-openai serve Qwen/Qwen2.5-7B-Instruct

Un'avvertenza: vLLM è un bersaglio in movimento. Il ritmo di rilascio è molto veloce (una nuova versione minore quasi ogni mese), e ogni rilascio porta nuovi modelli, nuove quantizzazioni, nuovi hardware. Installa la versione corrente e leggi le release notes — la funzione che ti serve (un modello specifico, una quantizzazione specifica) magari è appena arrivata.

I concetti base per dimensionare l'installazione

Throughput. Misurato in token al secondo, è la produzione del sistema. Ci sono due numeri, e raccontano cose diverse: la latenza di un singolo utente (quanto è veloce la tua risposta, token per token) e il throughput (token totali generati da tutti gli utenti simultanei). vLLM è ottimizzato per il secondo: può sacrificare un po' di velocità di ciascuna risposta singola in cambio di un grande guadagno sul numero di risposte servite insieme. Se c'è un solo utente, questo scambio non conviene — ed è per questo che Ollama basta.

KV cache e VRAM. La memoria che serve a un server ha tre componenti: i pesi del modello, il KV cache (che cresce con la lunghezza del contesto e con il numero di utenti simultanei) e i calcoli intermedi. Un modello da 7B in FP16 occupa circa 14GB solo per i pesi. Quantizzato a 8 bit (INT8 o FP8) scende a 7-8GB. Su una scheda da 24GB hai spazio per un modello da 14B a 8 bit, oppure per un modello da 7B con un contesto molto lungo e molti utenti simultanei.

Quantizzazione. Quantizzare significa rappresentare il modello con meno bit per ogni peso: 16 (FP16, precisione completa), 8 (INT8/FP8), 4 (INT4, GPTQ/AWQ, GGUF). Meno bit significa meno memoria occupata e una GPU più veloce; il prezzo è una piccola perdita di qualità, che varia da modello a modello e da quantizzazione a quantizzazione. vLLM supporta FP8, INT8, INT4 e formati a 4 bit come NVFP4 e GGUF. Scegliere la quantizzazione giusta è un compromesso da provare in pratica, non solo in teoria: parti da 8 bit e scendi a 4 bit solo se ti serve più contesto o più utenti simultanei.

Batch size e concorrenza. Il parametro --max-num-seqs fissa il numero massimo di richieste trattate in parallelo. Alzalo se hai molti utenti e tanta VRAM; tienilo basso se vuoi che ciascuna risposta singola sia la più veloce possibile.

Mettere in moto un primo modello

Ecco la sequenza minima per andare da zero a un'API che risponde.

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --served-model-name qwen7b \
  --max-model-len 8192

vLLM scarica il modello da Hugging Face al primo avvio, lo carica sulla GPU e avvia un server sulla porta 8000. Per provarlo:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen7b", "messages": [{"role": "user", "content": "Ciao, chi sei?"}]}'

La risposta è un JSON in formato OpenAI. Da qui in poi il resto è semplice: punti Open WebUI o qualunque altro client verso http://localhost:8000/v1 e usi il modello come se fosse l'API di OpenAI.

Consigli pratici

1. Parti da Ollama. Prova prima il modello con Ollama (o LM Studio): capire se il modello è adatto al tuo caso d'uso, prima di investire in un server.
2. Passa a vLLM quando l'uso è condiviso. Un utente su un portatile: vLLM aggiunge complessità senza beneficio. Una rete di tre macchine o più, o un'applicazione che chiama il modello: vLLM conviene subito.
3. Misura, non indovinare. Dopo l'installazione, testa la latenza con un solo utente e il throughput con alcune richieste concorrenti. I numeri ti dicono se l'hardware è adatto.
4. Non quantizzare troppo. 8 bit è la scelta sicura di default; 4 bit solo quando ti serve contesto o concorrenza.
5. Segui i rilasci. Il ritmo è veloce: una versione che non supportava un modello che ti interessa può averlo fatto da un mese.

In sintesi

vLLM è il passo che porta l'IA locale da "il mio assistente" a "il mio servizio": lo stesso modello, la stessa GPU, ma un server vero — concorrente, misurabile, integrabile in qualsiasi applicazione. Quando conviene usarlo? Quando ci sono più utenti, o quando il modello lavora dentro un'applicazione. Quando conviene restare su Ollama? Quando sei in uno e fai una conversazione: in quel caso la semplicità vince.

Articolo generato con IA