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

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

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

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

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

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

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

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

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

மாதிரி அளவால் (model size) அலைவரிசையை (bandwidth) வகுக்கும்போது கிடைக்கும் மதிப்பை விட, உண்மையான throughput குறைவாகவே இருக்கும். ஏனெனில், வளரும் context-ல் attention செயல்பாட்டிற்கு கூடுதல் பணி தேவைப்படுகிறது, இதை எளிய வகுத்தல் முறை கணக்கில் கொள்வதில்லை.

ஒப்பீட்டிற்காக, ஆங்கிலத்தில் சத்தமில்லாமல் வாசிக்கும் ஒரு முதிர்ந்த நபர் வினாடிக்கு சராசரியாக 4.0 முதல் 4.3 சொற்களை வாசிக்கிறார்: இது non-fiction நூல்களுக்கு நிமிடத்திற்கு 238 சொற்கள் மற்றும் fiction நூல்களுக்கு 260 சொற்கள் ஆகும். வினாடிக்கு 15 tokens அல்லது அதற்கு மேல் வேகம் இருந்தால், அது ஒரு வாசகருக்கு இயல்பான தட்டச்சு வேகத்தைப் போலவே உணரப்படும். இதனால்தான் பல CPU-மட்டும் கொண்ட அமைப்புகள் (CPU-only setups) எந்தப் புகாருமின்றிச் சிறப்பாகச் செயல்படுகின்றன.

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

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

Weights-ஐ quantize செய்தாலும் cache-ஐ quantize செய்ய முடியாது என்பதால், ஒரு குறிப்பிட்ட சதவீதத்தை மட்டும் கணக்கிடாமல், cache-ன் அளவை முறையாகக் கணக்கிட வேண்டும். ஒவ்வொரு token-க்கும், full-attention model-ஆனது ஒவ்வொரு layer மற்றும் ஒவ்வொரு KV head-க்கும் key மற்றும் value-ஐச் சேமிக்கும். Ollama-வின் default cache type-ஆன FP16-ல், ஒரு எண்ணிற்கு 2 bytes தேவைப்படும். 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 context-க்கு 2.15 GB. எனவே, 4.9 GB அளவுள்ள 8B model-க்கு 8k context-ல் சுமார் 7 GB VRAM-ம், 16k context-ல் சுமார் 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 அல்லது அதற்கு மேல் திட்டமிடுங்கள். 4 bits-ல் உள்ள 70B model சுமார் 43 GB (Llama 3.3 70B) ஆகும். 80 layers கொண்ட இதில், FP16 cache 8k context-க்கு சுமார் 2.7 GB-யையும், 16k context-க்கு 5.4 GB-யையும் சேர்க்கிறது. எனவே, இதற்கு 48 GB card தேவைப்படும், அதில் மிகக் குறைந்த இடமே மீதமிருக்கும், அல்லது இரண்டு சிறிய cards-ஐப் பயன்படுத்தலாம். இதே கணக்கீடு பெரிய அளவுகளுக்கும் பொருந்தும், மேலும் Kimi K3 போன்ற 2.8 trillion parameter model-க்கான VRAM கணக்கீடு ஒரு card-ஐத் தேர்ந்தெடுப்பது எப்போது தேவையற்றதாகிறது என்பதைக் காட்டுகிறது.

நீண்ட context-களைப் பயன்படுத்தும்போதே இது மிக முக்கியமாகிறது. Llama 3.1 போன்ற full-attention model-களில், KV cache-ஆனது context நீளத்திற்கு ஏற்ப நேரியல் முறையில் (linearly) வளர்கிறது. 128k tokens-ல் இது weights-ன் அளவை விட அதிகமாகலாம். Sliding-window அல்லது chunked attention கொண்ட model-கள் மாறுபட்டவை: Hugging Face-ன் Transformers ஆவணங்கள் Mistral, Gemma 2 மற்றும் Llama 4 ஆகியவற்றை இதற்கு உதாரணமாகக் குறிப்பிடுகின்றன. இவற்றில் குறிப்பிட்ட layer-களின் cache, window அல்லது chunk அளவை எட்டியதும் வளர்வது நின்றுவிடும், எனவே இவற்றின் மொத்த அளவு மெதுவாகவே அதிகரிக்கும். நீங்கள் நீண்ட context-களைப் பயன்படுத்தத் திட்டமிட்டால், முதலில் cache-க்கு முன்னுரிமை அளித்து, உங்கள் engine வழங்கும் cache quantization வசதிகளைச் சரிபார்க்கவும். Ollama-வில், OLLAMA_KV_CACHE_TYPE=q8_0 ஆனது default f16-ஐ விட பாதி நினைவகத்தையே பயன்படுத்துகிறது, மேலும் Flash Attention இயக்கப்பட்டிருக்கும்போது மட்டுமே cache quantization செயல்படும். Context நீளத்தை நீங்களே நேரடியாக அமைக்கவும். Ollama தனது default அளவை VRAM-ஐப் பொறுத்துத் தீர்மானிக்கிறது: 24 GiB-க்குக் கீழ் 4k, 24 முதல் 48 GiB வரை 32k, மற்றும் 48 GiB அல்லது அதற்கு மேல் 256k. 48 GB card-ல் 70B model-ஐ இயக்கும்போது, இந்த default அமைப்பு card-ன் கொள்ளளவை விட அதிக cache-ஐக் கேட்கும்.

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

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

nvidia-smi

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

Containers-க்கு, driver மட்டும் போதாது. சாதனத்தை (device) உள்ளே கொண்டு செல்ல 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 திறனைக் குறிப்பிடுகிறது என்றால், கோரப்பட்ட சாதன driver-ஐ Docker-ஆல் கண்டறிய முடியவில்லை என்று பொருள்; toolkit நிறுவப்பட்டுள்ளதா என்பதைச் சரிபார்த்து, பின் nvidia-ctk வரியை மீண்டும் இயக்கி, restart செய்யவும். Compose-ல் இதற்கு இணையானது ஒரு deploy.resources.reservations.devices உள்ளீடு ஆகும், அதன் driver என்பது nvidia மற்றும் அதன் திறன்கள் பட்டியலில் gpu இருக்கும், இது Docker Compose on a VPS-ல் விவரிக்கப்பட்டுள்ள சாதாரண service வரையறைகளுக்குள் பொருந்தும்.

மேம்படுத்துவதற்கு முன் அளவிடுங்கள்

நீங்கள் பயன்படுத்த விரும்பும் மாதிரியை, உங்களிடம் ஏற்கனவே உள்ள 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 per second-ல் உங்கள் generation வேகம். prompt eval rate என்பது உங்கள் உள்ளீட்டை இயந்திரம் எவ்வளவு வேகமாக வாசித்தது என்பதைக் குறிக்கும். இந்த இரண்டு எண்களும் எந்த மேம்பாடு உதவும் என்பதைத் தெரிவிக்கும்: குறைந்த eval rate என்பது memory-bandwidth சிக்கல், நீண்ட உள்ளீடுகளில் குறைந்த prompt eval rate என்பது compute சிக்கல்.

GPU உள்ள இயந்திரத்தில், மாதிரி உண்மையில் அதில் பதிந்துள்ளதா என்பதைச் சரிபார்க்கவும்:

ollama ps

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

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

GPU instances, token-களின் அடிப்படையில் அல்லாமல், ஒதுக்கப்பட்ட compute time-ன் அடிப்படையில் கட்டணம் வசூலிக்கின்றன. இதற்கான கட்டணங்கள் மற்றும் நிறுத்தப்பட்ட instances-க்கான கட்டணங்கள் அந்தந்த provider-ஆல் நிர்ணயிக்கப்படுகின்றன. ஒரு GPU எப்போதும் இயங்கிக்கொண்டிருந்து, ஒரு நாளில் சில கோரிக்கைகளை (requests) மட்டுமே கையாண்டால், அது பணம் செலுத்தப்பட்ட நேரத்தின் பெரும்பகுதியை வீணாக்குகிறது. இதன் லாப-நட்ட சமநிலை (break-even) பயன்பாட்டைப் பொறுத்தது: அதிக பயன்பாட்டில் உள்ள GPU, token ஒன்றுக்கு குறைந்த செலவையே தருகிறது; ஆனால், பயன்பாடின்றி இருக்கும் GPU முழுமையான இழப்பாகும்.

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

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 மாதிரிக்கு எனக்கு எவ்வளவு VRAM தேவை?

Ollama-வின் இயல்புநிலை FP16 cache-உடன், 8k context-ல் 4-bit quantized 8B மாதிரிக்கு சுமார் 7 GB மற்றும் 16k-ல் சுமார் 8 GB தேவைப்படும். எடைகள் (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-ன் பங்கு தோராயமாக பாதியாகக் குறையும். நீங்கள் 128k context-ல் இயக்கத் திட்டமிட்டால், cache-க்குத் தனியாக இட ஒதுக்கீடு செய்யவும், ஏனெனில் அது எடைகளை விடப் பெரியதாக வளரக்கூடும்.

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

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

எனது GPU ஏன் CPU-வை விட மிகச் சிறிதளவே வேகமாக உள்ளது?

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

ஒரு பயனர் மட்டும் பயன்படுத்தும் போது GPU VPS வாங்குவது பயனுள்ளதா?

பொதுவாக இல்லை. ஆங்கிலத்தில் பெரியவர்கள் அமைதியாகப் படிக்கும் வேகம் வினாடிக்கு சுமார் 4.0 முதல் 4.3 சொற்கள் ஆகும், மேலும் CPU பெட்டியின் வேகத்தை இதனுடன் ஒப்பிடும் முன் tokens per second-ஐ சொற்களாக மாற்ற வேண்டும். நீண்ட prompts, பட உருவாக்கம் (image generation), மற்றும் fine-tuning ஆகியவற்றுக்காக மட்டுமே ஒரு பயனர் இந்தச் செலவை நியாயப்படுத்த முடியும். ஒரே நேரத்தில் பல பயனர்களுக்குச் சேவை செய்வதுதான் வலுவான வாதம், ஏனெனில் batching மூலம் ஒரு GPU பல கோரிக்கைகளுக்கு இடையே எடைகளை (weights) பகிர்ந்து கொள்ள முடியும்.

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

Fine-tuning, மொத்தமாக embedding செய்தல், அல்லது batch transcription போன்ற வேலைகள் அவ்வப்போது இருந்தால் மணிநேர அடிப்படையில் வாடகைக்கு எடுக்கவும். கார்டு எப்போதும் பிஸியாக இருந்தால் மட்டுமே எப்போதும் இயங்க வைக்கவும், ஏனெனில் provisioned GPU compute என்பது உருவாக்கப்பட்ட tokens-க்கு அல்லாமல் நேரத்திற்குத்தான் கட்டணம் வசூலிக்கிறது. குறைந்த போக்குவரத்து கொண்ட assistant-க்கு, idle-ல் இருக்கும் GPU-வை விட CPU VPS அல்லது token அடிப்படையில் கட்டணம் வசூலிக்கும் hosted API மலிவானது.