আপনার কি GPU-সহ VPS দরকার, নাকি CPU যথেষ্ট?

GPU-সহ VPS দরকার, নাকি CPU যথেষ্ট?

GPU-সহ VPS ব্যবহার করলে নিজে একটি model চালানোর ক্ষেত্রে 2টি বিষয় বদলে যায়: token কত দ্রুত তৈরি হয় এবং কোনো model আদৌ memory-তে কত বড় আকারে fit করে। অন্য কিছু বদলায় না। আপনার workload যদি একবারে 1 জনকে উত্তর দেওয়া quantized 7B থেকে 27B chat model, কম volume-এর embedding job, অথবা Whisper small দিয়ে speech transcription হয়, তাহলে পর্যাপ্ত RAM-সহ সাধারণ CPU VPS-ই কাজটি করতে পারে। CPU দিয়ে শুরু করুন, যে সংখ্যাটি আপনাকে সমস্যায় ফেলছে তা মাপুন, তারপর প্রয়োজন হলে বড় configuration-এ যান।

কারণটি হলো memory bandwidth। একটি language model 1টি token তৈরি করার সময় প্রয়োজনীয় সব weight memory থেকে পড়ে। 4 bits-এ quantized একটি 8B model disk-এ প্রায় 4.9 GB জায়গা নেয় এবং memory-তেও প্রায় একই পরিমাণ জায়গা লাগে। তাই 1টি token তৈরি করতে প্রায় 4.9 GB data স্থানান্তর করতে হয়। Machine-এর memory bandwidth-কে ওই সংখ্যা দিয়ে ভাগ করলে প্রতি second-এ token তৈরির সর্বোচ্চ সীমা পাওয়া যায়। আপনি যে প্রায় প্রতিটি benchmark পড়বেন, তার ব্যাখ্যা এই একটি ভাগেই রয়েছে।

GPU আসলে কী সুবিধা দেয়

Bandwidth। আধুনিক host-এর server DDR5 প্রতি সেকেন্ডে কয়েক দশ GB ডেটা সরাতে পারে। GPU memory (VRAM, video RAM) প্রতি সেকেন্ডে কয়েকশ থেকে এক হাজারেরও বেশি GB ডেটা সরাতে পারে। এই অনুপাতই speedup-এর মাত্রা, এবং এটি বড়।

Speed সহ capacity। 64 GB RAM-সহ একটি CPU box 4 bits-এ 70B model load করতে পারে। এটি চলবে, তবে chat করার চেয়ে পড়ার গতির কাছাকাছি গতিতে। এখানে GPU কেবল তখনই সাহায্য করে, যখন model-টি VRAM-এ ধরে। কারণ layers system RAM-এ spill করলেই ধীর path আবার কার্যকর হয়।

Batch throughput। এই বিষয়টিই অনেকে কম গুরুত্ব দেন। একটি GPU একজন user-এর জন্য generate করলে তার অধিকাংশ compute idle থাকে, কারণ এটি memory-এর জন্য অপেক্ষা করে। একসঙ্গে 20টি request serve করলে একই weight read সব 20টি request-এর জন্য ব্যবহৃত হয়। Aggregate tokens per second কয়েক গুণ বেড়ে যায়, অথচ প্রতি-user speed সামান্যই কমে। llama.cpp-এর মতো CPU inference engine-ও batching সমর্থন করে; লাভ hardware এবং workload-এর ওপর নির্ভর করে। আপনি যদি অনেক client-এর call গ্রহণ করে এমন একটি API তৈরি করেন, তাহলে raw single-stream speed-এর চেয়ে GPU ব্যবহারের পক্ষে batching-ই বেশি গুরুত্বপূর্ণ যুক্তি।

Prompt processing। দীর্ঘ prompt পড়া compute-bound, memory-bound নয়। এই কাজেই GPU সবচেয়ে বেশি ব্যবধানে এগিয়ে থাকে। CPU যে 30,000 token context এক মিনিটে process করে, GPU সেটি কয়েক সেকেন্ডে করতে পারে। প্রতিটি request-এ documents যুক্ত করা retrieval setup-এ এই পার্থক্যটি সব সময় স্পষ্ট হয়।

আনুমানিক সংখ্যা এবং সেগুলো কীভাবে বুঝবেন

প্রকৃত throughput ব্যান্ডউইথকে model size দিয়ে ভাগ করার হিসাবের চেয়েও কম হয়। কারণ context বড় হওয়ার সঙ্গে attention-এর জন্য অতিরিক্ত কাজ যোগ হয়, যা সরল ভাগের হিসাবটি বিবেচনা করে না।

তুলনার জন্য, ইংরেজিতে প্রাপ্তবয়স্কদের নীরবে পড়ার গড় গতি প্রতি সেকেন্ডে প্রায় 4.0 থেকে 4.3 শব্দ: non-fiction-এর ক্ষেত্রে প্রতি মিনিটে 238 শব্দ এবং fiction-এর ক্ষেত্রে 260 শব্দ। প্রতি সেকেন্ডে 15 tokens বা তার বেশি গতি একজন পাঠকের কাছে স্বাভাবিক typing-এর মতোই মনে হয়। এ কারণেই শুধু CPU ব্যবহার করা অনেক setup বাস্তবে কোনো সমস্যা ছাড়াই যথেষ্ট ভালো কাজ করে।

কেনার আগে VRAM-এর আকার নির্ধারণ

Model file-এর আকার হলো সর্বনিম্ন সীমা, প্রয়োজনীয় আকার নয়। Weights-এর জন্য বরাদ্দ রাখুন, এর সঙ্গে KV cache (key-value cache, attention যে প্রতি-token memory ধরে রাখে) এবং প্রায় 1 GB overhead যোগ করুন।

একটি নির্দিষ্ট শতাংশ যোগ না করে 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 memory লাগে: 8k context-এ প্রায় 1.07 GB এবং 16k-এ 2.15 GB। তাই 4.9 GB-এর 8B model-এর জন্য 8k-এ প্রায় 7 GB এবং 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 দরকার, অথবা দুটি ছোট card ব্যবহার করতে হবে। একই হিসাব এর চেয়েও বড় model-এর ক্ষেত্রেও প্রযোজ্য। Kimi K3-এর মতো 2.8 trillion parameter model-এর VRAM হিসাব দেখায়, কখন একটি card বেছে নেওয়াই আর মূল প্রশ্ন থাকে না।

Long context-এ এই বিষয়টি সবচেয়ে গুরুত্বপূর্ণ। Llama 3.1-এর মতো full-attention model-এ context length বাড়ার সঙ্গে KV cache linearly বাড়ে। 128k tokens-এ এটি weights-এর আকারকেও ছাড়িয়ে যেতে পারে। Sliding-window বা chunked attention ব্যবহার করা model আলাদা। Hugging Face-এর Transformers documentation-এ Mistral, Gemma 2 এবং Llama 4-এর উদাহরণ দেওয়া হয়েছে। এসব model-এ সংশ্লিষ্ট layer-এর cache window বা chunk size-এ পৌঁছালে আর বাড়ে না। তাই মোট memory ধীরে বাড়ে। Long context ব্যবহার করার পরিকল্পনা থাকলে প্রথমে cache-এর জন্য প্রয়োজনীয় memory নির্ধারণ করুন। আপনার engine cache quantization-এর জন্য কী সুবিধা দেয়, সেটিও যাচাই করুন। Ollama-তে OLLAMA_KV_CACHE_TYPE=q8_0 default f16-এর প্রায় অর্ধেক memory ব্যবহার করে। Flash Attention enabled থাকলেই cache quantization প্রযোজ্য হয়। Context length-ও স্পষ্টভাবে নির্ধারণ করুন। Ollama VRAM অনুযায়ী default বেছে নেয়: 24 GiB-এর নিচে 4k, 24 থেকে 48 GiB-এ 32k, এবং 48 GiB বা তার বেশি হলে 256k। 48 GB card-এ 70B model চালালে এই default card-এ থাকা memory-এর তুলনায় অনেক বেশি cache চায়।

মেশিনে আসলে কী আছে তা পরীক্ষা করুন

GPU instance-এ অন্য কিছু করার আগে driver card-টি শনাক্ত করছে কি না নিশ্চিত করুন।

nvidia-smi

এখানে GPU-এর নাম, driver version এবং মোট memory-এর মধ্যে কতটা ব্যবহৃত হয়েছে—এসবের একটি table দেখা উচিত। NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver দেখালে NVIDIA-SMI driver-এ পৌঁছাতে পারছে না; driver ইনস্টল করা আছে কি না এবং এর kernel module loaded কি না পরীক্ষা করুন। সাধারণ Ubuntu image-এ সমাধানটি সাধারণত sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install চালানো, তারপর reboot করা, যাতে নতুন module loaded হয়। Compute machine-এর জন্য Ubuntu-এর server documentation sudo ubuntu-drivers install --gpgpu ব্যবহারের পরামর্শ দেয়; এটি server driver branch নির্বাচন করে।

Container-এর ক্ষেত্রে শুধু driver যথেষ্ট নয়। Device 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-এর ভেতর থেকে pass through কাজ করছে কি না যাচাই করুন:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

একই table দেখা উচিত। কোনো GPU capability পূরণ করতে না পারা device-এর নাম উল্লেখ করা docker: Error response from daemon: could not select device driver line-এর অর্থ হলো Docker অনুরোধের সঙ্গে মেলে এমন device driver খুঁজে পায়নি; toolkit ইনস্টল করা আছে কি না পরীক্ষা করুন, তারপর nvidia-ctk line এবং restart আবার চালান। Compose-এ এর সমতুল্য হলো একটি deploy.resources.reservations.devices entry, যার driver হলো nvidia এবং যার capabilities list-এ gpu রয়েছে। এটি একটি VPS-এ Docker Compose-এ বর্ণিত সাধারণ service definition-এর সঙ্গে ব্যবহার করা যায়।

আপগ্রেডের আগে পরিমাপ করুন

আপনি যে মডেলটি ব্যবহার করতে চান, সেটিই আপনার বর্তমান CPU মেশিনে চালান এবং ফলাফল নথিবদ্ধ করুন। 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 হলো প্রতি সেকেন্ডে token তৈরির গতি। prompt eval rate হলো মেশিনটি আপনার input পড়ার গতি। এই দুটি সংখ্যা দেখেই বোঝা যায় কোন upgrade উপকারী হবে: eval rate কম হলে সমস্যা memory bandwidth-এ, আর দীর্ঘ input-এর ক্ষেত্রে prompt eval rate কম হলে সমস্যা compute ক্ষমতায়।

GPU থাকা মেশিনে মডেলটি সত্যিই GPU-তে লোড হয়েছে কি না পরীক্ষা করুন:

ollama ps

সবকিছু GPU memory-তে ধরে গেলে PROCESSOR column-এ 100% GPU দেখা যায়। তা না হলে 43%/57% CPU/GPU-এর মতো কিছু দেখা যায়। মডেলের একটি অংশ GPU-তে এবং বাকি অংশ CPU-তে ভাগ হয়ে গেলে ফল সাধারণত প্রত্যাশার চেয়ে খারাপ হয়, কারণ প্রতিটি token-কে ধীর অংশটির জন্যও অপেক্ষা করতে হয়।

খরচের প্রশ্ন

GPU instance-এর ক্ষেত্রে বিল provision করা compute time অনুযায়ী হয়, token অনুযায়ী নয়। Rate এবং stopped instance-এর charge provider নির্ধারণ করে। দিনে অল্প কয়েকটি request-এর জন্য সব সময় চালু রাখা GPU তার paid time-এর বেশিরভাগই idle অবস্থায় কাটায়। লাভজনকতার মূল বিষয় হল utilisation: ব্যস্ত GPU প্রতি token-এ সাশ্রয়ী, আর idle GPU সম্পূর্ণ অপচয়।

তিনটি বাস্তবসম্মত পদ্ধতি কার্যকর। নিয়মিত কম-volume-এর কাজ CPU VPS-এ চালান। মাঝে মাঝে আসা কঠিন request hosted API-তে পাঠিয়ে token অনুযায়ী মূল্য দিন। Batch job, fine-tuning বা bulk embedding run-এর জন্য ঘণ্টাভিত্তিক GPU ভাড়া নিন, কাজ শেষ হলে সেটি destroy করুন। এগুলো একসঙ্গে ব্যবহার করা স্বাভাবিক। সব সময় চালু থাকা VPS-এ AI agent-এর খরচ নিয়ন্ত্রণ-এ বর্ণিত budgeting discipline এখানেও প্রযোজ্য। পার্থক্য হল, এখানে token count নয়, idle time-ই মূল অপচয়।

GPU ছাড়াও যেগুলো ভালোভাবে চলে

কম ভলিউমে embeddings। একটি ছোট embedding model কয়েকটি CPU core ব্যবহার করে প্রতি মিনিটে শত শত সংক্ষিপ্ত document process করতে পারে। একবার তৈরি করা index দ্রুত হওয়া জরুরি নয়।

Transcription-এর জন্য Whisper small এবং base। CPU-তে Faster-whisper ছোট model-এর ক্ষেত্রে প্রায় real time-এ transcription করতে পারে। রাতভর চলা pipeline-এর জন্য এটি যথেষ্ট।

এক বা দুইজন user-এর জন্য প্রায় 27B পর্যন্ত quantized chat model। গতি কম, তবে ফল পড়া ও ব্যবহার করা যায়।

যেকোনো কাজকে batch job বলা যায়। কেউ যদি screen না দেখেন, তাহলে wall-clock speed একটি scheduling detail; এটি বাধ্যতামূলক requirement নয়।

যেসব কাজে বাস্তবে GPU প্রয়োজন: ছোট adapter-এর সীমার বাইরে training বা fine-tuning, একসঙ্গে অনেক user-কে service দেওয়া, image ও video generation, এবং real-time speech—যেখানে latency-ই মূল product।

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। 8k-এ KV cache প্রায় 1.07 GB এবং 16k-এ 2.15 GB যোগ করে। বাকি প্রায় 1 GB overhead-এর জন্য লাগে। 8 GB card-এ 8k context চলে, তবে 16k-এ সীমার কাছাকাছি থাকে। 12 GB card-এ দীর্ঘ context-এর জন্য স্বাচ্ছন্দ্যজনক অতিরিক্ত জায়গা থাকে। Cache-কে q8_0-এ পরিবর্তন করলে cache-এর ব্যবহার প্রায় অর্ধেক হয়। 128k context চালানোর পরিকল্পনা থাকলে cache-এর জন্য আলাদাভাবে capacity নির্ধারণ করুন, কারণ এটি weights-এর চেয়ে বড় হতে পারে।

GPU ছাড়া কি Ollama চালানো যায়?

হ্যাঁ। Ollama স্বয়ংক্রিয়ভাবে CPU ব্যবহার করে এবং model ধরে রাখার মতো RAM থাকলেই চলে। Memory speed অনুযায়ী 4-bit 8B model-এ প্রতি সেকেন্ডে প্রায় 5 থেকে 12টি token আশা করতে পারেন। একজন user-এর জন্য এটি পড়ার গতির কাছাকাছি। CPU-তে দীর্ঘ prompt-ই প্রধান সমস্যা। কারণ 30,000 token-এর context পড়া compute-bound এবং reply তৈরি করার চেয়ে অনেক বেশি সময় নেয়।

আমার GPU CPU-এর চেয়ে সামান্য দ্রুত কেন?

সাধারণ কারণ হলো model সম্পূর্ণভাবে VRAM-এ fit করেনি। ফলে কিছু layer CPU-তে চলে এবং প্রতিটি token ধীর অংশটির জন্য অপেক্ষা করে। ollama ps চালিয়ে PROCESSOR column-এ 100% GPU লেখা আছে কি না দেখুন। Split দেখা গেলে ছোট quantization বা ছোট model ব্যবহার করুন। আরেকটি সাধারণ কারণ হলো benchmark-এর সময় খুব কম হওয়া, যার ফলে model load করার সময়ই measurement-এ প্রাধান্য পায়।

একজন user-এর জন্য GPU VPS নেওয়া কি সার্থক?

সাধারণত নয়। English-এ প্রাপ্তবয়স্কদের নীরবে পড়ার গড় গতি প্রতি সেকেন্ডে প্রায় 4.0 থেকে 4.3টি শব্দ। CPU box-এর গতি ওই গতির সঙ্গে তুলনা করার আগে tokens per second-কে words per second-এ রূপান্তর করতে হবে। একজন user-এর ক্ষেত্রে খরচের যৌক্তিক কারণ হলো দীর্ঘ prompt, image generation এবং fine-tuning। একই সময়ে অনেক user-কে service দেওয়াই সবচেয়ে শক্তিশালী কারণ, কারণ batching একটি GPU-কে একাধিক request-এর মধ্যে weight read ভাগ করে নিতে দেয়।

GPU hourly ভাড়া নেব, নাকি সব সময় চালু রাখব?

কাজ যদি bursty হয়, যেমন fine-tuning, bulk embedding run বা batch transcription job, তাহলে hourly ভাড়া নিন। Card নিয়মিত ব্যস্ত থাকলেই কেবল সব সময় চালু রাখুন, কারণ provisioned GPU compute উৎপাদিত token-এর ভিত্তিতে নয়, ব্যবহৃত সময়ের ভিত্তিতে billing করে। কম traffic-এর assistant একটি CPU VPS বা token অনুযায়ী মূল্য নেওয়া hosted API-তে চালানো idle GPU-এর চেয়ে সস্তা।