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 lang im Speicher. Danach gibt Ollama das Modell 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 der Server, bevor das erste Token eintrifft. Das Verhalten tritt beispielsweise bei einer Chat-Oberfläche oder einem Coding-Agenten auf: Zunächst reagiert alles schnell, dann bleibt es eine Weile ruhig, und die nächste Nachricht wird wieder langsam verarbeitet. Es liegt kein Fehler vor. Der Inaktivitäts-Timer ist abgelaufen.

Der Timer heißt keep_alive. Er gilt pro Modell und wird nach jeder abgeschlossenen Anfrage neu gestartet. Ein Modell, das gerade eine Anfrage beantwortet, wird nie entladen. Der Server entfernt nur ein Modell, für das keine aktive Anfrage vorliegt. Im August 2026 beträgt der Standardwert fünf Minuten. Er gilt für jedes Modell, das dieser Server lädt.

keep_alive kann an zwei Stellen festgelegt werden: für die einzelne Anfrage oder als Standardwert des Servers. Ein systemd-Drop-in sorgt dafür, dass der Standardwert des Servers auch nach einem Neustart erhalten bleibt. Diese Anleitung setzt voraus, dass Ollama bereits als Dienst ausgeführt wird. Falls das nicht der Fall ist, beginnen Sie mit der Installation von Ollama auf einem VPS und kehren Sie anschließend hierher zurück.

Welche Modelle sind derzeit geladen, 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 daher 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 wie 4 minutes from now ausgegeben. Bei einem Modell, das mit einem negativen keep_alive geladen wurde, wird Forever ausgegeben. Während des kurzen Zeitraums, in dem der Server das Modell entlädt, wird Stopping... ausgegeben.

Die Spalten können sich zwischen Releases ändern. Lesen Sie daher die Kopfzeile, anstatt die Felder in einem Skript zu zählen. Für automatisierte Auswertungen 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. Deshalb ist sein load_duration groß. Teilen Sie den Wert durch 1000000000, um ihn in Sekunden abzulesen. Der zweite Aufruf läuft, während sich das Modell im Speicher befindet, und meldet einen deutlich kleineren Wert. 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. Informationen zur Generierungsgeschwindigkeit vor und nach dieser Pause finden Sie unter So messen Sie die Tokens pro Sekunde 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 Werteformate akzeptiert:

• eine Dauerangabe: "30m", "24h", "90s"
• eine einfache Zahl, interpretiert als Sekunden: 3600
• ein negativer Wert, -1 oder "-1m", der überhaupt kein Inaktivitäts-Timeout bedeutet
• 0, wodurch das Modell direkt nach Abschluss dieser Anfrage entladen wird

Ein Wert in der Anfrage überschreibt den Serverstandard, und zwar in beide Richtungen. Das ist wichtiger, als es zunächst klingt: Ein Client, der eigenes keep_alive sendet, setzt sich gegen jede Serverkonfiguration durch.

Sie können ein Modell auch laden, ohne etwas zu generieren. Senden Sie nur den Modellnamen. Der Server lädt das Modell und gibt eine leere Antwort mit "done": true 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 Abruf 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"

Mit OLLAMA_KEEP_ALIVE standardmäßig 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. Das Feld akzeptiert dieselben Formate wie das Anfragefeld. Daher funktionieren 30m, 3600 und -1.

Entscheidend ist jedoch, in welcher Umgebung die Variable gesetzt wird. Wenn Sie export OLLAMA_KEEP_ALIVE=30m in Ihrer SSH-Sitzung ausführen, hat das keine Wirkung, weil die Paketinstallation den Server als systemd-Dienst unter einem eigenen Benutzer und mit einer eigenen Umgebung ausführt. Ihre Login-Shell und dieser Dienst verwenden nicht dieselbe Umgebung. Das ist der häufigste Grund dafür, dass die Einstellung scheinbar ignoriert wird.

Machen Sie die Einstellung mit einem systemd-Drop-in dauerhaft

sudo systemctl edit ollama.service

Der Editor wird mit zwei Kommentar-Markierungen geöffnet. Geben Sie Ihren Inhalt zwischen diesen Markierungen ein: systemd verwirft alles, was Sie unterhalb der zweiten Markierung schreiben.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Beim Speichern wird /etc/systemd/system/ollama.service.d/override.conf geschrieben. Das ist ein Drop-in und keine Änderung an der ausgelieferten Unit. Daher bleibt Ihre Einstellung erhalten, wenn ein Ollama-Paketupdate ollama.service ersetzt. 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 gestartet wird. Fehlt OLLAMA_KEEP_ALIVE=30m in dieser Ausgabe, wurde das Drop-in nicht übernommen. Ursache ist fast immer ein fehlender [Service]-Header oder Inhalt, der unterhalb der Markierung eingegeben wurde. Der Neustart entfernt alle geladenen Modelle. Die nächste Anfrage lädt das Modell daher vollständig neu. Wärmen Sie es mit dem obigen Preload-Aufruf vor.

Welche Kosten ein resident gehaltenes Modell verursacht

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. Ein 27B-Modell ist eine andere Größenordnung. Die Speicherberechnung für den Betrieb auf einer CPU-only-VPS sollten Sie durchgehen, bevor Sie sich entscheiden, ein Modell resident zu halten. Wenn Sie keep_alive auf -1 setzen, haben Sie festgelegt, 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.

Überwachen 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 könnte. 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 Model-Server beendet wurde. Eine Zeile mit Ihrer Datenbank bedeutet, dass das Modell Vorrang hatte und ein wichtiger Dienst beendet wurde. Beide Ergebnisse gehen auf dieselbe Entscheidung zurück: ein langes Keep-Alive-Zeitfenster auf einem Server ohne Speicherreserve.

Zwei Kosten werden leicht übersehen. Eine längere Kontextlänge reserviert einen größeren KV-Cache (Key-Value-Cache, also den zustandsbezogenen Attention-Speicher pro Token, den das Modell während der Generierung vorhält). Dieser Cache ist Teil der residenten Speichergröße. Ein Wert OLLAMA_NUM_PARALLEL über 1 reserviert diesen Cache einmal pro parallelem Slot. Wenn Sie mehrere Personen mit einem Modell bedienen möchten, müssen Sie den Speicher für die Slots dimensionieren, nicht nur für die Gewichte.

Eine sinnvolle Standardeinstellung: Ein Modell auf einem Server mit Speicherreserve kann -1 verwenden. Auf einem gemeinsam genutzten Server sollten Sie ein Zeitfenster wählen, das die Abstände zwischen Ihren Anfragen abdeckt, beispielsweise 30m. Danach 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 nicht geladenen Namen wird couldn't find model "qwen3:8b" to stop zurückgegeben. Ü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 dies, anstatt den Dienst neu zu starten. systemctl restart ollama gibt den Speicher ebenfalls frei, entlädt jedoch alle anderen geladenen Modelle und beendet jede laufende Anfrage.

Mehr als ein Modell auf einem Server ausführen

OLLAMA_MAX_LOADED_MODELS begrenzt, wie viele Modelle gleichzeitig geladen bleiben. Seit August 2026 beträgt der Standardwert drei pro GPU beziehungsweise drei auf einem System ohne GPU. Die Begrenzung zählt Modelle. Der tatsächlich verfügbare Speicher ist jedoch das entscheidende Limit. Daher kann ein zweites großes Modell bereits abgelehnt werden, lange bevor drei Modelle erreicht 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. Die Modellgewichte werden dadurch nicht gegen die Anfrage eines anderen Modells geschützt.

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

sudo journalctl -u ollama -f

Eine Zeile über das Ausladen eines Runners, um Platz zu schaffen, direkt neben der Anfrage, die dies ausgelöst hat, zeigt, dass diese beiden Modelle nicht gemeinsam auf diesem System Platz finden. Die Lösung besteht darin, weniger Modelle auf diesem Server zu betreiben oder für das Modell, das schnell antworten muss, ein langes Zeitfenster und für das Modell, das Sie selten aufrufen, 0 zu verwenden.

Hinweise, die über das nächste Release hinaus gelten

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

ollama --version
ollama serve --help

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

Wenn ein Editor oder ein Agent Ihren Server steuert, prüfen Sie, was dieser Client sendet, bevor Sie den Server als Ursache ansehen. Einen Coding-Agent auf Ihren eigenen Ollama-Server ausrichten beschreibt, wo diese Anfrageeinstellungen hinterlegt sind.

FAQ

Warum entlädt Ollama mein Modell nach 5 Minuten?

Fünf Minuten sind der Standardwert für keep_alive, den Ollama nach Abschluss einer Anfrage startet. 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 Speicher?

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 Idle-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 nicht enthalten ist, hat der Server sie nie 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 ein eigenes keep_alive sendet. Dadurch wird der Standardwert des Servers überschrieben.

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.