Ollama pull o run: differenze e posizione dei modelli

ollama pull vs ollama run

ollama pull scarica un modello e termina. ollama run scarica il modello solo se non è presente, quindi lo carica in memoria e apre una chat interattiva. Il download è identico e i file vengono salvati nella stessa posizione. Solo run continua a eseguire operazioni.

Questa unica differenza determina quale comando usare in uno script e quale eseguire da una shell interattiva.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

La prima riga scarica il modello e termina, quindi è sicura da usare durante il provisioning e in un'unità systemd. La seconda apre una sessione di chat; digita /bye o premi Ctrl+D per uscire. La terza invia un singolo prompt, stampa la risposta e termina: è la forma adatta a uno script che deve ottenere una risposta, non aprire una sessione. Anche in questa terza forma, la lunghezza della risposta dipende interamente dal modello. Una domanda di una riga può quindi produrre tre paragrafi. Limitare la risposta con num_predict consente di mantenere run generato dallo script entro una dimensione che il chiamante può effettivamente usare. I nomi dei modelli cambiano rapidamente. Considera quindi gemma4 un segnaposto: è l'esempio usato dalla documentazione ufficiale di Ollama ad agosto 2026, e qualsiasi tag della libreria funziona nello stesso modo. Se preferisci sostituirlo con un modello già dimensionato per un server reale, eseguire Nemotron 3.5 Lightning su un VPS indica il tag esatto da scaricare e la quantità di memoria necessaria.

Perché il primo comando ollama run sembra bloccarsi

Un primo run su un VPS appena configurato può rimanere senza output per diversi minuti. Non c'è alcun problema. Il prompt della chat non può comparire finché il modello non è stato scaricato sul disco e caricato in memoria, quindi run esegue un download di diversi gigabyte prima di poter mostrare qualsiasi informazione.

Due fattori nascondono questa attività. Ollama visualizza la barra di avanzamento solo quando il suo output è un terminale, quindi un run all'interno di uno script shell, di un cron job, di un passaggio CI o di un semplice ssh host ollama run ... non stampa nulla durante il download. Dopo che i dati sono stati scaricati, il file deve ancora essere letto dal disco e caricato nella RAM prima che venga restituito il primo token; su un VPS di piccole dimensioni, questa operazione è lenta. Se il server non dispone di memoria sufficiente per il modello, il kernel inizia a usare lo swap e l'attesa si allunga notevolmente.

Monitorare il processo da una seconda sessione invece di procedere per supposizioni:

df -h /
watch -n5 df -h /

Uno spazio libero che diminuisce a intervalli indica che il download è ancora in corso. Se lo spazio libero smette di diminuire mentre il comando è ancora occupato, il download è terminato ed è iniziato il caricamento in memoria.

Per questo conviene eseguire il pull in anticipo. Chi digita ollama run non dovrebbe mai essere anche la persona che deve attendere il download.

Scaricare il modello prima che venga richiesto

Lo stesso vale per tutto ciò che non è una persona: un agente di programmazione configurato per usare il tuo endpoint Ollama di solito rinuncia alla prima richiesta invece di attendere il completamento di un download di diversi gigabyte. Su un nuovo server, esegui il pull nello stesso script che installa il server:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

Se stai configurando il server per la prima volta, la guida completa all'installazione di Ollama su un VPS descrive il servizio e gli utenti autorizzati a raggiungerlo. Dopo questo passaggio, conviene configurare un pull che continui anche dopo la chiusura del terminale, perché un download interrotto a metà può lasciare il model store incompleto.

Eseguilo all'interno di tmux oppure affidalo a systemd come unità one-shot eseguita all'avvio. Scrivi /etc/systemd/system/ollama-pull.service:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Entrambi i comandi usano intenzionalmente /bin/sh -c. Un semplice ExecStart= richiede un percorso assoluto e l'installer non inserisce sempre il binario nella stessa directory, quindi command -v ollama sul tuo server è l'unica risposta affidabile. L'esecuzione tramite la shell usa il PATH del servizio invece di un percorso copiato da una guida. Anche il primo ExecStart è importante: After=ollama.service indica che l'unità del server è stata avviata, ma non che sia pronta. Per questo il ciclo attende che ollama list risponda prima di iniziare il pull.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

Il journal dovrebbe mostrare il completamento del pull senza errori e ollama list dovrebbe quindi mostrare il modello. Per mantenere aggiornato un tag che cambia, aggiungi un timer systemd o una voce cron settimanale che esegua lo stesso pull. Ripetere il pull di un tag che è cambiato scarica i nuovi layer e lascia quelli precedenti senza riferimenti; questi vengono rimossi al successivo avvio del server.

Cosa accade quando un pull viene interrotto

Ogni layer di un modello viene memorizzato tramite un hash calcolato sui relativi contenuti. Un pull interrotto non comporta quindi la perdita del lavoro già svolto: esegui di nuovo lo stesso ollama pull e i layer già completati vengono riconosciuti e saltati. Il download riprende dal layer in cui si era interrotto.

Un'operazione elimina questo stato di avanzamento. Quando il server Ollama si avvia, rimuove i layer memorizzati a cui nessun manifest di modello fa riferimento. Il layer parziale lasciato da un pull interrotto rientra esattamente in questa categoria. Riavviare il servizio prima di riprovare elimina quindi la parte già scaricata. Ripeti prima il pull e riavvia in seguito. Se un download parziale deve effettivamente sopravvivere a un riavvio, imposta OLLAMA_NOPRUNE=1 nell'ambiente del servizio, quindi rimuovilo. La pulizia eseguita all'avvio impedisce infatti l'accumulo di layer orfani sul disco.

Se il pull si è interrotto con no space left on device, libera spazio prima di riprovare. Se df segnala che il disco è pieno e du sulla directory del modello non spiega l'utilizzo, lo spazio è stato occupato altrove. In questo caso, conviene leggere i motivi per cui df e du restituiscono valori diversi prima di eliminare qualsiasi elemento.

Dove Ollama archivia i modelli su un VPS?

Chiedi direttamente al tuo server invece di fidarti di un percorso indicato in una guida, inclusa questa. La posizione cambia tra un'installazione tramite pacchetto e un container e cambia ancora se qualcuno ha impostato OLLAMA_MODELS.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat stampa il file dell'unità insieme a ogni drop-in, quindi include anche una riga OLLAMA_MODELS impostata da te o incorporata nell'immagine. Se non è presente una riga di questo tipo, l'archivio si trova nella home directory dell'account con cui viene eseguito il servizio e getent passwd stampa quella home directory nel sesto campo separato da due punti. find cerca in un filesystem la directory blobs, che è il percorso in cui vengono effettivamente scritti i layer. Rimuovi -xdev se i modelli potrebbero trovarsi già su un mount separato.

Ora misura e interpreta i valori del tuo sistema:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

L'archivio ha due parti. manifests contiene un piccolo file per ogni tag del modello e quel file elenca i layer da cui è composto il tag. blobs contiene i layer veri e propri, ciascuno identificato dall'hash del proprio contenuto; quasi tutto lo spazio occupato si trova qui. Poiché i layer sono condivisi tra i tag, due modelli basati sugli stessi pesi riportano ciascuno la propria dimensione in ollama list, ma occupano quello spazio una sola volta sul disco. Di conseguenza, la somma delle dimensioni elencate può superare il valore riportato da du per la directory.

I file dei modelli riempiono il filesystem root di un VPS di piccole dimensioni più rapidamente di qualsiasi altro componente che probabilmente installerai. Il fattore che incide maggiormente sulla dimensione è il formato dei pesi. Scegliere tra q4, q8 e fp16 può fare risparmiare diversi gigabyte per modello.

Spostare i modelli su un volume dati con OLLAMA_MODELS

Se il piano prevede un secondo disco o un volume dati più grande, sposta lo store prima che il filesystem root si riempia. Arresta prima il server, per non copiare un file mentre è ancora in scrittura.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit apre un editor su un file drop-in, lasciando invariata l’unità fornita dal pacchetto ed evitando che un aggiornamento del pacchetto sovrascriva la modifica. Aggiungi queste due righe:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show dovrebbe visualizzare il nuovo percorso e ollama list dovrebbe mostrare gli stessi modelli visualizzati prima dello spostamento. Un elenco vuoto indica che il server non riesce a leggere la nuova directory. Il servizio viene eseguito come utente ollama, quindi quell’utente deve disporre dei permessi di lettura e scrittura sulla destinazione. Questo è il compito della riga chown precedente. Controlla journalctl -e -u ollama per individuare errori di autorizzazione relativi al nuovo percorso. Elimina la copia precedente solo dopo aver verificato che l’elenco sia corretto: uno spostamento non riuscito seguito dall’eliminazione della sorgente obbligherebbe a scaricare nuovamente tutto.

L’altra opzione mantiene il percorso originale e monta il volume dati su quel percorso:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

Se findmnt stampa il mount, il bind è attivo. Un bind mount è utile quando un altro componente del server si aspetta già il percorso predefinito. Presenta però un problema: i file copiati si trovano ancora sotto il mount point sul disco root, nascosti dal mount. Lo spazio non viene quindi recuperato finché non smonti il volume e non rimuovi quei file. La variabile d’ambiente è l’opzione più semplice da spiegare alla persona che effettuerà il prossimo accesso.

Dove il container li conserva invece

L’immagine ufficiale conserva i modelli nel volume montato, non in una directory dell’host appartenente a un utente ollama. Il comando documentato per l’avvio è:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama prima dei due punti è un volume Docker denominato, mentre /root/.ollama indica il percorso in cui il server scrive all’interno del container. Di conseguenza, du non trova nulla nei percorsi della sezione precedente, perché quei file non si trovano lì. Visualizza il percorso e le dimensioni effettivi:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Leggi il campo Mountpoint da docker volume inspect, quindi esegui sudo du -sh su quel percorso. Per conservare i modelli in un volume di dati, sostituisci il volume denominato con una directory dell’host (-v /mnt/data/ollama:/root/.ollama) e ricrea il container. Il container scrive come root, quindi la directory dell’host risulta di proprietà di root. Con Podman rootless, invece, gli ID vengono mappati nell’intervallo subuid dell’utente; la proprietà visualizzata sull’host risulta quindi ancora diversa: eseguire Ollama con Podman rootless descrive questa mappatura.

Una precisazione riguarda la pulizia. docker volume prune rimuove ogni volume a cui non fa riferimento alcun container. Se rimuovi o ricrei il container ollama senza il relativo volume, una successiva operazione di prune elimina tutti i modelli scaricati. Non sarà possibile recuperarli, se non scaricandoli di nuovo. Leggi come ridurre l’uso del disco Docker su un VPS prima di eseguire prune su un server che ospita modelli.

Rimuovere un modello con ollama rm, non con rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm elimina il manifest relativo a quel tag, quindi elimina i layer a cui nessun manifest rimanente fa riferimento. Lo spazio torna disponibile non appena questi file vengono scollegati, quindi df si completa subito. Poiché i layer sono condivisi, la rimozione di uno dei due tag strettamente correlati può liberare molto meno dello spazio indicato dalla dimensione ollama list accanto al tag. È il comportamento previsto, non un errore di eliminazione.

Eliminare manualmente i file rompe la relazione tra questi elementi. Rimuovi un blob con rm, ma il manifest continua a elencarlo; di conseguenza ollama list continua a mostrare il modello e qualsiasi tentativo di utilizzarlo fallisce quando viene letto il layer mancante. Se rimuovi manualmente un manifest, i relativi layer restano sul disco senza alcun riferimento e occupano spazio che nessun comando Ollama ti segnalerà. Se lo hai già fatto, ollama rm sul tag rimuove la voce residua e il riavvio del server elimina i layer a cui non fa riferimento alcun manifest.

È necessaria un'ultima distinzione, perché i due aspetti vengono continuamente confusi. ollama rm riguarda lo spazio su disco. ollama stop gemma4 scarica un modello dalla memoria e non libera spazio su disco. Il tempo per cui un modello resta residente nella RAM una volta completato il download è regolato da un'impostazione distinta; mantenere un modello caricato invece di ricaricarlo a ogni richiesta descrive questo comportamento.

FAQ

Qual è la differenza tra ollama pull e ollama run?

ollama pull scarica un modello sul disco e termina. ollama run verifica se il modello è già presente sul disco, lo scarica se non lo è, lo carica in memoria e apre quindi una sessione interattiva di chat. Entrambi scrivono gli stessi file nella stessa directory. Usa pull durante il provisioning e negli script; usa run quando una persona lavora al terminale. ollama run <model> "your prompt" invia un prompt e termina: è la forma utilizzabile negli script di run.

Perché il primo ollama run sembra bloccarsi?

Sta eseguendo il download. Il prompt della chat non può comparire finché il modello non è stato scritto sul disco e caricato in memoria; un modello occupa diversi gigabyte. Ollama visualizza la barra di avanzamento solo quando l'output è diretto a un terminale, quindi un run eseguito in uno script, in un cron job o in un ssh host ollama run ... non mostra nulla mentre l'operazione è in corso. Apri una seconda sessione ed esegui watch -n5 df -h /: se lo spazio libero diminuisce a intervalli, il download è in corso. Scarica il modello in anticipo per evitare l'attesa.

Dove archivia Ollama i modelli?

La posizione dipende dal tipo di installazione, quindi stampala invece di presupporla. Esegui systemctl cat ollama.service per verificare se OLLAMA_MODELS è impostata nell'unità o in un drop-in. Se non è impostata, l'archivio si trova nella home directory dell'account con cui viene eseguito il servizio; getent passwd ollama stampa questa directory. sudo find / -xdev -type d -name blobs 2>/dev/null individua direttamente la directory dei layer. Nell'immagine del container, l'archivio si trova nel volume montato e docker volume inspect ollama stampa il relativo Mountpoint sull'host.

Come posso spostare i modelli di Ollama su un altro disco?

Arresta il servizio, copia l'archivio nella nuova posizione con rsync -a, assegna la directory all'account del servizio con sudo chown -R ollama:ollama <directory>, quindi esegui sudo systemctl edit ollama.service e aggiungi Environment="OLLAMA_MODELS=<directory>" sotto una riga [Service]. Ricarica la configurazione con sudo systemctl daemon-reload e riavvia il servizio. Verifica con systemctl show ollama --property=Environment e ollama list. Un elenco vuoto significa quasi sempre che l'utente ollama non può leggere la nuova directory; journalctl -e -u ollama mostra il percorso.

L'eliminazione dei file del modello libera spazio?

L'eliminazione manuale dei file libera i byte, ma lascia l'archivio in uno stato incoerente. Se rimuovi un blob, il manifest continua a elencare quel modello, che continua quindi a comparire in ollama list e non può essere utilizzato. Se rimuovi un manifest, i relativi layer restano sul disco senza alcun riferimento. Usa ollama rm <model>: elimina il manifest e poi i layer che nessun altro modello utilizza. Se i file sono già stati eliminati manualmente, esegui ollama rm sul tag per rimuovere la voce, quindi riavvia il server; il riavvio rimuove i layer ai quali non fa riferimento alcun manifest.