Ollama model memory मध्ये कायम loaded कसे ठेवावे

Ollama काही मिनिटांनंतर model unload का करते?

शेवटची request पूर्ण झाल्यानंतर Ollama model पाच मिनिटे memory मध्ये loaded ठेवते आणि त्यानंतर तो मुक्त करते. पुढील request वेळी weights पुन्हा disk वरून वाचून RAM किंवा VRAM मध्ये map करावे लागतात. त्यामुळे पहिला token मिळण्यापूर्वी विलंब होतो. म्हणून chat UI किंवा coding agent सुरुवातीला जलद वाटतो, काही काळ शांत राहतो आणि पुढील message वर पुन्हा धीमा वाटतो. काहीही बिघडलेले नाही. idle timer ची मुदत संपलेली असते.

या timer ला keep_alive म्हणतात. तो प्रत्येक model साठी स्वतंत्र असतो आणि प्रत्येक request पूर्ण झाल्यावर पुन्हा सुरू होतो. सध्या request चे उत्तर देत असलेला model कधीही unload केला जात नाही, कारण active request नसलेल्या model चीच server कडून मुदत संपवली जाते. August 2026 पर्यंत default पाच मिनिटे आहे आणि या server कडून load केलेल्या प्रत्येक model ला तो लागू होतो.

keep_alive सेट करण्यासाठी दोन ठिकाणे आहेत: individual request मध्ये किंवा server default म्हणून. server default reboot नंतरही कायम ठेवण्यासाठी systemd drop-in वापरावा लागतो. या मार्गदर्शकात Ollama आधीपासून service म्हणून चालू आहे असे गृहीत धरले आहे. तसे नसल्यास VPS वर Ollama install करणे येथून सुरुवात करा आणि नंतर येथे परत या.

सध्या कोणते models memory मध्ये आहेत आणि ते कधी expire होतील?

ollama ps

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

रिकामा output म्हणजे काहीही load केलेले नाही. त्यामुळे पुढील request वेळी पूर्ण load करावा लागतो. PROCESSOR मधून weights कुठे ठेवले आहेत ते दिसते. 100% GPU आणि 100% CPU ही स्पष्ट प्रकरणे आहेत. 25%/75% CPU/GPU सारख्या split चा अर्थ model VRAM मध्ये बसला नाही. त्यामुळे त्याचा काही भाग processor वर चालतो आणि generation अधिक धीमे होते.

UNTIL हा countdown आहे. त्यात 4 minutes from now सारखी relative time दिसते. model negative keep_alive सह load केला असल्यास Forever दिसते. server model unload करत असतानाच्या अल्प कालावधीत Stopping... दिसते.

Releases नुसार column set बदललेला आहे. त्यामुळे script मध्ये fields मोजण्याऐवजी header वाचा. Automated कामांसाठी API ला विचारावे:

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

प्रत्येक entry मध्ये expires_at, 2026-08-09T14:38:31.83753Z सारखा absolute timestamp आणि size_vram असतो. size_vram मधून त्या model चा किती भाग GPU memory मध्ये आहे ते कळते. size_vram चे मूल्य 0 असल्यास model CPU वर चालत आहे.

प्रत्यक्ष reload साठी लागणारा वेळ

याचा अंदाज बांधू नका. Ollama प्रत्येक response मध्ये load time load_duration म्हणून 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}'

पहिल्या call मध्ये model load होते, त्यामुळे त्याचे load_duration मोठे असते. ते seconds मध्ये वाचण्यासाठी 1000000000 ने भागा. दुसरा call model memory मध्ये resident असताना चालतो आणि त्यात खूपच लहान संख्या दिसते. त्या दोन आकड्यांमधील फरक timer संपल्यानंतर प्रत्येक user ला सहन करावा लागणारा विलंब आहे. keep_alive बदलण्याचे हेच मुख्य कारण आहे. त्या pause च्या आधी आणि नंतरची generation speed पाहण्यासाठी तुमच्या स्वतःच्या box वर tokens per second कसे मोजायचे हे पहा.

एका विनंतीवर Ollama मॉडेल memory मध्ये loaded ठेवा

विनंतीसोबत keep_alive पाठवा. विनंती पूर्ण झाल्यापासून ते त्या मॉडेलवर लागू होते.

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

चार मूल्यरूपे स्वीकारली जातात:

• duration string: "30m", "24h", "90s"
• seconds म्हणून वाचला जाणारा साधा number: 3600
• negative value, -1 किंवा "-1m"; याचा अर्थ idle timeout अजिबात नाही
• 0; याचा अर्थ ही विनंती पूर्ण होताच मॉडेल unload करणे

विनंतीवरील मूल्य server default ला दोन्ही दिशांनी override करते. याचे महत्त्व अपेक्षेपेक्षा अधिक आहे: client ने स्वतःचा keep_alive पाठवला, तर server वर configure केलेल्या कोणत्याही मूल्यापेक्षा तो प्राधान्याने लागू होतो.

काहीही generate न करताही तुम्ही मॉडेल load करू शकता. फक्त मॉडेलचे नाव पाठवा. server ते load करतो आणि "done": true असलेला रिकामा response परत करतो.

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

रीबूटनंतर किंवा नवीन मॉडेल pull केल्यानंतर चालवायची हीच command आहे. त्यामुळे पहिल्या प्रत्यक्ष user request साठी मॉडेल load होण्याचा अतिरिक्त वेळ लागत नाही. CLI मध्ये flag वापरून तेच काम करता येते:

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

OLLAMA_KEEP_ALIVE वापरून ते default म्हणून लागू ठेवा

सर्व्हर सुरू होताना OLLAMA_KEEP_ALIVE वाचतो आणि स्वतःचे मूल्य नसलेल्या प्रत्येक मॉडेलसाठी ते वापरतो. यामध्ये request field प्रमाणेच स्वरूपे वापरता येतात. त्यामुळे 30m, 3600 आणि -1 ही सर्व कार्य करतात.

मात्र हे कोणत्या environment मध्ये सेट केले आहे, हे महत्त्वाचे आहे. तुमच्या SSH session मध्ये export OLLAMA_KEEP_ALIVE=30m चालवून उपयोग होत नाही, कारण package द्वारे केलेली installation सर्व्हरला स्वतंत्र user आणि स्वतंत्र environment असलेल्या systemd service म्हणून चालवते. तुमचा login shell आणि ती service यांचा परस्पर संबंध नसतो. हे setting दुर्लक्षित होत असल्याचे दिसण्याचे सर्वात सामान्य कारण आहे.

systemd drop-in वापरून ही सेटिंग restart नंतरही कायम ठेवा

sudo systemctl edit ollama.service

Editor मध्ये दोन comment markers दिसतील. त्यांच्यामध्ये मजकूर लिहा: दुसऱ्या marker नंतर लिहिलेली कोणतीही माहिती systemd दुर्लक्षित करते.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Save केल्यावर /etc/systemd/system/ollama.service.d/override.conf लिहिले जाते. हा shipped unit मध्ये केलेला बदल नसून drop-in आहे. त्यामुळे Ollama package upgrade मुळे ollama.service बदलले तरी तुमची setting कायम राहते. Drop-in आणि unit files तुमच्यासाठी नवीन असल्यास, systemd service आणि timer मार्गदर्शक त्यांची कार्यपद्धती स्पष्ट करते.

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

शेवटची command service प्रत्यक्षात कोणत्या environment मध्ये चालेल ते दाखवते. त्या output मध्ये OLLAMA_KEEP_ALIVE=30m नसल्यास drop-in लागू झालेला नाही. याचे कारण बहुतेक वेळा [Service] header नसणे किंवा marker नंतरच्या ओळी चुकीच्या ठिकाणी लिहिणे असते. Restart केल्यावर loaded models हटवले जातात. त्यामुळे पुढील request वेळी model पुन्हा load होतो. वरील preload call वापरून तो आधीच warm करा.

मॉडेल resident ठेवण्याचा खर्च

ollama ps मधील SIZE स्तंभ संपूर्ण idle window दरम्यान राखून ठेवलेली memory दर्शवतो. ती केवळ request चालू असतानाची memory नाही. 4-bit quantisation असलेले 8B मॉडेल साधारण 5 ते 6 GB memory वापरते. 27B मॉडेलसाठी परिस्थिती वेगळी आहे. त्यामुळे ते resident ठेवण्याचा निर्णय घेण्यापूर्वी CPU-only VPS वर एक मॉडेल चालवण्यासाठी लागणाऱ्या memory चे गणित समजून घेणे उपयुक्त ठरते. keep_alive ला -1 सेट केल्यास, त्या box वरील इतर सर्व गोष्टींपेक्षा मॉडेलला कायमस्वरूपी प्राधान्य देण्याचा निर्णय घेतला जातो. लहान VPS वर याचा थेट परिणाम तुमच्या database, web app आणि build jobs वर होतो.

अंदाजावर विश्वास ठेवण्याऐवजी प्रत्यक्ष आकडे तपासा. मॉडेल load असताना ही command चालवा. त्यानंतर ollama stop झाल्यावर ती पुन्हा चालवा:

free -h

available स्तंभ नवीन process ला kernel अजून देऊ शकणारी memory दर्शवतो. NVIDIA GPU box वर nvidia-smi VRAM मधील हीच परिस्थिती दाखवतो. Box मधील memory संपल्यास kernel memory परत मिळवण्यासाठी एखादा process बंद करतो:

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

एखाद्या ओळीत ollama चे नाव असल्यास model server बंद केलेला असतो. ओळीत तुमच्या database चे नाव असल्यास मॉडेल जिंकले आणि तुमच्यासाठी महत्त्वाची गोष्ट बंद झाली. दोन्ही परिणाम एकाच निर्णयामुळे होतात: headroom नसलेल्या box वर दीर्घ keep-alive window ठेवणे.

इथे दोन खर्च सहज लक्षात येत नाहीत. मोठी context length मोठा KV cache राखून ठेवते. KV cache म्हणजे key value cache; मॉडेल generate करत असताना राखून ठेवलेली प्रत्येक token साठीची attention state. हा cache resident size चाच भाग असतो. OLLAMA_NUM_PARALLEL 1 पेक्षा मोठे असल्यास प्रत्येक parallel slot साठी हा cache स्वतंत्रपणे राखून ठेवला जातो. एका मॉडेलमधून अनेक लोकांना सेवा देण्याचा विचार असल्यास memory चे sizing केवळ weights साठी नव्हे, तर slots साठी करा.

व्यवहार्य default असा आहे: headroom असलेल्या box वर एक मॉडेल -1 वापरू शकते. Shared box वर तुमच्या requests मधील अंतर व्यापणारी window वापरा, उदाहरणार्थ 30m. त्यामुळे तुम्ही काम थांबवल्यावर memory पुन्हा उपलब्ध होते.

मॉडेल त्वरित memory मधून काढा

ollama stop qwen3:8b

यावर कोणतेही output न देता response मिळतो आणि मॉडेल ollama ps मधून नाहीसे होते. Load केलेले नसलेले नाव दिल्यास couldn't find model "qwen3:8b" to stop मिळते. API स्वरूपात prompt नसलेली request पाठवावी आणि keep_alive ची किंमत 0 ठेवावी:

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

Response मध्ये "done_reason": "unload" असते. Service restart करण्याऐवजी हे वापरा. systemctl restart ollama मुळे memory देखील मोकळी होते; मात्र इतर सर्व loaded models काढले जातात आणि सुरू असलेली प्रत्येक request थांबवली जाते.

एका सर्व्हरवर एकापेक्षा जास्त models चालवणे

OLLAMA_MAX_LOADED_MODELS एकाच वेळी किती models loaded राहू शकतात यावर मर्यादा घालते. August 2026 पर्यंत GPU असलेल्या प्रत्येक मशीनसाठी ही default मर्यादा three आहे. फक्त CPU असलेल्या मशीनसाठीही ती three आहे. ही मर्यादा models ची संख्या मोजते. मात्र खरी मर्यादा memory ची असते. त्यामुळे three पर्यंत पोहोचण्यापूर्वीच दुसऱ्या मोठ्या model साठी पुरेशी memory उपलब्ध नसल्याने तो नाकारला जाऊ शकतो.

नवीन model ची विनंती आली आणि त्यासाठी पुरेशी memory उपलब्ध नसेल, तर scheduler जागा करण्यासाठी resident models पैकी एक unload करतो. तो active request नसलेला model प्राधान्याने निवडतो. -1 वापरून loaded केलेल्या model चा timer अद्याप संपलेला नसला तरी तो model evict केला जाऊ शकतो. त्यामुळे negative keep_alive म्हणजे idle timeout नाही. दुसऱ्या model ची request आल्यावर weights memory मध्ये कायम ठेवली जात नाहीत.

हा निर्णय debug level वर log केला जातो. त्याच drop-in मध्ये दुसरी Environment="OLLAMA_DEBUG=1" line जोडा, सेवा restart करा आणि खालीलप्रमाणे log monitor करा:

sudo journalctl -u ollama -f

ज्या request मुळे ही प्रक्रिया सुरू झाली, तिच्या जवळच runner unload करून जागा करण्याबाबतची line दिसत असेल, तर हे दोन models या मशीनवर एकत्र बसत नाहीत. उपाय म्हणजे या मशीनवर models ची संख्या कमी करणे. तसेच पटकन उत्तर देणे आवश्यक असलेल्या model साठी मोठी window आणि क्वचित वापरत असलेल्या model साठी 0 ठेवणे हा दुसरा उपाय आहे.

पुढील release नंतरही लागू राहणारे मार्गदर्शन

Ollama वारंवार release होते आणि त्याची default settings बदलतात. त्यामुळे आकडे पाठ करण्याऐवजी तुमच्यासमोरील build तपासा:

ollama --version
ollama serve --help

ollama serve --help त्या build द्वारे प्रत्यक्षात वाचल्या जाणाऱ्या environment variables ची यादी देते. त्यात OLLAMA_KEEP_ALIVE देखील आहे. दोन नियम releases मध्ये कायम लागू राहिले आहेत आणि त्यांवर सुरक्षितपणे आधारित configuration करता येते. Request मधील value ही server default पेक्षा प्राधान्याने लागू होते. तसेच कोणतेही config file काय अपेक्षित आहे असे सांगत असले तरी प्रत्यक्षात काय load झाले आहे याचे सत्य ollama ps मध्ये दिसते.

एखादा editor किंवा agent तुमचा server नियंत्रित करत असल्यास server ला दोष देण्यापूर्वी तो client काय पाठवतो ते तपासा. तुमच्या स्वतःच्या Ollama server कडे coding agent निर्देशित करणे या लेखात त्या request settings कुठे असतात हे स्पष्ट केले आहे.

FAQ

Ollama 5 मिनिटांनंतर माझे model unload का करते?

पाच मिनिटे हा default keep_alive आहे. Request पूर्ण झाल्यावर Ollama सुरू करणारा हा idle timer आहे. Timer संपल्यावर server weights मुक्त करतो. त्यामुळे पुढील request मध्ये ते disk वरून पुन्हा load होतात. या reload मुळे जाणवणारा pause निर्माण होतो. एका request साठी हा कालावधी वाढवण्यासाठी JSON body मध्ये "keep_alive": "30m" पाठवा. संपूर्ण server साठी OLLAMA_KEEP_ALIVE environment variable वापरा.

Ollama चे model memory मध्ये कायम loaded कसे ठेवायचे?

Negative value वापरा: request मध्ये "keep_alive": -1 किंवा server साठी OLLAMA_KEEP_ALIVE=-1. त्यानंतर ollama ps च्या UNTIL column मध्ये Forever दिसते. यामुळे idle timer काढला जातो. इतर कोणताही बदल होत नाही. दुसरे model मागितले असता memory कमी पडल्यास scheduler जागा करण्यासाठी हे model तरीही unload करतो.

OLLAMA_KEEP_ALIVE दुर्लक्षित का केले जाते?

हे variable कुठे set केले आहे ते तपासा. systemctl show ollama --property=Environment चालवा. त्या output मध्ये variable नसेल, तर server ला ते कधीच मिळालेले नाही. कारण तुमच्या shell मध्ये export केलेले variable systemd service पर्यंत पोहोचत नाही. sudo systemctl edit ollama.service वापरून ते set करा. त्यानंतर sudo systemctl daemon-reload आणि sudo systemctl restart ollama चालवा. दुसरे कारण असे असू शकते की client request मध्ये स्वतःचे keep_alive पाठवत आहे. त्यामुळे server default override होते.

Ollama restart न करता memory कशी मुक्त करायची?

ollama stop qwen3:8b त्या एकाच model ला त्वरित unload करते. Server आणि इतर सर्व loaded models सुरू राहतात. API द्वारे prompt शिवाय आणि "keep_alive": 0 सह request पाठवा. Reply मध्ये "done_reason": "unload" येते. ollama ps वापरून पडताळा करा. त्यात हे model यापुढे सूचीबद्ध नसावे.