GPU VPS தேவையா? CPU போதுமா என்பதை அறிய வழி

GPU கொண்ட VPS தேவையா, அல்லது CPU போதுமா?

GPU கொண்ட VPS-ல் ஒரு model-ஐ நீங்களே இயக்கும்போது இரண்டு விஷயங்கள் மாறும்: tokens வெளிவரும் வேகம் மற்றும் ஒரு model முழுமையாக 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 தரவை நகர்த்த வேண்டும். machine-ன் memory bandwidth-ஐ அந்த எண்ணால் வகுத்தால், ஒரு வினாடிக்கு உருவாக்கக்கூடிய tokens-ன் உச்சவரம்பு கிடைக்கும். நீங்கள் படிக்கும் பெரும்பாலான benchmarks-ஐ இந்த ஒரே வகுத்தல் விளக்குகிறது.

GPU உண்மையில் உங்களுக்கு வழங்குவது

Bandwidth. நவீன host-இல் உள்ள Server DDR5, ஒரு வினாடிக்கு பத்துக்கணக்கான gigabytes தரவை நகர்த்தும். GPU memory (VRAM, video RAM), ஒரு வினாடிக்கு நூற்றுக்கணக்கான முதல் ஆயிரத்திற்கும் மேற்பட்ட gigabytes தரவை நகர்த்தும். இந்த விகிதமே speedup ஆகும்; அது பெரியது.

வேகத்துடன் கூடிய Capacity. 64 GB RAM கொண்ட CPU box-இல் 4 bits-ல் 70B model-ஐ load செய்யலாம். அது இயங்கும்; ஆனால் chat செய்வதைவிட வாசிப்பதை ஒத்த வேகத்தில் இருக்கும். Model முழுவதும் VRAM-இல் பொருந்தினால் மட்டுமே GPU இங்கு உதவும். ஏனெனில் layers system RAM-க்கு spill ஆனவுடன் slow path மீண்டும் செயல்படும்.

Batch throughput. இதை மக்கள் குறைவாக மதிப்பிடுகின்றனர். ஒரு user-க்காக GPU generate செய்யும்போது, compute-இன் பெரும்பகுதி idle-ஆக இருக்கும்; GPU memory-க்காக காத்திருப்பதே காரணம். ஒரே நேரத்தில் 20 requests-ஐ serve செய்தால், அதே weight read 20 requests-க்கும் பயன்படும். ஒவ்வொரு user-க்கான வேகம் மிகக் குறைவாக மட்டுமே குறையும்; மொத்த tokens per second பல மடங்கு உயரும். CPU இவ்வாறு செயல்படாது. CPU box-இல் ஒரே நேரத்தில் 2 users இருந்தால், அவர்கள் ஒருவருக்கொருவர் வேகத்தை சுமார் பாதியாகக் குறைப்பார்கள். பல clients அழைக்கும் API-ஐ உருவாக்குகிறீர்கள் என்றால், raw single-stream speed-ஐவிட batching என்பதே GPU-க்கான முக்கிய காரணம்.

Prompt processing. நீண்ட prompt-ஐ வாசிப்பது memory-bound அல்ல; அது compute-bound. இங்குதான் GPUs மிகப் பெரிய வித்தியாசத்தைக் காட்டுகின்றன. CPU ஒரு நிமிடத்தில் process செய்யும் 30,000 token context, GPU-இல் சில வினாடிகளில் முடியும். ஒவ்வொரு request-லும் documents-ஐ சேர்க்கும் Retrieval setups-இல் இந்த வேறுபாடு தொடர்ந்து தென்படும்.

தோராயமான எண்கள் மற்றும் அவற்றை எவ்வாறு வாசிப்பது

கீழே உள்ள block, 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 வரிசை, DDR5 CPU box-இல் உள்ள 11 உடன் ஒப்பிடும்போது ஒரு வினாடிக்கு 50 tokens காட்டுகிறது. இது தோராயமாக ஐந்து மடங்கு ஆகும். இந்த வேறுபாடு raw compute-இல் உள்ள வேறுபாட்டைக் காட்டிலும் bandwidth விகிதத்துடன் பொருந்துகிறது. வளர்ந்து வரும் context மீது attention கணக்கீடு கூடுதல் பணியைச் சேர்ப்பதால், உண்மையான throughput, bandwidth-ஐ model size-ஆல் வகுத்த மதிப்பைவிடக் குறைவாக இருக்கும். எளிய வகுத்தல் இதைக் கணக்கில் எடுத்துக்கொள்ளாது.

ஒப்பிடுவதற்காக, ஒருவர் ஒரு வினாடிக்கு சுமார் 5 முதல் 10 words வரை வாசிப்பார். ஒரு வாசிப்பாளருக்கு ஒரு வினாடிக்கு 15 tokens அல்லது அதற்கு மேல் இருந்தால், அது ஏற்கனவே வழக்கமான typing வேகமாகத் தோன்றும். அதனால் CPU-only setups பலவும் கவனத்திற்கு வராமல் போதுமானதாக இருக்கும்.

வாங்குவதற்கு முன் VRAM அளவை நிர்ணயித்தல்

Model file size என்பது குறைந்தபட்ச அளவு மட்டுமே; தேவையான மொத்த அளவு அல்ல. Weights, KV cache (key-value cache; attention பராமரிக்கும் ஒவ்வொரு token-க்குமான memory), மேலும் சுமார் 1 GB overhead ஆகியவற்றுக்கான இடத்தை ஒதுக்கவும்.

July 2026 நிலவரப்படி ஒரு நடைமுறை விதி: model file size-ஐ gigabytes-ல் எடுத்துக்கொண்டு, வழக்கமான 8k முதல் 16k context-க்கு 20 சதவீதத்தைச் சேர்க்கவும். 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 தேவைப்படும்.

நீண்ட context-கள் இந்த விதியைப் பொருந்தாததாக மாற்றுகின்றன. Context length அதிகரிக்கும்போது KV cache நேரியல் முறையில் பெரிதாகிறது. 128k tokens அளவில், அது weights-ஐவிடவும் பெரிதாகலாம். நீண்ட context-களைப் பயன்படுத்தத் திட்டமிட்டால், முதலில் cache-க்கான அளவை நிர்ணயிக்கவும். உங்கள் engine cache quantization-க்கு வழங்கும் வசதிகளையும் சரிபார்க்கவும்.

இயந்திரத்தில் உண்மையில் உள்ளவற்றைச் சரிபார்க்கவும்

GPU instance-ல், வேறு எதையும் செய்வதற்கு முன் driver card-ஐக் கண்டறிகிறதா என்பதை உறுதிப்படுத்தவும்.

nvidia-smi

GPU name, 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-ஐ Docker வழியாக pass செய்ய 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 மீண்டும் தோன்ற வேண்டும். பூர்த்தி செய்ய முடியாத 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-ல் இயக்கி, அளவீடுகளைப் பதிவு செய்யுங்கள். VPS-ல் Ollama மூலம் LLM-ஐ self-hosting செய்வது என்ற முறையில், இதற்கு ஒரு flag மட்டும் போதும்:

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

வெளியீட்டின் முடிவில் timing தகவல்கள் இருக்கும். eval rate என்பது tokens per second-ல் கணக்கிடப்பட்ட உங்கள் generation speed ஆகும். prompt eval rate என்பது machine உங்கள் input-ஐ எவ்வளவு வேகமாகப் படித்தது என்பதைக் காட்டும். எந்த upgrade உதவும் என்பதை இந்த இரண்டு அளவீடுகள் காட்டுகின்றன: குறைந்த eval rate என்பது memory-bandwidth சிக்கலைக் குறிக்கும். நீண்ட input-களில் குறைந்த prompt eval rate என்பது compute சிக்கலைக் குறிக்கும்.

GPU கொண்ட machine-ல், model உண்மையில் GPU-க்கு load ஆனதா என்பதைச் சரிபார்க்கவும்:

ollama ps

எல்லாம் GPU memory-ல் பொருந்தும்போது PROCESSOR column-ல் 100% GPU எனக் காட்டப்படும். பொருந்தாவிட்டால், 43%/57% CPU/GPU போன்ற மதிப்பு காட்டப்படும். Model-ன் ஒரு பகுதி மட்டும் GPU-க்கும் மற்ற பகுதி CPU-க்கும் பிரிக்கப்படுவது, பொதுவாக நீங்கள் எதிர்பார்ப்பதைவிட மோசமான செயல்திறனைத் தரும். ஒவ்வொரு token-உம் இன்னும் மெதுவான பகுதி முடியும் வரை காத்திருக்க வேண்டும்.

செலவு பற்றிய கேள்வி

GPU instances, அதற்கு இணையான CPU instance-ஐ விட பல மடங்கு அதிகம் செலவாகும். அவை உருவாக்கும் tokens எண்ணிக்கைக்காக அல்ல, இயங்கும் ஒவ்வொரு மணி நேரத்திற்கும் கட்டணம் வசூலிக்கும். நாளொன்றுக்கு சில requests மட்டுமே வழங்கும், எப்போதும் இயங்கும் GPU instance என்பது inference இயக்குவதற்கான மிக அதிகச் செலவான முறையாகும். செலவு சமநிலையை நிர்ணயிப்பது utilisation ஆகும்: அதிகப் பணிச்சுமையுடன் இயங்கும் GPU, ஒவ்வொரு token-க்கும் குறைந்த செலவாகும்; செயலற்ற GPU முற்றிலும் வீணாகும்.

நடைமுறையில் மூன்று முறைகள் பொருந்தும். தொடர்ந்து குறைந்த அளவில் நடைபெறும் பணிகளை CPU VPS-ல் வைத்திருங்கள். அரிதாக வரும் கடினமான request-ஐ hosted API-க்கு அனுப்பி, ஒவ்வொரு token-க்கும் கட்டணம் செலுத்துங்கள். batch jobs, fine-tuning அல்லது bulk embedding run-களுக்காக GPU-ஐ மணிநேர அடிப்படையில் rent செய்து, பணிகள் முடிந்ததும் அதை அழிக்கவும். இம்முறைகளை இணைத்துப் பயன்படுத்துவது இயல்பானது. எப்போதும் இயங்கும் VPS-ல் AI agent செலவுக் கட்டுப்பாடு பகுதியில் விளக்கப்பட்ட budgeting ஒழுக்கமும் இங்கே பொருந்தும். ஆனால் இங்கு கசிவு token எண்ணிக்கை அல்ல; idle time ஆகும்.

GPU இல்லாமலும் நன்றாக இயங்குபவை

குறைந்த அளவிலான Embeddings. சிறிய embedding model, சில CPU cores-ல் ஒவ்வொரு நிமிடமும் நூற்றுக்கணக்கான குறுகிய documents-ஐ process செய்யும். ஒருமுறை உருவாக்கப்பட்ட index வேகமாக இருக்க வேண்டிய அவசியமில்லை.

Transcription-க்கு Whisper small மற்றும் base models. CPU-ல் இயங்கும் faster-whisper, small model-ஐ கிட்டத்தட்ட real time-ல் transcribe செய்யும். இரவு முழுவதும் இயங்கும் pipeline-க்கு இது போதுமானது.

ஒன்று அல்லது இரண்டு users-க்கு, சுமார் 27B வரை உள்ள Quantized chat models. இவை மெதுவாக இருந்தாலும், படிக்கவும் பயன்படுத்தவும் முடியும்.

Batch job என்று அழைக்கக்கூடிய எந்தப் பணியும். திரையை யாரும் கண்காணிக்கவில்லை என்றால், wall-clock speed என்பது scheduling detail மட்டுமே; கட்டாயத் தேவையல்ல.

GPU உண்மையாகத் தேவைப்படும் பணிகள்: சிறிய adapter-ஐத் தாண்டிய training அல்லது fine-tuning, ஒரே நேரத்தில் பல users-க்கு serving, image மற்றும் video generation, மேலும் latency-யே product ஆக இருக்கும் 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-இல் இயக்கத் திட்டமிட்டால், cache-க்குத் தனியாக அளவை நிர்ணயிக்கவும். அது weights-ஐ விடப் பெரியதாக வளரக்கூடும்.

GPU இல்லாமல் Ollama-வை இயக்க முடியுமா?

ஆம். Ollama தானாக CPU-க்கு மாறும். Model-ஐ memory-யில் வைத்திருக்கத் தேவையான அளவு RAM மட்டுமே வேண்டும். Memory speed-ஐப் பொறுத்து 4-bit 8B model-க்கு வினாடிக்கு சுமார் 5 முதல் 12 tokens கிடைக்கும். ஒரு user-க்கு இது வாசிக்கும் வேகத்திற்கு நெருக்கமாக இருக்கும். CPU-இல் நீண்ட prompts தான் முக்கிய சிக்கல். 30,000 tokens கொண்ட context-ஐ வாசிப்பது compute-bound ஆக இருப்பதால், reply-ஐ உருவாக்குவதை விட அதிக நேரம் எடுக்கும்.

என் GPU, CPU-வை விட மிகக் குறைவாகவே வேகமாக இருப்பதற்கான காரணம் என்ன?

Model முழுவதும் VRAM-இல் பொருந்தாததே பொதுவான காரணம். அதனால் சில layers CPU-இல் இயங்கும். ஒவ்வொரு token-மும் மெதுவான பகுதியை எதிர்பார்க்க வேண்டியிருக்கும். ollama ps-ஐ இயக்கி, PROCESSOR column-ல் 100% GPU என்று காட்டப்படுகிறதா எனச் சரிபார்க்கவும். Split காட்டப்பட்டால், சிறிய quantization அல்லது சிறிய model-ஐப் பயன்படுத்தவும். மற்றொரு பொதுவான காரணம், குறுகிய benchmark-இல் model load time அளவீட்டில் ஆதிக்கம் செலுத்துவதாகும்.

ஒரே user-க்கு GPU VPS பயன்படுத்துவது பயனுள்ளதா?

பொதுவாக இல்லை. ஒருவர் வினாடிக்கு 5 முதல் 10 சொற்கள் மட்டுமே வாசிப்பார். சுமார் 13B வரையிலான model-களுக்கு CPU box ஏற்கனவே அதைவிட வேகமாக tokens-ஐ உருவாக்கும். ஒரே user-க்கு செலவை நியாயப்படுத்தக்கூடிய சூழல்கள் நீண்ட prompts, image generation மற்றும் fine-tuning ஆகும். ஒரே நேரத்தில் பல users-க்கு சேவை வழங்குவதே வலுவான காரணம். Batching மூலம், ஒரு GPU ஒரு request-க்கு பதிலளிக்கும் செலவுக்கு நெருக்கமாக இருபது requests-க்கு பதிலளிக்க முடியும்.

GPU-ஐ hourly-ஆக rent செய்வதா அல்லது எப்போதும் இயக்கத்தில் வைத்திருப்பதா?

வேலை bursty ஆக இருந்தால் hourly-ஆக rent செய்யவும். Fine-tuning, bulk embedding run அல்லது batch transcription job போன்றவை இதற்கான உதாரணங்கள். GPU instance tokens உருவாக்கியதற்காக அல்ல, இயங்கிக் கொண்டிருக்கும் நேரத்திற்காக billing செய்வதால், card தொடர்ந்து busy-ஆக இருக்கும் போது மட்டும் எப்போதும் இயக்கத்தில் வைக்கவும். குறைந்த traffic கொண்ட assistant-க்கு idle GPU-வை விட CPU VPS அல்லது token அடிப்படையில் கட்டணம் செலுத்தும் hosted API குறைந்த செலவாக இருக்கும்.