Come mantenere un modello Ollama in memoria

Perché Ollama scarica il modello dopo alcuni minuti?

Ollama mantiene un modello caricato in memoria per cinque minuti dall'ultima richiesta, quindi lo libera. La richiesta successiva deve leggere i pesi dal disco e mapparli nuovamente nella RAM o nella VRAM, causando un'attesa prima che venga restituito il primo token. Per questo un'interfaccia di chat o un agente di programmazione sembra veloce, resta inattivo per un po' e poi torna lento al messaggio successivo. Non c'è alcun problema. Il timer di inattività è scaduto.

Il timer si chiama keep_alive. È specifico per ogni modello e si riavvia 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 ogni modello caricato dal server.

Esistono due modi per impostare keep_alive: sulla 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 nulla, quindi la richiesta successiva deve eseguire un caricamento completo. PROCESSOR indica dove sono stati caricati i pesi. 100% GPU e 100% CPU rappresentano i casi evidenti. Una suddivisione come 25%/75% CPU/GPU significa che il modello non entrava nella VRAM: una parte viene quindi eseguita sul processore e la generazione è più lenta.

UNTIL indica il conto alla rovescia e stampa un tempo relativo come 4 minutes from now. Stampa Forever quando il modello è stato caricato con un valore negativo di keep_alive. 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 attività 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 significa che il modello viene eseguito sulla CPU.

Il costo effettivo del reload

Non procedere per supposizioni. Ollama riporta 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 suo valore load_duration è elevato. Dividilo per 1000000000 per leggerlo in secondi. La seconda chiamata viene eseguita mentre il modello è residente e riporta un valore molto più basso. La differenza tra queste due cifre è il costo che ogni utente sostiene dopo la scadenza del timer, ed è il motivo per cui conviene modificare keep_alive. La maggior parte di questa differenza dipende dalla lettura dal disco. Se hai spostato la directory del modello su un secondo volume, la velocità di quel volume determina il limite minimo di ogni caricamento a freddo. Per 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 numero di secondi: 3600
• un valore negativo, -1 o "-1m", che disabilita completamente il timeout di inattività
• 0, che scarica il modello non appena termina la richiesta

Un valore specificato nella richiesta sostituisce il valore predefinito del server, in entrambi i sensi. Questo è più importante di quanto possa sembrare: un client che invia il proprio keep_alive ha la precedenza su qualsiasi configurazione del server.

Puoi anche 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 reale 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 dispone di un valore proprio. Accetta gli stessi formati del campo della richiesta, quindi funzionano sia 30m sia 3600 sia -1.

Il punto critico è l’ambiente in cui 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. È il motivo più comune per cui l’impostazione sembra ignorata.

Rendi la configurazione persistente ai riavvii con un drop-in di systemd

sudo systemctl edit ollama.service

L’editor si apre con due marcatori di commento. Scrivi tra questi 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. Si tratta di un drop-in, non di una modifica all’unità fornita dal pacchetto. Di conseguenza, un aggiornamento del pacchetto Ollama che sostituisce ollama.service non modifica questa 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 stampa 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. Esegui la chiamata di precaricamento precedente per riscaldarlo.

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, e vale la pena analizzare il calcolo della memoria necessaria per eseguirne uno su un VPS con sola CPU prima di decidere di mantenerlo residente. Impostando keep_alive su -1, si stabilisce che il modello ha sempre la precedenza su tutto il resto del server. Su un VPS di piccole dimensioni, questo riduce direttamente le 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 avuto la precedenza e che un altro componente importante è stato terminato. Entrambi i risultati derivano dalla stessa decisione: usare 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 mantiene durante la generazione), e questa cache fa parte delle dimensioni del modello residente. Le sue dimensioni dipendono da num_ctx. Di conseguenza, aumentare la finestra di contesto aumenta la memoria occupata dal modello residente per tutta la durata dell'inattività, non soltanto mentre risponde. 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 unico modello, dimensiona la memoria in base agli slot, non soltanto ai pesi.

Un'impostazione predefinita ragionevole è usare -1 per un solo modello su un server con sufficiente margine di memoria. 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 restituisce un output vuoto 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 procedura invece di riavviare il servizio. Anche systemctl restart ollama libera 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 reale è la memoria. Di conseguenza, 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 è ancora scaduto, incluso un modello caricato con -1. Pertanto, un valore negativo per keep_alive indica l'assenza di un timeout per l'inattività. Non mantiene i pesi in memoria impedendo 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:

sudo journalctl -u ollama -f

Una riga relativa allo scaricamento di un runner per liberare spazio, accanto alla richiesta che lo ha causato, indica 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 che viene richiesto raramente.

Indicazioni valide anche per 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, tra cui OLLAMA_KEEP_ALIVE. Due regole sono rimaste valide tra le release e possono essere usate come base. Un valore specificato nella richiesta prevale sul valore predefinito del server. Inoltre, ollama ps indica ciò che è effettivamente caricato, indipendentemente da quanto dichiarato in un file di configurazione.

Se un editor o un agent gestisce il server, controlla ciò che invia il client prima di attribuire la causa al server. Configurare un agent di coding per usare il proprio server Ollama descrive 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. Quando scade, il server libera i pesi del modello. La richiesta successiva deve quindi ricaricarli dal disco, causando la pausa percepita. Aumenta questo 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 rimuovi il timer di inattività, senza modificare altro. Se viene richiesto un altro modello e la memoria disponibile non è sufficiente, 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. Un'altra causa può essere un client che invia il proprio 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 l'API, invia una richiesta senza prompt e con "keep_alive": 0. La risposta conterrà "done_reason": "unload". Verifica con ollama ps: il modello non dovrebbe più essere elencato.