Ollama o vLLM: quale server LLM scegliere

Ollama e vLLM in un paragrafo

Ollama è un gestore di modelli con un server integrato: scarica i pesi quantizzati, li carica e risponde su 127.0.0.1:11434, usando la CPU se il computer dispone solo di quella. vLLM è un motore per il throughput: mantiene occupata una GPU gestendo molte richieste contemporaneamente, quindi è lo strumento sbagliato su una macchina senza GPU. Questa è l'intera decisione. Una persona che parla con un assistente locale è un caso d'uso per Ollama. Un'applicazione che serve un team è un caso d'uso per vLLM.

Entrambi espongono un'API HTTP compatibile con OpenAI, quindi il codice client passa dall'uno all'altro modificando l'URL di base. L'API non è la differenza. La differenza è ciò che accade quando arriva una seconda richiesta mentre la prima sta ancora generando token.

Che cos'è realmente Ollama

Ollama è un livello di praticità. Con un solo comando di installazione fornisce un registro dei modelli (ollama pull llama3.1:8b), un archivio locale dei pesi, un prompt di chat, un servizio systemd e un'API HTTP. I modelli che distribuisce sono file GGUF, generalmente quantizzati a 4 bit. Per questo un modello 7B o 8B occupa circa 5 GB su disco invece di 16 GB. La quantizzazione rende possibile l'inferenza sulla CPU.

Il suo runner si basa su llama.cpp, la libreria di inferenza C++ che ha reso pratica la quantizzazione GGUF sull'hardware comune. Da allora Ollama ha aggiunto un proprio engine per alcune famiglie di modelli più recenti, ma llama.cpp è ancora il substrato della maggior parte di ciò che distribuisce. Quindi, quando si confrontano Ollama e llama.cpp, si confronta soprattutto un livello di ergonomia con il componente che avvolge.

Il sistema è progettato per un solo utente. A luglio 2026, il valore predefinito di OLLAMA_NUM_PARALLEL è 1. Questo significa che un modello elabora una richiesta alla volta e tutte le altre attendono in una coda che contiene 512 elementi per impostazione predefinita (OLLAMA_MAX_QUEUE). È possibile aumentare l'impostazione della concorrenza. La sezione seguente spiega quali costi comporta. Se non hai mai eseguito Ollama, inizia da ospitare Ollama su un VPS e mantenere chiusa la porta 11434, perché l'API non dispone di alcun tipo di autenticazione.

Che cos'è realmente vLLM

vLLM è esclusivamente un server di inferenza. Non gestisce una libreria di modelli, non include prompt per la chat e non scarica automaticamente un modello al momento della richiesta. All'avvio si specifica un repository di Hugging Face. vLLM carica quel modello e lo serve fino all'arresto del processo.

Il vantaggio di questa specializzazione è il throughput. Il risultato dipende da due meccanismi. PagedAttention archivia la KV cache (cache key-value, ovvero lo stato dell'attenzione per ogni token che il modello conserva per ogni richiesta attiva) in blocchi di dimensione fissa, come un sistema operativo gestisce la memoria mediante paginazione. Una richiesta non richiede più una grande area contigua riservata in base al caso peggiore. La memoria che prima rimaneva riservata e inutilizzata diventa quindi disponibile per un numero maggiore di richieste simultanee. Il continuous batching consente a una nuova richiesta di unirsi al batch in esecuzione al passaggio successivo della decodifica, invece di attendere il completamento del batch corrente. Quando una sequenza termina, lascia immediatamente il batch e il relativo slot viene riutilizzato.

Il risultato pratico è il seguente: su una singola GPU, passando da un utente simultaneo a trenta, il numero totale di token al secondo aumenta nettamente, mentre la velocità per utente diminuisce molto meno di quanto ci si aspetterebbe. Con le impostazioni predefinite di Ollama, passare da un utente a trenta fa semplicemente attendere ventinove persone.

Il batching continuo fa tutta la differenza

Immagina cinque richieste che raggiungono ciascun server nello stesso momento, su hardware identico.

Con le impostazioni predefinite, Ollama esegue la prima richiesta fino al completamento, poi la seconda e così via. Il quinto chiamante attende quattro generazioni complete. La velocità di elaborazione complessiva è all'incirca quella di una sola generazione, perché il processore lavora sempre e solo su una sequenza.

vLLM esegue il decoding di tutte e cinque le richieste nello stesso passaggio forward. Generare un token per cinque sequenze costa appena più che generare un token per una sola sequenza, perché la parte costosa consiste nel leggere i pesi del modello dalla memoria, e questa lettura è condivisa dall'intero batch. Questo è lo stesso limite di larghezza di banda della memoria che rende lenta l'inferenza sulla CPU: il costo principale è lo spostamento dei pesi, non l'aritmetica.

Puoi impostare OLLAMA_NUM_PARALLEL=4 e ottenere parte di questo comportamento. Il costo è la memoria. Ogni slot parallelo richiede la propria cache KV e Ollama suddivide la finestra di contesto tra gli slot; quindi, quattro richieste parallele verso un modello configurato per 8192 token lasciano a ciascuna richiesta 2048 token di contesto. La cache paginata di vLLM evita questo compromesso, perché i blocchi vengono allocati a una richiesta man mano che la richiesta cresce effettivamente.

Installare e servire con Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Lo script di installazione crea un utente di sistema ollama, installa il binario e registra ollama.service associato a 127.0.0.1:11434. La riga eval rate visualizzata da --verbose indica i token al secondo effettivi su quel sistema. È più affidabile di qualsiasi dato pubblicato.

Per aumentare la concorrenza, usa un drop-in di systemd, così un aggiornamento non sovrascrive la modifica:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps mostra ciò che è caricato e la relativa colonna PROCESSOR indica il valore effettivo. 100% CPU significa che non viene utilizzata alcuna GPU. Questa è la spiegazione corretta per la maggior parte dei casi in cui Ollama è lento.

Installare e servire con vLLM

vLLM richiede Linux e Python da 3.10 a 3.13. Installarlo in un ambiente virtuale dedicato, perché installa una build specifica di PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Quindi avviare un modello. Il nome è l'ID di un repository Hugging Face, non un tag breve:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Il primo avvio è lento perché scarica i pesi e poi profila la GPU per determinare quanti blocchi di cache KV possono essere contenuti. Il servizio è in ascolto sulla porta 8000. Verificarlo prima di scrivere il codice client:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Se Docker è già installato sul server, l'immagine ufficiale evita di gestire la dipendenza CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host è obbligatorio, non decorativo: PyTorch trasferisce i tensori tra processi tramite la memoria condivisa e l'allocazione predefinita della memoria condivisa di Docker è troppo piccola per l'inferenza con parallelismo sui tensori.

I flag più importanti in produzione sono --max-model-len (la finestra di contesto che si è disposti a pagare), --gpu-memory-utilization (la frazione della scheda che vLLM può utilizzare, 0.92 per impostazione predefinita a luglio 2026), --tensor-parallel-size per distribuire un singolo modello su più GPU e --api-key.

L'autenticazione è un flag in vLLM ed è assente in Ollama

vLLM impone un bearer token se ne viene specificato uno:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Lo stesso valore può provenire dalla variabile di ambiente VLLM_API_KEY. Una richiesta che non lo include riceve una risposta HTTP 401. Questo non giustifica comunque la pubblicazione della porta 8000 su un'interfaccia pubblica, perché vLLM non applica il rate limiting e un token trasmesso tramite HTTP in chiaro può essere letto durante il transito. Tuttavia, il server dispone di un meccanismo per identificare il chiamante.

Ollama non dispone di alcun meccanismo analogo. Non esistono chiavi, accesso autenticato o allow-list. Qualsiasi processo che possa raggiungere la porta 11434 può eseguire, scaricare o eliminare modelli. Mantienilo sull'interfaccia di loopback e raggiungilo tramite una VPN WireGuard ospitata autonomamente, oppure tramite un reverse proxy che richieda l'autenticazione e termini TLS (transport layer security).

Hardware: requisiti di ciascuno

Ollama viene eseguito sulla CPU. Un modello quantizzato a 4 bit richiede circa mezzo gigabyte di RAM per ogni miliardo di parametri, oltre a circa un gigabyte di overhead di runtime e a ulteriore memoria per il contesto. Un modello 3B richiede quindi circa 4 GB liberi, mentre un modello 8B ne richiede circa 8 GB. La velocità su una vCPU condivisa varia da una cifra bassa a una velocità a due cifre basse in token al secondo. Il limite dipende dalla larghezza di banda della memoria, non da una configurazione errata, e nessun flag può risolverlo.

vLLM presuppone la presenza di una GPU. Il percorso predefinito usa pesi non quantizzati con precisione a 16 bit, che richiedono circa 2 GB per ogni miliardo di parametri. Un modello 8B richiede circa 16 GB di memoria video solo per i pesi, prima di considerare la cache KV necessaria per la concorrenza per cui è stato installato vLLM. Su una scheda da 24 GB rimane una cache utilizzabile. Su una scheda da 16 GB, invece, non rimane spazio sufficiente. Devi quindi scegliere un modello più piccolo oppure passare --quantization con un checkpoint quantizzato. Esiste un backend per la CPU, ma i pacchetti standard non sono compilati per questo backend e viene meno il motivo stesso per eseguire vLLM.

Di conseguenza, nella maggior parte dei casi la domanda sull'hardware determina la scelta del software. Se non hai una GPU, usa Ollama. Se una GPU a noleggio resta al 5 percento di utilizzo perché le richieste vengono serializzate, usa vLLM.

Quale scegliere per il carico di lavoro

• Una persona, un VPS con CPU, per redigere e riassumere: Ollama. La velocità è accettabile e non esiste una soluzione più semplice.
• Un assistente per la programmazione o un server MCP che collega i tuoi strumenti a un modello locale, utilizzato solo da te: Ollama. La concorrenza pari a 1 è il carico di lavoro effettivo.
• Il confronto tra cinque modelli questa settimana: Ollama. Scaricare ed eliminare modelli con tag è esattamente ciò per cui è progettato, mentre vLLM richiede il riavvio del processo per ogni modello.
• Un'applicazione interna, un prodotto di chat o una pipeline di recupero con utenti reali: vLLM. In questo caso il batching giustifica il costo della GPU.
• Un processo batch che valuta centomila documenti durante la notte: vLLM, con un --max-num-seqs elevato. Il throughput è l'unica metrica importante, mentre la latenza per documento non lo è.
• Una piattaforma per agenti in cui diversi agenti AI self-hosted accedono contemporaneamente al modello: vLLM, perché il traffico degli agenti è irregolare e per sua natura parallelo.

Modalità di errore e stringhe visualizzate

vLLM non si avvia e restituisce un errore relativo alla cache KV. Il messaggio contiene entrambi i valori:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Il modello dichiara una finestra di contesto più grande della memoria disponibile dopo il caricamento dei pesi. Riducila con --max-model-len 8192 oppure aumenta --gpu-memory-utilization se nessun altro processo utilizza la scheda. Superare un utilizzo di circa 0.95 tende a sostituire questo errore di avvio con un arresto anomalo CUDA per memoria insufficiente in un secondo momento, sotto carico. È l'esito peggiore tra i due.

Ollama stampa Killed durante la generazione. Il killer Linux per mancanza di memoria ha arrestato il processo perché il modello richiedeva più RAM di quella disponibile sul sistema. Verifica con sudo dmesg | grep -i oom. La soluzione consiste nell'utilizzare un modello più piccolo o con una quantizzazione più aggressiva, non nel modificare un'impostazione.

Ollama risponde correttamente da solo, ma si blocca sotto carico. Non viene visualizzato alcun errore. Le richieste richiedono semplicemente più tempo all'aumentare del numero di chiamanti, perché OLLAMA_NUM_PARALLEL=1 le serializza. Aumentalo e accetta un contesto più piccolo per richiesta, oppure sposta il carico di lavoro su vLLM.

vLLM restituisce 401 per ogni chiamata. Lo hai avviato con --api-key, ma il client non invia alcun header Authorization. La maggior parte delle librerie client OpenAI invia come chiave il valore specificato. Impostalo quindi nel client invece di rimuovere il flag.

vLLM indica che il modello non è stato trovato. Ollama scarica i modelli quando necessario, mentre vLLM non lo fa. Il campo model nel corpo della richiesta deve corrispondere all'ID del repository con cui hai avviato il modello oppure al valore di --served-model-name, se lo hai impostato. Verifica la stringa esatta con curl http://localhost:8000/v1/models.

Eseguire entrambi è una scelta ragionevole

Non si escludono a vicenda. Un'architettura comune prevede vLLM su un'istanza GPU per servire l'applicazione e Ollama sul VPS ordinario accanto, per gli script locali, i processi cron e la prova delle nuove release dei modelli. Entrambi gli endpoint sono compatibili con OpenAI, quindi una sola libreria client e la modifica dell'URL di base sono sufficienti. Il controllo dei costi è più importante del motore scelto, perché una GPU inattiva viene addebitata quanto una GPU sotto carico; inoltre, mantenere prevedibili i costi degli agenti e dell'inferenza è un'attività distinta dalla scelta del server.

FAQ

vLLM è più veloce di Ollama?

Per una singola richiesta sulla stessa GPU, la differenza è contenuta, perché entrambi eseguono gli stessi calcoli. Per molte richieste simultanee, vLLM è nettamente più veloce, perché il continuous batching decodifica ogni sequenza attiva in un'unica forward pass, mentre la configurazione predefinita di Ollama le esegue una alla volta. Su una macchina solo CPU, il confronto non è applicabile: Ollama funziona anche in questo ambiente, mentre vLLM di fatto no.

vLLM può funzionare senza una GPU?

Non in modo utile. I pacchetti standard sono destinati alle GPU NVIDIA o AMD e, su una CPU, viene meno il motivo per cui esiste vLLM: mantenere un acceleratore saturo con richieste raggruppate. Esiste un backend CPU per le attività di sviluppo. Per l'inferenza reale su CPU, usa direttamente Ollama o llama.cpp.

Qual è la differenza tra Ollama e llama.cpp?

llama.cpp è la libreria di inferenza e GGUF è il suo formato per i pesi quantizzati. Il runner di Ollama è basato su llama.cpp e aggiunge i componenti che llama.cpp lascia all'utente: un registro dei modelli, il download automatico, un server residente, un'unità systemd e un endpoint compatibile con OpenAI. Ollama ha aggiunto un proprio engine per alcune famiglie di modelli più recenti, quindi i due strumenti non sono più identici internamente.

Quanta memoria GPU richiede vLLM per un modello 8B?

Con precisione a 16 bit, i soli pesi occupano circa 16 GB, cioè approssimativamente 2 GB per ogni miliardo di parametri, e la KV cache richiede ulteriore spazio. Una scheda da 24 GB offre un margine adeguato. Una scheda da 16 GB richiede un checkpoint quantizzato o un modello più piccolo. vLLM riserva una frazione della memoria della scheda impostata da --gpu-memory-utilization, che a luglio 2026 ha valore predefinito 0.92.

Devo modificare il codice dell'applicazione per passare da uno all'altro?

Di solito devi modificare solo l'URL di base, la chiave API e il nome del modello. Ollama espone la propria interfaccia compatibile con OpenAI su http://127.0.0.1:11434/v1 e ignora la chiave, mentre vLLM espone http://localhost:8000/v1 e verifica la chiave se ne imposti una. I nomi dei modelli hanno formati diversi: llama3.1:8b per Ollama e un ID completo del repository, come Qwen/Qwen2.5-1.5B-Instruct, per vLLM.