Ollama model को memory में permanently कैसे रखें

Ollama कुछ मिनटों के बाद मॉडल को अनलोड क्यों कर देता है?

Ollama अंतिम अनुरोध के बाद पांच मिनट तक मॉडल को मेमोरी में लोड रखता है, उसके बाद उसे मुक्त कर देता है। अगले अनुरोध को डिस्क से वेट्स (weights) को फिर से पढ़ना पड़ता है और उन्हें RAM या VRAM में मैप करना पड़ता है, इसलिए पहला टोकन आने से पहले इसमें देरी होती है। यही कारण है कि एक चैट UI या कोडिंग एजेंट तेज महसूस होता है, कुछ समय के लिए शांत हो जाता है, और फिर अगले संदेश पर धीमा महसूस होता है। कुछ भी खराब नहीं हुआ है। आइडल टाइमर (idle timer) समाप्त हो गया है।

इस टाइमर को keep_alive कहा जाता है। यह प्रति मॉडल होता है, और हर बार अनुरोध पूरा होने पर यह फिर से शुरू हो जाता है। जो मॉडल वर्तमान में किसी अनुरोध का उत्तर दे रहा है, उसे कभी अनलोड नहीं किया जाता है, क्योंकि सर्वर केवल उसी मॉडल को एक्सपायर करता है जिसका कोई सक्रिय अनुरोध नहीं होता है। अगस्त 2026 तक डिफ़ॉल्ट समय पांच मिनट है, और यह इस सर्वर द्वारा लोड किए गए प्रत्येक मॉडल पर लागू होता है।

keep_alive को सेट करने के दो स्थान हैं: व्यक्तिगत अनुरोध पर, या सर्वर डिफ़ॉल्ट के रूप में। एक systemd drop-in वह तरीका है जिससे सर्वर डिफ़ॉल्ट रीस्टार्ट के बाद भी बना रहता है। यह गाइड मानती है कि Ollama पहले से ही एक सर्विस के रूप में चल रहा है। यदि ऐसा नहीं है, तो Ollama को VPS पर इंस्टॉल करना से शुरुआत करें और फिर वापस आएं।

अभी कौन से मॉडल लोड हैं और उनकी समय-सीमा कब समाप्त होगी?

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 पर चल रहा है।

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 के लिए, अपने सिस्टम पर tokens per second मापने का तरीका देखें।

Ollama model को एक request पर memory में लोड रखें

Request के साथ keep_alive भेजें। यह request पूरा होने के क्षण से उस model पर लागू हो जाता है।

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 के रूप में पढ़ा जाता है: 3600
• एक negative मान, -1 या "-1m", जिसका अर्थ है कि कोई idle timeout नहीं होगा
• 0, जिसका अर्थ है कि यह request पूरा होते ही model को unload कर दिया जाए

Request पर दिया गया मान server के default मान को दोनों दिशाओं में override कर देता है। यह सुनने में जितना लगता है, उससे कहीं अधिक महत्वपूर्ण है: यदि client अपना स्वयं का keep_alive भेजता है, तो वह server पर आपके द्वारा configure की गई किसी भी सेटिंग पर प्रभावी रहता है।

आप बिना कुछ generate किए भी model को लोड कर सकते हैं। केवल model का नाम भेजें। Server उसे लोड करता है और "done": true के साथ एक खाली response लौटाता है।

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

Reboot के बाद, या नया model pull करने के बाद चलाने के लिए यही command है, ताकि पहले वास्तविक user request को loading का समय न देना पड़े। CLI भी एक flag के साथ यही काम करता है:

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

OLLAMA_KEEP_ALIVE के साथ इसे डिफ़ॉल्ट रूप से लोड रखें

सर्वर स्टार्टअप पर OLLAMA_KEEP_ALIVE को पढ़ता है और इसे हर उस मॉडल के लिए उपयोग करता है जिसमें अपना स्वयं का मान नहीं होता है। यह request field के समान ही प्रारूप लेता है, इसलिए 30m, 3600 और -1 सभी काम करते हैं।

समस्या यह है कि यह किस environment में होना चाहिए। अपने SSH session में export OLLAMA_KEEP_ALIVE=30m चलाने से कुछ नहीं होता, क्योंकि packaged install सर्वर को एक systemd service के रूप में उसके अपने user और उसके अपने environment के तहत चलाता है। आपका login shell और वह service कभी एक-दूसरे से नहीं मिलते। यही सबसे आम कारण है कि यह सेटिंग अनदेखी (ignored) लगती है।

systemd drop-in के साथ इसे रीस्टार्ट के बाद भी सक्रिय रखें

sudo systemctl edit ollama.service

एडिटर दो कमेंट मार्कर्स के साथ खुलता है। उनके बीच में टाइप करें: दूसरे मार्कर के नीचे आप जो कुछ भी लिखेंगे, systemd उसे हटा देगा।

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

सेव करने पर /etc/systemd/system/ollama.service.d/override.conf लिखा जाता है। यह मूल unit फाइल को एडिट करने के बजाय एक drop-in है, इसलिए Ollama पैकेज का अपग्रेड जो ollama.service को बदलता है, आपकी सेटिंग को सुरक्षित रखता है। यदि drop-ins और unit फाइल्स आपके लिए नए हैं, तो systemd service और timer गाइड में इनकी कार्यप्रणाली समझाई गई है।

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

अंतिम कमांड उस एनवायरनमेंट को प्रिंट करता है जिसमें सर्विस वास्तव में चलेगी। यदि उस लाइन में OLLAMA_KEEP_ALIVE=30m मौजूद नहीं है, तो drop-in लागू नहीं हुआ है। इसका कारण लगभग हमेशा एक गायब [Service] हेडर या मार्कर के नीचे टाइप की गई लाइनें होती हैं। रीस्टार्ट करने पर सभी लोडेड मॉडल्स हट जाते हैं, इसलिए अगली रिक्वेस्ट एक कोल्ड लोड (cold load) होती है। इसे ऊपर दिए गए preload कॉल के साथ वॉर्म-अप करें।

मॉडल को resident रखने की लागत

ollama ps में SIZE कॉलम वह मेमोरी है जो पूरे idle window के दौरान होल्ड रहती है, न कि केवल request के समय। 4-bit quantisation पर एक 8B मॉडल लगभग 5 से 6 GB लेता है। 27B मॉडल की स्थिति अलग है, और केवल CPU वाले VPS पर इसे चलाने के लिए मेमोरी की गणना को समझ लेना चाहिए, इससे पहले कि आप इसे resident रखने का निर्णय लें। keep_alive को -1 पर सेट करने का अर्थ है कि आपने तय कर लिया है कि यह मॉडल सर्वर पर मौजूद बाकी सभी चीजों से अधिक महत्वपूर्ण है। एक छोटे VPS पर, यह आपके डेटाबेस, वेब ऐप और बिल्ड जॉब्स के साथ सीधा समझौता है।

अनुमान पर भरोसा करने के बजाय वास्तविक आंकड़ों पर नजर रखें। जब मॉडल लोड हो, तब यह कमांड चलाएँ, और फिर ollama stop के बाद दोबारा चलाएँ:

free -h

available कॉलम वह मेमोरी है जिसे kernel अभी भी किसी नई process को दे सकता है। NVIDIA GPU वाले बॉक्स पर, nvidia-smi VRAM में यही स्थिति दिखाता है। यदि बॉक्स की मेमोरी खत्म हो जाती है, तो kernel मेमोरी रिकवर करने के लिए किसी process को kill कर देता है:

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

यदि log में ollama का नाम आता है, तो इसका मतलब है कि मॉडल सर्वर victim था। यदि log में आपके डेटाबेस का नाम आता है, तो इसका मतलब है कि मॉडल जीत गया और आपकी महत्वपूर्ण service बंद हो गई। दोनों परिणाम एक ही निर्णय से आते हैं: बिना headroom वाले बॉक्स पर लंबा keep-alive window रखना।

यहाँ दो लागतें ऐसी हैं जिन्हें नजरअंदाज करना आसान है। लंबी context length एक बड़े KV cache (key value cache, generation के दौरान मॉडल द्वारा रखा गया प्रति-टोकन attention state) को reserve करती है, और यह cache resident size का हिस्सा होता है। 1 से अधिक OLLAMA_NUM_PARALLEL प्रत्येक parallel slot के लिए उस cache को एक बार reserve करता है। यदि आप एक ही मॉडल से कई लोगों को serve करने की योजना बना रहे हैं, तो मेमोरी का आकार केवल weights के लिए नहीं, बल्कि slots के लिए भी तय करें।

एक उचित default: headroom वाले बॉक्स पर एक मॉडल -1 का उपयोग कर सकता है। एक shared बॉक्स पर ऐसा window इस्तेमाल करना चाहिए जो आपकी requests के बीच के अंतराल को कवर करे, जैसे कि 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) को पिन नहीं करता है।

उस निर्णय को डिबग स्तर पर लॉग किया जाता है। उसी ड्रॉप-इन में दूसरी Environment="OLLAMA_DEBUG=1" लाइन जोड़ें, रीस्टार्ट करें, और देखें:

sudo journalctl -u ollama -f

जगह बनाने के लिए किसी रनर को अनलोड करने के बारे में एक लाइन, जो उस अनुरोध के बगल में दिखाई देती है जिसने इसे ट्रिगर किया है, आपको बताती है कि ये दो मॉडल इस मशीन पर एक साथ फिट नहीं होते हैं। इसका समाधान इस बॉक्स पर कम मॉडल रखना है, या उस मॉडल के लिए एक लंबी विंडो रखना है जिसे तेजी से उत्तर देना आवश्यक है और जिसे आप शायद ही कभी कॉल करते हैं उसके लिए 0 का उपयोग करना है।

अगले release के बाद भी प्रभावी रहने वाले दिशा-निर्देश

Ollama अक्सर update होता है और इसके defaults बदलते रहते हैं, इसलिए संख्याओं को याद रखने के बजाय अपने सामने मौजूद build की जाँच करें:

ollama --version
ollama serve --help

ollama serve --help उन environment variables की सूची देता है जिन्हें वह build वास्तव में पढ़ता है, जिनमें OLLAMA_KEEP_ALIVE भी शामिल है। दो नियम सभी releases में स्थिर रहे हैं और उन पर भरोसा किया जा सकता है। request में दिया गया मान server के default मान से अधिक प्रभावी होता है। और ollama ps इस बात का प्रमाण है कि क्या load हुआ है, चाहे configuration file में कुछ भी लिखा हो।

यदि कोई editor या agent आपके server को संचालित कर रहा है, तो server को दोष देने से पहले यह जाँच लें कि वह client क्या भेज रहा है। अपने Ollama server पर coding agent को point करना इस बात को कवर करता है कि वे request settings कहाँ स्थित होती हैं।

FAQ

Ollama 5 मिनट के बाद मेरे मॉडल को अनलोड क्यों कर देता है?

5 मिनट डिफ़ॉल्ट keep_alive है, जो कि एक आइडल टाइमर है जिसे Ollama किसी रिक्वेस्ट के पूरा होने पर शुरू करता है। जब यह समय समाप्त हो जाता है, तो सर्वर वेट्स (weights) को फ्री कर देता है, इसलिए अगली रिक्वेस्ट उन्हें डिस्क से फिर से लोड करती है, और वह रीलोड ही वह पॉज़ है जिसे आप महसूस करते हैं। इसे एक रिक्वेस्ट के लिए बढ़ाने हेतु JSON बॉडी में "keep_alive": "30m" भेजें, या पूरे सर्वर के लिए OLLAMA_KEEP_ALIVE एनवायरनमेंट वेरिएबल का उपयोग करें।

मैं Ollama मॉडल को स्थायी रूप से मेमोरी में कैसे रख सकता हूँ?

एक नेगेटिव वैल्यू का उपयोग करें: रिक्वेस्ट पर "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 के साथ पुष्टि करें, जिसमें अब वह मॉडल लिस्ट नहीं होना चाहिए।