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 کو expire کرتا ہے جس کی کوئی active request نہ ہو۔ August 2026 تک default مدت پانچ منٹ ہے، اور یہ مدت ہر اس model پر لاگو ہوتی ہے جسے یہ server load کرتا ہے۔

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

اس وقت کون سے models resident ہیں، اور یہ کب 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 کا وقت لگے گا۔ 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 کے درمیان column set تبدیل ہوا ہے، اس لیے 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 میں موجود ہوتا ہے، اس لیے یہ بہت کم value رپورٹ کرتی ہے۔ ان دونوں figures کے درمیان فرق وہ لاگت ہے جو timer ختم ہونے کے بعد ہر user کو ادا کرنی پڑتی ہے، اور keep_alive تبدیل کرنے کی پوری وجہ بھی یہی ہے۔ اس pause سے پہلے اور بعد کی generation speed کے لیے دیکھیں: اپنے box پر tokens per second کی پیمائش کیسے کریں۔

ایک درخواست پر Ollama model کو memory میں loaded رکھیں

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

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
• منفی 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 کے ساتھ خالی response واپس کرتا ہے۔

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

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

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

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

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

اصل مسئلہ یہ ہے کہ یہ کس environment میں موجود ہونا چاہیے۔ اپنی SSH session میں export OLLAMA_KEEP_ALIVE=30m چلانے سے کوئی اثر نہیں ہوتا، کیونکہ packaged install سرور کو systemd service کے طور پر اپنے مخصوص user اور اپنے environment کے تحت چلاتا ہے۔ آپ کا login shell اور وہ service ایک دوسرے سے منسلک نہیں ہوتے۔ یہی سب سے عام وجہ ہے کہ یہ 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 حقیقتاً چلنے والی ہے۔ اگر اس line میں OLLAMA_KEEP_ALIVE=30m موجود نہ ہو تو drop-in لاگو نہیں ہوا۔ اس کی وجہ تقریباً ہمیشہ missing [Service] header یا marker کے نیچے typed کی گئی lines ہوتی ہیں۔ restart کے دوران ہر loaded model unload ہو جاتا ہے، اس لیے اگلی request cold load شروع کرے گی۔ اوپر دی گئی preload call سے اسے دوبارہ warm کریں۔

ماڈل کو مستقل طور پر میموری میں رکھنے کی لاگت

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

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

free -h

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

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

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

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

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

ماڈل کو فوراً unload کریں

ollama stop qwen3:8b

یہ بغیر کسی output کے واپس آتا ہے، اور ماڈل ollama ps سے غائب ہو جاتا ہے۔ جو نام loaded نہ ہو، اس کے لیے 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 والے server پر بھی تین models ہیں۔ یہ حد models کی تعداد گنتی ہے، جبکہ اصل حد memory ہے۔ اس لیے تین تک پہنچنے سے بہت پہلے دوسرا بڑا model لوڈ کرنے کے لیے memory ناکافی ہو سکتی ہے۔

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

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

sudo journalctl -u ollama -f

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

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

Ollama بار بار release ہوتا ہے اور اس کے defaults تبدیل ہوتے رہتے ہیں، اس لیے نمبرز یاد رکھنے کے بجائے اپنے سامنے موجود 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 منٹ بعد اپنا ماڈل کیوں unload کر دیتا ہے؟

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

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

منفی value استعمال کریں: درخواست میں "keep_alive": -1، یا server کے لیے OLLAMA_KEEP_ALIVE=-1۔ اس کے بعد ollama ps، UNTIL column میں Forever دکھاتا ہے۔ اس سے idle timer ختم ہو جاتا ہے، اس کے علاوہ کوئی تبدیلی نہیں ہوتی۔ اگر کسی دوسرے model کی درخواست آئے اور 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 درخواست میں اپنا 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 مزید درج نہیں ہونا چاہیے۔