GPU असलेला VPS कधी आवश्यक असतो?

तुम्हाला GPU असलेला VPS आवश्यक आहे का, की CPU पुरेसा आहे?

GPU असलेला VPS स्वतः मॉडेल चालवताना दोन गोष्टी बदलतो: tokens किती वेगाने निर्माण होतात आणि मॉडेल मेमरीमध्ये मावते की नाही. याशिवाय तो दुसरे काहीही बदलत नाही. तुमच्या कामात 7B ते 27B quantized chat model एकावेळी एका व्यक्तीला उत्तर देत असेल, कमी प्रमाणात embedding job चालत असेल किंवा Whisper small वापरून speech transcription होत असेल, तर पुरेशी RAM असलेला सामान्य CPU VPS हे काम आधीच करू शकतो. CPU वर सुरुवात करा, त्रासदायक वाटणारे मोजमाप नोंदवा आणि त्यानंतर मोठ्या क्षमतेच्या पर्यायाकडे जा.

याचे कारण memory bandwidth आहे. भाषा मॉडेल एक token निर्माण करते तेव्हा त्याला आवश्यक असलेले सर्व weights ते मेमरीमधून वाचते. 4 bits वर quantized केलेले 8B मॉडेल disk वर साधारण 4.7 GB असते आणि मेमरीमध्येही जवळपास तेवढीच जागा घेते. त्यामुळे एक token निर्माण करण्यासाठी सुमारे 4.7 GB डेटा हलवावा लागतो. मशीनच्या memory bandwidth ला त्या संख्येने भागा. मिळणारे मूल्य tokens per second ची कमाल मर्यादा असते. तुम्ही वाचत असलेल्या जवळपास प्रत्येक benchmark चे स्पष्टीकरण या एकाच भागाकारातून मिळते.

GPU मुळे प्रत्यक्षात काय मिळते

बँडविड्थ. आधुनिक होस्टवरील सर्व्हर DDR5 दर सेकंदाला दहा-दहा गिगाबाइट डेटा हलवते. GPU मेमरी (VRAM, video RAM) शेकडो ते एक हजारपेक्षा अधिक गिगाबाइट डेटा हलवते. या दोन्हीमधील गुणोत्तर म्हणजे गतीवाढ, आणि ती मोठी असते.

वेगासह क्षमता. 64 GB RAM असलेला CPU सर्व्हर 4 bits मध्ये 70B मॉडेल लोड करू शकतो. ते चालेल, पण गप्पा मारण्यापेक्षा वाचण्याच्या वेगाजवळ. या परिस्थितीत GPU तेव्हाच मदत करते जेव्हा मॉडेल VRAM मध्ये बसते. लेअर्स system RAM मध्ये गेल्याच्या क्षणी धीमा मार्ग पुन्हा सक्रिय होतो.

बॅच थ्रूपुट. या भागाचा लोक कमी अंदाज लावतात. GPU एका वापरकर्त्यासाठी मजकूर तयार करताना त्याची बहुतांश संगणन क्षमता निष्क्रिय राहते, कारण तो मेमरीची वाट पाहत असतो. एकाच वेळी 20 विनंत्या हाताळल्यास, तेच weight read सर्व 20 विनंत्यांसाठी वापरले जाते. प्रत्येक सेकंदाला तयार होणाऱ्या एकूण tokens ची संख्या अनेक पटींनी वाढते, तर प्रत्येक वापरकर्त्याचा वेग फारसा कमी होत नाही. CPU असे करत नाही. CPU सर्व्हरवर दोन समांतर वापरकर्ते एकमेकांचा वेग साधारणपणे निम्मा करतात. अनेक क्लायंट ज्या API ला कॉल करतात ते तयार करत असल्यास, एकाच प्रवाहाच्या कच्च्या वेगापेक्षा बॅचिंग हा GPU वापरण्याचा अधिक महत्त्वाचा युक्तिवाद आहे.

प्रॉम्प्ट प्रक्रिया. मोठा प्रॉम्प्ट वाचणे हे memory-bound नसून compute-bound असते, आणि याच ठिकाणी GPU सर्वाधिक फरक निर्माण करते. CPU ला एका मिनिटात प्रक्रिया करता येणारा 30,000 tokens चा संदर्भ GPU वर काही सेकंदांत प्रक्रिया होतो. प्रत्येक विनंतीमध्ये documents समाविष्ट करणाऱ्या retrieval सेटअपमध्ये हा फरक सतत जाणवतो.

अंदाजे आकडे आणि ते कसे वाचावेत

खालील तक्त्यात 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 साठी अतिरिक्त processing आवश्यक असते. साधी भागाकाराची गणना हे काम विचारात घेत नाही.

तुलनेसाठी, एखादी व्यक्ती साधारण 5 ते 10 शब्द प्रति सेकंद या वेगाने वाचते. एका वाचकासाठी 15 tokens per second किंवा त्याहून अधिक वेग सामान्य typing सारखा वाटतो. म्हणूनच केवळ CPU वापरणाऱ्या अनेक setup पुरेसे चांगले ठरतात.

खरेदीपूर्वी VRAM चे आकारमान ठरवा

मॉडेल फाइलचा आकार ही किमान मर्यादा आहे; तो आवश्यक आकार नाही. वेट्स, तसेच KV cache (key-value cache; attention ठेवत असलेली प्रत्येक token साठीची मेमरी), आणि सुमारे 1 GB अतिरिक्त भार यांचा अंदाज घ्या.

जुलै 2026 पर्यंतचा व्यावहारिक नियम: मॉडेल फाइलचा आकार gigabytes मध्ये घ्या आणि सामान्य 8k ते 16k context साठी त्यात 20 टक्के वाढवा. 4.7 GB क्षमतेच्या 8B मॉडेलला सुमारे 6 GB VRAM आवश्यक असते. 4 bits मधील 27B मॉडेलचा आकार सुमारे 16 GB असतो आणि त्याला अंदाजे 20 GB आवश्यक असतात. 4 bits मधील 70B मॉडेलचा आकार सुमारे 40 GB असतो आणि त्यासाठी 48 GB card किंवा दोन लहान cards आवश्यक असतात.

मोठे contexts हा नियम लागू होऊ देत नाहीत. context length वाढल्यावर KV cache रेषीय पद्धतीने वाढतो आणि 128k tokens वर तो वेट्सपेक्षाही मोठा होऊ शकतो. मोठे contexts वापरण्याची योजना असल्यास, आधी cache साठी आकारमान ठरवा आणि तुमचे engine cache quantization साठी कोणते पर्याय देते ते तपासा.

प्रत्यक्षात मशीनवर काय उपलब्ध आहे ते तपासा

GPU instance वर इतर कोणतीही कृती करण्यापूर्वी driver ला card दिसत आहे याची खात्री करा.

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 झाला नाही. Stock Ubuntu image मध्ये सामान्यतः sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install हा उपाय असतो. त्यानंतर reboot करा, जेणेकरून नवीन module load होईल.

Containers साठी केवळ driver पुरेसा नाही. Device उपलब्ध करून देण्यासाठी 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

तोच तक्ता दिसला पाहिजे. पूर्ण करता न येणाऱ्या GPU capability चे नाव असलेली docker: Error response from daemon: could not select device driver line दिसत असल्यास toolkit install आहे, पण Docker चे configuration पुन्हा केलेले नाही किंवा Docker restart केलेले नाही. त्यामुळे nvidia-ctk line आणि restart पुन्हा चालवा. Compose मध्ये यासाठी deploy.resources.reservations.devices entry वापरली जाते. तिचे driver हे nvidia असते आणि capabilities list मध्ये gpu असते. ही entry VPS वरील Docker Compose मध्ये वर्णन केलेल्या सामान्य service definitions मध्ये जोडता येते.

अपग्रेड करण्यापूर्वी मोजमाप करा

तुम्ही प्रत्यक्ष वापरणार असलेले मॉडेल, तुमच्याकडे आधीपासून असलेल्या CPU मशीनवर चालवा आणि आकडे नोंदवा. VPS वर LLM साठी Ollama self-hosting वापरताना यासाठी एकच flag आवश्यक आहे:

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

आउटपुटच्या शेवटी वेळेची मोजमापे असतात. eval rate म्हणजे tokens प्रति सेकंदातील तुमचा generation speed. prompt eval rate म्हणजे मशीनने तुमचे input किती वेगाने वाचले. कोणते upgrade उपयुक्त ठरेल हे या दोन आकड्यांवरून ठरते: कमी eval rate म्हणजे memory-bandwidth समस्या, तर मोठ्या input वर कमी prompt eval rate म्हणजे compute समस्या.

GPU असलेल्या मशीनवर मॉडेल प्रत्यक्षात GPU वर लोड झाले आहे का ते तपासा:

ollama ps

सर्व काही GPU memory मध्ये मावल्यास PROCESSOR column मध्ये 100% GPU दिसते. मॉडेल पूर्णपणे मावले नाही तर 43%/57% CPU/GPU सारखे काहीतरी दिसते. मॉडेलचा काही भाग GPU वर आणि उर्वरित भाग CPU वर असणे तुमच्या अपेक्षेपेक्षा सहसा धीमे असते, कारण प्रत्येक token ला अजूनही धीम्या भागाची प्रतीक्षा करावी लागते.

खर्चाचा प्रश्न

GPU instances ची किंमत तुलनात्मक CPU instance पेक्षा अनेक पटींनी जास्त असते. ते तयार असलेल्या प्रत्येक तासासाठी शुल्क आकारतात; त्यांनी तयार केलेल्या tokens साठी नाही. दररोज मोजक्याच requests हाताळणारा सतत सुरू असलेला GPU हा inference चालवण्याचा सर्वाधिक खर्चिक मार्ग आहे. समतोलबिंदूचा मुख्य घटक म्हणजे utilisation: व्यस्त GPU वर प्रत्येक token चा खर्च कमी असतो, तर निष्क्रिय GPU म्हणजे निव्वळ अपव्यय.

तीन व्यवहार्य पद्धती आहेत. नियमितपणे कमी प्रमाणात होणारे काम CPU VPS वर ठेवा. क्वचित येणाऱ्या कठीण request साठी hosted API वापरा आणि प्रत्येक token नुसार शुल्क द्या. Batch jobs, fine-tuning किंवा मोठ्या प्रमाणातील embedding run साठी GPU तासाच्या दराने भाड्याने घ्या आणि काम पूर्ण झाल्यावर तो नष्ट करा. या पद्धती एकत्र वापरणे सामान्य आहे. सतत सुरू असलेल्या VPS वरील AI agent च्या खर्चाचे नियंत्रण यामध्ये वर्णन केलेली अर्थसंकल्पीय शिस्त येथेही लागू होते. फरक एवढाच आहे की येथे token count ऐवजी निष्क्रिय वेळ हा खर्चाची गळती ठरतो.

GPU शिवाय अजूनही सुरळीत चालणाऱ्या गोष्टी

कमी प्रमाणातील embeddings. एक लहान embedding model काही CPU cores वर दर मिनिटाला शेकडो लघु documents प्रक्रिया करू शकतो. एकदा तयार केलेला index जलद असणे आवश्यक नसते.

Transcription साठी Whisper small आणि base. CPU वर Faster-whisper, small model वापरल्यास, जवळपास real time मध्ये transcription करतो. रात्रभर चालणाऱ्या pipeline साठी हे पुरेसे आहे.

एक किंवा दोन users साठी सुमारे 27B पर्यंतचे quantized chat models. प्रक्रिया धीमी असते, पण output वाचनीय आणि वापरण्यायोग्य असतो.

ज्या कामाला तुम्ही batch job म्हणाल. स्क्रीनकडे कोणी पाहत नसल्यास, wall-clock speed ही आवश्यकतेपेक्षा scheduling detail असते.

GPU ची खरोखर गरज कुठे असते: small adapter पेक्षा मोठे training किंवा fine-tuning, अनेक concurrent users साठी serving, image आणि video generation, तसेच latency हेच product असलेल्या real-time speech साठी.

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 वर fallback करते. मॉडेल साठवण्यासाठी पुरेशी RAM असणे आवश्यक आहे. Memory speed नुसार 4-bit 8B मॉडेलसाठी सुमारे 5 ते 12 tokens प्रति सेकंद अपेक्षित आहेत. एका वापरकर्त्यासाठी हा वेग वाचनाच्या गतीजवळचा असतो. CPU वर लांब prompts ही मुख्य अडचण असते, कारण 30,000 tokens चा context वाचणे compute-bound असते आणि उत्तर तयार करण्यापेक्षा त्याला बराच अधिक वेळ लागतो.

माझा GPU CPU पेक्षा फारच थोडा वेगवान का आहे?

सामान्य कारण म्हणजे मॉडेल पूर्णपणे VRAM मध्ये बसलेले नसते. त्यामुळे काही layers CPU वर चालतात आणि प्रत्येक token ला धीम्या भागाची प्रतीक्षा करावी लागते. ollama ps चालवा आणि PROCESSOR column मध्ये 100% GPU असे दिसते का ते तपासा. Split दिसत असल्यास smaller quantization किंवा smaller model वापरा. दुसरे सामान्य कारण म्हणजे कमी कालावधीचा benchmark. अशा वेळी मोजमापावर model load time चा प्रभाव अधिक असतो.

एका वापरकर्त्यासाठी GPU VPS घेणे फायदेशीर आहे का?

सामान्यतः नाही. एक व्यक्ती प्रति सेकंद 5 ते 10 शब्द वाचते. सुमारे 13B पर्यंतच्या मॉडेलसाठी CPU box आधीच त्यापेक्षा अधिक वेगाने tokens तयार करते. एका वापरकर्त्यासाठी खर्च योग्य ठरणाऱ्या परिस्थितींमध्ये long prompts, image generation आणि fine-tuning यांचा समावेश होतो. एकाच वेळी अनेक वापरकर्त्यांना सेवा देणे हा सर्वात मजबूत कारण आहे, कारण batching मुळे एक GPU एका request चे उत्तर देण्याच्या खर्चाजवळपास वीस requests ची उत्तरे देऊ शकतो.

GPU तासाच्या हिशोबाने rent करावा की तो कायम चालू ठेवावा?

काम bursty असल्यास hourly rent करा. उदाहरणार्थ, fine-tuning, bulk embedding run किंवा batch transcription job. Card सतत व्यस्त राहत असल्यासच तो कायम चालू ठेवा, कारण GPU instance तयार असलेल्या कालावधीसाठी billing करते, तयार केलेल्या tokens साठी नाही. कमी traffic असलेला assistant idle GPU पेक्षा CPU VPS वर किंवा प्रति token शुल्क असलेल्या hosted API वर स्वस्त पडतो.