GPU ఉన్న VPS ఎప్పుడు అవసరం? CPU ఎప్పుడు సరిపోతుంది?

GPU ఉన్న VPS అవసరమా, లేక CPU సరిపోతుందా?

GPU ఉన్న VPS ద్వారా మోడల్‌ను స్వయంగా అమలు చేయడంలో రెండు విషయాలు మారుతాయి: టోకెన్‌లు ఉత్పత్తి అయ్యే వేగం, అలాగే మొత్తం మెమరీలో సరిపోగల మోడల్ పరిమాణం. ఇతర విషయాల్లో ఎలాంటి మార్పు ఉండదు. మీ పనిభారం quantized 7B నుంచి 27B chat model వరకు ఉండి, ఒకేసారి ఒక్క వ్యక్తికి సమాధానం ఇవ్వడం, తక్కువ పరిమాణంలో embedding పని చేయడం, లేదా Whisper smallతో speech transcription చేయడం మాత్రమే అయితే, తగినంత RAM ఉన్న సాధారణ CPU VPS ఆ పనిని ఇప్పటికే నిర్వహిస్తుంది. ముందుగా CPUపై ప్రారంభించండి. మీకు ఇబ్బంది కలిగించే కొలతను గుర్తించండి. తర్వాత అవసరమైతే అధిక సామర్థ్యానికి మారండి.

దీనికి కారణం memory bandwidth. language model ఒక టోకెన్‌ను ఉత్పత్తి చేసేటప్పుడు, అవసరమైన ప్రతి weightను మెమరీ నుంచి చదువుతుంది. 4 bitsకు quantized చేసిన 8B model డిస్క్‌లో సుమారు 4.7 GB ఉంటుంది. మెమరీలో కూడా దాదాపు అంతే పరిమాణం ఉంటుంది. అందువల్ల ఒక టోకెన్‌ను ఉత్పత్తి చేయడానికి సుమారు 4.7 GB డేటాను తరలించాలి. మెషీన్ memory bandwidthను ఆ సంఖ్యతో భాగిస్తే, సెకనుకు ఉత్పత్తి చేయగల టోకెన్‌ల గరిష్ఠ పరిమితి లభిస్తుంది. మీరు చదివే దాదాపు ప్రతి benchmarkను ఈ ఒక్క భాగింపు వివరిస్తుంది.

GPU నిజంగా మీకు ఏమి అందిస్తుంది

బ్యాండ్‌విడ్త్. ఆధునిక హోస్ట్‌లోని Server DDR5 ప్రతి సెకనుకు పదుల గిగాబైట్ల డేటాను తరలిస్తుంది. GPU మెమరీ (VRAM, video RAM) ప్రతి సెకనుకు వందల గిగాబైట్ల నుంచి వెయ్యికి పైగా గిగాబైట్ల డేటాను తరలిస్తుంది. ఈ నిష్పత్తే వేగవృద్ధిని నిర్ణయిస్తుంది. ఇది గణనీయంగా ఉంటుంది.

వేగంతో కూడిన సామర్థ్యం. 64 GB RAM ఉన్న CPU బాక్స్ 4 bits వద్ద 70B మోడల్‌ను లోడ్ చేయగలదు. అది పనిచేస్తుంది, కానీ సంభాషణ కంటే చదవడం వంటి వేగంతో ఉంటుంది. మోడల్ VRAMలో సరిపోతేనే GPU ఇక్కడ సహాయపడుతుంది. ఎందుకంటే layers system RAMలోకి వెళ్లిన వెంటనే నెమ్మదైన మార్గమే మళ్లీ ప్రధానమవుతుంది.

బ్యాచ్ throughput. చాలామంది తక్కువగా అంచనా వేసేది ఇదే. ఒక వినియోగదారుని కోసం GPU రూపొందిస్తుంటే, దాని computeలో ఎక్కువ భాగం idleగా ఉంటుంది. కారణం, అది మెమరీ కోసం వేచి ఉంటుంది. ఒకేసారి 20 requestsను అందిస్తే, అదే weight read మొత్తం 20 requestsకు ఉపయోగపడుతుంది. ప్రతి సెకనుకు మొత్తం tokens సంఖ్య అనేక రెట్లు పెరుగుతుంది. ప్రతి వినియోగదారుని వేగం మాత్రం స్వల్పంగానే తగ్గుతుంది. CPU ఇలా చేయలేడు. CPU బాక్స్‌లో ఒకేసారి పనిచేసే ఇద్దరు వినియోగదారులు సాధారణంగా ఒకరి వేగాన్ని మరొకరు సగానికి తగ్గిస్తారు. అనేక clients పిలిచే APIను నిర్మిస్తున్నట్లయితే, raw single-stream వేగం కంటే batching అనేదే GPUకు బలమైన కారణం.

Prompt processing. దీర్ఘమైన promptను చదవడం memory-bound కాకుండా compute-bound ప్రక్రియ. GPUలు అత్యంత ఎక్కువ ప్రయోజనం చూపించేది ఇక్కడే. CPU ఒక నిమిషంలో process చేసే 30,000 token contextను GPU కొన్ని secondsలో process చేస్తుంది. ప్రతి requestలో documentsను చేర్చే Retrieval సెటప్‌లలో ఈ తేడా నిరంతరం కనిపిస్తుంది.

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

క్రింది బ్లాక్‌లో July 2026 నాటికి 4-bit quantizationతో 8B model కోసం సాధారణంగా ప్రచురించబడిన single-stream గణాంకాలు ఉన్నాయి. ఇవి ఖచ్చితమైన హామీ కాదు; పరిమాణ క్రమాన్ని అంచనా వేయడానికి మాత్రమే ఉపయోగపడతాయి. మీ 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 చూపిస్తుంది. DDR5 CPU box కోసం ఈ విలువ 11. ఇది సుమారు ఐదు రెట్లు ఎక్కువ. ఈ తేడా raw computeలోని వ్యత్యాసం కంటే bandwidth ratioకు ఎక్కువగా అనుగుణంగా ఉంటుంది. వాస్తవ throughput కూడా bandwidthను model sizeతో భాగించిన విలువ కంటే తక్కువగా ఉంటుంది. ఎందుకంటే పెరుగుతున్న contextపై attention అదనపు పని చేస్తుంది. సాధారణ భాగహారం ఈ పనిని పరిగణనలోకి తీసుకోదు.

పోల్చి చూడటానికి, ఒక వ్యక్తి సెకనుకు సుమారు 5 నుంచి 10 పదాలు చదువుతాడు. సెకనుకు 15 tokens లేదా అంతకంటే ఎక్కువ వేగం ఉంటే, ఒకే readerకు అది సాధారణ typing వేగంలా అనిపిస్తుంది. అందుకే CPU-only setupsలో చాలా వరకు వాస్తవ వినియోగానికి సరిపోతాయి.

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

మోడల్ ఫైల్ పరిమాణం కనీస అవసరం మాత్రమే, పూర్తి అవసరం కాదు. వెయిట్లతో పాటు KV cache (key-value cache, attention నిర్వహించే ప్రతి టోకెన్ మెమరీ), అలాగే సుమారు 1 GB అదనపు ఓవర్‌హెడ్‌కు కూడా VRAM కేటాయించండి.

July 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 కార్డ్ లేదా రెండు చిన్న కార్డులు అవసరం.

దీర్ఘమైన contextలు ఈ నియమాన్ని వర్తించనివిగా చేస్తాయి. KV cache పరిమాణం context lengthతో సమాన నిష్పత్తిలో పెరుగుతుంది. 128k tokens వద్ద, దాని పరిమాణం వెయిట్ల కంటే కూడా ఎక్కువ కావచ్చు. మీరు దీర్ఘమైన contextలను ఉపయోగించాలనుకుంటే, ముందుగా 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 కాలేదు అని అర్థం. ప్రామాణిక Ubuntu imageలో సాధారణంగా దీనికి పరిష్కారం sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install. ఆ తర్వాత reboot చేయాలి, తద్వారా కొత్త module load అవుతుంది.

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 కనిపిస్తే, toolkit install అయింది కానీ Dockerను మళ్లీ configure చేయలేదు లేదా restart చేయలేదు అని అర్థం. అందువల్ల nvidia-ctk lineను మళ్లీ అమలు చేసి, restart చేయండి. Composeలో దీనికి సమానమైనది deploy.resources.reservations.devices entry. దాని driver విలువ nvidiaగా ఉండాలి, అలాగే capabilities listలో gpu ఉండాలి. ఇది VPSలో Docker Composeలో వివరించిన సాధారణ service definitionsలో చేర్చవచ్చు.

అప్‌గ్రేడ్ చేయడానికి ముందు కొలవండి

మీరు వాస్తవంగా ఉపయోగించాలనుకుంటున్న model‌ను, ఇప్పటికే ఉన్న CPU machine‌పైనే అమలు చేసి, ఫలితాలను నమోదు చేయండి. VPSలో LLMను self-host చేయడానికి Ollamaతో దీనికి ఒక flag చాలు:

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

Output చివరలో timing వివరాలు ఉంటాయి. eval rate అనేది ప్రతి సెకనుకు tokensలో మీ generation speed. prompt eval rate అనేది machine మీ input‌ను ఎంత వేగంగా చదివిందో చూపిస్తుంది. ఏ upgrade ఉపయోగకరమో ఈ రెండు సంఖ్యలు తెలియజేస్తాయి: తక్కువ eval rate ఉంటే అది memory-bandwidth సమస్య. దీర్ఘమైన inputలపై తక్కువ prompt eval rate ఉంటే అది compute సమస్య.

GPU ఉన్న machineలో model నిజంగా GPUపైనే load అయిందో తనిఖీ చేయండి:

ollama ps

ప్రతిదీ సరిపోతే PROCESSOR columnలో 100% GPU కనిపిస్తుంది. సరిపోకపోతే 43%/57% CPU/GPU వంటి విలువ కనిపిస్తుంది. Partial split సాధారణంగా మీరు ఊహించినదానికంటే అధ్వాన్నంగా ఉంటుంది, ఎందుకంటే ప్రతి token నెమ్మదైన భాగం కోసం ఇంకా వేచి ఉండాలి.

ఖర్చు ప్రశ్న

GPU instances, సమాన సామర్థ్యం ఉన్న CPU instance కంటే అనేక రెట్లు ఖరీదైనవి. అవి ఉత్పత్తి చేసే tokens ఆధారంగా కాకుండా, అమల్లో ఉన్న ప్రతి గంటకు billing చేస్తాయి. రోజుకు కొద్ది requests మాత్రమే అందించే ఎప్పుడూ ప్రారంభించి ఉంచిన GPU, inference అమలు చేయడానికి అత్యంత ఖరీదైన విధానం. సమతుల్య స్థానం utilisation పై ఆధారపడి ఉంటుంది: బిజీగా ఉన్న GPU ప్రతి token కు తక్కువ ఖర్చు అవుతుంది. పనిలేకుండా ఉన్న GPU పూర్తిగా వృథా.

నిజంగా ఉపయోగపడే మూడు విధానాలు ఉన్నాయి. స్థిరమైన, తక్కువ పరిమాణంలోని పనిని CPU VPS పై ఉంచండి. అప్పుడప్పుడు వచ్చే క్లిష్టమైన request ను hosted API కు పంపి, ప్రతి token కు చెల్లించండి. Batch jobs, fine-tuning లేదా bulk embedding run కోసం GPU ని గంటల ప్రాతిపదికన rent చేసి, పని పూర్తయ్యాక దాన్ని destroy చేయండి. ఈ విధానాలను కలపడం సాధారణమే. ఎప్పుడూ ప్రారంభించి ఉంచిన VPS పై AI agent ఖర్చు నియంత్రణలో వివరించిన budgeting discipline ఇక్కడ కూడా వర్తిస్తుంది. అయితే ఇక్కడ leak tokens సంఖ్య కాదు; idle time.

GPU లేకపోయినా సజావుగా నడిచేవి

తక్కువ పరిమాణంలోని Embeddings. చిన్న embedding model కొన్ని CPU coresపై ప్రతి నిమిషం వందల కొద్దీ చిన్న పత్రాలను process చేయగలదు. మీరు ఒక్కసారి build చేసిన 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కు serving, image మరియు video generation, అలాగే latencyనే ప్రధాన ఉత్పత్తిగా భావించే 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 మాత్రమే అవసరం. 4-bit 8B మోడల్‌కు memory speedపై ఆధారపడి సెకనుకు సుమారు 5 నుంచి 12 tokens వస్తాయని ఆశించండి. ఇది ఒక వినియోగదారుకు చదివే వేగానికి దగ్గరగా ఉంటుంది. CPUపై పొడవైన prompts ప్రధాన సమస్య. 30,000 tokens contextను చదవడం compute-bound కావడం వల్ల reply రూపొందించడంకంటే చాలా ఎక్కువ సమయం పడుతుంది.

నా GPU CPU కంటే స్వల్పంగా మాత్రమే వేగంగా ఎందుకు ఉంది?

మోడల్ మొత్తం VRAMలో సరిపోకపోవడం సాధారణ కారణం. అందువల్ల కొన్ని layers CPUపై అమలవుతాయి. ప్రతి token నెమ్మదైన భాగం కోసం వేచి ఉంటుంది. ollama psను అమలు చేసి, PROCESSOR columnలో 100% GPU కనిపిస్తుందో తనిఖీ చేయండి. split కనిపిస్తే, చిన్న quantization లేదా చిన్న మోడల్‌ను ఉపయోగించండి. మరో సాధారణ కారణం చిన్న benchmark. అందులో model load time కొలతను ఎక్కువగా ప్రభావితం చేస్తుంది.

ఒకే వినియోగదారుకు GPU VPS విలువైనదేనా?

సాధారణంగా కాదు. ఒక వ్యక్తి సెకనుకు 5 నుంచి 10 పదాలు చదువుతాడు. సుమారు 13B వరకు ఉన్న మోడళ్లకు CPU box ఇప్పటికే దానికంటే వేగంగా tokens ఉత్పత్తి చేస్తుంది. ఒకే వినియోగదారుకు ఖర్చును సమర్థించే సందర్భాలు పొడవైన prompts, image generation మరియు fine-tuning. ఒకేసారి అనేక మంది వినియోగదారులకు సేవలు అందించడం అత్యంత బలమైన కారణం. batching ద్వారా ఒక GPU, ఒక requestకు సమీపమైన ఖర్చుతో ఇరవై requestsకు సమాధానం ఇవ్వగలదు.

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

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