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

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

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

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

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

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

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

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

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

تقریبی اعداد اور انہیں پڑھنے کا طریقہ

ذیل کا جدول July 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 ratio سے مطابقت رکھتا ہے۔ حقیقی throughput عموماً bandwidth کو model size سے تقسیم کرنے کے نتیجے سے بھی کم ہوتا ہے، کیونکہ بڑھتے ہوئے context پر attention اضافی کام کرتا ہے جسے یہ سادہ تقسیم نظرانداز کرتی ہے۔

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

خرید سے پہلے VRAM کا حجم طے کرنا

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

July 2026 تک ایک عملی اصول یہ ہے: model file کا حجم gigabytes میں لیں اور معمول کے 8k سے 16k context کے لیے اس میں 20 فیصد شامل کریں۔ 4.7 GB کا 8B model تقریباً 6 GB VRAM چاہتا ہے۔ 4 bits پر 27B model کا حجم تقریباً 16 GB ہوتا ہے اور اسے تقریباً 20 GB درکار ہوتی ہے۔ 4 bits پر 70B کا حجم تقریباً 40 GB ہوتا ہے اور اسے 48 GB card یا دو چھوٹے cards درکار ہوتے ہیں۔ یہی حساب اس سے کہیں بڑے models کے لیے بھی کارآمد رہتا ہے، اور Kimi K3 جیسے 2.8 trillion parameter model کے لیے VRAM کا حساب دکھاتا ہے کہ کس مرحلے پر card منتخب کرنا بنیادی سوال نہیں رہتا۔

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

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

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 کا مطلب ہے کہ driver موجود نہیں، یا kernel upgrade کے بعد kernel module دوبارہ build نہیں ہوا۔ عام Ubuntu image پر عموماً sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install چلانا مسئلہ حل کرتا ہے۔ اس کے بعد reboot کریں تاکہ نیا module load ہو جائے۔

Containers کے لیے صرف driver کافی نہیں ہوتا۔ Docker کو device pass through کرنے کے لیے 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 کے اندر سے pass through کی کامیابی ثابت کریں:

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 کا نام ہو جسے وہ پورا نہیں کر سکتی، اس کا مطلب ہے کہ toolkit install ہے لیکن Docker کو دوبارہ configure یا restart نہیں کیا گیا۔ اس لیے 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، تقابلی CPU instance کے مقابلے میں کئی گنا مہنگے ہوتے ہیں، اور ان کے موجود رہنے کے ہر گھنٹے کی فیس لی جاتی ہے؛ تیار کیے گئے tokens کی تعداد کے حساب سے نہیں۔ ایسا ہمیشہ آن GPU جو روزانہ صرف چند requests فراہم کرے، inference چلانے کا سب سے مہنگا طریقہ ہے۔ اصل فیصلہ کن عنصر utilisation ہے: مصروف GPU فی token کم لاگت رکھتا ہے، جبکہ idle GPU خالص ضیاع ہے۔

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

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 ماڈل کے لیے کتنی VRAM درکار ہے؟

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

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

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

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

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

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

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

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

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