Ollama-Modell dauerhaft im Speicher halten

Warum entlädt Ollama das Modell nach einigen Minuten?

Ollama hält ein Modell nach der letzten Anfrage fünf Minuten im Speicher geladen und gibt es danach frei. Bei der nächsten Anfrage müssen die Gewichte erneut von der Festplatte gelesen und in den RAM oder VRAM eingebunden werden. Deshalb wartet die Anfrage, bevor das erste Token eintrifft. Eine Chat-Oberfläche oder ein Coding-Agent wirkt dadurch zunächst schnell, pausiert eine Weile und reagiert bei der nächsten Nachricht wieder langsam. Es ist nichts defekt. Der Leerlauf-Timer ist abgelaufen.

Der Timer heißt keep_alive. Er gilt pro Modell und startet nach jedem Abschluss einer Anfrage neu. Ein Modell, das gerade eine Anfrage beantwortet, wird nie entladen, weil der Server nur ein Modell ohne aktive Anfrage auslaufen lässt. Seit August 2026 beträgt der Standardwert fünf Minuten. Er gilt für jedes Modell, das dieser Server lädt.

keep_alive lässt sich an zwei Stellen festlegen: für die einzelne Anfrage oder als Standardwert des Servers. Mit einem systemd-Drop-in bleibt der Standardwert des Servers auch nach einem Neustart erhalten. In dieser Anleitung wird vorausgesetzt, dass Ollama bereits als Dienst läuft. Falls das nicht der Fall ist, beginnen Sie mit Ollama auf einem VPS installieren und kehren Sie anschließend hierher zurück.

Welche Modelle sind derzeit resident, und wann laufen sie ab?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Eine leere Ausgabe bedeutet, dass nichts geladen ist. Die nächste Anfrage muss das Modell dann vollständig laden. PROCESSOR zeigt, wohin die Gewichte geladen wurden. 100% GPU und 100% CPU sind die eindeutigen Fälle. Eine Aufteilung wie 25%/75% CPU/GPU bedeutet, dass das Modell nicht vollständig in den VRAM passte. Ein Teil läuft dann auf dem Prozessor, und die Generierung ist langsamer.

UNTIL ist der Countdown. Der Wert wird als relative Zeit ausgegeben, zum Beispiel 4 minutes from now. Forever wird ausgegeben, wenn das Modell mit einem negativen keep_alive geladen wurde. Während des kurzen Zeitraums, in dem der Server das Modell entlädt, wird Stopping... ausgegeben.

Die Spalten haben sich zwischen den Releases geändert. Lesen Sie daher die Kopfzeile, statt die Felder in einem Skript zu zählen. Für automatisierte Abläufe fragen Sie die API ab:

curl -s http://localhost:11434/api/ps

Jeder Eintrag enthält expires_at, einen absoluten Zeitstempel wie 2026-08-09T14:38:31.83753Z, sowie size_vram, den Anteil dieses Modells im GPU-Speicher. Ein size_vram von 0 bedeutet, dass das Modell auf der CPU ausgeführt wird.

Was der Reload tatsächlich kostet

Raten Sie nicht. Ollama gibt die Ladezeit in jeder Antwort als load_duration in Nanosekunden aus.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

Der erste Aufruf lädt das Modell. Daher ist der Wert für load_duration groß. Teilen Sie ihn durch 1000000000, um die Zeit in Sekunden abzulesen. Der zweite Aufruf läuft, während sich das Modell im Speicher befindet, und gibt einen deutlich kleineren Wert aus. Die Differenz zwischen diesen beiden Werten ist die Wartezeit, die nach Ablauf des Timers für jeden Benutzer anfällt. Genau deshalb sollten Sie keep_alive ändern. Der größte Teil dieser Differenz entfällt auf das Lesen von der Festplatte. Wenn Sie das Modellverzeichnis auf ein zweites Volume verschoben haben, bestimmt die Geschwindigkeit dieses Volumes die Mindestdauer jedes kalten Ladevorgangs. Informationen zur Generierungsgeschwindigkeit vor und nach dieser Pause finden Sie unter So messen Sie die Token-Geschwindigkeit auf Ihrem eigenen System.

Ein Ollama-Modell bei einer Anfrage im Speicher geladen halten

Senden Sie keep_alive mit der Anfrage. Die Einstellung gilt für dieses Modell, sobald die Anfrage abgeschlossen ist.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Es werden vier Wertformen akzeptiert:

• eine Dauerangabe: "30m", "24h", "90s"
• eine einfache Zahl, die als Sekunden interpretiert wird: 3600
• ein negativer Wert, -1 oder "-1m", der bedeutet, dass keine Leerlaufzeitüberschreitung gilt
• 0, das bedeutet, dass das Modell unmittelbar nach Abschluss dieser Anfrage entladen wird

Ein Wert in der Anfrage überschreibt den Serverstandard in beide Richtungen. Das ist wichtiger, als es zunächst klingt: Ein Client, der sein eigenes keep_alive sendet, hat Vorrang vor allen Einstellungen, die Sie auf dem Server konfiguriert haben.

Sie können ein Modell auch laden, ohne etwas zu generieren. Senden Sie nur den Modellnamen. Der Server lädt das Modell und gibt mit "done": true eine leere Antwort zurück.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Das ist der Befehl, den Sie nach einem Reboot oder nach dem Abrufen eines neuen Modells ausführen. Dadurch muss die erste echte Benutzeranfrage nicht für das Laden warten. Die CLI erledigt dasselbe mit einem Flag:

ollama run --keepalive 30m qwen3:8b "hello"

Standardmäßig mit OLLAMA_KEEP_ALIVE geladen halten

Der Server liest OLLAMA_KEEP_ALIVE beim Start ein und verwendet diesen Wert für jedes Modell, das keinen eigenen Wert enthält. Es gelten dieselben Formen wie für das Request-Feld. Daher funktionieren 30m, 3600 und -1.

Entscheidend ist jedoch, in welcher Umgebung die Variable gesetzt sein muss. export OLLAMA_KEEP_ALIVE=30m in Ihrer SSH-Sitzung auszuführen, bewirkt nichts, weil die Paketinstallation den Server als systemd-Dienst unter einem eigenen Benutzer und mit einer eigenen Umgebung startet. Ihre Login-Shell und dieser Dienst haben keine gemeinsame Umgebung. Dies ist der häufigste Grund dafür, dass die Einstellung scheinbar ignoriert wird.

Mit einem systemd-Drop-in einen Neustart überstehen

sudo systemctl edit ollama.service

Der Editor wird mit zwei Kommentar-Markierungen geöffnet. Schreiben Sie zwischen diese Markierungen: systemd verwirft alles, was Sie unterhalb der zweiten Markierung eingeben.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Beim Speichern wird /etc/systemd/system/ollama.service.d/override.conf geschrieben. Dabei handelt es sich um ein Drop-in und nicht um eine Änderung an der ausgelieferten Unit. Ein Ollama-Paketupgrade, das ollama.service ersetzt, lässt Ihre Einstellung daher unverändert. Wenn Drop-ins und Unit-Dateien für Sie neu sind, erklärt der Leitfaden zu systemd-Services und -Timern die Funktionsweise.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

Der letzte Befehl gibt die Umgebung aus, mit der der Dienst tatsächlich ausgeführt wird. Fehlt OLLAMA_KEEP_ALIVE=30m in dieser Ausgabe, wurde das Drop-in nicht übernommen. Ursache ist fast immer ein fehlender [Service]-Header oder eine Eingabe unterhalb der Markierung. Der Neustart entfernt alle geladenen Modelle. Die nächste Anfrage lädt das Modell daher zunächst vollständig. Führen Sie zum Aufwärmen den obigen Preload-Aufruf aus.

Was Sie der residente Modellbetrieb kostet

Die Spalte SIZE in ollama ps bezeichnet den Speicher, der während des gesamten Leerlaufzeitraums belegt bleibt, nicht nur während einer Anfrage. Ein 8B-Modell mit 4-Bit-Quantisierung benötigt etwa 5 bis 6 GB. Bei einem 27B-Modell gelten andere Voraussetzungen. Die Speicherberechnung für den Betrieb auf einer CPU-only-VPS sollten Sie daher durchgehen, bevor Sie sich entscheiden, ein Modell resident zu halten. Wenn Sie keep_alive auf -1 setzen, entscheiden Sie, dass das Modell dauerhaft Vorrang vor allem anderen auf dem Server hat. Auf einer kleinen VPS geht das direkt zulasten Ihrer Datenbank, Ihrer Webanwendung und Ihrer Build-Jobs.

Prüfen Sie die tatsächlichen Werte, statt einer Schätzung zu vertrauen. Führen Sie den folgenden Befehl aus, während ein Modell geladen ist, und anschließend noch einmal nach ollama stop:

free -h

Die Spalte available zeigt den Speicher, den der Kernel noch an einen neuen Prozess vergeben kann. Auf einem NVIDIA-GPU-Server zeigt nvidia-smi dasselbe für den VRAM. Wenn der Speicher ausgeht, beendet der Kernel einen Prozess, um Speicher freizugeben:

sudo dmesg -T | grep -i "out of memory"

Eine Zeile mit ollama bedeutet, dass der Modellserver beendet wurde. Eine Zeile mit Ihrer Datenbank bedeutet, dass das Modell Vorrang hatte und ein wichtiger Dienst verloren ging. Beide Ergebnisse beruhen auf derselben Entscheidung: einem langen Keep-alive-Zeitraum auf einem Server ohne Speicherreserve.

Zwei Kosten werden dabei leicht übersehen. Eine größere Context Length reserviert einen größeren KV-Cache (Key-Value-Cache, der Attention-Zustand pro Token, den das Modell während der Generierung speichert). Dieser Cache ist Bestandteil der residenten Größe. Seine Größe ergibt sich aus num_ctx. Wenn Sie das Context Window vergrößern, erhöht sich daher der Speicherbedarf des residenten Modells für den gesamten Leerlaufzeitraum, nicht nur während der Antwort. OLLAMA_NUM_PARALLEL über 1 reserviert diesen Cache einmal pro parallelem Slot. Wenn Sie mehrere Personen mit einem Modell bedienen möchten, dimensionieren Sie den Speicher für die Slots und nicht nur für die Gewichte.

Eine sinnvolle Standardeinstellung: Ein Modell auf einem Server mit ausreichender Speicherreserve kann -1 verwenden. Ein gemeinsam genutzter Server sollte ein Zeitfenster verwenden, das die Abstände zwischen Ihren Anfragen abdeckt, beispielsweise 30m. Dann wird der Speicher wieder freigegeben, sobald Sie nicht mehr arbeiten.

Modell sofort entladen

ollama stop qwen3:8b

Der Befehl wird ohne Ausgabe beendet, und das Modell verschwindet aus ollama ps. Für einen Namen, der nicht geladen ist, wird couldn't find model "qwen3:8b" to stop ausgegeben. Über die API senden Sie eine Anfrage ohne Prompt und setzen keep_alive auf 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

Die Antwort enthält "done_reason": "unload". Verwenden Sie diese Methode, anstatt den Dienst neu zu starten. systemctl restart ollama gibt den Speicher ebenfalls frei, entlädt jedoch jedes andere geladene Modell und beendet alle laufenden Anfragen.

Mehrere Modelle auf einem Server ausführen

OLLAMA_MAX_LOADED_MODELS begrenzt, wie viele Modelle gleichzeitig geladen bleiben. Seit August 2026 ist der Standardwert drei pro GPU oder drei auf einem System ohne GPU. Die Begrenzung zählt Modelle. Der tatsächliche Grenzwert ist jedoch der verfügbare Speicher. Deshalb kann ein zweites großes Modell bereits abgelehnt werden, bevor drei Modelle geladen sind.

Wenn ein neues Modell angefordert wird und nicht genügend Speicher dafür verfügbar ist, lädt der Scheduler eines der bereits geladenen Modelle aus dem Speicher, um Platz zu schaffen. Bevorzugt wird ein Modell ohne aktive Anfrage. Der Scheduler kann auch ein Modell entfernen, dessen Timer noch nicht abgelaufen ist, einschließlich eines mit -1 geladenen Modells. Ein negativer Wert für keep_alive bedeutet daher, dass kein Leerlauf-Timeout gilt. Er schützt die Gewichte nicht vor einer Anforderung für ein anderes Modell.

Diese Entscheidung wird auf der Debug-Ebene protokolliert. Fügen Sie derselben Drop-in-Datei eine zweite Environment="OLLAMA_DEBUG=1"-Zeile hinzu, starten Sie den Dienst neu und überwachen Sie das Protokoll:

sudo journalctl -u ollama -f

Eine Meldung, dass ein Runner entfernt wird, um Platz zu schaffen, direkt neben der auslösenden Anfrage, zeigt, dass diese beiden Modelle nicht gemeinsam auf dieses System passen. Verwenden Sie auf diesem System weniger Modelle oder wählen Sie für das Modell, das schnell antworten muss, ein langes Zeitfenster und für das Modell, das Sie selten aufrufen, 0.

Leitlinien, die über das nächste Release hinaus Bestand haben

Ollama veröffentlicht häufig neue Versionen, und die Standardwerte ändern sich. Prüfen Sie daher den vorliegenden Build, statt sich Zahlen zu merken:

ollama --version
ollama serve --help

ollama serve --help listet die Umgebungsvariablen auf, die dieser Build tatsächlich einliest, darunter OLLAMA_KEEP_ALIVE. Zwei Regeln galten über mehrere Releases hinweg und bilden eine verlässliche Grundlage. Ein Wert in der Anfrage hat Vorrang vor dem Serverstandard. Und ollama ps zeigt zuverlässig, was tatsächlich geladen ist, unabhängig davon, was eine Konfigurationsdatei vorgibt.

Wenn ein Editor oder ein Agent Ihren Server steuert, prüfen Sie, was dieser Client sendet, bevor Sie den Server verantwortlich machen. Einen Coding-Agent auf Ihren eigenen Ollama-Server richten behandelt, wo sich diese Anfrageeinstellungen befinden.

FAQ

Warum entlädt Ollama mein Modell nach 5 Minuten?

Fünf Minuten sind der Standardwert für keep_alive, den Ollama startet, sobald eine Anfrage abgeschlossen ist. Nach Ablauf gibt der Server die Gewichte frei. Die nächste Anfrage lädt sie dann erneut von der Festplatte. Diese Ladezeit verursacht die spürbare Pause. Erhöhen Sie den Wert für eine einzelne Anfrage, indem Sie "keep_alive": "30m" im JSON-Body senden. Für den gesamten Server verwenden Sie die Umgebungsvariable OLLAMA_KEEP_ALIVE.

Wie halte ich ein Ollama-Modell dauerhaft im Arbeitsspeicher?

Verwenden Sie einen negativen Wert: "keep_alive": -1 für die Anfrage oder OLLAMA_KEEP_ALIVE=-1 für den Server. ollama ps zeigt dann Forever in der Spalte UNTIL an. Dadurch wird nur der Leerlauf-Timer deaktiviert. Wenn ein anderes Modell angefordert wird und der Speicher nicht ausreicht, entlädt der Scheduler dieses Modell weiterhin, um Platz zu schaffen.

Warum wird OLLAMA_KEEP_ALIVE ignoriert?

Prüfen Sie, wo Sie die Variable gesetzt haben. Führen Sie systemctl show ollama --property=Environment aus. Wenn die Variable in dieser Ausgabe fehlt, hat der Server sie nicht erhalten. Eine in Ihrer Shell exportierte Variable wird nicht an einen systemd-Dienst weitergegeben. Setzen Sie sie mit sudo systemctl edit ollama.service. Führen Sie anschließend sudo systemctl daemon-reload und sudo systemctl restart ollama aus. Eine weitere Ursache ist ein Client, der bei der Anfrage einen eigenen Wert für keep_alive sendet. Dieser überschreibt den Serverstandard.

Wie gebe ich den Speicher frei, ohne Ollama neu zu starten?

ollama stop qwen3:8b entlädt dieses eine Modell sofort. Der Server und alle anderen geladenen Modelle laufen weiter. Senden Sie über die API eine Anfrage ohne Prompt und mit "keep_alive": 0. Die Antwort enthält dann "done_reason": "unload". Prüfen Sie dies mit ollama ps. Das Modell sollte dort nicht mehr aufgeführt sein.