ద్వారా GPU ఉన్న VPS ఎప్పుడు అవసరం? CPU సరిపోతుందా?
GPU VPS batch పనులకు throughput, పెద్ద మోడళ్లకు memory ఇస్తుంది. Quantized chat models, embeddings, Whisper small CPUపై నడుస్తాయి. ముందుగా కొలిచి నిర్ణయించండి.
GPU ఉన్న VPS అవసరమా, లేక CPU సరిపోతుందా?
GPU ఉన్న VPSలో మోడల్ను స్వయంగా నడిపినప్పుడు ప్రధానంగా రెండు విషయాలు మారతాయి: tokens ఉత్పత్తి అయ్యే వేగం, అలాగే memoryలో అసలు సరిపోయే మోడల్ పరిమాణం. మిగతా విషయాల్లో ఎలాంటి మార్పు ఉండదు. మీ 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కు quantize చేసిన 8B model diskలో సుమారు 4.7 GB ఉంటుంది. memoryలో కూడా దాదాపు అంతే పరిమాణం ఉంటుంది. అందువల్ల ఒక tokenను రూపొందించడానికి సుమారు 4.7 GB dataని తరలించాలి. యంత్రం యొక్క memory bandwidthను ఆ పరిమాణంతో భాగిస్తే, సెకనుకు tokens సంఖ్యకు గరిష్ఠ పరిమితి లభిస్తుంది. మీరు చదివే దాదాపు ప్రతి benchmarkను ఈ ఒక్క భాగాకారంతోనే వివరించవచ్చు.
GPU ద్వారా వాస్తవంగా లభించేది
బ్యాండ్విడ్త్. ఆధునిక hostలోని Server DDR5 ప్రతి సెకనుకు దశల కొద్దీ gigabytes డేటాను తరలిస్తుంది. GPU memory (VRAM, video RAM) ప్రతి సెకనుకు వందల నుంచి వెయ్యికి పైగా gigabytes డేటాను తరలిస్తుంది. ఈ నిష్పత్తే speedup; ఇది చాలా పెద్దది.
వేగంతో కూడిన సామర్థ్యం. 64 GB RAM ఉన్న CPU boxలో 4 bits వద్ద 70B modelను load చేయవచ్చు. అయితే దాని వేగం chat చేయడంకన్నా చదవడంలా ఉంటుంది. ఈ సందర్భంలో model మొత్తం VRAMలో సరిపోతేనే GPU సహాయపడుతుంది. ఎందుకంటే layers system RAMకు వెళ్లిన వెంటనే slow path మళ్లీ ప్రధానంగా మారుతుంది.
Batch throughput. చాలామంది తక్కువగా అంచనా వేసేది ఇదే. ఒక user కోసం GPU generate చేస్తున్నప్పుడు దాని computeలో ఎక్కువ భాగం idleగా ఉంటుంది, ఎందుకంటే అది memory కోసం వేచి ఉంటుంది. ఒకేసారి 20 requestsను serve చేస్తే అదే weight read మొత్తం 20 requestsకు ఉపయోగపడుతుంది. ఒక్కో user వేగం చాలా తక్కువగా మాత్రమే తగ్గుతుండగా, మొత్తం tokens per second అనేక రెట్లు పెరుగుతుంది. CPU ఇలా చేయదు. CPU boxలో ఒకేసారి పనిచేసే ఇద్దరు users సాధారణంగా ఒకరి వేగాన్ని మరొకరు సగానికి తగ్గిస్తారు. అనేక clients call చేసే APIను నిర్మిస్తున్నప్పుడు raw single-stream speedకన్నా batching అనేది GPUకు బలమైన కారణం.
Prompt processing. పొడవైన promptను చదవడం memory-bound కాదు; ఇది compute-bound. ఈ విషయంలోనే GPUs అత్యధిక ప్రయోజనం ఇస్తాయి. CPU ఒక నిమిషంలో process చేసే 30,000 token contextను GPU కొన్ని secondsలో process చేయగలదు. ప్రతి requestలో documentsను చేర్చే retrieval setupsలో ఈ తేడా నిరంతరం కనిపిస్తుంది.
సుమారు గణాంకాలు మరియు వాటిని ఎలా అర్థం చేసుకోవాలి
క్రింద ఉన్న బ్లాక్ July 2026 నాటికి 4-bit quantizationతో ఉన్న 8B model కోసం సాధారణంగా ప్రచురించిన single-stream గణాంకాలను చూపిస్తుంది. ఇవి order-of-magnitude మార్గదర్శకం మాత్రమే; హామీ కాదు. మీ quantization, context length మరియు inference engine ఆధారంగా ఈ విలువలు మారుతాయి.
The data behind this chart
[
{
"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 ratio కు అనుగుణంగా ఉంటుంది. వాస్తవ throughput కూడా bandwidth ను model size తో భాగించిన విలువ కంటే తక్కువగా ఉంటుంది. కారణం, context పెరుగుతున్న కొద్దీ attention కు అదనపు పని అవసరం అవుతుంది; సరళమైన భాగాకారం దాన్ని పరిగణనలోకి తీసుకోదు.
పోలిక కోసం, ఒక వ్యక్తి సెకనుకు సుమారుగా 5 నుంచి 10 పదాలు చదువుతాడు. సెకనుకు 15 tokens లేదా అంతకంటే ఎక్కువ ఉంటే, ఒకే reader కు అది సాధారణ typing వేగంలా అనిపిస్తుంది. అందుకే CPU-only setups చాలా సందర్భాల్లో ఎటువంటి సమస్య లేకుండా సరిపోతాయి.
మీరు కొనుగోలు చేయడానికి ముందు VRAM పరిమాణాన్ని నిర్ణయించడం
Model file పరిమాణం కనీస అవసరం మాత్రమే; అదే మొత్తం అవసరం కాదు. Weights, అలాగే KV cache (key-value cache; attention ప్రతి token కోసం నిల్వ చేసే memory), మరియు సుమారు 1 GB overhead కోసం కూడా VRAM కేటాయించండి.
July 2026 నాటికి ఒక ప్రాయోగిక నియమం: model file పరిమాణాన్ని gigabytes లో తీసుకుని, సాధారణ 8k నుంచి 16k context కోసం దానికి 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 ఎంపికే ఇక అసలు ప్రశ్న కాని స్థాయిని చూపిస్తుంది.
Long contexts ఈ నియమాన్ని మార్చేస్తాయి. Context length పెరిగే కొద్దీ KV cache కూడా linear గా పెరుగుతుంది. 128k tokens వద్ద ఇది weights కంటే కూడా పెద్దదిగా మారవచ్చు. మీరు long contexts ఉపయోగించాలనుకుంటే ముందుగా cache కోసం అవసరమైన పరిమాణాన్ని నిర్ణయించండి. మీ engine cache quantization కోసం ఏ ఎంపికలను అందిస్తుందో కూడా పరిశీలించండి.
సిస్టమ్లో వాస్తవంగా ఉన్నవి ఏమిటో పరిశీలించండి
GPU instanceలో మరే పని చేయకముందు driver ఆ cardను గుర్తిస్తుందో నిర్ధారించండి.
nvidia-smiGPU పేరు, driver version, అలాగే మొత్తం memoryలో ప్రస్తుతం ఎంత ఉపయోగించబడుతోందో చూపించే పట్టిక కనిపించాలి. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver కనిపిస్తే driver లేదు లేదా kernel upgrade తర్వాత kernel module మళ్లీ build కాలేదు అని అర్థం. సాధారణ 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అదే పట్టిక మళ్లీ కనిపించాలి. అది తీర్చలేని GPU capability పేరుతో కూడిన docker: Error response from daemon: could not select device driver line కనిపిస్తే, toolkit install అయింది కానీ Dockerను reconfigure చేయలేదు లేదా restart చేయలేదు అని అర్థం. అందువల్ల nvidia-ctk lineను మళ్లీ అమలు చేసి, restart చేయండి. Composeలో దీనికి సమానమైనది deploy.resources.reservations.devices entry. అందులోని driver విలువ nvidia అయి ఉండాలి మరియు capabilities listలో gpu ఉండాలి. ఇది VPSపై Docker Composeలో వివరించిన సాధారణ service definitionsలో నేరుగా ఉపయోగించవచ్చు.
అప్గ్రేడ్కు ముందు కొలవండి
మీరు వాస్తవంగా ఉపయోగించాలనుకుంటున్న model ను, ఇప్పటికే ఉన్న CPU machine పై run చేసి, ఫలితాలను నమోదు చేయండి. VPSలో Ollamaతో LLMను self-host చేయడం కోసం దీనికి ఒక flag చాలు:
ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."Output చివరలో timing వివరాలు ఉంటాయి. eval rate మీ generation speed ను tokens per second లో చూపిస్తుంది. మీ input ను machine ఎంత వేగంగా చదివిందో prompt eval rate చూపిస్తుంది. ఏ upgrade ఉపయోగకరంగా ఉంటుందో ఈ రెండు సంఖ్యలు తెలియజేస్తాయి: eval rate తక్కువగా ఉంటే అది memory-bandwidth సమస్య. Long inputs సమయంలో prompt eval rate తక్కువగా ఉంటే అది compute సమస్య.
GPU ఉన్న machine పై model నిజంగా GPUలో load అయిందో తనిఖీ చేయండి:
ollama psఅన్నీ సరిపోతే PROCESSOR column లో 100% GPU కనిపిస్తుంది. సరిపోకపోతే 43%/57% CPU/GPU వంటి విలువ కనిపిస్తుంది. Partial split సాధారణంగా మీరు ఊహించినదానికంటే నెమ్మదిగా ఉంటుంది, ఎందుకంటే ప్రతి token slow half కోసం వేచి ఉండాల్సి వస్తుంది.
ఖర్చు ప్రశ్న
GPU instances, సమాన సామర్థ్యం ఉన్న CPU instance కంటే పలుమార్లు ఎక్కువ ఖర్చవుతాయి. అవి ఉత్పత్తి చేసే tokens ఆధారంగా కాకుండా, అవి అమలులో ఉన్న ప్రతి గంటకు billing చేస్తాయి. రోజుకు కొద్దిపాటి requests మాత్రమే అందించే ఎప్పుడూ ఆన్లో ఉండే GPUతో inference నడపడం అత్యంత ఖరీదైన పద్ధతి. సమతుల్య ఖర్చు utilisation పై ఆధారపడి ఉంటుంది: busy GPU ప్రతి tokenకు తక్కువ ఖర్చుతో పనిచేస్తుంది; idle GPU మాత్రం పూర్తిగా వృథా.
నిజంగా పనిచేసే మూడు సాధారణ విధానాలు ఉన్నాయి. నిరంతరంగా వచ్చే తక్కువ పరిమాణపు పనిని CPU VPSపై ఉంచండి. అప్పుడప్పుడు వచ్చే కఠినమైన requestను hosted APIకు పంపి, ప్రతి tokenకు చెల్లించండి. batch jobs, fine-tuning లేదా పెద్ద embedding run కోసం GPUను గంటల ప్రాతిపదికన rent చేసి, పని పూర్తయిన తర్వాత దాన్ని destroy చేయండి. ఈ విధానాలను కలపడం సాధారణమే. ఎప్పుడూ ఆన్లో ఉండే VPSలో AI agent ఖర్చు నియంత్రణలో వివరించిన budgeting discipline ఇక్కడ కూడా వర్తిస్తుంది. అయితే ఇక్కడ leak అయ్యేది token count కాదు, idle time.
GPU లేకుండా కూడా సజావుగా నడిచేవి
తక్కువ పరిమాణంలోని embeddings. కొన్ని CPU cores పై చిన్న embedding model ప్రతి నిమిషం వందల కొద్దీ చిన్న documents ను process చేయగలదు. మీరు ఒకసారి నిర్మించిన index వేగంగా ఉండాల్సిన అవసరం లేదు.
Transcription కోసం Whisper small మరియు base models. CPU పై faster-whisper small model కు సమీప real-time వేగంతో transcription చేస్తుంది. రాత్రంతా నడిచే pipeline కు ఇది సరిపోతుంది.
ఒకరు లేదా ఇద్దరు users కోసం సుమారు 27B వరకు quantized chat models. వేగం తక్కువగా ఉంటుంది. కానీ చదవడానికి అనుకూలంగా, ఉపయోగించగల స్థాయిలో ఉంటాయి.
మీరు batch job గా పరిగణించే ఏ పనైనా. ఎవరూ screen ను గమనించకపోతే, wall-clock వేగం అవసరం కాకుండా scheduling వివరంగా మాత్రమే ఉంటుంది.
నిజంగా GPU అవసరమయ్యే పనులు: చిన్న adapter పరిమితిని మించిన training లేదా fine-tuning, అనేక concurrent users కు serving, image మరియు video generation, అలాగే latency నే ఉత్పత్తి విలువగా కలిగిన real-time speech.
FAQ
7B లేదా 8B model కోసం ఎంత VRAM అవసరం?
సాధారణ 8k నుంచి 16k context వద్ద 4-bit quantized 8B model కోసం సుమారు 6 GB అవసరం. Weights పరిమాణం సుమారు 4.7 GB ఉంటుంది. మిగిలినది KV cache మరియు సుమారు 1 GB overhead కోసం ఉపయోగించబడుతుంది. 12 GB card ఎక్కువ context కోసం తగినంత అదనపు స్థలాన్ని ఇస్తుంది. 128k context వద్ద run చేయాలనుకుంటే cache కోసం ప్రత్యేకంగా పరిమాణాన్ని నిర్ణయించాలి. అది weights కంటే పెద్దదిగా పెరగవచ్చు.
GPU లేకుండా Ollama ను run చేయగలనా?
అవును. Ollama స్వయంచాలకంగా CPU కు fallback అవుతుంది. model ను memoryలో ఉంచడానికి సరిపడే RAM మాత్రమే అవసరం. Memory speed ఆధారంగా 4-bit 8B model కు సెకనుకు సుమారు 5 నుంచి 12 tokens వస్తాయని అంచనా వేయవచ్చు. ఇది ఒక user కోసం చదివే వేగానికి దగ్గరగా ఉంటుంది. CPUపై పొడవైన prompts అసలు సమస్య. 30,000 tokens context ను చదవడం compute-bound అవుతుంది. అందువల్ల reply generate చేయడం కంటే దీనికి చాలా ఎక్కువ సమయం పడుతుంది.
నా GPU CPU కంటే స్వల్పంగా మాత్రమే వేగంగా ఎందుకు ఉంది?
సాధారణ కారణం model మొత్తం VRAMలో సరిపోకపోవడం. అందువల్ల కొన్ని layers CPUపై run అవుతాయి. ప్రతి token నెమ్మదైన భాగం కోసం వేచి ఉంటుంది. ollama ps ను run చేసి, PROCESSOR columnలో 100% GPU ఉందో చూడండి. Split కనిపిస్తే చిన్న quantization లేదా చిన్న model ఉపయోగించండి. మరో సాధారణ కారణం చిన్న benchmark కావడం. అలాంటి సందర్భంలో model load time కొలతపై అధిక ప్రభావం చూపుతుంది.
ఒక user కోసం GPU VPS ఉపయోగించడం విలువైనదేనా?
సాధారణంగా కాదు. ఒక వ్యక్తి సెకనుకు 5 నుంచి 10 words చదువుతాడు. సుమారు 13B వరకు ఉన్న models కోసం CPU box ఇప్పటికే దానికంటే వేగంగా tokens ఉత్పత్తి చేస్తుంది. ఒక user కోసం ఖర్చును సమర్థించే సందర్భాలు పొడవైన prompts, image generation మరియు fine-tuning. ఒకేసారి అనేక usersకు సేవ అందించడం మరింత బలమైన కారణం. Batching ద్వారా ఒక GPU, ఒక requestకు సమీపమైన ఖర్చుతో ఇరవై requestsకు సమాధానం ఇవ్వగలదు.
GPUని గంటల వారీగా rent చేయాలా, లేక ఎల్లప్పుడూ onలో ఉంచాలా?
పని burstyగా ఉంటే గంటల వారీగా rent చేయండి: fine-tuning, bulk embedding run లేదా batch transcription job వంటి సందర్భాల్లో. Card నిరంతరం busyగా ఉన్నప్పుడు మాత్రమే ఎల్లప్పుడూ onలో ఉంచండి. GPU instance tokens ఉత్పత్తి చేసినందుకు కాకుండా ఉనికిలో ఉన్నందుకు billing చేస్తుంది. తక్కువ traffic ఉన్న assistantకు idle GPU కంటే CPU VPS లేదా token ఆధారంగా చెల్లించే hosted API చవకగా ఉంటుంది.