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 میں محفوظ ہے۔ دوسری interactive chat session کھولتی ہے؛ اسے چھوڑنے کے لیے /bye لکھیں یا Ctrl+D دبائیں۔ تیسری ایک single prompt بھیجتی ہے، جواب print کرتی ہے اور exit ہو جاتی ہے۔ جب script کو session کے بجائے جواب درکار ہو تو یہی form مناسب ہے۔ اس تیسرے form میں بھی جواب کی لمبائی مکمل طور پر ماڈل پر منحصر رہتی ہے۔ اس لیے one-line سوال کے جواب میں تین paragraphs آ سکتے ہیں۔ num_predict کے ذریعے جواب کی حد مقرر کرنا scripted run کو اس سائز کے اندر رکھتا ہے جسے caller حقیقتاً استعمال کر سکتا ہے۔ Model names تیزی سے تبدیل ہوتے ہیں، اس لیے یہاں gemma4 کو placeholder سمجھیں۔ August 2026 تک یہ وہ example ہے جسے official Ollama documentation استعمال کرتی ہے، اور library کا کوئی بھی tag اسی طرح کام کرتا ہے۔ اگر آپ ایسا model استعمال کرنا چاہیں جسے کسی نے حقیقی server کے مطابق پہلے ہی size کیا ہو تو VPS پر Nemotron 3.5 Lightning چلانے میں pull کرنے کے لیے exact tag اور درکار memory دی گئی ہے۔

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

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

دو چیزیں یہ عمل چھپا دیتی ہیں۔ Ollama اپنا progress bar صرف اسی وقت دکھاتی ہے جب اس کا output terminal ہو۔ اس لیے shell script، cron job، CI step یا سادہ ssh host ollama run ... کے اندر موجود run download کے دوران کچھ بھی print نہیں کرتی۔ پھر bytes ڈسک پر آ جانے کے بعد بھی پہلے token سے پہلے file کو ڈسک سے 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 ٹائپ کرے، download کی لاگت اسی وقت ادا کرنے والا شخص نہیں ہونا چاہیے۔

ماڈل پہلے ہی pull کر لیں، اس سے پہلے کہ کوئی اس کی درخواست کرے

یہ بات ہر اس چیز پر بھی لاگو ہوتی ہے جو انسان نہیں ہے: آپ کے Ollama endpoint کی طرف اشارہ کیا گیا coding agent عموماً کئی GB کی download مکمل ہونے کا انتظار کرنے کے بجائے پہلی request پر ہی دست بردار ہو جائے گا۔ نئے box پر server install کرنے والے اسی script میں model بھی pull کر لیں:

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

اگر آپ پہلی بار server تیار کر رہے ہیں تو VPS پر مکمل Ollama install میں 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 میں نہیں رکھتا؛ اس لیے اپنے box پر 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 دکھانا چاہیے۔ کسی moving tag کو تازہ رکھنے کے لیے systemd timer یا weekly cron entry شامل کریں جو یہی pull چلاتی ہو۔ منتقل ہو جانے والے tag کو دوبارہ pull کرنے سے نئی layers download ہوتی ہیں، جبکہ پرانی layers کے لیے کوئی reference باقی نہیں رہتا۔ server اگلی بار start ہونے پر یہ غیر متعلقہ layers صاف ہو جاتی ہیں۔

پل میں رکاوٹ آنے پر کیا ہوتا ہے

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

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

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

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

کسی بھی guide، بشمول اس guide، میں دیے گئے path پر بھروسا کرنے کے بجائے اپنے سرور سے خود معلوم کریں۔ 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 ہٹا دیں۔

اب جگہ استعمال کی مقدار معلوم کریں اور اپنے نتائج دیکھیں:

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

store کے 2 حصے ہیں۔ manifests میں ہر model tag کے لیے ایک چھوٹی file ہوتی ہے، اور وہ file ان layers کی فہرست دیتی ہے جن سے tag بنایا گیا ہے۔ blobs میں اصل layers ہوتی ہیں۔ ہر layer کا نام اس کے contents کے hash کے مطابق ہوتا ہے، اور تقریباً پوری جگہ یہی استعمال کرتی ہیں۔ Layers مختلف tags کے درمیان shared ہوتی ہیں۔ اس لیے ایک ہی weights پر بنائے گئے 2 models ollama list میں اپنا اپنا size دکھاتے ہیں، لیکن disk پر وہ جگہ صرف 1 بار استعمال ہوتی ہے۔ اسی وجہ سے درج شدہ sizes کا مجموعہ du کی جانب سے directory کے لیے دکھائی گئی مقدار سے زیادہ ہو سکتا ہے۔

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

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

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

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

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

cleanup کے بارے میں ایک انتباہ۔ docker volume prune ہر اس volume کو ہٹا دیتا ہے جسے کوئی container refer نہیں کرتا۔ اگر آپ ollama container کو اس کے volume کے بغیر remove یا recreate کرتے ہیں تو بعد میں prune آپ کے download کیے گئے تمام models حذف کر دے گا۔ انہیں دوبارہ download کرنے کے سوا واپسی کا کوئی طریقہ نہیں ہوگا۔ models host کرنے والے 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 میں موجود نہیں ہوتا۔ یہ files unlink ہوتے ہی جگہ دوبارہ دستیاب ہو جاتی ہے، اس لیے df فوراً مکمل ہو جاتا ہے۔ چونکہ layers مشترکہ ہوتی ہیں، اس لیے دو قریبی متعلقہ tags میں سے ایک کو ہٹانے سے عموماً ollama list کے ساتھ دکھائے گئے size سے کہیں کم جگہ خالی ہو سکتی ہے۔ یہ درست رویہ ہے، delete کی ناکامی نہیں۔

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

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

FAQ

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

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

میرا پہلا ollama run رک گیا ہوا کیوں محسوس ہوتا ہے؟

یہ download کر رہا ہوتا ہے۔ Chat prompt اس وقت تک ظاہر نہیں ہو سکتا جب تک ماڈل disk پر موجود نہ ہو اور memory میں load نہ ہو جائے، جبکہ ایک ماڈل کئی 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 کہاں محفوظ کرتا ہے؟

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

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

Service روکیں، rsync -a کے ذریعے store کو نئے مقام پر 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 کے ذریعے تصدیق کریں۔ خالی list کا تقریباً ہمیشہ مطلب یہ ہوتا ہے کہ ollama user نئی directory کو پڑھ نہیں سکتا؛ journalctl -e -u ollama path کا نام بتا دے گا۔

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

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