Ollama håller kvar modellen i minnet: mät och styr keep-alive

Att RAM eller VRAM fortfarande är upptaget när Ollama har svarat är normalt. Ollama behåller som standard modellen laddad i fem minuter, så att ett nytt anrop kan slippa en ny modelladdning. Det är en avvägning: väntetiden vid nästa anrop kan minska, men minnet är inte tillgängligt för ett spel, en annan modell eller ett annat tungt program under tiden. Med ett kontrollerat anrop, ollama ps och parametern keep_alive kan du se och styra beteendet i stället för att gissa.

Börja med Ollamas bild av minnet

Stäng först andra lokala AI-klienter som kan använda samma GPU. Kör sedan ollama ps innan provet. Kommandot listar de modeller som för närvarande är laddade i minnet. Kolumnen PROCESSOR visar om modellen ligger i CPU-minne, GPU-minne eller är delad mellan dem, medan UNTIL visar när Ollama planerar att lasta ur modellen. En tom lista betyder att Ollama inte har någon modell laddad just då.

ollama ps

Vill du spara mätvärden maskinellt ger GET /api/ps samma typ av inventering som JSON. Svaret innehåller bland annat modellnamn, total storlek, size_vram och expires_at. Fälten hjälper dig hålla isär en modell som ligger helt i VRAM från en som också använder systemets RAM.

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

Ta samtidigt en skärmbild eller notera ledigt RAM i operativsystemets aktivitetshanterare. Har du ett Nvidia-kort kan nvidia-smi ge en separat VRAM-kontroll. Operativsystemets totalsiffra är inte identisk med Ollamas modellstorlek: andra processer, drivrutiner och cache använder också minne. Jämför därför förändringen före och efter samma prov, inte bara två lösa totalsiffror från olika arbetslägen.

Kör ett anrop med en tydlig sluttid

Välj den modell du faktiskt använder och byt llama3.2 i exemplet om det behövs. Anropet nedan stänger av strömning, så att svaret och Ollamas tidsfält kommer i ett JSON-objekt. keep_alive är satt till tio minuter. När svaret är klart ska modellen därför synas i ollama ps med ungefär tio minuter kvar.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Svara med ett ord: klar",
  "stream": false,
  "keep_alive": "10m"
}'

Kör ollama ps direkt efter svaret och igen efter två minuter. Notera modell, SIZE, PROCESSOR och UNTIL vid båda tidpunkterna. Om du använder API:t kan du i stället spara expires_at. Det här är själva beviset för uppehållstiden; ett högt totalt RAM-utnyttjande räcker inte för att visa vilken process eller modell som håller minnet.

Prova omedelbar urlastning

Ollama dokumenterar två sätt att frigöra minnet direkt. CLI-kommandot ollama stop är enklast när du arbetar manuellt. Ange samma modellnamn som står i ollama ps:

ollama stop llama3.2
ollama ps

För ett API-flöde kan du skicka ett generate-anrop med keep_alive satt till 0. Ett tomt anrop räcker för att be Ollama lasta ur den angivna modellen:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "keep_alive": 0
}'
ollama ps

Kontrollera resultatet i två lager. Först ska modellen försvinna från ollama ps. Därefter ska operativsystemets RAM- eller VRAM-värde röra sig åt rätt håll. Frigöringen kan synas med viss fördröjning i en aktivitetsgraf, så notera värdet efter exempelvis 10 och 30 sekunder i stället för att kräva att varje grafpunkt ändras samtidigt.

Mät kostnaden vid nästa anrop

Omedelbar urlastning frigör minne men gör nästa anrop kallt. Kör därför samma korta prompt en gång direkt medan modellen ligger kvar och en gång efter att du lastat ur den. I det icke-strömmande svaret redovisar Ollama load_duration i nanosekunder. En låg laddningstid när modellen ligger kvar och en tydligt högre tid efter urlastning visar den väntetid du köper loss genom att reservera minnet.

Gör minst tre par och använd medianen. Ett enstaka anrop kan påverkas av diskcache, annan GPU-last och bakgrundsarbete. Om du vill skilja modelladdning, promptbearbetning och generering mer noggrant finns hela metoden i mätguiden för kall och varm Ollama-start. Här räcker jämförelsen för att avgöra om en viss uppehållstid är värd minnet.

Välj tid efter glappet mellan anrop

Utgå från den längsta normala pausen i ditt arbetsflöde, inte från ett godtyckligt högt tal. Kommer följdfrågan oftast inom tre minuter ger standardens fem minuter rimlig marginal. Arbetar du i block med tio till femton minuters mellanrum kan 15m vara ett bättre provvärde. Behöver du minnet direkt efter varje svar är 0 tydligast.

En negativ tid, exempelvis -1, håller enligt Ollamas dokumentation modellen laddad utan tidsgräns. Det passar bara när maskinen är avsedd för modellen och minnesmarginalen är verifierad. Om flera modeller konkurrerar om samma RAM eller VRAM kan en lång uppehållstid göra nästa modell svårare att ladda.

Ställ in per anrop eller för hela servern

keep_alive i /api/generate och /api/chat är bäst när olika klienter behöver olika tider. För ett servergemensamt standardvärde kan du sätta miljövariabeln OLLAMA_KEEP_ALIVE när Ollama-servern startar. Den tar samma typer av värden: en tidssträng som 10m, sekunder, ett negativt värde eller 0. Ett keep_alive-värde i det enskilda API-anropet går före miljövariabeln.

Dokumentera tre saker i driftkortet: serverns standard, vilka klienter som skriver över den och vilket minnesvärde som ska utlösa urlastning. Då går det att förklara varför en modell fortfarande ligger kvar utan att leta i både tjänstekonfiguration och klientkod.

Källor

• Ollama FAQ — fem minuters standard, tillåtna keep-alive-värden, omedelbar urlastning och miljövariabeln
• Ollama generate-API — keep_alive, stream och svarsfältet load_duration
• Ollama ps-API — laddade modeller, storlek, VRAM-storlek och sluttid

Källorna kontrollerades 23 sep 2026. Rekommendationerna om 2, 5 och 15 minuter är provvärden för olika arbetsmönster, inte Ollamas kapacitetslöften. Kontrollera artikeln igen när Ollama ändrar dokumentationen för keep_alive, OLLAMA_KEEP_ALIVE eller /api/ps, eller senast 23 okt 2026.