Ollama pull आणि run: मॉडेल कुठे साठते?

ollama pull आणि ollama run मधील फरक

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

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

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

पहिली ओळ मॉडेल आणून बाहेर पडते. त्यामुळे ती provisioning आणि systemd unit मध्ये सुरक्षितपणे वापरता येते. दुसरी ओळ chat session उघडते; त्यातून बाहेर पडण्यासाठी /bye टाइप करा किंवा Ctrl+D दाबा. तिसरी ओळ एकच prompt पाठवते, उत्तर दाखवते आणि बाहेर पडते. Session ऐवजी उत्तर आवश्यक असताना script साठी हाच प्रकार योग्य असतो. Model names लवकर बदलतात. त्यामुळे येथे gemma4 हे placeholder समजा: August 2026 पर्यंत अधिकृत Ollama documentation मध्ये वापरलेले हे उदाहरण आहे. Library मधील कोणताही tag याच प्रकारे कार्य करतो.

पहिला 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 धीमा असतो. 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 type करणाऱ्या व्यक्तीने download साठी प्रतीक्षा करू नये.

कोणी मागण्यापूर्वी model pull करा

नवीन box वर server install करणाऱ्या त्याच script मध्ये pull समाविष्ट करा:

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

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

हे tmux मध्ये चालवा किंवा boot वेळी चालणाऱ्या one-shot 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 मध्ये ठेवत नाही. त्यामुळे तुमच्या box वरील command -v ollama हाच विश्वसनीय पर्याय आहे. Shell मार्फत चालवल्याने guide मधून कॉपी केलेल्या path ऐवजी service PATH वापरला जातो. पहिला ExecStart देखील महत्त्वाचा आहे: After=ollama.service याचा अर्थ server unit सुरू झाली आहे; server वापरासाठी तयार आहे असा त्याचा अर्थ नाही. त्यामुळे 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 किंवा साप्ताहिक cron entry जोडा आणि त्यातून तोच pull चालवा. बदललेल्या tag साठी पुन्हा pull केल्यास नवीन layers download होतात. जुन्या layers कडे कोणताही संदर्भ उरत नाही आणि server पुढील वेळी सुरू झाल्यावर त्या साफ केल्या जातात.

पुल मध्ये खंड पडल्यावर काय होते

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

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

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

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

या मार्गदर्शिकेतील path वरही विश्वास ठेवण्याऐवजी स्वतःच्या मशीनला विचारा. 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 सह unit file प्रिंट करते. त्यामुळे तुम्ही सेट केलेली किंवा image मध्ये आधीपासून असलेली OLLAMA_MODELS line तिथे दिसते. अशी line नसल्यास store हा सेवा ज्या account अंतर्गत चालते त्या account च्या home directory अंतर्गत असतो. getent passwd ही home directory colon ने विभक्त केलेल्या सहाव्या field मध्ये प्रिंट करते. find एका filesystem मध्ये blobs directory शोधते. प्रत्यक्ष layers याच directory मध्ये लिहिल्या जातात. Models वेगळ्या 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 असते. त्या file मध्ये tag कोणत्या layers पासून तयार झाला आहे याची नोंद असते. blobs मध्ये प्रत्यक्ष layers असतात. प्रत्येक layer ला त्याच्या contents च्या hash वर आधारित नाव असते आणि जवळपास संपूर्ण आकार याच ठिकाणी असतो. Layers अनेक tags मध्ये shared असल्यामुळे, समान weights वर तयार केलेली दोन models ollama list मध्ये आपापला आकार दाखवतात; मात्र disk वर ही जागा एकदाच वापरली जाते. त्यामुळे दाखवलेल्या आकारांची बेरीज directory साठी du ने दाखवलेल्या आकारापेक्षा जास्त असू शकते.

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

OLLAMA_MODELS वापरून models data volume वर हलवा

योजनेत दुसरा disk किंवा मोठा data volume असल्यास root filesystem भरून जाण्यापूर्वी 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 मध्ये editor उघडते. त्यामुळे packaged unit मध्ये बदल होत नाही आणि package upgrade तुमचा बदल overwrite करू शकत नाही. या दोन lines जोडा:

[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 ने move करण्यापूर्वी दिसत असलेलेच models दाखवले पाहिजेत. रिकामी list म्हणजे server नवीन directory वाचू शकत नाही. Service ollama user म्हणून चालते. त्यामुळे त्या user ला destination वर read आणि write access आवश्यक आहे. हे वरील chown line चे काम आहे. नवीन path चा उल्लेख असलेल्या permission errors साठी journalctl -e -u ollama तपासा. List योग्य असल्याची खात्री झाल्यानंतरच जुनी copy delete करा. Move अयशस्वी झाल्यावर source delete केल्यास सर्व काही पुन्हा 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 mount कार्यरत आहे. Box वरील दुसरी एखादी गोष्ट default location ची अपेक्षा करत असल्यास bind mount उपयुक्त ठरतो. यामध्ये एक अडचण आहे: तुम्ही copy केलेल्या files mount point अंतर्गत root disk वरच राहतात, पण mount मुळे त्या लपतात. त्यामुळे unmount करून त्या files remove करेपर्यंत space परत मिळत नाही. पुढे login करणाऱ्या व्यक्तीला समजावून सांगण्यासाठी environment variable हा दोन पर्यायांपैकी सोपा पर्याय आहे.

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

अधिकृत image models तुम्ही mount केलेल्या ठिकाणी साठवते. ती कोणत्याही ollama वापरकर्त्याशी संबंधित 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 लिहितो. त्यामुळे मागील section मधील 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 चालवा. Models 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 बाबत एक सूचना. docker volume prune कोणत्याही container कडून संदर्भित नसलेले प्रत्येक volume काढून टाकते. Volume शिवाय ollama container काढला किंवा पुन्हा तयार केला, तर नंतरचा prune तुम्ही download केलेले प्रत्येक model हटवतो. ते पुन्हा मिळवण्याचा एकमेव मार्ग म्हणजे ते पुन्हा download करणे. Models असलेल्या VPS वर 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 सामायिक केलेले असल्यामुळे, परस्परांशी जवळचे संबंध असलेल्या दोन tags पैकी एक काढल्यास, त्याच्या शेजारी ollama list ने दाखवलेल्या आकारापेक्षा खूपच कमी जागा मोकळी होऊ शकते. हे अपेक्षित वर्तन आहे; delete अयशस्वी झालेले नाही.

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

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

FAQ

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

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

माझे पहिले ollama run अडकल्यासारखे का दिसते?

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

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

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

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

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

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

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