VPS پر Ollama یا llama.cpp: کون سا چلائیں؟

Ollama بمقابلہ llama.cpp: آپ کون سی layer چلانا چاہتے ہیں؟

Ollama اور llama.cpp اس مفہوم میں ایک دوسرے کے حریف نہیں ہیں جو سوال میں ظاہر کیا گیا ہے۔ llama.cpp inference engine ہے: یہ model file لوڈ کرتا ہے اور prompt کو tokens میں تبدیل کرتا ہے۔ Ollama، اسی engine کے اوپر چلنے والا model manager، background daemon اور HTTP API ہے۔ Ollama کی README میں آج بھی llama.cpp کو اس کے inference backend کے طور پر درج کیا گیا ہے (2 August 2026 کو جانچا گیا)۔ اس لیے اصل سوال یہ ہے کہ آپ اپنے VPS پر کون سی layer چلانا چاہتے ہیں، نہ کہ ان میں سے کون زیادہ تیز ہے۔

Ollama اس وقت چلائیں جب آپ ایسی service چاہتے ہوں جو نام کے ذریعے models حاصل کرے اور مسلسل نگرانی کے بغیر کام کرتی رہے۔ llama.cpp براہ راست اس وقت چلائیں جب server محدود وسائل والا ہو اور آپ کو exact model file، exact context size اور exact thread count منتخب کرنے کی ضرورت ہو، کیونکہ چھوٹے VPS پر ان میں سے ہر setting ایسی memory استعمال کرتی ہے جو آپ کے پاس موجود نہیں ہے۔

ہر project اصل میں کیا ہے

llama.cpp، ggml library پر مبنی transformer inference کی C اور C++ implementation ہے۔ یہ GGUF files پڑھتا ہے۔ GGUF (GGML universal file format) ایک single-file container ہے جس میں weights، tokeniser اور engine کو model چلانے کے لیے درکار metadata موجود ہوتا ہے۔ یہ project مختلف کاموں کے لیے الگ binaries فراہم کرتا ہے۔ llama-server ایک HTTP server ہے، llama-cli interactive prompt ہے، اور llama-bench throughput کی پیمائش کرتا ہے۔ Releases کو semantic version کے بجائے build number سے tag کیا جاتا ہے۔ موجودہ tag b10224 ہے، جو 2 August 2026 کو publish ہوا، اور تقریباً ہر working day ایک نیا tag جاری ہوتا ہے۔

Ollama ایک Go program ہے۔ ollama serve سے شروع ہونے والا background daemon models load کرتا ہے اور HTTP requests کا جواب دیتا ہے، جبکہ command line client اس daemon سے رابطہ کرتا ہے۔ دونوں کے پیچھے ollama.com پر موجود ایک registry ہے، جس میں پہلے سے pack کیے گئے models رکھے جاتے ہیں۔ Ollama semantic versions استعمال کرتا ہے، اور v0.32.5، 27 July 2026 کو جاری ہوا۔ ollama pull ایک GGUF کو prompt template اور default parameters کے set کے ساتھ fetch کرتا ہے، پھر Linux پر اسے /usr/share/ollama/.ollama/models کے تحت محفوظ کرتا ہے۔ یہ files root disk پر موجود رہتی ہیں اور ہر file کئی gigabytes تک پہنچ سکتی ہے، اس لیے 25 GB root volume والے VPS پر تیسرے download سے پہلے یہ جاننا مفید ہے کہ pull کے بعد کیا باقی رہ جاتا ہے اور model directory کو دوسری جگہ کیسے منتقل کیا جائے۔

یہ packaging ہی دونوں کے درمیان بنیادی فرق ہے۔ Ollama آپ کے لیے quantisation، template اور context length کا فیصلہ کرتا ہے اور یاد رکھنے کے لیے ایک نام دیتا ہے۔ llama.cpp کچھ بھی طے نہیں کرتا اور آپ کو flags دیتا ہے۔

محور 1: ماڈل اور quantisation کا کنٹرول

Quantisation ہر weight کو 16 یا 32 bits سے گھٹا کر 4، 5 یا 8 bits کر دیتی ہے۔ اسی سے 8 billion parameters والا model عام VPS کی RAM میں سما جاتا ہے۔ GGUF کی naming، pattern معلوم ہونے کے بعد، آسانی سے سمجھی جا سکتی ہے: Q4_K_M کا مطلب 4-bit K-quant، medium size ہے۔ زیادہ number زیادہ precision برقرار رکھتا ہے اور زیادہ memory استعمال کرتا ہے۔

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

یہ bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository میں Hugging Face پر شائع شدہ file sizes ہیں۔ انہیں 2 August 2026 کو پڑھا گیا اور bytes سے GiB میں تبدیل کیا گیا۔ ایک model کے 6 builds ہیں، اور سب سے چھوٹا build 2.96 GiB کا ہے، جبکہ سب سے بڑا 7.95 GiB کا ہے۔ عام default، Q4_K_M، 4.58 GiB کا ہے۔ 4 GiB VPS پر یہی ایک انتخاب طے کرتا ہے کہ model load بھی ہوگا یا نہیں۔ Size اس فیصلے کا صرف نصف حصہ ہے، کیونکہ جس row کی لاگت آپ برداشت کر سکتے ہیں وہ لازماً استعمال کے قابل نہیں ہوتی، اور Q4، Q8 اور fp16 دراصل answer quality پر کیا اثر ڈالتے ہیں سے معلوم ہوتا ہے کہ اضافی gigabytes سے کوئی قابلِ محسوس فائدہ بھی ملے گا یا نہیں۔

llama.cpp میں آپ file کا نام دیتے ہیں، اس لیے row کا انتخاب آپ خود کرتے ہیں۔

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c tokens میں context size ہے، -t thread count ہے، اور -ngl بتاتا ہے کہ کتنی layers GPU پر منتقل کی جائیں گی؛ صرف CPU والے box پر یہ 0 ہوتا ہے۔ آپ کے لیے کچھ خودکار طور پر فرض نہیں کیا جاتا۔

Ollama میں quantisation اس tag کے ساتھ شامل ہوتی ہے جسے آپ pull کرتے ہیں، اور ollama ls دکھاتا ہے کہ disk پر حقیقتاً کیا موجود ہے۔ جب registry میں مطلوبہ build موجود نہ ہو تو خود GGUF import کریں۔ ایک Modelfile لکھیں:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

پھر اسے build کریں اور نتیجہ check کریں:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Context length وہ setting ہے جو اکثر مسئلہ پیدا کرتی ہے۔ Ollama دستیاب VRAM کی بنیاد پر اپنا default منتخب کرتا ہے، اور GPU کے بغیر box سب سے چھوٹے bucket میں آتا ہے: 4096 tokens۔ اسے 20,000 tokens کی document بھیجنے پر اضافی tokens model کے دیکھنے سے پہلے ہی drop ہو جاتے ہیں، اس لیے جواب ایسی file کے بارے میں پُراعتماد مگر غلط ہوتا ہے جسے model نے صرف آدھا پڑھا ہو۔ اسے daemon پر OLLAMA_CONTEXT_LENGTH کے ذریعے، یا Modelfile میں PARAMETER num_ctx کے ذریعے بڑھائیں۔ اگر بڑے window کی ضرورت صرف ایک job کو ہو تو num_ctx کو server-wide کے بجائے ہر request کے لیے set کیا جا سکتا ہے، جس سے اضافی cache daemon کے دیگر کاموں پر لاگو نہیں ہوتا۔ llama.cpp میں بھی کسی default پر بھروسا نہیں کیا جا سکتا۔ -c واضح طور پر set کریں اور معلوم رکھیں کہ آپ نے کیا set کیا ہے۔

وہ memory arithmetic جو عموماً کوئی نہیں دکھاتا

Model file پوری لاگت نہیں ہوتی۔ KV cache (key/value cache) ہر layer میں context کے ہر token کے لیے ایک entry رکھتا ہے، اور conversation بڑھنے کے ساتھ یہ بھی بڑھتا جاتا ہے۔

Llama 3.1 8B کے لیے حساب کریں۔ Model میں 32 layers، 8 key/value heads اور head dimension 128 ہے۔ f16 میں ہر token ہر key اور value کے لیے 2 bytes رکھتا ہے، اس لیے 2 x 8 x 128 x 2 = 4096 bytes فی layer بنتے ہیں۔ 32 layers میں یہ 128 KiB فی token بنتا ہے۔ 4096 token context کے لیے 512 MiB درکار ہوتے ہیں، جبکہ 32,768 token context کے لیے 4 GiB درکار ہوتے ہیں۔

اس لیے 4k context پر Q4_K_M 8B model کو weights کے لیے تقریباً 4.58 GiB، cache کے لیے تقریباً 0.5 GiB، اور runtime کے لیے اضافی memory درکار ہوتی ہے۔ یہ 4 GiB RAM میں نہیں چلتا۔ 8 GiB RAM میں کام کرنے کے لیے کچھ گنجائش کے ساتھ چل جاتا ہے۔ اسی 8 GiB box پر context کو 32k تک بڑھائیں تو صرف cache ہی دستیاب گنجائش ختم کر دیتا ہے۔ Model load ہونے کے دوران free -h سے memory کا استعمال براہِ راست monitor کریں، اور ایسے estimate پر اعتماد نہ کریں جس کی پیمائش نہ کی گئی ہو۔ اگر آپ 8B سے کہیں بڑے model کے لیے sizing کر رہے ہیں تو CPU-only VPS پر 27B model کے لیے یہی حساب دکھاتا ہے کہ 8 سے 64 GB تک ہر tier میں حقیقتاً کتنا data آ سکتا ہے۔

Ollama اس اثر کو مزید بڑھا دیتا ہے۔ OLLAMA_NUM_PARALLEL کی default value 1 ہے، اور model کو درکار memory اس number اور context length کے حاصل ضرب کے ساتھ بڑھتی ہے۔ دونوں کو ایک ساتھ بڑھانے پر daemon خاموشی سے آپ کی توقع سے کئی گنا زیادہ RAM طلب کرتا ہے۔ یہی حساب simultaneous users کی حد بھی متعین کرتا ہے، کیونکہ ہر concurrent request کو KV cache کا اپنا حصہ درکار ہوتا ہے؛ یہی وجہ ہے کہ ایک شخص کے لیے ٹھیک چلنے والا server پانچ افراد پر رک جاتا ہے۔

محور 2: آپ کو جس daemon کو operate کرنا ہے

Ollama کا install script ایک systemd unit لکھتا ہے، ایک ollama system user بناتا ہے اور service کو enable کرتا ہے۔ آپ کو یہ سب خود لکھے بغیر lifecycle management مل جاتی ہے۔ Configuration systemd کے ذریعے کی جاتی ہے:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE CPU VPS پر کسی بھی دوسری جگہ کے مقابلے میں زیادہ اہم ہے۔ Models بطور default 5 منٹ تک memory میں رکھے جاتے ہیں، پھر unload ہو جاتے ہیں۔ اگلی request جواب دینے سے پہلے پوری file کو disk سے دوبارہ پڑھتی ہے، اس لیے سست storage پر 4.58 GiB reload دو سیکنڈ کے جواب کو تیس سیکنڈ کے جواب میں بدل دیتا ہے۔ طویل keep-alive latency کا مسئلہ حل کرتا ہے، لیکن RAM مستقل طور پر استعمال ہوتی رہتی ہے۔ دونوں حقیقی costs ہیں۔ جو نقصان کم ہو، اسے منتخب کریں۔ اگر آپ چاہتے ہیں کہ model ہر حال میں resident رہے، تو keep_alive کو اس طرح set کرنا کہ وہ idle periods اور reboots کے بعد بھی برقرار رہے چند lines میں مکمل ہو جاتا ہے اور ہر بار box restart ہونے پر model کو دستی طور پر warm کرنے کی ضرورت ختم کر دیتا ہے۔

llama.cpp کوئی daemon فراہم نہیں کرتا، اس لیے unit آپ کو خود /etc/systemd/system/llama-server.service کے طور پر لکھنی ہوگی:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

اسے sudo systemctl enable --now llama-server سے enable کریں۔ اس کے بعد process اپنی پوری lifetime میں model کو memory میں رکھتا ہے۔ Idle ہونے پر کچھ بھی unload نہیں ہوتا، اس لیے reload کا اچانک مسئلہ نہیں آتا، لیکن service stop کیے بغیر memory واپس حاصل کرنے کا کوئی طریقہ بھی نہیں ہوتا۔ اگر units لکھنا آپ کے لیے نیا کام ہے، تو یہ اسی pattern کے مطابق ہے جس طرح VPS پر اپنی services کو systemd کے تحت چلایا جاتا ہے۔

محور 3: آپ کی ایپ کس API سے رابطہ کرے گی

یہ محور کافی حد تک محدود ہو گیا ہے۔ اب دونوں پروجیکٹس OpenAI chat format استعمال کرتے ہیں، اس لیے زیادہ تر client libraries میں صرف base URL تبدیل کرنے کے بعد دونوں میں سے کسی ایک کے ساتھ کام کیا جا سکتا ہے۔

Ollama 127.0.0.1:11434 پر listening کرتا ہے۔ اس کا OpenAI-compatible route http://localhost:11434/v1/chat/completions ہے، جبکہ اسی کے ساتھ یہ native API بھی /api/chat پر فراہم کرتا ہے۔ Anthropic-compatible route بھی documented ہے۔

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server 127.0.0.1:8080 پر listening کرتا ہے اور /v1/chat/completions، /v1/completions اور /v1/embeddings فراہم کرتا ہے۔ اس کے علاوہ اپنا /completion endpoint اور built-in web UI بھی موجود ہے۔ یہ ایسے operational routes بھی فراہم کرتا ہے جو Ollama میں نہیں ہیں: readiness probe کے لیے /health، loaded model کی settings کے لیے /props، ہر request slot میں جاری کارروائی دیکھنے کے لیے /slots، اور Prometheus format میں metrics کے لیے /metrics۔ اگر آپ اس service کی monitoring کا منصوبہ بنا رہے ہیں تو غالباً فیصلہ کن فرق یہی ہوگا۔

کوئی بھی server آپ کے لیے authentication خودکار طور پر فعال نہیں کرتا۔ اچھی وجہ سے دونوں کا default loopback ہے۔ ان تک SSH tunnel کے ذریعے یا reverse proxy کے پیچھے سے رسائی حاصل کریں، اور 11434 یا 8080 کو کبھی internet پر کھلا نہ چھوڑیں۔

CPU-only VPS حقیقتاً کیا کر سکتا ہے

CPU-only VPS چھوٹے models کو آہستہ چلاتا ہے۔ یہی دیانت دار خلاصہ ہے، اور اہم بات یہ جاننا ہے کہ حد کہاں واقع ہوتی ہے۔ اس کے گرد کوئی بھی design بنانے سے پہلے پیمائش کریں:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp کالم prompt processing speed اور tg کالم token generation speed دکھاتا ہے، دونوں کی اکائی tokens per second ہے۔ shared vCPU plan پر Q4_K_M میں 8B model عموماً tg کے لیے کم single-digit رفتار دیتا ہے۔ اصل مسئلہ prompt processing ہے: پہلا output token ظاہر ہونے سے پہلے پورا prompt process ہوتا ہے، اس لیے ایک طویل system prompt ہر request کے ساتھ انتظار کا وقت بڑھا دیتا ہے۔ Reply length وہ حصہ ہے جسے آپ براہ راست محدود کر سکتے ہیں، کیونکہ تین tokens فی second کی رفتار پر 600 tokens کا طویل جواب machine کو تین منٹ تک مصروف رکھتا ہے۔ اس لیے num_predict سے output محدود کرنا کسی ایک طویل جواب کو timeout بننے سے روکنے کا سب سے کم خرچ طریقہ ہے۔

CPU پر قابلِ استعمال: 1B سے 4B model جو classification، extraction، مختصر summaries یا routing کرے۔ Replies چند seconds میں آ جاتے ہیں اور memory عام plan میں سما جاتی ہے۔ اس size کے لیے range کے بجائے ایک عملی مثال میں VPS پر Nemotron 3.5 Lightning حاصل کرکے اس کی پیمائش exact tag، درکار حقیقی RAM اور GPU کے بغیر برقرار رہنے والی speed فراہم کرتی ہے۔ CPU پر قابلِ استعمال نہیں: reading speed کے مطابق interactive chat، coding assistants، طویل دستاویزات پر کام، یا ایسا کوئی agent loop جو سلسلہ وار بہت سی calls کرے۔ بارہ calls والا loop، اگر ہر call میں چار seconds لگیں، تو کوئی output پیدا کرنے سے پہلے ایک منٹ لیتا ہے۔ اگر منصوبہ ابتدا ہی سے coding assistant کا تھا تو کسی agent کو اپنے host کیے ہوئے model کی طرف متوجہ کرنا واضح کرتا ہے کہ چھوٹا local model کن کاموں میں حقیقتاً بہتر ہے اور کن کاموں کے لیے hosted API برقرار رکھنی ہوگی۔

جب اعداد و شمار موزوں نہ ہوں تو دو راستے ہیں۔ اگر مسئلہ concurrency ہے، یعنی ایک ہی وقت میں بہت سے users ایک model استعمال کر رہے ہیں، تو engine کا انتخاب بدلتا ہے، اور concurrent serving کے لیے Ollama اور vLLM کا موازنہ اسی موضوع کا احاطہ کرتا ہے۔ اگر مسئلہ raw speed ہے تو جواب GPU سے منسلک VPS ہے، جہاں -ngl کی قدر بامعنی ہونا شروع ہوتی ہے۔ دونوں میں سے کسی راستے سے پہلے hardware کے لیے baseline حاصل کریں، کیونکہ disk اور memory bandwidth بھی load time کو CPU جتنا متاثر کرتے ہیں۔ قابلِ تکرار VPS benchmark کے لیے ایک گھنٹہ صرف کرنا مفید ہے۔

llama.cpp انسٹال کریں اور ایک مخصوص build پر مقرر کریں

دونوں projects ہر ہفتے تبدیل ہوتے ہیں، اس لیے deployed version درج کر لیں۔ upstream one-liner موجودہ build انسٹال کرتا ہے:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

کسی مخصوص build پر مقرر کرنے کے لیے releases page سے prebuilt tarball استعمال کریں۔ 2 August 2026 تک build b10224 موجودہ tag ہے:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

یا اسی tag کو source سے build کریں:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

HTTPS features کے لیے libssl-dev دستاویزی dependency ہے۔ compile میں کئی منٹ لگتے ہیں اور اس کے لیے smallest plans میں دستیاب RAM سے زیادہ RAM درکار ہوتی ہے، اس لیے build بڑے box پر کریں اور اگر small box میں RAM کم پڑ جائے تو binaries وہاں copy کر دیں۔

Ollama کو ایک مخصوص version پر نصب کریں

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

یہ script OLLAMA_VERSION پڑھتی ہے، اس لیے آپ ہر صبح جاری ہونے والی تازہ release لینے کے بجائے ایک معلوم طور پر درست release مقرر کر سکتے ہیں۔ v0.32.5، 27 July 2026 کو جاری کیا گیا تھا۔ اگر آپ script کو shell میں pipe نہیں کرنا چاہتے تو manual طریقہ بھی موجود ہے:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

manual طریقہ systemd unit یا service user نہیں بناتا، اس لیے یہ دونوں آپ کو خود شامل کرنے ہوں گے۔ VPS پر Ollama کی مکمل رہنمائی میں service setup کا مرحلہ بہ مرحلہ طریقہ بیان کیا گیا ہے۔

ناکامی کی صورتیں اور نظر آنے والے متن

Ollama ماڈل لوڈ کرنے سے انکار کرتا ہے۔ ollama run اس نوعیت کی سطر واپس کرتا ہے:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama لوڈ کرنے سے پہلے سائز کی جانچ کرتا ہے، اس لیے فوراً ناکام ہو کر وجہ بتا دیتا ہے۔ quantisation کی فہرست میں ایک کم درجے والی قطار پر جائیں، context length کم کریں، یا چھوٹا ماڈل منتخب کریں۔

llama.cpp ناکام نہیں ہوتا بلکہ انتہائی سست ہو جاتا ہے۔ llama.cpp ڈیفالٹ طور پر GGUF کو memory-map کرتا ہے، اس لیے RAM سے بڑی فائل بھی شروع ہو جاتی ہے۔ اس کے بعد kernel ہر token پر weights کو disk سے بار بار page in اور page out کرتا ہے، اور generation کی رفتار چند seconds فی token تک گر جاتی ہے جبکہ disk 100 percent استعمال پر پہنچ جاتی ہے۔ حقیقی allocation پر مجبور کرنے کے لیے --no-mmap دیں، تاکہ کارکردگی خراب ہونے کے بجائے فوراً ناکام ہو۔ جب kernel مداخلت کرتا ہے تو dmesg وجہ دکھاتا ہے:

Out of memory: Killed process 1234 (llama-server)

ماڈل فائل بالکل لوڈ نہیں ہوگی۔ آپ کے engine سے نئے model family کے لیے بنائی گئی GGUF ایسی error دیتی ہے جس میں وہ architecture درج ہوتا ہے جسے engine نہیں پہچانتا:

error loading model architecture: unknown model architecture: 'qwen3next'

اس کا حل engine upgrade ہے، کوئی دوسری فائل نہیں۔ یہ pinning کی قیمت ہے، اور اسی لیے build number لکھ کر رکھنا ضروری ہے۔ آپ کو معلوم ہونا چاہیے کہ upgrade کس version سے کر رہے ہیں۔

API مقامی طور پر جواب دیتی ہے لیکن آپ کی app سے نہیں۔ Ollama 127.0.0.1:11434 پر bind ہوتی ہے، اس لیے دوسرے host کو connection refused ملتا ہے۔ OLLAMA_HOST=0.0.0.0:11434 کو systemctl edit ollama کے ذریعے صرف اس وقت set کریں جب port firewall یا private network کے پیچھے ہو، کیونکہ API کے سامنے authentication موجود نہیں ہے۔

وقفے کے بعد پہلا جواب بہت سست ہوتا ہے۔ 5 minute کی idle unload ہو چکی ہے اور ماڈل دوبارہ disk سے پڑھا جا رہا ہے۔ request سے فوراً پہلے ollama ps چلانے پر کوئی loaded model نہیں دکھتا، جو اس کی تصدیق کرتا ہے۔ OLLAMA_KEEP_ALIVE کی قدر بڑھائیں۔

تو آپ کو کون سا چلانا چاہیے؟

جب آپ چاہتے ہوں کہ models آپ کے لیے manage ہوں اور بغیر کسی اضافی کام کے OpenAI طرز کا endpoint دستیاب ہو، تو Ollama چلائیں۔ پہلی deployment کے لیے یہ موزوں default ہے، اور ان تمام صورتوں میں بھی جب model کا انتخاب بار بار تبدیل ہونا ہو۔

جب memory اتنی محدود ہو کہ آپ کو quantisation row خود منتخب کرنا پڑے، monitoring کے لیے /health، /slots اور /metrics درکار ہوں، یا آپ کو ایسا flag چاہیے جو Ollama ظاہر نہیں کرتا، تو llama.cpp براہِ راست چلائیں۔ VPS پر یہ زیادہ موزوں انتخاب ہے جہاں model بمشکل fit ہوتا ہو، کیونکہ اسے fit کرنے والی settings وہی ہیں جنہیں Ollama آپ کی طرف سے منتخب کرتا ہے۔

دونوں کو چلانا معمول کی بات ہے۔ experiments کے لیے Ollama، اور اس ایک model کے لیے llama.cpp جسے آپ production میں deploy کرتے ہیں اور کبھی تبدیل نہیں کرنا چاہتے۔

FAQ

کیا Ollama صرف llama.cpp کے گرد ایک wrapper ہے؟

قریب قریب، لیکن wrapper حقیقی کام بھی کرتا ہے۔ Ollama کی README میں llama.cpp کو inference backend کے طور پر درج کیا گیا ہے (2 August 2026 کو جانچا گیا)۔ Ollama اس کے اوپر model registry، chat messages کو prompt میں تبدیل کرنے والا prompt template، sampling کے default parameters، idle unloading کے ساتھ daemon، اور HTTP API شامل کرتا ہے۔ جب آپ یکساں settings پر فی سیکنڈ tokens کا موازنہ کرتے ہیں تو آپ ایک ہی engine کا اپنے ساتھ موازنہ کر رہے ہوتے ہیں۔ دراصل آپ management layer کے درمیان انتخاب کر رہے ہوتے ہیں۔

صرف CPU والے VPS پر کون سا زیادہ تیز ہے؟

دونوں ایک ہی engine استعمال کرتے ہیں، اس لیے ایک ہی model file، quantisation، context size اور thread count پر نتائج عموماً قریب قریب ہوتے ہیں۔ لوگ جن اختلافات کی اطلاع دیتے ہیں، وہ عموماً مختلف defaults کی وجہ سے ہوتے ہیں، خاص طور پر context length اور thread count کی وجہ سے، نہ کہ engine کی وجہ سے۔ اسے llama-bench -m <file> -p 512 -n 128 سے ناپیں اور کسی شائع شدہ figure پر یقین کرنے سے پہلے اپنے server پر tg column کا موازنہ کریں۔

کیا میں Ollama کے ساتھ اپنی GGUF file استعمال کر سکتا ہوں؟

ہاں۔ file کو server پر رکھیں، ایک Modelfile لکھیں جس کی پہلی line FROM ./your-model.gguf ہو، اپنی ضرورت کے مطابق PARAMETER lines شامل کریں، مثلاً num_ctx، پھر ollama create your-name -f ./Modelfile چلائیں۔ ollama ls اسے registry سے pull کی گئی دیگر files کے ساتھ list کرے گا۔ اس طرح آپ وہ quantisation استعمال کر سکتے ہیں جو registry میں موجود نہیں ہے۔

8B model کے لیے مجھے کتنی RAM درکار ہے؟

file size، KV cache اور runtime، تینوں کو budget میں شامل کریں۔ Llama 3.1 8B کی Q4_K_M build disk پر تقریباً 4.58 GiB ہے، اور 4096 tokens کا context تقریباً 512 MiB cache شامل کرتا ہے، اس لیے 8 GiB RAM مناسب ہے، جبکہ 4 GiB کافی نہیں ہے۔ cache، context کے ساتھ بڑھتا ہے: اسی model کو 32,768 tokens کے context پر صرف cache کے لیے تقریباً 4 GiB درکار ہوتے ہیں۔ Ollama کے ساتھ یہ بھی یاد رکھیں کہ requirement OLLAMA_NUM_PARALLEL کے ساتھ بڑھتی ہے۔