Ollama o llama.cpp su un VPS solo CPU?

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 utilizza 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 sia più veloce.

Usa Ollama quando vuoi un servizio che scarichi i modelli in base al nome e continui a funzionare senza interventi. Usa 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 risorse 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 a file singolo che include i pesi, il tokenizer e i metadati necessari al motore per eseguire il modello. Il progetto distribuisce 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 il numero di build, non con una versione semantica. Il tag attuale è b10224, pubblicato il 2 agosto 2026, e nei giorni lavorativi viene pubblicato un nuovo tag quasi ogni giorno.

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 quel daemon. Entrambi usano 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 insieme di parametri predefiniti, quindi lo salva in /usr/share/ollama/.ollama/models su Linux. Questi file occupano spazio sul disco root e possono raggiungere diversi gigabyte ciascuno. Su un VPS con un volume root da 25 GB, è quindi utile sapere che cosa lascia pull e come spostare altrove la directory dei modelli prima che il terzo download lo riempia.

Questa modalità di packaging è l'unica differenza sostanziale. Ollama sceglie per te la quantizzazione, il template e la lunghezza del contesto e ti offre un solo nome da ricordare. llama.cpp non sceglie nulla e ti offre 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 entrare 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 maggiore precisione 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. Sono disponibili 6 build dello stesso modello; la più piccola occupa 2.96 GiB, mentre la più grande occupa 7.95 GiB. La scelta predefinita più comune, Q4_K_M, occupa 4.58 GiB. Su un VPS da 4 GiB, questa singola scelta determina se il modello può essere caricato. La dimensione è soltanto metà della decisione, perché una variante che rientra nella memoria disponibile non è automaticamente una variante che vale la pena usare. Il costo effettivo di Q4, Q8 e fp16 sulla qualità delle risposte indica se i gigabyte aggiuntivi producono un miglioramento percepibile.

Con llama.cpp si specifica il file, quindi la variante viene 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 indica il numero di thread e -ngl stabilisce quanti layer trasferire a una GPU (0 su un sistema 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, è possibile importare direttamente un file GGUF. Scrivere un Modelfile:

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

Quindi compilare 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, su un sistema senza GPU, usa la categoria più piccola: 4096 token. Se gli si invia un documento di 20.000 token, quelli eccedenti vengono scartati prima che il modello possa leggerli. La risposta può quindi risultare sicura di sé, ma errata, perché il modello ha letto soltanto una parte del file. Aumentare il valore con OLLAMA_CONTEXT_LENGTH sul daemon oppure con PARAMETER num_ctx in un Modelfile. Se soltanto un'attività richiede una finestra più ampia, num_ctx può essere impostato per singola richiesta anziché a livello globale del server, evitando di riservare la cache aggiuntiva a tutte le altre attività gestite dal daemon. Anche con llama.cpp non è consigliabile affidarsi al valore predefinito. Impostare esplicitamente -c e verificare il valore configurato.

L’aritmetica della memoria che nessuno mostra

Il file del modello non rappresenta l’intero costo. La cache KV (key/value cache) conserva una voce per ogni layer e per ogni token del contesto, quindi cresce insieme alla 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 sono 128 KiB per token. Un contesto di 4096 token richiede quindi 512 MiB, mentre un contesto di 32,768 token richiede 4 GiB.

Di conseguenza, un modello Q4_K_M 8B con un contesto di 4k richiede 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 le altre attività. Se porti il contesto a 32k sulla stessa macchina con 8 GiB, la sola cache consuma tutta la memoria residua. Osserva l’utilizzo in tempo reale con free -h mentre il modello è caricato e non fidarti di una stima che non hai verificato con una misurazione. Se devi dimensionare un modello ben oltre 8B, la stessa aritmetica applicata a un modello 27B su un VPS con solo CPU mostra cosa può contenere realmente ogni livello da 8 a 64 GB.

Ollama amplifica il problema. OLLAMA_NUM_PARALLEL ha valore predefinito 1 e la memoria richiesta da un modello cresce in proporzione al prodotto tra questo numero e la lunghezza del contesto. Se aumenti entrambi contemporaneamente, il daemon può richiedere silenziosamente una quantità di RAM diverse volte superiore a quella prevista. La stessa aritmetica determina anche il limite degli utenti simultanei, perché ogni richiesta concorrente richiede la propria porzione di cache KV. È questo il motivo per cui un server che funziona bene per una persona si blocca con cinque.

Asse 2: il demone da gestire

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 è 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 una VPS con CPU che in qualsiasi altro contesto. Per impostazione predefinita, i modelli restano in memoria per 5 minuti, quindi vengono scaricati. La richiesta successiva deve rileggere l’intero file dal disco prima di poter rispondere, quindi un ricaricamento di 4.58 GiB può trasformare una risposta di due secondi in una di trenta secondi su uno storage lento. Un keep-alive lungo elimina la latenza del ricaricamento, ma occupa la RAM in modo permanente. Entrambi sono costi reali. Scegli quello meno penalizzante. Se decidi che il modello deve restare semplicemente residente, impostare keep_alive affinché sopravviva ai periodi di inattività e ai riavvii richiede poche righe ed evita di dover riscaldare manualmente il modello a ogni riavvio del server.

llama.cpp non fornisce alcun demone, quindi devi scrivere tu 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 durante i periodi di inattività: non ci sono ricaricamenti imprevisti, ma non puoi recuperare la memoria se non arrestando il servizio. Se non hai mai scritto unità, il modello è lo stesso di eseguire i propri servizi con systemd su una VPS.

Asse 3: l'API con cui comunicherà la tua applicazione

Questa differenza si è ridotta molto. Ora entrambi i progetti supportano il formato chat di OpenAI, quindi la maggior parte delle librerie client funziona con entrambi dopo aver modificato soltanto l'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 e fornisce /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 un controllo di prontezza, /props per le impostazioni del modello caricato, /slots per indicare l'attività di ogni 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 un buon motivo, entrambi utilizzano per impostazione predefinita il loopback. Raggiungili tramite un tunnel SSH o dietro un reverse proxy e non esporre mai 11434 o 8080 a Internet.

Cosa può fare realisticamente un VPS con solo CPU

Un VPS con solo CPU esegue lentamente i modelli di piccole dimensioni. Questa è la sintesi corretta; la parte utile consiste nel capire dove si trova il limite. Misura le prestazioni prima di progettare qualsiasi soluzione:

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 espresse in token al secondo. Su un piano con vCPU condivisa, un modello 8B con quantizzazione Q4_K_M raggiunge in genere valori di poche unità per tg. L'elaborazione del prompt è il fattore più penalizzante: l'intero prompt viene elaborato prima che appaia il primo token della risposta, quindi un prompt di sistema lungo aggiunge un'attesa a ogni singola richiesta. La lunghezza della risposta è la parte del costo che puoi controllare direttamente: a tre token al secondo, un modello che genera 600 token occupa la macchina per tre minuti. Per questo, limitare l'output con num_predict è il modo meno costoso per evitare che una risposta troppo lunga causi un timeout.

Utilizzabile su CPU: un modello da 1B a 4B per classificazione, estrazione, riepiloghi brevi o routing. Le risposte arrivano in pochi secondi e la memoria richiesta rientra in un piano normale. Per un esempio concreto di queste dimensioni, invece di un intervallo, Nemotron 3.5 Lightning scaricato e misurato su un VPS riporta il tag esatto, la RAM effettivamente richiesta e la velocità mantenuta senza GPU. Non utilizzabile su CPU: chat interattiva alla velocità di lettura, assistenti per la programmazione, attività su documenti lunghi o qualsiasi flusso con un loop agentico che esegue molte chiamate in sequenza. Un loop che esegue dodici chiamate da quattro secondi ciascuna impiega un minuto prima di produrre un risultato. Se l'obiettivo era comunque usare un assistente per la programmazione, indirizzare un agent verso un modello ospitato autonomamente spiega quali attività un modello locale di piccole dimensioni gestisce realmente meglio e quali devono restare su un'API hosted.

Quando i numeri non sono sufficienti, esistono due alternative. Se il problema è la concorrenza, cioè molti utenti che usano contemporaneamente un unico modello, cambia la scelta del motore; il confronto tra Ollama e vLLM per il serving concorrente tratta questo scenario. Se il problema è la velocità pura, la risposta è un VPS con una GPU collegata, dove -ngl inizia ad avere un valore significativo. Prima di scegliere una delle due alternative, stabilisci una baseline per l'hardware stesso, perché la larghezza di banda di disco e memoria influisce sui tempi di caricamento tanto quanto la CPU. Un benchmark ripetibile per VPS vale l'ora necessaria per eseguirlo.

Installa llama.cpp con una build bloccata

Entrambi i progetti vengono aggiornati ogni settimana, quindi annota la versione distribuita. Il comando su una riga fornito dal 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 bloccare una build specifica, scarica 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, compila lo stesso tag dai sorgenti:

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 rispetto a quella disponibile nei piani più piccoli, quindi compila su una macchina più grande e copia i binari se quella più piccola esaurisce la memoria.

Installare Ollama con una versione bloccata

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. La versione 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 aggiungerli manualmente. La guida completa per eseguire Ollama su un VPS descrive passo passo la configurazione del servizio.

Modalità di errore e messaggi visualizzati

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 controlla le dimensioni prima del caricamento, quindi si interrompe subito e indica il motivo. Passa alla riga di quantizzazione successiva, riduci la lunghezza del contesto oppure scegli un modello più piccolo.

llama.cpp non si interrompe, ma diventa estremamente lento. Per impostazione predefinita, llama.cpp utilizza il memory mapping per il file GGUF, quindi può avviare anche un file più grande della RAM disponibile. Il kernel trasferisce quindi i pesi da e verso il disco per ogni token e la generazione richiede diversi secondi per token, mentre il disco raggiunge il 100% di utilizzo. Passa --no-mmap per forzare un'allocazione effettiva, in modo che il processo si interrompa subito invece di degradare le prestazioni. Quando interviene il kernel, dmesg mostra il motivo:

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

Il file del modello non viene caricato in alcun caso. Un GGUF creato per una famiglia di modelli più recente rispetto al 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 compromesso del pinning e il motivo per cui devi annotare il numero della build. Devi sapere da quale versione stai effettuando l'aggiornamento.

L'API risponde localmente, ma non dall'applicazione. Ollama resta 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. È trascorso il periodo di inattività di 5 minuti 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 vuoi un endpoint compatibile con OpenAI senza configurazioni aggiuntive. È la scelta predefinita corretta per una prima distribuzione e per tutti i casi in cui prevedi di cambiare spesso modello.

Usa direttamente llama.cpp quando la memoria è così limitata da richiedere la selezione manuale della riga di 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 a malapena, perché le impostazioni che ne consentono l'esecuzione sono esattamente quelle che Ollama seleziona al posto tuo.

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

FAQ

Ollama è soltanto un wrapper per llama.cpp?

È una semplificazione, perché il wrapper svolge attività reali. Il README di Ollama indica llama.cpp come backend di inferenza (verificato il 2 agosto 2026). Ollama aggiunge un registry dei modelli, il template del prompt che converte i messaggi della chat in un prompt, un insieme di parametri di sampling predefiniti, un daemon che scarica i modelli inattivi e un'API HTTP. Se confronti i token al secondo con impostazioni identiche, stai confrontando lo stesso motore con se stesso. La scelta effettiva riguarda il livello di gestione.

Qual è il più veloce su un VPS con la sola CPU?

Usano lo stesso motore, quindi con lo stesso file del modello, la stessa quantizzazione, la stessa dimensione del contesto e lo stesso numero di thread le prestazioni sono simili. Le differenze riportate di solito dipendono da valori predefiniti diversi, soprattutto dalla lunghezza del contesto e dal numero di thread, non dal motore. Misura le prestazioni con llama-bench -m <file> -p 512 -n 128 e confronta la colonna tg sul tuo server prima di considerare attendibili i valori pubblicati.

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 registry. In questo modo puoi usare una quantizzazione non disponibile nel registry.

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; 8 GiB di RAM sono quindi sufficienti, mentre 4 GiB non bastano. La cache cresce con la dimensione del contesto: lo stesso modello con un contesto di 32,768 token richiede da solo circa 4 GiB di cache. Con Ollama, considera inoltre che il requisito cresce con OLLAMA_NUM_PARALLEL.