VPS پر Ollama محفوظ طریقے سے کیسے host کریں؟

آپ کیا بنا رہے ہیں

آپ کے اپنے سرور پر چلنے والا ایک open-weight language model، جو HTTP API کے ذریعے جواب دے گا، اور اگر آپ چاہیں تو browser میں ایک chat page بھی فراہم کرے گا۔ Ollama وہ جز ہے جو model download کرتا ہے، اسے memory میں load کرتا ہے، اور http://127.0.0.1:11434 پر requests وصول کرتا ہے۔ installation کے لیے ایک command کافی ہے۔ اس کام کی اصل مشکل دوسری جگہ ہے: ایسا model منتخب کرنا جسے آپ کا VPS واقعی RAM میں رکھ سکے، اور inference server کو غلطی سے پوری internet پر authentication کے بغیر public نہ کر دینا۔

پہلے دو واضح انتباہات۔ CPU-only VPS پر چھوٹے models بھی آہستہ چلتے ہیں، اور API میں built-in authentication بالکل موجود نہیں ہے۔ ذیل میں دونوں نکات کی تفصیل دی گئی ہے، کیونکہ مسائل عموماً یہی دونوں وجوہات پیدا کرتے ہیں۔

حقیقت پسندانہ سائز کا جائزہ، سادہ اعداد میں

کسی model کی memory footprint تقریباً اس کے file size کے برابر ہوتی ہے، اس کے علاوہ runtime overhead کے لیے تقریباً ایک gigabyte اور context window کے لیے کچھ مزید memory درکار ہوتی ہے۔ Ollama کے default models 4-bit quantized ہوتے ہیں، جنہیں Q4 کہا جاتا ہے۔ اس میں ہر ایک billion parameters کے لیے تقریباً نصف gigabyte RAM درکار ہوتی ہے۔ اس لیے حساب سادہ ہے، اور یہی ہر چیز کا فیصلہ کرتا ہے۔

llama3.2:3b جیسا 3B model تقریباً 2 GB کا download ہوتا ہے اور اسے چلانے کے لیے تقریباً 4 GB free RAM درکار ہوتی ہے۔ mistral:7b یا llama3.1:8b جیسے 7B یا 8B model کا disk پر سائز تقریباً 5 GB ہوتا ہے، اور انہیں تقریباً 8 GB RAM درکار ہوتی ہے؛ بہتر کارکردگی کے لیے 16 GB RAM مناسب ہے۔ 13B یا 14B model کے لیے تقریباً 16 GB RAM درکار ہوتی ہے۔ 30B سے 70B range کے کسی بھی model کے لیے زیادہ RAM والا server یا، حقیقتاً، GPU درکار ہوتا ہے۔ CPU VPS پر یہ یا تو fit نہیں ہوگا، یا اتنی سست رفتاری سے جواب دے گا کہ عملی طور پر بے کار ہوگا۔

اب رفتار کی بات کرتے ہیں، کیونکہ لوگ اسی حصے کو کم سمجھتے ہیں۔ CPU inference کا انحصار clock speed کے بجائے memory bandwidth پر ہوتا ہے، اور shared vCPU VPS میں bandwidth محدود ہوتی ہے۔ single-digit سے low-double-digit tokens per second کی توقع رکھیں: 7-8B Q4 model عموماً 4 سے 10 tokens per second کی رفتار حاصل کر سکتا ہے، جبکہ 3B model 10 سے 25 tokens per second تک پہنچ سکتا ہے۔ GPU تقریباً ایک order of magnitude زیادہ تیز ہوتا ہے۔ یہ جان بوجھ کر تخمینی اعداد ہیں۔ درست طریقہ یہ ہے کہ اپنے server کی کارکردگی خود measure کریں؛ نیچے دیا گیا run step یہی طریقہ دکھاتا ہے۔ کسی بھی article میں دیے گئے عدد پر، اس article کے عدد پر بھی، بھروسا نہ کریں؛ اپنے eval rate کے نتائج پر بھروسا کریں۔

عملی نتیجہ یہ ہے کہ CPU پر چلنے والے چھوٹے quantized models drafting، summarizing اور classification کے لیے واقعی مفید ہیں، بشرطیکہ آپ ان کی رفتار قبول کر سکیں۔ اس سے بڑے یا زیادہ تیز model کے لیے GPU instance کا بجٹ رکھیں۔

کسی مخصوص model کو مخصوص server کے ساتھ جانچنے کے لیے اس کی memory footprint کا تخمینہ یہاں لگائیں:

Ollama انسٹال کریں

اس کے 2 صاف طریقے ہیں۔ خالی VPS پر official script سب سے آسان ہے:

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

یہ ollama نام کا system user بناتا ہے، binary کو /usr/local/bin/ollama میں انسٹال کرتا ہے، اور ollama.service نام کی systemd service رجسٹر کرتا ہے۔ یہ service boot کے وقت شروع ہوتی ہے اور 127.0.0.1:11434 پر bind کرتی ہے۔ تصدیق کریں کہ یہ چل رہی ہے:

systemctl status ollama
ollama --version

اگر آپ پہلے سے Docker چلا رہے ہیں تو container استعمال کریں:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

port mapping میں 127.0.0.1: prefix پر توجہ دیں۔ اس سے port صرف localhost سے bind ہوتی ہے۔ اس کے بجائے -p 11434:11434 لکھنے سے یہ ہر interface پر publish ہو جاتی ہے۔ security section اسی غلطی سے خبردار کرتا ہے۔ انسٹال کرنے کا ایک ہی طریقہ منتخب کریں۔ script اور container ایک ساتھ نہ چلائیں، ورنہ دونوں processes اسی port پر قابض ہونے کی کوشش کریں گے۔

اپنا پہلا model pull کر کے چلائیں

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull model کی layers کو disk پر download کرتا ہے، اور اس model کے لیے یہ تقریباً 2 GB ہے۔ run انہیں memory میں load کرتا ہے اور آپ کو >>> prompt پر لے آتا ہے۔ کوئی سوال لکھیں۔ weights کو disk سے RAM میں load ہونے کے دوران پہلے token میں کئی seconds لگ سکتے ہیں، اس کے بعد جواب stream ہوتا ہے۔ chat سے نکلنے کے لیے /bye لکھیں؛ Ollama پس منظر میں چلتا رہتا ہے۔

دیکھیں کہ کیا load ہے اور یہ کیسے کام کر رہا ہے:

ollama ps

PROCESSOR column اصل صورتِ حال بتاتا ہے۔ 100% CPU کا مطلب ہے کہ کوئی GPU استعمال نہیں ہو رہا، اور سست رفتاری کی وجہ بھی یہی ہے۔ verbose flag کے ذریعے حقیقی رفتار ناپیں:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

آخر میں print ہونے والی eval rate line اس hardware پر آپ کی tokens per second رفتار ہے۔ منصوبہ بندی اسی عدد کو بنیاد بنا کر کریں۔

ماڈلز کہاں محفوظ ہوتے ہیں، اور کتنی disk خریدنی چاہیے

اسکرپٹ کے ذریعے install کیے گئے اور service کے طور پر چلنے والے models ollama صارف کے home میں محفوظ ہوتے ہیں:

sudo du -sh /usr/share/ollama/.ollama/models

اپنے user کے طور پر interactive طریقے سے چلانے پر یہ ~/.ollama/models میں محفوظ ہوتے ہیں۔ container میں یہ ollama نامی volume میں محفوظ ہوتے ہیں۔ یہ بات اہم ہے، کیونکہ quantized weights تیزی سے disk space استعمال کرتے ہیں: 3B تقریباً 2 GB، 7-8B تقریباً 5 GB، اور 14B تقریباً 9 GB ہوتا ہے۔ موازنے کے لیے چار models pull کریں تو آپ کو محسوس کیے بغیر 20 GB استعمال ہو جاتے ہیں۔ disk کا سائز ان models کے مطابق رکھیں جنہیں آپ محفوظ رکھنا چاہتے ہیں، اور باقی models کو ollama rm <model> سے delete کر دیں۔ اگر اسی VPS پر پہلے سے کوئی ایسی چیز چل رہی ہو جو خود بھی بہت زیادہ space استعمال کرتی ہو، مثلاً PhotoPrism یا Immich میں photo library محفوظ ہو، تو پہلے اس space کو خالی disk space سے منہا کریں اور باقی کو اپنے models کے لیے حقیقی budget سمجھیں۔

اسے اپنی نگرانی میں service کے طور پر چلائیں

Install script نے پہلے ہی ollama.service کو register کر دیا ہے، اس لیے یہ مزید کسی configuration کے بغیر boot پر restart ہو جاتی ہے۔ تبدیل کرنے کے قابل اہم setting یہ ہے کہ model کتنی دیر memory میں موجود رہے۔ بعض setups میں bind address بھی تبدیل کرنا ہوتا ہے۔ یہ دونوں settings systemd drop-in میں شامل کریں تاکہ Ollama upgrade انہیں overwrite نہ کرے:

sudo systemctl edit ollama.service

Editor میں دکھائے گئے [Service] header کے تحت یہ شامل کریں:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE اس مدت کا تعین کرتا ہے جس کے بعد آخری request کے بعد model memory میں موجود رہتا ہے۔ Default 5 minutes ہے۔ ایسے box پر جہاں پورا دن queries چلتی ہوں، اسے بڑھا دیں تاکہ weights ہر بار دوبارہ load نہ ہوں۔ محدود RAM والے box پر اسے 0 مقرر کریں تاکہ request مکمل ہوتے ہی RAM آزاد ہو جائے۔ systemctl edit unit files کو دوبارہ load کرتا ہے، اس لیے تبدیلی لاگو کرنے کے لیے service restart کریں:

sudo systemctl restart ollama

سب سے اہم حفاظتی نکتہ

By default Ollama، 127.0.0.1:11434 پر bind ہوتا ہے، اس لیے صرف VPS کے اندر موجود processes ہی اس تک رسائی حاصل کر سکتے ہیں۔ یہ default درست ہے۔ اسے برقرار رکھیں۔

API میں authentication موجود نہیں ہے۔ بالکل نہیں۔ اس میں API key، login، rate limit یا allow-list میں سے کچھ بھی نہیں ہے۔ جو بھی port 11434 تک رسائی حاصل کر سکتا ہے، وہ آپ کے pull کیے ہوئے کسی بھی model کو چلا سکتا ہے، نئے models pull کر سکتا ہے، انہیں delete کر سکتا ہے، اور آپ کے CPU یا GPU کو غیر معینہ مدت تک مکمل load پر چلا سکتا ہے۔ Shodan جیسے scanners کھلے ہوئے Ollama instances کو ہزاروں کی تعداد میں index کرتے ہیں، اور exposed instance چند گھنٹوں کے اندر تلاش کر کے غلط استعمال کیا جاتا ہے۔

لہٰذا یہ وہ واحد غلطی ہے جو ہرگز نہیں کرنی: `OLLAMA_HOST=0.0.0.0 set کر کے اپنے firewall میں 11434 کھلا نہ چھوڑیں۔ اس سے بغیر authentication والا inference server پورے internet کے لیے public ہو جاتا ہے۔ کوئی بھی configuration 0.0.0.0 پر raw 11434` کو محفوظ نہیں بنا سکتی، کیونکہ Ollama میں configure کرنے کے لیے authentication موجود ہی نہیں؛ authentication کا نظام سرے سے شامل نہیں ہے۔ یہ اصول اسی مخصوص service کے بارے میں ہے، ہر port کھولنے پر عمومی پابندی نہیں۔ remote desktop کے لیے self-hosted RustDesk relay کو اپنا کام کرنے کے لیے public traffic قبول کرنا ہی پڑتا ہے، اور یہ اپنی key-based authentication اور documented ports کی مختصر فہرست فراہم کر کے اس کی اجازت حاصل کرتا ہے؛ Ollama میں ان دونوں میں سے کچھ بھی موجود نہیں ہے۔

کسی دوسرے مقام سے model تک رسائی حاصل کرنے کے تین محفوظ طریقے ہیں:

• اسے local رکھیں۔ اگر واحد caller اسی VPS پر چلنے والا کوئی دوسرا program، cron script، bot یا آپ کے tools کو model سے جوڑنے والا MCP server ہے تو bind کو 127.0.0.1 پر رہنے دیں اور اس program سے http://127.0.0.1:11434 کو call کرائیں۔ کچھ بھی expose نہیں ہوتا اور کسی اضافی اقدام کی ضرورت نہیں ہوتی۔
• private tunnel کے ذریعے رسائی حاصل کریں۔ VPS کو اپنے زیرِ انتظام WireGuard VPN میں شامل کریں، OLLAMA_HOST کو tunnel address پر set کریں، مثلاً 10.8.0.1، نہ کہ 0.0.0.0، اور صرف VPN peers کو connect کرنے دیں۔ public internet کو 11434 پر اب بھی کچھ نظر نہیں آئے گا۔
• اس کے سامنے authentication والا reverse proxy رکھیں۔ TLS کو terminate کریں اور nginx، Traefik یا Caddy پر password یا token لازمی قرار دیں، پھر requests کو 127.0.0.1:11434 پر proxy کریں۔ Ollama اپنا localhost bind برقرار رکھتا ہے؛ public port پر صرف proxy listening کرتا ہے۔ یہ اسی طریقے کا استعمال ہے جس میں کسی local service کے سامنے nginx پر Let's Encrypt certificate لگایا جاتا ہے۔

reverse-proxy کا اختیار بالکل وہی ہے جو chat UI اگلے مرحلے میں فراہم کرتا ہے، اور اس کے ساتھ حقیقی login بھی موجود ہے۔

Open WebUI کے ساتھ TLS کے پیچھے chat UI شامل کریں

Open WebUI ایک self-hosted chat interface ہے۔ اسے Docker میں چلائیں اور مقامی Ollama کی طرف point کریں:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Linux VPS پر --network=host flag اہم ہے۔ یہ container کو host کے network namespace میں شامل کرتا ہے، اس لیے container کے اندر 127.0.0.1، host کا اپنا loopback ہوتا ہے اور container 127.0.0.1:11434 کے ذریعے Ollama تک پہنچتا ہے، جبکہ Ollama کو کسی دوسرے interface پر listen کرنے کی ضرورت نہیں ہوتی۔ آپ کو کہیں اور جو bridge-network طریقہ نظر آئے گا، یعنی --add-host=host.docker.internal:host-gateway کو OLLAMA_BASE_URL=http://host.docker.internal:11434 کے ساتھ استعمال کرنا، یہاں کام نہیں کرتا۔ اس نام سے Docker bridge gateway resolve ہوتا ہے، اور host پر 127.0.0.1 سے bound service bridge کے ذریعے قابل رسائی نہیں ہوتی۔ نتیجتاً Open WebUI یہ بتاتا رہتا ہے کہ وہ Ollama سے connect نہیں کر سکتا۔

Host networking کا نقصان یہ ہے کہ Open WebUI اب host کے port 8080 پر ہر interface پر listen کرتا ہے۔ کوئی بھی -p mapping نظرانداز کر دی جاتی ہے، اور Docker اس بارے میں warning دکھاتا ہے۔ اس لیے host firewall اور provider firewall، دونوں پر 8080 بند کریں، اور TLS reverse proxy کو واحد public entry point رہنے دیں۔ پہلی بار Open WebUI کھولنے پر یہ آپ سے admin account بنانے کو کہتا ہے۔ یہی account authentication layer ہے، اس لیے مضبوط password منتخب کریں۔

اپنے laptop سے HTTPS کے ذریعے chat کھولنے کے لیے 127.0.0.1:8080 کے سامنے TLS reverse proxy رکھیں۔ اگر آپ اس server پر پہلے ہی کئی Docker apps route کر رہے ہیں تو کئی apps کے لیے automatic TLS کے ساتھ Traefik سب سے موزوں انتخاب ہے۔ ایک label block certificate جاری کرتا ہے اور chat.example.com کو Open WebUI تک route کرتا ہے۔ Security section کا اصول یہاں بھی برقرار رہتا ہے: public port اور login کی ذمہ داری proxy کی ہوتی ہے، جبکہ Ollama localhost پر رہتا ہے اور Open WebUI کا اپنا 8080 firewall سے محفوظ رہتا ہے۔

اپنے code سے OpenAI-compatible endpoint استعمال کریں

Ollama، /v1 پر OpenAI chat API کے ایک subset کی سہولت فراہم کرتا ہے، اس لیے زیادہ تر OpenAI client libraries میں صرف دو چیزیں تبدیل کرنے کے بعد کام ہو جاتا ہے: base URL اور عارضی key۔

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

api_key client library کے لیے ضروری ہے، لیکن Ollama اسے نظرانداز کرتا ہے، اس لیے کوئی بھی string کام کرے گی۔ model ایسا نام ہونا چاہیے جسے آپ پہلے ہی pull کر چکے ہوں؛ نامعلوم نام model "x" not found, try pulling it first واپس کرتا ہے۔ سادہ curl call کا طریقہ بھی یہی ہے:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

اسی طریقے سے آپ model کو agent اور editor tooling کے ساتھ مربوط کرتے ہیں۔ اگر آپ پہلے ہی اسی box پر development کرتے ہیں تو local model، VPS پر tmux کے اندر چلنے والے Claude Code کے ساتھ scripts اور plugins کو بھی چلا سکتا ہے۔ اس طرح کم لاگت اور نجی drafting کا کام paid API سے باہر رکھا جا سکتا ہے، جبکہ پیچیدہ reasoning hosted model کے پاس رہتی ہے۔

ناکامی کی صورتیں، نظر آنے والے عین strings کے ساتھ

generation کے دوران process "Killed" ہو جاتا ہے۔ آپ ایک بڑا model شروع کرتے ہیں اور terminal میں Killed دکھائی دیتا ہے، یا server log میں llama runner process has terminated: signal: killed نظر آتا ہے۔ Linux OOM killer نے اسے روک دیا کیونکہ model کو سرور میں موجود RAM سے زیادہ RAM درکار تھی۔ sudo dmesg | grep -i oom سے وجہ کی تصدیق کریں؛ اس میں Out of memory: Killed process ... (ollama) جیسی سطر نظر آئے گی۔ حل یہ ہے کہ کم سائز یا زیادہ quantized model استعمال کریں، 13B کے بجائے llama3.2:3b استعمال کریں، یا swap شامل کریں۔ اس طرح وہ load جو physical RAM سے معمولی سا زیادہ ہو، ختم ہونے کے بجائے آہستہ چل کر مکمل ہو سکتا ہے۔ Swap فوری crash کو سست response میں بدل دیتا ہے؛ یہ 4 GB پر 70B model کو عملی نہیں بناتا۔ اگر آپ terminal نہیں دیکھ رہے ہوں تو یہ kill خاموشی سے ہو جاتا ہے۔ ایسے سرور پر جسے آپ کسی دوسرے مقام سے query کرتے ہیں، OnFailure= unit کو ollama.service سے منسلک کریں۔ یہ push alerts کے لیے اپنے زیر انتظام ntfy server پر اطلاع بھیجے گا۔ اس طرح process ختم ہوتے ہی آپ کو معلوم ہو جائے گا، بجائے اس کے کہ اگلی request کے وقت اس کا پتا چلے۔

"Error: model requires more system memory"۔ Ollama model شروع کرنے سے انکار کرتا ہے اور Error: model requires more system memory (X GiB) than is available (Y GiB) دکھاتا ہے۔ یہ اوپر بیان کردہ crash کا محتاط انداز ہے: Ollama نے حساب کر کے خود رکنے کا فیصلہ کیا، بجائے اس کے کہ OOM killer کو یہ کام کرنا پڑے۔ یہ آپ کو دونوں numbers بھی دکھاتا ہے۔ ایسا model منتخب کریں جس کی requirement آپ کی free RAM سے کم ہو؛ اسے free -h سے check کریں۔ آپ context length کم کر سکتے ہیں یا بڑی VPS استعمال کر سکتے ہیں۔ کوئی flag model کو memory میں fit نہیں کر سکتا؛ درکار memory حقیقی ہے۔

پہلا token آنے میں بہت وقت لگتا ہے، پھر سب کچھ معمول کے مطابق چلتا ہے۔ Cold model پہلے 5 سے 30 سیکنڈ تک کچھ نہیں دکھاتا، پھر معمول کے مطابق stream کرتا ہے۔ اس وقفے کے دوران weights پہلی بار disk سے RAM میں load ہوتے ہیں، اور سست storage اس عمل کو مزید طویل کر دیتی ہے۔ Load ہونے کے بعد model OLLAMA_KEEP_ALIVE کی مدت تک memory میں موجود رہتا ہے، اس لیے دوسرا prompt فوراً جواب دیتا ہے۔ اگر پہلا load call path میں موجود کسی timeout سے زیادہ طویل ہو جائے تو سست جواب کے بجائے error ملتا ہے۔ یہ معلوم کرنا کہ context deadline exceeded کس layer نے رپورٹ کیا بتاتا ہے کہ client، proxy یا خود load کے عمل میں سے کس کی انتظار کی مدت ختم ہوئی۔ اگر یہ وقفے پریشان کریں تو اس value کو بڑھا دیں، اور یہ دیکھنے کے لیے ollama ps استعمال کریں کہ آیا اس وقت کوئی model loaded ہے۔

ہر چیز بس سست ہے۔ error کے بغیر دس tokens فی second یا اس سے کم رفتار ملتی ہے۔ یہ CPU inference ہے، جو CPU inference کی متوقع کارکردگی دکھا رہا ہے۔ ollama ps میں 100% CPU نظر آتا ہے، جس کا مطلب ہے کہ GPU موجود نہیں ہے۔ یہ bug نہیں ہے اور کوئی setting اسے درست نہیں کر سکتی، کیونکہ حد memory bandwidth ہے، configuration کی خرابی نہیں۔ چھوٹا model استعمال کریں، اس رفتار کو قبول کریں، یا GPU instance پر منتقل ہوں۔ کوئی چیز خراب سمجھنے سے پہلے --verbose سے اپنی حقیقی رفتار ناپیں۔

دوسری machine سے connection refused آتا ہے۔ اپنے laptop سے آپ کو curl: (7) Failed to connect to <ip> port 11434: Connection refused ملتا ہے۔ یہ متوقع رویہ ہے: Ollama صرف localhost پر bind ہوتا ہے۔ 0.0.0.0 پر bind کر کے اسے "درست" نہ کریں؛ یہی وہ exposure mistake ہے جس کا اوپر ذکر ہوا ہے۔ model تک VPN یا authentication کرنے والے proxy کے ذریعے پہنچیں۔

آپ نے 11434 کو internet پر expose کر دیا۔ اگر آپ نے OLLAMA_HOST=0.0.0.0 set کیا، firewall کھولا، اور اب ایسے model pulls دیکھ رہے ہیں جو آپ نے شروع نہیں کیے، یا نامعلوم clients کی وجہ سے CPU 100% پر ہے، تو آپ کا server دریافت کر کے استعمال کیا جا چکا ہے۔ یہ کوئی نایاب صورت نہیں بلکہ بنیادی اور سنگین mistake ہے۔ دوبارہ 127.0.0.1 یا VPN address پر bind کریں، firewall میں 11434 بند کریں، اور سامنے authentication لگائیں۔ فرض کریں کہ اس address کے کھلے رہنے کے دوران وہاں دستیاب ہر چیز کو اجنبی لوگوں نے query کیا ہے۔

بیک اپس اور اپ گریڈز

ضائع ہونے والی state بہت کم ہے۔ Models دوبارہ download کیے جا سکتے ہیں، اس لیے صرف Open WebUI کے data volume، accounts، chat history، settings اور آپ کے بنائے ہوئے کسی بھی systemd drop-in کا بیک اپ لینا ضروری ہے۔ عارضی container کے ذریعے volume کا بیک اپ لیں:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Ollama کو install script دوبارہ چلا کر اپ گریڈ کریں؛ Open WebUI کو docker pull ghcr.io/open-webui/open-webui:main کے ذریعے اپ گریڈ کرنے کے بعد container دوبارہ بنائیں۔ طویل مدت کے لیے کسی چیز کو pin نہ کریں۔ دونوں models کا معیار اور runtime تیزی سے تبدیل ہوتے ہیں، اس لیے release notes پڑھیں اور اپنے server پر دوبارہ benchmark کریں۔ گزشتہ سہ ماہی کے اعداد و شمار پر بھروسا نہ کریں۔

FAQ

کیا میں واقعی صرف CPU والے VPS پر LLM چلا سکتا ہوں؟

ہاں، لیکن کچھ حدود کے ساتھ۔ 3B سے 8B تک کے چھوٹے quantized models CPU پر چلتے ہیں اور مسودہ تیار کرنے، خلاصہ بنانے اور classification کے لیے واقعی مفید ہیں، اگرچہ shared vCPU پر رفتار کم ہوتی ہے اور عموماً single-digit سے low-double-digit tokens per second رہتی ہے۔ 13B یا اس سے بڑے models بہت سست ہوتے ہیں یا مکمل طور پر RAM میں فٹ نہیں ہوتے۔ حقیقی رفتار یا بڑے models کے لیے GPU instance درکار ہے۔

ہر model کو کتنی RAM درکار ہوتی ہے؟

default 4-bit quantized models کے لیے ایک محتاط عمومی اصول یہ ہے کہ weights کے لیے ہر billion parameters پر تقریباً 0.5 GB RAM درکار ہوتی ہے، اس کے علاوہ تقریباً 1 GB overhead اور context کے لیے کچھ اضافی RAM چاہیے۔ اس لیے 3B model کے لیے تقریباً 4 GB خالی RAM، 7-8B model کے لیے تقریباً 8 GB، اور 14B model کے لیے تقریباً 16 GB درکار ہوتی ہے۔ free -h سے دستیاب headroom دیکھیں، اور operating system اور server پر چلنے والی دیگر چیزوں کے لیے بھی گنجائش رکھیں۔

کیا Ollama API authenticated ہے؟

نہیں۔ Ollama میں built-in authentication، API key یا rate limit موجود نہیں ہے۔ جو بھی port 11434 تک پہنچ سکتا ہے، اسے اس پر مکمل اختیار حاصل ہے۔ اسی وجہ سے یہ default طور پر 127.0.0.1 پر bind ہوتا ہے، اور آپ کو 11434 کو 0.0.0.0 پر internet کے لیے کبھی expose نہیں کرنا چاہیے۔ اسے مقامی طور پر، private VPN کے ذریعے، یا ایسے reverse proxy کے ذریعے access کریں جو login شامل کرتا ہو۔

میں web chat interface کیسے شامل کروں؟

Open WebUI کو Docker میں --network=host کے ساتھ چلائیں، تاکہ یہ host کا loopback share کرے اور native Ollama کو http://127.0.0.1:11434 پر access کر سکے۔ اس کے بعد اس کے port 8080 کے سامنے TLS reverse proxy رکھیں تاکہ آپ اپنے laptop سے access کر سکیں۔ Firewall پر 8080 بند رکھیں، تاکہ صرف proxy ہی public access فراہم کرے۔ Open WebUI کا اپنا admin account login فراہم کرتا ہے، اور پہلی بار launch پر اس کا password مقرر کیا جاتا ہے۔

میں اسے اپنی application سے کیسے call کروں؟

http://127.0.0.1:11434/v1 پر موجود OpenAI-compatible endpoint استعمال کریں۔ کسی بھی OpenAI SDK کو اس base URL پر point کریں، API key کے طور پر کوئی بھی string دیں کیونکہ اسے نظرانداز کیا جاتا ہے، اور model میں اس model کا نام مقرر کریں جسے آپ نے pull کیا ہے۔ موجودہ OpenAI code عموماً base URL اور key کے علاوہ کسی تبدیلی کے بغیر چلتا ہے۔