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

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

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

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

GPU प्रत्यक्षात काय देते

Bandwidth. आधुनिक host वरील server DDR5 दर सेकंदाला दहा-दहा gigabytes डेटा हलवते. GPU memory (VRAM, video RAM) दर सेकंदाला शेकडो ते हजाराहून अधिक gigabytes डेटा हलवते. हे गुणोत्तरच speedup आहे आणि ते मोठे आहे.

Capacity with speed. 64 GB RAM असलेला CPU box 4 bits मध्ये 70B model लोड करू शकतो. तो चालेल; मात्र त्याचा वेग संवाद साधण्यापेक्षा वाचण्याच्या वेगासारखा असेल. येथे GPU तेव्हाच मदत करते जेव्हा model VRAM मध्ये पूर्णपणे मावतो. Layers system RAM मध्ये spill होताच slow path पुन्हा लागू होतो.

Batch throughput. हा भाग लोकांच्या अपेक्षेपेक्षा अधिक महत्त्वाचा आहे. एका user साठी generate करताना GPU ची बहुतांश compute capacity idle राहते, कारण तो memory ची वाट पाहत असतो. एकाच वेळी 20 requests serve केल्यास तोच weight read सर्व 20 requests साठी वापरला जातो. Aggregate tokens per second अनेक पटींनी वाढतात, तर प्रत्येक user चा वेग फारसा कमी होत नाही. CPU असे करू शकत नाही. CPU box वर दोन concurrent users एकमेकांचा वेग साधारणपणे निम्मा करतात. अनेक clients ज्या API ला call करतात ते तयार करत असाल, तर raw single-stream speed पेक्षा batching हा GPU वापरण्याचा अधिक महत्त्वाचा युक्तिवाद आहे.

Prompt processing. Long prompt वाचणे हे memory-bound नसून compute-bound असते आणि येथे GPU सर्वाधिक फरक दाखवते. CPU ला 1 minute लागणारा 30,000 token context GPU वर काही seconds मध्ये प्रक्रिया होतो. प्रत्येक request मध्ये documents भरून पाठवणाऱ्या retrieval setups मध्ये हा फरक सतत जाणवतो.

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

खालील तक्त्यात 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 मधील फरकापेक्षा memory bandwidth च्या गुणोत्तराशी अधिक जुळतो. प्रत्यक्ष throughput हा bandwidth ला model size ने भागल्यावर मिळणाऱ्या आकड्यापेक्षाही कमी असतो. याचे कारण वाढणाऱ्या context वर attention मुळे अतिरिक्त काम करावे लागते आणि साधी भागाकाराची गणना ते धरून चालत नाही.

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

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

Model file चा आकार ही किमान मर्यादा आहे; आवश्यक आकार नाही. Weights, तसेच KV cache (key-value cache, attention ज्या प्रत्येक token साठी ठेवते ती मेमरी), आणि सुमारे 1 GB overhead यांच्यासाठी जागा राखून ठेवा.

July 2026 पर्यंतचा व्यावहारिक नियम असा आहे: सामान्य 8k ते 16k context साठी model file चा आकार gigabytes मध्ये घ्या आणि त्यात 20 percent जोडा. 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 आवश्यक असतात. हीच गणना त्यापेक्षा मोठ्या models साठीही लागू होते. Kimi K3 सारख्या 2.8 trillion parameter model साठीचे VRAM गणित दाखवते की एका टप्प्यानंतर कोणता card निवडायचा हा प्रश्नच उरत नाही.

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

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

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

nvidia-smi

या output मध्ये GPU चे नाव, driver version आणि एकूण memory पैकी वापरलेली memory दाखवणारी table असावी. 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 ओळीत पूर्ण करता न येणारी GPU capability नमूद असल्यास toolkit install आहे, पण Docker चे reconfiguration किंवा restart झालेले नाही. त्यामुळे nvidia-ctk ओळ पुन्हा चालवा आणि restart करा. Compose मध्ये याच्यासाठी deploy.resources.reservations.devices entry वापरली जाते. तिचे driver हे nvidia असते आणि capabilities list मध्ये gpu असते. ही entry VPS वर Docker Compose मध्ये समाविष्ट केलेल्या सामान्य service definitions मध्ये जोडता येते.

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

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

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

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

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

ollama ps

सगळे model memory मध्ये बसल्यास PROCESSOR column मध्ये 100% GPU दिसते. Model पूर्णपणे बसला नाही, तर 43%/57% CPU/GPU सारखे काहीतरी दिसते. Model चा काही भागच 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 किंवा मोठ्या प्रमाणातील embedding run साठी GPU तासानुसार भाड्याने घ्या आणि काम पूर्ण झाल्यावर तो नष्ट करा. या पद्धती एकत्र वापरणे सामान्य आहे. नेहमी सुरू असलेल्या VPS वरील AI agent खर्च नियंत्रण मध्ये वर्णन केलेली budget व्यवस्थापन शिस्त येथेही लागू होते. मात्र येथे गळतीचे कारण 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. ते धीमे असतात, पण वाचण्यास सोपे आणि वापरण्यायोग्य असतात.

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

GPU ची खरोखर गरज कुठे असते: लहान 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 कार्डमध्ये मोठ्या context साठी पुरेशी अतिरिक्त जागा राहते. 128k context वापरणार असल्यास cache साठी स्वतंत्रपणे क्षमता ठरवा, कारण तो weights पेक्षा मोठा होऊ शकतो.

GPU शिवाय Ollama चालवता येते का?

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

माझा GPU CPU पेक्षा किंचितच वेगवान का आहे?

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

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

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

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

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