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

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

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

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

একটি GPU বাস্তবে কী সুবিধা দেয়

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

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

Batch throughput। এই বিষয়টি মানুষ প্রায়ই অবমূল্যায়ন করে। একজন user-এর জন্য generate করার সময় একটি GPU-এর অধিকাংশ compute idle থাকে, কারণ এটি 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 সেটি কয়েক সেকেন্ডে process করতে পারে। প্রতিটি request-এর মধ্যে documents যুক্ত করা retrieval setup-এ এই পার্থক্যটি সব সময় স্পষ্ট হয়।

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

নিচের ব্লকে 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 সারিতে প্রতি সেকেন্ডে 50 tokens দেখানো হয়েছে, যেখানে DDR5 CPU box-এর ক্ষেত্রে মান 11। এটি আনুমানিক পাঁচ গুণ, যা raw compute-এর পার্থক্যের বদলে bandwidth ratio-এর সঙ্গে সামঞ্জস্যপূর্ণ। বাস্তব throughput bandwidth-কে model size দিয়ে ভাগ করলে যে মান পাওয়া যায়, তার চেয়েও কম হয়। কারণ context বড় হওয়ার সঙ্গে attention অতিরিক্ত কাজ যোগ করে, যা সরল ভাগের হিসাব উপেক্ষা করে।

তুলনার জন্য, একজন মানুষ প্রতি সেকেন্ডে প্রায় 5 থেকে 10টি শব্দ পড়েন। প্রতি সেকেন্ডে 15 বা তার বেশি tokens হলে একজন পাঠকের কাছে গতি ইতিমধ্যে স্বাভাবিক typing-এর মতো মনে হয়। তাই CPU-only অনেক setup নিঃশব্দে যথেষ্ট ভালো কাজ করে।

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

মডেল ফাইলের আকার হলো সর্বনিম্ন সীমা, প্রয়োজনীয় মোট পরিমাণ নয়। Weights, KV cache (key-value cache; attention যে প্রতি-token মেমরি ধরে রাখে), এবং অতিরিক্ত প্রায় 1 GB overhead-এর জন্য VRAM বরাদ্দ করুন।

July 2026 অনুযায়ী একটি ব্যবহারিক নিয়ম হলো: gigabytes-এ মডেল ফাইলের আকারের সঙ্গে সাধারণ 8k থেকে 16k context-এর জন্য 20 শতাংশ যোগ করুন। 4.7 GB-এর 8B মডেলের জন্য প্রায় 6 GB VRAM প্রয়োজন। 4 bits-এ 27B মডেলের আকার প্রায় 16 GB এবং এর জন্য আনুমানিক 20 GB প্রয়োজন। 4 bits-এ 70B মডেলের আকার প্রায় 40 GB; এর জন্য 48 GB-এর একটি card অথবা দুটি ছোট card প্রয়োজন।

দীর্ঘ context এই নিয়ম অকার্যকর করতে পারে। KV cache-এর আকার context length-এর সঙ্গে সরলরৈখিকভাবে বাড়ে এবং 128k tokens-এ এটি weights-এর আকারকেও ছাড়িয়ে যেতে পারে। দীর্ঘ context ব্যবহারের পরিকল্পনা থাকলে প্রথমে cache-এর জন্য প্রয়োজনীয় VRAM নির্ধারণ করুন এবং আপনার engine cache quantization-এর কী সুবিধা দেয় তা যাচাই করুন।

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

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

nvidia-smi

এখানে GPU-এর নাম, driver version এবং মোট memory-এর মধ্যে কতটা ব্যবহৃত হয়েছে—এসবের একটি table দেখতে পাবেন। NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver দেখালে driver অনুপস্থিত, অথবা kernel upgrade-এর পরে kernel module পুনর্নির্মিত হয়নি। সাধারণ Ubuntu image-এ সাধারণত sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install চালিয়ে সমস্যাটি ঠিক করা যায়। এরপর reboot করুন, যাতে নতুন module লোড হয়।

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 পূরণ করতে না পারার কথা উল্লেখ করা docker: Error response from daemon: could not select device driver line দেখালে 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 হলো tokens per second-এ generation speed। 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-এর মতো কিছু দেখা যায়। আংশিকভাবে ভাগ করা সাধারণত আপনার প্রত্যাশার চেয়ে খারাপ ফল দেয়, কারণ প্রতিটি token-কে এখনও ধীর অংশটির জন্য অপেক্ষা করতে হয়।

খরচের প্রশ্ন

GPU instance-এর খরচ তুলনীয় CPU instance-এর তুলনায় কয়েক গুণ বেশি। এগুলো উৎপন্ন token-এর জন্য নয়, চালু থাকা প্রতিটি ঘণ্টার জন্য বিল করে। প্রতিদিন অল্প কয়েকটি request পরিবেশন করা একটি সর্বদা চালু GPU-তে inference চালানোর সবচেয়ে ব্যয়বহুল পদ্ধতি। লাভ-ক্ষতির সীমা নির্ধারণ করে utilisation: ব্যস্ত GPU-তে প্রতি token-এর খরচ কম, আর নিষ্ক্রিয় GPU সম্পূর্ণ অপচয়।

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

GPU ছাড়াই যা ভালোভাবে চলে

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

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

এক বা দুইজন user-এর জন্য প্রায় 27B পর্যন্ত quantized chat model। ধীর, তবে পড়া যায় এবং ব্যবহারযোগ্য।

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

যে কাজগুলোর জন্য সত্যিই GPU প্রয়োজন: ছোট adapter-এর সীমার বাইরে training বা fine-tuning, একসঙ্গে অনেক user-কে serving করা, 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 কার্ডে দীর্ঘ context ব্যবহারের জন্য যথেষ্ট অতিরিক্ত জায়গা থাকে। 128k context চালানোর পরিকল্পনা থাকলে cache-এর আকার আলাদাভাবে নির্ধারণ করুন, কারণ এটি weights-এর চেয়ে বড় হতে পারে।

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

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

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

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

একজন ব্যবহারকারীর জন্য GPU VPS কি খরচসাপেক্ষভাবে উপযোগী?

সাধারণত নয়। একজন ব্যক্তি প্রতি সেকেন্ডে 5 থেকে 10 words পড়েন, এবং প্রায় 13B পর্যন্ত মডেলের জন্য CPU box ইতিমধ্যে তার চেয়ে দ্রুত tokens তৈরি করে। একজন ব্যবহারকারীর জন্য খরচটি যুক্তিসঙ্গত হওয়ার ক্ষেত্রগুলো হলো দীর্ঘ prompts, image generation এবং fine-tuning। একসঙ্গে অনেক ব্যবহারকারীকে service দেওয়াই সবচেয়ে শক্তিশালী কারণ, কারণ batching-এর মাধ্যমে একটি GPU একটি request-এর কাছাকাছি খরচে বিশটি requests-এর উত্তর দিতে পারে।

GPU ঘণ্টাভিত্তিক ভাড়া নেওয়া উচিত, নাকি সবসময় চালু রাখা উচিত?

কাজ অনিয়মিত হলে ঘণ্টাভিত্তিক ভাড়া নিন: fine-tuning, bulk embedding run অথবা batch transcription job-এর ক্ষেত্রে। GPU instance tokens তৈরি করার ভিত্তিতে নয়, চালু থাকার ভিত্তিতে billing করে। তাই card ব্যস্ত না থাকলে সবসময় চালু রাখবেন না। কম traffic-এর assistant-এর জন্য CPU VPS অথবা প্রতি token অনুযায়ী অর্থপ্রদত্ত hosted API, নিষ্ক্রিয় GPU-এর চেয়ে সস্তা।