Ollama pull आणि run मधील फरक, मॉडेल फाइल्स कुठे आहेत

ollama pull विरुद्ध ollama run

ollama pull मॉडेल डाउनलोड करून थांबते. ollama run मॉडेल उपलब्ध नसल्यासच ते डाउनलोड करते, त्यानंतर ते memory मध्ये load करून interactive chat उघडते. डाउनलोड समान असतो आणि files त्याच ठिकाणी साठवल्या जातात. त्यानंतर पुढे सुरू राहणारी एकमेव command म्हणजे run.

हा एकच फरक कोणती command script मध्ये वापरायची आणि कोणती keyboard समोर वापरायची हे ठरवतो.

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

पहिली ओळ मॉडेल fetch करून बाहेर पडते. त्यामुळे ती provisioning आणि systemd unit मध्ये सुरक्षितपणे वापरता येते. दुसरी interactive chat session उघडते; बाहेर पडण्यासाठी /bye टाइप करा किंवा Ctrl+D दाबा. तिसरी एकच prompt पाठवते, उत्तर print करते आणि बाहेर पडते. Session ऐवजी उत्तर आवश्यक असलेल्या script साठी हा प्रकार योग्य आहे. या तिसऱ्या प्रकारात उत्तराची लांबी पूर्णपणे मॉडेलवर अवलंबून राहते. त्यामुळे एक ओळीचा प्रश्न तीन परिच्छेदांचे उत्तर देऊ शकतो. num_predict ने उत्तराची कमाल लांबी ठरवणे यामुळे scripted run caller प्रत्यक्षात वापरू शकेल अशा आकारात ठेवता येते. Model names लवकर बदलतात. त्यामुळे येथे gemma4 ला placeholder समजा. August 2026 पर्यंत official Ollama documentation मध्ये वापरलेले हे उदाहरण आहे; library मधील कोणताही tag याच प्रकारे काम करतो. प्रत्यक्ष server साठी आधीच sizing केलेले मॉडेल वापरायचे असल्यास, VPS वर Nemotron 3.5 Lightning चालवणे येथे pull करण्यासाठी अचूक tag आणि आवश्यक memory दिली आहे.

पहिल्यांदा ollama run गोठल्यासारखे का दिसते

नवीन VPS वर पहिला run काही मिनिटे कोणतेही output न दाखवता सुरू राहू शकतो. काहीही बिघडलेले नसते. Model disk वर साठवून memory मध्ये load होईपर्यंत chat prompt दिसू शकत नाही. त्यामुळे run आधी तुम्हाला काही दाखवण्यापूर्वी अनेक gigabyte चा download करत असते.

हे काम दोन कारणांमुळे दिसत नाही. Ollama चे progress bar output terminal कडे जात असेल तेव्हाच दिसते. त्यामुळे shell script, cron job, CI step किंवा साध्या ssh host ollama run ... मधील run download सुरू असताना काहीही print करत नाही. त्यानंतर bytes disk वर आले तरी पहिला token मिळण्यापूर्वी file disk वरून RAM मध्ये read करावी लागते. लहान VPS वर हा read धीमा असतो. VPS मध्ये model साठी पुरेशी memory नसल्यास kernel swapping सुरू करते आणि प्रतीक्षा आणखी वाढते.

अंदाज बांधण्याऐवजी दुसऱ्या session मधून त्याची स्थिती पाहा:

df -h /
watch -n5 df -h /

Free space टप्प्याटप्प्याने कमी होत असल्यास download अजून सुरू आहे. Command अजून busy असताना free space कमी होणे थांबले असल्यास download पूर्ण झाला आहे आणि memory मध्ये load सुरू झाला आहे.

म्हणूनच model आधीच pull करून ठेवणे योग्य ठरते. ollama run टाइप करणाऱ्या व्यक्तीने download साठी प्रतीक्षा करू नये.

मॉडेलची मागणी होण्यापूर्वी ते डाउनलोड करा

व्यक्ती नसलेल्या कोणत्याही गोष्टीसाठी हेच लागू होते: तुमच्या Ollama endpoint कडे निर्देश केलेला coding agent मोठ्या आकाराचे download पूर्ण होईपर्यंत थांबण्याऐवजी पहिल्याच request वर सहसा थांबतो. नवीन मशीनवर server install करणाऱ्या त्याच script मध्ये model pull करा:

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

तुम्ही server प्रथमच सुरू करत असाल, तर VPS वर संपूर्ण Ollama install मध्ये service आणि तिच्यापर्यंत पोहोचण्याची परवानगी कोणाला आहे हे दोन्ही स्पष्ट केले आहे. त्यानंतर terminal बंद झाल्यानंतरही सुरू राहणारा pull सेट करणे महत्त्वाचे आहे. मधेच बंद झालेला download अनेकदा model store अर्धवट भरलेला ठेवतो.

तो tmux मध्ये चालवा किंवा boot वेळी एकदाच चालणाऱ्या unit म्हणून systemd कडे द्या. /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

दोन्ही commands जाणूनबुजून /bin/sh -c मार्फत चालतात. साध्या ExecStart= साठी absolute path आवश्यक असतो. Installer binary नेहमी त्याच directory मध्ये ठेवत नाही. त्यामुळे तुमच्या मशीनवरील command -v ollama हाच एकमेव विश्वासार्ह पर्याय आहे. Shell मार्फत चालवल्यास guide मधून कॉपी केलेल्या path ऐवजी service PATH वापरला जातो. पहिला ExecStart देखील आवश्यक आहे: After=ollama.service याचा अर्थ server unit सुरू झाला आहे; server ready आहे असा त्याचा अर्थ नाही. त्यामुळे pull सुरू होण्यापूर्वी loop ollama list कडून उत्तर मिळेपर्यंत थांबतो.

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

Journal मध्ये pull कोणत्याही error शिवाय पूर्ण झाल्याचे दिसले पाहिजे. त्यानंतर ollama list मध्ये model दिसला पाहिजे. बदलणारा tag अद्ययावत ठेवण्यासाठी systemd timer किंवा weekly cron entry जोडा आणि त्यातून हाच pull चालवा. बदललेल्या tag चा पुन्हा pull केल्यावर नवीन layers डाउनलोड होतात. जुन्या layers कडे कोणताही संदर्भ राहत नाही. Server पुढच्या वेळी सुरू झाल्यावर त्या साफ केल्या जातात.

पुलमध्ये व्यत्यय आल्यावर काय होते

मॉडेलमधील प्रत्येक layer त्याच्या स्वतःच्या contents च्या hash अंतर्गत साठवला जातो. त्यामुळे pull मध्ये व्यत्यय आला तरी आधी केलेले काम वाया जात नाही: तोच ollama pull पुन्हा चालवा. आधी पूर्ण झालेले layers ओळखले जातात आणि वगळले जातात. त्यामुळे download ज्या layer वर थांबले होते, तिथून पुढे सुरू होते.

मात्र एका कृतीमुळे ही प्रगती नष्ट होते. Ollama server सुरू झाल्यावर, कोणत्याही model manifest कडून संदर्भित नसलेले साठवलेले layers काढून टाकतो. बंद पडलेल्या pull ने मागे ठेवलेला partial layer नेमका तसाच असतो. त्यामुळे पुन्हा प्रयत्न करण्यापूर्वी service restart केल्यास आधी download केलेला भाग नष्ट होतो. आधी pull पुन्हा करून पाहा आणि नंतर restart करा. Partial download ने restart नंतरही टिकून राहणे खरोखर आवश्यक असल्यास, service environment मध्ये OLLAMA_NOPRUNE=1 सेट करा. नंतर ते काढून टाका, कारण orphaned layers disk वर साचू नयेत यासाठी startup cleanup आवश्यक आहे.

Pull no space left on device सह बंद पडला असल्यास, पुन्हा प्रयत्न करण्यापूर्वी मोकळी जागा उपलब्ध करा. df पूर्ण disk दाखवत असेल आणि model directory वरील du त्याचे कारण स्पष्ट करत नसेल, तर जागा दुसरीकडे वापरली गेली आहे. काहीही delete करण्यापूर्वी df आणि du मधील फरकाची कारणे वाचणे उपयुक्त ठरेल.

Ollama मॉडेल्स VPS वर कुठे साठवतो?

या मार्गदर्शकातील path वरही आंधळा विश्वास ठेवू नका. स्वतःच्या box ला त्याचे मॉडेल्स कुठे आहेत ते विचारा. package install आणि container यांमध्ये location वेगळी असते. तसेच कोणी OLLAMA_MODELS सेट केले असल्यास location पुन्हा बदलते.

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

systemctl cat प्रत्येक drop-in सह unit file प्रिंट करतो. त्यामुळे तुम्ही सेट केलेली किंवा तुमच्या image मध्ये आधीपासून असलेली OLLAMA_MODELS line तिथे दिसते. अशी line नसल्यास, store हा service ज्या account अंतर्गत चालतो त्या account च्या home directory खाली असतो. getent passwd ही home directory colon-separated output मधील सहाव्या field मध्ये प्रिंट करतो. find एका filesystem मध्ये blobs directory शोधतो. प्रत्यक्ष layers याच directory मध्ये लिहिल्या जातात. मॉडेल्स आधीपासून वेगळ्या mount वर असण्याची शक्यता असल्यास -xdev काढून टाका.

आता मोजमाप करा आणि स्वतःचे आकडे वाचा:

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

Store चे दोन भाग आहेत. manifests मध्ये प्रत्येक model tag साठी एक छोटी file असते. त्या tag पासून कोणते layers तयार झाले आहेत, हे त्या file मध्ये नमूद केलेले असते. blobs मध्ये प्रत्यक्ष layers असतात. प्रत्येक layer ला त्याच्या contents च्या hash वर आधारित नाव दिलेले असते आणि जवळपास संपूर्ण size तिथेच असतो. Layers वेगवेगळ्या tags मध्ये shared असल्यामुळे, समान weights वर तयार केलेले दोन models ollama list मध्ये प्रत्येकी आपापला size दाखवतात; मात्र disk वर ती जागा एकदाच वापरली जाते. त्यामुळे दाखविलेल्या sizes ची बेरीज du ने directory साठी दाखविलेल्या size पेक्षा जास्त असू शकते.

Model files छोट्या VPS root filesystem ला तुम्ही बहुधा install कराल अशा इतर कोणत्याही गोष्टीपेक्षा जलद भरतात. त्यांच्या size वर सर्वाधिक परिणाम करणारा घटक म्हणजे weight format. q4, q8 आणि fp16 मधील निवड केल्यास प्रत्येक model साठी अनेक gigabytes ची बचत होऊ शकते.

मॉडेल्स OLLAMA_MODELS वापरून data volume वर हलवा

योजनेत दुसरी disk किंवा मोठा data volume असल्यास, root filesystem भरून जाण्यापूर्वी models store हलवा. सर्वप्रथम server थांबवा, जेणेकरून अद्याप लिहिली जात असलेली file copy होणार नाही.

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 drop-in file उघडते. त्यामुळे packaged unit मध्ये बदल होत नाही आणि package upgrade तुमचा बदल overwrite करू शकत नाही. या दोन ओळी जोडा:

[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 ने तुमचा नवीन path दाखवला पाहिजे आणि ollama list ने हलवण्यापूर्वी दिसत असलेलेच models दाखवले पाहिजेत. रिकामी list असल्यास server नवीन directory वाचू शकत नाही. सेवा ollama user म्हणून चालते. त्यामुळे त्या user ला destination वर read आणि write access आवश्यक आहे. वरील chown line हे access देते. नवीन path संदर्भातील permission errors साठी journalctl -e -u ollama तपासा. List योग्य असल्याची खात्री झाल्यावरच जुनी copy delete करा. कारण move अयशस्वी झाल्यानंतर source delete केल्यास सर्व files पुन्हा download कराव्या लागतील.

दुसरा पर्याय मूळ path ठेवतो आणि data volume त्यावर mount करतो:

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 ने mount दाखवला असल्यास bind सक्रिय आहे. Server वरील दुसरी एखादी गोष्ट default location अपेक्षित करत असल्यास bind mount उपयुक्त ठरतो. मात्र यात एक अडचण आहे: तुम्ही बाहेर copy केलेल्या files root disk वरील mount point खालीच राहतात. Mount मुळे त्या लपलेल्या दिसतात. त्यामुळे unmount करून त्या files remove करेपर्यंत disk space परत मिळत नाही. पुढील login करणाऱ्या व्यक्तीला समजावून सांगण्यासाठी environment variable हा दोन पर्यायांपैकी सोपा पर्याय आहे.

कंटेनर त्यांना त्याऐवजी कुठे ठेवतो

अधिकृत image मॉडेल्स तुम्ही mount केलेल्या ठिकाणी साठवते. ती कोणत्याही ollama user च्या मालकीच्या host directory मध्ये साठवत नाही. दस्तऐवजीकरणातील run command अशी आहे:

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

कोलनच्या आधीचे ollama हे named Docker volume आहे. /root/.ollama हे container मधील ते ठिकाण आहे जिथे server लिहितो. त्यामुळे मागील विभागातील paths वर du चालवल्यास काहीही सापडत नाही, कारण तेथे काहीही नसते. प्रत्यक्ष location आणि size दाखवा:

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

docker volume inspect मधील Mountpoint field वाचा आणि त्यावर sudo du -sh चालवा. मॉडेल्स data volume वर ठेवण्यासाठी named volume ऐवजी host directory (-v /mnt/data/ollama:/root/.ollama) द्या आणि container पुन्हा तयार करा. container root म्हणून लिहितो. त्यामुळे ती host directory root च्या मालकीची होते. rootless Podman मध्ये ids तुमच्या user च्या subuid range मध्ये map केले जातात. त्यामुळे host वरील ownership पुन्हा वेगळी दिसते: rootless Podman अंतर्गत Ollama चालवणे या mapping चे स्पष्टीकरण देते.

cleanup बाबत एक सूचना. कोणत्याही container कडून संदर्भित नसलेले प्रत्येक volume docker volume prune काढते. ollama container त्याच्या volume शिवाय काढला किंवा पुन्हा तयार केला, तर नंतरचा prune तुम्ही download केलेले प्रत्येक मॉडेल काढून टाकतो. ते पुन्हा download करण्याशिवाय परत मिळवण्याचा कोणताही मार्ग राहत नाही. मॉडेल्स host करणाऱ्या box वर prune चालवण्यापूर्वी VPS वरील Docker disk usage prune कसे करावे वाचा.

ollama rm वापरून मॉडेल काढा; rm वापरू नका

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm त्या tag साठीचे manifest हटवते. त्यानंतर कोणत्याही उरलेल्या manifest मध्ये संदर्भ नसलेले layers हटवते. या files unlink होताच जागा मोकळी होते. त्यामुळे df ची प्रक्रिया लगेच पूर्ण होते. Layers share केलेले असल्यामुळे, एकमेकांशी जवळचे संबंध असलेल्या दोन tags पैकी एक काढल्यावर ollama list च्या बाजूला दाखवलेल्या आकारापेक्षा खूपच कमी जागा मोकळी होऊ शकते. हे अपेक्षित वर्तन आहे. Delete अयशस्वी झालेले नाही.

Files हाताने हटवल्यास ही जोडी विस्कळीत होते. rm वापरून blob काढल्यास manifest मध्ये त्याचा संदर्भ राहतो. त्यामुळे ollama list मॉडेल दाखवत राहते, परंतु missing layer वाचताना ते वापरण्याचा प्रत्येक प्रयत्न अयशस्वी होतो. Manifest हाताने काढल्यास त्याचे layers disk वरच राहतात, पण त्यांचा संदर्भ देणारे काहीही उरत नाही. त्यामुळे अशी जागा व्यापली जाते जी कोणतीही Ollama command तुम्हाला दाखवणार नाही. हे आधीच केले असल्यास, tag वर ollama rm चालवल्याने उरलेली entry साफ होते. Server पुन्हा सुरू केल्यावर कोणत्याही संदर्भाशिवाय राहिलेले layers साफ होतात.

शेवटचा एक फरक लक्षात ठेवा, कारण हे दोन्ही सतत गोंधळले जातात. ollama rm disk शी संबंधित आहे. ollama stop gemma4 मॉडेल memory मधून unload करते आणि disk वरील जागा मोकळी करत नाही. Download पूर्ण झाल्यानंतर मॉडेल RAM मध्ये किती काळ resident राहील, हे स्वतंत्र setting आहे. प्रत्येक request वेळी पुन्हा load करण्याऐवजी मॉडेल loaded ठेवणे या setting चे स्पष्टीकरण देते.

FAQ

ollama pull आणि ollama run यांच्यात काय फरक आहे?

ollama pull मॉडेल डिस्कवर डाउनलोड करून बंद होते. ollama run मॉडेल आधीच डिस्कवर आहे का ते तपासते; नसल्यास ते डाउनलोड करते, मेमरीमध्ये लोड करते आणि त्यानंतर परस्परसंवादी chat session सुरू करते. दोन्ही commands समान files समान directory मध्ये लिहितात. Provisioning आणि scripts मध्ये pull वापरा; keyboard समोर वापरकर्ता उपस्थित असताना run वापरा. ollama run <model> "your prompt" एक prompt पाठवून बंद होते. हा run चा script मध्ये वापरता येणारा प्रकार आहे.

माझे पहिले ollama run अडकले आहे असे का वाटते?

ते डाउनलोड होत आहे. मॉडेल डिस्कवर उपलब्ध होऊन मेमरीमध्ये लोड होईपर्यंत chat prompt दिसू शकत नाही. मॉडेलचा आकार अनेक gigabytes असतो. Ollama progress bar फक्त output terminal असताना दाखवते. त्यामुळे script, cron job किंवा ssh host ollama run ... मधील run कार्यरत असताना काहीही दाखवत नाही. दुसरे session उघडा आणि watch -n5 df -h / चालवा. मोकळी जागा टप्प्याटप्प्याने कमी होत असल्यास download सुरू आहे. मॉडेल आधीच pull करा; त्यामुळे प्रतीक्षा टळेल.

Ollama आपली models कुठे साठवते?

स्थान install पद्धतीवर अवलंबून असते. त्यामुळे अंदाज न लावता ते print करा. unit किंवा drop-in मध्ये OLLAMA_MODELS सेट आहे का हे पाहण्यासाठी systemctl cat ollama.service चालवा. ते सेट नसल्यास store हा सेवा ज्या account म्हणून चालते त्या account च्या home directory अंतर्गत असतो. हे home directory getent passwd ollama print करते. Layer directory थेट शोधण्यासाठी sudo find / -xdev -type d -name blobs 2>/dev/null वापरा. Container image साठी store mounted volume मध्ये असतो. त्याचा host Mountpoint docker volume inspect ollama print करते.

Ollama models दुसऱ्या disk वर कशा हलवायच्या?

सेवा थांबवा. rsync -a वापरून store नवीन स्थानावर copy करा. sudo chown -R ollama:ollama <directory> वापरून directory सेवा account ला द्या. त्यानंतर sudo systemctl edit ollama.service चालवा आणि [Service] line अंतर्गत Environment="OLLAMA_MODELS=<directory>" जोडा. sudo systemctl daemon-reload वापरून reload करा आणि सेवा restart करा. systemctl show ollama --property=Environment आणि ollama list वापरून पडताळणी करा. यादी रिकामी असल्यास जवळजवळ नेहमीच ollama user नवीन directory वाचू शकत नाही. journalctl -e -u ollama path दाखवेल.

Model files हटवल्याने disk space मोकळी होते का?

हाताने files हटवल्यास bytes मोकळे होतात; परंतु store विसंगत राहतो. Blob हटवला तरी manifest मध्ये ते model नोंदलेले राहते. त्यामुळे ते ollama list मध्ये दिसत राहते आणि वापरताना failure येतो. Manifest हटवल्यास त्याचे layers disk वर राहतात, पण त्यांचा संदर्भ देणारे काहीही उरत नाही. ollama rm <model> वापरा. हे manifest हटवते आणि इतर कोणत्याही model ला आवश्यक नसलेले layers त्यानंतर हटवते. Files आधीच हाताने हटवले असतील, तर entry साफ करण्यासाठी tag वर ollama rm चालवा. त्यानंतर server restart करा. कोणत्याही manifest मध्ये संदर्भ नसलेले layers यामुळे हटवले जातात.