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

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

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

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

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

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

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

Batch throughput. यह वह हिस्सा है जिसे लोग कम आंकते हैं। एक उपयोगकर्ता के लिए जनरेट करने वाला GPU अपनी अधिकांश compute क्षमता को खाली छोड़ देता है, क्योंकि वह मेमोरी का इंतजार कर रहा होता है। एक साथ 20 requests सर्व करें और वही weight read सभी 20 के काम आता है। प्रति सेकंड कुल tokens की संख्या कई गुना बढ़ जाती है जबकि प्रति-उपयोगकर्ता गति में बहुत कम गिरावट आती है। llama.cpp जैसे CPU inference engines भी batching का समर्थन करते हैं, जिसमें लाभ हार्डवेयर और workload पर निर्भर करता है। यदि आप एक ऐसा API बना रहे हैं जिसे कई clients कॉल करते हैं, तो batching ही GPU के लिए सबसे बड़ा तर्क है, न कि केवल raw single-stream गति।

Prompt processing. एक लंबे prompt को पढ़ना compute-bound होता है, न कि memory-bound, और यहीं पर GPU सबसे बड़े अंतर से जीतते हैं। 30,000 tokens का context जिसे CPU एक मिनट में प्रोसेस करता है, GPU पर वह कुछ ही सेकंड में हो जाता है। Retrieval setups जो हर request में documents भरते हैं, वे इसे लगातार महसूस करते हैं।

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

वास्तविक throughput, बैंडविड्थ को मॉडल साइज से विभाजित करने पर प्राप्त परिणाम से भी कम होता है। इसका कारण यह है कि जैसे-जैसे context बढ़ता है, attention मैकेनिज्म का कार्यभार भी बढ़ जाता है, जिसे यह साधारण विभाजन नजरअंदाज कर देता है।

तुलना के लिए, अंग्रेजी में सामान्य मौन पठन की गति औसतन 4.0 से 4.3 शब्द प्रति सेकंड होती है: गैर-काल्पनिक (non-fiction) के लिए 238 शब्द प्रति मिनट और काल्पनिक (fiction) के लिए 260 शब्द प्रति मिनट। 15 tokens प्रति सेकंड या उससे अधिक की गति किसी भी एकल पाठक के लिए सामान्य टाइपिंग जैसी महसूस होती है। यही कारण है कि बहुत सारे CPU-only सेटअप बिना किसी समस्या के सुचारू रूप से चलते हैं।

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

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

एक निश्चित प्रतिशत जोड़ने के बजाय cache की गणना करें, क्योंकि weights को quantize करने से cache quantize नहीं होता है। प्रत्येक टोकन के लिए, एक full-attention मॉडल हर layer और हर KV head के लिए एक key और value स्टोर करता है। यह FP16 में प्रति संख्या 2 bytes लेता है, जो Ollama का डिफ़ॉल्ट cache प्रकार है। 2026-10-27 को जाँची गई Ollama की मॉडल मेटाडेटा के अनुसार, Llama 3.1 8B में 32 layers और 128 dimensions के 8 KV heads हैं। यह प्रति टोकन 128 KiB के बराबर है: 8k context पर लगभग 1.07 GB और 16k पर 2.15 GB। इसलिए, 4.9 GB के 8B मॉडल को 8k पर लगभग 7 GB VRAM और 16k पर लगभग 8 GB VRAM चाहिए। 4 bits पर 27B मॉडल लगभग 17 GB का होता है (Ollama लाइब्रेरी में Gemma 3 27B)। Gemma 3 के मेटाडेटा में 1,024-टोकन की sliding window दी गई है, जो इसके cache को बढ़ने से रोकती है, इसलिए 20 GB या उससे अधिक की योजना बनाएँ। 4 bits पर 70B मॉडल लगभग 43 GB का होता है (Llama 3.3 70B)। 80 layers के साथ, इसका FP16 cache 8k पर लगभग 2.7 GB और 16k पर 5.4 GB जुड़ जाता है, इसलिए इसे 48 GB के कार्ड की आवश्यकता होती है जिसमें बहुत कम जगह बचती है, या फिर दो छोटे कार्डों की। यही गणित इसके आगे भी काम करता है, और Kimi K3 जैसे 2.8 ट्रिलियन पैरामीटर मॉडल के लिए VRAM गणित दिखाता है कि कहाँ कार्ड चुनना ही मुख्य समस्या नहीं रह जाती।

लंबे contexts के लिए यह सबसे अधिक मायने रखता है। Llama 3.1 जैसे full-attention मॉडलों पर, KV cache context की लंबाई के साथ रैखिक रूप से बढ़ता है, और 128k टोकन पर यह weights से भी अधिक हो सकता है। sliding-window या chunked attention वाले मॉडल अलग होते हैं: Hugging Face की Transformers documentation में Mistral, Gemma 2 और Llama 4 को ऐसे उदाहरणों के रूप में बताया गया है जहाँ उन layers पर cache का आकार window या chunk size तक पहुँचने के बाद बढ़ना बंद हो जाता है, इसलिए उनका कुल आकार धीरे बढ़ता है। यदि आप लंबे contexts का उपयोग करने की योजना बना रहे हैं, तो पहले cache के लिए आकार निर्धारित करें और देखें कि आपका इंजन cache quantization के लिए क्या विकल्प देता है। Ollama में, OLLAMA_KV_CACHE_TYPE=q8_0 डिफ़ॉल्ट f16 की तुलना में लगभग आधी मेमोरी का उपयोग करता है, और cache quantization केवल तभी लागू होता है जब Flash Attention सक्षम हो। context की लंबाई को भी स्पष्ट रूप से सेट करें। Ollama VRAM के आधार पर अपना डिफ़ॉल्ट चुनता है: 24 GiB से कम पर 4k, 24 से 48 GiB के बीच 32k, और 48 GiB या उससे अधिक पर 256k। 70B मॉडल चलाने वाले 48 GB कार्ड पर, वह डिफ़ॉल्ट कार्ड की क्षमता से कहीं अधिक cache की मांग करता है।

मशीन पर उपलब्ध हार्डवेयर की जाँच करें

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

nvidia-smi

आपको एक ऐसी तालिका चाहिए जिसमें 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 है। एक standard Ubuntu image पर इसका समाधान आमतौर पर sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install है, जिसके बाद module को load करने के लिए reboot करना होता है। Compute machines के लिए, Ubuntu का server documentation sudo ubuntu-drivers install --gpgpu की अनुशंसा करता है, जो server driver branch को चुनता है।

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

वही तालिका दिखाई देनी चाहिए। एक docker: Error response from daemon: could not select device driver लाइन, जो किसी ऐसी gpu capability का नाम लेती है जिसे वह पूरा नहीं कर सकता, का अर्थ है कि Docker अनुरोध से मेल खाने वाला device driver नहीं ढूँढ सका; जाँचें कि toolkit installed है, फिर nvidia-ctk लाइन को पुनः चलाएँ और restart करें। Compose में इसका समकक्ष एक deploy.resources.reservations.devices entry है जिसका driver, nvidia है और जिसकी capabilities सूची में gpu शामिल है, जो Docker Compose on a VPS में वर्णित सामान्य service definitions में फिट बैठता है।

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

जिस मॉडल का आप वास्तव में उपयोग करना चाहते हैं, उसे अपने मौजूदा CPU बॉक्स पर चलाएं और आंकड़े रिकॉर्ड करें। Ollama self-hosting an LLM on a VPS के साथ इसके लिए केवल एक फ्लैग की आवश्यकता होती है:

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

आउटपुट का अंत टाइमिंग के साथ होता है। eval rate आपकी जनरेशन स्पीड है, जिसे tokens per second में मापा जाता है। prompt eval rate यह दर्शाता है कि मशीन ने आपके इनपुट को कितनी तेजी से पढ़ा। ये दो संख्याएं बताती हैं कि कौन सा अपग्रेड मददगार होगा: कम eval rate मेमोरी-बैंडविड्थ की समस्या है, और लंबे इनपुट पर कम prompt eval rate एक कंप्यूट (compute) समस्या है।

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

ollama ps

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

लागत संबंधी प्रश्न

GPU instances के लिए बिलिंग टोकन के बजाय provisioned compute time के आधार पर होती है, जिसकी दरें और stopped-instance शुल्क provider द्वारा निर्धारित किए जाते हैं। एक always-on GPU जो दिन में केवल कुछ ही requests process करता है, वह अपना अधिकांश भुगतान किया गया समय idle रहकर बिताता है। यहाँ break-even point उपयोग (utilisation) पर निर्भर करता है: एक व्यस्त GPU प्रति टोकन सस्ता पड़ता है, जबकि एक idle GPU पूरी तरह से बर्बादी है।

तीन ईमानदार तरीके प्रभावी हैं। कम-वॉल्यूम वाले स्थिर काम को CPU VPS पर रखें। कभी-कभार आने वाली कठिन requests को hosted API पर भेजें और प्रति टोकन भुगतान करें। batch jobs, fine-tuning, या bulk embedding run के लिए GPU को प्रति घंटे के हिसाब से किराए पर लें और काम पूरा होने पर उसे destroy कर दें। इनका मिश्रण सामान्य है, और always-on VPS पर AI agent लागत नियंत्रण में वर्णित बजट अनुशासन यहाँ भी लागू होता है, बस अंतर यह है कि यहाँ टोकन संख्या के बजाय idle time ही मुख्य नुकसान (leak) है।

बिना 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 ही उत्पाद है।

FAQ

7B या 8B मॉडल के लिए मुझे कितनी VRAM चाहिए?

Ollama के डिफ़ॉल्ट FP16 कैश के साथ, 8k कॉन्टेक्स्ट पर 4-bit क्वांटाइज़्ड 8B मॉडल के लिए लगभग 7 GB और 16k पर लगभग 8 GB VRAM की आवश्यकता होती है। मॉडल वेट्स लगभग 4.9 GB के होते हैं, KV कैश 8k पर लगभग 1.07 GB या 16k पर 2.15 GB जोड़ता है, और बाकी लगभग 1 GB ओवरहेड होता है। 8 GB का कार्ड 8k पर इसे संभाल लेता है लेकिन 16k पर यह काफी सीमित हो जाता है, जबकि 12 GB का कार्ड लंबे कॉन्टेक्स्ट के लिए पर्याप्त जगह देता है। कैश को q8_0 पर स्विच करने से कैश का हिस्सा लगभग आधा हो जाता है। यदि आप 128k कॉन्टेक्स्ट पर चलाने की योजना बना रहे हैं, तो कैश के लिए अलग से जगह रखें, क्योंकि यह वेट्स से भी बड़ा हो सकता है।

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

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

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

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

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

आमतौर पर नहीं। अंग्रेजी में वयस्क मौन पठन की औसत गति लगभग 4.0 से 4.3 शब्द प्रति सेकंड होती है, और CPU बॉक्स की तुलना करने से पहले टोकन प्रति सेकंड को शब्द प्रति सेकंड में बदलना आवश्यक है। एक उपयोगकर्ता के लिए लागत को सही ठहराने वाले मामले लंबे प्रॉम्प्ट्स, इमेज जनरेशन और फाइन-ट्यूनिंग हैं। एक साथ कई उपयोगकर्ताओं को सेवा देना सबसे मजबूत तर्क है, क्योंकि बैचिंग एक GPU को अनुरोधों के बीच वेट्स रीड्स साझा करने की अनुमति देती है।

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

जब काम रुक-रुक कर हो, जैसे कि फाइन-ट्यूनिंग, बल्क एम्बेडिंग रन, या बैच ट्रांसक्रिप्शन जॉब, तो इसे प्रति घंटे किराए पर लें। इसे केवल तभी हमेशा चालू रखें जब कार्ड लगातार व्यस्त रहे, क्योंकि प्रोविजन्ड GPU कंप्यूट उत्पन्न टोकन के बजाय समय के लिए बिल करता है। कम ट्रैफ़िक वाले असिस्टेंट के लिए CPU VPS, या प्रति टोकन भुगतान वाली होस्टेड API, खाली पड़े GPU की तुलना में सस्ती पड़ती है।