Ollama pull और run में अंतर और model files कहाँ होती हैं

ollama pull बनाम ollama run

ollama pull एक model को download करता है और रुक जाता है। ollama run model को केवल तभी download करता है यदि वह मौजूद न हो, फिर उसे memory में load करता है और एक interactive chat खोलता है। download की प्रक्रिया समान है और files एक ही स्थान पर save होती हैं। केवल run ही उसके बाद चलता रहता है।

यह एक अंतर तय करता है कि कौन सा command script में उपयोग करना है और कौन सा keyboard पर।

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

पहली पंक्ति model को fetch करती है और exit हो जाती है, इसलिए यह provisioning और systemd unit में सुरक्षित है। दूसरी पंक्ति एक chat session खोलती है; इसे छोड़ने के लिए /bye टाइप करें या Ctrl+D दबाएं। तीसरी पंक्ति एक single prompt भेजती है, उत्तर print करती है और exit हो जाती है; script को यही रूप चाहिए होता है जब उसे session के बजाय केवल उत्तर की आवश्यकता हो। वह तीसरा रूप अभी भी उत्तर की लंबाई को पूरी तरह से model पर छोड़ देता है, इसलिए एक पंक्ति का प्रश्न तीन paragraphs में वापस आ सकता है, और num_predict के साथ उत्तर को सीमित करना ही वह तरीका है जो एक scripted run को उस आकार में रखता है जिसका उपयोग caller वास्तव में कर सके। Model के नाम तेजी से बदलते हैं, इसलिए यहाँ gemma4 को एक placeholder के रूप में मानें: यह वह उदाहरण है जिसका उपयोग आधिकारिक Ollama documentation अगस्त 2026 तक कर रहा है, और library का कोई भी tag समान व्यवहार करता है। यदि आप किसी ऐसे model को substitute करना चाहते हैं जिसे किसी ने पहले ही एक वास्तविक server के लिए size किया है, तो VPS पर Nemotron 3.5 Lightning चलाना pull करने के लिए सटीक tag और उसके लिए आवश्यक memory की जानकारी देता है।

Ollama को पहली बार run करने पर वह रुका हुआ क्यों लगता है

एक नए VPS पर पहली बार run चलाने पर कई मिनटों तक कोई output नहीं दिखता है। इसका मतलब यह नहीं है कि कुछ खराब है। जब तक model disk पर न आ जाए और memory में load न हो जाए, तब तक chat prompt दिखाई नहीं दे सकता। इसलिए, कुछ भी दिखाने से पहले run कई gigabytes का data download कर रहा होता है।

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

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

df -h /
watch -n5 df -h /

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

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

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

यही बात उन सभी चीजों पर लागू होती है जो व्यक्ति नहीं हैं: आपके Ollama endpoint पर पॉइंट किया गया कोडिंग एजेंट आमतौर पर कई गीगाबाइट का डाउनलोड पूरा होने का इंतज़ार करने के बजाय पहले अनुरोध पर ही हार मान लेगा। एक नए बॉक्स पर, उसी स्क्रिप्ट के माध्यम से पुल करें जो सर्वर को इंस्टॉल करती है:

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

यदि आप पहली बार सर्वर सेटअप कर रहे हैं, तो VPS पर पूर्ण Ollama इंस्टॉलेशन सर्विस और उसे एक्सेस करने की अनुमति रखने वाले उपयोगकर्ताओं को कवर करता है। उसके बाद, जो चीज सेटअप करने योग्य है, वह एक ऐसा पुल है जो आपके टर्मिनल के बंद होने के बाद भी चलता रहे, क्योंकि बीच में रुका हुआ डाउनलोड ही वह कारण है जिससे लोगों का मॉडल स्टोर अधूरा रह जाता है।

इसे 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 उत्तर न दे दे, उसके बाद ही पुल शुरू होता है।

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

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

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

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

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

यदि pull no space left on device के साथ विफल हुआ है, तो retry करने से पहले खाली स्थान (free space) बनाएँ। यदि df डिस्क फुल होने की रिपोर्ट देता है और मॉडल डायरेक्टरी पर du इसका हिसाब नहीं देता है, तो वह स्थान कहीं और इस्तेमाल हो रहा है, और कुछ भी डिलीट करने से पहले 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 unit file को हर drop-in के साथ print करता है, इसलिए आपके द्वारा सेट की गई या image में पहले से मौजूद OLLAMA_MODELS लाइन वहाँ दिखाई देगी। यदि ऐसी कोई लाइन नहीं है, तो store उस account की home directory के अंतर्गत होता है जिसके तहत service चलती है, और getent passwd उस home directory को colon-separated छठे field में 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 एक छोटी file होती है, और वह file उन layers की सूची रखती है जिनसे tag बना है। blobs में स्वयं layers होती हैं, जिनमें से प्रत्येक का नाम उसकी contents के hash के आधार पर रखा जाता है, और लगभग सारा size वहीं होता है। चूंकि layers को tags के बीच साझा किया जाता है, इसलिए समान weights पर बने दो models ollama list में अपना-अपना size दिखाते हैं, जबकि disk पर वे उस जगह को केवल एक बार घेरते हैं। इसलिए, सूचीबद्ध sizes का योग du द्वारा directory के लिए दी गई रिपोर्ट से अधिक हो सकता है।

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

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

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

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

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

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

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

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

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

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

क्लीनअप के बारे में एक चेतावनी। docker volume prune हर उस वॉल्यूम को हटा देता है जिसे कोई भी कंटेनर रेफर नहीं करता। ollama कंटेनर को उसके वॉल्यूम के बिना हटाएँ या फिर से बनाएँ, तो बाद में 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 आकार की तुलना में बहुत कम स्पेस खाली हो सकता है। यह सही व्यवहार है, न कि डिलीट प्रक्रिया की विफलता।

फाइलों को मैन्युअल रूप से हटाने से यह पेयर (pair) टूट जाता है। यदि आप rm से एक ब्लॉब (blob) हटाते हैं और मैनिफेस्ट में वह अभी भी सूचीबद्ध है, तो 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 चलाएँ, फिर सर्वर को रीस्टार्ट करें, जो उन लेयर्स को हटा देता है जिन्हें कोई मैनिफेस्ट रेफर नहीं करता है।