GPU वाला VPS कब चाहिए, CPU कब पर्याप्त है

क्या आपको GPU वाला VPS चाहिए, या CPU पर्याप्त है?

GPU वाला VPS स्वयं कोई मॉडल चलाने पर दो चीज़ों को बदलता है: tokens कितनी तेज़ी से निकलते हैं, और कोई मॉडल 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 disk पर लगभग 4.7 GB और memory में भी लगभग उतना ही होता है, इसलिए एक token बनाने का अर्थ लगभग 4.7 GB data स्थानांतरित करना है। मशीन की memory bandwidth को उस संख्या से विभाजित करें। इससे tokens per second की अधिकतम सीमा मिलती है। यही एक division आपके पढ़े जाने वाले लगभग हर benchmark को समझाता है।

GPU से वास्तव में आपको क्या मिलता है

बैंडविड्थ। आधुनिक होस्ट में Server DDR5 प्रति सेकंड दसियों gigabytes डेटा स्थानांतरित करता है। GPU memory (VRAM, video RAM) प्रति सेकंड सैकड़ों से लेकर 1,000 से अधिक gigabytes डेटा स्थानांतरित करती है। यही अनुपात speedup है, और यह काफी बड़ा होता है।

गति के साथ क्षमता। 64 GB RAM वाला CPU box 4 bits पर 70B model load कर सकता है। यह चलेगा, लेकिन chatting की तुलना में reading जैसी गति से। यहां GPU तभी मदद करता है जब model VRAM में समा जाए, क्योंकि layers के system RAM में जाते ही धीमा मार्ग फिर से प्रभावी हो जाता है।

Batch throughput। यह वह हिस्सा है जिसे लोग कम आंकते हैं। एक user के लिए generation करते समय GPU की अधिकांश compute क्षमता निष्क्रिय रहती है, क्योंकि वह memory की प्रतीक्षा कर रहा होता है। एक साथ 20 requests serve करें, तो वही weight read सभी 20 requests के लिए काम करता है। कुल tokens per second कई गुना बढ़ जाता है, जबकि प्रत्येक user की speed में बहुत कम कमी आती है। CPU ऐसा नहीं कर सकता। CPU box पर दो concurrent users एक-दूसरे की गति को लगभग आधा कर देते हैं। यदि आप ऐसा API बना रहे हैं जिसे अनेक clients call करेंगे, तो raw single-stream speed की तुलना में batching GPU के पक्ष में अधिक मजबूत तर्क है।

Prompt processing। लंबा prompt पढ़ना compute-bound होता है, memory-bound नहीं। यही वह क्षेत्र है जहां GPU सबसे बड़े अंतर से बेहतर प्रदर्शन करते हैं। 30,000 token का context जिसे CPU process करने में एक मिनट लगाता है, GPU पर कुछ seconds में process हो सकता है। ऐसे 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 शब्द प्रति सेकंड पढ़ता है। एकल reader के लिए 15 tokens per second या उससे अधिक गति पहले ही सामान्य typing जैसी लगती है। इसी कारण केवल CPU वाले कई setup बिना किसी समस्या के पर्याप्त रहते हैं।

खरीदने से पहले VRAM का आकार निर्धारित करें

Model file का आकार न्यूनतम सीमा है, आवश्यकता नहीं। Weights, साथ में KV cache (key-value cache, यानी attention द्वारा प्रति-token रखा जाने वाला memory), और लगभग 1 GB overhead के लिए budget निर्धारित करें।

July 2026 के अनुसार एक व्यावहारिक नियम यह है: सामान्य 8k से 16k context के लिए model file का आकार gigabytes में लें और उसमें 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 चाहिए।

Long contexts इस नियम को विफल कर देते हैं। KV cache context length के साथ रैखिक रूप से बढ़ता है, और 128k tokens पर यह स्वयं weights से भी बड़ा हो सकता है। यदि आप long 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 नहीं हुआ। Stock Ubuntu image पर आमतौर पर इसका समाधान sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install चलाना है। इसके बाद reboot करें, ताकि नया module load हो सके।

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 का नाम हो जिसे वह पूरा नहीं कर सकता, बताती है कि toolkit install है, लेकिन Docker को फिर से configure या restart नहीं किया गया। इसलिए nvidia-ctk वाली line दोबारा चलाएँ और restart करें। Compose में इसका समकक्ष एक deploy.resources.reservations.devices entry है, जिसका driver, nvidia हो और जिसकी capabilities list में gpu हो। इसे VPS पर Docker Compose में बताए गए सामान्य service definitions में शामिल किया जा सकता है।

अपग्रेड से पहले माप लें

जिस मॉडल का आप वास्तव में उपयोग करना चाहते हैं, उसे अपने मौजूदा CPU सर्वर पर चलाएँ और परिणाम दर्ज करें। VPS पर Ollama के साथ LLM को स्वयं होस्ट करना में इसके लिए केवल एक 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 बताता है कि मशीन आपके input को कितनी तेज़ी से पढ़ती है। इन दोनों संख्याओं से पता चलता है कि कौन-सा upgrade उपयोगी होगा: कम eval rate memory-bandwidth की समस्या है, जबकि लंबे input पर कम prompt eval rate compute की समस्या है।

जिस मशीन में GPU हो, वहाँ जाँचें कि मॉडल वास्तव में GPU पर लोड हुआ है:

ollama ps

PROCESSOR column में सब कुछ फिट होने पर 100% GPU दिखता है। यदि मॉडल फिट न हो, तो इसमें 43%/57% CPU/GPU जैसा कुछ दिख सकता है। आंशिक रूप से split किया गया मॉडल अक्सर आपकी अपेक्षा से खराब प्रदर्शन करता है, क्योंकि प्रत्येक token को धीमे हिस्से का इंतज़ार करना पड़ता है।

लागत का प्रश्न

GPU instances की लागत तुलनीय CPU instance की तुलना में कई गुना अधिक होती है। इनके लिए हर उस घंटे का शुल्क लिया जाता है, जब ये उपलब्ध रहते हैं, न कि इनके द्वारा बनाए गए tokens के आधार पर। दिन में कुछ ही requests को संभालने वाला हमेशा चालू GPU, inference चलाने का सबसे महंगा तरीका है। लागत-समता utilisation पर निर्भर करती है: व्यस्त GPU प्रति token सस्ता होता है, जबकि निष्क्रिय GPU पूरी तरह की बर्बादी है।

तीन व्यावहारिक तरीके उपयोगी हैं। लगातार कम मात्रा वाले काम को CPU VPS पर चलाएँ। कभी-कभार आने वाली कठिन request को hosted API पर भेजें और प्रति token भुगतान करें। batch jobs, fine-tuning या bulk embedding run के लिए GPU को प्रति घंटे के हिसाब से किराये पर लें और काम पूरा होने पर उसे नष्ट कर दें। इन तरीकों को मिलाकर उपयोग करना सामान्य है। हमेशा चालू 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 करता है। यह overnight चलने वाली pipeline के लिए पर्याप्त है।

लगभग 27B तक के Quantized chat models, एक या दो users के लिए। ये धीमे हैं, लेकिन पढ़ने और उपयोग करने योग्य हैं।

वे सभी कार्य जिन्हें आप batch job कहेंगे। यदि कोई screen नहीं देख रहा है, तो wall-clock speed आवश्यकता के बजाय scheduling का विषय है।

GPU की वास्तविक आवश्यकता इन कार्यों के लिए होती है: छोटे adapter से आगे training या fine-tuning, कई concurrent users को serve करना, 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 के लिए अलग से क्षमता निर्धारित करें। यह weights से बड़ा हो सकता है।

क्या मैं GPU के बिना Ollama चला सकता हूँ?

हाँ। Ollama अपने-आप CPU पर चला जाता है। मॉडल रखने के लिए केवल पर्याप्त RAM चाहिए। 4-bit 8B मॉडल के लिए memory speed के आधार पर लगभग 5 से 12 tokens प्रति second की अपेक्षा करें। एक user के लिए यह पढ़ने की गति के करीब है। CPU पर लंबे prompts मुख्य समस्या होते हैं। 30,000 tokens का context पढ़ना compute-bound होता है और reply generate करने से काफी अधिक समय लेता है।

मेरा GPU CPU से मुश्किल से तेज क्यों है?

सामान्य कारण यह है कि मॉडल पूरी तरह VRAM में फिट नहीं हुआ। इसलिए कुछ layers CPU पर चलती हैं और हर token को धीमे हिस्से का इंतजार करना पड़ता है। ollama ps चलाएँ और जाँचें कि PROCESSOR column में 100% GPU लिखा है। यदि split दिखाई दे, तो छोटी quantization या छोटा मॉडल इस्तेमाल करें। दूसरा सामान्य कारण छोटा benchmark है। इसमें model load time measurement पर हावी होता है।

क्या single user के लिए GPU VPS लेना उचित है?

आमतौर पर नहीं। एक व्यक्ति 5 से 10 words प्रति second की गति से पढ़ता है। CPU box लगभग 13B तक के मॉडलों के लिए इससे तेज़ tokens generate कर देता है। Single user के लिए लागत को उचित ठहराने वाले मामले लंबे prompts, image generation और fine-tuning हैं। एक साथ कई users को सेवा देना सबसे मजबूत कारण है। Batching के कारण एक GPU, एक request का उत्तर देने की लागत के लगभग, twenty requests का उत्तर दे सकता है।

क्या मुझे GPU hourly किराए पर लेना चाहिए या उसे हमेशा चालू रखना चाहिए?

जब काम bursty हो, तब hourly किराए पर लें। इसके उदाहरण fine-tuning, bulk embedding run या batch transcription job हैं। हमेशा चालू तभी रखें जब card लगातार व्यस्त रहता हो। GPU instance tokens produce करने के बजाय चालू रहने के समय के लिए bill करता है। Low-traffic assistant के लिए CPU VPS या प्रति token भुगतान वाला hosted API, idle GPU की तुलना में सस्ता होता है।