GPU والا VPS کب لینا چاہیے؟ CPU کب کافی ہے؟

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

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

اس کی وجہ memory bandwidth ہے۔ جب language model ایک token تیار کرتا ہے، تو وہ درکار تمام weights کو میموری سے پڑھتا ہے۔ 4 bits پر quantized 8B model ڈسک پر تقریباً 4.7 GB ہوتا ہے اور میموری میں بھی تقریباً اتنی ہی جگہ لیتا ہے، اس لیے ایک token تیار کرنے کا مطلب تقریباً 4.7 GB ڈیٹا منتقل کرنا ہے۔ مشین کی memory bandwidth کو اس مقدار سے تقسیم کریں، تو tokens per second کی زیادہ سے زیادہ حد حاصل ہو جاتی ہے۔ یہی ایک تقسیم تقریباً ہر اس benchmark کی وضاحت کرتی ہے جسے آپ پڑھیں گے۔

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

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

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

Batch throughput۔ لوگ اس حصے کو کم سمجھتے ہیں۔ ایک user کے لیے generation کرتے وقت GPU کی زیادہ تر compute capacity idle رہتی ہے، کیونکہ وہ memory کا انتظار کر رہا ہوتا ہے۔ ایک وقت میں 20 requests کو serve کریں تو وہی weight read، تمام 20 requests کے لیے استعمال ہوتی ہے۔ مجموعی tokens per second کئی گنا بڑھ جاتے ہیں، جبکہ ہر user کی رفتار میں معمولی کمی آتی ہے۔ CPU ایسا نہیں کر سکتا۔ CPU box پر بیک وقت دو users ایک دوسرے کی رفتار تقریباً نصف کر دیتے ہیں۔ اگر آپ ایسی API بنا رہے ہیں جسے بہت سے clients call کریں گے، تو batching، raw single-stream speed کے مقابلے میں GPU کے حق میں زیادہ مضبوط دلیل ہے۔

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

تخمینی اعداد، اور انہیں کیسے پڑھیں

ذیل کا حصہ جولائی 2026 تک 4-bit quantization والے 8B model کے لیے شائع شدہ single-stream اعداد فراہم کرتا ہے۔ یہ صرف order-of-magnitude رہنمائی ہیں، ضمانت نہیں۔ آپ کی quantization، context length اور inference engine ان اعداد کو تبدیل کر سکتی ہیں۔

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

24 GB GPU والی قطار میں 50 tokens per second دکھائے گئے ہیں، جبکہ DDR5 CPU box کے لیے یہ مقدار 11 ہے۔ یہ تقریباً پانچ گنا فرق ہے، جو raw compute کے فرق کے بجائے bandwidth کے تناسب سے مطابقت رکھتا ہے۔ حقیقی throughput، bandwidth کو model size سے تقسیم کرنے کے نتیجے سے بھی کم ہوتا ہے، کیونکہ بڑھتے ہوئے context پر attention اضافی کام کرتا ہے جسے یہ سادہ تقسیم نظرانداز کرتی ہے۔

موازنے کے لیے، ایک شخص تقریباً 5 سے 10 الفاظ فی سیکنڈ پڑھتا ہے۔ ایک ہی قاری کے لیے 15 tokens per second یا اس سے زیادہ رفتار پہلے ہی عام typing جیسی محسوس ہوتی ہے۔ اسی لیے صرف CPU استعمال کرنے والے بہت سے setups خاموشی سے کافی کارآمد ہوتے ہیں۔

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

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

July 2026 تک ایک عملی اصول یہ ہے: model file size کو gigabytes میں لیں اور عام 8k سے 16k context کے لیے اس میں 20 فیصد شامل کریں۔ 4.7 GB کا 8B model تقریباً 6 GB VRAM چاہتا ہے۔ 4 bits پر 27B model تقریباً 16 GB کا ہوتا ہے اور اسے تقریباً 20 GB درکار ہوتی ہے۔ 4 bits پر 70B model تقریباً 40 GB کا ہوتا ہے اور اسے 48 GB card یا دو چھوٹے cards درکار ہوتے ہیں۔

طویل contexts اس اصول کو ناکافی بنا دیتے ہیں۔ KV cache، context length کے ساتھ خطی طور پر بڑھتا ہے، اور 128k tokens پر یہ خود weights سے بھی زیادہ ہو سکتا ہے۔ اگر آپ طویل contexts استعمال کرنے کا ارادہ رکھتے ہیں تو پہلے cache کے لیے مطلوبہ گنجائش کا تخمینہ لگائیں، پھر دیکھیں کہ آپ کا engine cache quantization کے لیے کیا سہولیات فراہم کرتا ہے۔

مشین میں موجود اصل چیزیں چیک کریں

GPU instance پر، کسی بھی دوسرے کام سے پہلے تصدیق کریں کہ driver کارڈ کو دیکھ رہا ہے۔

nvidia-smi

آپ کو ایسی جدول درکار ہے جس میں GPU کا نام، driver version، اور کل memory میں سے استعمال شدہ memory درج ہو۔ NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver کا مطلب ہے کہ driver موجود نہیں، یا kernel upgrade کے بعد kernel module دوبارہ build نہیں ہوا۔ معیاری Ubuntu image پر عموماً sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install سے مسئلہ حل ہو جاتا ہے۔ اس کے بعد reboot کریں تاکہ نیا module load ہو جائے۔

Containers کے لیے صرف driver کافی نہیں ہے۔ ڈیوائس کو 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

وہی جدول دوبارہ ظاہر ہونی چاہیے۔ docker: Error response from daemon: could not select device driver کی ایسی سطر، جس میں وہ gpu capability درج ہو جسے پورا نہیں کیا جا سکتا، اس بات کی علامت ہے کہ toolkit انسٹال ہے، لیکن Docker کو دوبارہ configure یا restart نہیں کیا گیا۔ اس لیے nvidia-ctk والی سطر دوبارہ چلائیں اور 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."

آؤٹ پٹ کے آخر میں timing کے اعداد ہوتے ہیں۔ 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 میں ہر چیز کے فٹ ہونے پر 100% GPU دکھائی دیتا ہے، یا فٹ نہ ہونے پر 43%/57% CPU/GPU جیسی قدر دکھائی دیتی ہے۔ جزوی تقسیم عموماً توقع سے زیادہ خراب کارکردگی دیتی ہے، کیونکہ ہر token کو اب بھی سست حصے کا انتظار کرنا پڑتا ہے۔

لاگت کا سوال

GPU instances کی لاگت اسی نوعیت کے CPU instance کے مقابلے میں کئی گنا زیادہ ہوتی ہے۔ ان کے لیے ہر اس گھنٹے کی فیس لی جاتی ہے جس میں وہ موجود ہوں، نہ کہ ان tokens کی تعداد کے مطابق جو وہ تیار کرتے ہیں۔ ایسا always-on GPU جو روزانہ صرف چند requests کو serve کرے، inference چلانے کا سب سے مہنگا طریقہ ہے۔ اصل فرق utilisation سے پڑتا ہے: مصروف GPU فی token کم لاگت رکھتا ہے، جبکہ غیر فعال GPU محض ضیاع ہے۔

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

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

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

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

تقریباً 27B تک کے quantized chat models، ایک یا دو users کے لیے۔ رفتار کم ہوتی ہے، لیکن نتائج قابلِ مطالعہ اور قابلِ استعمال رہتے ہیں۔

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

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

FAQ

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

عام 8k سے 16k context کے ساتھ 4-bit quantized 8B model کے لیے تقریباً 6 GB درکار ہے۔ Weights تقریباً 4.7 GB ہوتے ہیں، جبکہ باقی جگہ KV cache اور تقریباً 1 GB overhead کے لیے استعمال ہوتی ہے۔ 12 GB card زیادہ طویل context کے لیے مناسب گنجائش فراہم کرتا ہے۔ اگر آپ 128k context چلانا چاہتے ہیں تو cache کے لیے الگ سے گنجائش مقرر کریں، کیونکہ یہ weights سے بھی بڑا ہو سکتا ہے۔

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

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

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

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

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

عام طور پر نہیں۔ ایک شخص 5 سے 10 الفاظ فی سیکنڈ کی رفتار سے پڑھتا ہے، جبکہ CPU box تقریباً 13B تک کے models کے لیے اس سے زیادہ رفتار سے tokens تیار کر لیتا ہے۔ ایک user کے لیے اضافی لاگت کو جائز قرار دینے والی صورتوں میں طویل prompts، image generation، اور fine-tuning شامل ہیں۔ بیک وقت متعدد users کو service فراہم کرنا اس کے حق میں سب سے مضبوط دلیل ہے، کیونکہ batching کے ذریعے ایک GPU تقریباً ایک request کے جواب کی لاگت میں بیس requests کے جواب دے سکتا ہے۔

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

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