Ollama o llama.cpp su un VPS: quale scegliere

Ollama e 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 questo motore. Il README di Ollama indica ancora llama.cpp come backend di inferenza (verificato il 27 ottobre 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, la dimensione esatta del contesto e il numero esatto di thread, perché su un VPS con poca memoria ciascuna di queste impostazioni richiede 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 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. Il progetto pubblica ora release con versionamento semantico (MAJOR.MINOR.PATCH) e v0.7.0, pubblicata il 15 October 2026, era l'ultima release disponibile il 27 October 2026. I tag nightly con numero di build continuano a essere pubblicati insieme a queste release, diversi al giorno; l'ultimo disponibile il 27 October 2026 era b11913.

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 il versionamento semantico. v0.32.5 è stato pubblicato il 27 July 2026 e v0.40.12 è stato rilasciato il 27 October 2026 alle 00:07 UTC. 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 vengono salvati sul disco root e occupano diversi gigabyte ciascuno. Su un VPS con un volume root da 25 GB, conviene quindi sapere che cosa lascia il comando pull e come spostare altrove la directory dei modelli prima che il terzo download lo riempia.

Questa modalità di impacchettamento è l'unica differenza sostanziale. Ollama sceglie per te la quantizzazione, il template e la lunghezza del contesto e ti offre un unico nome da ricordare. llama.cpp espone queste impostazioni tramite flag, usando valori predefiniti automatici per quelle che non imposti.

Asse 1: controllo del modello e della quantizzazione

La quantizzazione memorizza i pesi usando meno bit rispetto ai 16 o 32 bit del modello originale. Le build GGUF più comuni usano in media circa 4, 5 o 8 bit per peso. La precisione non è uniforme in tutto il file. Nel codice sorgente del quantizzatore di llama.cpp (consultato il 27 ottobre 2026), una build Q4_K_M mantiene la maggior parte dei tensori a 4 bit, ma usa invece la quantizzazione Q6_K a 6 bit per il layer di output e per i tensori dei valori dell'attenzione e di riduzione del feed-forward in circa metà dei layer. I tensori piccoli, come quelli delle norme, non vengono quantizzati. È questo che permette a un modello da 8 miliardi di parametri di entrare nella RAM di un VPS ordinario. La nomenclatura GGUF è comprensibile una volta noto lo schema: Q4_K_M significa quantizzazione K a 4 bit, di dimensione media. Un numero più alto mantiene 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, consultate il 2 agosto 2026 e convertite da byte a GiB. 6 build dello stesso modello, con una dimensione minima di 2.96 GiB rispetto ai 7.95 GiB della build più grande. Il valore predefinito più comune, Q4_K_M, occupa 4.58 GiB. Su un VPS da 4 GiB, questa singola scelta determina se il modello viene caricato. La dimensione è solo metà della decisione, perché una riga che rientra nel budget non è automaticamente una riga che vale la pena usare. Il costo effettivo di Q4, Q8 e fp16 sulla qualità delle risposte indica se i gigabyte aggiuntivi apportano un miglioramento percepibile.

Con llama.cpp si specifica il file, quindi si sceglie direttamente quella riga.

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 è la dimensione del contesto in token, -t è il numero di thread e -ngl specifica quanti layer trasferire a una GPU (0 su un sistema con sola CPU). Le impostazioni non valorizzate usano i valori predefiniti. --fit è attivo per impostazione predefinita e adatta gli argomenti non impostati alla memoria disponibile sul dispositivo.

Con Ollama, la quantizzazione è associata al tag scaricato e ollama ls mostra ciò che è effettivamente presente sul disco. Quando 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 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. Un sistema senza GPU ricade nel bucket più piccolo: 4096 token. Se gli si invia un documento di 20,000 token, quelli aggiuntivi vengono eliminati prima che il modello possa esaminarli. La risposta può quindi risultare sicura ma errata rispetto a un file letto solo parzialmente. Aumentare il valore con OLLAMA_CONTEXT_LENGTH sul daemon oppure con PARAMETER num_ctx in un Modelfile. Se solo un'attività richiede una finestra più ampia, num_ctx può essere impostato per singola richiesta invece che a livello dell'intero server. In questo modo la cache aggiuntiva non viene mantenuta per tutte le altre attività gestite dal daemon. Anche llama.cpp non ha un valore predefinito sufficientemente affidabile. 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 è quindi già disponibile. 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, quindi vengono scaricati. La richiesta successiva deve ricaricare l’intero file prima di poter rispondere. Se il kernel conserva ancora il file nella page cache, l’operazione è rapida. Tuttavia, il file resta nella cache solo se c’è RAM disponibile. Quando altro lavoro lo espelle dalla cache, il file deve essere letto di nuovo dal disco. Su uno storage lento, ricaricare 4.58 GiB può trasformare una risposta di due secondi in una risposta di trenta secondi. Un keep-alive lungo elimina questa latenza, ma occupa la RAM in modo permanente. Entrambi sono costi reali. Scegli quello meno penalizzante. Se decidi che il modello deve semplicemente restare residente, impostare keep_alive in modo che superi i periodi di inattività e i riavvii richiede poche righe ed evita di dover riscaldare manualmente il modello ogni volta che il server si riavvia.

llama.cpp non fornisce né un demone né un utente di servizio, quindi devi configurarli manualmente. Dalla directory llama.cpp in cui hai eseguito la compilazione, installa il binario e le relative librerie in /usr/local, crea l’utente llama e assegnagli una copia del modello:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Se hai usato l’archivio della release invece di compilare il programma, imposta ExecStart sul percorso di llama-server al suo interno, perché l’archivio conserva le librerie accanto al binario. Scrivi quindi 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 manterrà quindi il modello per tutta la sua durata. Per impostazione predefinita, il modello non viene scaricato quando il servizio resta inattivo. L’aggiunta di --sleep-idle-seconds abilita però lo scaricamento e il ricaricamento automatici senza arrestare il servizio. Se la scrittura delle unità è una novità, si tratta dello stesso modello usato per eseguire i propri servizi con systemd su un VPS.

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

Questa asse si è ristretta molto. Ora entrambi i progetti supportano il formato chat di OpenAI, quindi la maggior parte delle librerie client funziona con entrambi dopo avere 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, mentre l’API nativa è disponibile anche su /api/chat. È inoltre documentato un endpoint compatibile con Anthropic. Nessuno di questi endpoint consente al modello di effettuare ricerche autonomamente. Se l’applicazione deve fornire risposte più recenti rispetto ai dati di addestramento del modello, prevedi di integrare la ricerca web tramite l’API di Ollama, Open WebUI o un breve ciclo di tool.

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"}]}'

Avviato con i flag precedenti, llama-server è in ascolto su 127.0.0.1:8080. Se lasciato alle impostazioni predefinite, ora usa la porta 9931 (verificato il 27 October 2026); quindi mantieni --port nella riga di comando se la tua applicazione si aspetta la porta 8080. Espone /v1/chat/completions, /v1/completions e /v1/embeddings, oltre al proprio endpoint /completion e a un'interfaccia web integrata. Espone anche route operative che Ollama non offre: /health per un readiness probe, /props per le impostazioni del modello caricato, /slots per indicare l'attività di ogni slot di richiesta e /metrics in formato Prometheus dopo avere aggiunto --metrics, perché questo endpoint è disabilitato per impostazione predefinita. Se prevedi di monitorare questo servizio, probabilmente questa differenza sarà determinante.

Nessuno dei due server abilita automaticamente l'autenticazione. Entrambi usano per impostazione predefinita 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 davvero un VPS con sole CPU

Un VPS con sole CPU esegue lentamente i modelli di piccole dimensioni. Questa è la sintesi corretta. La parte utile è capire dove si trova il limite. Misurare prima di progettare qualsiasi soluzione basata su questi dati:

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. La colonna tg indica la velocità di generazione dei token. Entrambe sono 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. Il problema principale è l'elaborazione del prompt: l'intero prompt viene elaborato prima che compaia il primo token della risposta. Un prompt di sistema lungo aggiunge quindi un'attesa a ogni richiesta. La lunghezza della risposta è la parte del carico che si può controllare direttamente. A tre token al secondo, infatti, un modello che genera una risposta prolissa di 600 token occupa il server per 200 secondi, cioè oltre tre minuti di sola generazione. Per questo limitare l'output con num_predict è il modo meno costoso per evitare che una singola 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 pratico con una dimensione precisa invece di un intervallo, Nemotron 3.5 Lightning scaricato e misurato su un VPS riporta il tag esatto, la quantità di RAM effettivamente richiesta e la velocità mantenuta senza GPU. Non utilizzabile su CPU: chat interattive 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 con dodici chiamate da quattro secondi ciascuna richiede un minuto prima di produrre un risultato. Se il piano prevedeva comunque un assistente per la programmazione, indirizzare un agent verso un modello gestito autonomamente indica quali attività un modello locale di piccole dimensioni può svolgere efficacemente e quali devono restare su un'API gestita.

Quando i numeri non sono sufficienti, esistono due alternative. Se il problema è la concorrenza, cioè molti utenti che accedono contemporaneamente a un unico modello, cambia la scelta del motore. Il confronto tra Ollama e vLLM per il serving concorrente analizza questo scenario. Se il problema è la velocità pura, la soluzione è un VPS con una GPU collegata, dove -ngl inizia ad avere un significato concreto. Prima di entrambe le opzioni, misura le prestazioni di base dell'hardware, perché la larghezza di banda di disco e memoria influisce sui tempi di caricamento quanto la CPU. Un benchmark ripetibile per VPS vale l'ora necessaria per eseguirlo.

Installare llama.cpp a una build fissata

Entrambi i progetti avanzano ogni settimana, quindi annota la versione distribuita. Il comando in 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 fissare una build specifica, usa invece il tarball precompilato disponibile nella pagina delle release. Il progetto pubblica ora anche release con versionamento semantico: v0.7.0 era l’ultima versione il 27 ottobre 2026 e la relativa pagina della release indicava nightly b11669 per i binari. v0.8.0 è stata pubblicata il 28 ottobre 2026 e la relativa pagina della release indicava nightly b11960 per i binari. I comandi seguenti usano b10224, il tag corrente del 2 agosto 2026; sostituiscilo con il tag che hai testato:

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 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 rispetto a quella disponibile nei piani più piccoli, quindi eseguila su una macchina più grande e copia i binari se quella 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. Le versioni precedenti di Ollama controllavano le dimensioni prima del caricamento e ollama run restituiva una riga di questo tipo:

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

Il codice sorgente attuale di Ollama non contiene più questo messaggio (verificato il 27 October 2026). Ora Ollama delega il caricamento a llama-server. Di conseguenza, un modello che non entra nella memoria disponibile viene segnalato come errore del runner, con messaggi che iniziano in questo modo:

llama-server reported out-of-memory during startup
llama-server process has terminated

In entrambi i casi, la correzione è la stessa. Passa alla riga successiva della quantizzazione, riduci la lunghezza del contesto oppure scegli un modello più piccolo.

llama.cpp non si arresta: diventa estremamente lento. Per impostazione predefinita, llama.cpp esegue il memory mapping del file GGUF. Anche un file più grande della RAM disponibile può quindi essere avviato. Il kernel trasferisce continuamente i pesi da e verso il disco per ogni token. La generazione rallenta fino a richiedere diversi secondi per token, mentre l'utilizzo del disco resta al 100 percento. Passa --load-mode none per disabilitare il memory mapping. Questa opzione ha sostituito --no-mmap, documentata come deprecata nella build b10224 fissata e non più presente nelle build attuali (verificato il 29 October 2026). Quando il kernel interviene, 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 motore produce un errore che indica un'architettura sconosciuta. <arch> è il nome memorizzato nei metadati del file:

llama_model_load: error loading model: unknown model architecture: '<arch>'

La correzione consiste nell'aggiornare il motore, non nel sostituire il file. Questo è il costo del blocco a una versione specifica e il motivo per cui devi annotare il numero di build. Devi sapere da quale versione stai eseguendo l'aggiornamento.

L'API risponde localmente, ma non dall'applicazione. Ollama si associa a 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 timeout di 5 minute per lo scaricamento in caso di inattività e il modello viene caricato di nuovo, dal disco se la page cache non lo ha mantenuto. 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 intorno a llama.cpp?

Quasi, ma il wrapper svolge attività aggiuntive. Il README di Ollama indica llama.cpp come backend di inferenza (verificato il 27 October 2026). Ollama aggiunge un registro dei modelli, il template del prompt che converte i messaggi della chat in un prompt, un set di parametri di campionamento predefiniti, 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. 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 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 che il registro non include.

Quanta RAM serve per un modello 8B?

Considera la dimensione 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; quindi 8 GiB di RAM sono 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, ricorda che il requisito cresce anche con OLLAMA_NUM_PARALLEL.