llama.cpp vs Ollama: quale scegliere nel 2026?

llama.cpp puro se vuoi il massimo dei token/secondo e il pieno controllo; Ollama se vuoi un’installazione a un comando e un server API che funziona out of the box. Ollama non è un motore concorrente: è un servizio Go che incorpora llama.cpp come backend di inferenza, aggiunge la gestione dei modelli (ollama pull llama3.1) e serve una REST API sulla porta 11434. Quindi la vera domanda non è «quale motore è più veloce» ma «quanto controllo vuoi sulle manopole di quel motore». Dato che Ollama spedisce default prudenti (quantizzazione Q4_K_M, contesto modesto, niente flash attention fino a poco fa), lo stesso hardware può produrre numeri sensibilmente diversi. Qui sotto: cosa cambia davvero, da dove nasce il divario di velocità, lo stesso modello in esecuzione su entrambi, e una tabella decisionale.

Qual è la differenza tra llama.cpp e Ollama?

llama.cpp è il motore di inferenza: un singolo progetto C/C++ di Georgi Gerganov, il creatore del GGUF, che esegue modelli quantizzati su CPU, GPU o un mix dei due. Ti dà llama-cli per i prompt one-shot e llama-server — un server HTTP compatibile OpenAI — più ogni flag di tuning che il motore supporta: offload dei layer sulla GPU, quantizzazione della KV cache, speculative decoding, sampler personalizzati.

Ollama è un prodotto costruito sopra quel motore. Fa fork e vendorizza llama.cpp, poi lo avvolge in:

• un registro di modelli (ollama pull, ollama list) con suddivisione automatica dei pesi GGUF,
• un sistema di Modelfile (una spec in stile Dockerfile per template di prompt e parametri),
• un demone in background che tiene i modelli caldi in VRAM ed espone la sua REST API,
• rilevamento automatico dell’hardware con default sicuri.

La conseguenza pratica: con Ollama gestisci i modelli; con llama.cpp gestisci l’inferenza. Se hai mai voluto cambiare il formato di quantizzazione, quantizzare la KV cache, alzare il contesto oltre il default o fissare layer specifici sulla GPU, quello è territorio llama.cpp. Ollama nasconde gran parte di quei comandi — di proposito.

	llama.cpp	Ollama
Cosa è	Motore di inferenza (C/C++)	Servizio che incapsula llama.cpp
Installazione	Build dai sorgenti o pacchetto	Installer a una riga, binario singolo
Eseguire un modello	llama-cli -m model.gguf + flag	ollama run llama3.1
API	Compatibile OpenAI (llama-server)	REST propria + endpoint compatibile OpenAI
Gestione modelli	I file GGUF te li scarichi da te	Registro: pull/list/rm
Default	Scegli tutto tu	Prudenti: Q4_K_M, contesto modesto
Aggiornamenti motore	Dal giorno uno (upstream)	In ritardo sulle release upstream
Profondità di tuning	Totale (KV quant, spec decode, sampler)	Passthrough limitato
Ideale per	Lavoro di performance, server, dispositivi edge	Iniziare, laptop di sviluppo

llama.cpp è più veloce di Ollama?

Con lo stesso file GGUF, la stessa quantizzazione, lo stesso contesto e la stessa versione di llama.cpp — no, la differenza resta nel rumore di misura, perché Ollama è llama.cpp che fa i conti. Ogni benchmark «Ollama è il 30% più lento» che vedi è in realtà un confronto tra default. Il divario nasce da tre posti:

1. Scelta della quantizzazione. Il registro di Ollama usa Q4_K_M di default. Esegui lo stesso modello come Q5_K_M o Q6_K da llama.cpp e ottieni qualità migliore per token a velocità simile — oppure scegli Q4_0/IQ4 per la velocità pura.
2. Flash attention e quantizzazione della KV cache. --flash-attn più -ctk q8_0 -ctv q8_0 riduce drasticamente la KV cache, il che alza i token/secondo a contesto lungo e ti fa stare contesti più grandi nella stessa VRAM. Ollama ne espone solo una parte.
3. Ritardo di versione. llama.cpp integra ottimizzazioni dei kernel ogni settimana; Ollama fa merge dall’upstream con i suoi tempi. Una build fresca di llama.cpp può essere misurabilmente più veloce di un binario Ollama di mesi prima sulla stessa macchina — finché Ollama non recupera.

Comando di benchmark rapido, agnostico dal motore — riporta la velocità di valutazione del prompt e di generazione:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Lancialo sul file modello di Ollama stesso (~/.ollama/models/blobs/..., rinominato in .gguf) e di solito replichi esattamente i numeri di Ollama — poi li batti aggiungendo -ctk q8_0 a contesto 16k.

Come esegui lo stesso modello in entrambi?

Entrambi consumano GGUF. Il minimo end-to-end per ciascuno:

# --- Percorso Ollama: installi, fai pull, servi ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # scarica Q4_K_M, carica in VRAM, apre una chat

# la sua API, in stile compatibile OpenAI:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- Percorso llama.cpp: compili, scarichi il GGUF, servi ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # oppure -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server espone lo schema OpenAI Chat Completions, quindi la stessa curl contro http://localhost:8080/v1/chat/completions funziona identica. Qualsiasi strumento costruito per l’API OpenAI — script, editor, pipeline RAG — può puntare a uno dei due. I flag fanno il lavoro vero: -ngl 99 scarica ogni layer sulla GPU, --flash-attn più la coppia -ctk/-ctv tiene un contesto 16k dentro una scheda da 8 GB che i default di Ollama rifiuterebbero.

Per scegliere il file GGUF e sapere cosa significano le etichette delle quant, vedi come eseguire modelli GGUF in locale.

Quando ha più senso Ollama?

La maggior parte delle persone dovrebbe partire con Ollama, e non è un premio di consolazione:

• Lo vuoi funzionare stasera. Un comando, modello scaricato, API su. llama.cpp significa scegliere un backend (CUDA/Vulkan/HIP/Metal), compilare e scaricare i pesi a mano.
• Gestisci tanti modelli. Registro, scaricamento automatico e Modelfile battono la gestione manuale di directory di file GGUF.
• La tua macchina è modesta. I default di Ollama sono prudenti per un motivo — quasi sempre ci stanno e girano.
• Vuoi una superficie API stabile. Il demone di Ollama gestisce il ciclo di vita dei modelli, così non lo deve fare un servizio a lunga esecuzione.

Scegli llama.cpp puro quando fai benchmarking, servi a qualsiasi scala, giri su un telefono o un Raspberry Pi, ti serve contesto lungo su poca VRAM, o vuoi una feature il giorno stesso in cui fa merge sull’upstream. I power user spesso usano entrambi: Ollama per i modelli di tutti i giorni, una build di llama.cpp pinnata per l’unico carico che ha bisogno dell’ultimo 20%.

Se il tuo confronto è davvero tra app desktop con GUI, è un altro asse — vedi Ollama vs LM Studio — e per la scelta del motore per task, i migliori LLM locali per programmare copre il lato modelli.

Quale dovresti usare?

Decidi in base al controllo, non alla velocità. I motori sono gli stessi; i default no. Installa Ollama se l’obiettivo è «gira e serve un’API» — perdi un po’ di manopole che tanto non avresti girato. Compila llama.cpp se l’obiettivo è token/secondo, lunghezza del contesto o controllo della quantizzazione — ottieni ogni manopola, al costo di gestire i modelli da te. In ogni caso esegui gli stessi file GGUF, e cambiare dopo costa un pomeriggio, non una riscrittura.