Ollama یا vLLM: LLM server کے لیے کیا چنیں؟

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

Ollama ایک model manager ہے جس کے ساتھ server منسلک ہوتا ہے: یہ quantized weights download اور load کرتا ہے، پھر 127.0.0.1:11434 پر جواب دیتا ہے؛ اگر سسٹم میں صرف CPU موجود ہو تو اسی پر کام کرتا ہے۔ vLLM ایک throughput engine ہے: یہ بیک وقت چلنے والی متعدد requests کے ذریعے GPU کو مسلسل مصروف رکھتا ہے، اس لیے ایسے machine پر یہ درست انتخاب نہیں جس میں GPU موجود نہ ہو۔ فیصلہ اتنا ہی ہے۔ کسی مقامی 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 کا local store، chat prompt، systemd service، اور HTTP API فراہم کرتا ہے۔ یہ جن models کو serve کرتا ہے وہ GGUF files ہوتی ہیں، جو عموماً 4-bit quantized ہوتی ہیں۔ اسی لیے 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 بھی شامل کیا، لیکن اس کی فراہم کردہ زیادہ تر functionality کے نیچے اب بھی llama.cpp بنیادی substrate ہے۔ اس لیے جب لوگ Ollama کا موازنہ llama.cpp سے کرتے ہیں تو وہ زیادہ تر ergonomics layer کا اس چیز سے موازنہ کر رہے ہوتے ہیں جسے وہ wrap کرتی ہے۔

اس design کا ہدف ایک 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 manage نہیں کرتا، اس میں chat prompt موجود نہیں ہوتا، اور request کے وقت یہ آپ کے لیے model download نہیں کرے گا۔ آپ launch کے وقت Hugging Face repository کا نام دیتے ہیں، یہ وہی ایک model load کرتا ہے، اور process روکنے تک اسے serve کرتا رہتا ہے۔

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

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

مسلسل batching ہی تمام فرق پیدا کرتی ہے

تصور کریں کہ ایک ہی وقت میں یکساں hardware پر چلنے والے ہر server پر پانچ requests پہنچتی ہیں۔

Ollama کی default settings میں پہلے request ایک کو مکمل کرتا ہے، پھر request دو کو، اور اسی طرح آگے بڑھتا ہے۔ پانچویں caller کو چار مکمل generations کا انتظار کرنا پڑتا ہے۔ مجموعی throughput تقریباً ایک generation کی رفتار کے برابر رہتا ہے، کیونکہ processor ایک وقت میں صرف ایک sequence پر کام کر رہا ہوتا ہے۔

vLLM پانچوں کو ایک ہی forward pass میں decode کرتا ہے۔ پانچ sequences کے لیے ایک token generate کرنے کی لاگت ایک sequence کے لیے ایک token generate کرنے سے بمشکل زیادہ ہوتی ہے، کیونکہ مہنگا مرحلہ model weights کو memory سے پڑھنا ہے، اور یہ read پورے batch میں مشترک ہوتی ہے۔ یہی memory-bandwidth حقیقت CPU inference کو سست بناتی ہے: لاگت weights منتقل کرنے کی ہوتی ہے، arithmetic کرنے کی نہیں۔

آپ OLLAMA_NUM_PARALLEL=4 set کر کے اس کا کچھ فائدہ حاصل کر سکتے ہیں۔ اس کی قیمت memory ہے۔ ہر parallel slot کو اپنا KV cache درکار ہوتا ہے، اور Ollama context window کو slots کے درمیان تقسیم کرتا ہے، اس لیے 8192 tokens کے لیے configured model کے خلاف چار parallel requests میں ہر request کے لیے 2048 tokens کا context باقی رہتا ہے۔ 8192 بھی پہلے سے طے شدہ قدر نہیں بلکہ ایک انتخاب ہے، اس لیے num_ctx بڑھانا اور اس کے لیے درکار RAM کا حجم طے کرنا وہ مرحلہ ہے جو فیصلہ کرتا ہے کہ چار slots سرے سے قابل استعمال بھی ہیں یا نہیں۔ vLLM کا paged cache اس trade-off سے بچاتا ہے، کیونکہ blocks اسی وقت request کو allocate کیے جاتے ہیں جب request حقیقتاً بڑھتی ہے۔ دونوں صورتوں میں ایک ہی box بیک وقت کتنے لوگوں کو service دے سکتا ہے، اس کی حد KV cache size، prefill cost اور queue depth پر منحصر ہوتی ہے؛ یہی وجہ ہے کہ جو server ایک شخص کے لیے ٹھیک محسوس ہوتا تھا، پانچ افراد پر سست ہو جاتا ہے۔

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 system user بناتا ہے، binary انسٹال کرتا ہے، اور ollama.service کو 127.0.0.1:11434 سے bind کر کے رجسٹر کرتا ہے۔ --verbose کی طرف سے دکھائی جانے والی eval rate لائن اس machine پر tokens per second کی حقیقی رفتار ہے۔ شائع کردہ کسی بھی عدد کے مقابلے میں اسی کو معتبر سمجھیں۔ ایک prompt کی ایک reading صرف ابتدائی نقطۂ آغاز ہے، capacity کا عدد نہیں۔ اس لیے مختلف concurrency کے دوران tokens per second کی پیمائش ہی بتاتی ہے کہ machine آپ کی متوقع load کو سنبھال سکتی ہے یا نہیں، اور GPU کرائے پر لینا per-token ادائیگی سے بہتر ہے یا نہیں۔

concurrency بڑھانے کے لیے systemd drop-in استعمال کریں تاکہ upgrade اس تبدیلی کو overwrite نہ کرے:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

ollama ps سے معلوم ہوتا ہے کہ کیا load ہے، جبکہ اس کا PROCESSOR column اصل صورتِ حال بتاتا ہے۔ 100% CPU کا مطلب ہے کہ GPU استعمال نہیں ہو رہا۔ Ollama کے سست ہونے کی زیادہ تر رپورٹس کی یہی حقیقی وجہ ہے۔ اس drop-in میں OLLAMA_KEEP_ALIVE=30m لائن کم load والی machine پر بھی اتنی ہی اہم ہے، کیونکہ default configuration کسی request کے بغیر پانچ منٹ بعد model کو unload کر دیتی ہے، اور requests کے درمیان model کو resident رکھنا ہی idle hour کے بعد آنے والے پہلے prompt کو دوبارہ مکمل load time ادا کرنے سے روکتا ہے۔

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 کو service فراہم کریں۔ نام Hugging Face repository id ہوتا ہے، مختصر tag نہیں:

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

پہلی بار startup سست ہوتا ہے، کیونکہ یہ پہلے weights download کرتا ہے اور پھر 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?"}]}'

اگر box پر 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 ضروری ہے، محض ظاہری نہیں: PyTorch processes کے درمیان tensors منتقل کرنے کے لیے shared memory استعمال کرتا ہے، اور Docker کی default shared-memory allocation tensor-parallel inference کے لیے بہت کم ہوتی ہے۔

Production میں سب سے اہم flags --max-model-len ہیں، یعنی وہ context window جس کی لاگت آپ قبول کرنے کو تیار ہیں؛ --gpu-memory-utilization، یعنی card کا وہ حصہ جسے vLLM استعمال کر سکتا ہے، جو July 2026 تک default طور پر 0.92 ہے؛ --tensor-parallel-size، جو ایک model کو کئی GPUs میں تقسیم کرتا ہے؛ اور --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 سے بھی حاصل کی جا سکتی ہے۔ اس کے بغیر بھیجی گئی request کو HTTP 401 ملتا ہے۔ پھر بھی port 8000 کو public interface پر کھولنے کی وجہ نہیں بنتی، کیونکہ vLLM میں rate limiting نہیں ہے اور plain HTTP token دورانِ ترسیل پڑھا جا سکتا ہے۔ تاہم اس کا مطلب یہ ہے کہ server میں caller کا تصور موجود ہے۔

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

Hardware: ہر ایک کے لیے درکار وسائل

Ollama CPU پر چلتا ہے۔ 4-bit quantized model کے لیے ہر billion parameters پر تقریباً آدھا gigabyte RAM درکار ہوتی ہے۔ اس کے علاوہ runtime overhead کے لیے تقریباً 1 gigabyte اور context کے لیے مزید memory درکار ہوتی ہے۔ اس لیے 3B model کے لیے تقریباً 4 GB free memory، جبکہ 8B model کے لیے تقریباً 8 GB درکار ہوتی ہے۔ مشترکہ vCPU پر رفتار عموماً single digit سے low double digit tokens per second ہوتی ہے۔ یہ memory bandwidth کی حد ہے، misconfiguration نہیں، اور کوئی flag اسے درست نہیں کر سکتا۔ کسی عمومی اصول کے بجائے کسی مخصوص release پر یہ حساب دیکھنے کے لیے VPS پر Nemotron 3.5 Lightning چلانا وہ exact tag متعین کرتا ہے جسے pull کرنا ہے، load ہونے کے بعد model کتنی RAM استعمال کرتا ہے، اور آیا صرف CPU پر اس کی رفتار قابلِ قبول ہے یا نہیں۔

vLLM عام طور پر GPU فرض کرتا ہے۔ اس کا default path unquantized weights کو 16-bit precision پر serve کرتا ہے، جس کے لیے ہر 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، اور مسودہ نویسی یا خلاصہ تیار کرنا: Ollama۔ رفتار قابل قبول ہے اور اس سے زیادہ آسان کوئی انتخاب نہیں۔
• coding assistant، یا آپ کے tools کو مقامی model سے جوڑنے والا MCP server، جسے صرف آپ استعمال کرتے ہیں: Ollama۔ اصل workload میں concurrency ایک ہی ہے۔
• اس ہفتے پانچ models کا موازنہ کرنا: Ollama۔ tagged models کو pull اور delete کرنا اسی کام کے لیے موزوں ہے، جبکہ vLLM میں ہر model کے لیے process restart درکار ہوتا ہے۔
• ایک داخلی app، chat product، یا حقیقی users والی retrieval pipeline: vLLM۔ اسی صورت میں batching کا فائدہ GPU bill کو جواز فراہم کرتا ہے۔
• رات بھر میں ایک لاکھ documents کی scoring کرنے والا batch job: vLLM، زیادہ --max-num-seqs کے ساتھ۔ صرف throughput اہم ہے، جبکہ ہر document کی latency اہم نہیں۔
• ایسا agent platform جس پر متعدد self-hosted AI agents بیک وقت model تک پہنچتے ہوں: vLLM، کیونکہ agent traffic فطری طور پر bursty اور parallel ہوتا ہے۔

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

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

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 لوڈ ہونے کے بعد دستیاب memory سے بڑی ہے۔ اسے --max-model-len 8192 کے ذریعے کم کریں، یا اگر card پر کوئی اور عمل نہیں چل رہا تو --gpu-memory-utilization بڑھائیں۔ utilisation کو تقریباً 0.95 سے زیادہ کرنے پر عموماً یہ startup error بعد میں load کے دوران CUDA out-of-memory crash میں تبدیل ہو جاتا ہے، جو دونوں میں زیادہ سنگین صورت ہے۔

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

Ollama اکیلے درست جواب دیتا ہے لیکن load کے دوران رک جاتا ہے۔ کہیں بھی کوئی error ظاہر نہیں ہوتا۔ Callers کی تعداد بڑھنے کے ساتھ requests صرف زیادہ وقت لیتی ہیں، کیونکہ OLLAMA_NUM_PARALLEL=1 انہیں serial انداز میں چلاتا ہے۔ طویل جوابات queue کو مزید خراب کرتے ہیں، کیونکہ ایک caller کے واحد slot کو اس وقت تک روکے رکھنے سے، جب تک model رکنے کا فیصلہ نہ کرے، اس کے پیچھے موجود تمام callers بلاک رہتے ہیں۔ اس لیے num_predict کے ذریعے جواب کی حد مقرر کرنا اس بات کی زیادہ سے زیادہ مدت مقرر کرتا ہے کہ کوئی ایک turn server کا slot کتنی دیر تک روک سکتا ہے۔ Parallel setting بڑھائیں اور فی request کم context قبول کریں، یا workload کو vLLM پر منتقل کریں۔

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

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

دونوں کو چلانا ایک معقول حل ہے

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

FAQ

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

اسی GPU پر ایک درخواست کے لیے فرق معمولی ہوتا ہے، کیونکہ دونوں ایک ہی حساب انجام دیتے ہیں۔ متعدد بیک وقت درخواستوں کے لیے vLLM بہت آگے ہے، کیونکہ continuous batching ہر فعال sequence کو ایک ہی forward pass میں decode کرتی ہے، جبکہ Ollama کی default ترتیب انہیں ایک کے بعد ایک چلاتی ہے۔ صرف CPU والی مشین پر یہ سوال لاگو نہیں ہوتا: 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 value 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۔