क्या आपको GPU वाले VPS की आवश्यकता है या CPU पर्याप्त है?

क्या आपको GPU वाले VPS की आवश्यकता है, या CPU पर्याप्त है?

GPU वाला VPS खुद मॉडल चलाने के संबंध में दो चीजों को बदलता है: टोकन कितनी तेजी से उत्पन्न होते हैं, और मॉडल मेमोरी में कितनी अच्छी तरह फिट होता है। यह इसके अलावा कुछ भी नहीं बदलता है। यदि आपका वर्कलोड एक बार में एक व्यक्ति को उत्तर देने वाला क्वांटाइज्ड 7B से 27B चैट मॉडल है, कम वॉल्यूम पर एम्बेडिंग जॉब है, या Whisper small के साथ स्पीच ट्रांसक्रिप्शन है, तो पर्याप्त RAM वाला एक सामान्य CPU VPS पहले से ही यह काम कर देता है। CPU पर शुरुआत करें, उस संख्या को मापें जो आपको परेशान करती है, फिर अपग्रेड करें।

इसका कारण मेमोरी बैंडविड्थ है। जब एक लैंग्वेज मॉडल एक टोकन उत्पन्न करता है, तो वह मेमोरी से अपने लिए आवश्यक प्रत्येक वेट (weight) को पढ़ता है। 4 बिट्स पर क्वांटाइज्ड एक 8B मॉडल डिस्क पर लगभग 4.7 GB का होता है और मेमोरी में भी लगभग इतना ही होता है, इसलिए एक टोकन उत्पन्न करने का अर्थ है लगभग 4.7 GB डेटा को मूव करना। मशीन की मेमोरी बैंडविड्थ को उस संख्या से विभाजित करें और आपको प्रति सेकंड टोकन की अधिकतम सीमा मिल जाएगी। वह एकल विभाजन आपके द्वारा पढ़े जाने वाले लगभग हर बेंचमार्क की व्याख्या करता है।

GPU वास्तव में आपको क्या प्रदान करता है

Bandwidth (बैंडविड्थ)। एक आधुनिक होस्ट पर सर्वर DDR5 प्रति सेकंड दर्जनों गीगाबाइट डेटा ट्रांसफर करता है। GPU मेमोरी (VRAM, वीडियो RAM) सैकड़ों से लेकर एक हजार गीगाबाइट से अधिक तक डेटा ट्रांसफर करती है। यह अनुपात ही गति में वृद्धि है, और यह काफी अधिक है।

गति के साथ क्षमता। 64 GB RAM वाला एक CPU बॉक्स 4-बिट पर 70B मॉडल लोड कर सकता है। यह चलेगा जरूर, लेकिन इसकी गति चैटिंग के बजाय पढ़ने जैसी धीमी होगी। GPU यहाँ केवल तभी मदद करता है जब मॉडल VRAM में फिट हो जाए, क्योंकि जिस क्षण लेयर्स सिस्टम RAM में जाती हैं, धीमी गति वाला पाथ फिर से प्रभावी हो जाता है।

Batch throughput (बैच थ्रूपुट)। यह वह हिस्सा है जिसे लोग कम आंकते हैं। एक उपयोगकर्ता के लिए जनरेट करने वाला GPU अपनी अधिकांश कंप्यूटिंग क्षमता को खाली छोड़ देता है, क्योंकि वह मेमोरी का इंतजार कर रहा होता है। एक साथ 20 अनुरोधों (requests) को सर्व करें, तो वही वेट रीड (weight read) सभी 20 के लिए काम आता है। प्रति सेकंड कुल टोकन की संख्या कई गुना बढ़ जाती है जबकि प्रति-उपयोगकर्ता गति में बहुत मामूली गिरावट आती है। CPU ऐसा नहीं कर सकता। CPU बॉक्स पर दो समवर्ती उपयोगकर्ता एक-दूसरे की गति को लगभग आधा कर देते हैं। यदि आप एक ऐसा API बना रहे हैं जिसे कई क्लाइंट कॉल करते हैं, तो बैचिंग ही GPU का उपयोग करने का मुख्य कारण है, न कि केवल सिंगल-स्ट्रीम की गति।

Prompt processing (प्रॉम्प्ट प्रोसेसिंग)। एक लंबे प्रॉम्प्ट को पढ़ना मेमोरी-बाउंड नहीं, बल्कि कंप्यूट-बाउंड होता है, और यहीं पर GPU सबसे बड़ी बढ़त हासिल करते हैं। 30,000 टोकन का कॉन्टेक्स्ट, जिसे CPU प्रोसेस करने में एक मिनट लेता है, GPU पर कुछ ही सेकंड में पूरा हो जाता है। रिट्रीवल सेटअप जो हर अनुरोध में डॉक्यूमेंट्स भरते हैं, वे इसे लगातार महसूस करते हैं।

अनुमानित आंकड़े और उन्हें पढ़ने का तरीका

नीचे दिया गया ब्लॉक जुलाई 2026 तक, 4-bit quantization पर 8B मॉडल के लिए सामान्य रूप से प्रकाशित 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 प्रति सेकंड दिखाती है, जबकि DDR5 CPU बॉक्स के लिए यह 11 है। यह लगभग पांच गुना है, जो raw compute के अंतर के बजाय bandwidth अनुपात को दर्शाता है। वास्तविक throughput मॉडल के आकार से विभाजित bandwidth से भी कम होता है, क्योंकि बढ़ते context पर attention का काम बढ़ जाता है, जिसे साधारण विभाजन में नहीं गिना जाता है।

तुलना के लिए, एक व्यक्ति लगभग 5 से 10 शब्द प्रति सेकंड की गति से पढ़ता है। 15 tokens प्रति सेकंड या उससे अधिक की गति एक पाठक के लिए सामान्य टाइपिंग जैसी महसूस होती है। यही कारण है कि बहुत सारे CPU-only सेटअप बिना किसी समस्या के काम करते हैं।

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

मॉडल फाइल का आकार न्यूनतम आवश्यकता है, न कि कुल आवश्यकता। वजन (weights), KV cache (key-value cache, जो attention द्वारा प्रति-टोकन रखी जाने वाली मेमोरी है), और लगभग 1 GB ओवरहेड के लिए बजट रखें।

जुलाई 2026 के अनुसार एक व्यावहारिक नियम यह है: मॉडल फाइल के आकार (GB में) को लें और सामान्य 8k से 16k context के लिए उसमें 20 प्रतिशत जोड़ें। एक 4.7 GB वाले 8B मॉडल को लगभग 6 GB VRAM की आवश्यकता होती है। 4 bits पर एक 27B मॉडल लगभग 16 GB का होता है और उसे मोटे तौर पर 20 GB VRAM चाहिए। 4 bits पर एक 70B मॉडल लगभग 40 GB का होता है और इसके लिए 48 GB वाले कार्ड, या दो छोटे कार्ड की आवश्यकता होती है। यही गणित इससे आगे भी काम करता है, और Kimi K3 जैसे 2.8 ट्रिलियन पैरामीटर मॉडल के लिए VRAM गणित यह दर्शाता है कि कहाँ कार्ड चुनना ही मुख्य प्रश्न नहीं रह जाता।

लंबे context इस नियम को तोड़ देते हैं। KV cache का आकार context की लंबाई के साथ रैखिक रूप से बढ़ता है, और 128k टोकन पर यह स्वयं weights से भी अधिक हो सकता है। यदि आप लंबे context का उपयोग करने की योजना बना रहे हैं, तो पहले cache के लिए आकार निर्धारित करें और जाँचें कि आपका engine cache quantization के लिए क्या विकल्प प्रदान करता है।

मशीन में मौजूद हार्डवेयर की जाँच करें

GPU instance पर, सबसे पहले यह सुनिश्चित करें कि driver कार्ड को पहचान रहा है।

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 नहीं हुआ है। एक standard Ubuntu image पर इसे ठीक करने के लिए आमतौर पर sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install का उपयोग करें, और फिर reboot करें ताकि नया module load हो सके।

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

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

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

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

ollama ps

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

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

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

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

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

कोई भी चीज़ जिसे आप 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 VRAM की आवश्यकता होती है। मॉडल का वजन लगभग 4.7 GB होता है, और बाकी हिस्सा KV cache और लगभग 1 GB overhead के लिए होता है। 12 GB का कार्ड लंबे context के लिए पर्याप्त जगह देता है। यदि आप 128k context पर चलाने की योजना बना रहे हैं, तो cache के लिए अलग से आकार निर्धारित करें, क्योंकि यह मॉडल के वजन से भी बड़ा हो सकता है।

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

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

मेरा GPU, CPU से थोड़ा ही तेज़ क्यों है?

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

क्या एक एकल उपयोगकर्ता के लिए GPU VPS लेना उचित है?

आमतौर पर नहीं। एक व्यक्ति 5 से 10 शब्द प्रति सेकंड की गति से पढ़ता है, और एक CPU बॉक्स लगभग 13B तक के मॉडल के लिए उससे तेज़ tokens उत्पन्न कर देता है। जो स्थितियाँ एकल उपयोगकर्ता के लिए लागत को उचित ठहराती हैं, वे हैं: लंबे prompts, image generation, और fine-tuning। एक साथ कई उपयोगकर्ताओं को सेवा देना सबसे मजबूत तर्क है, क्योंकि batching एक GPU को एक अनुरोध का उत्तर देने की लागत के करीब बीस अनुरोधों का उत्तर देने की अनुमति देता है।

क्या मुझे GPU को प्रति घंटे किराए पर लेना चाहिए या हमेशा चालू रखना चाहिए?

जब काम रुक-रुक कर हो, तो प्रति घंटे किराए पर लें: जैसे fine-tuning, bulk embedding run, या batch transcription job। GPU को केवल तभी हमेशा चालू रखें जब कार्ड लगातार व्यस्त रहे, क्योंकि GPU instance के लिए बिल उसके अस्तित्व (existing) के आधार पर आता है, न कि उत्पन्न tokens के आधार पर। कम ट्रैफ़िक वाले assistant को CPU VPS पर, या प्रति token भुगतान वाले hosted API पर चलाना, खाली पड़े GPU की तुलना में सस्ता पड़ता है।