Come tenere un modello Ollama sempre in memoria

Perché Ollama scarica il modello dopo alcuni minuti?

Ollama mantiene un modello caricato in memoria per cinque minuti dall'ultima richiesta, poi lo rimuove dalla memoria. La richiesta successiva deve rileggere i pesi dal disco e mapparli nuovamente in RAM o VRAM. Per questo la risposta si blocca prima della generazione del primo token. È il motivo per cui un'interfaccia di chat o un agente di coding sembra veloce, resta inattivo per un po' e poi torna lento al messaggio successivo. Non c'è un guasto. Il timer di inattività è scaduto.

Il timer si chiama keep_alive. È specifico per ogni modello e viene riavviato ogni volta che una richiesta termina. Un modello che sta rispondendo a una richiesta non viene mai scaricato, perché il server fa scadere il modello solo quando non ci sono richieste attive. Ad agosto 2026 il valore predefinito è cinque minuti e si applica a tutti i modelli caricati dal server.

È possibile impostare keep_alive in due punti: nella singola richiesta oppure come valore predefinito del server. Un drop-in di systemd permette di mantenere il valore predefinito del server anche dopo un riavvio. Questa guida presuppone che Ollama sia già in esecuzione come servizio. In caso contrario, iniziare da installare Ollama su un VPS e poi tornare qui.

Quali modelli sono attualmente residenti e quando scadono?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Un output vuoto significa che non è stato caricato alcun modello, quindi la richiesta successiva richiede un caricamento completo. PROCESSOR indica dove sono stati caricati i pesi. 100% GPU e 100% CPU sono i casi più chiari. Una suddivisione come 25%/75% CPU/GPU indica che il modello non entra nella VRAM: una parte viene quindi eseguita sul processore e la generazione è più lenta.

UNTIL è il conto alla rovescia e stampa un tempo relativo come 4 minutes from now. Stampa Forever quando il modello è stato caricato con un valore keep_alive negativo. Stampa Stopping... durante il breve intervallo in cui il server sta scaricando il modello.

L'insieme delle colonne è cambiato tra le diverse release, quindi leggete l'intestazione invece di contare i campi in uno script. Per le operazioni automatizzate, interrogate l'API:

curl -s http://localhost:11434/api/ps

Ogni voce contiene expires_at, un timestamp assoluto come 2026-08-09T14:38:31.83753Z, e size_vram, la parte del modello presente nella memoria GPU. Un valore size_vram pari a 0 indica che il modello è in esecuzione sulla CPU.

Quanto costa realmente il reload

Non fare supposizioni. Ollama restituisce il tempo di caricamento in ogni risposta, nel campo load_duration, espresso in nanosecondi.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

La prima chiamata carica il modello, quindi il valore di load_duration è elevato. Dividilo per 1000000000 per leggerlo in secondi. La seconda chiamata viene eseguita mentre il modello è ancora residente e restituisce un valore molto più basso. La differenza tra questi due valori è il tempo che ogni utente deve attendere una volta scaduto il timer. È questo il motivo per cui conviene modificare keep_alive. Per conoscere la velocità di generazione prima e dopo questa pausa, consulta come misurare i token al secondo sul tuo server.

Mantieni un modello Ollama caricato in memoria per una richiesta

Invia keep_alive con la richiesta. L'impostazione si applica al modello dal momento in cui la richiesta termina.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Sono accettati quattro formati di valore:

• una stringa che indica una durata: "30m", "24h", "90s"
• un numero semplice, interpretato come secondi: 3600
• un valore negativo, -1 o "-1m", che indica l'assenza completa di timeout di inattività
• 0, che scarica il modello non appena la richiesta termina

Un valore specificato nella richiesta sostituisce il valore predefinito del server, in entrambe le direzioni. Questo è più importante di quanto sembri: un client che invia il proprio keep_alive prevale su qualsiasi valore configurato sul server.

È inoltre possibile caricare un modello senza generare alcun contenuto. Invia soltanto il nome del modello. Il server lo carica e restituisce una risposta vuota con "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Questo è il comando da eseguire dopo un riavvio o dopo aver scaricato un nuovo modello, in modo che la prima richiesta effettiva dell'utente non debba attendere il caricamento. La CLI svolge la stessa funzione con un flag:

ollama run --keepalive 30m qwen3:8b "hello"

Mantienilo caricato per impostazione predefinita con OLLAMA_KEEP_ALIVE

Il server legge OLLAMA_KEEP_ALIVE all’avvio e lo usa per ogni modello che non definisce un valore proprio. Accetta gli stessi formati del campo della richiesta, quindi funzionano 30m, 3600 e -1.

Il punto è in quale ambiente deve essere definita la variabile. Eseguire export OLLAMA_KEEP_ALIVE=30m nella sessione SSH non produce alcun effetto, perché l’installazione tramite pacchetto esegue il server come servizio systemd, con un utente e un ambiente propri. La shell di login e il servizio non condividono l’ambiente. Questo è il motivo più comune per cui l’impostazione sembra ignorata.

Rendi l'impostazione persistente dopo un riavvio con un drop-in di systemd

sudo systemctl edit ollama.service

L'editor si apre con due marcatori di commento. Scrivi tra i due marcatori: systemd ignora tutto ciò che viene scritto sotto il secondo.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Il salvataggio scrive /etc/systemd/system/ollama.service.d/override.conf. Questo è un drop-in, non una modifica dell'unità fornita dal pacchetto. Pertanto, un aggiornamento del pacchetto Ollama che sostituisce ollama.service non modifica la tua impostazione. Se i drop-in e i file unità sono concetti nuovi, la guida ai servizi e ai timer di systemd ne descrive il funzionamento.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

L'ultimo comando mostra l'ambiente con cui il servizio verrà effettivamente eseguito. Se OLLAMA_KEEP_ALIVE=30m manca da quella riga, il drop-in non è stato applicato. La causa è quasi sempre un'intestazione [Service] mancante oppure righe inserite sotto il marcatore. Il riavvio scarica tutti i modelli caricati, quindi la richiesta successiva esegue un caricamento a freddo. Riscalda il modello con la chiamata di precaricamento precedente.

Quanto costa mantenere un modello residente

La colonna SIZE in ollama ps indica la memoria occupata per tutta la finestra di inattività, non soltanto durante una richiesta. Un modello 8B con quantizzazione a 4 bit occupa circa 5-6 GB. Un modello 27B richiede una valutazione diversa: prima di decidere di mantenerlo residente, conviene esaminare il calcolo della memoria necessaria per eseguirlo su un VPS con sola CPU. Impostando keep_alive su -1, si decide che il modello ha priorità permanente su tutto il resto del server. Su un VPS di piccole dimensioni, questo comporta una riduzione diretta delle risorse disponibili per il database, l'applicazione web e i processi di build.

Controlla i valori effettivi invece di affidarti a una stima. Esegui questo comando mentre un modello è caricato, quindi ripetilo dopo ollama stop:

free -h

La colonna available indica la memoria che il kernel può ancora assegnare a un nuovo processo. Su un server con GPU NVIDIA, nvidia-smi mostra la stessa situazione nella VRAM. Se il server esaurisce la memoria, il kernel termina un processo per recuperare risorse:

sudo dmesg -T | grep -i "out of memory"

Una riga che indica ollama significa che il server del modello è stato terminato. Una riga che indica il database significa che il modello ha prevalso e che un servizio importante è stato interrotto. Entrambi i risultati derivano dalla stessa decisione: impostare una finestra di keep-alive lunga su un server senza margine di memoria.

In questo caso è facile trascurare due costi. Una lunghezza del contesto maggiore riserva una cache KV più grande (key value cache, lo stato dell'attenzione per token che il modello conserva durante la generazione), e questa cache rientra nella dimensione residente. Un valore OLLAMA_NUM_PARALLEL superiore a 1 riserva questa cache una volta per ogni slot parallelo. Se prevedi di servire più persone con un solo modello, dimensiona la memoria in base agli slot, non soltanto ai pesi.

Un valore predefinito ragionevole è -1 per un solo modello su un server con memoria disponibile. Su un server condiviso, usa una finestra che copra gli intervalli tra le richieste, ad esempio 30m, così la memoria viene rilasciata quando smetti di lavorare.

Scaricare immediatamente un modello

ollama stop qwen3:8b

Il comando non restituisce alcun output e il modello scompare da ollama ps. Per un nome non caricato restituisce couldn't find model "qwen3:8b" to stop. La forma API è una richiesta senza prompt, con keep_alive impostato su 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

La risposta contiene "done_reason": "unload". Usare questa opzione invece di riavviare il servizio. systemctl restart ollama libera anche la memoria, ma rimuove tutti gli altri modelli caricati e interrompe ogni richiesta in esecuzione.

Eseguire più modelli su un singolo server

OLLAMA_MAX_LOADED_MODELS limita il numero di modelli caricati contemporaneamente. Ad agosto 2026, il valore predefinito è tre per GPU oppure tre su un sistema con sola CPU. Il limite conta i modelli, ma il vincolo effettivo è la memoria. Per questo, il caricamento di un secondo modello di grandi dimensioni può essere rifiutato molto prima di raggiungere tre modelli.

Quando viene richiesto un nuovo modello e la memoria disponibile non è sufficiente, lo scheduler scarica uno dei modelli residenti per liberare spazio. Preferisce un modello senza richieste attive. Può anche rimuovere un modello il cui timer non è scaduto, incluso un modello caricato con -1. Pertanto, un valore negativo di keep_alive disabilita il timeout di inattività. Non blocca i pesi per impedire il caricamento di un altro modello.

Questa decisione viene registrata al livello di debug. Aggiungi una seconda riga Environment="OLLAMA_DEBUG=1" allo stesso drop-in, riavvia il servizio e monitora il log:

sudo journalctl -u ollama -f

Una riga che indica lo scaricamento di un runner per liberare spazio, accanto alla richiesta che lo ha causato, conferma che questi due modelli non possono essere caricati insieme su questa macchina. La soluzione consiste nell'usare meno modelli su questo server oppure nell'impostare una finestra lunga per il modello che deve rispondere rapidamente e 0 per quello utilizzato raramente.

Indicazioni che restano valide oltre la prossima release

Ollama rilascia spesso nuove versioni e i valori predefiniti cambiano. Controlla quindi la build in uso invece di memorizzare i numeri:

ollama --version
ollama serve --help

ollama serve --help elenca le variabili d'ambiente che la build legge effettivamente, incluso OLLAMA_KEEP_ALIVE. Due regole sono rimaste valide tra le release e possono essere usate senza rischi. Un valore specificato nella richiesta ha la precedenza sul valore predefinito del server. Inoltre, ollama ps indica cosa è effettivamente caricato, indipendentemente da quanto dichiarato da un file di configurazione.

Se un editor o un agente controlla il server, verifica cosa invia il client prima di attribuire il problema al server. Indirizzare un agente di programmazione al proprio server Ollama spiega dove si trovano queste impostazioni della richiesta.

FAQ

Perché Ollama scarica il modello dopo 5 minuti?

Cinque minuti è il valore predefinito di keep_alive, il timer di inattività che Ollama avvia quando una richiesta termina. Alla scadenza, il server libera i pesi; la richiesta successiva deve quindi ricaricarli dal disco. È questo il ritardo che si osserva. Aumenta il valore per una singola richiesta inviando "keep_alive": "30m" nel corpo JSON oppure per l'intero server usando la variabile d'ambiente OLLAMA_KEEP_ALIVE.

Come posso mantenere permanentemente un modello Ollama in memoria?

Usa un valore negativo: "keep_alive": -1 nella richiesta oppure OLLAMA_KEEP_ALIVE=-1 per il server. ollama ps mostra quindi Forever nella colonna UNTIL. In questo modo viene rimosso il timer di inattività, senza modificare altro. Se viene richiesto un altro modello e la memoria disponibile è insufficiente, lo scheduler scarica comunque questo modello per fare spazio.

Perché OLLAMA_KEEP_ALIVE viene ignorata?

Controlla dove l'hai impostata. Esegui systemctl show ollama --property=Environment. Se la variabile non compare nell'output, il server non l'ha mai ricevuta, perché una variabile esportata nella shell non viene trasmessa a un servizio systemd. Impostala con sudo systemctl edit ollama.service, quindi esegui sudo systemctl daemon-reload e sudo systemctl restart ollama. L'altra causa possibile è un client che invia il proprio valore keep_alive nella richiesta, sovrascrivendo il valore predefinito del server.

Come posso liberare la memoria senza riavviare Ollama?

ollama stop qwen3:8b scarica immediatamente quel modello e lascia in esecuzione il server e tutti gli altri modelli caricati. Tramite API, invia una richiesta senza prompt e con "keep_alive": 0. La risposta contiene "done_reason": "unload". Verifica con ollama ps: il modello non dovrebbe più essere elencato.