Paano Panatilihing Loaded ang Ollama Model sa Memory

Bakit ina-unload ni Ollama ang model pagkalipas ng ilang minuto?

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

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

May dalawang lugar kung saan maaaring i-set ang keep_alive: sa indibidwal na request o bilang default ng server. Ang systemd drop-in ang nagpapanatili sa default ng server kahit mag-restart ito. Ipinapalagay ng guide 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.

Aling mga modelo 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

Ibig sabihin ng walang output ay walang naka-load, kaya kailangan ng susunod na request na maghintay sa buong proseso ng pag-load. Ipinapakita ng PROCESSOR kung saan napunta ang weights. Malinaw na ipinapakita ng 100% GPU at 100% CPU ang ganitong sitwasyon. Ang split gaya ng 25%/75% CPU/GPU ay nangangahulugang hindi nagkasya ang modelo 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 modelo gamit ang negatibong keep_alive. Nagpi-print ito ng Stopping... sa maikling pagitan habang inaalis ng server ang modelo sa memory.

Nagbago ang mga column sa pagitan ng mga release, kaya basahin ang header sa halip na bilangin ang mga field sa isang script. Para sa anumang automation, gamitin ang API:

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

May expires_at ang bawat entry, na isang absolute timestamp gaya ng 2026-08-09T14:38:31.83753Z, at size_vram, na nagsasaad kung gaano kalaking bahagi ng modelong iyon ang nasa GPU memory. Ang size_vram na 0 ay nangangahulugang tumatakbo ang modelo sa CPU.

Aktuwal na halaga 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 nasa memorya pa ang model at nag-uulat ng mas maliit na value. Ang agwat ng dalawang value na ito ang kailangang tiisin ng bawat user kapag nag-expire na ang timer. Ito ang buong dahilan kung bakit kailangang baguhin ang keep_alive. Karamihan sa agwat na ito ay disk read. Kaya kung inilipat mo ang model directory sa pangalawang volume, ang speed ng volume na iyon ang nagtatakda ng pinakamababang oras sa bawat cold load. Para sa generation speed bago at pagkatapos ng pause na iyon, tingnan ang 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 mga segundo: 3600
• negatibong value, -1 o "-1m", na nangangahulugang walang idle timeout
• 0, na nangangahulugang i-unload ang model kaagad matapos ang request

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

Maaari ka ring mag-load ng model nang walang pag-generate ng anuman. Ipadala lamang ang pangalan ng model. Ilo-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 na 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"

Panatilihin itong 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 ang format nito sa request field, kaya gumagana ang 30m, 3600, at -1.

Ang mahalaga ay kung saang 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 environment. Hindi nagkakaroon ng ugnayan ang iyong login shell at ang service na iyon. Ito ang pinakakaraniwang dahilan kung bakit mukhang hindi gumagana ang setting.

Gawin itong manatili pagkatapos ng restart gamit ang systemd drop-in

sudo systemctl edit ollama.service

Binubuksan ng editor ang file 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"

Isinusulat ng pag-save ang /etc/systemd/system/ollama.service.d/override.conf. Drop-in ito sa halip na direktang pag-edit ng shipped unit, kaya hindi naaapektuhan 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

Inililista 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 nai-type sa ibaba ng marker. Inaalis ng restart ang lahat ng naka-load na model, kaya cold load ang susunod na request. Gamitin ang preload call sa itaas upang i-warm up ito.

Magkano ang gastos sa pagpapanatiling naka-load ng 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, kaya makabubuting suriin muna ang memory arithmetic para sa pagpapatakbo nito sa CPU-only VPS bago magpasiyang panatilihin itong naka-load. Kapag itinakda mo ang keep_alive sa -1, pinili mong unahin ang model kaysa sa lahat ng iba pang workload sa server, nang permanente. Sa maliit na VPS, direktang kapalit nito ang memory na kailangan ng 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 ilaan 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, papatayin ng kernel ang isang process upang makabawi:

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

Kapag binanggit ng isang line ang ollama, ang model server ang pinatay. Kapag database mo ang binanggit, nanalo ang model at natalo ang isang mahalagang serbisyo. Pareho itong resulta ng iisang desisyon: mahabang keep-alive window sa isang box na walang sapat na headroom.

May dalawang gastos dito na madaling hindi mapansin. Kapag mas mahaba ang context length, mas malaking KV cache ang nireserba. Ang KV cache (key value cache) ay ang per-token attention state na pinananatili ng model habang nagge-generate. Bahagi ng resident size ang cache na ito. Nakadepende ang laki nito sa num_ctx, kaya ang pagtaas ng context window ay nagpapalaki sa memory na ginagamit ng resident model sa buong idle period, hindi lamang habang sumasagot ito. Ang OLLAMA_NUM_PARALLEL na higit sa 1 ay nagrereserba ng cache para sa bawat parallel slot. Kung plano mong mag-serve ng ilang user mula sa iisang model, i-size ang memory batay sa mga slot, hindi lamang sa weights.

Makatuwirang default ang sumusunod: 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 maibalik ang memory kapag tapos ka nang magtrabaho.

I-unload agad ang isang model

ollama stop qwen3:8b

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

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

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

Pagpapatakbo ng higit sa isang model sa iisang server

Nililimitahan ng OLLAMA_MAX_LOADED_MODELS kung ilang model ang maaaring manatiling naka-load nang sabay-sabay. Noong August 2026, ang default ay tatlo bawat GPU, o tatlo sa CPU-only na machine. Bilang ng mga model ang nililimitahan nito, pero memory ang tunay na limitasyon. Kaya maaaring hindi pagbigyan ang pangalawang malaking model dahil wala nang sapat na memory, kahit hindi pa umaabot sa tatlo ang bilang.

Kapag may hiniling na bagong model at walang sapat na memory para rito, nag-uunload ang scheduler ng isa sa mga kasalukuyang model upang maglaan ng espasyo. Mas pinipili nito ang model na walang aktibong request. Maaari rin nitong i-evict ang model na hindi pa nag-e-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 para sa request ng ibang model.

Nila-log ang desisyong iyon sa debug level. Magdagdag ng pangalawang 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 nito ang request na nag-trigger sa pag-unload, hindi sapat ang memory ng machine na ito para sa dalawang model na iyon nang sabay. Ang solusyon ay bawasan ang mga 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 tawagan.

Mga gabay na mananatiling kapaki-pakinabang lampas sa susunod na release

Madalas mag-release ang Ollama at nagbabago ang mga default nito, kaya suriin ang build na nasa harap 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 na iyon, kabilang ang OLLAMA_KEEP_ALIVE. May dalawang panuntunang nanatiling pareho sa iba’t ibang release at ligtas gawing batayan. Mas nangingibabaw ang value sa request kaysa sa default ng server. At ang ollama ps ang nagsasabi kung ano ang aktuwal na naka-load, anuman ang nakasaad na dapat i-load sa config file.

Kung editor o agent ang kumokontrol sa server mo, tingnan muna kung ano ang ipinapadala ng client bago sisihin ang server. Saklaw ng Pagtutok ng coding agent sa sarili mong Ollama server kung saan matatagpuan ang mga setting na iyon ng request.

FAQ

Bakit ina-unload ng Ollama ang model ko pagkalipas ng 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 pause na nararanasan mo. Itaas ito 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 mapapanatiling naka-load sa memory ang isang Ollama model?

Gumamit ng negatibong 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 ni-request at kulang ang memory, ia-unload pa rin ng scheduler ang model na ito upang maglaan ng espasyo.

Bakit hindi gumagana 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 umaabot sa systemd service ang variable na in-export sa 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 dahilan ay client na nagpapadala ng sarili nitong keep_alive sa request, na nag-o-override sa default ng server.

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

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