12 novembre 2026 · Team VRAMfarm

vLLM vs Ollama vs llama.cpp: con quale far girare il tuo LLM, e i comandi

Se con il modello parli solo tu, i tre sono veloci più o meno allo stesso modo e Ollama è quello che richiede meno lavoro: un comando di installazione e un ollama run. Se uno script lancia 50 richieste in parallelo o dieci colleghi usano lo stesso modello, vLLM tira fuori dalla stessa scheda circa 5–10 volte più token al secondo in totale, e il divario cresce con il carico. llama.cpp, il motore da cui è nato Ollama, è quello da scegliere quando vuoi controllare ogni byte: file di quantizzazione precisi, tipi di cache, quali layer restano sulla CPU.

Tutti e tre girano su un server a noleggio con un’immagine PyTorch vuota, e tutti e tre offrono un’API compatibile con OpenAI. Le differenze stanno nel batching, nei formati dei file e nel modo in cui trattano la memoria.

In breve

Ollama è costruito sulle stesse basi GGML di llama.cpp, quindi formati dei file, livelli di quantizzazione e velocità con un solo utente sono simili. Ollama aggiunge comodità: una libreria di modelli con nomi brevi, il rilevamento automatico della GPU, modelli caricati su richiesta. Nasconde invece il controllo, e te ne accorgi il giorno in cui un modello va lento e devi capire perché.

Velocità: una conversazione contro cinquanta

In una singola conversazione la generazione del testo è limitata dalla banda di memoria: per ogni nuovo token la scheda legge l’intero modello una volta. Conta meno il runtime e più la dimensione del file. Ne esce un risultato che molti non si aspettano: vLLM che serve un modello da 8B nel suo BF16 originale (16 GB) è più lento, per un solo utente, di Ollama con un file a 4 bit (5 GB), semplicemente perché per ogni token legge il triplo dei byte.

Il batching cambia il quadro. vLLM legge i pesi una volta per un intero batch di richieste e aggiunge le nuove al batch in corso man mano che le vecchie finiscono, quindi l’output totale cresce quasi in modo lineare con gli utenti finché non si esauriscono calcolo o memoria per la cache. Ecco degli intervalli indicativi per un modello da 8B su una RTX 4090, ricavati da calcoli sulla banda e da report della community, non da benchmark nostri:

La velocità con un solo utente basta e avanza in ogni riga: le persone leggono a 5–8 token al secondo. Il divario si apre con il carico: un bot di assistenza, uno strumento interno per un team, o un lavoro batch che di notte classifica 100.000 descrizioni di prodotti. Per questi casi vLLM è il motore giusto, e il costo per milione di token mostra cosa significa sul conto.

Vale la pena conoscere altri due motori. SGLang è un’alternativa molto vicina a vLLM, con formati simili e un server compatibile con OpenAI, forte quando molte richieste condividono un lungo prefisso. TensorRT-LLM spreme il massimo dalle schede NVIDIA da data center, ma richiede più configurazione. Se stai scegliendo tra i primi tre, non ti serve nessuno dei due.

Come ciascuno tratta la memoria

Quasi tutte le storie di “andava lento” e “è andato in crash” nascono da qui.

Ollama sposta sulla CPU senza dirtelo. Se il modello più il suo contesto non ci stanno, Ollama sposta alcuni layer nella RAM di sistema e continua a una frazione della velocità. In una nostra prova, Qwen3 32B su una scheda da 24 GB con un contesto di 32k ha mandato il 18% dei layer sulla CPU ed è sceso da circa 30 token al secondo a 2,5. Esegui ollama ps: la colonna PROCESSOR dovrebbe dire 100% GPU. Imposta il contesto con OLLAMA_CONTEXT_LENGTH, e ricorda che OLLAMA_NUM_PARALLEL moltiplica la cache: quattro slot in parallelo con 8k di contesto richiedono la cache di 32k.

llama.cpp fa esattamente quello che gli dici. -ngl stabilisce quanti layer vanno sulla GPU (99 significa tutti), -c il contesto totale e -np il numero di slot paralleli che se lo dividono: -c 32768 -np 4 dà a quattro utenti circa 8k ciascuno. Per i modelli mixture-of-experts che non ci stanno, --n-cpu-moe tiene una parte dei pesi degli expert nella RAM di sistema mentre i layer condivisi restano sulla GPU, e così i grandi modelli MoE girano su schede più piccole a una velocità utilizzabile.

vLLM riserva la memoria in anticipo. Di default all’avvio prende il 90% della scheda e riempie con la KV cache quello che i pesi non usano. Poi verifica che ci stia una richiesta con il contesto massimo, e se non ci sta si rifiuta di partire; l’errore indica il contesto più grande che ci starebbe. Imposta --max-model-len su quanto ti serve davvero, e abbassa --gpu-memory-utilization se qualcos’altro deve condividere la scheda. La guida a CUDA out of memory copre il resto.

Ollama: comandi di avvio

Su un server PyTorch vuoto, nel terminale di Jupyter o via SSH:

curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 \
  ollama serve > /workspace/ollama.log 2>&1 &
ollama run qwen3:8b

Funziona anche qualsiasi GGUF da Hugging Face: ollama run hf.co/<user>/<repo>:Q4_K_M. L’API ascolta sulla porta 11434:

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" \
  -d '{"model": "qwen3:8b", "messages": [{"role": "user", "content": "Hello"}]}'

Se ti basta una finestra di chat, niente di tutto questo ti serve: l’app pronta di chat IA privata installa da sola Ollama, un modello Qwen3 o MiMo e Open WebUI, come descritto in il tuo ChatGPT con Open WebUI.

llama.cpp: compili una volta, poi lo usi

llama.cpp va compilato con CUDA. L’immagine del server contiene il runtime CUDA ma non il compilatore, quindi prima installa il toolkit di NVIDIA. Scarica qualche GB, che conta come traffico, e la compilazione richiede 5–15 minuti:

wget -q https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
dpkg -i cuda-keyring_1.1-1_all.deb && apt-get update -qq
apt-get install -y -qq cuda-toolkit-12-8 cmake git build-essential
export PATH=/usr/local/cuda-12.8/bin:$PATH

git clone https://github.com/ggml-org/llama.cpp /workspace/llama.cpp && cd /workspace/llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

Poi scarica un GGUF e avvia il server con quattro slot paralleli:

pip install -U huggingface_hub
hf download <user>/<repo>-GGUF <model>-Q4_K_M.gguf --local-dir /workspace/models
./build/bin/llama-server -m /workspace/models/<model>-Q4_K_M.gguf \
  -ngl 99 -c 32768 -np 4 --flash-attn on --host 127.0.0.1 --port 8081

Sui nostri server la porta 8080 è occupata da Jupyter, da qui la 8081. llama-server serve l’API in stile OpenAI su /v1 e una semplice pagina di chat alla radice. Se userai di nuovo llama.cpp, tieni la cartella compilata /workspace/llama.cpp nella cartella salvata invece di ricompilare ogni volta.

vLLM: un’API in due comandi

pip install "vllm==0.11.0" "transformers>=4.56,<5"   # compilato per CUDA 12.8
vllm serve Qwen/Qwen3-8B --max-model-len 16384 \
  --host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &

Un semplice pip install vllm porta l’ultima release con la sua build di PyTorch, e nell’autunno 2026 quella build punta a una versione di CUDA più recente di quella supportata dai driver di molte macchine, quindi il motore non parte. Per questo il comando qui sopra fissa vLLM 0.11.0 (PyTorch 2.8, CUDA 12.8), la versione usata dal nostro server vLLM; su una macchina che nel catalogo mostra CUDA 13 o successiva puoi prendere una release più recente. Controlla la versione di CUDA indicata prima dell’avvio; incompatibilità tra CUDA e driver spiega come leggere quei numeri. Il server vLLM pronto salta questo passaggio: vLLM è installato in una versione adatta alla macchina e avvia da solo un modello Qwen 7B. Per servire un altro modello lì, esegui pkill -f "vllm serve" e lancia il tuo comando sulla porta 8000.

Dal tuo codice usa il client OpenAI standard con il tuo indirizzo:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="change-me")
r = client.chat.completions.create(model="Qwen/Qwen3-8B",
    messages=[{"role": "user", "content": "Summarise this ticket: ..."}])
print(r.choices[0].message.content)

Le stesse righe, con un altro base URL, collegano un bot Telegram, una pipeline RAG o un’app esistente scritta per OpenAI.

Raggiungere l’API dall’esterno e tenerla attiva

Un server non ha un IP pubblico tutto suo: SSH, Jupyter e le app passano dal nostro indirizzo, con porte assegnate a quel server. Sul server vLLM la porta 8000 è già pubblicata e la dashboard mostra l’indirizzo dell’API. Su un server PyTorch vuoto sono pubblicati solo SSH e Jupyter, quindi raggiungi Ollama o llama.cpp con un tunnel SSH dal tuo computer: ssh -p <port> -L 8081:localhost:8081 root@<address> (porta e indirizzo dalla scheda del server; la guida alla chiave SSH ti aiuta a configurare la chiave), poi usa http://localhost:8081. Un’immagine Docker personalizzata può pubblicare una porta sua. Docker dentro il server non è disponibile, ed è per questo che tutti i comandi qui installano con pip o con uno script.

Tutto ciò che è raggiungibile dall’esterno ha bisogno di una chiave. vLLM accetta --api-key, anche llama.cpp accetta --api-key, mentre Ollama non ha una chiave sua, quindi tienilo dietro un tunnel.

Avvia i server che devono restare accesi a lungo con nohup ... & e un file di log come sopra, oppure dentro tmux (apt-get install -y tmux, poi tmux new -s llm), così continuano a girare quando chiudi il browser o la sessione SSH. Si fermano insieme al server: la fatturazione finisce nel minuto in cui premi Ferma, e l’avvio successivo parte da un disco pulito, tranne quello che hai tenuto nella cartella salvata.