Ollama model in geheugen houden: zo stelt u keep_alive in

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 naar het RAM of VRAM mappen, 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 bij het volgende bericht weer traag reageert. Er is niets defect. De inactiviteitstimer is verlopen.

De timer heet keep_alive. Deze is 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 standaardwaarde voor de server. Een systemd drop-in zorgt ervoor dat de standaardwaarde 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 ontlaadt.

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

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

Elke invoer 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 het herladen 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 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 te wijzigen. Het grootste deel van dat verschil wordt veroorzaakt door schijf-leesacties; als u dus de modelmap naar een tweede volume heeft verplaatst, bepaalt de snelheid van dat volume de ondergrens voor elke koude start. 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 bij één verzoek

Verstuur keep_alive bij 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 waarden 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, krijgt voorrang op alles wat u op de server heeft geconfigureerd.

U kunt een model ook 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 om uit te voeren na een reboot, of na het ophalen van een nieuw model, 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 dit moet staan. Het uitvoeren van export OLLAMA_KEEP_ALIVE=30m in uw SSH-sessie heeft geen effect, omdat de pakketinstallatie de server uitvoert als een systemd-service onder een eigen gebruiker met een eigen omgeving. Uw inlog-shell en die service komen elkaar nooit tegen. 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 uw wijzigingen tussen deze twee regels: systemd negeert alles wat u onder de tweede markering schrijft.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Het opslaan schrijft /etc/systemd/system/ollama.service.d/override.conf. Dit is een drop-in in plaats van een aanpassing 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 verwerkt. 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 cold load. Warm het model op met de bovenstaande preload-aanroep.

Wat het resident houden van een model u kost

De kolom SIZE in ollama ps betreft 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 er op de server draait. Op een kleine VPS is dat 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 geladen is, en daarna nogmaals na ollama stop:

free -h

De kolom available 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 in VRAM. Als de server onvoldoende geheugen heeft, beëindigt de kernel een proces om ruimte vrij te maken:

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

Een regel met de naam ollama betekent dat de modelserver het slachtoffer was. Een regel met de naam van uw database betekent dat het model won en dat een proces dat u belangrijk vond, is beëindigd. Beide uitkomsten vloeien voort uit dezelfde beslissing: een lang keep-alive-venster op een server zonder reservecapaciteit.

Twee kostenposten worden hier gemakkelijk 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-grootte. Hoe groot deze wordt, volgt uit num_ctx, dus het vergroten van het contextvenster verhoogt het geheugen dat een resident model vasthoudt gedurende de gehele inactieve periode, niet alleen terwijl het antwoord geeft. OLLAMA_NUM_PARALLEL boven 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 ruimte kan -1 gebruiken. Een gedeelde server moet een venster gebruiken dat de pauzes tussen uw verzoeken overbrugt, zoals 30m, zodat het geheugen vrijkomt wanneer 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 en 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 lopend 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, maar het geheugen is de feitelijke beperkende factor. Een tweede groot model kan daarom al worden geweigerd 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 voorkeur gaat uit naar een model zonder actieve aanvraag. Het systeem verwijdert ook een model waarvan de timer nog niet is verstreken, inclusief een model dat is geladen met -1. Een negatieve waarde voor keep_alive betekent dus geen idle-timeout. Dit zet de gewichten niet vast tegen een aanvraag van een ander model.

Deze 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 op dat moment gebruikt 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 verschillende releases heen consistent 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 ontlaadt Ollama mijn model na 5 minuten?

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 pauze 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 bij het verzoek, of OLLAMA_KEEP_ALIVE=-1 voor de server. ollama ps toont vervolgens Forever in de kolom UNTIL. Dit verwijdert enkel de inactiviteitstimer. Als er een ander model wordt opgevraagd en het geheugen is beperkt, zal de scheduler dit model alsnog ontladen 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. Een andere oorzaak is een client die een eigen keep_alive meestuurt bij het verzoek, wat de standaardwaarde van de server overschrijft.

Hoe maak ik het geheugen vrij zonder Ollama te herstarten?

ollama stop qwen3:8b ontlaadt dat specifieke model direct, 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.