Ollama بمقابلہ vLLM: کون سا LLM server چلائیں؟

Ollama بمقابلہ vLLM، ایک پیراگراف میں

Ollama ایک model manager ہے جس کے ساتھ server منسلک ہوتا ہے: یہ quantized weights download کرتا ہے، انہیں load کرتا ہے، اور 127.0.0.1:11434 پر جواب دیتا ہے؛ اگر machine میں صرف CPU ہو تو CPU استعمال کرتا ہے۔ vLLM ایک throughput engine ہے: یہ بیک وقت چلنے والی متعدد requests کے ذریعے GPU کو مسلسل مصروف رکھتا ہے، اور ایسی machine پر موزوں نہیں جس میں GPU موجود نہ ہو۔ فیصلہ اسی قدر سادہ ہے۔ کسی local assistant سے بات کرنے والا ایک شخص Ollama کا استعمال ہے۔ کسی team کو service فراہم کرنے والی application vLLM کا استعمال ہے۔

دونوں OpenAI-compatible HTTP API استعمال کرتے ہیں، اس لیے base URL تبدیل کر کے client code کو ایک سے دوسرے پر منتقل کیا جا سکتا ہے۔ API فرق نہیں ہے۔ فرق اس وقت ظاہر ہوتا ہے جب پہلی request ابھی tokens generate کر رہی ہو اور دوسری request آ جائے۔

Ollama اصل میں کیا ہے

Ollama سہولت فراہم کرنے والی ایک تہہ ہے۔ یہ ایک ہی install command سے آپ کو model registry (ollama pull llama3.1:8b)، weights کا مقامی store، chat prompt، systemd service، اور HTTP API فراہم کرتا ہے۔ یہ جن models کو چلاتا ہے وہ GGUF files ہوتی ہیں، جنہیں عموماً 4-bit quantization کے ساتھ تیار کیا جاتا ہے۔ اسی وجہ سے 7B یا 8B model، disk پر 16 GB کے بجائے تقریباً 5 GB جگہ لیتا ہے۔ Quantization ہی CPU inference کو ممکن بناتی ہے۔

اس کا runner، llama.cpp پر مبنی ہے۔ llama.cpp ایک C++ inference library ہے جس نے عام hardware پر GGUF quantization کو عملی بنایا۔ بعد میں Ollama نے کچھ نئے model families کے لیے اپنا engine بھی شامل کیا، لیکن اس کی فراہم کردہ زیادہ تر سہولتوں کے پیچھے اب بھی llama.cpp بنیادی layer ہے۔ اس لیے جب لوگ Ollama کا llama.cpp سے موازنہ کرتے ہیں، تو وہ عموماً ایک ergonomics layer کا اس چیز سے موازنہ کر رہے ہوتے ہیں جسے وہ wrap کرتی ہے۔

اس کا design target ایک user ہے۔ July 2026 تک OLLAMA_NUM_PARALLEL کی default value 1 ہے۔ اس کا مطلب ہے کہ ایک model ایک وقت میں ایک request process کرتا ہے، جبکہ باقی تمام requests ایسی queue میں انتظار کرتی ہیں جس میں default طور پر 512 entries کی گنجائش ہوتی ہے (OLLAMA_MAX_QUEUE)۔ آپ parallel setting بڑھا سکتے ہیں، اور ذیل کا section بتاتا ہے کہ اس کے لیے آپ کو کیا قیمت ادا کرنا ہوگی۔ اگر آپ نے پہلے Ollama نہیں چلایا، تو VPS پر Ollama host کرنا اور port 11434 کو بند رکھنا سے شروع کریں، کیونکہ API میں کسی بھی قسم کی authentication موجود نہیں ہے۔

vLLM اصل میں کیا ہے

vLLM صرف inference server ہے، اس کے علاوہ کچھ نہیں۔ یہ model library کا انتظام نہیں کرتا، اس میں chat prompt موجود نہیں ہے، اور request کے وقت یہ آپ کے لیے model حاصل نہیں کرے گا۔ آغاز کے وقت آپ Hugging Face repository کا نام دیتے ہیں، یہ اسی ایک model کو load کرتا ہے، اور process روکنے تک اسے serve کرتا رہتا ہے۔

اس محدود دائرۂ کار کے بدلے آپ کو زیادہ throughput ملتا ہے۔ یہ کام دو mechanisms انجام دیتے ہیں۔ PagedAttention، KV cache (key-value cache، یعنی ہر فعال request کے لیے model کی جانب سے محفوظ کیا جانے والا فی-token attention state) کو fixed-size blocks میں محفوظ کرتا ہے، بالکل اسی طرح جیسے operating system memory کو pages میں تقسیم کرتا ہے۔ اب کسی request کے لیے worst-case کے مطابق ایک بڑی contiguous reservation درکار نہیں رہتی، اس لیے پہلے reserved اور غیر استعمال شدہ memory زیادہ concurrent requests کے لیے دستیاب ہو جاتی ہے۔ Continuous batching کے ذریعے نئی request، موجودہ batch مکمل ہونے کا انتظار کرنے کے بجائے اگلے decoding step پر جاری batch میں شامل ہو سکتی ہے۔ مکمل ہونے والی sequence فوراً batch سے نکل جاتی ہے اور اس کی جگہ دوبارہ پُر ہو جاتی ہے۔

عملی نتیجہ یہ ہے: ایک GPU پر ایک concurrent user سے تیس users تک جانے سے کل tokens per second میں نمایاں اضافہ ہوتا ہے، جبکہ ہر user کی speed توقع کے مقابلے میں کہیں کم گھٹتی ہے۔ Ollama کے default کے تحت ایک user سے تیس users تک جانے کا نتیجہ صرف یہ ہوتا ہے کہ انتیس افراد انتظار کرتے ہیں۔

مسلسل بیچنگ ہی اصل فرق ہے

فرض کریں کہ یکساں ہارڈویئر والے ہر سرور پر ایک ہی وقت میں پانچ درخواستیں پہنچتی ہیں۔

Ollama اپنی طے شدہ ترتیبات کے ساتھ پہلی درخواست کو مکمل کرتا ہے، پھر دوسری کو، اور اسی طرح آگے۔ پانچویں درخواست بھیجنے والا چار مکمل جنریشنز کا انتظار کرتا ہے۔ مجموعی تھروپٹ تقریباً ایک جنریشن کی رفتار کے برابر رہتا ہے، کیونکہ پروسیسر ایک وقت میں صرف ایک سیکوئنس پر کام کر رہا ہوتا ہے۔

vLLM پانچوں سیکوئنسز کو ایک ہی فارورڈ پاس میں ڈیکوڈ کرتا ہے۔ پانچ سیکوئنسز کے لیے ایک ٹوکن جنریٹ کرنے کی لاگت ایک سیکوئنس کے لیے ایک ٹوکن جنریٹ کرنے سے بمشکل زیادہ ہوتی ہے، کیونکہ مہنگا مرحلہ ماڈل کے ویٹس کو میموری سے پڑھنا ہے، اور یہ ریڈ پورے بیچ کے لیے مشترک ہوتا ہے۔ یہی میموری بینڈوڈتھ کا اصول CPU inference کو سست بناتا ہے: لاگت ویٹس منتقل کرنے کی ہوتی ہے، حسابی عمل کی نہیں۔

آپ OLLAMA_NUM_PARALLEL=4 سیٹ کر کے اس کا کچھ فائدہ حاصل کر سکتے ہیں۔ اس کی قیمت میموری ہے۔ ہر متوازی سلاٹ کو اپنا KV cache درکار ہوتا ہے، اور Ollama context window کو سلاٹس میں تقسیم کرتا ہے۔ اس لیے 8192 tokens کے لیے configured ماڈل کے خلاف چار متوازی درخواستوں میں ہر درخواست کے لیے 2048 tokens کا context باقی رہتا ہے۔ vLLM کا paged cache اس سمجھوتے سے بچاتا ہے، کیونکہ blocks درخواست کو اسی وقت allocate کیے جاتے ہیں جب درخواست حقیقتاً بڑھتی ہے۔

Ollama کے ساتھ انسٹال کریں اور سروس فراہم کریں

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

انسٹالیشن اسکرپٹ ایک ollama سسٹم صارف بناتا ہے، بائنری انسٹال کرتا ہے، اور ollama.service کو 127.0.0.1:11434 سے منسلک حالت میں رجسٹر کرتا ہے۔ --verbose کے ذریعے دکھائی جانے والی eval rate لائن اس مشین پر فی سیکنڈ حقیقی ٹوکنز کی تعداد ہے۔ اسے شائع کردہ کسی بھی عدد پر ترجیح دیں۔

ہم وقت چلنے والی درخواستوں کی تعداد بڑھانے کے لیے systemd drop-in استعمال کریں، تاکہ اپ گریڈ اس تبدیلی کو تبدیل نہ کرے:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps دکھاتا ہے کہ کیا لوڈ ہے، اور اس کا PROCESSOR کالم اصل صورتحال بتاتا ہے۔ 100% CPU کا مطلب ہے کہ GPU استعمال نہیں ہو رہا۔ Ollama کے سست ہونے کی زیادہ تر رپورٹس کی یہی درست وضاحت ہے۔

vLLM کے ساتھ انسٹال اور سروس چلائیں

vLLM کے لیے Linux اور Python 3.10 سے 3.13 تک درکار ہیں۔ اسے اپنے الگ virtual environment میں انسٹال کریں، کیونکہ یہ مخصوص PyTorch build انسٹال کرتا ہے:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

اس کے بعد model کو سروس کے طور پر چلائیں۔ نام Hugging Face repository id ہوتا ہے، مختصر tag نہیں:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

پہلی بار startup میں وقت لگتا ہے، کیونکہ یہ پہلے weights ڈاؤن لوڈ کرتا ہے اور پھر GPU کی profiling کرتا ہے تاکہ یہ طے کیا جا سکے کہ کتنے KV cache blocks کی گنجائش ہے۔ یہ port 8000 پر listening کرتا ہے۔ Client code لکھنے سے پہلے اسے چیک کریں:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

اگر اس server پر پہلے سے Docker موجود ہے تو official image استعمال کرنے سے CUDA dependency کا کام خودکار ہو جاتا ہے:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host ضروری ہے، محض اضافی option نہیں: PyTorch processes کے درمیان tensors منتقل کرنے کے لیے shared memory استعمال کرتا ہے، اور Docker کی default shared-memory allocation tensor-parallel inference کے لیے بہت کم ہوتی ہے۔

Production میں سب سے اہم flags یہ ہیں: --max-model-len (وہ context window جس کی لاگت برداشت کرنے کے لیے آپ تیار ہیں)، --gpu-memory-utilization (card کے resource کا وہ حصہ جسے vLLM استعمال کر سکتا ہے؛ July 2026 تک default 0.92 ہے)، ایک model کو کئی GPUs میں تقسیم کرنے کے لیے --tensor-parallel-size، اور --api-key۔

vLLM میں authentication ایک flag ہے، جبکہ Ollama میں موجود نہیں

vLLM اس وقت bearer token نافذ کرتا ہے جب آپ اسے فراہم کریں:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

یہی value VLLM_API_KEY environment variable سے بھی حاصل کی جا سکتی ہے۔ اس token کے بغیر بھیجی گئی request کو HTTP 401 ملتا ہے۔ پھر بھی یہ port 8000 کو public interface پر ظاہر کرنے کی وجہ نہیں بنتی، کیونکہ vLLM میں rate limiting نہیں ہے اور سادہ HTTP token دورانِ ترسیل پڑھا جا سکتا ہے۔ تاہم، اس کا مطلب یہ ہے کہ server میں caller کا تصور موجود ہے۔

Ollama میں ایسا کوئی انتظام نہیں ہے۔ اس میں key، login یا allow-list موجود نہیں ہے۔ جو بھی process 11434 تک پہنچ سکتا ہے، وہ models چلا، pull یا delete کر سکتا ہے۔ اسے loopback پر رکھیں اور اپنے زیرِ انتظام WireGuard VPN کے ذریعے، یا ایسے authenticating reverse proxy کے ذریعے رسائی حاصل کریں جو TLS (transport layer security) کو terminate کرتا ہو۔

ہارڈویئر: ہر ایک کو کیا درکار ہے

Ollama CPU پر چلتا ہے۔ 4-bit quantized model کے لیے فی billion parameters تقریباً نصف gigabyte RAM درکار ہوتی ہے۔ اس کے علاوہ runtime overhead کے لیے تقریباً 1 gigabyte اور context کے لیے مزید میموری درکار ہوتی ہے۔ اس لیے 3B model کو تقریباً 4 GB خالی میموری، جبکہ 8B model کو تقریباً 8 GB خالی میموری درکار ہوتی ہے۔ مشترکہ vCPU پر رفتار فی سیکنڈ single digit سے low double digit tokens تک ہوتی ہے۔ یہ memory bandwidth کا مسئلہ ہے، misconfiguration کا نہیں، اور کوئی flag اسے درست نہیں کر سکتا۔

vLLM کے لیے GPU درکار ہوتا ہے۔ اس کا default path 16-bit precision میں unquantized weights فراہم کرتا ہے۔ اس کے لیے فی billion parameters تقریباً 2 GB درکار ہوتے ہیں۔ چنانچہ 8B model کو صرف weights کے لیے تقریباً 16 GB video memory درکار ہوتی ہے۔ اس میں وہ KV cache شامل نہیں ہے جو vLLM چلانے کے لیے درکار concurrency فراہم کرتا ہے۔ 24 GB card پر cache کے لیے قابلِ استعمال گنجائش باقی رہتی ہے۔ 16 GB card پر یہ ممکن نہیں ہوتا۔ اس صورت میں آپ کو چھوٹا model منتخب کرنا ہوگا یا quantized checkpoint کے ساتھ --quantization پاس کرنا ہوگا۔ CPU backend موجود ہے، لیکن standard wheels اس کے لیے build نہیں کیے گئے۔ اس سے vLLM چلانے کی بنیادی وجہ بھی ختم ہو جاتی ہے۔

لہٰذا زیادہ تر صورتوں میں hardware کا سوال ہی software کا جواب دے دیتا ہے۔ GPU نہ ہو تو Ollama استعمال کریں۔ اگر requests کو serialise کیے جانے کی وجہ سے rented GPU صرف 5 percent utilisation پر چل رہا ہو تو vLLM استعمال کریں۔

آپ کے workload کے لیے کون سا انتخاب کریں

• ایک شخص، CPU VPS پر drafting اور summarising: Ollama۔ رفتار قابلِ قبول ہے اور اس سے آسان کوئی دوسرا طریقہ نہیں۔
• coding assistant، یا ایک MCP server جو آپ کے tools کو local model سے جوڑتا ہے، جسے صرف آپ استعمال کرتے ہیں: Ollama۔ ایک وقت میں ایک درخواست ہی اصل workload ہے۔
• اس ہفتے پانچ models کا موازنہ کرنا: Ollama۔ tagged models کو pull اور delete کرنا اسی کام کے لیے موزوں ہے، جبکہ vLLM میں ہر model کے لیے process restart کرنا پڑتا ہے۔
• ایک internal app، chat product، یا حقیقی users والی retrieval pipeline: vLLM۔ یہی وہ صورت ہے جہاں batching کا فائدہ GPU bill کو جواز فراہم کرتا ہے۔
• رات بھر میں ایک لاکھ documents کی scoring کرنے والا batch job: vLLM، زیادہ --max-num-seqs کے ساتھ۔ یہاں throughput ہی واحد اہم metric ہے؛ ہر document کی latency اہم نہیں۔
• ایسا agent platform جہاں کئی self-hosted AI agents بیک وقت model سے رابطہ کریں: vLLM، کیونکہ agent traffic فطری طور پر bursty اور parallel ہوتا ہے۔

ناکامی کی صورتیں، ان پیغامات کے ساتھ جو آپ دیکھیں گے

vLLM، KV cache کی خرابی کے ساتھ شروع ہونے سے انکار کرتا ہے۔ پیغام دونوں اعداد دکھاتا ہے:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

ماڈل ایک ایسا context window ظاہر کرتا ہے جو weights لوڈ ہونے کے بعد دستیاب میموری سے بڑا ہے۔ اسے --max-model-len 8192 کے ذریعے کم کریں، یا اگر card پر کوئی اور عمل نہیں چل رہا تو --gpu-memory-utilization بڑھائیں۔ استعمال کو تقریباً 0.95 سے زیادہ کرنا عموماً startup error کو بعد میں load کے دوران CUDA out-of-memory crash سے بدل دیتا ہے۔ یہ دونوں میں زیادہ سنگین ہے۔

Ollama، generation کے دوران Killed دکھاتا ہے۔ Linux کا out-of-memory killer نے process روک دیا، کیونکہ ماڈل کو اس مشین میں موجود RAM سے زیادہ RAM درکار تھی۔ sudo dmesg | grep -i oom سے تصدیق کریں۔ حل کم بڑا یا زیادہ quantized ماڈل استعمال کرنا ہے، نہ کہ کوئی setting تبدیل کرنا۔

Ollama اکیلے درست جواب دیتا ہے، لیکن load کے دوران رک جاتا ہے۔ کہیں بھی کوئی error ظاہر نہیں ہوتا۔ Callers کی تعداد بڑھنے کے ساتھ requests صرف زیادہ وقت لیتی ہیں، کیونکہ OLLAMA_NUM_PARALLEL=1 انہیں باری باری چلاتا ہے۔ اسے بڑھائیں اور ہر request کے لیے چھوٹا context قبول کریں، یا workload کو vLLM پر منتقل کریں۔

vLLM ہر call پر 401 واپس کرتا ہے۔ آپ نے اسے --api-key کے ساتھ شروع کیا، لیکن client کوئی Authorization header نہیں بھیجتا۔ زیادہ تر OpenAI client libraries key کے طور پر وہی value بھیجتی ہیں جو آپ فراہم کرتے ہیں، اس لیے flag ہٹانے کے بجائے وہ value client میں set کریں۔

vLLM کہتا ہے کہ ماڈل نہیں ملا۔ Ollama ضرورت کے وقت model pull کرتا ہے، vLLM ایسا نہیں کرتا۔ request body میں model field کا value اس repository id سے مطابقت رکھنا چاہیے جس کے ساتھ آپ نے vLLM شروع کیا تھا، یا اگر آپ نے اسے set کیا ہو تو --served-model-name کے value سے۔ curl http://localhost:8000/v1/models کے ذریعے عین string کی تصدیق کریں۔

دونوں کو چلانا ایک مناسب جواب ہے

یہ ایک دوسرے کے متبادل نہیں ہیں۔ عام ترتیب یہ ہوتی ہے کہ application کو سروس دینے کے لیے GPU instance پر vLLM چلایا جائے، جبکہ local scripts، cron jobs، اور model releases کے نئے ورژنز آزمانے کے لیے اسی کے ساتھ معمول کے VPS پر Ollama چلایا جائے۔ دونوں endpoints، OpenAI-compatible ہیں، اس لیے ایک client library اور base-URL تبدیل کرنا کافی ہوتا ہے۔ یہاں لاگت پر قابو رکھنا دونوں engines میں سے کسی ایک کے انتخاب سے زیادہ اہم ہے، کیونکہ غیر فعال GPU بھی مصروف GPU جتنی ہی لاگت لیتا ہے، اور agent اور inference کی لاگت کو قابلِ پیش گوئی رکھنا، server منتخب کرنے سے الگ ایک نظم ہے۔

FAQ

کیا vLLM، Ollama سے زیادہ تیز ہے؟

اسی GPU پر ایک درخواست کے لیے فرق معمولی ہوتا ہے، کیونکہ دونوں ایک ہی حساب انجام دیتے ہیں۔ متعدد بیک وقت درخواستوں کے لیے vLLM بہت آگے ہے، کیونکہ continuous batching ہر فعال sequence کو ایک ہی forward pass میں decode کرتی ہے، جبکہ Ollama کی default ترتیب انہیں ایک کے بعد ایک چلاتی ہے۔ صرف CPU والی machine پر یہ سوال لاگو نہیں ہوتا: Ollama وہاں چلتا ہے، جبکہ vLLM عملاً نہیں چلتا۔

کیا vLLM، GPU کے بغیر چل سکتا ہے؟

مفید طور پر نہیں۔ معیاری wheels، NVIDIA یا AMD GPUs کو ہدف بناتے ہیں۔ vLLM کا بنیادی مقصد، یعنی batched requests کے ذریعے accelerator کو مسلسل مصروف رکھنا، CPU پر ختم ہو جاتا ہے۔ development کے لیے CPU backend موجود ہے۔ حقیقی CPU inference کے لیے Ollama یا llama.cpp براہِ راست استعمال کریں۔

Ollama اور llama.cpp میں کیا فرق ہے؟

llama.cpp inference library ہے، جبکہ GGUF اس کا quantized weight format ہے۔ Ollama کا runner اسی پر مبنی ہے اور وہ حصے شامل کرتا ہے جو llama.cpp آپ کے ذمے چھوڑتا ہے: model registry، automatic download، resident server، systemd unit، اور OpenAI-compatible endpoint۔ Ollama نے کچھ نئے model families کے لیے اپنا engine بھی شامل کیا ہے، اس لیے دونوں اندرونی طور پر اب مکمل طور پر یکساں نہیں رہے۔

8B model کے لیے vLLM کو کتنی GPU memory درکار ہوتی ہے؟

16-bit precision پر صرف weights کے لیے تقریباً 16 GB درکار ہوتے ہیں، یعنی تقریباً 2 GB فی billion parameters، اور اس کے علاوہ KV cache کے لیے بھی جگہ درکار ہوتی ہے۔ 24 GB card مناسب رہتا ہے۔ 16 GB card کے لیے quantized checkpoint یا چھوٹا model درکار ہوتا ہے۔ vLLM card کی memory کا وہ حصہ استعمال کرتا ہے جو --gpu-memory-utilization سے مقرر ہوتا ہے؛ July 2026 تک اس کی default قدر 0.92 ہے۔

کیا ان کے درمیان تبدیل ہونے کے لیے مجھے application code تبدیل کرنا ہوگا؟

عام طور پر صرف base URL، API key، اور model name تبدیل کرنے ہوتے ہیں۔ Ollama اپنی OpenAI-compatible surface http://127.0.0.1:11434/v1 پر فراہم کرتا ہے اور key کو نظرانداز کرتا ہے، جبکہ vLLM http://localhost:8000/v1 فراہم کرتا ہے اور اگر آپ key مقرر کریں تو اسے نافذ کرتا ہے۔ model names کی شکل مختلف ہوتی ہے: Ollama کے لیے llama3.1:8b، اور vLLM کے لیے مکمل repository id، مثلاً Qwen/Qwen2.5-1.5B-Instruct۔