দ্বারা আপনার কি GPU-সহ VPS দরকার, নাকি CPU যথেষ্ট?
GPU VPS batch কাজের গতি ও বড় model-এর জন্য বেশি memory দেয়। তবে quantized chat model, embeddings ও Whisper small CPU-তেই চলে। আগে মেপে সিদ্ধান্ত নিন।
আপনার কি GPU-সহ VPS দরকার, নাকি CPU যথেষ্ট?
GPU-সহ VPS নিজে কোনো model চালানোর ক্ষেত্রে দুটি বিষয় পরিবর্তন করে: token কত দ্রুত তৈরি হয় এবং memory-তে আদৌ কত বড় model রাখা যায়। এটি আর কিছু পরিবর্তন করে না। আপনার workload যদি quantized 7B থেকে 27B chat model দিয়ে এক সময়ে একজনকে উত্তর দেওয়া, কম volume-এর embedding job, অথবা Whisper small দিয়ে speech transcription হয়, তাহলে পর্যাপ্ত RAM-সহ সাধারণ CPU VPS-ই কাজটি করতে পারে। CPU দিয়ে শুরু করুন, যে performance সংখ্যা আপনাকে সমস্যায় ফেলছে তা মাপুন, তারপর প্রয়োজন হলে উন্নত hardware-এ যান।
কারণটি হলো memory bandwidth। একটি language model যখন একটি token তৈরি করে, তখন তার প্রয়োজনীয় প্রতিটি weight memory থেকে পড়ে। 4 bits-এ quantized একটি 8B model-এর আকার disk-এ প্রায় 4.7 GB এবং memory-তেও প্রায় একই, তাই একটি token তৈরি করতে প্রায় 4.7 GB data স্থানান্তর করতে হয়। মেশিনের memory bandwidth-কে ওই সংখ্যা দিয়ে ভাগ করলে প্রতি সেকেন্ডে token-এর সর্বোচ্চ সীমা পাওয়া যায়। এই একটিমাত্র ভাগই আপনি পড়তে যাওয়া প্রায় প্রতিটি benchmark-এর ব্যাখ্যা দেয়।
একটি GPU আসলে কী সুবিধা দেয়
Bandwidth। আধুনিক host-এর server DDR5 প্রতি সেকেন্ডে কয়েক দশ গিগাবাইট ডেটা স্থানান্তর করে। GPU memory (VRAM, video RAM) প্রতি সেকেন্ডে কয়েক শত থেকে এক হাজারেরও বেশি গিগাবাইট ডেটা স্থানান্তর করে। এই অনুপাতই speedup, এবং এটি বড়।
Capacity with speed। 64 GB RAM-যুক্ত একটি CPU box 4 bits-এ 70B model load করতে পারে। এটি চলবে, তবে chat করার গতির চেয়ে পড়ার গতির কাছাকাছি। এখানে GPU তখনই সাহায্য করে যখন model-টি VRAM-এ fit করে, কারণ layers system RAM-এ spill হওয়ার সঙ্গে সঙ্গে slow path আবার নিয়ন্ত্রণ নেয়।
Batch throughput। মানুষ এই বিষয়টি প্রায়ই কম গুরুত্ব দেয়। একজন user-এর জন্য GPU generate করলে তার অধিকাংশ compute idle থাকে, কারণ GPU memory-এর জন্য অপেক্ষা করে। একসঙ্গে 20টি request serve করলে একই weight read সব 20টি request-এর কাজে লাগে। Aggregate tokens per second কয়েক গুণ বেড়ে যায়, অথচ প্রতি user-এর speed খুব সামান্য কমে। CPU এভাবে কাজ করে না। CPU box-এ দুইজন concurrent user সাধারণত একে অপরের speed প্রায় অর্ধেক করে দেয়। আপনি যদি এমন একটি API তৈরি করেন যেটিতে অনেক client call করে, তাহলে raw single-stream speed-এর চেয়ে batching-ই GPU ব্যবহারের বড় কারণ।
Prompt processing। দীর্ঘ prompt পড়া compute-bound, memory-bound নয়। এই কাজেই GPU সবচেয়ে বেশি ব্যবধানে এগিয়ে থাকে। CPU যে 30,000 token context process করতে এক মিনিট নেয়, GPU সেটি কয়েক সেকেন্ডে করতে পারে। প্রতিটি request-এর মধ্যে documents যুক্ত করা retrieval setup-এ এই পার্থক্যটি নিয়মিতই বোঝা যায়।
আনুমানিক সংখ্যা এবং সেগুলো কীভাবে পড়বেন
নিচের ব্লকে July 2026 অনুযায়ী 4-bit quantization-এ 8B model-এর single-stream ব্যবহারের জন্য প্রকাশিত সাধারণ পরিসংখ্যান দেওয়া হয়েছে। এগুলো order-of-magnitude নির্দেশনা, কোনো নিশ্চয়তা নয়। আপনার quantization, context length এবং inference engine অনুযায়ী সংখ্যাগুলো পরিবর্তিত হবে।
The data behind this chart
[
{
"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 per second দেখানো হয়েছে, যেখানে DDR5 CPU box-এর ক্ষেত্রে সংখ্যা 11। এটি মোটামুটি পাঁচ গুণ, যা raw compute-এর পার্থক্যের চেয়ে memory bandwidth ratio-এর সঙ্গে বেশি সামঞ্জস্যপূর্ণ। প্রকৃত throughput সাধারণত bandwidth-কে model size দিয়ে ভাগ করলে যে ফল পাওয়া যায়, তার চেয়ে কম হয়। কারণ context বাড়ার সঙ্গে attention-এর জন্য অতিরিক্ত কাজ লাগে, যা এই সরল ভাগে ধরা হয় না।
তুলনার জন্য, একজন মানুষ প্রতি সেকেন্ডে প্রায় 5 থেকে 10টি শব্দ পড়েন। 15 tokens per second বা তার বেশি গতি একজন পাঠকের কাছে স্বাভাবিক typing-এর মতোই মনে হয়। এ কারণেই CPU-only setup-এর অনেকগুলো বাস্তবে যথেষ্ট ভালোভাবে কাজ করে।
কেনার আগে VRAM-এর আকার নির্ধারণ করুন
Model file-এর আকার হলো ন্যূনতম ভিত্তি, প্রয়োজনীয় মোট পরিমাণ নয়। Weights, KV cache (key-value cache, attention যে প্রতি-token memory ধরে রাখে) এবং overhead হিসেবে প্রায় 1 GB—সবকিছুর জন্য VRAM বরাদ্দ করুন।
July 2026 অনুযায়ী একটি ব্যবহারিক নিয়ম হলো: gigabytes-এ model file-এর আকার নিন এবং সাধারণ 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 অথবা দুটি ছোট card প্রয়োজন। এর চেয়ে বড় model-এর ক্ষেত্রেও একই হিসাব কার্যকর থাকে। Kimi K3-এর মতো 2.8 trillion parameter model-এর VRAM হিসাব দেখায়, কোন পর্যায়ে card বাছাই করাই আর মূল প্রশ্ন থাকে না।
দীর্ঘ context এই নিয়মকে অকার্যকর করে। Context length বাড়ার সঙ্গে KV cache সরলরেখায় বৃদ্ধি পায়, এবং 128k tokens-এ এটি weights-এর আকারকেও ছাড়িয়ে যেতে পারে। দীর্ঘ context ব্যবহারের পরিকল্পনা থাকলে প্রথমে cache-এর জন্য প্রয়োজনীয় VRAM নির্ধারণ করুন এবং আপনার engine cache quantization-এর জন্য কী সুবিধা দেয় তা যাচাই করুন।
মেশিনে বাস্তবে কী আছে তা পরীক্ষা করুন
GPU instance-এ অন্য কিছু করার আগে driver card-টি শনাক্ত করছে কি না নিশ্চিত করুন।
nvidia-smiএখানে GPU-এর নাম, 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 হয়।
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 আবার দেখা উচিত। docker: Error response from daemon: could not select device driver line-এ এমন একটি gpu capability-এর নাম থাকলে যা এটি পূরণ করতে পারে না, তার অর্থ toolkit installed আছে, কিন্তু Docker reconfigure বা restart করা হয়নি। তাই 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-এর খরচ তুলনীয় CPU instance-এর চেয়ে কয়েক গুণ বেশি। এগুলোর বিল token উৎপাদনের ভিত্তিতে নয়, instance যত ঘণ্টা চালু থাকে সেই সময়ের ভিত্তিতে হয়। দিনে অল্প কয়েকটি অনুরোধ পরিবেশন করা একটি সবসময় চালু GPU-তে inference চালানোর সবচেয়ে ব্যয়বহুল পদ্ধতি। লাভ-ক্ষতির সীমা নির্ধারণ করে utilisation। ব্যস্ত GPU-তে প্রতি token-এর খরচ কম, আর নিষ্ক্রিয় GPU সম্পূর্ণ অপচয়।
তিনটি বাস্তবসম্মত পদ্ধতি কার্যকর। নিয়মিত কম-volume-এর কাজ CPU VPS-এ চালান। মাঝে মাঝে আসা জটিল অনুরোধ hosted API-তে পাঠিয়ে প্রতি token অনুযায়ী অর্থ পরিশোধ করুন। batch job, fine-tuning বা bulk embedding run-এর জন্য ঘণ্টাভিত্তিক GPU rent করুন, কাজ শেষে সেটি 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 মডেলের জন্য কত 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-এর জন্য আলাদাভাবে capacity নির্ধারণ করুন, কারণ এটি weights-এর চেয়ে বড় হতে পারে।
GPU ছাড়া কি Ollama চালানো যায়?
হ্যাঁ। Ollama স্বয়ংক্রিয়ভাবে CPU ব্যবহার করে এবং মডেলটি ধরে রাখার জন্য যথেষ্ট RAM প্রয়োজন। memory speed অনুযায়ী 4-bit 8B মডেলের ক্ষেত্রে প্রতি সেকেন্ডে প্রায় 5 থেকে 12টি token পাওয়ার আশা করুন। একজন user-এর জন্য এটি পড়ার গতির কাছাকাছি। CPU-তে দীর্ঘ prompt-ই মূল সমস্যা, কারণ 30,000 token-এর context পড়া compute-bound এবং উত্তরের generation-এর তুলনায় অনেক বেশি সময় নেয়।
আমার GPU CPU-এর চেয়ে সামান্য দ্রুত কেন?
সাধারণ কারণ হলো, মডেলটি সম্পূর্ণভাবে VRAM-এ fit করেনি। তাই কিছু layer CPU-তে চলে এবং প্রতিটি token ধীর অংশটির জন্য অপেক্ষা করে। ollama ps চালিয়ে দেখুন PROCESSOR column-এ 100% GPU লেখা আছে কি না। split দেখা গেলে ছোট quantization বা ছোট মডেল ব্যবহার করুন। আরেকটি সাধারণ কারণ হলো benchmark-এর সময় কম হওয়া, যার ফলে measurement-এ model load time-এর প্রভাব বেশি পড়ে।
একজন user-এর জন্য GPU VPS কি খরচসাপেক্ষভাবে যুক্তিযুক্ত?
সাধারণত নয়। একজন ব্যক্তি প্রতি সেকেন্ডে 5 থেকে 10টি word পড়েন, আর প্রায় 13B পর্যন্ত মডেলের ক্ষেত্রে CPU box ইতিমধ্যেই তার চেয়ে দ্রুত token তৈরি করে। একজন user-এর জন্য খরচের যৌক্তিকতা তৈরি করে এমন কাজ হলো দীর্ঘ prompt, image generation এবং fine-tuning। একই সময়ে অনেক user-কে service দেওয়াই সবচেয়ে শক্তিশালী কারণ, কারণ batching-এর মাধ্যমে একটি GPU প্রায় একজনকে উত্তর দেওয়ার খরচেই বিশটি request-এর উত্তর দিতে পারে।
GPU hourly ভাড়া নেওয়া উচিত, নাকি একটি GPU সবসময় চালু রাখা উচিত?
কাজ যদি bursty হয়, যেমন fine-tuning, bulk embedding run বা batch transcription job, তাহলে hourly ভাড়া নিন। GPU সবসময় চালু রাখুন কেবল card-টি নিয়মিত ব্যস্ত থাকলে, কারণ GPU instance token তৈরি করার ভিত্তিতে নয়, চালু থাকা সময়ের ভিত্তিতে bill করে। কম traffic-এর assistant-এর জন্য idle GPU-এর চেয়ে CPU VPS বা token অনুযায়ী মূল্য নেওয়া hosted API সস্তা।