GPU வசதி கொண்ட VPS எப்போது தேவை? முழுமையான விளக்கம்

உங்களுக்கு GPU வசதி கொண்ட VPS தேவையா அல்லது CPU போதுமானதா?

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

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

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

வேகத்துடன் கூடிய கொள்ளளவு. 64 GB RAM கொண்ட ஒரு CPU பெட்டியால் 4 bits-ல் ஒரு 70B மாதிரியை ஏற்ற முடியும். இது இயங்கும், ஆனால் உரையாடுவதை விட வாசிப்பதற்கேற்ற வேகத்தில் இருக்கும். மாதிரி VRAM-க்குள் அடங்கினால் மட்டுமே GPU உதவும், ஏனெனில் layers system RAM-க்குச் சென்றவுடன், மெதுவான பாதை மீண்டும் செயல்பாட்டுக்கு வந்துவிடும்.

Batch throughput (தொகுப்பு செயலாக்கம்). மக்கள் குறைவாக மதிப்பிடும் பகுதி இது. ஒரு பயனர் மட்டும் பயன்படுத்தும்போது, GPU-ன் பெரும்பாலான compute திறன் சும்மா இருக்கும், ஏனெனில் அது memory-க்காகக் காத்திருக்கிறது. ஒரே நேரத்தில் 20 கோரிக்கைகளைச் செயல்படுத்தினால், ஒரே weight read மூலம் 20 கோரிக்கைகளும் பூர்த்தி செய்யப்படும். ஒவ்வொரு பயனருக்கான வேகம் சிறிதளவே குறைந்தாலும், ஒட்டுமொத்த tokens per second பல மடங்கு உயரும். CPU-வால் இதைச் செய்ய முடியாது. ஒரு CPU பெட்டியில் இரண்டு பயனர்கள் ஒரே நேரத்தில் பயன்படுத்தினால், வேகம் பாதியாகக் குறையும். பல clients அழைக்கும் ஒரு API-ஐ நீங்கள் உருவாக்கினால், ஒற்றை stream வேகத்தை விட, batching வசதிக்காகவே GPU-ஐத் தேர்ந்தெடுக்க வேண்டும்.

Prompt processing (தூண்டுதல் செயலாக்கம்). நீண்ட prompt-ஐ வாசிப்பது memory-ஐச் சார்ந்ததல்ல, compute-ஐச் சார்ந்தது. இங்குதான் GPU-கள் மிகப்பெரிய வித்தியாசத்தை ஏற்படுத்துகின்றன. CPU ஒரு நிமிடத்தில் கையாளும் 30,000 token கொண்ட context-ஐ, GPU சில நொடிகளில் முடித்துவிடும். ஒவ்வொரு கோரிக்கையிலும் ஆவணங்களைச் சேர்க்கும் Retrieval setups-ல் இந்த வேகம் தொடர்ந்து உணரப்படும்.

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

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

ஒப்பீட்டளவில், ஒரு மனிதன் வினாடிக்கு சுமார் 5 முதல் 10 வார்த்தைகளை வாசிப்பான். வினாடிக்கு 15 tokens அல்லது அதற்கு மேல் இருந்தால், அது ஒரு வாசகருக்கு இயல்பான தட்டச்சு வேகத்தைப் போன்ற உணர்வைத் தரும். இதனால்தான் பல CPU-மட்டும் கொண்ட அமைப்புகள் எந்தப் புகாருமின்றி சிறப்பாகச் செயல்படுகின்றன.

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

Model கோப்பின் அளவு என்பது குறைந்தபட்சத் தேவையே தவிர, அதுவே முழுமையான தேவை அல்ல. Model weights, KV cache (ஒவ்வொரு token-க்கும் attention முறை பயன்படுத்தும் நினைவகம்), மற்றும் சுமார் 1 GB மேலதிக நினைவகம் ஆகியவற்றை உள்ளடக்கித் திட்டமிட வேண்டும்.

ஜூலை 2026 நிலவரப்படி ஒரு நடைமுறை விதி: model கோப்பின் அளவை gigabytes-ல் எடுத்துக்கொண்டு, 8k முதல் 16k வரையிலான சாதாரண context-க்கு 20 சதவீதத்தை அதனுடன் கூட்டிக்கொள்ள வேண்டும். ஒரு 4.7 GB அளவுள்ள 8B model-க்கு சுமார் 6 GB VRAM தேவைப்படும். 4 bits-ல் உள்ள ஒரு 27B model சுமார் 16 GB இருக்கும், அதற்கு ஏறத்தாழ 20 GB VRAM தேவைப்படும். 4 bits-ல் உள்ள ஒரு 70B model சுமார் 40 GB இருக்கும், அதற்கு 48 GB கார்டு அல்லது இரண்டு சிறிய கார்டுகள் தேவைப்படும். இதே கணக்கீடு இதற்கு மேலான அளவுகளுக்கும் பொருந்தும், மேலும் Kimi K3 போன்ற 2.8 டிரில்லியன் அளவுருக்கள் கொண்ட model-க்கான VRAM கணக்கீடு எப்போது கார்டு தேர்வு செய்வது என்பது ஒரு பொருட்டல்ல என்பதை உணர்த்துகிறது.

நீண்ட context-கள் இந்த விதியை மாற்றும். KV cache-ன் அளவு context நீளத்திற்கு ஏற்ப நேரியல் முறையில் (linearly) அதிகரிக்கும். 128k tokens அளவில், இது model weights-ன் அளவையே மிஞ்சக்கூடும். நீங்கள் நீண்ட context-களைப் பயன்படுத்தத் திட்டமிட்டால், முதலில் cache-க்கான அளவைத் தீர்மானியுங்கள்; உங்கள் engine-ல் cache quantization வசதி உள்ளதா என்பதைச் சரிபாருங்கள்.

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

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

nvidia-smi

GPU பெயர், driver பதிப்பு, மற்றும் மொத்த நினைவகத்தில் பயன்படுத்தப்பட்ட அளவு ஆகியவற்றைக் காட்டும் அட்டவணை உங்களுக்குத் தேவை. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver என்பது driver விடுபட்டுள்ளது அல்லது kernel மேம்படுத்தலுக்குப் பிறகு kernel module மீண்டும் உருவாக்கப்படவில்லை என்பதைக் குறிக்கிறது. ஒரு சாதாரண Ubuntu image-ல், இதற்குத் தீர்வாக பொதுவாக sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install-ஐப் பயன்படுத்த வேண்டும், பின்னர் புதிய module ஏற்றப்படுவதற்கு கணினியை reboot செய்ய வேண்டும்.

Containers-க்கு, driver மட்டும் போதாது. Device-ஐ உள்ளே கொண்டு செல்ல (passthrough) 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

அதே அட்டவணை தோன்ற வேண்டும். ஒரு docker: Error response from daemon: could not select device driver வரியானது, பூர்த்தி செய்ய முடியாத ஒரு gpu capability-ஐக் குறிப்பிடுகிறது என்றால், toolkit நிறுவப்பட்டும் Docker மீண்டும் கட்டமைக்கப்படவில்லை அல்லது restart செய்யப்படவில்லை என்று அர்த்தம். எனவே, nvidia-ctk வரியை மீண்டும் இயக்கி, restart செய்யவும். Compose-ல் இதற்கு இணையானது ஒரு deploy.resources.reservations.devices உள்ளீடு ஆகும், அதன் driver என்பது nvidia மற்றும் அதன் capabilities பட்டியலில் gpu இருக்க வேண்டும். இது Docker Compose on a VPS-ல் விவரிக்கப்பட்டுள்ள சாதாரண service வரையறைகளுக்குள் அமையும்.

மேம்படுத்துவதற்கு முன் அளவீடு செய்யுங்கள்

நீங்கள் பயன்படுத்த விரும்பும் மாதிரியை (model), உங்களிடம் ஏற்கனவே உள்ள CPU கணினியில் இயக்கி, அதன் முடிவுகளைப் பதிவு செய்யுங்கள். Ollama self-hosting an LLM on a VPS மூலம் இதைச் செய்ய ஒரு flag போதுமானது:

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

வெளியீட்டின் இறுதியில் நேர அளவீடுகள் இருக்கும். eval rate என்பது ஒரு வினாடிக்கு எத்தனை tokens உருவாக்கப்படுகின்றன என்பதைக் குறிக்கும் வேகம். prompt eval rate என்பது உங்கள் உள்ளீட்டை அந்த இயந்திரம் எவ்வளவு வேகமாக வாசித்தது என்பதைக் குறிக்கும். இந்த இரண்டு எண்களும் எந்த மேம்பாடு உங்களுக்கு உதவும் என்பதைத் தெரிவிக்கும்: eval rate குறைவாக இருந்தால் அது memory-bandwidth தொடர்பான சிக்கல்; நீண்ட உள்ளீடுகளுக்கு prompt eval rate குறைவாக இருந்தால் அது compute தொடர்பான சிக்கல்.

GPU உள்ள இயந்திரத்தில், மாதிரி (model) சரியாக GPU-வில் பதிவேறியுள்ளதா என்பதைச் சரிபார்க்கவும்:

ollama ps

அனைத்தும் சரியாகப் பொருந்தினால் PROCESSOR நெடுவரிசையில் 100% GPU என்று காட்டும், இல்லையெனில் 43%/57% CPU/GPU போன்ற மதிப்பைக் காட்டும். மாதிரி பகுதியளவு பிரிந்திருந்தால் (partial split), அது நீங்கள் எதிர்பார்ப்பதை விட மோசமான செயல்திறனையே தரும்; ஏனெனில் ஒவ்வொரு token-ம் மெதுவான பகுதியின் பதிலுக்காகக் காத்திருக்க வேண்டியிருக்கும்.

செலவு குறித்த கேள்வி

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

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

GPU இன்றி சிறப்பாக இயங்கும் பணிகள்

குறைந்த அளவிலான Embeddings. ஒரு சிறிய embedding model சில CPU cores-களைப் பயன்படுத்தி நிமிடத்திற்கு நூற்றுக்கணக்கான சிறிய ஆவணங்களைச் செயலாக்கும். நீங்கள் ஒருமுறை உருவாக்கும் index-க்கு அதிக வேகம் தேவையில்லை.

Transcription-க்கு Whisper small மற்றும் base மாதிரிகள். CPU-வில் இயங்கும் Faster-whisper, small மாதிரியைப் பயன்படுத்தி கிட்டத்தட்ட நிகழ்நேரத்தில் (near real time) transcription செய்கிறது. இது இரவு நேரத்தில் இயங்கும் pipeline-க்கு போதுமானது.

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

Batch job என்று அழைக்கப்படும் எந்தவொரு பணியும். திரையைப் பார்த்து யாரும் காத்திருக்கவில்லை என்றால், அதன் செயலாக்க வேகம் (wall-clock speed) ஒரு கால அட்டவணை சார்ந்த விவரமே தவிர, அது ஒரு கட்டாயத் தேவை அல்ல.

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

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

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

எனது GPU ஏன் CPU-வை விட வேகமாக இல்லை?

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

ஒரு தனிப் பயனருக்கு GPU VPS அவசியமா?

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

நான் GPU-வை மணிநேர அடிப்படையில் வாடகைக்கு எடுக்க வேண்டுமா அல்லது எப்போதும் இயங்க வைக்க வேண்டுமா?

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