Ollama pull oder run: Unterschiede und Speicherort

ollama pull im Vergleich zu ollama run

ollama pull lädt ein Modell herunter und beendet sich. ollama run lädt das Modell nur herunter, wenn es fehlt, lädt es anschließend in den Arbeitsspeicher und öffnet einen interaktiven Chat. Der Download ist identisch, und die Dateien werden am selben Ort gespeichert. Nur run läuft danach weiter.

Dieser eine Unterschied entscheidet, welcher Befehl in ein Skript und welcher an die Tastatur gehört.

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

Die erste Zeile ruft das Modell ab und beendet sich. Daher eignet sie sich für die Bereitstellung und für eine systemd-Unit. Die zweite öffnet eine Chatsitzung. Geben Sie /bye ein oder drücken Sie Ctrl+D, um sie zu beenden. Die dritte sendet einen einzelnen Prompt, gibt die Antwort aus und beendet sich. Das ist die Form, die ein Skript benötigt, wenn es eine Antwort statt einer Sitzung braucht. Modellnamen ändern sich schnell. Behandeln Sie gemma4 hier daher als Platzhalter: Es ist das Beispiel, das die offizielle Ollama-Dokumentation im August 2026 verwendet. Jedes Tag aus der Bibliothek verhält sich genauso.

Warum der erste ollama-Aufruf wie eingefroren wirkt

Ein erster run auf einem frischen VPS kann mehrere Minuten ohne Ausgabe bleiben. Es ist nichts defekt. Die Chat-Eingabe kann erst erscheinen, wenn das Modell auf der Festplatte liegt und in den Arbeitsspeicher geladen wurde. Daher führt run zunächst einen Download von mehreren Gigabyte durch, bevor überhaupt eine Ausgabe erscheint.

Zwei Dinge machen diesen Vorgang unsichtbar. Ollama zeigt den Fortschrittsbalken nur an, wenn seine Ausgabe an ein Terminal geht. Daher gibt ein run in einem Shell-Skript, einem Cronjob, einem CI-Schritt oder einer einfachen ssh host ollama run ... während des Downloads überhaupt nichts aus. Nachdem die Daten übertragen wurden, muss die Datei außerdem noch von der Festplatte in den Arbeitsspeicher gelesen werden, bevor das erste Token erscheint. Auf einem kleinen VPS dauert dieser Lesevorgang lange. Wenn der Server nicht über genügend Arbeitsspeicher für das Modell verfügt, beginnt der Kernel mit dem Auslagern, und die Wartezeit verlängert sich deutlich.

Überwachen Sie den Vorgang in einer zweiten Sitzung, statt zu raten:

df -h /
watch -n5 df -h /

Wenn der freie Speicher schrittweise abnimmt, läuft der Download noch. Wenn der freie Speicher nicht weiter abnimmt, während der Befehl weiterhin aktiv ist, wurde der Download abgeschlossen und das Laden in den Arbeitsspeicher hat begonnen.

Das spricht dafür, das Modell im Voraus herunterzuladen. Die Person, die ollama run eingibt, sollte niemals für den Download warten müssen.

Modell abrufen, bevor es angefordert wird

Rufen Sie das Modell auf einem neuen System mit demselben Skript ab, das auch den Server installiert:

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

Wenn Sie den Server zum ersten Mal einrichten, behandelt die vollständige Installation von Ollama auf einem VPS den Dienst selbst und die Frage, wer darauf zugreifen darf. Danach sollten Sie einen Abruf einrichten, der unabhängig von Ihrem Terminal weiterläuft. Ein Download, der nach der Hälfte abgebrochen wird, führt sonst leicht zu einem nur teilweise befüllten Modellspeicher.

Führen Sie den Abruf innerhalb von tmux aus oder übergeben Sie ihn systemd als One-Shot-Unit, die beim Booten ausgeführt wird. Schreiben Sie /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

Beide Befehle verwenden absichtlich /bin/sh -c. Ein direkt aufgerufenes ExecStart= benötigt einen absoluten Pfad. Außerdem installiert das Installationsprogramm die Binärdatei nicht immer im selben Verzeichnis. Daher ist command -v ollama auf Ihrem eigenen System die einzige zuverlässige Auskunft. Die Ausführung über die Shell verwendet den PATH des Dienstes und nicht einen aus einer Anleitung kopierten Pfad. Auch das erste ExecStart ist wichtig: After=ollama.service bedeutet, dass die Server-Unit gestartet wurde. Das bedeutet nicht, dass der Dienst bereits bereit ist. Die Schleife wartet deshalb, bis ollama list antwortet, bevor der Abruf beginnt.

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

Das Journal sollte anzeigen, dass der Abruf ohne Fehler abgeschlossen wurde. Anschließend sollte ollama list das Modell anzeigen. Damit ein veränderliches Tag aktuell bleibt, fügen Sie einen systemd-Timer oder einen wöchentlichen cron-Eintrag hinzu, der denselben Abruf ausführt. Wird ein verschobenes Tag erneut abgerufen, werden die neuen Layer heruntergeladen. Die alten Layer bleiben ohne Verweise zurück und werden beim nächsten Start des Servers bereinigt.

Was passiert, wenn ein Pull unterbrochen wird

Jede Ebene eines Modells wird unter einem Hash ihres eigenen Inhalts gespeichert. Ein unterbrochener Pull ist daher keine vergeudete Arbeit: Führen Sie denselben ollama pull erneut aus. Bereits fertiggestellte Ebenen werden erkannt und übersprungen. Der Download wird mit der unterbrochenen Ebene fortgesetzt.

Eine Aktion zerstört diesen Fortschritt. Beim Start des Ollama-Servers werden gespeicherte Ebenen entfernt, auf die kein Modellmanifest verweist. Eine unvollständige Ebene eines abgebrochenen Pulls ist genau eine solche Ebene. Wenn Sie den Dienst vor dem nächsten Versuch neu starten, geht der bereits heruntergeladene Teil verloren. Wiederholen Sie den Pull zuerst und starten Sie den Dienst erst danach neu. Wenn ein unvollständiger Download einen Neustart tatsächlich überstehen muss, setzen Sie OLLAMA_NOPRUNE=1 in der Dienstumgebung. Entfernen Sie die Einstellung anschließend wieder. Diese Bereinigung beim Start verhindert, dass verwaiste Ebenen den Speicherplatz auf der Festplatte belegen.

Wenn der Pull mit no space left on device abgebrochen wurde, geben Sie vor dem nächsten Versuch Speicherplatz frei. Wenn df eine volle Festplatte meldet und du im Modellverzeichnis den belegten Speicherplatz nicht erklärt, wurde der Speicherplatz an anderer Stelle belegt. Lesen Sie die Gründe für unterschiedliche Ergebnisse von df und du, bevor Sie etwas löschen.

Wo speichert Ollama Modelle auf einem VPS?

Fragen Sie Ihr eigenes System, statt einem Pfad aus irgendeiner Anleitung zu vertrauen, auch nicht dieser. Der Speicherort unterscheidet sich zwischen einer Paketinstallation und einem Container. Er ändert sich außerdem, wenn jemand OLLAMA_MODELS gesetzt hat.

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

systemctl cat gibt die Unit-Datei zusammen mit allen Drop-in-Dateien aus. Dadurch wird auch eine von Ihnen gesetzte oder bereits in das Image integrierte OLLAMA_MODELS-Zeile angezeigt. Ohne eine solche Zeile liegt der Speicher unter dem Home-Verzeichnis des Kontos, unter dem der Dienst ausgeführt wird. getent passwd gibt dieses Home-Verzeichnis im sechsten durch Doppelpunkte getrennten Feld aus. find durchsucht ein Dateisystem nach dem Verzeichnis blobs. Dort werden die Layer tatsächlich gespeichert. Lassen Sie -xdev weg, wenn sich die Modelle bereits auf einem separaten Mount befinden können.

Messen Sie nun nach und lesen Sie Ihre eigenen Werte:

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

Der Speicher besteht aus zwei Teilen. manifests enthält eine kleine Datei für jedes Modell-Tag. Diese Datei listet die Layer auf, aus denen das Tag besteht. blobs enthält die Layer selbst. Jeder Layer ist nach dem Hash seines Inhalts benannt. Fast die gesamte Größe entfällt auf diesen Bereich. Da Layer von mehreren Tags gemeinsam verwendet werden, weist jedes von denselben Gewichten erstellte Modell in ollama list seine eigene Größe aus. Auf der Festplatte wird dieser Speicherplatz jedoch nur einmal belegt. Deshalb können sich die ausgewiesenen Größen auf mehr summieren, als du für das Verzeichnis meldet.

Modelldateien füllen das Root-Dateisystem eines kleinen VPS schneller als fast alles andere, was Sie wahrscheinlich installieren. Der größte Einfluss auf ihre Größe ist das Gewichtsformat. Die Wahl zwischen q4, q8 und fp16 kann pro Modell mehrere Gigabyte ausmachen.

Modelle mit OLLAMA_MODELS auf ein Datenvolume verschieben

Wenn ein zweites Laufwerk oder ein größeres Datenvolume vorgesehen ist, verschieben Sie den Speicherort, bevor das Root-Dateisystem voll läuft. Stoppen Sie den Server zuerst. Dadurch kopieren Sie keine Datei, in die noch geschrieben wird.

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 öffnet einen Editor für eine Drop-in-Datei. Dadurch bleibt die mitgelieferte Unit unverändert, und ein Paket-Upgrade kann Ihre Änderung nicht überschreiben. Fügen Sie diese beiden Zeilen hinzu:

[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 sollte Ihren neuen Pfad ausgeben. ollama list sollte dieselben Modelle anzeigen wie vor dem Verschieben. Eine leere Liste bedeutet, dass der Server das neue Verzeichnis nicht lesen kann. Der Dienst läuft als Benutzer ollama. Dieser Benutzer benötigt Lese- und Schreibzugriff auf das Zielverzeichnis. Dafür ist die darüberstehende Zeile chown zuständig. Prüfen Sie journalctl -e -u ollama auf Berechtigungsfehler, in denen der neue Pfad genannt wird. Löschen Sie die alte Kopie erst, wenn die Liste korrekt ist. Ein fehlgeschlagenes Verschieben mit anschließend gelöschter Quelle würde bedeuten, dass Sie alle Modelle erneut herunterladen müssen.

Die andere Möglichkeit behält den ursprünglichen Pfad bei und bindet das Datenvolume dort ein:

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 /

Wenn findmnt den Mount ausgibt, ist der Bind-Mount aktiv. Ein Bind-Mount ist hilfreich, wenn eine andere Komponente auf dem Server bereits den Standardpfad erwartet. Dabei gibt es eine wichtige Einschränkung: Die kopierten Dateien liegen unter dem Mount-Punkt weiterhin auf dem Root-Datenträger. Der Mount verdeckt sie. Der Speicherplatz wird daher erst wieder freigegeben, wenn Sie den Mount aushängen und die Dateien entfernen. Die Umgebungsvariable ist die leichter verständliche der beiden Varianten für die nächste Person, die sich anmeldet.

Wo der Container die Modelle stattdessen speichert

Das offizielle Image speichert Modelle in dem Verzeichnis, das Sie einbinden, nicht in einem Host-Verzeichnis des Benutzers ollama. Der dokumentierte Startbefehl lautet:

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

ollama vor dem Doppelpunkt ist ein benanntes Docker-Volume, und /root/.ollama ist der Pfad, in den der Server im Container schreibt. Daher findet du unter den Pfaden aus dem vorherigen Abschnitt nichts, weil dort keine Modelle liegen. Geben Sie den tatsächlichen Speicherort und dessen Größe aus:

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

Lesen Sie das Feld Mountpoint aus docker volume inspect aus und führen Sie anschließend sudo du -sh damit aus. Um die Modelle auf einem Daten-Volume zu speichern, ersetzen Sie das benannte Volume durch ein Host-Verzeichnis (-v /mnt/data/ollama:/root/.ollama) und erstellen Sie den Container neu. Der Container schreibt als root, daher gehört dieses Host-Verzeichnis anschließend root. Unter rootless Podman werden die IDs stattdessen in den Subuid-Bereich Ihres Benutzers abgebildet. Dadurch sieht der Besitzer auf dem Host erneut anders aus: Ollama unter rootless Podman ausführen behandelt diese Zuordnung.

Beachten Sie die folgende Warnung zur Bereinigung. docker volume prune entfernt jedes Volume, auf das kein Container verweist. Wenn Sie den ollama-Container ohne sein Volume entfernen oder neu erstellen, löscht ein späteres Prune alle heruntergeladenen Modelle. Sie können sie dann nur erneut herunterladen. Lesen Sie wie Sie die Docker-Datenträgernutzung auf einem VPS bereinigen, bevor Sie Prune auf einem System ausführen, auf dem Modelle gespeichert sind.

Ein Modell mit ollama rm entfernen, nicht mit rm

ollama list
ollama rm gemma4
ollama list
df -h /

`ollama rm löscht das Manifest für diesen Tag. Anschließend werden die Layer gelöscht, auf die kein verbleibendes Manifest mehr verweist. Der Speicherplatz wird freigegeben, sobald diese Dateien entlinkt sind. Daher verschiebt sich df sofort. Da Layer gemeinsam genutzt werden, kann das Entfernen eines von zwei eng verwandten Tags deutlich weniger Speicherplatz freigeben als die Größe, die neben ollama list` angezeigt wird. Das ist korrektes Verhalten und kein fehlgeschlagener Löschvorgang.

Das manuelle Löschen von Dateien beschädigt dieses Paar. Wenn Sie einen Blob mit `rm entfernen, führt das Manifest ihn weiterhin auf. Daher zeigt ollama list das Modell weiterhin an. Jeder Verwendungsversuch schlägt fehl, sobald die fehlende Schicht gelesen wird. Wenn Sie ein Manifest manuell entfernen, bleiben seine Layer ohne Verweise auf der Festplatte und belegen Speicherplatz, den kein Ollama-Befehl anzeigt. Falls Sie das bereits getan haben, entfernt ollama rm` beim betreffenden Tag den übrig gebliebenen Eintrag. Ein Neustart des Servers entfernt außerdem Layer, auf die nichts mehr verweist.

Eine letzte Unterscheidung ist wichtig, da beides häufig verwechselt wird. `ollama rm betrifft den Speicherplatz auf der Festplatte. ollama stop gemma4` entfernt ein Modell aus dem Arbeitsspeicher, gibt aber keinen Festplattenspeicher frei. Wie lange ein Modell nach abgeschlossenem Download im RAM verbleibt, ist eine separate Einstellung. Das Beibehalten eines geladenen Modells statt des erneuten Ladens bei jeder Anfrage behandelt dieses Thema.

FAQ

Was ist der Unterschied zwischen ollama pull und ollama run?

ollama pull lädt ein Modell auf die Festplatte und beendet sich. ollama run prüft, ob das Modell bereits auf der Festplatte vorhanden ist, lädt es andernfalls herunter, lädt es in den Arbeitsspeicher und öffnet anschließend eine interaktive Chat-Sitzung. Beide Befehle schreiben dieselben Dateien in dasselbe Verzeichnis. Verwenden Sie pull bei der Bereitstellung und in Skripten. Verwenden Sie run, wenn eine Person an der Tastatur arbeitet. ollama run <model> "your prompt" sendet einen einzelnen Prompt und beendet sich. Das ist die für Skripte geeignete Form von run.

Warum scheint mein erster ollama run zu hängen?

Das Modell wird heruntergeladen. Der Chat-Prompt kann erst angezeigt werden, wenn das Modell auf der Festplatte liegt und in den Arbeitsspeicher geladen wurde. Ein Modell ist mehrere Gigabyte groß. Ollama zeigt den Fortschrittsbalken nur an, wenn die Ausgabe an ein Terminal geht. Daher zeigt ein run innerhalb eines Skripts, eines Cron-Jobs oder eines ssh host ollama run ... während der Verarbeitung überhaupt nichts an. Öffnen Sie eine zweite Sitzung und führen Sie watch -n5 df -h / aus. Wenn der freie Speicher schrittweise abnimmt, läuft der Download. Laden Sie das Modell vorher herunter. Dann entfällt die Wartezeit.

Wo speichert Ollama seine Modelle?

Der Speicherort hängt von der Installation ab. Geben Sie ihn daher aus, statt ihn anzunehmen. Führen Sie systemctl cat ollama.service aus, um zu prüfen, ob OLLAMA_MODELS in der Unit oder einem Drop-in gesetzt ist. Falls nicht, liegt der Speicher unter dem Home-Verzeichnis des Kontos, unter dem der Dienst ausgeführt wird. getent passwd ollama gibt dieses Verzeichnis aus. sudo find / -xdev -type d -name blobs 2>/dev/null ermittelt das Layer-Verzeichnis direkt. Beim Container-Image liegt der Speicher im eingebundenen Volume. docker volume inspect ollama gibt dessen Host-Mountpoint aus.

Wie verschiebe ich Ollama-Modelle auf eine andere Festplatte?

Stoppen Sie den Dienst. Kopieren Sie den Speicher mit rsync -a an den neuen Speicherort. Übertragen Sie das Verzeichnis mit sudo chown -R ollama:ollama <directory> auf das Dienstkonto. Führen Sie anschließend sudo systemctl edit ollama.service aus und fügen Sie unter einer [Service]-Zeile Environment="OLLAMA_MODELS=<directory>" hinzu. Laden Sie die Konfiguration mit sudo systemctl daemon-reload neu und starten Sie den Dienst neu. Prüfen Sie das Ergebnis mit systemctl show ollama --property=Environment und ollama list. Eine leere Liste bedeutet fast immer, dass der ollama-Benutzer das neue Verzeichnis nicht lesen kann. journalctl -e -u ollama gibt den Pfad aus.

Gibt das Löschen der Modelldateien den Speicherplatz frei?

Das manuelle Löschen von Dateien gibt zwar Speicherplatz frei, hinterlässt den Speicher jedoch in einem inkonsistenten Zustand. Wenn Sie einen Blob löschen, führt das Manifest das Modell weiterhin auf. Es erscheint daher weiterhin in ollama list und schlägt bei der Verwendung fehl. Wenn Sie ein Manifest löschen, bleiben seine Layer auf der Festplatte. Es gibt dann keine Verweise mehr auf diese Layer. Verwenden Sie ollama rm <model>. Der Befehl löscht das Manifest und anschließend die Layer, die kein anderes Modell benötigt. Wenn Dateien bereits manuell gelöscht wurden, führen Sie ollama rm für das Tag aus, um den Eintrag zu entfernen. Starten Sie danach den Server neu. Dabei werden Layer entfernt, auf die kein Manifest verweist.