GPU والا VPS کب واقعی ضروری ہے؟

کیا آپ کو GPU والا VPS درکار ہے، یا CPU کافی ہے؟

GPU والے VPS سے خود model چلانے میں دو چیزیں تبدیل ہوتی ہیں: tokens کے ظاہر ہونے کی رفتار، اور یہ کہ کوئی بڑا model memory میں فٹ بھی ہوتا ہے یا نہیں۔ اس کے علاوہ کچھ تبدیل نہیں ہوتا۔ اگر آپ کا workload quantized 7B سے 27B chat model ہے جو ایک وقت میں ایک شخص کو جواب دیتا ہے، کم حجم کا embedding job ہے، یا Whisper small کے ذریعے speech transcription ہے، تو کافی RAM والا عام CPU VPS یہ کام پہلے ہی کر لیتا ہے۔ CPU سے شروع کریں، اس پیمائش کو record کریں جو آپ کے لیے مسئلہ بن رہی ہے، پھر ضرورت کے مطابق بہتر مشین پر منتقل ہوں۔

اس کی وجہ memory bandwidth ہے۔ جب language model ایک token generate کرتا ہے تو وہ درکار تمام weights کو memory سے پڑھتا ہے۔ 4 bits پر quantized 8B model disk پر تقریباً 4.9 GB لیتا ہے اور memory میں بھی تقریباً اتنی ہی جگہ استعمال کرتا ہے، اس لیے ایک token تیار کرنے کا مطلب تقریباً 4.9 GB data منتقل کرنا ہے۔ machine کی memory bandwidth کو اس مقدار سے تقسیم کریں، تو آپ کو tokens per second کی زیادہ سے زیادہ نظری رفتار مل جاتی ہے۔ آپ جو تقریباً ہر benchmark پڑھیں گے، اس کی بنیادی وضاحت یہی ایک تقسیم ہے۔

GPU آپ کو حقیقت میں کیا فراہم کرتا ہے

Bandwidth۔ جدید host میں server DDR5 فی سیکنڈ دسیوں gigabytes منتقل کرتی ہے۔ GPU memory (VRAM، video RAM) فی سیکنڈ سینکڑوں سے لے کر ایک ہزار سے زیادہ gigabytes منتقل کرتی ہے۔ یہی تناسب speedup ہے، اور یہ نمایاں ہوتا ہے۔

رفتار کے ساتھ capacity۔ 64 GB RAM والا CPU box، 4 bits پر 70B model load کر سکتا ہے۔ یہ چلے گا، لیکن رفتار chatting کے بجائے reading کے زیادہ قریب ہوگی۔ یہاں GPU صرف اسی صورت مدد دیتا ہے جب model VRAM میں سما جائے، کیونکہ layers کے system RAM میں منتقل ہوتے ہی slow path دوبارہ غالب آ جاتا ہے۔

Batch throughput۔ لوگ اس حصے کو کم اہم سمجھتے ہیں۔ جب GPU ایک user کے لیے generate کرتا ہے تو اس کی زیادہ تر compute idle رہتی ہے، کیونکہ وہ memory کا انتظار کر رہا ہوتا ہے۔ بیک وقت 20 requests serve کریں تو weight کا وہی read تمام 20 requests کے لیے استعمال ہوتا ہے۔ Aggregate tokens per second کئی گنا بڑھ جاتا ہے، جبکہ فی user رفتار میں معمولی کمی آتی ہے۔ llama.cpp جیسے CPU inference engines بھی batching کو support کرتے ہیں، اور اس کے فوائد hardware اور workload کے مطابق مختلف ہوتے ہیں۔ اگر آپ ایسی API بنا رہے ہیں جسے بہت سے clients call کریں گے، تو raw single-stream speed کے مقابلے میں batching GPU کے حق میں زیادہ مضبوط دلیل ہے۔

Prompt processing۔ طویل prompt پڑھنا compute-bound ہوتا ہے، memory-bound نہیں، اور یہی وہ مقام ہے جہاں GPUs سب سے بڑے فرق کے ساتھ بہتر کارکردگی دکھاتے ہیں۔ 30,000 tokens کا context جسے CPU ایک منٹ میں process کرتا ہے، GPU پر چند seconds میں process ہو سکتا ہے۔ وہ retrieval setups جو ہر request میں documents شامل کرتے ہیں، اس فرق کو مسلسل محسوس کرتے ہیں۔

تقریبی اعداد اور انہیں سمجھنے کا طریقہ

حقیقی throughput بھی bandwidth کو model size سے تقسیم کرنے کے نتیجے سے کم رہتی ہے، کیونکہ بڑھتے ہوئے context پر attention اضافی کام کرتی ہے جسے سادہ تقسیم نظرانداز کر دیتی ہے۔

موازنے کے لیے، انگریزی میں بالغ افراد کی خاموش مطالعے کی اوسط رفتار تقریباً 4.0 سے 4.3 الفاظ فی سیکنڈ ہے: non-fiction کے لیے 238 الفاظ فی منٹ اور fiction کے لیے 260 الفاظ فی منٹ۔ 15 tokens فی سیکنڈ یا اس سے زیادہ رفتار ایک واحد قاری کو عام typing جیسی محسوس ہوتی ہے۔ اسی لیے صرف CPU پر چلنے والے بہت سے setups عملی طور پر کافی بہتر کارکردگی دیتے ہیں۔

خرید سے پہلے VRAM کا تخمینہ لگائیں

Model file size کم از کم ضرورت ہے، مکمل ضرورت نہیں۔ Weights، KV cache (key-value cache، یعنی ہر token کے لیے attention کی برقرار رکھی ہوئی memory)، اور تقریباً 1 GB overhead کے لیے گنجائش رکھیں۔

Cache کا حساب خود لگائیں، محض ایک مقررہ percentage شامل نہ کریں، کیونکہ weights کو quantize کرنے سے cache quantize نہیں ہوتا۔ ہر token کے لیے full-attention model ہر layer اور ہر KV head کے لیے ایک key اور ایک value محفوظ کرتا ہے۔ FP16 میں ہر number کے لیے 2 bytes درکار ہوتے ہیں، اور یہ Ollama کی default cache type ہے۔ 2026-10-27 کو چیک کیے گئے Ollama کے model metadata کے مطابق، Llama 3.1 8B میں 32 layers اور 8 KV heads ہیں، جبکہ ہر head کی dimension 128 ہے۔ اس سے فی token 128 KiB بنتا ہے: 8k context پر تقریباً 1.07 GB اور 16k پر 2.15 GB۔ اس لیے 4.9 GB کا 8B model، 8k پر تقریباً 7 GB اور 16k پر تقریباً 8 GB VRAM چاہتا ہے۔ 4 bits پر 27B model تقریباً 17 GB کا ہوتا ہے (Ollama library میں Gemma 3 27B)۔ Gemma 3 کے metadata میں 1,024-token sliding window درج ہے، جو اس کے cache کے بڑے حصے کو بڑھنے سے روکتی ہے، اس لیے 20 GB یا اس سے زیادہ کی منصوبہ بندی کریں۔ 4 bits پر 70B model تقریباً 43 GB کا ہوتا ہے (Llama 3.3 70B)۔ اس میں 80 layers ہیں، اس لیے اس کا FP16 cache 8k پر تقریباً 2.7 GB اور 16k پر 5.4 GB مزید لیتا ہے۔ چنانچہ اسے 48 GB card درکار ہے، جس میں بہت کم اضافی گنجائش بچے گی، یا دو چھوٹے cards درکار ہوں گے۔ یہی حساب اس سے کہیں بڑے models پر بھی لاگو ہوتا ہے، اور Kimi K3 جیسے 2.8 trillion parameter model کے لیے VRAM کا حساب واضح کرتا ہے کہ کس مرحلے پر card منتخب کرنا بنیادی سوال ہی نہیں رہتا۔

یہ مسئلہ long contexts میں سب سے زیادہ اہم ہوتا ہے۔ Llama 3.1 جیسے full-attention models میں KV cache، context length کے ساتھ خطی طور پر بڑھتا ہے، اور 128k tokens پر weights سے بھی بڑا ہو سکتا ہے۔ Sliding-window یا chunked attention والے models مختلف ہوتے ہیں۔ Hugging Face کی Transformers documentation میں Mistral، Gemma 2 اور Llama 4 ایسی مثالوں کے طور پر دیے گئے ہیں جہاں ان layers کا cache window یا chunk size تک پہنچنے کے بعد مزید نہیں بڑھتا، اس لیے مجموعی memory زیادہ آہستہ بڑھتی ہے۔ اگر آپ long contexts استعمال کرنے کا ارادہ رکھتے ہیں تو پہلے cache کے لیے گنجائش مقرر کریں، پھر دیکھیں کہ آپ کا engine cache quantization کے لیے کیا سہولت دیتا ہے۔ Ollama میں OLLAMA_KV_CACHE_TYPE=q8_0، default f16 کی تقریباً نصف memory استعمال کرتا ہے، اور cache quantization صرف اس وقت لاگو ہوتی ہے جب Flash Attention enabled ہو۔ Context length بھی واضح طور پر set کریں۔ Ollama اپنی default value VRAM کے مطابق منتخب کرتا ہے: 24 GiB سے کم پر 4k، 24 سے 48 GiB تک 32k، اور 48 GiB یا اس سے زیادہ پر 256k۔ 48 GB card پر 70B model چلاتے وقت یہ default card کی گنجائش سے کہیں زیادہ cache طلب کرتا ہے۔

مشین پر موجود چیزوں کی تصدیق کریں

GPU instance پر کسی بھی دوسرے کام سے پہلے تصدیق کریں کہ driver کو card نظر آ رہا ہے۔

nvidia-smi

آپ کو ایسی table نظر آنی چاہیے جس میں GPU کا نام، driver version، اور استعمال شدہ memory بمقابلہ کل memory درج ہو۔ NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver کا مطلب ہے کہ NVIDIA-SMI driver تک رسائی حاصل نہیں کر سکتا؛ تصدیق کریں کہ driver installed ہے اور اس کا kernel module loaded ہے۔ stock Ubuntu image پر عموماً حل sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install ہوتا ہے، جس کے بعد reboot کریں تاکہ نیا module load ہو جائے۔ compute machines کے لیے Ubuntu کی server documentation sudo ubuntu-drivers install --gpgpu تجویز کرتی ہے، جو server driver branch منتخب کرتا ہے۔

Containers کے لیے صرف driver کافی نہیں ہوتا۔ device کو container میں منتقل کرنے کے لیے Docker کو NVIDIA Container Toolkit درکار ہوتا ہے۔

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

پھر container کے اندر سے passthrough کے کام کرنے کی تصدیق کریں:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

وہی table ظاہر ہونی چاہیے۔ docker: Error response from daemon: could not select device driver کی کوئی line، جس میں ایسی gpu capability کا نام ہو جسے پورا نہیں کیا جا سکتا، اس بات کی نشاندہی کرتی ہے کہ Docker کو request کے مطابق device driver نہیں ملا؛ تصدیق کریں کہ toolkit installed ہے، پھر nvidia-ctk line اور restart دوبارہ چلائیں۔ Compose میں اس کے مساوی ایک deploy.resources.reservations.devices entry ہے، جس کا driver، nvidia ہو اور capabilities list میں gpu شامل ہو۔ یہ عام service definitions میں شامل ہوتی ہے جن کا احاطہ VPS پر Docker Compose میں کیا گیا ہے۔

اپ گریڈ سے پہلے پیمائش کریں

وہی model چلائیں جسے آپ واقعی استعمال کرنا چاہتے ہیں۔ اسے موجودہ CPU machine پر چلائیں اور اعداد و شمار درج کریں۔ VPS پر Ollama کے ذریعے LLM کی self-hosting کے لیے صرف ایک flag درکار ہے:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

آؤٹ پٹ کے آخر میں timings شامل ہوتی ہیں۔ eval rate آپ کی generation speed کو tokens per second میں ظاہر کرتا ہے۔ prompt eval rate بتاتا ہے کہ machine نے آپ کی input کتنی رفتار سے پڑھی۔ یہ دونوں اعداد بتاتے ہیں کہ کون سا upgrade زیادہ فائدہ دے گا: کم eval rate memory bandwidth کا مسئلہ ہے، جبکہ طویل inputs پر کم prompt eval rate compute کا مسئلہ ہے۔

جس machine میں GPU موجود ہو، اس میں تصدیق کریں کہ model واقعی GPU پر load ہوا ہے:

ollama ps

PROCESSOR column میں ہر چیز کے fit ہونے پر 100% GPU دکھائی دیتا ہے، یا fit نہ ہونے کی صورت میں 43%/57% CPU/GPU جیسی قدر دکھائی دیتی ہے۔ جزوی split عموماً توقع سے زیادہ خراب ہوتا ہے، کیونکہ ہر token کو پھر بھی سست حصے کا انتظار کرنا پڑتا ہے۔

لاگت کا سوال

GPU instances کے لیے billing tokens کے بجائے provisioned compute time کے مطابق ہوتی ہے، جبکہ rates اور stopped-instance charges provider مقرر کرتا ہے۔ روزانہ صرف چند requests کو serve کرنے والا ہمیشہ چلتا ہوا GPU اپنے paid time کا زیادہ تر حصہ idle گزارتا ہے۔ break-even کا تعلق utilisation سے ہے: مصروف GPU فی token سستا ہوتا ہے، جبکہ idle GPU خالص ضیاع ہے۔

تین عملی طریقے مؤثر ہیں۔ مسلسل مگر کم volume والا کام CPU VPS پر رکھیں۔ کبھی کبھار آنے والی مشکل request کو hosted API پر بھیجیں اور فی token ادائیگی کریں۔ batch jobs، fine-tuning یا bulk embedding run کے لیے GPU کو فی گھنٹہ rent کریں، پھر اسے destroy کر دیں۔ ان طریقوں کو ملانا معمول کی بات ہے، اور ہمیشہ چلنے والے VPS پر AI agent کی لاگت کا کنٹرول میں بیان کردہ budgeting discipline یہاں بھی لاگو ہوتی ہے۔ فرق صرف یہ ہے کہ یہاں leak token count نہیں بلکہ idle time ہے۔

GPU کے بغیر بھی کیا چیزیں اچھی طرح چلتی ہیں

کم حجم میں embeddings۔ ایک چھوٹا embedding model چند CPU cores پر فی منٹ سینکڑوں مختصر دستاویزات process کر لیتا ہے، اور ایک بار بنایا گیا index تیز ہونا ضروری نہیں۔

transcription کے لیے Whisper small اور base۔ CPU پر Faster-whisper، small model کے ساتھ تقریباً real time میں transcription کر لیتا ہے۔ یہ ایسے pipeline کے لیے کافی ہے جو رات بھر چلتا رہے۔

ایک یا دو users کے لیے تقریباً 27B تک کے quantized chat models۔ رفتار کم ہوگی، لیکن output پڑھنے اور استعمال کرنے کے قابل ہوگا۔

ہر وہ کام جسے آپ batch job کہیں گے۔ اگر کوئی screen نہیں دیکھ رہا تو wall-clock speed ضرورت کے بجائے scheduling کی تفصیل بن جاتی ہے۔

GPU کی حقیقی ضرورت ان کاموں کے لیے ہوتی ہے: کسی چھوٹے adapter سے آگے training یا fine-tuning، بیک وقت متعدد users کو service دینا، image اور video generation، اور real-time speech، جہاں latency ہی بنیادی product ہو۔

FAQ

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

8k context پر 4-bit quantized 8B model کے لیے تقریباً 7 GB، اور 16k پر تقریباً 8 GB درکار ہوتی ہے، اگر Ollama کا default FP16 cache استعمال ہو۔ Weights تقریباً 4.9 GB ہوتے ہیں، KV cache 8k پر تقریباً 1.07 GB یا 16k پر 2.15 GB شامل کرتا ہے، جبکہ باقی overhead تقریباً 1 GB ہوتا ہے۔ 8 GB card اسے 8k پر چلا لیتا ہے، مگر 16k پر گنجائش بہت کم رہ جاتی ہے۔ 12 GB card طویل contexts کے لیے مناسب اضافی گنجائش فراہم کرتا ہے۔ Cache کو q8_0 پر تبدیل کرنے سے cache کا حصہ تقریباً نصف رہ جاتا ہے۔ اگر آپ 128k context پر چلانے کا ارادہ رکھتے ہیں تو cache کے لیے الگ سے گنجائش رکھیں، کیونکہ یہ weights سے زیادہ بڑا ہو سکتا ہے۔

کیا میں GPU کے بغیر Ollama چلا سکتا ہوں؟

ہاں۔ Ollama خودکار طور پر CPU پر منتقل ہو جاتا ہے اور صرف اتنی RAM درکار ہوتی ہے جس میں model سما سکے۔ Memory speed کے مطابق 4-bit 8B model کے لیے تقریباً 5 سے 12 tokens فی سیکنڈ کی رفتار متوقع ہے، جو ایک user کے لیے عام reading pace کے قریب ہے۔ CPU پر اصل مسئلہ طویل prompts ہوتے ہیں، کیونکہ 30,000 tokens کا context پڑھنا compute-bound ہوتا ہے اور reply generate کرنے کے مقابلے میں کہیں زیادہ وقت لیتا ہے۔

میرا GPU CPU سے بمشکل تیز کیوں ہے؟

عام وجہ یہ ہے کہ model مکمل طور پر VRAM میں fit نہیں ہوا۔ اس لیے کچھ layers CPU پر چلتی ہیں اور ہر token کو سست حصے کا انتظار کرنا پڑتا ہے۔ ollama ps چلائیں اور دیکھیں کہ PROCESSOR column میں 100% GPU لکھا ہے۔ اگر split نظر آئے تو چھوٹی quantization یا چھوٹا model استعمال کریں۔ دوسری عام وجہ مختصر benchmark ہے، جس میں model load time پیمائش پر غالب آ جاتا ہے۔

کیا ایک user کے لیے GPU VPS لینا فائدہ مند ہے؟

عام طور پر نہیں۔ English میں بالغ افراد کی خاموش reading کی اوسط رفتار تقریباً 4.0 سے 4.3 الفاظ فی سیکنڈ ہے، اور CPU box کی رفتار کا اس pace سے موازنہ کرنے سے پہلے tokens فی سیکنڈ کو words فی سیکنڈ میں تبدیل کرنا ضروری ہے۔ ایک user کے لیے اس لاگت کو درست ثابت کرنے والے حالات میں طویل prompts، image generation اور fine-tuning شامل ہیں۔ ایک ہی وقت میں متعدد users کو service دینا سب سے مضبوط جواز ہے، کیونکہ batching ایک GPU کو requests کے درمیان weight reads share کرنے دیتی ہے۔

کیا مجھے GPU فی گھنٹہ کرائے پر لینا چاہیے یا اسے ہمیشہ چلتا رکھنا چاہیے؟

جب کام bursty ہو، مثلاً fine-tuning، bulk embedding run یا batch transcription job، تو فی گھنٹہ کرائے پر لیں۔ اسے ہمیشہ صرف اسی وقت چلتا رکھیں جب card مسلسل مصروف رہے، کیونکہ provisioned GPU compute tokens کی تعداد کے بجائے وقت کے حساب سے بل کیا جاتا ہے۔ کم traffic والا assistant idle GPU کے مقابلے میں CPU VPS یا tokens کے حساب سے ادائیگی والی hosted API پر سستا ہوتا ہے۔