Ollama मॉडेल मेमरीमध्ये कायम कसे ठेवावे?

Ollama काही मिनिटांनंतर मॉडेल अनलोड का करते?

Ollama शेवटच्या विनंतीनंतर पाच मिनिटांपर्यंत मॉडेल मेमरीमध्ये लोड करून ठेवते आणि त्यानंतर ते मोकळे करते. पुढील विनंती आल्यावर, सिस्टिमला पुन्हा डिस्कवरून वेट्स (weights) वाचावे लागतात आणि ते RAM किंवा VRAM मध्ये मॅप करावे लागतात, त्यामुळे पहिला टोकन येण्यापूर्वी विलंब होतो. म्हणूनच चॅट UI किंवा कोडिंग एजंट सुरुवातीला वेगवान वाटतात, काही काळ शांत राहतात आणि पुढच्या मेसेजवर पुन्हा संथ वाटतात. यात काहीही बिघडलेले नाही. आयडल टायमर (idle timer) संपलेला असतो.

या टायमरला keep_alive म्हणतात. हे प्रत्येक मॉडेलसाठी स्वतंत्र असते आणि प्रत्येक विनंती पूर्ण झाल्यावर ते पुन्हा सुरू होते. जे मॉडेल सध्या विनंतीचे उत्तर देत आहे, ते कधीही अनलोड केले जात नाही, कारण सर्व्हर फक्त अशाच मॉडेलचा टायमर संपवतो ज्यावर कोणतीही सक्रिय विनंती नाही. ऑगस्ट 2026 पर्यंत, डीफॉल्ट वेळ पाच मिनिटे आहे आणि ती या सर्व्हरवर लोड होणाऱ्या प्रत्येक मॉडेलला लागू होते.

keep_alive सेट करण्यासाठी दोन ठिकाणे आहेत: वैयक्तिक विनंतीवर किंवा सर्व्हर डीफॉल्ट म्हणून. systemd ड्रॉप-इन फाईलमुळे सर्व्हरचे डीफॉल्ट सेटिंग रीस्टार्टनंतरही टिकून राहते. हे मार्गदर्शक असे गृहीत धरते की Ollama आधीच एक सर्व्हिस म्हणून सुरू आहे. जर नसेल, तर VPS वर Ollama इन्स्टॉल करणे पासून सुरुवात करा आणि त्यानंतर परत या.

सध्या कोणते मॉडेल्स मेमरीमध्ये आहेत आणि त्यांची मुदत कधी संपेल?

ollama ps

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

रिकामे आउटपुट म्हणजे कोणतेही मॉडेल लोड केलेले नाही, त्यामुळे पुढील विनंतीसाठी पूर्ण लोड वेळ लागेल. PROCESSOR तुम्हाला वेट्स (weights) कुठे साठवले आहेत हे सांगते. 100% GPU आणि 100% CPU हे स्पष्ट प्रकार आहेत. 25%/75% CPU/GPU सारखी विभागणी म्हणजे मॉडेल VRAM मध्ये पूर्णपणे मावले नाही, त्यामुळे त्याचा काही भाग प्रोसेसरवर चालतो आणि जनरेशनचा वेग मंदावतो.

UNTIL हा काउंटडाउन आहे आणि तो 4 minutes from now सारखा सापेक्ष वेळ दर्शवतो. जेव्हा मॉडेल नकारात्मक keep_alive सह लोड केले जाते, तेव्हा तो Forever दर्शवतो. सर्व्हर अनलोड होत असतानाच्या कमी कालावधीत तो Stopping... दर्शवतो.

रिलीजनुसार कॉलमचा संच बदलला आहे, त्यामुळे स्क्रिप्टमध्ये फील्ड्स मोजण्याऐवजी हेडर वाचा. कोणत्याही स्वयंचलित प्रक्रियेसाठी, API ला विचारा:

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

प्रत्येक नोंदीमध्ये expires_at, 2026-08-09T14:38:31.83753Z सारखा एक निरपेक्ष टाइमस्टॅम्प आणि size_vram, म्हणजेच GPU मेमरीमध्ये असलेल्या मॉडेलचा भाग, यांचा समावेश असतो. size_vram चे मूल्य 0 असणे म्हणजे मॉडेल CPU वर चालत आहे.

रीलोडचा प्रत्यक्ष खर्च काय आहे

याबाबत अंदाज लावू नका. Ollama प्रत्येक प्रतिसादात लोड होण्यासाठी लागणारा वेळ load_duration मध्ये, नॅनोसेकंदमध्ये दर्शवते.

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

पहिली कॉल मॉडेल लोड करते, म्हणून तिचा load_duration मोठा असतो. सेकंदात वाचण्यासाठी त्याला 1000000000 ने भागा. दुसरी कॉल मॉडेल मेमरीमध्ये असताना चालते आणि ती खूप लहान संख्या दर्शवते. टायमर संपल्यानंतर प्रत्येक वापरकर्त्याला जो वेळ द्यावा लागतो, तो या दोन आकड्यांमधील फरक आहे आणि हेच keep_alive बदलण्याचे मुख्य कारण आहे. या फरकाचा मोठा भाग डिस्क रीडचा असतो, त्यामुळे जर तुम्ही मॉडेल डिरेक्टरी दुसऱ्या व्हॉल्यूमवर हलवली असेल, तर त्या व्हॉल्यूमचा वेग प्रत्येक कोल्ड लोडची किमान मर्यादा ठरवतो. त्या पॉजच्या दोन्ही बाजूंच्या जनरेशन वेगासाठी, तुमच्या स्वतःच्या मशीनवर टोकन्स प्रति सेकंद कसे मोजावेत हे पहा.

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

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

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

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

• कालावधी दर्शवणारी स्ट्रिंग: "30m", "24h", "90s"
• एक साधी संख्या, जी सेकंद म्हणून वाचली जाते: 3600
• ऋण मूल्य, -1 किंवा "-1m", ज्याचा अर्थ असा की कोणताही आयडल टाइमआउट (idle timeout) नसेल
• 0, ज्याचा अर्थ असा की ही विनंती पूर्ण होताच मॉडेल अनलोड करा

विनंतीवर दिलेले मूल्य सर्व्हरच्या डीफॉल्ट मूल्याला ओव्हरराइड करते, दोन्ही दिशांनी. हे ऐकण्यापेक्षा अधिक महत्त्वाचे आहे: क्लायंटने स्वतःचे keep_alive पाठवल्यास, सर्व्हरवर तुम्ही कॉन्फिगर केलेल्या कोणत्याही सेटिंगपेक्षा तेच ग्राह्य धरले जाते.

तुम्ही काहीही जनरेट न करताही मॉडेल लोड करू शकता. फक्त मॉडेलचे नाव पाठवा. सर्व्हर ते लोड करतो आणि "done": true सह रिकामी प्रतिक्रिया देतो.

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

रीबूटनंतर किंवा नवीन मॉडेल पुल (pull) केल्यानंतर चालवण्यासाठी ही कमांड आहे, जेणेकरून पहिल्या खऱ्या वापरकर्त्याच्या विनंतीला लोड होण्यासाठी प्रतीक्षा करावी लागणार नाही. CLI देखील एका फ्लॅगद्वारे हेच काम करते:

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

OLLAMA_KEEP_ALIVE वापरून सर्व्हरवर मॉडेल लोड ठेवा

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

येथे मुख्य अडचण ही आहे की हे environment variable नेमके कुठे सेट करायचे. तुमच्या SSH सेशनमध्ये export OLLAMA_KEEP_ALIVE=30m चालवल्याने काहीही फरक पडत नाही, कारण पॅकेज्ड इन्स्टॉलमध्ये सर्व्हर हा एक systemd सर्व्हिस म्हणून त्याच्या स्वतःच्या युजर आणि environment अंतर्गत चालतो. तुमचे लॉगिन शेल आणि ती सर्व्हिस यांचा एकमेकांशी संबंध नसतो. ही सेटिंग दुर्लक्षित केल्यासारखी वाटण्याचे हे सर्वात सामान्य कारण आहे.

systemd drop-in वापरून रीबूटनंतरही सेवा सुरू ठेवणे

sudo systemctl edit ollama.service

एडिटर दोन कमेंट मार्कर्ससह उघडेल. त्या दोन मार्कर्सच्या मध्ये मजकूर लिहा: दुसऱ्या मार्करच्या खाली लिहिलेला कोणताही मजकूर systemd द्वारे दुर्लक्षित केला जातो.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

सेव्ह केल्यावर /etc/systemd/system/ollama.service.d/override.conf फाईल तयार होते. हे मूळ युनिट फाईलमध्ये बदल करण्याऐवजी एक ड्रॉप-इन (drop-in) आहे, त्यामुळे जेव्हा Ollama पॅकेज अपग्रेड होऊन ollama.service फाईल रिप्लेस करते, तेव्हा तुमचे सेटिंग सुरक्षित राहते. जर तुम्हाला ड्रॉप-इन्स आणि युनिट फाईल्स नवीन असतील, तर systemd service and timer guide मध्ये याची सविस्तर माहिती दिली आहे.

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

शेवटची कमांड ती एनवायरमेंट प्रिंट करते ज्यामध्ये सर्व्हिस प्रत्यक्षात रन होईल. जर त्या ओळीत OLLAMA_KEEP_ALIVE=30m नसेल, तर ड्रॉप-इन लागू झालेला नाही. याचे मुख्य कारण सहसा [Service] हेडर गहाळ असणे किंवा मार्कर्सच्या खाली ओळी लिहिणे हे असते. रीबूटमुळे सर्व लोड केलेले मॉडेल्स मेमरीमधून निघून जातात, त्यामुळे पुढची विनंती 'कोल्ड लोड' (cold load) असेल. वरील प्रीलोड कॉल वापरून सर्व्हिस 'वॉर्म अप' (warm up) करा.

मॉडेल मेमरीमध्ये कायम ठेवण्याचे परिणाम

ollama ps मधील SIZE कॉलम म्हणजे केवळ विनंती (request) प्रक्रिया होत असतानाच नव्हे, तर संपूर्ण आयडल विंडो (idle window) दरम्यान व्यापलेली मेमरी होय. 4-bit क्वांटायझेशनसह 8B मॉडेल साधारणपणे 5 ते 6 GB मेमरी घेते. 27B मॉडेलची बाब वेगळी आहे आणि केवळ CPU असलेल्या VPS वर ते चालवण्यासाठी लागणारे मेमरी गणित समजून घेणे आवश्यक आहे, त्याआधी ते मेमरीमध्ये कायम ठेवण्याचा निर्णय घेऊ नका. जर तुम्ही keep_alive हे -1 वर सेट केले, तर याचा अर्थ असा की सर्व्हरवरील इतर सर्व गोष्टींपेक्षा मॉडेलला प्राधान्य दिले गेले आहे. लहान VPS वर, हा निर्णय थेट तुमच्या डेटाबेस, वेब ॲप आणि बिल्ड जॉब्सच्या कार्यक्षमतेवर परिणाम करतो.

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

free -h

available कॉलम म्हणजे अशी मेमरी जी कर्नल अजूनही नवीन प्रोसेसला देऊ शकते. NVIDIA GPU असलेल्या सर्व्हरवर, nvidia-smi मध्ये VRAM बाबत अशीच माहिती दिसते. जर सर्व्हरची मेमरी संपली, तर मेमरी रिकव्हर करण्यासाठी कर्नल एखादी प्रोसेस बंद (kill) करते:

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

जर ओळीमध्ये ollama चे नाव असेल, तर मॉडेल सर्व्हर बंद झाला आहे. जर ओळीमध्ये तुमच्या डेटाबेसचे नाव असेल, तर मॉडेलने मेमरी जिंकली आहे आणि तुमच्या महत्त्वाच्या प्रोसेसचा बळी गेला आहे. दोन्ही परिणाम एकाच निर्णयामुळे मिळतात: पुरेशी जागा नसताना सर्व्हरवर लांब 'कीप-अलाईव्ह' (keep-alive) विंडो ठेवणे.

येथे दोन खर्च दुर्लक्षित होणे सोपे आहे. लांब कॉन्टेक्स्ट लेंथ (context length) मुळे मोठी KV कॅशे (key value cache, मॉडेल जनरेट करताना प्रत्येक टोकनची अटेंशन स्टेट साठवते) रिझर्व्ह केली जाते आणि ही कॅशे मॉडेलच्या एकूण मेमरीचा भाग असते. ती किती मोठी असेल हे num_ctx वरून ठरते, त्यामुळे कॉन्टेक्स्ट विंडो वाढवणे म्हणजे मॉडेल केवळ उत्तर देत असतानाच नव्हे, तर संपूर्ण आयडल कालावधीत जास्त मेमरी व्यापून ठेवणे होय. 1 पेक्षा जास्त OLLAMA_NUM_PARALLEL प्रत्येक पॅरलल स्लॉटसाठी ती कॅशे रिझर्व्ह करते. जर तुम्ही एकाच मॉडेलवरून अनेक वापरकर्त्यांना सेवा देण्याचे नियोजन करत असाल, तर मेमरीचा आकार केवळ वेट्स (weights) साठी नाही, तर स्लॉट्ससाठी मोजा.

एक योग्य डिफॉल्ट: पुरेशी जागा असलेल्या सर्व्हरवर एक मॉडेल -1 वापरू शकते. शेअर केलेल्या सर्व्हरवर अशी विंडो असावी जी तुमच्या विनंत्यांच्या मधील अंतर कव्हर करेल, जसे की 30m, जेणेकरून काम थांबवल्यावर मेमरी पुन्हा मोकळी होईल.

मॉडेल त्वरित अनलोड करा

ollama stop qwen3:8b

हे कमांड कोणतीही आउटपुट न देता पूर्ण होते आणि मॉडेल ollama ps मधून निघून जाते. जर एखादे नाव लोड केलेले नसेल, तर ते couldn't find model "qwen3:8b" to stop देते. API फॉरमॅटमध्ये प्रॉम्प्टशिवाय विनंती केली जाते आणि keep_alive हे 0 वर सेट केले जाते:

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

या उत्तरामध्ये "done_reason": "unload" असते. सर्व्हिस रीस्टार्ट करण्याऐवजी याचा वापर करा. systemctl restart ollama देखील मेमरी मोकळी करते, परंतु ते इतर सर्व लोड केलेली मॉडेल्स काढून टाकते आणि चालू असलेल्या सर्व विनंत्या थांबवते.

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

OLLAMA_MAX_LOADED_MODELS एका वेळी किती मॉडेल्स लोड राहू शकतात याची मर्यादा ठरवते. ऑगस्ट 2026 पर्यंत, प्रति GPU तीन मॉडेल्स किंवा CPU-ओन्ली मशीनवर तीन मॉडेल्स ही डीफॉल्ट मर्यादा आहे. ही मर्यादा मॉडेल्सच्या संख्येवर आधारित आहे, परंतु प्रत्यक्ष मर्यादा मेमरीची असते. त्यामुळे, तीन मॉडेल्सची मर्यादा गाठण्यापूर्वीच दुसऱ्या मोठ्या मॉडेलला मेमरीच्या कमतरतेमुळे नाकारले जाऊ शकते.

जेव्हा नवीन मॉडेलची विनंती केली जाते आणि त्यासाठी पुरेशी मेमरी नसते, तेव्हा शेड्युलर जागा निर्माण करण्यासाठी आधीपासून लोड असलेल्या मॉडेल्सपैकी एक अनलोड करतो. ज्या मॉडेलसाठी कोणतीही सक्रिय विनंती नाही, त्याला प्राधान्य दिले जाते. ज्या मॉडेलचा टाइमर संपलेला नाही, त्यालाही शेड्युलर काढून टाकू शकतो, ज्यामध्ये -1 ने लोड केलेले मॉडेलही समाविष्ट आहे. त्यामुळे, keep_alive चे नकारात्मक मूल्य म्हणजे कोणताही आयडल टाइमआउट नाही. हे वेट्स (weights) दुसऱ्या मॉडेलच्या विनंतीविरुद्ध पिन (pin) करत नाही.

हा निर्णय डीबग लेव्हलवर लॉग केला जातो. त्याच ड्रॉप-इन फाईलमध्ये दुसरी Environment="OLLAMA_DEBUG=1" ओळ जोडा, सर्व्हिस रीस्टार्ट करा आणि खालीलप्रमाणे तपासा:

sudo journalctl -u ollama -f

जागा निर्माण करण्यासाठी रनर अनलोड करण्याबद्दलची ओळ, जी ती विनंती ट्रिगर करणाऱ्या विनंतीच्या शेजारी दिसते, ती तुम्हाला सांगते की ही दोन मॉडेल्स या मशीनवर एकत्र बसत नाहीत. यावर उपाय म्हणजे या मशीनवर मॉडेल्सची संख्या कमी करणे, किंवा ज्या मॉडेलला जलद प्रतिसाद देणे आवश्यक आहे त्यासाठी मोठा विंडो कालावधी ठेवणे आणि ज्या मॉडेलला तुम्ही क्वचितच कॉल करता त्यासाठी 0 वापरणे.

पुढील रिलीजच्या पलीकडे टिकणारे मार्गदर्शन

Ollama वारंवार रिलीज केले जाते आणि त्याचे डीफॉल्ट बदलत असतात, त्यामुळे आकडे पाठ करण्याऐवजी तुमच्या समोर असलेल्या बिल्डची तपासणी करा:

ollama --version
ollama serve --help

ollama serve --help मध्ये त्या एनवायरमेंट व्हेरिएबल्सची यादी असते जी प्रत्यक्ष बिल्ड वाचते, त्यापैकी OLLAMA_KEEP_ALIVE एक आहे. दोन नियम सर्व रिलीजमध्ये कायम राहिले आहेत आणि त्यावर अवलंबून राहणे सुरक्षित आहे. विनंतीवर (request) दिलेले मूल्य सर्व्हरच्या डीफॉल्ट मूल्यापेक्षा प्रभावी ठरते. आणि ollama ps हे काय लोड झाले आहे याचे सत्य सांगते, मग कॉन्फिगरेशन फाईलमध्ये काहीही लिहिलेले असो.

जर एखादा एडिटर किंवा एजंट तुमचा सर्व्हर चालवत असेल, तर सर्व्हरला दोष देण्यापूर्वी तो क्लायंट काय पाठवत आहे ते तपासा. तुमच्या स्वतःच्या Ollama सर्व्हरकडे कोडिंग एजंट निर्देशित करणे या लेखात त्या विनंती सेटिंग्ज कुठे असतात हे स्पष्ट केले आहे.

FAQ

Ollama 5 मिनिटांनंतर माझे मॉडेल का अनलोड करते?

5 मिनिटे हा डीफॉल्ट keep_alive आहे, जो विनंती पूर्ण झाल्यावर Ollama सुरू करते. हा वेळ संपल्यावर सर्व्हर मॉडेलचे वेट्स (weights) मोकळे करतो, त्यामुळे पुढच्या विनंतीच्या वेळी ते पुन्हा डिस्कवरून लोड करावे लागते आणि तो विलंब तुम्हाला जाणवतो. एका विनंतीसाठी हा वेळ वाढवण्यासाठी JSON बॉडीमध्ये "keep_alive": "30m" पाठवा, किंवा संपूर्ण सर्व्हरसाठी OLLAMA_KEEP_ALIVE हे environment variable वापरा.

मी Ollama मॉडेल कायमस्वरूपी मेमरीमध्ये कसे ठेवू शकतो?

ऋण (negative) मूल्य वापरा: विनंतीमध्ये "keep_alive": -1 किंवा सर्व्हरसाठी OLLAMA_KEEP_ALIVE=-1 वापरा. त्यानंतर ollama ps कमांड चालवल्यास UNTIL कॉलममध्ये Forever दिसेल. यामुळे फक्त आयडल टायमर निघून जातो. जर दुसऱ्या मॉडेलची विनंती आली आणि मेमरी कमी असेल, तर शेड्युलर जागा करण्यासाठी हे मॉडेल अनलोड करू शकतो.

OLLAMA_KEEP_ALIVE कडे दुर्लक्ष का केले जात आहे?

तुम्ही ते कोठे सेट केले आहे ते तपासा. systemctl show ollama --property=Environment चालवा, जर व्हेरिएबल आउटपुटमध्ये दिसत नसेल तर सर्व्हरला ते मिळालेले नाही, कारण तुमच्या शेलमध्ये एक्सपोर्ट केलेले व्हेरिएबल systemd सर्व्हिसपर्यंत पोहोचत नाही. ते sudo systemctl edit ollama.service वापरून सेट करा, त्यानंतर sudo systemctl daemon-reload आणि sudo systemctl restart ollama चालवा. दुसरे कारण म्हणजे क्लायंट स्वतःची keep_alive विनंती पाठवत आहे, जी सर्व्हरच्या डीफॉल्ट सेटिंगला ओव्हरराइड करते.

Ollama रीस्टार्ट न करता मी मेमरी कशी मोकळी करू शकतो?

ollama stop qwen3:8b कमांड ते विशिष्ट मॉडेल त्वरित अनलोड करते आणि सर्व्हर तसेच इतर लोड केलेली मॉडेल्स सुरू ठेवते. API द्वारे, कोणतीही प्रॉम्प्ट न पाठवता "keep_alive": 0 सह विनंती पाठवा, त्यानंतर उत्तरामध्ये "done_reason": "unload" मिळेल. ollama ps सह खात्री करा, ज्यामध्ये आता ते मॉडेल दिसू नये.