Ollama pull oder run: Unterschiede und Modellpfad

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. Nur run läuft danach weiter.

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

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

Die erste Zeile lädt das Modell herunter 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. Dieses Format eignet sich für ein Skript, wenn es eine Antwort statt einer Sitzung benötigt. Auch bei diesem dritten Format bestimmt weiterhin ausschließlich das Modell die Länge der Antwort. Eine Frage in einer Zeile kann daher mit drei Absätzen beantwortet werden. Die Antwort mit num_predict begrenzen sorgt dafür, dass ein skriptbasiertes run innerhalb einer Größe bleibt, die der aufrufende Prozess tatsächlich verarbeiten kann. Modellnamen ändern sich schnell. Behandeln Sie gemma4 hier daher als Platzhalter. Zum Stand August 2026 ist dies das Beispiel aus der offiziellen Ollama-Dokumentation. Jedes Tag aus der Bibliothek verhält sich gleich. Wenn Sie stattdessen ein Modell verwenden möchten, das bereits auf einem realen Server dimensioniert wurde, nennt Nemotron 3.5 Lightning auf einem VPS ausführen das genaue abzurufende Tag und den dafür erforderlichen Arbeitsspeicher.

Warum der erste ollama-Aufruf wie eingefroren wirkt

Ein erster run auf einem frischen VPS kann mehrere Minuten ohne Ausgabe laufen. Das ist kein Fehler. Die Chat-Eingabe kann erst erscheinen, wenn das Modell auf dem Datenträger liegt und in den Arbeitsspeicher geladen wurde. run lädt daher zunächst mehrere Gigabyte herunter, bevor überhaupt eine Ausgabe möglich ist.

Dabei bleiben zwei Vorgänge unsichtbar. Ollama zeigt den Fortschrittsbalken nur an, wenn die Ausgabe an ein Terminal erfolgt. Ein run in einem Shell-Skript, einem Cron-Job, einem CI-Schritt oder einer einfachen ssh host ollama run ... gibt während des Downloads daher überhaupt nichts aus. Nachdem die Bytes übertragen wurden, muss die Datei außerdem vom Datenträger 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 in den Swap-Bereich. Dadurch verlängert sich die Wartezeit erheblich.

Prüfen Sie den Vorgang in einer zweiten Sitzung, statt nur zu warten:

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 noch aktiv ist, wurde der Download abgeschlossen und das Laden in den Arbeitsspeicher hat begonnen.

Das spricht dafür, das Modell vorab herunterzuladen. Wer ollama run eingibt, sollte nicht gleichzeitig für den Download warten müssen.

Modell abrufen, bevor es jemand anfordert

Dasselbe gilt für alles, was keine Person ist: Ein auf Ihren Ollama-Endpunkt gerichteter Coding-Agent gibt bei der ersten Anfrage normalerweise auf, statt den Download mehrerer Gigabyte abzuwarten. Rufen Sie das Modell auf einem neuen Server in demselben Skript ab, das den Server installiert:

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

Wenn Sie den Server zum ersten Mal einrichten, beschreibt die vollständige Installation von Ollama auf einem VPS den Dienst selbst und legt fest, wer darauf zugreifen darf. Richten Sie anschließend einen Pull ein, der unabhängig von Ihrem Terminal weiterläuft. Ein Download, der nach der Hälfte abgebrochen wird, führt häufig zu einem nur teilweise gefüllten Modellspeicher.

Führen Sie den Vorgang 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 laufen absichtlich über /bin/sh -c. Ein einfaches 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 Server die einzige zuverlässige Lösung. Durch die Shell wird der PATH des Dienstes verwendet und nicht ein aus einer Anleitung kopierter Pfad. Das erste ExecStart ist ebenfalls wichtig: After=ollama.service bedeutet, dass die Server-Unit gestartet wurde. Der Server ist dadurch noch nicht zwangsläufig bereit. Die Schleife wartet deshalb, bis ollama list antwortet, bevor der Pull beginnt.

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

Das Journal sollte anzeigen, dass der Pull 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 Pull ausführt. Beim erneuten Abrufen eines Tags, das auf eine neue Version zeigt, werden die neuen Layer heruntergeladen. Die alten Layer haben dann keine Verweise mehr und werden beim nächsten Start des Servers bereinigt.

Was bei einer unterbrochenen Pull-Operation passiert

Jede Modellsicht wird unter einem Hash ihres eigenen Inhalts gespeichert. Eine unterbrochene Pull-Operation ist daher keine vergeudete Arbeit: Führen Sie denselben ollama pull erneut aus. Bereits fertiggestellte Schichten werden erkannt und übersprungen. Der Download wird mit der unterbrochenen Schicht fortgesetzt.

Eine Aktion macht diesen Fortschritt zunichte. Beim Start des Ollama-Servers entfernt dieser gespeicherte Schichten, auf die kein Modellmanifest verweist. Eine unvollständige Schicht, die von einer abgebrochenen Pull-Operation zurückbleibt, ist genau eine solche Schicht. Wenn Sie den Dienst vor dem erneuten Versuch neu starten, wird der bereits heruntergeladene Teil gelöscht. Wiederholen Sie die Pull-Operation 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 sich verwaiste Schichten auf der Festplatte ansammeln.

Wenn die Pull-Operation mit no space left on device abgebrochen wurde, schaffen Sie vor dem erneuten Versuch freien Speicherplatz. Wenn df eine volle Festplatte meldet und du im Modellverzeichnis den belegten Speicher nicht erklärt, wurde der Speicherplatz an anderer Stelle belegt. Lesen Sie dann die Gründe für abweichende Angaben von df und du, bevor Sie etwas löschen.

Wo speichert Ollama Modelle auf einem VPS?

Fragen Sie Ihren eigenen Server, statt einem Pfad aus einer beliebigen 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-ins aus. Dadurch wird dort auch eine von Ihnen gesetzte oder 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 möglicherweise auf einem separaten Mount befinden.

Messen Sie jetzt 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 für jeden Modell-Tag eine kleine Datei. Diese Datei listet die Layer auf, aus denen der 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 Teil. Da Layer von mehreren Tags gemeinsam verwendet werden, weist ollama list für zwei Modelle mit denselben Gewichten jeweils deren eigene Größe aus, obwohl dieser Speicherplatz auf der Festplatte nur einmal belegt wird. Daher können sich die aufgeführten Größen zu 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. Auswahl zwischen q4, q8 und fp16 kann pro Modell mehrere Gigabyte ausmachen.

Modelle mit OLLAMA_MODELS in 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, damit Sie keine Datei kopieren, 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 Paketupgrade 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 sorgt die obige Zeile chown. Prüfen Sie journalctl -e -u ollama auf Berechtigungsfehler, die den neuen Pfad nennen. Löschen Sie die alte Kopie erst, wenn die Liste korrekt ist. Bei einem fehlgeschlagenen Verschieben und gelöschten Quelldateien müssten Sie sonst alles erneut herunterladen.

Die andere Option 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 Anwendung auf dem Server bereits den Standardpfad erwartet. Dabei gibt es eine wichtige Falle: Die kopierten Dateien liegen unter dem Mount-Punkt auf dem Root-Datenträger weiterhin dort, werden aber vom Mount verborgen. Der Speicherplatz wird erst freigegeben, wenn Sie das Dateisystem aushängen und die Dateien löschen. Die Umgebungsvariable lässt sich der nächsten Person, die sich anmeldet, leichter erklären.

Wo der Container die Modelle stattdessen speichert

Das offizielle Image speichert die 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 bezeichnet den Pfad, in den der Server im Container schreibt. Deshalb findet du unter den Pfaden aus dem vorherigen Abschnitt nichts: Dort befinden sich keine Modelle. Geben Sie den tatsächlichen Speicherort und seine 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. Wenn Sie die Modelle in einem Daten-Volume speichern möchten, 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 wiederum anders aus: Ollama unter rootless Podman ausführen beschreibt diese Abbildung.

Beachten Sie außerdem die 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 von Ihnen heruntergeladenen Modelle. Sie können sie dann nur durch erneutes Herunterladen wiederherstellen. Lesen Sie Docker-Festplattennutzung 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 und anschließend die Layer, auf die kein verbleibendes Manifest mehr verweist. Der Speicherplatz steht wieder zur Verfügung, sobald diese Dateien entkoppelt sind, daher wird df sofort ausgeführt. Da Layer gemeinsam genutzt werden, kann das Entfernen eines von zwei eng verwandten Tags deutlich weniger Speicherplatz freigeben als die Größe, die ollama list daneben anzeigt. Das ist korrektes Verhalten und kein fehlgeschlagenes Löschen.

Das manuelle Löschen von Dateien beschädigt dieses Zusammenspiel. Entfernen Sie einen Blob mit rm, enthält das Manifest weiterhin den Verweis darauf. Daher zeigt ollama list das Modell weiterhin an, und jeder Nutzungsversuch schlägt fehl, sobald die fehlende Layer gelesen wird. Entfernen Sie ein Manifest manuell, bleiben seine Layer ohne Verweise auf der Festplatte und belegen Speicherplatz, den kein Ollama-Befehl ausweist. Wenn Sie dies bereits getan haben, entfernt ollama rm am Tag den übrig gebliebenen Eintrag. Ein Neustart des Servers entfernt anschließend Layer, auf die nichts mehr verweist.

Zum Schluss eine wichtige Unterscheidung, da beides häufig verwechselt wird. ollama rm betrifft den Speicherplatz auf der Festplatte. ollama stop gemma4 entfernt ein Modell aus dem Arbeitsspeicher und gibt keinen Festplattenspeicher frei. Wie lange ein Modell nach Abschluss des Downloads im RAM verbleibt, ist eine separate Einstellung. Der Abschnitt Ein Modell geladen lassen, statt es bei jeder Anfrage erneut zu laden behandelt dieses Thema.

FAQ

Was ist der Unterschied zwischen ollama pull und ollama run?

ollama pull lädt ein Modell auf die Festplatte herunter und beendet sich. ollama run prüft, ob das Modell bereits auf der Festplatte liegt, lädt es andernfalls herunter, lädt es in den Arbeitsspeicher und öffnet anschließend eine interaktive Chatsitzung. Beide Befehle schreiben dieselben Dateien in dasselbe Verzeichnis. Verwenden Sie pull bei der Bereitstellung und in Skripten. Verwenden Sie run, wenn eine Person am Terminal arbeitet. ollama run <model> "your prompt" sendet einen Prompt und beendet sich. Das ist die skriptfähige Form von run.

Warum scheint mein erster ollama run zu hängen?

Das Modell wird heruntergeladen. Die Chat-Eingabeaufforderung kann erst erscheinen, 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. Ein run in einem Skript, einem Cronjob oder einem ssh host ollama run ... zeigt währenddessen daher ü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 im Voraus 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. Ist die Variable nicht gesetzt, liegt der Speicher im Home-Verzeichnis des Kontos, unter dem der Dienst ausgeführt wird. Dieses Verzeichnis gibt getent passwd ollama 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 Mountpoint auf dem Host 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. Weisen Sie das Verzeichnis mit sudo chown -R ollama:ollama <directory> dem Dienstkonto zu. Führen Sie anschließend sudo systemctl edit ollama.service aus und ergänzen Sie Environment="OLLAMA_MODELS=<directory>" unter einer [Service]-Zeile. 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 Benutzer ollama 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 die Bytes frei, hinterlässt den Speicher aber 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 ohne Referenz auf der Festplatte erhalten. Verwenden Sie ollama rm <model>. Dieser 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 den Tag aus, um den Eintrag zu entfernen. Starten Sie danach den Server neu. Er entfernt Layer, auf die kein Manifest verweist.