ollama pull اور run میں فرق، ماڈل کہاں محفوظ ہوتے ہیں

ollama pull بمقابلہ ollama run

ollama pull ماڈل download کرتا ہے اور پھر رک جاتا ہے۔ ollama run ماڈل صرف اس وقت download کرتا ہے جب وہ موجود نہ ہو، پھر اسے memory میں load کرتا ہے اور interactive chat کھول دیتا ہے۔ download کا عمل یکساں ہوتا ہے اور files بھی اسی جگہ محفوظ ہوتی ہیں۔ اس کے بعد صرف run چلتا رہتا ہے۔

یہی ایک فرق طے کرتا ہے کہ script میں کون سا command استعمال ہونا چاہیے اور keyboard پر کون سا۔

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

پہلی line ماڈل fetch کرکے exit ہو جاتی ہے، اس لیے provisioning اور systemd unit میں محفوظ ہے۔ دوسری ایک chat session کھولتی ہے؛ اسے چھوڑنے کے لیے /bye لکھیں یا Ctrl+D دبائیں۔ تیسری ایک single prompt بھیجتی ہے، جواب print کرتی ہے اور exit ہو جاتی ہے۔ جب script کو session کے بجائے جواب درکار ہو تو یہی مطلوبہ طریقہ ہے۔ Model names تیزی سے تبدیل ہوتے ہیں، اس لیے یہاں gemma4 کو placeholder سمجھیں: August 2026 تک یہ official Ollama documentation میں استعمال ہونے والی مثال ہے، اور library کا کوئی بھی tag اسی طرح کام کرتا ہے۔

پہلی ollama run کمانڈ کے منجمد محسوس ہونے کی وجہ

نئے VPS پر پہلی run کئی منٹ تک بغیر کسی output کے چل سکتی ہے۔ کوئی خرابی نہیں ہوتی۔ Chat prompt اس وقت تک ظاہر نہیں ہو سکتا جب تک model disk پر محفوظ ہو کر memory میں load نہ ہو جائے۔ اس لیے run پہلے کئی gigabytes کا download کرتی ہے، پھر کوئی output دکھاتی ہے۔

اس کام کے نظر نہ آنے کی دو وجوہات ہیں۔ 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 پر یہ عمل سست ہو سکتا ہے۔ اگر machine کے پاس model کے لیے کافی memory نہ ہو تو kernel swapping شروع کر دیتا ہے، اور انتظار بہت بڑھ جاتا ہے۔

اندازہ لگانے کے بجائے دوسری session سے اسے monitor کریں:

df -h /
watch -n5 df -h /

اگر free space مرحلہ وار کم ہو رہی ہو تو download ابھی جاری ہے۔ اگر command مصروف ہو لیکن free space کم ہونا رک جائے تو download مکمل ہو چکا ہے اور memory میں load ہونا شروع ہو گیا ہے۔

اسی لیے model پہلے سے pull کرنا بہتر ہے۔ جو شخص ollama run type کرتا ہے، اسے download کے انتظار کی قیمت کبھی نہیں چکانی چاہیے۔

ماڈل کے طلب کیے جانے سے پہلے اسے pull کریں

نئے server پر، اسی script میں model pull کریں جو server انسٹال کرتی ہے:

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

اگر آپ پہلی بار server تیار کر رہے ہیں تو VPS پر مکمل Ollama انسٹالیشن میں service اور اس تک رسائی کی اجازت رکھنے والے صارفین کی تفصیل موجود ہے۔ اس کے بعد ایسا pull ترتیب دینا مفید ہے جو آپ کے terminal سے باہر بھی جاری رہے، کیونکہ download کا درمیان میں رک جانا model store کے نامکمل طور پر بھرنے کا سبب بنتا ہے۔

اسے tmux کے اندر چلائیں، یا اسے systemd کے one-shot unit کے طور پر boot پر چلانے کے لیے دیں۔ /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 میں نہیں رکھتا۔ اس لیے اپنے server پر command -v ollama ہی قابلِ اعتماد جواب ہے۔ Shell کے ذریعے چلانے سے guide سے نقل کیے گئے path کے بجائے service کا PATH استعمال ہوتا ہے۔ پہلا ExecStart بھی اہم ہے: After=ollama.service کا مطلب ہے کہ server unit شروع ہو چکا ہے، یہ ready ہونے کے برابر نہیں۔ اس لیے loop pull شروع ہونے سے پہلے 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 کے لیے کوئی reference باقی نہیں رہتا۔ اگلی بار server شروع ہونے پر یہ layers صاف کر دی جاتی ہیں۔

Pull interrupted ہونے پر کیا ہوتا ہے

ماڈل کی ہر layer اس کے اپنے contents کے hash کے تحت محفوظ ہوتی ہے۔ اس لیے interrupted pull کا کام ضائع نہیں ہوتا: وہی ollama pull دوبارہ چلائیں۔ جو layers پہلے ہی مکمل ہو چکی ہیں، انہیں پہچان کر skip کر دیا جاتا ہے، اور download اسی layer سے جاری ہوتا ہے جہاں یہ رک گیا تھا۔

ایک action اس progress کو ختم کر دیتا ہے۔ Ollama server شروع ہونے پر ان محفوظ layers کو حذف کر دیتا ہے جن کا کسی model manifest میں حوالہ موجود نہ ہو۔ dead pull سے بچ جانے والی partial layer بھی بالکل ایسی ہی ہوتی ہے۔ اس لیے retry کرنے سے پہلے service restart کرنے پر پہلے سے download کیا گیا حصہ ضائع ہو جاتا ہے۔ پہلے pull retry کریں اور بعد میں restart کریں۔ اگر partial download کا restart کے بعد برقرار رہنا واقعی ضروری ہو تو service environment میں OLLAMA_NOPRUNE=1 set کریں، پھر اسے دوبارہ remove کر دیں، کیونکہ startup cleanup ہی orphaned layers کو disk پر جمع ہونے سے روکتا ہے۔

اگر pull no space left on device کے ساتھ ختم ہوا ہو تو retry سے پہلے space خالی کریں۔ اگر df full disk کی اطلاع دے اور model directory میں du اس کی وضاحت نہ کرے تو space کسی اور جگہ استعمال ہوئی ہے۔ کچھ بھی delete کرنے سے پہلے df اور du کے مختلف نتائج کی وجوہات پڑھنا مفید ہوگا۔

Ollama ماڈلز VPS پر کہاں محفوظ کرتا ہے؟

کسی بھی guide، بشمول اس guide، میں دیے گئے path پر بھروسا کرنے کے بجائے اپنے server سے خود معلوم کریں۔ Package install اور container کے درمیان location مختلف ہوتی ہے، اور اگر کسی نے OLLAMA_MODELS set کیا ہو تو location دوبارہ تبدیل ہو جاتی ہے۔

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

systemctl cat unit file کو تمام drop-in کے ساتھ دکھاتا ہے، اس لیے آپ کی set کی ہوئی یا image میں شامل OLLAMA_MODELS line وہاں نظر آتی ہے۔ اگر ایسی line موجود نہ ہو تو store اس account کی home directory کے اندر ہوتا ہے جس کے نام سے service چلتی ہے، اور getent passwd اس home directory کو colon سے الگ کیے گئے چھٹے field میں دکھاتا ہے۔ find ایک filesystem میں blobs directory تلاش کرتا ہے، جہاں layers دراصل لکھی جاتی ہیں۔ اگر models پہلے ہی کسی الگ mount پر موجود ہو سکتے ہوں تو -xdev ہٹا دیں۔

اب size ناپیں اور اپنے حاصل کردہ 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 ہوتی ہیں۔ ہر layer کا نام اس کے contents کے hash کے مطابق ہوتا ہے، اور تقریباً سارا size وہیں ہوتا ہے۔ Layers مختلف tags کے درمیان shared ہوتی ہیں، اس لیے ایک ہی weights پر بنائے گئے دو models ollama list میں اپنا اپنا size دکھاتے ہیں، جبکہ disk پر وہ جگہ صرف ایک بار استعمال ہوتی ہے۔ اسی وجہ سے درج شدہ sizes کا مجموعہ directory کے لیے du کے دکھائے گئے size سے زیادہ ہو سکتا ہے۔

Model files ایک چھوٹے VPS root filesystem کو عموماً کسی بھی دوسری install کی جانے والی چیز سے زیادہ تیزی سے بھر دیتی ہیں۔ ان کے size پر سب سے زیادہ اثر weight format کا ہوتا ہے۔ q4، q8 اور fp16 میں انتخاب فی model کئی gigabytes کے storage کی بچت کر سکتا ہے۔

OLLAMA_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 کو وہی models دکھانے چاہییں جو منتقلی سے پہلے دکھائے گئے تھے۔ خالی list کا مطلب ہے کہ server نئی directory پڑھ نہیں سکتا۔ service ollama user کے طور پر چلتی ہے، اس لیے اس user کو destination پر read اور write access درکار ہے۔ اوپر دی گئی chown line یہی کام کرتی ہے۔ نئی path سے متعلق permission errors کے لیے journalctl -e -u ollama چیک کریں۔ پرانی copy صرف list درست ہونے کے بعد حذف کریں، کیونکہ ناکام منتقلی کے بعد source حذف کرنے کا مطلب ہے کہ سب کچھ دوبارہ download کرنا پڑے گا۔

دوسرا طریقہ اصل path برقرار رکھتا ہے اور data volume کو اسی path پر 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 فعال ہے۔ Bind mount اس وقت مفید ہوتا ہے جب server پر کوئی دوسری چیز پہلے ہی default location کی توقع کر رہی ہو۔ اس میں ایک مسئلہ ہے: جو files آپ نے باہر copy کی تھیں وہ root disk پر mount point کے اندر موجود رہتی ہیں، مگر mount کے باعث چھپی ہوتی ہیں۔ اس لیے space اس وقت تک واپس نہیں ملتی جب تک آپ unmount کر کے انہیں حذف نہ کریں۔ اگلے login کرنے والے شخص کو سمجھانے کے لیے environment variable دونوں طریقوں میں آسان ہے۔

اس کے بجائے container انہیں کہاں محفوظ رکھتا ہے

official image models کو کسی بھی mounted location میں محفوظ کرتی ہے، نہ کہ کسی ollama user سے متعلق host directory میں۔ دستاویزی run command یہ ہے:

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

colon سے پہلے ollama ایک named Docker volume ہے، جبکہ /root/.ollama وہ location ہے جہاں server container کے اندر لکھتا ہے۔ اس لیے پچھلے section کے paths کے خلاف du چلانے پر کچھ نہیں ملتا، کیونکہ models وہاں موجود ہی نہیں ہیں۔ اصل 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 کی ownership root کے پاس چلی جاتی ہے۔ rootless Podman میں ids آپ کے user کی subuid range میں map ہوتی ہیں، اس لیے host ownership دوبارہ مختلف نظر آتی ہے: rootless Podman کے تحت Ollama چلانا اس mapping کی وضاحت کرتا ہے۔

Cleanup کے بارے میں ایک warning ہے۔ docker volume prune ہر اس volume کو remove کر دیتا ہے جس کا کوئی container حوالہ نہیں دیتا۔ ollama container کو اس کے volume کے بغیر remove یا recreate کرنے کے بعد بعد میں چلایا گیا prune آپ کے download کیے گئے تمام models delete کر سکتا ہے۔ انہیں واپس حاصل کرنے کا واحد طریقہ دوبارہ download کرنا ہوگا۔ Models رکھنے والے box پر prune چلانے سے پہلے VPS پر Docker disk usage کو prune کرنے کا طریقہ پڑھیں۔

ollama rm سے model ہٹائیں، rm سے نہیں

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm اس tag کے لیے manifest حذف کرتا ہے، پھر وہ layers حذف کرتا ہے جن کا حوالہ کسی باقی manifest میں موجود نہیں ہوتا۔ فائلیں unlink ہوتے ہی جگہ واپس دستیاب ہو جاتی ہے، اس لیے df فوراً آگے بڑھتا ہے۔ چونکہ layers مشترک ہوتی ہیں، اس لیے قریب سے متعلق دو tags میں سے ایک کو ہٹانے سے ollama list کے ساتھ دکھائے گئے سائز سے کہیں کم جگہ خالی ہو سکتی ہے۔ یہ درست رویہ ہے، ناکام deletion نہیں۔

فائلیں دستی طور پر حذف کرنے سے یہ جوڑا ٹوٹ جاتا ہے۔ rm سے blob حذف کریں تو manifest میں اس کا حوالہ باقی رہتا ہے، اس لیے ollama list model دکھاتا رہتا ہے، لیکن missing layer پڑھتے وقت اسے استعمال کرنے کی ہر کوشش ناکام ہو جاتی ہے۔ manifest دستی طور پر حذف کریں تو اس کی layers disk پر ایسی رہ جاتی ہیں جن کی طرف کوئی حوالہ نہیں ہوتا، اور ایسی جگہ گھیرتی ہیں جسے کوئی Ollama command آپ کو report نہیں کرے گی۔ اگر آپ ایسا کر چکے ہیں تو tag پر ollama rm چلانے سے باقی entry صاف ہو جاتی ہے، اور server restart کرنے سے وہ layers صاف ہو جاتی ہیں جن کی طرف کوئی حوالہ نہیں ہوتا۔

ایک آخری فرق بھی واضح رہنا چاہیے، کیونکہ یہ دونوں اکثر خلط ملط ہو جاتے ہیں۔ ollama rm کا تعلق disk سے ہے۔ ollama stop gemma4 model کو memory سے unload کرتا ہے اور disk کی کوئی جگہ خالی نہیں کرتا۔ Download مکمل ہونے کے بعد model کتنی دیر RAM میں موجود رہے، یہ الگ setting ہے، اور ہر request پر دوبارہ load کرنے کے بجائے model کو loaded رکھنے میں اس کی وضاحت ہے۔

FAQ

ollama pull اور ollama run میں کیا فرق ہے؟

ollama pull ماڈل کو disk پر download کر کے ختم ہو جاتا ہے۔ ollama run پہلے دیکھتا ہے کہ ماڈل disk پر موجود ہے یا نہیں، موجود نہ ہو تو اسے download کرتا ہے، memory میں load کرتا ہے، اور پھر interactive chat session کھولتا ہے۔ دونوں ایک ہی files کو ایک ہی directory میں لکھتے ہیں۔ Provisioning اور scripts میں pull استعمال کریں، اور جب کوئی شخص keyboard پر موجود ہو تو run استعمال کریں۔ ollama run <model> "your prompt" ایک prompt بھیج کر ختم ہو جاتا ہے، جو run کی scriptable شکل ہے۔

میری پہلی run بظاہر رک کیوں جاتی ہے؟

یہ download ہو رہی ہوتی ہے۔ Chat prompt اس وقت تک ظاہر نہیں ہو سکتا جب تک model disk پر موجود اور memory میں load نہ ہو جائے، اور ایک model کئی gigabytes کا ہوتا ہے۔ Ollama اپنا progress bar صرف اس وقت دکھاتا ہے جب output terminal ہو، اس لیے کسی script، cron job یا ssh host ollama run ... کے اندر run کام کے دوران بالکل کچھ نہیں دکھاتا۔ دوسری session کھولیں اور watch -n5 df -h / چلائیں: اگر free space مرحلہ وار کم ہو رہی ہو تو download جاری ہے۔ Model پہلے ہی pull کر لیں، تو یہ انتظار ختم ہو جائے گا۔

Ollama اپنے models کہاں محفوظ کرتا ہے؟

Location installation پر منحصر ہوتی ہے، اس لیے فرض کرنے کے بجائے اسے print کریں۔ systemctl cat ollama.service چلائیں تاکہ معلوم ہو سکے کہ unit یا drop-in میں OLLAMA_MODELS set ہے یا نہیں۔ اگر یہ set نہ ہو تو store اس account کی home directory کے اندر ہوتا ہے جس کے نام سے service چل رہی ہے؛ getent passwd ollama اسے print کرتا ہے۔ sudo find / -xdev -type d -name blobs 2>/dev/null layer directory کو براہ راست locate کرتا ہے۔ Container image کے لیے store mounted volume کے اندر ہوتا ہے، اور docker volume inspect ollama اس کا host Mountpoint print کرتا ہے۔

میں Ollama models کو کسی دوسری disk پر کیسے منتقل کروں؟

Service stop کریں، 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 restart کریں۔ systemctl show ollama --property=Environment اور ollama list کے ذریعے تصدیق کریں۔ تقریباً ہمیشہ empty list کا مطلب یہ ہوتا ہے کہ ollama user نئی directory کو read نہیں کر سکتا؛ journalctl -e -u ollama path کا نام بتا دے گا۔

کیا model files delete کرنے سے space خالی ہو جاتی ہے؟

Files کو ہاتھ سے delete کرنے سے bytes تو خالی ہو جاتے ہیں، لیکن store غیر مستقل حالت میں رہتا ہے۔ کوئی blob remove کرنے پر manifest میں وہ model اب بھی درج رہتا ہے، اس لیے وہ ollama list میں دکھائی دیتا رہتا ہے اور استعمال کے وقت ناکام ہو جاتا ہے۔ اگر manifest remove کریں تو اس کی layers disk پر باقی رہتی ہیں، لیکن ان کی طرف اشارہ کرنے والی کوئی چیز نہیں رہتی۔ ollama rm <model> استعمال کریں؛ یہ manifest delete کرتا ہے، پھر وہ layers بھی delete کرتا ہے جن کی کسی دوسرے model کو ضرورت نہیں۔ اگر files پہلے ہی ہاتھ سے delete کی جا چکی ہوں تو entry صاف کرنے کے لیے tag پر ollama rm چلائیں، پھر server restart کریں؛ اس سے وہ layers remove ہو جائیں گی جن کی طرف کوئی manifest اشارہ نہیں کرتا۔