Ollama pull o run: dove finiscono i modelli

differenze tra ollama pull e 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 nello stesso percorso. Solo run continua con le operazioni successive.

Questa differenza determina quale comando usare in uno script e quale usare da una sessione interattiva.

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

La prima riga scarica il modello e termina, quindi è adatta al provisioning e a un'unità systemd. La seconda apre una sessione di chat; digita /bye oppure premi Ctrl+D per uscire. La terza invia un singolo prompt, stampa la risposta e termina. È il formato adatto a uno script che deve ottenere una risposta anziché avviare una sessione. 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 si comporta allo stesso modo.

Perché il primo avvio di ollama sembra bloccato

Un primo run su un VPS appena configurato può restare senza produrre output per diversi minuti. Non c’è un problema. Il prompt della chat non può comparire finché il modello non è stato scaricato sul disco e caricato in memoria, quindi run sta eseguendo un download di diversi gigabyte prima di poter mostrare qualcosa.

Due aspetti nascondono questa attività. Ollama visualizza la barra di avanzamento solo quando l’output è un terminale, quindi un run eseguito 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 il download, il file deve comunque 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 ulteriormente.

Controlla l’operazione da una seconda sessione invece di procedere per tentativi:

df -h /
watch -n5 df -h /

Se lo spazio libero diminuisce a intervalli, il download è ancora in corso. Se lo spazio libero smette di diminuire mentre il comando è ancora in esecuzione, 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 la persona che deve attendere il download.

Scaricare il modello prima che venga richiesto

Su un server nuovo, esegui il download tramite lo 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 chi può raggiungerlo. In seguito conviene configurare un download che continui anche dopo la chiusura del terminale, perché un download interrotto a metà può lasciare il repository dei modelli incompleto.

Eseguilo all'interno di tmux oppure affidalo a systemd come unità one-shot da eseguire 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 passano volutamente attraverso /bin/sh -c. Un ExecStart= senza percorso richiede un percorso assoluto e l'installer non inserisce sempre il binario nella stessa directory, quindi command -v ollama sul 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, quindi il ciclo attende che ollama list risponda prima di avviare il download.

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

Il journal dovrebbe mostrare il completamento del download senza errori e ollama list dovrebbe quindi mostrare il modello. Per mantenere aggiornato un tag mobile, aggiungi un timer systemd o una voce cron settimanale che esegua lo stesso download. Se esegui nuovamente il download di un tag che è cambiato, vengono scaricati i nuovi layer e quelli precedenti restano senza riferimenti; verranno rimossi al successivo avvio del server.

Cosa succede quando un pull viene interrotto

Ogni layer di un modello viene archiviato usando un hash calcolato sul proprio contenuto. Un pull interrotto non rappresenta quindi lavoro perso: esegui di nuovo lo stesso ollama pull. I layer già completati vengono riconosciuti e ignorati, quindi il download riprende dal layer interrotto.

Un'azione elimina questo avanzamento. Quando il server Ollama si avvia, rimuove i layer archiviati a cui nessun manifest di modello fa riferimento. Il layer parziale lasciato da un pull interrotto è esattamente uno di questi. 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 necessariamente sopravvivere a un riavvio, imposta OLLAMA_NOPRUNE=1 nell'ambiente del servizio, quindi rimuovilo, perché è la pulizia all'avvio a impedire 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 nella directory del modello non spiega l'occupazione, lo spazio è stato utilizzato altrove. Prima di eliminare qualsiasi elemento, conviene leggere i motivi per cui df e du mostrano valori diversi.

Dove archivia Ollama i modelli su un VPS?

Verificate direttamente sul vostro server invece di fidarvi di un percorso indicato in una guida, inclusa questa. Il percorso cambia tra un'installazione tramite pacchetto e un container e cambia nuovamente 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 mostra anche una riga OLLAMA_MODELS impostata manualmente o inclusa nell'immagine. In assenza di questa riga, l'archivio si trova nella home directory dell'account con cui viene eseguito il servizio; getent passwd stampa tale home directory nel sesto campo separato da due punti. find cerca il percorso blobs in un filesystem; è qui che vengono effettivamente scritti i layer. Rimuovete -xdev se i modelli potrebbero trovarsi già su un mount separato.

Ora misurate e leggete i vostri valori:

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

L'archivio ha due componenti. manifests contiene un file di piccole dimensioni per ogni tag del modello e il file elenca i layer da cui è composto il tag. blobs contiene i layer veri e propri, ciascuno denominato in base all'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 indicano ciascuno la propria dimensione in ollama list, ma occupano una sola volta quello spazio su disco. Di conseguenza, le dimensioni elencate possono superare il valore restituito da du per la directory.

I file dei modelli riempiono il filesystem root di un VPS di piccole dimensioni più rapidamente di quasi qualsiasi altro componente che probabilmente installerete. Il fattore che incide maggiormente sulle dimensioni è il formato dei pesi. Scegliere tra q4, q8 e fp16 può far 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, spostare l'archivio prima che il filesystem root si riempia. Arrestare prima il server, per evitare di 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, quindi l'unità fornita dal pacchetto resta invariata e un aggiornamento del pacchetto non può sovrascrivere la modifica. Aggiungere 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 stampare 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 questo utente deve avere accesso in lettura e scrittura alla destinazione; questo è il compito della riga chown precedente. Controllare journalctl -e -u ollama per individuare errori di autorizzazione che indicano il nuovo percorso. Eliminare la copia precedente solo dopo aver verificato che l'elenco sia corretto, perché uno spostamento non riuscito seguito dall'eliminazione della sorgente obbliga 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 /

La stampa di findmnt indica che il mount è attivo. Un bind mount è utile quando un altro componente del server si aspetta già la posizione predefinita. Presenta però un problema: i file copiati restano sotto il mount point sul disco root, nascosti dal mount, quindi lo spazio non viene recuperato finché non si smontano il volume e si rimuovono i file. La variabile d'ambiente è l'opzione più semplice da spiegare alla persona che accederà al server successivamente.

Dove li conserva invece il container

L'immagine ufficiale conserva i modelli nel percorso 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 è il percorso in cui il server scrive all'interno del container. Per questo du sui percorsi della sezione precedente non trova nulla: quei file non si trovano lì. Visualizza il percorso e le dimensioni effettive:

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 salvare i modelli in un volume 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; anche la proprietà visualizzata sull'host cambia: eseguire Ollama con Podman rootless descrive questo mapping.

Un'avvertenza sulla pulizia. docker volume prune rimuove tutti i volumi a cui nessun container fa riferimento. Se rimuovi o ricrei il container ollama senza il relativo volume, una successiva operazione di prune elimina tutti i modelli scaricati, senza possibilità di 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 per quel tag, quindi elimina i layer ai quali nessun manifest fa più riferimento. Lo spazio viene recuperato non appena questi file vengono scollegati, quindi df si aggiorna immediatamente. 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. È un comportamento corretto, non un'eliminazione non riuscita.

Eliminare manualmente i file rompe la corrispondenza tra i due elementi. Rimuovendo un blob con rm, il manifest continua a elencarlo; di conseguenza ollama list continua a mostrare il modello e ogni tentativo di utilizzarlo non riesce quando viene letto il layer mancante. Rimuovendo manualmente un manifest, i relativi layer restano sul disco senza alcun riferimento e occupano spazio che nessun comando Ollama segnalerà. Se lo hai già fatto, ollama rm sul tag elimina la voce residua; il riavvio del server elimina i layer ai quali non fa riferimento alcun elemento.

Un'ultima distinzione, perché i due concetti vengono confusi spesso. 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 dopo il completamento del download è controllato da un'impostazione separata; la sezione mantenere un modello caricato invece di ricaricarlo a ogni richiesta la descrive.

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 trova, lo carica in memoria e apre quindi una sessione di chat interattiva. Entrambi scrivono gli stessi file nella stessa directory. Usare pull durante il provisioning e negli script, e run quando una persona lavora dalla shell. ollama run <model> "your prompt" invia un prompt e termina; è la forma utilizzabile negli script di run.

Perché il primo ollama run sembra bloccarsi?

Il modello è in fase di download. Il prompt della chat non può comparire finché il modello non è stato scaricato sul disco e caricato in memoria, e 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, da un cron job o in un ssh host ollama run ... non mostra nulla mentre il download è in corso. Aprire una seconda sessione ed eseguire watch -n5 df -h /: se lo spazio libero diminuisce a intervalli, il download è in corso. Scaricare il modello in anticipo elimina l'attesa.

Dove archivia Ollama i propri modelli?

La posizione dipende dal tipo di installazione, quindi è preferibile visualizzarla invece di presupporla. Eseguire 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 tale directory. sudo find / -xdev -type d -name blobs 2>/dev/null individua direttamente la directory dei layer. Nell'immagine 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?

Arrestare il servizio, copiare l'archivio nella nuova posizione con rsync -a, assegnare la directory all'account del servizio con sudo chown -R ollama:ollama <directory>, quindi eseguire sudo systemctl edit ollama.service e aggiungere Environment="OLLAMA_MODELS=<directory>" sotto una riga [Service]. Ricaricare la configurazione con sudo systemctl daemon-reload e riavviare il servizio. Verificare con systemctl show ollama --property=Environment e ollama list. Un elenco vuoto indica quasi sempre che l'utente ollama non può leggere la nuova directory; journalctl -e -u ollama mostrerà il percorso.

L'eliminazione dei file dei modelli libera spazio?

L'eliminazione manuale dei file libera i byte, ma lascia l'archivio in uno stato incoerente. Se si rimuove un blob, il manifest continua a elencare quel modello, che continua quindi a comparire in ollama list e non funziona quando viene utilizzato. Se si rimuove un manifest, i relativi layer restano sul disco senza alcun riferimento. Usare ollama rm <model>, che elimina il manifest e poi i layer non necessari ad altri modelli. Se i file sono già stati eliminati manualmente, eseguire ollama rm sul tag per rimuovere la voce, quindi riavviare il server: il riavvio rimuove i layer a cui nessun manifest fa riferimento.