Ollama vs llama.cpp : quale scegliere nel 2026 ?

#Il collegamento reale tra Ollama e llama.cpp

llama.cpp è il progetto in C/C++ di Georgi Gerganov che esegue modelli di linguaggio nel formato GGUF su CPU e GPU, senza dipendenze da Python né da PyTorch. È il componente di inferenza di riferimento dell'intero ecosistema locale: LM Studio, KoboldCpp, Jan e Ollama si basano su di esso, direttamente o tramite un fork.

Ollama non è quindi un concorrente di llama.cpp in senso stretto: è uno strato aggiuntivo. Incorpora un proprio motore derivato da llama.cpp, a cui aggiunge un gestore dei modelli, un daemon in background e un'API. Quando digiti `ollama run qwen3`, è il codice derivato da llama.cpp a produrre i token. La domanda non è «qual è il più veloce» — a parità di quantizzazione e hardware, le prestazioni sono molto simili — ma «quale livello di astrazione fa al caso tuo».

#Ciò che Ollama aggiunge realmente a llama.cpp

Compilare e avviare manualmente llama.cpp significa gestire da soli il download dei GGUF, i percorsi dei file e una lunga riga di opzioni. Ollama si occupa di tutto questo. Ecco concretamente cosa offre in più rispetto al solo motore:

Registro e pull

`ollama pull qwen3:8b` scarica il modello da ollama.com, sceglie una quantizzazione predefinita (spesso Q4_K_M) e lo archivia in un archivio di blob. Non serve andare a caccia del file giusto su Hugging Face.

Daemon persistente

Un servizio gira in background e ascolta su http://localhost:11434. Il modello rimane caricato in memoria tra due richieste (keep-alive) e viene rimosso automaticamente dalla memoria dopo un periodo di inattività.

Offload GPU automatico

Ollama stima la VRAM disponibile e distribuisce i layer tra GPU e CPU senza che tu debba regolare `-ngl`. Pratico, ma a volte troppo cauto.

Modelfile

Un file dichiarativo (in stile Dockerfile) che fissa un modello di base, un prompt di sistema, una temperatura e un template di chat sotto un nome riutilizzabile.

API compatibile con OpenAI

Un endpoint /v1/chat/completions pronto all'uso, oltre all'API nativa /api/generate. Qualsiasi client OpenAI può collegarsi cambiando l'URL di base.

Dall'altro lato, llama.cpp ti lascia fare tutto — ma devi fare tutto tu. Recuperi il GGUF da solo, scrivi la riga di comando e gestisci il ciclo di vita del processo. È il prezzo del controllo totale, che il seguito di questo confronto llama cpp vs ollama illustrerà nel dettaglio.

#Prerequisiti

Il solo fattore che decide veramente cosa potrai eseguire è la memoria (RAM o VRAM su GPU dedicata). Questi riferimenti in Q4_K_M valgono per entrambi gli strumenti, poiché il motore è lo stesso:

3B ≈ 2 GB

Trova posto su quasi qualsiasi hardware, anche su una RTX 3060 da 12 GB, con un margine enorme.

7B ≈ 5 GB

Utilizzo agevole già a partire da 8 GB di VRAM (RTX 3060, 4060).

14B ≈ 9 GB

Entra interamente nella VRAM di una RTX 3060 da 12 GB o di una 4070 da 12 GB.

32B ≈ 19 GB

Richiede una RTX 4090 da 24 GB, oppure un offload parziale CPU/GPU su 16 GB.

70B ≈ 40 GB

Richiede multi-GPU, un Mac con memoria unificata (M4 Pro 48 GB) o un offload aggressivo.

#Installare e avviare entrambi

1. 01
   Installare Ollama

   Lo script ufficiale installa il daemon e la CLI con un solo comando su Linux; su macOS e Windows, su ollama.com è disponibile un programma di installazione grafico. Una volta installato, il servizio è in ascolto su http://localhost:11434.
2. 02
   Avviare un modello con Ollama

   `ollama run qwen3:8b` scarica il modello alla prima esecuzione, poi apre una sessione di chat. Non c'è altro da configurare: l'offload sulla GPU, il contesto e il template sono gestiti automaticamente.
3. 03
   Compilare llama.cpp

   Si clona il repository ggml-org/llama.cpp e si compila con CMake. L'opzione del backend GPU dipende dal tuo hardware: CUDA per NVIDIA, Metal (attivato per default) su Mac, ROCm o Vulkan per AMD.
4. 04
   Avviare un GGUF con llama.cpp

   `llama-cli` carica un file .gguf specificato esplicitamente, con tutte le impostazioni sulla riga di comando: numero di layer GPU (`-ngl`), dimensione del contesto (`-c`), thread CPU (`-t`). Nulla viene dedotto al posto tuo.

# Installer (Linux) puis lancer un modèle
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Vérifier le daemon et lister les modèles
curl http://localhost:11434/api/tags
ollama list

# Cloner et compiler avec le backend CUDA (NVIDIA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Lancer un GGUF avec 35 couches sur le GPU et 8192 de contexte
./build/bin/llama-cli -m ./qwen3-8b-Q4_K_M.gguf -ngl 35 -c 8192 -p "Bonjour"

#Benchmark semplice dei due sullo stesso GGUF

Il modo migliore per mettere fine alle discussioni: misurare entrambi sullo stesso file, sulla stessa macchina. llama.cpp fornisce `llama-bench`, uno strumento dedicato che misura separatamente il throughput di generazione (token/secondo) e l'elaborazione del prompt (prompt processing).

# Débit brut du moteur sur le GGUF, tout GPU
./build/bin/llama-bench -m ./qwen3-8b-Q4_K_M.gguf -ngl 99
# Sortie : colonnes pp (prompt) et tg (génération) en tok/s

# Importer le GGUF dans Ollama sans le re-télécharger
printf 'FROM ./qwen3-8b-Q4_K_M.gguf\n' > Modelfile
ollama create qwen3-local -f Modelfile

# Chronométrer une génération (--verbose affiche les tok/s)
ollama run qwen3-local --verbose "Explique la photosynthèse en 200 mots"

Il risultato tipico nel 2026, a parità di GGUF e con tutti i layer sulla GPU: la velocità di generazione è quasi identica, con uno scarto di pochi punti percentuali. È logico: il kernel di calcolo è lo stesso. Le differenze osservate derivano quasi sempre da impostazioni implicite diverse, non dal motore:

Layer in offload

Ollama può lasciare alcuni strati sulla CPU per prudenza nell'uso della VRAM, mentre `llama-bench -ngl 99` sposta tutto sulla GPU. Risultato: Ollama sembra più lento, ma si tratta di una scelta di ripartizione.

Dimensione del contesto

Un contesto più grande riserva più VRAM per la cache KV e riduce lo spazio per i pesi. Confronta a parità di contesto.

Flash attention e cache KV

Attivati o meno, quantizzati o meno, questi parametri modificano il tasso di elaborazione. In llama.cpp li imposti tu; in Ollama dipendono dalla versione e dalle variabili d'ambiente.

#Impostazioni avanzate accessibili solo in llama.cpp

È qui che il confronto llama.cpp vs Ollama pende decisamente da una parte. Esponendo direttamente i flag del motore, llama.cpp dà accesso a opzioni che Ollama nasconde o rende disponibili solo in parte. Per un uso avanzato, queste impostazioni cambiano tutto:

Offload chirurgico (-ngl)

Decidi esattamente quanti layer assegnare alla GPU, con una precisione di un singolo layer. Con una VRAM appena sufficiente, riuscire a caricare 2 o 3 layer in più rispetto a Ollama può far passare un modello da «lento» a «fluido».

Cache KV quantizzato (-ctk/-ctv)

Quantizzare la cache KV in q8_0 riduce quasi della metà la memoria occupata dal contesto, permettendo finestre molto più lunghe a parità di VRAM — una leva poco accessibile con Ollama.

Flash attention (--flash-attn)

Attivazione esplicita dell'attenzione ottimizzata, con un impatto diretto sulla velocità e sulla memoria dei contesti lunghi.

Decodifica speculativa (--model-draft)

Collegare un piccolo modello « bozza » per accelerare un modello grande. Il guadagno può essere considerevole sul codice e il supporto è nativo in llama.cpp.

Grammatiche GBNF (--grammar)

Vincolare l'output a una grammatica formale (JSON rigoroso, enumerazione, formato personalizzato). Indispensabile per un output strutturato affidabile, e con un controllo molto più granulare rispetto alla modalità JSON di Ollama.

RoPE e scaling del contesto

Regolare `--rope-freq-base` e `--rope-freq-scale` per estendere il contesto oltre quello previsto dall'addestramento originale, tenendo sotto controllo il degrado.

Ollama rende disponibili alcune di queste impostazioni tramite i parametri del Modelfile o le variabili d'ambiente, ma raramente con la stessa granularità e spesso con un certo ritardo rispetto alle novità di llama.cpp. Se la tua esigenza è «il contesto più lungo possibile sulla mia VRAM» o «JSON di cui è garantita la validità», il motore usato direttamente ti permette di regolare viti che lo strato sovrastante ha saldato.

#Server API: Ollama vs llama-server

Entrambi possono servire un modello tramite HTTP. Ollama espone il suo daemon su http://localhost:11434 con un'API nativa (/api/generate, /api/chat) e un endpoint compatibile con OpenAI (/v1/chat/completions). Da parte sua, llama.cpp fornisce `llama-server`, un binario che avvia un'API compatibile con OpenAI e include una piccola interfaccia web.

# API OpenAI-compatible sur le port 8080, tout GPU
./build/bin/llama-server -m ./qwen3-8b-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# Interface web : http://localhost:8080  ·  API : /v1/chat/completions

Più modelli su richiesta

Ollama carica e rimuove dalla memoria automaticamente diversi modelli in base alle richieste. `llama-server` serve un modello per processo — più semplice da capire, meno magico.

Controllo dei flag

Con llama-server, ogni parametro del motore (contesto, cache KV, flash attention) è un flag di avvio esplicito. Ideale per fissare una configurazione di produzione riproducibile.

Ecosistema

L'API di Ollama sulla porta 11434 è diventata uno standard di fatto: Open WebUI, gli editor di codice e le integrazioni si collegano direttamente a questa API. È un vero vantaggio in termini di comodità.

#Verdetto per profilo: principiante, sviluppatore, homelab

Poiché il motore è lo stesso, il verdetto non riguarda le prestazioni, ma il tuo profilo e la tua tolleranza all'uso della riga di comando.

Principiante → Ollama

Un comando per installare, uno per avviare, un modello che «funziona» senza dover regolare nulla. Nessun motivo per compilare codice C++ per conversare con un LLM. Resta su Ollama, eventualmente con Open WebUI come interfaccia.

Sviluppatore → entrambi

Ollama per prototipare in fretta e per l'API OpenAI subito disponibile; llama.cpp quando hai bisogno di grammatiche GBNF, di decodifica speculativa o di un controllo esatto della cache KV. Il passaggio dall'uno all'altro è indolore: il GGUF è condiviso.

Homelab / self-host → llama.cpp (llama-server)

Per sfruttare fino all'ultimo byte una VRAM limitata, fissare una configurazione riproducibile ed estendere il contesto, il motore usato direttamente è la scelta vincente. Il lavoro aggiuntivo — compilare, scrivere i flag, gestire i processi — è proprio ciò che cerchi di padroneggiare.

In una frase: Ollama è il punto di partenza migliore e basta per la stragrande maggioranza degli usi; si passa a llama.cpp usato direttamente quando un'impostazione precisa — contesto, cache KV, grammatica, offload con precisione al singolo layer — diventa il fattore limitante. Non è una sostituzione, è un aumento del controllo.

#Per approfondire

Queste guide approfondiscono questo confronto, dall'installazione alla messa a punto:

Iniziare con Ollama

« Installare Ollama in 5 minuti (Windows, macOS, Linux) » copre l'installazione del daemon e del primo modello, puntando sulla semplicità.

Servire modelli senza Ollama

« llama-server: un'API OpenAI locale con llama.cpp » descrive in dettaglio l'offloading dei layer con regolazione fine e l'interfaccia web inclusa, per quanto riguarda il controllo.

Scegliere la quantizzazione

« Quantizzazione GGUF nel 2026: Q4_K_M vs Q5_K_M vs Q6_K » aiuta a scegliere il file .gguf corretto, comune ai due strumenti.