Ollama model in geheugen houden met keep_alive

Waarom ontlaadt Ollama het model na enkele minuten?

Ollama houdt een model vijf minuten na het laatste verzoek in het geheugen en geeft het daarna vrij. Het volgende verzoek moet de gewichten opnieuw van de schijf lezen en in het RAM of VRAM laden, waardoor het proces stagneert voordat het eerste token arriveert. Dit is de reden waarom een chat-UI of een coding agent snel aanvoelt, een tijdje stil blijft en vervolgens weer traag reageert bij het volgende bericht. Er is niets defect. De inactiviteitstimer is verlopen.

De timer heet keep_alive. Deze geldt per model en wordt telkens opnieuw gestart wanneer een verzoek is voltooid. Een model dat momenteel een verzoek beantwoordt, wordt nooit ontladen, omdat de server alleen modellen verwijdert waarvoor geen actief verzoek is. Sinds augustus 2026 is de standaardwaarde vijf minuten en deze is van toepassing op elk model dat deze server laadt.

Er zijn twee manieren om keep_alive in te stellen: per individueel verzoek of als standaardinstelling voor de server. Een systemd drop-in zorgt ervoor dat de standaardinstelling van de server behouden blijft na een herstart. Deze handleiding gaat ervan uit dat Ollama al als service draait. Als dat niet het geval is, begin dan met Ollama installeren op een VPS en keer daarna terug.

Welke modellen zijn momenteel geladen en wanneer verlopen ze?

ollama ps

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

Een lege uitvoer betekent dat er niets is geladen, waardoor het volgende verzoek een volledige laadtijd vereist. PROCESSOR geeft aan waar de gewichten zijn geplaatst. 100% GPU en 100% CPU zijn de duidelijke gevallen. Een splitsing zoals 25%/75% CPU/GPU betekent dat het model niet in het VRAM paste, waardoor een deel op de processor draait en de generatie trager verloopt.

UNTIL is het aftelmoment en toont een relatieve tijd zoals 4 minutes from now. Het toont Forever wanneer het model is geladen met een negatieve keep_alive. Het toont Stopping... tijdens het korte venster waarin de server het model aan het ontladen is.

De kolomset is tussen releases gewijzigd, dus lees de header in plaats van velden te tellen in een script. Gebruik voor automatisering de API:

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

Elk item bevat expires_at, een absolute tijdsaanduiding zoals 2026-08-09T14:38:31.83753Z, en size_vram, het deel van dat model dat in het GPU-geheugen staat. Een size_vram van 0 betekent dat het model op de CPU draait.

Wat de herlaadactie daadwerkelijk kost

Gok hier niet naar. Ollama rapporteert de laadtijd in elk antwoord, als load_duration, in nanoseconden.

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}'

De eerste aanroep laadt het model, waardoor de load_duration groot is. Deel door 1000000000 om dit in seconden af te lezen. De tweede aanroep wordt uitgevoerd terwijl het model in het geheugen aanwezig is en rapporteert een veel kleiner getal. Het verschil tussen deze twee cijfers is wat elke gebruiker betaalt zodra de timer is verlopen, en dit is de enige reden om keep_alive aan te passen. Zie hoe u tokens per seconde op uw eigen systeem meet voor de generatiesnelheid aan weerszijden van die pauze.

Een Ollama-model in het geheugen houden na een verzoek

Verstuur keep_alive met het verzoek. Dit is van toepassing op dat model vanaf het moment dat het verzoek is voltooid.

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

Er worden vier waardevormen geaccepteerd:

• een tijdsduur-string: "30m", "24h", "90s"
• een getal, gelezen als seconden: 3600
• een negatieve waarde, -1 of "-1m", wat betekent dat er geen idle-timeout is
• 0, wat betekent dat het model direct na afloop van dit verzoek uit het geheugen wordt geladen

Een waarde in het verzoek overschrijdt de standaardinstelling van de server, in beide richtingen. Dit is belangrijker dan het lijkt: een client die zijn eigen keep_alive meestuurt, wint het altijd van de configuratie op de server.

U kunt ook een model laden zonder iets te genereren. Verstuur alleen de modelnaam. De server laadt het model en geeft een leeg antwoord terug met "done": true.

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

Dit is het commando dat u uitvoert na een herstart, of nadat u een nieuw model heeft binnengehaald, zodat het eerste echte gebruikersverzoek niet hoeft te wachten op het laden. De CLI voert dezelfde taak uit met een flag:

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

Houd het standaard geladen met OLLAMA_KEEP_ALIVE

De server leest OLLAMA_KEEP_ALIVE bij het opstarten en gebruikt deze voor elk model dat geen eigen waarde heeft. Het accepteert dezelfde vormen als het verzoekveld, dus 30m, 3600 en -1 werken allemaal.

Het knelpunt is in welke omgeving deze variabele moet staan. Het uitvoeren van export OLLAMA_KEEP_ALIVE=30m in uw SSH-sessie heeft geen effect, omdat de pakketinstallatie de server als een systemd-service uitvoert onder een eigen gebruiker met een eigen omgeving. Uw inlog-shell en die service komen nooit met elkaar in contact. Dit is de meest voorkomende reden waarom de instelling genegeerd lijkt te worden.

Zorg voor persistentie na een herstart met een systemd drop-in

sudo systemctl edit ollama.service

De editor opent met twee commentaarmarkeringen. Typ tussen deze markeringen: systemd negeert alles wat u onder de tweede markering schrijft.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Opslaan schrijft /etc/systemd/system/ollama.service.d/override.conf. Dit is een drop-in in plaats van een bewerking van het meegeleverde unit-bestand, waardoor een upgrade van het Ollama-pakket die ollama.service vervangt, uw instelling ongemoeid laat. Als drop-ins en unit-bestanden nieuw voor u zijn, behandelt de handleiding voor systemd-services en timers de werking hiervan.

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

Het laatste commando toont de omgeving waarin de service daadwerkelijk zal draaien. Als OLLAMA_KEEP_ALIVE=30m ontbreekt op die regel, is de drop-in niet actief. De oorzaak is bijna altijd een ontbrekende [Service]-header of tekst die onder de markering is getypt. De herstart zelf verwijdert elk geladen model uit het geheugen, dus het volgende verzoek is een koude start. Warm het model op met de bovenstaande preload-aanroep.

De kosten van een resident model

De SIZE-kolom in ollama ps vertegenwoordigt het geheugen dat gedurende het gehele inactieve venster wordt vastgehouden, niet alleen tijdens een verzoek. Een 8B-model met 4-bit kwantisatie neemt ongeveer 5 tot 6 GB in beslag. Een 27B-model is een ander verhaal, en de geheugenberekening voor het draaien van een dergelijk model op een VPS zonder GPU is het waard om door te rekenen voordat u besluit het resident te houden. Stel keep_alive in op -1 en u heeft besloten dat het model permanent voorrang krijgt op alles wat op de server draait. Op een kleine VPS is dit een directe afweging ten opzichte van uw database, uw webapplicatie en uw build-taken.

Monitor de werkelijke cijfers in plaats van te vertrouwen op een schatting. Voer dit uit terwijl een model is geladen, en nogmaals na ollama stop:

free -h

De available-kolom is het geheugen dat de kernel nog aan een nieuw proces zou kunnen toewijzen. Op een systeem met een NVIDIA GPU toont nvidia-smi hetzelfde beeld voor VRAM. Als het geheugen opraakt, beëindigt de kernel een proces om ruimte vrij te maken:

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

Een regel waarin ollama wordt genoemd, betekent dat de modelserver het slachtoffer was. Een regel waarin uw database wordt genoemd, betekent dat het model won en een proces dat u belangrijk vindt, is beëindigd. Beide uitkomsten vloeien voort uit dezelfde beslissing: een lang keep-alive-venster op een server zonder vrije capaciteit.

Twee kostenposten worden hier vaak over het hoofd gezien. Een langere contextlengte reserveert een grotere KV-cache (key value cache, de per-token attention-status die het model bijhoudt tijdens het genereren), en die cache maakt deel uit van de resident-omvang. OLLAMA_NUM_PARALLEL groter dan 1 reserveert die cache eenmaal per parallelle slot. Als u van plan bent om meerdere gebruikers te bedienen met één model, bereken het geheugen dan op basis van de slots, niet alleen op basis van de gewichten.

Een redelijke standaardinstelling: één model op een server met voldoende vrije capaciteit kan -1 gebruiken. Een gedeelde server moet een venster gebruiken dat de pauzes tussen uw verzoeken overbrugt, zoals 30m, zodat het geheugen vrijkomt zodra u stopt met werken.

Een model onmiddellijk ontladen

ollama stop qwen3:8b

Het commando keert terug zonder uitvoer en het model verdwijnt uit ollama ps. Een naam die niet is geladen resulteert in couldn't find model "qwen3:8b" to stop. De API-vorm is een verzoek zonder prompt waarbij keep_alive is ingesteld op 0:

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

Het antwoord bevat "done_reason": "unload". Gebruik dit in plaats van de service te herstarten. systemctl restart ollama maakt het geheugen ook vrij, maar verwijdert elk ander geladen model en beëindigt elk actief verzoek.

Meerdere modellen op één server draaien

OLLAMA_MAX_LOADED_MODELS beperkt het aantal modellen dat tegelijkertijd geladen blijft. Sinds augustus 2026 is de standaardwaarde drie per GPU, of drie op een systeem zonder GPU. De limiet telt het aantal modellen, terwijl het geheugen de werkelijke beperking vormt. Een tweede groot model kan dus al geweigerd worden lang voordat u de limiet van drie bereikt.

Wanneer een nieuw model wordt aangevraagd en er is onvoldoende geheugen beschikbaar, ontlaadt de scheduler een van de actieve modellen om ruimte te maken. De scheduler geeft de voorkeur aan een model zonder actieve aanvraag en zal een model verwijderen waarvan de timer nog niet is verlopen, inclusief een model dat is geladen met -1. Een negatieve keep_alive betekent dus geen idle-timeout. Dit zet de gewichten niet vast tegen de aanvraag van een ander model.

Die beslissing wordt gelogd op debug-niveau. Voeg een tweede Environment="OLLAMA_DEBUG=1"-regel toe aan hetzelfde drop-in-bestand, herstart de service en monitor het proces:

sudo journalctl -u ollama -f

Een regel over het ontladen van een runner om ruimte te maken, direct naast de aanvraag die dit veroorzaakte, geeft aan dat deze twee modellen niet samen op deze machine passen. De oplossing is om minder modellen op deze server te draaien, of een lang venster in te stellen voor het model dat snel moet reageren en 0 te gebruiken voor het model dat u zelden aanroept.

Richtlijnen die langer meegaan dan de volgende release

Ollama brengt vaak updates uit en de standaardinstellingen wijzigen regelmatig. Controleer daarom de build die u voor u heeft in plaats van versienummers uit uw hoofd te leren:

ollama --version
ollama serve --help

ollama serve --help somt de omgevingsvariabelen op die de betreffende build daadwerkelijk inleest, waaronder OLLAMA_KEEP_ALIVE. Twee regels zijn door de releases heen constant gebleven en vormen een betrouwbare basis. Een waarde in het verzoek overschrijft de standaardinstelling van de server. En ollama ps is de enige bron van waarheid over wat er geladen is, ongeacht wat er in een configuratiebestand staat.

Als een editor of een agent uw server aanstuurt, controleer dan wat die client verstuurt voordat u de server de schuld geeft. Een coding agent koppelen aan uw eigen Ollama-server beschrijft waar deze verzoekinstellingen zich bevinden.

FAQ

Waarom verwijdert Ollama mijn model na 5 minuten uit het geheugen?

Vijf minuten is de standaardwaarde voor keep_alive, de inactiviteitstimer die Ollama start zodra een verzoek is voltooid. Wanneer deze verloopt, geeft de server de gewichten vrij. Het volgende verzoek laadt ze daarom opnieuw vanaf de schijf, wat de vertraging veroorzaakt die u ervaart. Verhoog deze waarde voor één verzoek door "keep_alive": "30m" in de JSON-body mee te sturen, of voor de gehele server met de omgevingsvariabele OLLAMA_KEEP_ALIVE.

Hoe houd ik een Ollama-model permanent in het geheugen geladen?

Gebruik een negatieve waarde: "keep_alive": -1 in het verzoek, of OLLAMA_KEEP_ALIVE=-1 voor de server. ollama ps toont vervolgens Forever in de kolom UNTIL. Dit verwijdert de inactiviteitstimer, maar doet niets anders. Als er een ander model wordt opgevraagd en er is onvoldoende geheugen, zal de scheduler dit model alsnog verwijderen om ruimte te maken.

Waarom wordt OLLAMA_KEEP_ALIVE genegeerd?

Controleer waar u de variabele heeft ingesteld. Voer systemctl show ollama --property=Environment uit; als de variabele niet in die uitvoer staat, heeft de server deze nooit ontvangen, omdat een variabele die in uw shell is geëxporteerd niet wordt doorgegeven aan een systemd-service. Stel deze in met sudo systemctl edit ollama.service en voer daarna sudo systemctl daemon-reload en sudo systemctl restart ollama uit. De andere oorzaak is een client die zijn eigen keep_alive meestuurt in het verzoek, wat de standaardwaarde van de server overschrijft.

Hoe maak ik het geheugen vrij zonder Ollama te herstarten?

ollama stop qwen3:8b verwijdert dat specifieke model direct uit het geheugen, terwijl de server en alle andere geladen modellen actief blijven. Stuur via de API een verzoek zonder prompt en met "keep_alive": 0; het antwoord bevat vervolgens "done_reason": "unload". Controleer dit met ollama ps, waarin het model niet langer vermeld zou moeten staan.