Ollama pull और run में अंतर: मॉडल फाइलें कहाँ सेव होती हैं

ollama pull बनाम ollama run

ollama pull एक मॉडल डाउनलोड करता है और रुक जाता है। ollama run मॉडल को केवल तभी डाउनलोड करता है यदि वह मौजूद न हो, फिर उसे मेमोरी में लोड करता है और एक इंटरैक्टिव चैट खोलता है। डाउनलोड की प्रक्रिया समान है और फाइलें एक ही स्थान पर सेव होती हैं। केवल run ही इसके बाद आगे चलता रहता है।

यह एक अंतर तय करता है कि कौन सा कमांड स्क्रिप्ट में इस्तेमाल होना चाहिए और कौन सा कीबोर्ड पर।

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

पहली लाइन मॉडल को फेच करती है और बाहर निकल जाती है, इसलिए यह प्रोविजनिंग और systemd यूनिट में सुरक्षित है। दूसरी लाइन एक चैट सेशन खोलती है; इसे छोड़ने के लिए /bye टाइप करें या Ctrl+D दबाएं। तीसरी लाइन एक सिंगल प्रॉम्प्ट भेजती है, उत्तर प्रिंट करती है और बाहर निकल जाती है, जो कि उस स्क्रिप्ट के लिए सही फॉर्मेट है जिसे सेशन के बजाय उत्तर की आवश्यकता होती है। मॉडल के नाम तेजी से बदलते हैं, इसलिए यहाँ gemma4 को एक प्लेसहोल्डर के रूप में मानें: यह वह उदाहरण है जिसका उपयोग अगस्त 2026 तक आधिकारिक Ollama डॉक्यूमेंटेशन में किया गया है, और लाइब्रेरी का कोई भी टैग इसी तरह काम करता है।

Ollama का पहला run frozen क्यों दिखता है

एक नए VPS पर पहला run बिना किसी आउटपुट के कई मिनटों तक रुक सकता है। कुछ भी खराब नहीं हुआ है। Chat prompt तब तक दिखाई नहीं दे सकता जब तक कि model डिस्क पर न हो और memory में load न हो जाए, इसलिए run आपको कुछ भी दिखाने से पहले कई gigabytes का download कर रहा होता है।

दो चीजें इस काम को छिपा देती हैं। Ollama अपना progress bar केवल तभी दिखाता है जब उसका output एक terminal हो, इसलिए shell script, cron job, CI step या plain ssh host ollama run ... के अंदर का run download के दौरान कुछ भी print नहीं करता है। फिर, एक बार bytes आ जाने के बाद, पहला token आने से पहले file को डिस्क से RAM में read करना पड़ता है, और एक छोटे VPS पर यह read प्रक्रिया धीमी होती है। यदि box में model के लिए पर्याप्त memory नहीं है, तो kernel swapping शुरू कर देता है और प्रतीक्षा का समय काफी बढ़ जाता है।

अनुमान लगाने के बजाय इसे दूसरे session से monitor करें:

df -h /
watch -n5 df -h /

Free space का चरणों में कम होना यह दर्शाता है कि download अभी भी चल रहा है। Free space का कम होना तब रुक जाता है जब command अभी भी busy हो, जिसका अर्थ है कि download पूरा हो गया है और memory में load करने की प्रक्रिया शुरू हो गई है।

यही कारण है कि पहले से pull करना बेहतर होता है। जो व्यक्ति ollama run type करता है, उसे download के लिए प्रतीक्षा नहीं करनी चाहिए।

किसी के अनुरोध करने से पहले मॉडल को pull करें

एक नए सर्वर पर, वही स्क्रिप्ट pull करें जो सर्वर को install करती है:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

यदि आप पहली बार सर्वर तैयार कर रहे हैं, तो the full Ollama on a VPS install में सर्विस और उसे एक्सेस करने की अनुमति रखने वाले लोगों के बारे में जानकारी दी गई है। इसके बाद, जो सेटअप करना सार्थक है, वह एक ऐसा pull है जो आपके टर्मिनल के बंद होने के बाद भी चलता रहे, क्योंकि बीच में डाउनलोड रुक जाने से मॉडल स्टोर अधूरा रह जाता है।

इसे tmux के अंदर चलाएं, या इसे systemd को एक one-shot यूनिट के रूप में दें जो बूट पर चले। /etc/systemd/system/ollama-pull.service लिखें:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

दोनों कमांड जानबूझकर /bin/sh -c के माध्यम से चलते हैं। एक साधारण ExecStart= को absolute path की आवश्यकता होती है, और इंस्टॉलर हमेशा बाइनरी को एक ही डायरेक्टरी में नहीं रखता है, इसलिए आपके अपने बॉक्स पर command -v ollama ही एकमात्र विश्वसनीय समाधान है। शेल के माध्यम से जाने पर गाइड से कॉपी किए गए पाथ के बजाय सर्विस PATH का उपयोग होता है। पहला ExecStart भी महत्वपूर्ण है: After=ollama.service का अर्थ है कि सर्वर यूनिट शुरू हो गई है, जो 'तैयार' होने के समान नहीं है, इसलिए लूप तब तक प्रतीक्षा करता है जब तक कि ollama list उत्तर न दे दे, उसके बाद ही pull शुरू होता है।

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

जर्नल में दिखना चाहिए कि pull बिना किसी त्रुटि के समाप्त हो गया है, और फिर ollama list को मॉडल दिखाना चाहिए। एक मूविंग टैग को अपडेट रखने के लिए, एक systemd timer या साप्ताहिक cron एंट्री जोड़ें जो वही pull चलाए। एक ऐसे टैग को फिर से pull करने पर जो मूव हो चुका है, नई लेयर्स डाउनलोड हो जाती हैं और पुरानी लेयर्स का कोई संदर्भ नहीं बचता, जिन्हें अगली बार सर्वर शुरू होने पर साफ कर दिया जाता है।

जब pull प्रक्रिया बाधित हो जाए तो क्या होता है

मॉडल की प्रत्येक layer उसकी अपनी सामग्री के hash के अंतर्गत store की जाती है। इसलिए, बाधित pull का मतलब यह नहीं है कि किया गया काम व्यर्थ गया: उसी ollama pull को दोबारा चलाएं, और जो layers पहले ही पूरी हो चुकी हैं, उन्हें पहचान कर छोड़ दिया जाएगा। इस प्रकार, download उस layer से जारी रहेगा जहाँ वह रुका था।

एक क्रिया इस प्रगति को नष्ट कर देती है। जब Ollama सर्वर start होता है, तो वह उन stored layers को हटा देता है जिनका कोई model manifest संदर्भ नहीं देता है, और एक बाधित pull द्वारा छोड़ी गई partial layer बिल्कुल वैसी ही होती है। इसलिए, retry करने से पहले सर्विस को restart करने पर वह हिस्सा हट जाता है जिसे आपने पहले ही download कर लिया है। पहले pull को retry करें और बाद में restart करें। यदि किसी partial download को restart के बाद भी सुरक्षित रखना आवश्यक है, तो सर्विस environment में OLLAMA_NOPRUNE=1 सेट करें, और बाद में उसे हटा दें, क्योंकि वह startup cleanup ही डिस्क पर orphaned layers को जमा होने से रोकता है।

यदि pull no space left on device के साथ विफल हो गया है, तो retry करने से पहले खाली जगह (free space) बनाएं। यदि df डिस्क फुल होने की रिपोर्ट देता है और मॉडल डायरेक्टरी पर du से उसका हिसाब नहीं मिल रहा है, तो वह जगह कहीं और इस्तेमाल हो रही है। कुछ भी delete करने से पहले df और du के असहमत होने के कारण को पढ़ना उपयोगी है।

Ollama VPS पर models कहाँ store करता है?

किसी भी गाइड (जिसमें यह भी शामिल है) में दिए गए path पर भरोसा करने के बजाय अपने सर्वर से ही पूछें। यह location package install और container के बीच अलग-अलग होती है, और यदि किसी ने OLLAMA_MODELS सेट किया है तो यह फिर से बदल जाती है।

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat यूनिट फाइल को हर drop-in के साथ print करता है, इसलिए आपके द्वारा सेट की गई या आपकी image में पहले से मौजूद OLLAMA_MODELS लाइन वहाँ दिखाई देगी। यदि ऐसी कोई लाइन नहीं है, तो store उस account की home directory के अंतर्गत होता है जिसके तहत service चलती है, और getent passwd उस home directory को colon-separated फील्ड में छठे स्थान पर print करता है। find एक filesystem में blobs directory को खोजता है, जहाँ वास्तव में layers लिखी जाती हैं। यदि models पहले से ही किसी अलग mount पर हो सकते हैं, तो -xdev को हटा दें।

अब मापें, और अपने स्वयं के numbers पढ़ें:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

store के दो भाग होते हैं। manifests में प्रति model tag एक छोटी फाइल होती है, और वह फाइल उन layers की सूची रखती है जिनसे tag बना है। blobs में स्वयं layers होती हैं, जिनमें से प्रत्येक का नाम उसकी सामग्री के hash के आधार पर रखा जाता है, और लगभग सारा आकार वहीं होता है। चूंकि layers को tags के बीच साझा किया जाता है, इसलिए समान weights पर बने दो models ollama list में अपना-अपना आकार दिखाते हैं, जबकि disk पर वे उस स्थान को केवल एक बार घेरते हैं। इसलिए, सूचीबद्ध आकारों का योग du द्वारा directory के लिए रिपोर्ट किए गए आकार से अधिक हो सकता है।

Model files एक छोटे VPS root filesystem को किसी भी अन्य चीज़ की तुलना में तेज़ी से भर देती हैं जिसे आप install कर सकते हैं, और उनके आकार को नियंत्रित करने का सबसे बड़ा तरीका weight format है। q4, q8 और fp16 के बीच चयन करना प्रति model कई gigabytes की बचत कर सकता है।

OLLAMA_MODELS के साथ मॉडल्स को डेटा वॉल्यूम पर ले जाना

यदि आपके प्लान में दूसरी डिस्क या बड़ा डेटा वॉल्यूम है, तो रूट फाइलसिस्टम के भरने से पहले स्टोर को स्थानांतरित कर दें। सबसे पहले सर्वर को रोकें, ताकि आप ऐसी फाइल कॉपी न करें जो अभी भी लिखी जा रही हो।

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit एक ड्रॉप-इन फाइल पर एडिटर खोलता है, ताकि पैकेज्ड यूनिट में कोई बदलाव न हो और पैकेज अपग्रेड आपके बदलाव को ओवरराइट न कर सके। ये दो लाइनें जोड़ें:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show को आपका नया पाथ प्रिंट करना चाहिए, और ollama list को वही मॉडल्स दिखाने चाहिए जो मूव करने से पहले दिख रहे थे। खाली लिस्ट का मतलब है कि सर्वर नई डायरेक्टरी को पढ़ नहीं पा रहा है। सर्विस ollama यूजर के रूप में चलती है, इसलिए उस यूजर को डेस्टिनेशन पर रीड और राइट एक्सेस की आवश्यकता होती है, जो ऊपर दी गई chown लाइन का काम है। नए पाथ का नाम बताने वाली परमिशन एरर्स के लिए journalctl -e -u ollama की जाँच करें। पुरानी कॉपी को केवल तभी डिलीट करें जब लिस्ट सही हो, क्योंकि मूव फेल होने और सोर्स डिलीट हो जाने का मतलब है कि सब कुछ फिर से डाउनलोड करना पड़ेगा।

दूसरा विकल्प ओरिजिनल पाथ को बनाए रखना और उस पर डेटा वॉल्यूम को माउंट करना है:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt द्वारा माउंट प्रिंट करने का मतलब है कि बाइंड लाइव है। बाइंड माउंट तब मदद करता है जब बॉक्स पर कोई अन्य चीज पहले से ही डिफॉल्ट लोकेशन की अपेक्षा कर रही हो। इसमें एक समस्या है: जो फाइलें आपने कॉपी की हैं, वे अभी भी रूट डिस्क पर माउंट पॉइंट के नीचे छिपी हुई हैं, इसलिए जब तक आप उन्हें अनमाउंट करके हटा नहीं देते, तब तक स्पेस वापस नहीं मिलता। एनवायरनमेंट वेरिएबल उन दोनों में से आसान है जिन्हें बाद में लॉग इन करने वाले व्यक्ति को समझाना हो।

कंटेनर इन्हें कहाँ रखता है

आधिकारिक image मॉडल्स को उस स्थान पर स्टोर करती है जिसे आप mount करते हैं, न कि किसी ऐसे host directory में जो किसी ollama user से संबंधित हो। प्रलेखित run कमांड इस प्रकार है:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama कोलन से पहले एक named Docker volume है, और /root/.ollama वह स्थान है जहाँ सर्वर कंटेनर के अंदर लिखता है। इसलिए पिछले सेक्शन के paths के विरुद्ध du चलाने पर कुछ नहीं मिलता, क्योंकि वहाँ कुछ भी नहीं है। वास्तविक स्थान और आकार प्रिंट करें:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

docker volume inspect से Mountpoint फ़ील्ड पढ़ें, फिर उसके विरुद्ध sudo du -sh चलाएँ। मॉडल्स को data volume पर रखने के लिए, named volume को एक host directory (-v /mnt/data/ollama:/root/.ollama) से बदलें और कंटेनर को फिर से बनाएँ। कंटेनर root के रूप में लिखता है, इसलिए उस host directory का स्वामित्व root के पास आ जाता है। rootless Podman के अंतर्गत ids आपके user की subuid रेंज में map हो जाती हैं, इसलिए host का स्वामित्व अलग दिखता है: rootless Podman के अंतर्गत Ollama चलाना उस मैपिंग को कवर करता है।

cleanup के बारे में एक चेतावनी। docker volume prune हर उस volume को हटा देता है जिसे कोई भी कंटेनर refer नहीं करता है। ollama कंटेनर को उसके volume के बिना हटाएँ या फिर से बनाएँ, तो बाद में किया गया prune आपके द्वारा डाउनलोड किए गए हर मॉडल को हटा देगा, और उन्हें दोबारा डाउनलोड करने के अलावा उन्हें वापस पाने का कोई तरीका नहीं है। VPS पर Docker डिस्क उपयोग को prune करने के तरीके के बारे में VPS पर Docker डिस्क उपयोग को prune कैसे करें पढ़ें, इससे पहले कि आप उस बॉक्स पर prune चलाएँ जो मॉडल्स को होस्ट करता है।

Ollama rm का उपयोग करके मॉडल हटाएं, rm का उपयोग न करें

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm उस टैग के लिए मैनिफेस्ट को हटा देता है, और फिर उन लेयर्स को हटा देता है जिन्हें कोई अन्य मैनिफेस्ट रेफर नहीं करता है। जैसे ही वे फाइलें अनलिंक होती हैं, डिस्क स्पेस वापस मिल जाता है, इसलिए df तुरंत प्रभावी हो जाता है। चूंकि लेयर्स साझा (shared) होती हैं, इसलिए दो निकट संबंधित टैग्स में से एक को हटाने पर, ollama list द्वारा प्रदर्शित आकार की तुलना में बहुत कम स्पेस खाली हो सकता है। यह सही व्यवहार है, न कि डिलीट प्रक्रिया की विफलता।

फाइलों को मैन्युअल रूप से हटाने से यह प्रक्रिया बाधित हो जाती है। यदि आप rm से कोई ब्लॉब हटाते हैं और मैनिफेस्ट में वह अभी भी सूचीबद्ध है, तो ollama list मॉडल को दिखाना जारी रखेगा और जब भी उस गायब लेयर को पढ़ने का प्रयास किया जाएगा, तो उपयोग विफल हो जाएगा। यदि आप मैन्युअल रूप से मैनिफेस्ट हटाते हैं, तो उसकी लेयर्स डिस्क पर बनी रहती हैं और उन्हें कोई भी Ollama कमांड रिपोर्ट नहीं करेगा, जिससे डिस्क स्पेस व्यर्थ घिरा रहता है। यदि आपने ऐसा पहले ही कर दिया है, तो टैग पर ollama rm चलाने से बची हुई एंट्री साफ हो जाएगी, और सर्वर को रीस्टार्ट करने से वे लेयर्स हट जाएंगी जिन्हें कोई भी रेफर नहीं कर रहा है।

एक अंतिम अंतर, क्योंकि अक्सर इन दोनों में भ्रम हो जाता है। ollama rm डिस्क से संबंधित है। ollama stop gemma4 मॉडल को मेमोरी से अनलोड करता है और डिस्क स्पेस बिल्कुल भी खाली नहीं करता है। डाउनलोड पूरा होने के बाद मॉडल RAM में कितनी देर तक रहता है, यह एक अलग सेटिंग है, और हर रिक्वेस्ट पर रीलोड करने के बजाय मॉडल को लोडेड रखना में इसे विस्तार से समझाया गया है।

FAQ

ollama pull और ollama run में क्या अंतर है?

ollama pull मॉडल को डिस्क पर डाउनलोड करता है और बंद हो जाता है। ollama run यह जाँचता है कि क्या मॉडल पहले से डिस्क पर मौजूद है, यदि नहीं तो उसे डाउनलोड करता है, मेमोरी में लोड करता है और फिर एक इंटरैक्टिव चैट सत्र खोलता है। दोनों एक ही डायरेक्टरी में एक ही फाइलें लिखते हैं। प्रोविजनिंग और स्क्रिप्ट्स में pull का उपयोग करें, और जब कोई व्यक्ति कीबोर्ड पर हो तो run का उपयोग करें। ollama run <model> "your prompt" एक प्रॉम्प्ट भेजता है और बंद हो जाता है, जो run का स्क्रिप्ट-योग्य रूप है।

मेरा पहला ollama run अटकता हुआ क्यों प्रतीत होता है?

यह डाउनलोड हो रहा है। चैट प्रॉम्प्ट तब तक दिखाई नहीं दे सकता जब तक मॉडल डिस्क पर न हो और मेमोरी में लोड न हो जाए, और एक मॉडल कई गीगाबाइट का होता है। Ollama अपना प्रोग्रेस बार केवल तभी दिखाता है जब आउटपुट एक टर्मिनल हो, इसलिए स्क्रिप्ट, क्रॉन जॉब या ssh host ollama run ... के अंदर run काम करते समय कुछ भी नहीं दिखाता है। एक दूसरा सत्र खोलें और watch -n5 df -h / चलाएँ: खाली जगह का चरणों में कम होना यह दर्शाता है कि डाउनलोड प्रगति पर है। मॉडल को पहले से पुल (pull) कर लें तो प्रतीक्षा समाप्त हो जाएगी।

Ollama अपने मॉडल कहाँ स्टोर करता है?

लोकेशन इंस्टॉलेशन पर निर्भर करती है, इसलिए अनुमान लगाने के बजाय इसे प्रिंट करें। यह देखने के लिए systemctl cat ollama.service चलाएँ कि क्या यूनिट या ड्रॉप-इन में OLLAMA_MODELS सेट है। यदि यह सेट नहीं है, तो स्टोर उस अकाउंट की होम डायरेक्टरी के अंतर्गत रहता है जिसके रूप में सर्विस चलती है, जिसे getent passwd ollama प्रिंट करता है। sudo find / -xdev -type d -name blobs 2>/dev/null सीधे लेयर डायरेक्टरी का पता लगाता है। कंटेनर इमेज के लिए, स्टोर माउंटेड वॉल्यूम के अंदर होता है, और docker volume inspect ollama इसके होस्ट Mountpoint को प्रिंट करता है।

मैं Ollama मॉडल को दूसरी डिस्क पर कैसे ले जाऊँ?

सर्विस को रोकें, स्टोर को rsync -a के साथ नए स्थान पर कॉपी करें, डायरेक्टरी का स्वामित्व sudo chown -R ollama:ollama <directory> के साथ सर्विस अकाउंट को दें, फिर sudo systemctl edit ollama.service चलाएँ और [Service] लाइन के अंतर्गत Environment="OLLAMA_MODELS=<directory>" जोड़ें। sudo systemctl daemon-reload के साथ रिलोड करें और रीस्टार्ट करें। systemctl show ollama --property=Environment और ollama list के साथ पुष्टि करें। एक खाली सूची का मतलब लगभग हमेशा यह होता है कि ollama यूजर नई डायरेक्टरी को पढ़ नहीं सकता है; journalctl -e -u ollama पाथ का नाम बताएगा।

क्या मॉडल फाइलों को हटाने से जगह खाली हो जाती है?

फाइलों को मैन्युअल रूप से हटाने से बाइट्स तो खाली हो जाते हैं लेकिन स्टोर असंगत (inconsistent) हो जाता है। एक ब्लॉब (blob) को हटाने पर भी मैनिफेस्ट में वह मॉडल सूचीबद्ध रहता है, इसलिए यह ollama list में दिखाई देता रहता है और उपयोग करने पर विफल हो जाता है। एक मैनिफेस्ट को हटाने पर उसकी लेयर्स डिस्क पर बनी रहती हैं और उन्हें कोई रेफर नहीं कर रहा होता। ollama rm <model> का उपयोग करें, जो मैनिफेस्ट को हटाता है और फिर उन लेयर्स को हटाता है जिनकी किसी अन्य मॉडल को आवश्यकता नहीं है। यदि फाइलें पहले ही मैन्युअल रूप से हटा दी गई हैं, तो एंट्री को क्लियर करने के लिए टैग पर ollama rm चलाएँ, फिर सर्वर को रीस्टार्ट करें, जो उन लेयर्स को हटा देता है जिन्हें कोई मैनिफेस्ट रेफर नहीं करता है।