Ollama-Modell dauerhaft im Speicher halten

Warum entlädt Ollama das Modell nach einigen Minuten?

Ollama lässt ein Modell nach der letzten Anfrage fünf Minuten lang im Speicher geladen und gibt es anschließend frei. Bei der nächsten Anfrage müssen die Gewichte erneut in den RAM oder VRAM geladen werden. Deshalb vergeht Zeit, bevor das erste Token eintrifft. Aus diesem Grund fühlt sich eine Chat-UI oder ein Coding-Agent zunächst schnell an, wird eine Weile still und reagiert bei der nächsten Nachricht wieder langsamer. Es ist nichts defekt. Der Leerlauf-Timer ist abgelaufen.

Der Timer heißt keep_alive. Er gilt pro Modell und wird nach jedem abgeschlossenen Request neu gestartet. Ein Modell, das gerade eine Anfrage beantwortet, wird nie entladen. Der Server lässt nur ein Modell ohne aktive Anfrage ablaufen. Im Oktober 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 gesetzt werden: für die einzelne Anfrage oder als Standardwert des Servers. Ein systemd-Drop-in sorgt dafür, dass der Serverstandard einen Neustart übersteht. In dieser Anleitung wird vorausgesetzt, dass Ollama bereits als Dienst ausgeführt wird. Falls nicht, beginnen Sie mit der Installation von Ollama auf einem VPS 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 kein Modell geladen ist. Die nächste Anfrage muss das Modell daher zuerst laden. PROCESSOR zeigt, wohin die Gewichte geladen wurden. 100% GPU und 100% CPU sind eindeutige Fälle. Eine Aufteilung wie 25%/75% CPU/GPU bedeutet, dass sich nur ein Teil des Modells im VRAM befindet. Der restliche Teil läuft auf dem Prozessor, wodurch die Generierung langsamer ist. Normalerweise passt das Modell nicht vollständig in den VRAM. Eine num_gpu-Einstellung, die festlegt, wie viele Layer auf der GPU ausgeführt werden, erzeugt jedoch dieselbe Aufteilung.

UNTIL ist der Countdown. Der Wert wird als relative Zeit wie 4 minutes from now ausgegeben. Forever wird ausgegeben, wenn das Modell mit einem negativen keep_alive geladen wurde. Während des kurzen Zeitfensters, 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 Script zu zählen. Ollama v0.40.2, das aktuelle Release zum Zeitpunkt dieser Prüfung am 2026-10-10, gibt außerdem eine RUNNER-Spalte zwischen CONTEXT und UNTIL aus. Sie nennt den Runner, der das Modell bereitstellt. Ihre Kopfzeile kann daher eine Spalte breiter sein als das obige Beispiel. 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, also den Teil des Modells, der sich im GPU-Speicher befindet. Ein size_vram-Wert von 0 bedeutet, dass das Modell auf der CPU ausgeführt wird.

Was der Reload tatsächlich kostet

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

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 sein load_duration groß. Teilen Sie den Wert durch 1000000000, um ihn als Sekunden abzulesen. Der zweite Aufruf läuft, während das Modell resident ist, und meldet einen deutlich kleineren Wert. Die Differenz zwischen diesen beiden Werten ist die Wartezeit, die jeder Benutzer nach Ablauf des Timers in Kauf nehmen muss. Genau deshalb sollten Sie keep_alive ändern. Nach einem Unload enthält der Page Cache des Kernels die Modelldatei häufig weiterhin. Auf einem System mit ausreichend freiem RAM kann ein Reload daher schneller sein als das erste Laden nach einem Boot. Wenn dieser Cache verdrängt wurde, werden die Gewichte von der Festplatte gelesen. Wenn Sie das Modellverzeichnis auf ein zweites Volume verschoben haben, bestimmt die Geschwindigkeit dieses Volumes die minimale Dauer jedes Cold Loads. Informationen zur Generierungsgeschwindigkeit vor und nach dieser Pause finden Sie unter So messen Sie 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 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.

Nach einem Neustart mit einem systemd-Drop-in weiterlaufen

sudo systemctl edit ollama.service

Der Editor wird mit zwei Kommentar-Markierungen geöffnet. Geben Sie den 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. 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. Falls 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. Die Ursache ist fast immer eine fehlende [Service]-Kopfzeile oder Inhalt, der unterhalb der Markierung eingegeben wurde. Der Neustart entfernt außerdem alle geladenen Modelle. Die nächste Anfrage lädt das Modell daher erneut. Wärmen Sie den Dienst mit dem obigen Preload-Aufruf vor. Das Drop-in bewahrt die Einstellung über einen Neustart hinweg, nicht aber das Modell: Der Dienst startet ollama serve ohne geladenes Modell. Führen Sie daher nach jedem Bootvorgang denselben Preload-Aufruf aus.

Die Kosten eines resident gehaltenen Modells

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 belegt etwa 5 bis 6 GB. Ein 27B-Modell ist eine andere Größenordnung, und die Speicherberechnung für den Betrieb auf einem CPU-only-VPS sollten Sie durchgehen, bevor Sie ein Modell resident halten. Wenn Sie keep_alive auf -1 setzen, legen Sie fest, dass das Modell diesen Speicher so lange belegt, wie der Server läuft, sofern die Anfrage eines anderen Modells es nicht verdrängt. Auf einem kleinen VPS steht dieser Speicher dann Ihrer Datenbank, Ihrer Webanwendung und Ihren Build-Jobs nicht zur Verfügung.

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 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 dem Namen Ihrer Datenbank bedeutet, dass das Modell weiterlief und ein wichtiger Prozess beendet wurde. Beide Ergebnisse gehen auf dieselbe Entscheidung zurück: ein langer Keep-Alive-Zeitraum auf einem Server ohne ausreichende Speicherreserve.

Zwei Kosten werden dabei leicht übersehen. Eine größere Context Length reserviert einen größeren KV-Cache (Key-Value-Cache, also den Attention-Zustand pro Token, den das Modell während der Generierung speichert). Dieser Cache gehört zur residenten Größe. Wie groß er wird, hängt von num_ctx ab. Wenn Sie daher das Context Window vergrößern, steigt der Speicherbedarf eines 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, nicht nur für die Gewichte.

Eine sinnvolle Standardeinstellung ist: Ein Modell auf einem Server mit ausreichender Speicherreserve kann -1 verwenden. Auf einem gemeinsam genutzten Server sollte der Zeitraum die Lücken zwischen Ihren Anfragen abdecken, 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. Bei einem Modell, das Sie abgerufen haben, das derzeit aber nicht geladen ist, wird ebenfalls keine Ausgabe zurückgegeben. Der Befehl prüft nicht, welche Modelle im Speicher geladen sind. Er sendet die Entladeanforderung, und der Server antwortet mit Erfolg, unabhängig davon, ob sich etwas im Speicher befand. Der Fehler couldn't find model "qwen3:8b" to stop tritt nur auf, wenn auf diesem Server kein Modell mit diesem Namen installiert ist. Das weist normalerweise auf einen Tippfehler im Namen oder Tag hin. Ein lautloser ollama stop ist daher kein Beweis dafür, dass Speicher freigegeben wurde. ollama ps ist dieser Beweis. Die API-Variante ist eine Anfrage ohne Prompt, bei der keep_alive auf 0 gesetzt wird:

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, entfernt 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 Oktober 2026 sind standardmäßig drei Modelle pro GPU oder drei Modelle auf einem System ohne GPU zulässig. Die Begrenzung zählt Modelle. Der tatsächliche Grenzwert ist jedoch der verfügbare Speicher. Daher kann ein zweites großes Modell bereits abgelehnt werden, bevor drei Modelle erreicht sind.

Wenn ein neues Modell angefordert wird und dafür nicht genügend Speicher verfügbar ist oder die Begrenzung erreicht wurde, entlädt der Scheduler eines der bereits geladenen Modelle. Dadurch wird Speicher freigegeben. Bevorzugt wird ein Modell ohne aktive Anfrage. Der Scheduler kann auch ein Modell entfernen, dessen Timer noch nicht abgelaufen ist. Das gilt auch für ein mit -1 geladenes Modell. Modelle mit kürzeren Zeitfenstern werden jedoch zuerst berücksichtigt. Ein negativer Wert für keep_alive bedeutet daher, dass kein Leerlauf-Timeout verwendet wird. Die Modellgewichte werden nicht gegen die Anfrage eines anderen Modells reserviert.

Diese Entscheidungen werden im Service-Log angezeigt. Der Fall, in dem die Begrenzung erreicht wurde, wird jedoch nur auf Debug-Level protokolliert. Fügen Sie im selben Drop-in eine zweite Environment="OLLAMA_DEBUG=1"-Zeile hinzu, starten Sie den Dienst neu und überwachen Sie das Log:

sudo journalctl -u ollama -f

Lesen Sie den Grund, der neben der Anfrage angegeben wird, die das Entladen ausgelöst hat. max runners achieved, unloading one to make room bedeutet, dass die OLLAMA_MAX_LOADED_MODELS-Begrenzung erreicht wurde. Das kann auch passieren, wenn beide Modelle in den verfügbaren Speicher passen würden. Erhöhen Sie die Begrenzung, wenn free -h noch ausreichenden Spielraum anzeigt. Eine Zeile, die meldet, dass das neue Modell voraussichtlich den verfügbaren Speicher überschreitet, gefolgt vom Entfernen eines Modells, zeigt, dass diese beiden Modelle auf diesem Rechner nicht gemeinsam geladen werden können. Verwenden Sie in diesem Fall weniger Modelle auf diesem Server. Alternativ können Sie für das Modell, das schnell antworten muss, ein langes Zeitfenster konfigurieren und für das Modell, das Sie selten aufrufen, 0 verwenden.

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 entfernt Ollama mein Modell nach 5 Minuten aus dem Speicher?

Fünf Minuten sind der Standardwert für keep_alive, den Ollama startet, sobald eine Anfrage abgeschlossen ist. Wenn der Timer abläuft, gibt der Server die Modellgewichte frei. Die nächste Anfrage muss sie daher erneut laden. Dieser Ladevorgang 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 Inaktivitätstimer deaktiviert. Wenn ein anderes Modell angefordert wird und der Speicher nicht ausreicht, entfernt der Scheduler dieses Modell weiterhin aus dem Speicher, um Platz zu schaffen. Ein Neustart oder Reboot löscht diese Einstellung ebenfalls. Laden Sie das Modell danach erneut vorab.

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 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 kann ein Client sein, der bei der Anfrage einen eigenen Wert für keep_alive sendet. Dieser überschreibt den Standardwert des Servers.

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

ollama stop qwen3:8b entfernt dieses eine Modell sofort aus dem Speicher. Der Server und alle anderen geladenen Modelle bleiben aktiv. 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 das mit ollama ps. Das Modell sollte dort nicht mehr aufgeführt sein.