Ollama model کو memory میں loaded رکھنے کا طریقہ

Ollama چند منٹ بعد model کو unload کیوں کرتا ہے؟

Ollama آخری request کے بعد model کو پانچ منٹ تک memory میں loaded رکھتا ہے، پھر اسے آزاد کر دیتا ہے۔ اگلی request کے وقت weights کو disk سے دوبارہ پڑھ کر RAM یا VRAM میں map کرنا پڑتا ہے، اس لیے پہلا token آنے سے پہلے تاخیر ہوتی ہے۔ اسی وجہ سے chat UI یا coding agent تیز محسوس ہوتا ہے، کچھ دیر خاموش رہتا ہے، پھر اگلے message پر دوبارہ سست محسوس ہوتا ہے۔ کوئی خرابی نہیں ہوئی۔ idle timer کی مدت ختم ہو گئی ہے۔

اس timer کو keep_alive کہا جاتا ہے۔ یہ ہر model کے لیے الگ ہوتا ہے اور ہر request مکمل ہونے پر دوبارہ شروع ہو جاتا ہے۔ جو model اس وقت کسی request کا جواب دے رہا ہو اسے کبھی unload نہیں کیا جاتا، کیونکہ server صرف ایسے model کی مدت ختم کرتا ہے جس کی کوئی active request نہ ہو۔ August 2026 تک default مدت پانچ منٹ ہے، اور یہ اس server کے load کیے جانے والے ہر model پر لاگو ہوتی ہے۔

keep_alive کو set کرنے کے دو مقامات ہیں: انفرادی request میں، یا server default کے طور پر۔ systemd drop-in server default کو restart کے بعد بھی برقرار رکھتا ہے۔ اس guide میں فرض کیا گیا ہے کہ Ollama پہلے ہی service کے طور پر چل رہا ہے۔ اگر ایسا نہیں ہے تو VPS پر Ollama install کرنے سے شروع کریں اور پھر واپس آئیں۔

اس وقت کون سے models memory میں موجود ہیں، اور وہ کب expire ہوں گے؟

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

خالی output کا مطلب ہے کہ کچھ بھی load نہیں ہے، اس لیے اگلی request میں مکمل load time دوبارہ صرف ہوگا۔ PROCESSOR بتاتا ہے کہ weights کہاں موجود ہیں۔ 100% GPU اور 100% CPU واضح حالتیں ہیں۔ 25%/75% CPU/GPU جیسی تقسیم کا مطلب ہے کہ model مکمل طور پر VRAM میں نہیں سما سکا، اس لیے اس کا کچھ حصہ processor پر چلتا ہے اور generation سست ہو جاتی ہے۔

UNTIL باقی وقت کا countdown ہے، اور 4 minutes from now جیسا relative time دکھاتا ہے۔ جب model کو منفی keep_alive کے ساتھ load کیا گیا ہو تو یہ Forever دکھاتا ہے۔ جب server unload ہو رہا ہو تو مختصر مدت کے دوران یہ Stopping... دکھاتا ہے۔

releases کے درمیان columns کا مجموعہ تبدیل ہو چکا ہے، اس لیے script میں fields گننے کے بجائے header پڑھیں۔ خودکار کارروائی کے لیے API سے معلومات حاصل کریں:

curl -s http://localhost:11434/api/ps

ہر entry میں expires_at، 2026-08-09T14:38:31.83753Z جیسا absolute timestamp، اور size_vram شامل ہوتا ہے۔ size_vram اس model کا وہ حصہ ہے جو GPU memory میں موجود ہے۔ size_vram کی قدر 0 ہونے کا مطلب ہے کہ model CPU پر چل رہا ہے۔

اصل reload کی لاگت

اس کا اندازہ نہ لگائیں۔ Ollama ہر response میں load time رپورٹ کرتا ہے، جو load_duration کے طور پر nanoseconds میں دیا جاتا ہے۔

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

پہلی call model کو load کرتی ہے، اس لیے اس کی load_duration بڑی ہوتی ہے۔ اسے seconds میں پڑھنے کے لیے 1000000000 سے تقسیم کریں۔ دوسری call اس وقت چلتی ہے جب model memory میں موجود ہوتا ہے، اس لیے یہ بہت چھوٹی قدر رپورٹ کرتی ہے۔ ان دونوں اعداد کے درمیان فرق وہ لاگت ہے جو timer ختم ہونے کے بعد ہر user کو برداشت کرنا پڑتی ہے، اور یہی keep_alive تبدیل کرنے کی بنیادی وجہ ہے۔ اس فرق کا زیادہ تر حصہ disk read پر مشتمل ہوتا ہے۔ اس لیے اگر آپ نے model directory کو دوسری volume پر منتقل کیا ہے تو اس volume کی رفتار ہر cold load کی کم از کم رفتار طے کرتی ہے۔ اس وقفے سے پہلے اور بعد generation speed کے لیے دیکھیں کہ اپنے box پر tokens per second کی پیمائش کیسے کریں۔

ایک درخواست پر Ollama ماڈل کو میموری میں loaded رکھیں

درخواست کے ساتھ keep_alive بھیجیں۔ درخواست مکمل ہوتے ہی یہ اسی ماڈل پر لاگو ہو جاتا ہے۔

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

چار value formats قبول کیے جاتے ہیں:

• duration string: "30m"، "24h"، "90s"
• سادہ number، جسے seconds کے طور پر پڑھا جاتا ہے: 3600
• negative value، -1 یا "-1m"، جس کا مطلب ہے کہ idle timeout بالکل نہیں ہوگا
• 0، جس کا مطلب ہے کہ یہ درخواست مکمل ہوتے ہی model unload کر دیا جائے

درخواست میں دی گئی value دونوں صورتوں میں server default کو override کرتی ہے۔ یہ بات بظاہر معمولی ہے، لیکن اہم ہے: اگر client اپنی keep_alive بھیجے تو وہ server پر configured کسی بھی value پر غالب ہوگی۔

آپ کوئی output generate کیے بغیر بھی model load کر سکتے ہیں۔ صرف model name بھیجیں۔ server اسے load کرتا ہے اور "done": true کے ساتھ empty response واپس کرتا ہے۔

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

یہ وہ command ہے جسے reboot کے بعد یا نیا model pull کرنے کے بعد چلانا چاہیے، تاکہ پہلے حقیقی user request کو load ہونے کا انتظار نہ کرنا پڑے۔ CLI یہی کام ایک flag کے ذریعے کرتا ہے:

ollama run --keepalive 30m qwen3:8b "hello"

OLLAMA_KEEP_ALIVE کے ذریعے اسے بطور ڈیفالٹ loaded رکھیں

Server startup کے وقت OLLAMA_KEEP_ALIVE پڑھتا ہے اور اسے ہر ایسے model کے لیے استعمال کرتا ہے جس میں اپنی value موجود نہ ہو۔ یہ request field جیسی ہی forms قبول کرتا ہے، اس لیے 30m، 3600 اور -1 سب کام کرتے ہیں۔

اصل مسئلہ یہ ہے کہ یہ environment کس user کے لیے set کیا گیا ہے۔ اپنی SSH session میں export OLLAMA_KEEP_ALIVE=30m چلانے سے کچھ نہیں ہوگا، کیونکہ packaged install server کو اس کے اپنے user اور اپنے environment کے تحت systemd service کے طور پر چلاتا ہے۔ آپ کی login shell اور وہ service ایک دوسرے کے environment تک رسائی نہیں رکھتیں۔ یہی سب سے عام وجہ ہے کہ یہ setting نظرانداز ہوتی محسوس ہوتی ہے۔

systemd drop-in کے ذریعے اسے restart کے بعد بھی فعال رکھیں

sudo systemctl edit ollama.service

ایڈیٹر دو comment markers کے ساتھ کھلتا ہے۔ ان کے درمیان لکھیں: systemd دوسرے marker کے نیچے لکھی ہوئی ہر چیز نظرانداز کر دیتا ہے۔

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

محفوظ کرنے سے /etc/systemd/system/ollama.service.d/override.conf لکھا جاتا ہے۔ یہ shipped unit میں ترمیم کرنے کے بجائے drop-in ہے، اس لیے Ollama package upgrade کے دوران ollama.service تبدیل ہونے پر بھی آپ کی setting برقرار رہتی ہے۔ اگر drop-ins اور unit files آپ کے لیے نئے ہیں تو systemd service اور timer guide میں طریقۂ کار بیان کیا گیا ہے۔

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

آخری command وہ environment دکھاتی ہے جس کے ساتھ service حقیقی طور پر چلے گی۔ اگر اس سطر میں OLLAMA_KEEP_ALIVE=30m موجود نہ ہو تو drop-in لاگو نہیں ہوا۔ اس کی وجہ تقریباً ہمیشہ missing [Service] header یا marker کے نیچے لکھی گئی lines ہوتی ہیں۔ restart کے عمل میں تمام loaded models خارج ہو جاتے ہیں، اس لیے اگلی request cold load ہوگی۔ اوپر دی گئی preload call سے اسے دوبارہ warm کریں۔

ماڈل کو resident رکھنے کی لاگت

ollama ps میں SIZE کالم پوری idle window کے دوران مختص رہنے والی memory دکھاتا ہے، صرف request کے وقت کی memory نہیں۔ 4-bit quantisation والا 8B model عموماً 5 سے 6 GB memory لیتا ہے۔ 27B model کا معاملہ بالکل مختلف ہے، اور صرف CPU والے VPS پر اسے چلانے کے لیے memory کا حساب اس سے پہلے کرنا مفید ہے کہ آپ اسے resident رکھنے کا فیصلہ کریں۔ keep_alive کو -1 پر set کرنے کا مطلب ہے کہ آپ نے مستقل طور پر فیصلہ کر لیا ہے کہ اس box پر model ہر دوسری چیز سے زیادہ اہم ہے۔ چھوٹے VPS پر یہ آپ کے database، web app اور build jobs کے ساتھ براہ راست memory trade-off ہے۔

اندازے پر بھروسا کرنے کے بجائے حقیقی اعداد دیکھیں۔ یہ command اس وقت چلائیں جب model loaded ہو، پھر ollama stop کے بعد دوبارہ چلائیں:

free -h

available کالم وہ memory دکھاتا ہے جو kernel اب بھی کسی نئے process کو دے سکتا ہے۔ NVIDIA GPU والے box پر nvidia-smi VRAM میں یہی صورت حال دکھاتا ہے۔ اگر box کی memory ختم ہو جائے تو kernel recovery کے لیے کسی process کو kill کر دیتا ہے:

sudo dmesg -T | grep -i "out of memory"

ollama کا نام دینے والی line کا مطلب ہے کہ model server متاثرہ process تھا۔ اگر line میں آپ کے database کا نام ہو تو model جیت گیا اور آپ کی اہم سروس میں سے کوئی ایک متاثر ہو گئی۔ دونوں نتائج ایک ہی فیصلے سے پیدا ہوتے ہیں: ایسے box پر طویل keep-alive window رکھنا جس میں اضافی memory موجود نہ ہو۔

یہاں دو لاگتیں آسانی سے نظر انداز ہو جاتی ہیں۔ زیادہ context length بڑی KV cache محفوظ کرتی ہے۔ KV cache سے مراد key value cache ہے، یعنی ہر token کے لیے وہ attention state جسے model generation کے دوران برقرار رکھتا ہے، اور یہ resident size کا حصہ ہوتی ہے۔ اس کا حجم num_ctx سے متعین ہوتا ہے، اس لیے context window بڑھانے سے resident model کی زیرِاستعمال memory پوری idle مدت کے لیے بڑھ جاتی ہے، صرف جواب دیتے وقت نہیں۔ 1 سے زیادہ OLLAMA_NUM_PARALLEL ہر parallel slot کے لیے یہ cache الگ محفوظ کرتا ہے۔ اگر آپ ایک ہی model سے کئی افراد کو سروس دینے کا ارادہ رکھتے ہیں تو memory کا حجم slots کے مطابق طے کریں، صرف weights کے مطابق نہیں۔

ایک مناسب default یہ ہے: اضافی memory والے box پر ایک model -1 استعمال کر سکتا ہے۔ shared box پر ایسی window استعمال کریں جو آپ کی requests کے درمیان وقفوں کا احاطہ کرے، مثلاً 30m، تاکہ آپ کے کام سے رکنے پر memory دوبارہ دستیاب ہو جائے۔

فوراً model unload کریں

ollama stop qwen3:8b

یہ کوئی output واپس نہیں کرتا، اور model ollama ps سے غائب ہو جاتا ہے۔ جو نام load نہ ہوا ہو، اس کے لیے couldn't find model "qwen3:8b" to stop واپس ملتا ہے۔ API طریقے میں prompt کے بغیر request بھیجیں اور keep_alive کو 0 پر set کریں:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

جواب میں "done_reason": "unload" شامل ہوتا ہے۔ service restart کرنے کے بجائے یہ طریقہ استعمال کریں۔ systemctl restart ollama memory بھی آزاد کرتا ہے، لیکن یہ ہر دوسرا loaded model بھی ہٹا دیتا ہے اور اس وقت چلنے والی ہر request کو ختم کر دیتا ہے۔

ایک سرور پر ایک سے زیادہ model چلانا

OLLAMA_MAX_LOADED_MODELS ایک وقت میں loaded رہنے والے models کی تعداد محدود کرتا ہے۔ August 2026 تک default فی GPU تین models ہے، یا صرف CPU والے system پر بھی تین models ہیں۔ یہ حد models گنتی ہے، جبکہ اصل حد memory ہے۔ اس لیے دوسرا بڑا model تین models تک پہنچنے سے بہت پہلے ہی memory نہ ملنے کی وجہ سے رد کیا جا سکتا ہے۔

جب کسی نئے model کی درخواست کی جاتی ہے اور اس کے لیے کافی memory دستیاب نہیں ہوتی، تو scheduler جگہ بنانے کے لیے loaded models میں سے ایک کو unload کر دیتا ہے۔ یہ عموماً ایسے model کو ترجیح دیتا ہے جس کی کوئی active request نہ ہو۔ یہ ایسے model کو بھی evict کر سکتا ہے جس کا timer ابھی expired نہ ہوا ہو، بشمول -1 کے ساتھ loaded model۔ لہٰذا منفی keep_alive کا مطلب ہے کہ idle timeout نہیں ہے۔ یہ model کے weights کو کسی دوسرے model کی request کے مقابلے میں محفوظ نہیں رکھتا۔

یہ فیصلہ debug level پر log ہوتا ہے۔ اسی drop-in میں دوسری Environment="OLLAMA_DEBUG=1" line شامل کریں، service restart کریں، اور یہ log monitor کریں:

sudo journalctl -u ollama -f

اگر کسی request کے ساتھ ہی runner کو جگہ بنانے کے لیے unload کرنے والی line نظر آئے، تو اس machine پر یہ دونوں models بیک وقت fit نہیں ہوتے۔ حل یہ ہے کہ اس server پر کم models رکھیں، یا اس model کے لیے طویل window مقرر کریں جسے فوری جواب دینا ضروری ہے، اور کم استعمال ہونے والے model کے لیے 0 استعمال کریں۔

اگلی release کے بعد بھی قابلِ استعمال رہنے والی رہنمائی

Ollama بار بار release ہوتا ہے اور اس کے default settings بدلتے رہتے ہیں، اس لیے نمبرز یاد رکھنے کے بجائے اپنے سامنے موجود build کو چیک کریں:

ollama --version
ollama serve --help

ollama serve --help ان environment variables کی فہرست دیتا ہے جنہیں وہ build حقیقتاً پڑھتا ہے، جن میں OLLAMA_KEEP_ALIVE بھی شامل ہے۔ دو اصول مختلف releases میں برقرار رہے ہیں اور ان پر اعتماد کیا جا سکتا ہے۔ request میں دی گئی value server default پر مقدم ہوتی ہے۔ اور ollama ps اس بات کا معتبر ذریعہ ہے کہ حقیقت میں کیا load ہوا ہے، چاہے config file میں کچھ اور درج ہو۔

اگر کوئی editor یا agent آپ کے server کو چلا رہا ہے تو server کو ذمہ دار ٹھہرانے سے پہلے دیکھیں کہ وہ client کیا بھیج رہا ہے۔ اپنے Ollama server کی طرف coding agent کی رہنمائی میں بتایا گیا ہے کہ request settings کہاں موجود ہوتی ہیں۔

FAQ

Ollama 5 منٹ بعد اپنا model کیوں unload کر دیتا ہے؟

پانچ منٹ default keep_alive ہیں۔ یہ وہ idle timer ہے جسے Ollama request مکمل ہونے پر شروع کرتا ہے۔ اس کی مدت ختم ہونے پر server model weights کو memory سے آزاد کر دیتا ہے، اس لیے اگلی request انہیں disk سے دوبارہ load کرتی ہے۔ آپ کو محسوس ہونے والا وقفہ اسی reload کی وجہ سے ہوتا ہے۔ ایک request کے لیے "keep_alive": "30m" کو JSON body میں بھیج کر اس مدت میں اضافہ کریں، یا پورے server کے لیے OLLAMA_KEEP_ALIVE environment variable استعمال کریں۔

Ollama model کو memory میں مستقل loaded کیسے رکھوں؟

منفی value استعمال کریں: request کے لیے "keep_alive": -1، یا server کے لیے OLLAMA_KEEP_ALIVE=-1۔ اس کے بعد ollama ps کے UNTIL column میں Forever دکھائی دے گا۔ اس سے صرف idle timer ختم ہوتا ہے۔ اگر کسی دوسرے model کی request آئے اور memory کم ہو، تو scheduler جگہ بنانے کے لیے اس model کو پھر بھی unload کر سکتا ہے۔

OLLAMA_KEEP_ALIVE کو نظرانداز کیوں کیا جا رہا ہے؟

دیکھیں کہ آپ نے اسے کہاں set کیا ہے۔ systemctl show ollama --property=Environment چلائیں۔ اگر variable اس output میں موجود نہیں، تو server نے اسے کبھی نہیں دیکھا، کیونکہ shell میں export کیا گیا variable systemd service تک نہیں پہنچتا۔ اسے sudo systemctl edit ollama.service کے ذریعے set کریں، پھر sudo systemctl daemon-reload اور sudo systemctl restart ollama چلائیں۔ دوسری وجہ یہ ہو سکتی ہے کہ client request میں اپنا keep_alive بھیج رہا ہو، جو server default کو override کر دیتا ہے۔

Ollama کو restart کیے بغیر memory کیسے آزاد کروں؟

ollama stop qwen3:8b صرف اس ایک model کو فوراً unload کرتا ہے اور server سمیت باقی تمام loaded models کو چلتا رہنے دیتا ہے۔ API کے ذریعے prompt کے بغیر request بھیجیں اور "keep_alive": 0 شامل کریں۔ جواب میں "done_reason": "unload" واپس آئے گا۔ ollama ps سے تصدیق کریں؛ اس میں وہ model مزید درج نہیں ہونا چاہیے۔