Ollama मॉडल को मेमोरी में हमेशा के लिए कैसे रखें

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

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

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

keep_alive को सेट करने के दो स्थान हैं: व्यक्तिगत अनुरोध पर, या सर्वर डिफ़ॉल्ट के रूप में। एक systemd drop-in वह तरीका है जिससे सर्वर डिफ़ॉल्ट रीस्टार्ट के बाद भी बना रहता है। यह गाइड मानती है कि 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 हर response में लोड होने का समय 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"}'

यह वह कमांड है जिसे रीबूट के बाद, या नया मॉडल पुल करने के बाद चलाना चाहिए, ताकि पहले वास्तविक उपयोगकर्ता अनुरोध को लोड होने में समय न लगे। CLI भी एक फ्लैग के साथ यही काम करता है:

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

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

सर्वर स्टार्टअप पर OLLAMA_KEEP_ALIVE को पढ़ता है और इसे हर उस मॉडल के लिए उपयोग करता है जिसका अपना कोई मान (value) नहीं होता है। यह 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 लिखा जाता है। यह एक drop-in है, न कि शिप की गई unit का संपादन, इसलिए Ollama पैकेज का अपग्रेड जो ollama.service को बदलता है, आपकी सेटिंग को सुरक्षित रखता है। यदि drop-ins और unit files आपके लिए नए हैं, तो systemd service और timer गाइड में इसकी कार्यप्रणाली समझाई गई है।

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

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

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

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

अनुमानों पर भरोसा करने के बजाय वास्तविक आंकड़ों पर नजर रखें। मॉडल लोड होने के दौरान इसे चलाएं, और फिर 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 का नाम आता है, तो इसका मतलब है कि मॉडल सर्वर को kill किया गया है। यदि आपके डेटाबेस का नाम आता है, तो इसका मतलब है कि मॉडल ने बाजी मार ली और आपकी महत्वपूर्ण service बंद हो गई। दोनों परिणाम एक ही निर्णय से आते हैं: बिना पर्याप्त headroom वाले बॉक्स पर लंबा keep-alive window रखना।

यहाँ दो ऐसी लागतें हैं जिन्हें नजरअंदाज करना आसान है। लंबी context length एक बड़े KV cache (key value cache, generation के दौरान मॉडल द्वारा रखा गया per token attention state) को reserve करती है, और यह cache resident size का हिस्सा होता है। इसका आकार num_ctx से तय होता है, इसलिए context window को बढ़ाना उस मेमोरी को बढ़ा देता है जिसे resident मॉडल पूरे idle period के दौरान होल्ड रखता है, न कि केवल जवाब देते समय। 1 से अधिक OLLAMA_NUM_PARALLEL होने पर, यह cache प्रति parallel slot एक बार 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-only सिस्टम पर भी तीन मॉडल है। यह सीमा मॉडलों की संख्या पर आधारित है, जबकि वास्तविक बाधा मेमोरी है। इसलिए, तीन की सीमा तक पहुँचने से बहुत पहले ही किसी दूसरे बड़े मॉडल के लिए जगह की कमी हो सकती है।

जब किसी नए मॉडल का अनुरोध किया जाता है और उसके लिए पर्याप्त मेमोरी नहीं होती है, तो शेड्यूलर जगह बनाने के लिए पहले से लोड किए गए मॉडलों में से एक को अनलोड कर देता है। यह ऐसे मॉडल को प्राथमिकता देता है जिसका कोई सक्रिय अनुरोध नहीं है। यह उस मॉडल को भी हटा सकता है जिसका टाइमर समाप्त नहीं हुआ है, जिसमें -1 के साथ लोड किया गया मॉडल भी शामिल है। इसलिए, नकारात्मक keep_alive का अर्थ है कि कोई idle timeout नहीं है। यह किसी अन्य मॉडल के अनुरोध के विरुद्ध weights को पिन नहीं करता है।

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

sudo journalctl -u ollama -f

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

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

Ollama अक्सर release होता है और इसके 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 के साथ पुष्टि करें, जिसमें अब वह मॉडल लिस्ट नहीं होना चाहिए।