Ollama-Modelle verwalten: aktualisieren, aufräumen, Speicher sparen

Eine Ollama-Installation wächst unauffällig: Jeder ollama run lädt bei Bedarf ein weiteres Modell, alte Tags bleiben liegen, und irgendwann meldet das Root-Dateisystem keinen freien Speicher mehr. Ein 8B-Modell in Q4_K_M belegt rund 4,7 GB, dieselbe Modellfamilie in F16 rund 16 GB. Dieses Tutorial zeigt, wie du Modelle gezielt aktualisierst, ungenutzte Layer entfernst und das Modellverzeichnis auf ein eigenes Volume legst.

Wo speichert Ollama seine Modelle?

Ollama speichert Modelle unter /usr/share/ollama/.ollama/models, wenn der Dienst per systemd unter dem Benutzer ollama läuft, und unter ~/.ollama/models, wenn du den Server als angemeldeter Benutzer selbst startest.

Innerhalb dieses Verzeichnisses gibt es zwei Ebenen:

Ein Blob kann von mehreren Tags referenziert werden. Deshalb ist die Summe der SIZE-Spalte aus ollama list in der Regel größer als der tatsächliche Verbrauch auf der Platte. Verlass dich für die Kapazitätsplanung immer auf du, nicht auf die Ausgabe von ollama list.

Voraussetzungen

• Ein Linux-Host mit installiertem Ollama (Version 0.5.0 oder neuer), zum Beispiel eine skalierbare Linux-VM mit dedizierter CPU
• Ein Benutzerkonto mit sudo-Rechten
• Mindestens 20 GB freier Speicher, wenn du mit mehreren 7B- bis 8B-Modellen arbeitest
• curl, awk und rsync auf dem Host

Prüfe zuerst die installierte Version, weil sich Befehle wie ollama stop und ollama ps erst in neueren Releases finden:

$ ollama -v
ollama version is 0.5.7

Installierte Modelle inventarisieren

Verschaffe dir einen Überblick, bevor du etwas löschst. ollama list zeigt alle lokalen Tags mit ihrer Modell-ID, ollama ps zeigt die aktuell in den Speicher geladenen Modelle:

$ ollama list
NAME                ID              SIZE      MODIFIED
llama3.1:8b         46e0c10c039e    4.9 GB    3 weeks ago
mistral:7b          f974a74358d6    4.1 GB    2 months ago
nomic-embed-text    0a109f422b47    274 MB    2 months ago
$ ollama ps
NAME           ID              SIZE      PROCESSOR    UNTIL
llama3.1:8b    46e0c10c039e    6.7 GB    100% GPU     4 minutes from now

Den realen Plattenverbrauch liest du direkt am Verzeichnis ab. Die größten Blobs findest du mit einer sortierten Auflistung:

$ sudo du -sh /usr/share/ollama/.ollama/models
9.4G    /usr/share/ollama/.ollama/models
$ sudo ls -lhS /usr/share/ollama/.ollama/models/blobs | head -5

Die Spalte MODIFIED aus ollama list ist der beste Indikator dafür, welche Modelle du seit Wochen nicht mehr angefasst hast.

Wie aktualisiere ich ein Ollama-Modell?

Ein Ollama-Modell aktualisierst du mit ollama pull <name>:<tag>. Der Befehl gleicht das Manifest mit der Registry ab und lädt nur die Layer nach, die sich geändert haben, statt das komplette Modell erneut zu übertragen.

$ ollama pull llama3.1:8b
pulling manifest
pulling 667b0c1932bc: 100%  4.9 GB
verifying sha256 digest
writing manifest
success

Ob sich tatsächlich etwas geändert hat, erkennst du an der Modell-ID. Notiere sie vor dem Pull und vergleiche sie danach:

$ ollama list | grep llama3.1
llama3.1:8b    46e0c10c039e    4.9 GB    3 weeks ago

Bleibt die ID gleich, war der Pull ein reiner Integritätscheck. Ändert sich die ID, hat der Anbieter den Tag neu veröffentlicht und der alte Blob wird entfernt, sofern ihn kein anderes Modell referenziert.

Wichtig ist die Unterscheidung der Tags: Bewegliche Tags wie :latest oder :8b zeigen auf wechselnde Builds. Fest quantisierte Tags wie llama3.1:8b-instruct-q4_K_M ändern sich nur selten. Für reproduzierbare Deployments nimmst du den vollständigen Tag, für Experimente reicht :latest.

Alle Modelle in einem Durchlauf aktualisieren

Ollama bringt keinen Sammelbefehl für Updates mit. Die Modellnamen aus ollama list lassen sich aber direkt weiterreichen:

$ ollama list | awk 'NR>1 {print $1}' | xargs -n1 ollama pull

ollama pull ist ein Client-Befehl und spricht die API unter 127.0.0.1:11434 an. Der Download landet deshalb immer im Verzeichnis des laufenden Dienstes, unabhängig davon, welcher Benutzer den Befehl absetzt.

Für einen regelmäßigen Lauf legst du einen Cron-Eintrag an. Plane das Update in ein Zeitfenster mit geringer Last, weil ein Pull mehrere Gigabyte Traffic erzeugt:

0 4 * * 0 /usr/local/bin/ollama list | awk 'NR>1 {print $1}' | xargs -n1 /usr/local/bin/ollama pull >> /var/log/ollama-update.log 2>&1

Ollama selbst aktualisieren

Die Server-Binary aktualisierst du unter Linux über dasselbe Installationsskript wie bei der Erstinstallation. Es ersetzt die Binary unter /usr/local/bin/ollama und startet den systemd-Dienst neu. Die Modelle unter OLLAMA_MODELS bleiben dabei unangetastet:

$ curl -fsSL https://ollama.com/install.sh | sh
$ sudo systemctl restart ollama
$ ollama -v

Entscheidungspfad: Update oder Löschen

Der folgende Ablauf beschreibt, wie du pro Modell entscheidest:

graph TD
    A["ollama list auswerten"] --> B{"Modell zuletzt genutzt?"}
    B -- "nein" --> C["ollama rm ausführen"]
    B -- "ja" --> D{"Tag beweglich, z. B. latest?"}
    D -- "ja" --> E["ollama pull ausführen"]
    D -- "nein" --> F["Version bleibt fixiert"]
    E --> G{"Modell-ID geändert?"}
    G -- "ja" --> H["Kurztest mit ollama run"]
    G -- "nein" --> I["Kein Update nötig"]
    C --> J["Belegung mit du -sh prüfen"]

Ungenutzte Modelle entfernen

Mit ollama rm löschst du das Manifest eines Tags und alle Blobs, die danach von keinem anderen Modell mehr referenziert werden. Mehrere Modelle kannst du in einem Aufruf angeben:

$ ollama rm mistral:7b
deleted 'mistral:7b'
$ ollama rm gemma2:2b qwen2.5:1.5b

Löschst du ein Modell, das gerade geladen ist, entlädt Ollama es zuerst aus dem Speicher. Ein Blick auf ollama ps vor dem Löschen verhindert trotzdem, dass du eine laufende Anwendung unterbrichst.

Lösche niemals Dateien direkt aus blobs/. Das Manifest zeigt danach auf einen fehlenden Layer und jeder Aufruf des Modells scheitert mit einer Digest-Fehlermeldung. Der einzige saubere Weg zurück ist ein erneutes ollama pull desselben Tags.

Warum belegt Ollama nach dem Löschen weiterhin Speicher?

Ollama belegt nach einem ollama rm weiterhin Speicher, wenn abgebrochene Downloads als sha256-...-partial-Dateien im Verzeichnis blobs/ zurückbleiben oder ein anderer lokaler Tag genau dieselben Layer referenziert.

Angebrochene Downloads findest du so:

$ sudo find /usr/share/ollama/.ollama/models/blobs -name '*-partial*' -exec ls -lh {} +

Ein erneuter ollama pull desselben Modells setzt den Download an dieser Stelle fort. Brauchst du das Modell nicht mehr, kannst du die -partial-Dateien gefahrlos löschen, weil sie von keinem Manifest referenziert werden. Stoppe den Dienst vorher, damit kein laufender Download betroffen ist.

Speicher sparen: passende Quantisierung wählen

Der größte Hebel beim Speicherverbrauch ist die Quantisierung, nicht die Anzahl der Modelle. Die folgenden Richtwerte gelten für ein Modell mit 8 Milliarden Parametern:

Welche Quantisierung ein lokales Modell nutzt, zeigt ollama show:

$ ollama show llama3.1:8b
  Model
    architecture        llama
    parameters          8.0B
    quantization        Q4_K_M
    context length      131072

Wenn du ein Modell in mehreren Quantisierungen vorhältst, um sie zu vergleichen, entferne die Verlierer nach dem Test wieder. Zwei Varianten desselben 8B-Modells teilen sich keine Gewichts-Blobs.

RAM und VRAM wieder freigeben

Geladene Modelle belegen Arbeitsspeicher beziehungsweise VRAM, auch wenn gerade keine Anfrage läuft. Standardmäßig hält Ollama ein Modell nach der letzten Anfrage fünf Minuten im Speicher. Mit ollama stop gibst du den Speicher sofort frei:

$ ollama stop llama3.1:8b
$ ollama ps
NAME    ID    SIZE    PROCESSOR    UNTIL

Die Haltedauer steuerst du global über die Umgebungsvariable OLLAMA_KEEP_ALIVE. Der Wert 0 entlädt sofort nach jeder Antwort, -1 hält das Modell dauerhaft geladen:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Auf reinen CPU-Hosts ist ein langes Keep-alive fast immer sinnvoll, weil das Laden eines 8B-Modells von der Platte je nach I/O mehrere Sekunden dauert. Wenn die Latenz auch danach nicht reicht, gehören solche Workloads auf GPU-Instanzen für LLM-Inference, wo das komplette Modell im VRAM liegt.

Modellverzeichnis auf ein eigenes Volume verschieben

Modelle gehören nicht auf die Systempartition. Verschiebe das Verzeichnis auf ein separates Volume, sobald du mehr als zwei Modelle dauerhaft vorhältst.

$ sudo systemctl stop ollama
$ sudo mkdir -p /data/ollama/models
$ sudo rsync -a /usr/share/ollama/.ollama/models/ /data/ollama/models/
$ sudo chown -R ollama:ollama /data/ollama

Anschließend setzt du OLLAMA_MODELS per systemd-Override. systemctl edit legt die Datei /etc/systemd/system/ollama.service.d/override.conf an:

$ sudo systemctl edit ollama.service

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

Danach neu laden und starten:

$ sudo systemctl daemon-reload
$ sudo systemctl start ollama

Erst wenn ollama list das gewohnte Ergebnis liefert, löschst du das alte Verzeichnis mit sudo rm -rf /usr/share/ollama/.ollama/models.

Verifikation

Drei Prüfungen bestätigen, dass Update und Umzug sauber durchgelaufen sind:

$ systemctl show ollama --property=Environment
Environment=OLLAMA_MODELS=/data/ollama/models
$ ollama list
$ du -sh /data/ollama/models
7.2G    /data/ollama/models

Ein Funktionstest schließt die Kette ab. Das Modell muss antworten, ohne vorher neu geladen zu werden:

$ ollama run llama3.1:8b "Antworte nur mit dem Wort OK."
OK

Troubleshooting

Error: model requires more system memory than is available: Das Modell passt nicht in RAM oder VRAM. Wechsle auf eine kleinere Quantisierung wie q4_K_M oder reduziere die Kontextlänge über den Parameter num_ctx.

ollama list ist nach dem Umzug leer: Der Dienst liest ein anderes Verzeichnis als erwartet. Prüfe mit systemctl show ollama --property=Environment, ob der Override aktiv ist, und kontrolliere mit sudo -u ollama ls /data/ollama/models, ob der Dienstbenutzer Lesezugriff hat.

Pull bricht mit max retries exceeded ab: Setze den Befehl einfach erneut ab. Ollama nimmt den Download an der Stelle der -partial-Datei wieder auf und lädt bereits übertragene Layer nicht noch einmal.

Speicher wird nach ollama rm nicht frei: Ein anderer Tag referenziert dieselben Blobs. Vergleiche die Modell-IDs in ollama list, identische IDs bedeuten identische Layer.

Fazit

Drei Befehle decken den Alltag ab: ollama list für den Bestand, ollama pull für Updates und ollama rm für das Aufräumen. Verlagere das Modellverzeichnis über OLLAMA_MODELS auf ein eigenes Volume, bevor die Systempartition volläuft, und prüfe den realen Verbrauch mit du -sh statt mit der SIZE-Spalte. Als nächster Schritt bietet sich ein wöchentlicher Cron-Lauf an, der Updates zieht und die Ausgabe protokolliert.

Weiterlesen

• Lokales Coding-Modell mit Ollama in der IDE nutzen
• Die Ollama-API aus eigenen Anwendungen ansprechen
• Ollama auf Ubuntu 24.04 installieren und als Dienst betreiben
• Ollama im Docker-Container betreiben
• Ollama im Netzwerk freigeben: Port, Bind-Adresse und Absicherung
• Ollama, LM Studio oder llama.cpp: Welches Werkzeug wofür?
• Ollama mit MCP-Servern verbinden: Werkzeuge für lokale Modelle
• Open WebUI als Oberfläche für Ollama einrichten
• Was ist Ollama? Funktionsweise, Modelle und Einsatzgebiete