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

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

Ollama اور llama.cpp اس مفہوم میں حریف نہیں ہیں جو سوال میں ظاہر کیا گیا ہے۔ llama.cpp inference engine ہے: یہ model file لوڈ کرتا ہے اور prompt کو tokens میں تبدیل کرتا ہے۔ Ollama ایک model manager، background daemon اور HTTP API ہے جو اس engine کے اوپر کام کرتا ہے۔ 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 استعمال کرتی ہے جو آپ کے پاس دستیاب نہیں۔

ہر پروجیکٹ دراصل کیا ہے

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

Ollama ایک Go program ہے۔ ollama serve سے شروع کیا جانے والا background daemon models لوڈ کرتا ہے اور HTTP requests کے جواب دیتا ہے، جبکہ command line client اس daemon سے رابطہ کرتا ہے۔ دونوں کے پیچھے ollama.com پر موجود ایک registry ہے، جس میں پہلے سے تیار models رکھے جاتے ہیں۔ Ollama semantic versions استعمال کرتا ہے، اور v0.32.5، 27 July 2026 کو جاری ہوا۔ ollama pull ایک GGUF کے ساتھ prompt template اور default parameters کا مجموعہ حاصل کرتا ہے، پھر اسے Linux پر /usr/share/ollama/.ollama/models کے تحت محفوظ کرتا ہے۔

یہ 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 بھی ہو گا یا نہیں۔

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)۔ آپ کے لیے کوئی value خود سے فرض نہیں کی جاتی۔

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 کریں اور نتیجہ چیک کریں:

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 تک پہنچنے سے پہلے ہی خارج کر دیے جاتے ہیں۔ نتیجتاً model اس file کے بارے میں پُراعتماد مگر غلط جواب دیتا ہے، کیونکہ اس نے file کا صرف نصف حصہ پڑھا ہوتا ہے۔ اسے daemon پر OLLAMA_CONTEXT_LENGTH کے ذریعے، یا Modelfile میں PARAMETER num_ctx کے ذریعے بڑھائیں۔ llama.cpp میں بھی کسی default پر بھروسا نہیں کرنا چاہیے۔ -c کو واضح طور پر set کریں اور معلوم رکھیں کہ آپ نے کیا set کیا ہے۔

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

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

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 میں یہ فی token 128 KiB بنتا ہے۔ 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 والے system پر context کو 32k تک بڑھائیں تو cache اکیلا ہی دستیاب گنجائش ختم کر دیتا ہے۔ Model loaded ہونے کے دوران free -h سے memory استعمال کو براہ راست monitor کریں، اور ایسے estimate پر اعتماد نہ کریں جس کی پیمائش نہ کی گئی ہو۔

Ollama اس memory استعمال کو مزید بڑھاتا ہے۔ OLLAMA_NUM_PARALLEL کی default value 1 ہے، اور model کی memory ضرورت اس value اور context length کے حاصل ضرب کے مطابق بڑھتی ہے۔ دونوں values ایک ساتھ بڑھانے پر daemon خاموشی سے آپ کی توقع سے کئی گنا زیادہ RAM طلب کرتا ہے۔

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

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 بطور ڈیفالٹ 5 منٹ تک memory میں رکھے جاتے ہیں، پھر unload کر دیے جاتے ہیں۔ اگلی request کا جواب دینے سے پہلے پوری file کو disk سے دوبارہ پڑھنا پڑتا ہے۔ اس لیے سست storage پر 4.58 GiB کی reload دو سیکنڈ کے جواب کو تیس سیکنڈ کے جواب میں بدل دیتی ہے۔ طویل keep-alive latency کا مسئلہ حل کرتا ہے، لیکن RAM مستقل طور پر استعمال ہوتی رہتی ہے۔ دونوں حقیقی costs ہیں۔ جو کم نقصان دہ ہو، اسے منتخب کریں۔

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 ہونے پر model unload نہیں ہوتا۔ اس کا مطلب ہے کہ reload کا غیر متوقع مسئلہ نہیں ہوگا، لیکن service روکنے کے علاوہ memory واپس حاصل کرنے کا کوئی طریقہ بھی نہیں ہوگا۔ اگر units لکھنا آپ کے لیے نیا کام ہے تو یہ اسی pattern کے مطابق ہے جس کے تحت VPS پر اپنی services کو systemd کے تحت چلایا جاتا ہے۔

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

یہ فرق اب کافی کم رہ گیا ہے۔ دونوں projects اب 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 خود فعال نہیں کرتا۔ دونوں servers مناسب security کے لیے default طور پر loopback پر bind ہوتے ہیں۔ ان تک SSH tunnel کے ذریعے یا reverse proxy کے پیچھے سے رسائی حاصل کریں، اور 11434 یا 8080 کو کبھی بھی internet پر open نہ کریں۔

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 column prompt processing speed اور tg column token generation speed دکھاتا ہے، اور دونوں کی اکائی tokens per second ہے۔ shared vCPU plan پر 8B model عموماً Q4_K_M میں tg کے لیے کم single digits تک پہنچتا ہے۔ اصل مسئلہ prompt processing ہے: پہلا output token ظاہر ہونے سے پہلے پورا prompt process ہوتا ہے، اس لیے طویل system prompt ہر request کے ساتھ اضافی انتظار پیدا کرتا ہے۔

CPU پر قابلِ استعمال: 1B سے 4B model جو classification، extraction، مختصر summaries یا routing کرے۔ Replies چند seconds میں آ جاتی ہیں اور memory عام plan میں پوری ہو جاتی ہے۔ CPU پر ناقابلِ استعمال: reading speed کے مطابق interactive chat، coding assistants، طویل دستاویزات پر کام، یا ایسا agent loop جو مسلسل کئی calls کرے۔ اگر loop ہر call میں چار seconds لے اور بارہ calls کرے تو کوئی output پیدا ہونے سے پہلے ایک minute گزر جاتا ہے۔

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

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

دونوں projects ہر ہفتے نئی تبدیلیاں جاری کرتے ہیں، اس لیے deploy کیے گئے 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 درکار ہوتی ہے، اس لیے بڑی مشین پر build کریں۔ اگر چھوٹی مشین پر build مکمل نہ ہو تو binaries وہاں copy کریں۔

Ollama انسٹال کریں اور ورژن مقرر کریں

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

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

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

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

ناکامی کی صورتیں اور وہ strings جو آپ دیکھیں گے

Ollama model لوڈ کرنے سے انکار کرتا ہے۔ ollama run اس شکل کی ایک line واپس کرتا ہے:

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

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

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

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

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

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

اس کا حل engine upgrade کرنا ہے، مختلف file استعمال کرنا نہیں۔ یہ 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 ہو چکا ہے اور model دوبارہ disk سے read ہو رہا ہے۔ request سے فوراً پہلے ollama ps چلانے پر کچھ بھی loaded نہیں دکھتا، جو اس کی تصدیق کرتا ہے۔ OLLAMA_KEEP_ALIVE کی قدر بڑھائیں۔

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

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

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

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

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 per second کا موازنہ کرتے ہیں تو آپ اسی 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 سے ناپیں اور کسی بھی شائع شدہ اعداد و شمار پر اعتماد کرنے سے پہلے اپنے 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، تینوں کے لیے RAM مختص کریں۔ Llama 3.1 8B کی Q4_K_M build disk پر تقریباً 4.58 GiB کی ہوتی ہے، اور 4096 token context تقریباً 512 MiB cache شامل کرتا ہے۔ اس لیے 8 GiB RAM مناسب ہے، جبکہ 4 GiB کافی نہیں ہے۔ Cache، context کے ساتھ بڑھتا ہے۔ اسی model کو 32,768 token context پر چلانے کے لیے صرف cache کے لیے تقریباً 4 GiB درکار ہوتی ہے۔ Ollama کے ساتھ یاد رکھیں کہ یہ ضرورت OLLAMA_NUM_PARALLEL کے ساتھ بھی بڑھتی ہے۔