Ollama o llama.cpp su un VPS: quale scegliere

Ollama vs llama.cpp: quale livello vuoi eseguire?

Ollama e llama.cpp non sono concorrenti nel senso implicato dalla domanda. llama.cpp è il motore di inferenza: carica un file di modello e converte un prompt in token. Ollama è un gestore di modelli, un demone in background e un'API HTTP che utilizzano quel motore. Il README di Ollama indica ancora llama.cpp come backend di inferenza (verificato il 2 agosto 2026). La domanda reale è quindi quale livello vuoi gestire sul tuo VPS, non quale dei due sia più veloce.

Esegui Ollama quando vuoi un servizio che scarichi i modelli in base al nome e continui a funzionare senza interventi. Esegui direttamente llama.cpp quando il server ha risorse limitate e devi scegliere il file di modello esatto, la dimensione esatta del contesto e il numero esatto di thread, perché su un VPS con poca memoria ciascuna di queste impostazioni consuma memoria che non hai.

Che cosa sono realmente i due progetti

llama.cpp è un'implementazione in C e C++ dell'inferenza dei transformer basata sulla libreria ggml. Legge i file GGUF. GGUF (GGML universal file format) è un contenitore in un singolo file che include i pesi, il tokenizzatore e i metadati necessari al motore per eseguire il modello. Il progetto fornisce binari distinti per attività diverse. llama-server è un server HTTP, llama-cli è un prompt interattivo e llama-bench misura il throughput. Le release sono contrassegnate con un numero di build, non con una versione semantica. Il tag corrente è b10224, pubblicato il 2 agosto 2026, e nei giorni lavorativi viene pubblicato quasi sempre un nuovo tag.

Ollama è un programma scritto in Go. Un daemon in background, avviato con ollama serve, carica i modelli e risponde alle richieste HTTP; un client a riga di comando comunica con il daemon. Entrambi utilizzano un registry disponibile su ollama.com, che contiene modelli già impacchettati. Ollama usa versioni semantiche e la versione v0.32.5 è stata rilasciata il 27 luglio 2026. ollama pull scarica un file GGUF insieme a un template per il prompt e a un set di parametri predefiniti, quindi lo salva in /usr/share/ollama/.ollama/models su Linux.

Questa modalità di packaging costituisce l'unica differenza sostanziale. Ollama sceglie per te la quantizzazione, il template e la lunghezza del contesto e ti fornisce un unico nome da ricordare. llama.cpp non sceglie nulla e ti fornisce dei flag.

Asse 1: controllo del modello e della quantizzazione

La quantizzazione riduce ogni peso da 16 o 32 bit a 4, 5 o 8 bit. È questo che consente a un modello con 8 miliardi di parametri di rientrare nella RAM di un normale VPS. La nomenclatura GGUF è leggibile quando se ne conosce lo schema: Q4_K_M indica una quantizzazione K a 4 bit, di dimensione media. Un numero più alto conserva una precisione maggiore e richiede più memoria.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Queste sono le dimensioni dei file pubblicati nel repository bartowski/Meta-Llama-3.1-8B-Instruct-GGUF su Hugging Face, rilevate il 2 agosto 2026 e convertite da byte a GiB. Si tratta di 6 build dello stesso modello; la più piccola occupa 2.96 GiB, contro i 7.95 GiB della più grande. L'impostazione predefinita più comune, Q4_K_M, occupa 4.58 GiB. Su un VPS da 4 GiB, questa singola scelta determina se il modello viene caricato o meno.

Con llama.cpp si specifica il nome del file, quindi la riga va scelta manualmente.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c indica la dimensione del contesto in token, -t il numero di thread e -ngl stabilisce quanti layer vengono spostati su una GPU (0 su un server con sola CPU). Non viene effettuata alcuna scelta automatica.

Con Ollama, la quantizzazione è inclusa nel tag che si scarica e ollama ls mostra ciò che è effettivamente presente sul disco. Se il registry non contiene la build desiderata, si può importare direttamente un file GGUF. Scrivere un Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Quindi creare il modello e verificare il risultato:

ollama create llama31-q4 -f ./Modelfile
ollama ls

La lunghezza del contesto è l'impostazione che causa più spesso problemi. Ollama sceglie il valore predefinito in base alla VRAM disponibile e un server senza GPU rientra nella categoria più bassa: 4096 token. Se gli si invia un documento di 20.000 token, quelli in eccesso vengono eliminati prima che il modello possa leggerli; la risposta risulta quindi sicura di sé, ma errata, perché il file è stato letto solo parzialmente. Aumentare il valore con OLLAMA_CONTEXT_LENGTH sul daemon oppure con PARAMETER num_ctx in un Modelfile. Anche llama.cpp non ha un valore predefinito affidabile. Impostare esplicitamente -c e verificare il valore configurato.

L'aritmetica della memoria che quasi nessuno mostra

Il file del modello non rappresenta il costo complessivo. La KV cache (cache di key/value) contiene una voce per ogni layer e per ogni token del contesto e cresce con l'aumentare della conversazione.

Calcoliamola per Llama 3.1 8B. Il modello ha 32 layer, 8 teste key/value e una dimensione della testa pari a 128. Ogni token memorizza una key e un value, ciascuno di 2 byte in f16, quindi 2 x 8 x 128 x 2 = 4096 byte per layer. Su 32 layer, il risultato è 128 KiB per token. Un contesto di 4096 token richiede quindi 512 MiB, mentre un contesto di 32,768 token richiede 4 GiB.

Un modello Q4_K_M 8B con un contesto di 4k richiede quindi circa 4.58 GiB per i pesi, più circa 0.5 GiB per la cache e la memoria necessaria al runtime. Non entra in 4 GiB di RAM. Entra in 8 GiB, lasciando memoria disponibile per il funzionamento del sistema. Se porti il contesto a 32k sulla stessa macchina con 8 GiB, la sola cache consuma tutta la memoria disponibile. Monitorala in tempo reale con free -h mentre il modello è caricato e non fidarti di una stima che non hai verificato con una misurazione.

Ollama amplifica il problema. OLLAMA_NUM_PARALLEL ha come valore predefinito 1 e la memoria necessaria a un modello cresce in proporzione al prodotto di quel numero per la lunghezza del contesto. Se aumenti entrambi contemporaneamente, il daemon richiede in modo silenzioso una quantità di RAM diverse volte superiore a quella prevista.

Asse 2: il daemon da amministrare

Lo script di installazione di Ollama scrive un'unità systemd, crea un utente di sistema ollama e abilita il servizio. La gestione del ciclo di vita è quindi disponibile senza doverla implementare. La configurazione passa da systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE è più importante su un VPS con CPU che in qualsiasi altro contesto. Per impostazione predefinita, i modelli restano in memoria per 5 minuti e poi vengono scaricati. La richiesta successiva deve rileggere l'intero file dal disco prima di poter rispondere, quindi un ricaricamento di 4.58 GiB trasforma una risposta di due secondi in una di trenta secondi su uno storage lento. Un keep-alive lungo elimina questa latenza, ma occupa permanentemente la RAM. Entrambe sono conseguenze reali. Scegli quella meno penalizzante.

llama.cpp non fornisce alcun daemon, quindi devi scrivere autonomamente l'unità come /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Abilitala con sudo systemctl enable --now llama-server. Il processo mantiene quindi il modello per tutta la propria durata. Il modello non viene scaricato quando il servizio resta inattivo: non si verificano ricaricamenti imprevisti, ma non puoi recuperare la memoria senza arrestare il servizio. Se non hai mai scritto unità, si tratta dello stesso schema usato per eseguire i propri servizi con systemd su un VPS.

Asse 3: l’API con cui comunicherà l’applicazione

Questa differenza si è ridotta molto. Entrambi i progetti ora supportano il formato chat di OpenAI, quindi la maggior parte delle librerie client funziona con entrambi dopo la sola modifica dell’URL di base.

Ollama è in ascolto su 127.0.0.1:11434. Il relativo endpoint compatibile con OpenAI è http://localhost:11434/v1/chat/completions e, in parallelo, mantiene un’API nativa su /api/chat. È documentato anche un endpoint compatibile con Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server è in ascolto su 127.0.0.1:8080 ed espone /v1/chat/completions, /v1/completions e /v1/embeddings, oltre al proprio endpoint /completion e a un’interfaccia web integrata. Espone anche endpoint operativi che Ollama non offre: /health per il readiness probe, /props per le impostazioni del modello caricato, /slots per lo stato di elaborazione di ciascuno slot delle richieste e /metrics in formato Prometheus. Se prevedi di monitorare questo servizio, probabilmente è questa la differenza decisiva.

Nessuno dei due server abilita automaticamente l’autenticazione. Per impostazione predefinita, entrambi usano il loopback per un motivo preciso. Raggiungili tramite un tunnel SSH o dietro un reverse proxy e non esporre mai 11434 o 8080 a Internet.

Cosa può fare concretamente un VPS con sola CPU

Un VPS con sola CPU esegue lentamente i modelli di piccole dimensioni. Questa è la sintesi corretta. L'aspetto utile è capire dove si trova il limite. Esegui le misurazioni prima di progettare qualsiasi soluzione basata su queste prestazioni:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

La colonna pp indica la velocità di elaborazione del prompt, mentre la colonna tg indica la velocità di generazione dei token. Entrambe sono espresse in token al secondo. In un piano con vCPU condivisa, un modello 8B con quantizzazione Q4_K_M raggiunge in genere valori di poche unità per tg. Il collo di bottiglia è l'elaborazione del prompt: l'intero prompt viene elaborato prima che venga prodotto il primo token di output, quindi un prompt di sistema lungo aggiunge un'attesa a ogni richiesta.

Utilizzabile con la sola CPU: un modello da 1B a 4B per classificazione, estrazione, riepiloghi brevi o instradamento delle richieste. Le risposte arrivano in pochi secondi e la memoria necessaria rientra nelle dimensioni di un piano normale. Non utilizzabile con la sola CPU: chat interattiva alla velocità di lettura, assistenti per la programmazione, elaborazione di documenti lunghi o qualsiasi attività con un ciclo agentico che esegue molte chiamate in sequenza. Un ciclo che esegue dodici chiamate da quattro secondi ciascuna impiega un minuto prima di produrre qualsiasi risultato.

Quando i numeri non sono sufficienti, esistono due alternative. Se il problema è la concorrenza, cioè molti utenti che utilizzano contemporaneamente un modello, cambia la scelta del motore; il confronto tra Ollama e vLLM per la gestione di richieste concorrenti tratta questo aspetto. Se il problema è la velocità pura, la soluzione è un VPS con GPU, dove -ngl inizia ad avere un significato. Prima di entrambe le alternative, misura le prestazioni di base dell'hardware, perché la larghezza di banda di disco e memoria incide sui tempi di caricamento quanto la CPU. Un benchmark ripetibile del VPS richiede un'ora, ma è utile.

Installare llama.cpp con una build fissata

Entrambi i progetti vengono aggiornati ogni settimana, quindi annotare la versione distribuita. Il comando in una riga del progetto upstream installa la build corrente:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Per fissare una build specifica, usare invece il tarball precompilato dalla pagina delle release. La build b10224 è il tag corrente al 2 agosto 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

In alternativa, compilare lo stesso tag dal codice sorgente:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev è la dipendenza documentata per le funzionalità HTTPS. La compilazione richiede diversi minuti e più RAM di quella disponibile nei piani più piccoli. Se il server più piccolo esaurisce la memoria, compilare su un server più grande e copiare i binari.

Installare Ollama fissando una versione

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Lo script legge OLLAMA_VERSION, quindi puoi mantenere una release verificata invece di installare qualunque versione sia stata rilasciata questa mattina. v0.32.5 è stata pubblicata il 27 luglio 2026. È disponibile anche una procedura manuale, se preferisci non passare uno script a una shell tramite pipe:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

La procedura manuale non crea l'unità systemd né l'utente di servizio, quindi devi crearli manualmente. La guida completa a Ollama su un VPS descrive passo per passo la configurazione del servizio.

Modalità di errore e stringhe visualizzate

Ollama rifiuta di caricare il modello. ollama run restituisce una riga di questo tipo:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama verifica le dimensioni prima del caricamento, quindi l’errore è immediato e ne indica la causa. Passa alla riga di quantizzazione successiva, riduci la lunghezza del contesto oppure scegli un modello più piccolo.

llama.cpp non restituisce un errore: rallenta fino a diventare inutilizzabile. Per impostazione predefinita, llama.cpp usa il memory mapping del file GGUF, quindi anche un file più grande della RAM viene avviato. Il kernel legge quindi i pesi dal disco e li espelle a ogni token; la generazione scende a diversi secondi per token, mentre l’utilizzo del disco raggiunge il 100 percento. Passa --no-mmap per forzare un’allocazione effettiva, in modo che il processo fallisca subito invece di degradare le prestazioni. Quando interviene il kernel, dmesg mostra la causa:

Out of memory: Killed process 1234 (llama-server)

Il file del modello non viene caricato. Un file GGUF creato per una famiglia di modelli più recente del tuo engine restituisce un errore che indica l’architettura non riconosciuta:

error loading model architecture: unknown model architecture: 'qwen3next'

La soluzione è aggiornare l’engine, non usare un file diverso. Questo è il costo del pinning e il motivo per cui devi annotare il numero di build. Devi sapere da quale versione stai effettuando l’aggiornamento.

L’API risponde localmente, ma non dall’applicazione. Ollama è in ascolto su 127.0.0.1:11434, quindi da un altro host la connessione viene rifiutata. Imposta OLLAMA_HOST=0.0.0.0:11434 tramite systemctl edit ollama solo quando la porta si trova dietro un firewall o su una rete privata, perché l’API non dispone di autenticazione integrata.

La prima risposta dopo una pausa è molto lenta. È avvenuto lo scaricamento del modello dopo 5 minuti di inattività e il modello viene nuovamente letto dal disco. ollama ps eseguito subito prima della richiesta non mostra alcun modello caricato, confermando la causa. Aumenta OLLAMA_KEEP_ALIVE.

Quindi, quale dovresti usare?

Usa Ollama quando vuoi che i modelli siano gestiti automaticamente e ti serve un endpoint compatibile con OpenAI senza configurazioni aggiuntive. È la scelta predefinita corretta per una prima distribuzione e per qualsiasi scenario in cui la scelta del modello cambierà spesso.

Usa direttamente llama.cpp quando la memoria è così limitata da dover scegliere personalmente la riga della quantizzazione, quando vuoi /health, /slots e /metrics per il monitoraggio oppure quando ti serve un flag che Ollama non espone. È la scelta più trasparente su un VPS in cui il modello entra appena nella memoria disponibile, perché le impostazioni che ne consentono l'esecuzione sono esattamente quelle che Ollama seleziona al posto tuo.

È normale eseguire entrambi. Ollama per gli esperimenti, llama.cpp per l'unico modello che metti in produzione e che non vuoi più modificare.

FAQ

Ollama è soltanto un wrapper per llama.cpp?

Quasi, ma il wrapper svolge un lavoro effettivo. Il README di Ollama indica llama.cpp come backend di inferenza (verificato il 2 agosto 2026). Oltre a questo, Ollama aggiunge un registro dei modelli, il template del prompt che converte i messaggi della chat in un prompt, un insieme di parametri predefiniti per il sampling, un daemon con scaricamento dei modelli inattivi e un'API HTTP. Quando confronti i token al secondo con impostazioni identiche, confronti lo stesso motore con se stesso. In pratica scegli tra i livelli di gestione.

Qual è il più veloce su una VPS che usa solo la CPU?

Condividono lo stesso motore, quindi con lo stesso file del modello, la stessa quantizzazione, le stesse dimensioni del contesto e lo stesso numero di thread, le prestazioni sono molto simili. Le differenze riportate di solito dipendono da impostazioni predefinite diverse, soprattutto dalla lunghezza del contesto e dal numero di thread, non dal motore. Misurale con llama-bench -m <file> -p 512 -n 128 e confronta la colonna tg sul tuo server prima di considerare attendibile qualsiasi dato pubblicato.

Posso usare un mio file GGUF con Ollama?

Sì. Copia il file sul server, scrivi un Modelfile la cui prima riga sia FROM ./your-model.gguf, aggiungi le righe PARAMETER necessarie, ad esempio num_ctx, quindi esegui ollama create your-name -f ./Modelfile. ollama ls lo elencherà insieme agli altri modelli scaricati dal registro. In questo modo puoi usare una quantizzazione non disponibile nel registro.

Quanta RAM serve per un modello 8B?

Considera le dimensioni del file, la cache KV e il runtime. Una build Q4_K_M di Llama 3.1 8B occupa circa 4.58 GiB su disco e un contesto di 4096 token aggiunge circa 512 MiB di cache. Pertanto, 8 GiB di RAM sono sufficienti, mentre 4 GiB non bastano. La cache cresce con le dimensioni del contesto: lo stesso modello con un contesto di 32,768 token richiede da solo circa 4 GiB di cache. Con Ollama, considera anche che il requisito cresce in base a OLLAMA_NUM_PARALLEL.