GPU ఉన్న VPS ఎప్పుడు అవసరం? 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ను generate చేసేటప్పుడు, అవసరమైన ప్రతి weightను memory నుంచి చదువుతుంది. 4 bitsకు quantize చేసిన 8B model diskలో సుమారు 4.9 GB ఉంటుంది. Memoryలో కూడా దాదాపు అంతే స్థలం పడుతుంది. అందువల్ల ఒక tokenను ఉత్పత్తి చేయడానికి సుమారు 4.9 GB dataను తరలించాలి. Machine memory bandwidthను ఆ పరిమాణంతో భాగిస్తే, సెకనుకు tokens సంఖ్యకు గరిష్ఠ పరిమితి లభిస్తుంది. మీరు చదివే దాదాపు ప్రతి benchmark వెనుక ఉన్న కారణాన్ని ఈ ఒక్క లెక్క వివరిస్తుంది.

GPU వాస్తవంగా మీకు అందించేది

Bandwidth. ఆధునిక host లోని server DDR5 memory ప్రతి సెకనుకు పదుల gigabytes డేటాను తరలిస్తుంది. GPU memory (VRAM, video RAM) ప్రతి సెకనుకు వందల gigabytes నుంచి వెయ్యికి పైగా gigabytes వరకు తరలిస్తుంది. ఈ నిష్పత్తే speedup ను నిర్ణయిస్తుంది. ఇది గణనీయంగా ఉంటుంది.

Capacity with speed. 64 GB RAM ఉన్న CPU machine 4 bits వద్ద 70B model ను load చేయగలదు. అయితే దాని వేగం సంభాషణ కంటే చదవడాన్ని ఎక్కువగా పోలి ఉంటుంది. Model మొత్తం VRAM లో సరిపోతేనే GPU ఇక్కడ సహాయపడుతుంది. Model layers system RAM కు వెళ్లిన వెంటనే నెమ్మదైన మార్గమే మళ్లీ వేగాన్ని నిర్ణయిస్తుంది.

Batch throughput. చాలామంది తక్కువగా అంచనా వేసేది ఇదే. ఒక user కోసం GPU generate చేస్తున్నప్పుడు, అది memory కోసం వేచి ఉండటం వల్ల దాని compute సామర్థ్యంలో ఎక్కువ భాగం idle గా ఉంటుంది. ఒకేసారి 20 requests ను serve చేస్తే, అదే weight read మొత్తం 20 requests కు ఉపయోగపడుతుంది. Aggregate tokens per second అనేక రెట్లు పెరుగుతుంది. ప్రతి user కు లభించే వేగం మాత్రం స్వల్పంగా మాత్రమే తగ్గుతుంది. llama.cpp వంటి CPU inference engines కూడా batching కు మద్దతు ఇస్తాయి. లాభాలు hardware మరియు workload పై ఆధారపడతాయి. అనేక clients call చేసే API ను నిర్మిస్తున్నట్లయితే, raw single-stream speed కంటే GPU కు batching ముఖ్యమైన కారణం.

Prompt processing. Long prompt ను చదవడం memory-bound కాదు; ఇది compute-bound. GPUలు అత్యధిక తేడా చూపించేది ఇక్కడే. CPU ఒక నిమిషంలో process చేసే 30,000 token context ను GPU కొన్ని seconds లో process చేయగలదు. ప్రతి request లో documents ను చేర్చే retrieval setups లో ఈ ప్రయోజనం తరచుగా కనిపిస్తుంది.

సుమారు సంఖ్యలు, వాటిని ఎలా అర్థం చేసుకోవాలి

నిజమైన throughput కూడా bandwidth ను model size తో భాగించిన విలువకన్నా తక్కువగా ఉంటుంది. ఎందుకంటే పెరుగుతున్న context పై attention కు అదనపు పని అవసరం అవుతుంది. ఆ పనిని సాధారణ భాగహారం పరిగణనలోకి తీసుకోదు.

పోలిక కోసం, ఆంగ్లంలో పెద్దలు మౌనంగా చదివే సగటు వేగం సెకనుకు సుమారు 4.0 నుంచి 4.3 పదాలు. Non-fiction కోసం నిమిషానికి 238 పదాలు, fiction కోసం 260 పదాలు ఉంటాయి. ఒకే reader కు సెకనుకు 15 tokens లేదా అంతకంటే ఎక్కువ వేగం సాధారణ typing లాగా అనిపిస్తుంది. అందుకే CPU-only setups చాలా సందర్భాల్లో ఎటువంటి సమస్య లేకుండా సరిపోతాయి.

కొనుగోలు చేయడానికి ముందు VRAM పరిమాణాన్ని నిర్ణయించడం

Model file పరిమాణం కనీస అంచనా మాత్రమే; అది అవసరమైన మొత్తం కాదు. Weights, KV cache (key-value cache, attention నిర్వహించే ప్రతి token కు సంబంధించిన memory), అలాగే సుమారు 1 GB overhead కోసం VRAM ను కేటాయించండి.

Cache ను ఒక స్థిర శాతంగా కలపకుండా, విడిగా లెక్కించండి. ఎందుకంటే weights ను quantize చేసినా cache quantize కాదు. ప్రతి token కోసం full-attention model ప్రతి layer మరియు ప్రతి KV head కు ఒక key, ఒక value ను నిల్వ చేస్తుంది. FP16లో ప్రతి number కు 2 bytes అవసరం. ఇది Ollama యొక్క default cache type. 2026-10-27న పరిశీలించిన Ollama model metadata ప్రకారం, Llama 3.1 8Bలో 32 layers, 128 dimensions కలిగిన 8 KV heads ఉన్నాయి. దీని ప్రకారం ప్రతి token కు 128 KiB అవసరం: 8k context వద్ద సుమారు 1.07 GB, 16k వద్ద 2.15 GB. కాబట్టి 4.9 GB పరిమాణం ఉన్న 8B model కు 8k వద్ద సుమారు 7 GB VRAM, 16k వద్ద సుమారు 8 GB VRAM అవసరం. 4 bits వద్ద 27B model సుమారు 17 GB ఉంటుంది (Ollama libraryలోని Gemma 3 27B). Gemma 3 metadataలో 1,024-token sliding window ఉంది. దీని వల్ల దాని cacheలో ఎక్కువ భాగం నిరంతరం పెరగదు. అందువల్ల 20 GB లేదా అంతకంటే ఎక్కువ VRAM కోసం ప్రణాళిక వేయండి. 4 bits వద్ద 70B model సుమారు 43 GB ఉంటుంది (Llama 3.3 70B). ఇందులో 80 layers ఉన్నాయి. అందువల్ల దీని FP16 cache 8k వద్ద సుమారు 2.7 GB, 16k వద్ద 5.4 GB అదనంగా అవసరం చేస్తుంది. కాబట్టి తక్కువ మిగులు ఉన్న 48 GB card అవసరం, లేదా రెండు చిన్న cards అవసరం. ఇదే లెక్కింపు దీనికంటే చాలా పెద్ద models కు కూడా వర్తిస్తుంది. Kimi K3 వంటి 2.8 trillion parameter model కోసం VRAM లెక్కింపులో card ఎంచుకోవడం అసలు ప్రశ్నగా మిగలని స్థితి ఎక్కడ మొదలవుతుందో చూపిస్తుంది.

Long contexts ఉన్నప్పుడు ఈ విషయం అత్యంత ముఖ్యమవుతుంది. Llama 3.1 వంటి full-attention modelsలో context length పెరిగే కొద్దీ KV cache కూడా linearగా పెరుగుతుంది. 128k tokens వద్ద ఇది weights పరిమాణాన్ని మించవచ్చు. Sliding-window లేదా chunked attention ఉన్న models భిన్నంగా పనిచేస్తాయి. Hugging Face Transformers documentationలో Mistral, Gemma 2, Llama 4 ఉదాహరణలుగా ఉన్నాయి. ఈ modelsలో window లేదా chunk size చేరుకున్న తర్వాత ఆ layersలో cache పెరగడం ఆగిపోతుంది. అందువల్ల మొత్తం పరిమాణం నెమ్మదిగా పెరుగుతుంది. Long contexts ఉపయోగించాలనుకుంటే ముందుగా cache ఆధారంగా VRAM పరిమాణాన్ని నిర్ణయించండి. మీ engine cache quantization కోసం ఏ సదుపాయాలు అందిస్తుందో కూడా పరిశీలించండి. Ollamaలో OLLAMA_KV_CACHE_TYPE=q8_0, default f16 ఉపయోగించే memoryలో సుమారు సగం memory ఉపయోగిస్తుంది. Flash Attention enabled ఉన్నప్పుడు మాత్రమే cache quantization వర్తిస్తుంది. Context length ను కూడా స్పష్టంగా set చేయండి. Ollama VRAM ఆధారంగా default ఎంచుకుంటుంది: 24 GiB కంటే తక్కువకు 4k, 24 నుంచి 48 GiB వరకు 32k, 48 GiB లేదా అంతకంటే ఎక్కువకు 256k. 70B model నడుస్తున్న 48 GB cardలో ఈ default cardలో ఉన్నదానికంటే చాలా ఎక్కువ cache కోరుతుంది.

యంత్రంలో నిజంగా ఉన్నదాన్ని పరిశీలించండి

GPU instanceలో మరే పనికన్నా ముందు driver cardను గుర్తిస్తుందో లేదో నిర్ధారించండి.

nvidia-smi

GPU పేరు, driver version, అలాగే మొత్తం memoryలో ఎంత ఉపయోగించబడుతోందో చూపించే పట్టిక కనిపించాలి. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver కనిపిస్తే NVIDIA-SMI driverను చేరుకోలేకపోతోంది; driver install అయిందో, దాని kernel module load అయిందో పరిశీలించండి. సాధారణ 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 ఒక్కటే సరిపోదు. Deviceను containerకు pass through చేయడానికి 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 కనిపిస్తే, ఆ అభ్యర్థనకు సరిపోయే device driverను Docker కనుగొనలేకపోయిందని అర్థం. Toolkit install అయిందో పరిశీలించండి. తరువాత 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 కు provider నిర్ణయించిన రేట్లు మరియు stopped instance charges వర్తిస్తాయి. వీటికి tokens ఆధారంగా కాకుండా provision చేసిన compute time ఆధారంగా బిల్లింగ్ జరుగుతుంది. రోజుకు కొద్దిపాటి requests మాత్రమే అందించే always-on GPU, చెల్లించిన సమయములో ఎక్కువ భాగం idle గా ఉంటుంది. లాభదాయకతను నిర్ణయించేది utilisation. నిరంతరం busy గా ఉండే GPU ప్రతి token కు తక్కువ ఖర్చు అవుతుంది. idle గా ఉన్న GPU మాత్రం పూర్తిగా వృథా.

మూడు ఆచరణాత్మక విధానాలు ఉన్నాయి. స్థిరమైన, తక్కువ పరిమాణంలోని పనిని CPU VPS పై ఉంచండి. అప్పుడప్పుడు వచ్చే క్లిష్టమైన request ను hosted API కు పంపి, ప్రతి token కు చెల్లించండి. Batch jobs, fine-tuning లేదా bulk embedding run కోసం GPU ను గంటల వారీగా rent చేసి, పని పూర్తయిన తర్వాత దాన్ని destroy చేయండి. ఈ విధానాలను కలపడం సాధారణమే. always-on VPS పై AI agent ఖర్చు నియంత్రణ లో వివరించిన budgeting discipline ఇక్కడ కూడా వర్తిస్తుంది. అయితే ఇక్కడ నష్టం tokens సంఖ్య వల్ల కాకుండా 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 context వద్ద 4-bit quantized 8B model కు సుమారు 7 GB, 16k వద్ద సుమారు 8 GB అవసరం. ఇది Ollama యొక్క default FP16 cache ను పరిగణనలోకి తీసుకున్న అంచనా. Weights పరిమాణం సుమారు 4.9 GB. KV cache 8k వద్ద సుమారు 1.07 GB, 16k వద్ద 2.15 GB అదనంగా ఉపయోగిస్తుంది. మిగిలినది సుమారు 1 GB overhead. 8 GB card 8k వద్ద సరిపోతుంది, కానీ 16k వద్ద పరిమితికి దగ్గరగా ఉంటుంది. 12 GB card ఎక్కువ context కోసం తగినంత అదనపు స్థలాన్ని ఇస్తుంది. Cache ను q8_0 కు మార్చితే, cache ఉపయోగించే VRAM సుమారు సగానికి తగ్గుతుంది. 128k context వద్ద అమలు చేయాలనుకుంటే cache కోసం ప్రత్యేకంగా పరిమాణాన్ని నిర్ణయించండి. ఎందుకంటే దాని పరిమాణం weights కంటే ఎక్కువ కావచ్చు.

GPU లేకుండా Ollama ను అమలు చేయవచ్చా?

అవును. 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పై నడుస్తాయి. ప్రతి token నెమ్మదైన భాగం పూర్తయ్యే వరకు వేచి ఉంటుంది. ollama ps ను అమలు చేసి, PROCESSOR column లో 100% GPU కనిపిస్తుందో చూడండి. Split కనిపిస్తే చిన్న quantization లేదా చిన్న model ను ఉపయోగించండి. మరో సాధారణ కారణం చిన్న benchmark. అందులో model load time కొలతను ప్రధానంగా ప్రభావితం చేస్తుంది.

ఒక user కోసం GPU VPS ఉపయోగించడం ప్రయోజనకరమా?

సాధారణంగా కాదు. Englishలో పెద్దవారి నిశ్శబ్ద పఠన వేగం సగటున సెకనుకు 4.0 నుంచి 4.3 words ఉంటుంది. CPU box వేగాన్ని ఆ వేగంతో పోల్చే ముందు tokens per second ను words per second గా మార్చాలి. ఒక user కోసం ఖర్చును సమర్థించే సందర్భాలు long prompts, image generation, fine-tuning. ఒకేసారి అనేక users కు service అందించడం మరింత బలమైన కారణం. Batching వల్ల ఒక GPU requests మధ్య weight reads ను పంచుకోగలదు.

GPU ను hourly అద్దెకు తీసుకోవాలా, లేక ఎల్లప్పుడూ నడిపించాలా?

పని bursty గా ఉంటే hourly అద్దెకు తీసుకోండి. ఉదాహరణకు fine-tuning, bulk embedding run లేదా batch transcription job. Card నిరంతరం busyగా ఉన్నప్పుడు మాత్రమే దాన్ని ఎల్లప్పుడూ నడపండి. Provisioned GPU compute ఉత్పత్తి చేసిన tokens ఆధారంగా కాకుండా ఉపయోగించిన సమయం ఆధారంగా billing చేస్తుంది. తక్కువ traffic ఉన్న assistant కు idle GPU కంటే CPU VPS లేదా token ఆధారంగా చెల్లించే hosted API చౌకగా ఉంటుంది.