Ollama 0.40: i modelli si aggiornano da soli e per un po’ occupano il doppio su disco

Questo pezzo è per chi usa Ollama sul proprio computer o su un piccolo server e sta per aggiornarlo. È una nota a margine della puntata 2 della Guida AI locale, quella sui runtime, e vive nell'hub AI engineering.

In breve: con Ollama 0.40.2, uscito l'8 ottobre, i modelli scaricati con le versioni precedenti vengono convertiti in background la prima volta che li avvii. Ollama tiene anche la copia vecchia come backup, per permetterti di tornare indietro. Quindi, per un po', ogni modello che usi occupa circa il doppio su disco. Prima di aggiornare controlla lo spazio libero. Dopo, quando sei sicuro di non voler tornare a una versione precedente alla 0.40, puoi cancellare i backup con lo script indicato nelle note di rilascio.

Aggiornamento del 21 ottobre 2026: dalla 0.40.3 dell'11 ottobre Ollama ha sospeso la conversione dei modelli in background. Secondo la pull request #18908 pesava su ogni richiesta e sulla memoria nei carichi ad alto volume, come i modelli di embedding, e tornerà in una release futura. I modelli già convertiti e i loro backup restano sul disco. Fino alla 0.40.7 del 18 ottobre le note non annunciano ancora la rimozione automatica dei backup: lo script più sotto resta il modo per recuperare spazio.

Cosa è cambiato davvero

La serie 0.40 ha avuto tre rilasci in due settimane, poi una serie di patch fino alla 0.40.7 del 18 ottobre. Per il disco contano queste righe, da leggere insieme.

Le date sono quelle delle release su GitHub, riportate all'ora italiana.

Il punto che tocca tutti è il terzo. Le note della 0.40.2 dicono che i modelli scaricati prima vengono aggiornati in background al primo avvio, "per prestazioni e compatibilità migliori quando girano su llama.cpp". La descrizione della pull request #18874 spiega il meccanismo: i GGUF vecchi che dipendevano dalle patch di Ollama su llama.cpp vengono convertiti sul disco. Per rendere sicuro un eventuale downgrade, Ollama conserva sia il file nuovo sia quello vecchio.

Perché lo spazio su disco raddoppia

Il backup non è un dettaglio. Un modello da 13 GB convertito diventa due file da circa 13 GB finché il backup resta lì. Non è un'ipotesi: è quello che un utente ha visto nella issue #18870, aperta l'8 ottobre, dove ollama list mostrava due righe da 13 GB per lo stesso modello più una terza voce con prefisso llamacpp:.

La 0.40.2 nasconde quei doppioni dalla lista. Lo spazio occupato però resta: la lista è più pulita, il disco no. Le note dicono che una versione futura cancellerà i backup da sola, senza indicare quando. Al 21 ottobre, con la 0.40.7, non è ancora successo.

Su un laptop con tre o quattro modelli medi la differenza si nota. Su un server con una libreria grande, o su una macchina con un SSD già pieno, può fermare il download del modello successivo.

Come togliere i backup

Le note di rilascio propongono questo script, che richiede jq:

curl -s localhost:11434/api/tags | jq -r '.models[].name' | while read -r m; do
  curl -s localhost:11434/api/show -d "{\"model\":\"$m\"}" | jq -r \
    'select(any(.manifests[]?; .runner == "llamacpp")) | .manifests[] | select(.runner == "ggml") | .digest'
done | sort -u | xargs -n1 ollama rm

Lo script interroga l'API locale. Per ogni modello che ha già la versione convertita, prende l'identificativo della copia vecchia e la rimuove. Cancella solo i backup, non i modelli che usi.

C'è un costo da conoscere prima di lanciarlo. Se dopo torni a una versione di Ollama precedente alla 0.40, quei modelli vanno riscaricati. Quindi l'ordine giusto è: aggiorni, usi i modelli per qualche giorno, e solo quando sei sicuro di restare sulla 0.40 togli i backup.

Il caso da guardare con attenzione: lo storage condiviso

La issue #18870 fa anche una domanda che le note non chiariscono: cosa succede se più server Ollama di versioni diverse usano la stessa cartella dei modelli?

Succede più spesso di quanto sembri. Un volume Docker montato da due container, una cartella di rete condivisa tra due macchine, una variabile OLLAMA_MODELS che punta allo stesso disco da due installazioni. La FAQ di Ollama spiega come spostare i modelli con OLLAMA_MODELS, ma non parla di versioni miste.

Dalla pull request sappiamo solo che Ollama crea un manifest di appoggio per evitare che un server più vecchio cancelli i file nuovi. Non c'è una garanzia scritta per l'uso misto. Finché non arriva, la scelta prudente è allineare tutte le installazioni che leggono la stessa cartella alla stessa versione.

Su Mac: MLX diventa il default

Se lavori su Apple Silicon, la 0.40.0 ha cambiato anche il motore. Le note della 0.40.0 dicono che le architetture supportate da MLX girano su MLX in automatico. Tra i modelli citati ci sono qwen3.8, gemma4, qwen3.6 e qwen3.5, più un modello di embedding, embeddinggemma-2.

Le note non danno numeri sulle prestazioni, e io non ne do. Se hai un benchmark tuo, rifallo dopo l'aggiornamento con gli stessi prompt: è l'unico confronto che vale per la tua macchina.

Cosa conviene fare adesso

• Prima di aggiornare, guarda quanto pesano i modelli che usi davvero con ollama list e controlla lo spazio libero. Se resti sulla 0.40.2, o quando la conversione tornerà, considera il doppio per ogni modello che avvierai. Dalla 0.40.3 in poi lo spazio doppio riguarda solo i modelli già convertiti.
• Se usi Docker, fissa la versione nell'immagine (per esempio ollama/ollama:0.40.7, l'ultima al 21 ottobre) invece di latest, così l'aggiornamento lo decidi tu e non il prossimo pull.
• Se più installazioni condividono la cartella dei modelli, aggiornale insieme.
• Tieni i backup per qualche giorno. Quando sei sicuro di restare sulla 0.40, lancia lo script e recupera lo spazio.
• Se il tuo codice parla con Ollama tramite l'API OpenAI-compatibile in locale, rifai un giro dei test dopo la conversione: il modello è lo stesso, il file sotto no.

Se stai ancora decidendo se far girare i modelli in locale, il punto di partenza è la puntata 1 della guida.