Paano Panatilihing Naka-load ang Ollama Model sa RAM

Bakit inaalis ng Ollama sa memory ang model pagkalipas ng ilang minuto?

Pinananatiling naka-load ng Ollama sa memory ang isang model nang limang minuto pagkatapos ng huling request, saka ito inaalis. Kailangang basahin muli ng susunod na request ang weights mula sa disk at i-map ang mga ito sa RAM o VRAM, kaya may pagkaantala bago lumabas ang unang token. Dahil dito, mabilis ang chat UI o coding agent, tumatahimik nang ilang sandali, at mabagal muli sa susunod na message. Walang sira. Nag-expire ang idle timer.

Ang timer ay tinatawag na keep_alive. Bawat model ay may sarili nito, at nire-restart ito sa tuwing natatapos ang isang request. Hindi kailanman inaalis ang model na kasalukuyang sumasagot sa isang request, dahil nag-e-expire lamang ang server ng model na walang aktibong request. Noong August 2026, limang minuto ang default, at nalalapat ito sa bawat model na nilo-load ng server na ito.

May dalawang lugar kung saan maaaring itakda ang keep_alive: sa indibidwal na request o bilang server default. Ang systemd drop-in ang nagpapanatili sa server default kahit mag-restart ang server. Ipinapalagay ng gabay na ito na tumatakbo na ang Ollama bilang isang service. Kung hindi pa ito tumatakbo, magsimula sa pag-install ng Ollama sa isang VPS at bumalik dito.

Anong mga model ang kasalukuyang naka-load, at kailan mag-e-expire ang mga ito?

ollama ps

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

Ang walang output ay nangangahulugang walang naka-load, kaya buong loading ang babayaran ng susunod na request. Ipinapakita ng PROCESSOR kung saan napunta ang weights. Ang 100% GPU at 100% CPU ang malinaw na mga kaso. Ang split gaya ng 25%/75% CPU/GPU ay nangangahulugang hindi nagkasya ang model sa VRAM, kaya bahagi nito ay tumatakbo sa processor at mas mabagal ang generation.

Ang UNTIL ang countdown, at nagpi-print ito ng relative time gaya ng 4 minutes from now. Nagpi-print ito ng Forever kapag na-load ang model gamit ang negatibong keep_alive. Nagpi-print ito ng Stopping... sa maikling panahon habang inaalis ng server ang model.

Nagbago ang set ng mga column sa pagitan ng mga release, kaya basahin ang header sa halip na bilangin ang mga field sa isang script. Para sa anumang automated na proseso, i-query ang API:

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

May expires_at ang bawat entry, isang absolute timestamp gaya ng 2026-08-09T14:38:31.83753Z, at size_vram, ang bahaging nasa GPU memory ng model. Ang size_vram na 0 ay nangangahulugang tumatakbo ang model sa CPU.

Ang aktuwal na gastos ng reload

Huwag itong hulaan. Iniuulat ng Ollama ang load time sa bawat response bilang load_duration, na nasa nanoseconds.

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

Nilo-load ng unang call ang model, kaya malaki ang load_duration nito. Hatiin ito sa 1000000000 para mabasa bilang seconds. Tumatakbo ang ikalawang call habang naka-resident ang model, kaya mas maliit ang iniuulat nitong bilang. Ang agwat ng dalawang value na ito ang kailangang bayaran ng bawat user kapag nag-expire ang timer. Ito ang buong dahilan para baguhin ang keep_alive. Para sa generation speed bago at pagkatapos ng pause na iyon, tingnan ang kung paano sukatin ang tokens per second sa sarili mong box.

Panatilihing naka-load sa memory ang isang Ollama model sa isang request

Ipadala ang keep_alive kasama ng request. Nalalapat ito sa model mula sa oras na matapos ang request.

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

Apat na anyo ng value ang tinatanggap:

• duration string: "30m", "24h", "90s"
• plain number na binabasa bilang segundo: 3600
• negatibong value, -1 o "-1m", na nangangahulugang walang idle timeout
• 0, na nangangahulugang i-unload ang model kapag natapos ang request

Ino-override ng value sa request ang default ng server sa parehong direksiyon. Mahalaga ito: mananaig ang sariling keep_alive ng client sa anumang na-configure mo sa server.

Maaari ka ring mag-load ng model nang walang anumang generation. Ipadala lamang ang pangalan ng model. Ila-load ito ng server at magbabalik ng walang laman na response na may "done": true.

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

Ito ang command na dapat patakbuhin pagkatapos ng reboot o pagkatapos mag-pull ng bagong model, upang hindi kailangang hintayin ng unang aktuwal na user request ang pag-load. Pareho rin ang ginagawa ng CLI gamit ang isang flag:

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

Panatilihing naka-load bilang default gamit ang OLLAMA_KEEP_ALIVE

Binabasa ng server ang OLLAMA_KEEP_ALIVE sa startup at ginagamit ito para sa bawat model na walang sariling value. Pareho ito ng mga form na ginagamit ng request field, kaya gumagana ang 30m, 3600, at -1.

Ang mahalaga ay kung kaninong environment ito dapat ilagay. Walang epekto ang pagpapatakbo ng export OLLAMA_KEEP_ALIVE=30m sa iyong SSH session dahil pinapatakbo ng packaged install ang server bilang systemd service sa ilalim ng sarili nitong user at sariling environment. Hindi nagkikita ang iyong login shell at ang service na iyon. Ito ang pinakakaraniwang dahilan kung bakit mukhang hindi pinapansin ang setting.

Gawing persistent ito matapos ang restart gamit ang systemd drop-in

sudo systemctl edit ollama.service

Magbubukas ang editor na may dalawang comment marker. Mag-type sa pagitan ng mga ito: itinatapon ng systemd ang anumang isusulat mo sa ibaba ng pangalawang marker.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Ang pag-save ay sumusulat sa /etc/systemd/system/ollama.service.d/override.conf. Drop-in ito at hindi pag-edit ng shipped unit, kaya mananatili ang setting mo kapag pinalitan ng Ollama package upgrade ang ollama.service. Kung bago sa iyo ang mga drop-in at unit file, ipinaliliwanag ng systemd service at timer guide ang mga mekanismo nito.

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

Ipinapakita ng huling command ang environment na aktuwal na gagamitin ng service. Kung wala ang OLLAMA_KEEP_ALIVE=30m sa linyang iyon, hindi nailapat ang drop-in. Halos palaging sanhi nito ang nawawalang [Service] header o mga linyang na-type sa ibaba ng marker. Inaalis ng restart mismo ang lahat ng naka-load na model, kaya cold load ang susunod na request. I-warm up ito gamit ang preload call sa itaas.

Magkano ang memory kapag nananatiling naka-load ang isang model

Ang column na SIZE sa ollama ps ay memory na ginagamit sa buong idle window, hindi lamang habang may request. Ang 8B model na may 4-bit quantisation ay kumokonsumo ng humigit-kumulang 5 hanggang 6 GB. Ibang usapan ang 27B model, at sulit pag-aralan ang memory arithmetic para magpatakbo nito sa CPU-only VPS bago ka magpasiyang panatilihin itong naka-load. Kapag itinakda mo ang keep_alive sa -1, nagpasya kang mas mahalaga ang model kaysa sa lahat ng iba pang tumatakbo sa server, nang permanente. Sa maliit na VPS, direktang kapalit nito ang memory para sa database, web app, at build jobs mo.

Suriin ang aktuwal na mga numero sa halip na umasa sa estimate. Patakbuhin ito habang naka-load ang model, at ulitin pagkatapos ng ollama stop:

free -h

Ang column na available ay ang memory na maaari pang ibigay ng kernel sa isang bagong process. Sa NVIDIA GPU box, ipinapakita ng nvidia-smi ang parehong sitwasyon sa VRAM. Kapag naubusan ng memory ang box, pumapatay ang kernel ng isang process upang makabawi:

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

Ang linyang may pangalan ng ollama ay nangangahulugang ang model server ang pinatay. Kapag database mo ang nakapangalan sa isang linya, nanalo ang model at naapektuhan ang isang serbisyong mahalaga sa iyo. Parehong resulta ang mga ito ng iisang desisyon: mahabang keep-alive window sa box na walang sapat na headroom.

May dalawang gastos dito na madaling hindi mapansin. Ang mas mahabang context length ay nagrereserba ng mas malaking KV cache (key value cache, ang per-token attention state na pinananatili ng model habang nagge-generate), at bahagi ng resident size ang cache na ito. Ang OLLAMA_NUM_PARALLEL na higit sa 1 ay nagrereserba ng cache na ito para sa bawat parallel slot. Kung plano mong mag-serve ng ilang tao mula sa isang model, i-size ang memory para sa mga slot, hindi lamang para sa weights.

Makatuwirang default: ang isang model sa box na may sapat na headroom ay maaaring gumamit ng -1. Ang shared box ay dapat gumamit ng window na sumasaklaw sa pagitan ng iyong mga request, gaya ng 30m, upang makabalik ang memory kapag tumigil ka sa pagtatrabaho.

Mag-unload agad ng model

ollama stop qwen3:8b

Wala itong ibinabalik na output, at nawawala ang model sa ollama ps. Kapag hindi naka-load ang pangalan, ibinabalik ang couldn't find model "qwen3:8b" to stop. Sa API, request ito na walang prompt at naka-set ang keep_alive sa 0:

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

May "done_reason": "unload" ang reply. Gamitin ito sa halip na i-restart ang service. Nagpapalaya rin ng memory ang systemctl restart ollama, pero inaalis nito ang lahat ng iba pang naka-load na model at tinatapos ang anumang request na kasalukuyang tumatakbo.

Pagpapatakbo ng higit sa isang model sa iisang server

OLLAMA_MAX_LOADED_MODELS ang naglilimita sa bilang ng mga model na sabay-sabay na nananatiling loaded, at noong August 2026, ang default ay tatlo bawat GPU, o tatlo sa isang CPU-only na server. Mga model ang binibilang ng limitasyong ito, pero memory ang tunay na hangganan. Kaya maaaring hindi mabigyan ng sapat na memory ang ikalawang malaking model bago pa umabot sa tatlo ang bilang.

Kapag may ni-request na bagong model at walang sapat na memory para rito, inaalis ng scheduler ang isa sa mga kasalukuyang loaded na model upang maglaan ng espasyo. Mas pipiliin nito ang model na walang aktibong request. Maaari rin nitong i-evict ang model na hindi pa nag-expire ang timer, kabilang ang model na na-load gamit ang -1. Kaya ang negatibong keep_alive ay nangangahulugang walang idle timeout. Hindi nito pini-pin ang weights upang hindi magamit sa request ng ibang model.

Naka-log ang desisyong ito sa debug level. Magdagdag ng ikalawang Environment="OLLAMA_DEBUG=1" line sa parehong drop-in, mag-restart, at mag-monitor:

sudo journalctl -u ollama -f

Kung may line tungkol sa pag-unload ng runner upang maglaan ng espasyo, at katabi ito ng request na nag-trigger sa pag-unload, ipinapakita nitong hindi kayang pagsabayin ng machine na ito ang dalawang model. Ang solusyon ay magpatakbo ng mas kaunting model sa server na ito, o magtakda ng mahabang window para sa model na kailangang mabilis sumagot at 0 para sa model na bihira mong tawagin.

Mga gabay na mananatiling kapaki-pakinabang kahit may bagong release

Madalas maglabas ng bagong build ang Ollama at nagbabago ang mga default nito, kaya suriin ang build na ginagamit mo sa halip na isaulo ang mga numero:

ollama --version
ollama serve --help

Inililista ng ollama serve --help ang mga environment variable na aktuwal na binabasa ng build, kabilang ang OLLAMA_KEEP_ALIVE. Dalawang tuntunin ang nanatili sa iba’t ibang release at ligtas gawing batayan. Mas pinapairal ng value sa request ang server default. At ang ollama ps ang tunay na batayan kung ano ang naka-load, anuman ang sinasabi ng config file na dapat itong i-load.

Kung editor o agent ang kumokontrol sa server mo, suriin muna kung ano ang ipinapadala ng client bago sisihin ang server. Sinasaklaw ng Pagkonekta ng coding agent sa sarili mong Ollama server kung saan nakalagay ang mga request setting na iyon.

FAQ

Bakit ina-unload ng Ollama ang model ko makalipas ang 5 minuto?

Ang 5 minuto ang default na keep_alive, ang idle timer na sinisimulan ng Ollama kapag natapos ang isang request. Kapag nag-expire ito, nililinis ng server ang weights. Kaya nire-reload ang mga ito mula sa disk sa susunod na request, at ang reload na iyon ang nagdudulot ng pause na nararanasan mo. Itaas ang value para sa isang request sa pamamagitan ng pagpapadala ng "keep_alive": "30m" sa JSON body, o para sa buong server gamit ang environment variable na OLLAMA_KEEP_ALIVE.

Paano ko papanatilihing naka-load sa memory ang isang Ollama model?

Gumamit ng negative value: "keep_alive": -1 sa request, o OLLAMA_KEEP_ALIVE=-1 para sa server. Ipinapakita naman ng ollama ps ang Forever sa column na UNTIL. Inaalis nito ang idle timer at wala nang iba. Kung may ibang model na nire-request at kulang ang memory, ia-unload pa rin ng scheduler ang model na ito upang makapaglaan ng espasyo.

Bakit hindi pinapansin ang OLLAMA_KEEP_ALIVE?

Suriin kung saan mo ito itinakda. Patakbuhin ang systemctl show ollama --property=Environment. Kung wala ang variable sa output na iyon, hindi ito nakita ng server dahil hindi nakakarating sa systemd service ang variable na in-export sa iyong shell. Itakda ito gamit ang sudo systemctl edit ollama.service, pagkatapos ay patakbuhin ang sudo systemctl daemon-reload at sudo systemctl restart ollama. Ang isa pang posibleng dahilan ay client na nagpapadala ng sarili nitong keep_alive sa request, na nag-o-override sa server default.

Paano ko lilinisin ang memory nang hindi nire-restart ang Ollama?

Inuuna ng ollama stop qwen3:8b ang pag-unload ng model na iyon at patuloy na tumatakbo ang server at ang iba pang naka-load na model. Sa API, magpadala ng request na walang prompt at may "keep_alive": 0. Ang response ay babalik na may "done_reason": "unload". Kumpirmahin gamit ang ollama ps; hindi na dapat nito ilista ang model.