কত RAM-এ কোন AI model self-host করা যায়

কোন বিষয় নির্ধারণ করে আপনি কোন AI model self-host করতে পারবেন

আপনি কোন AI model self-host করতে পারবেন, তা একটি বিষয়ের ওপর নির্ভর করে: সার্ভারের RAM। Model family এবং framework-এর গুরুত্ব এর তুলনায় অনেক কম। মূল বিষয় হলো, অতিরিক্ত কিছু memory অবশিষ্ট রেখে model-এর weights RAM-এ fit করে কি না। এটি হিসাব করার পদ্ধতি এই পোস্টে দেখানো হয়েছে। Runtime install করা আলাদা কাজ। এর জন্য VPS-এ Ollama চালানোর guide দেখুন।

দুটি খরচ এই সিদ্ধান্ত নির্ধারণ করে। Weights হলো স্থির খরচ। এটি parameter count এবং quantisation দ্বারা নির্ধারিত হয়। Context window হলো চলমান খরচ। অনেকে এটি উপেক্ষা করেন, যতক্ষণ না গতকাল load হওয়া model আজ আর load হতে চায় না।

আকার নির্ধারণের হিসাব: প্রতি parameter-এ bit

একটি model file-এর প্রায় সম্পূর্ণ অংশই weights নিয়ে গঠিত। প্রতিটি weight নির্দিষ্ট সংখ্যক bit-এ সংরক্ষিত হয়। Quantisation বলতে model যে precision-এ train করা হয়েছে, তার চেয়ে কম bit-এ weight সংরক্ষণ বোঝায়। এতে সামান্য accuracy কমে, কিন্তু memory usage অনেক কমে। আকার সরাসরি এই সূত্র অনুসরণ করে:

weights in GB = (parameters in billions x bits per weight) / 8

Models 16 bits-এ release করা হয়, যা প্রতি billion parameter-এ 2 GB-এর সমান। এ কারণেই প্রায় কেউ VPS-এ release precision ব্যবহার করে না। বাস্তবে আপনি যে quantisation-গুলো দেখতে পাবেন, সেগুলোর প্রকৃত গড় bits per weight হলো:

• Q8_0 প্রতি weight-এ প্রায় 8.5 bits সংরক্ষণ করে, তাই প্রতি billion parameter-এ প্রায় 1.1 GB লাগে।
• Q6_K প্রায় 6.6 bits সংরক্ষণ করে, তাই প্রতি billion-এ প্রায় 0.83 GB লাগে।
• Q5_K_M প্রায় 5.7 bits সংরক্ষণ করে, তাই প্রতি billion-এ প্রায় 0.71 GB লাগে।
• Q4_K_M প্রায় 4.8 bits সংরক্ষণ করে, তাই প্রতি billion-এ প্রায় 0.6 GB লাগে।

কাজের হিসাব হিসেবে প্রতি billion parameter-এ 0.6 GB ব্যবহার করুন। Memory-bound box-এ Q4_K_M যুক্তিসংগত default: বেশিরভাগ task-এ 8 bits-এর তুলনায় quality loss কম, আর file-এর আকার প্রায় অর্ধেক। 4 bits-এর নিচে গেলে loss দ্রুত বাড়ে। তাই একই generation-এর 4 bits-এ থাকা 32B model-এর তুলনায় 2 bits-এ সংকুচিত 70B model সাধারণত খারাপ উত্তর দেয়। Memory কম হলে 4 bits-এর নিচে নামার আগে এক size class ছোট করুন।

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

উপরের weight column-এ প্রতি billion-এর জন্য 0.6 GB-এর নিয়ম প্রয়োগ করা হয়েছে। প্রকৃত GGUF file সাধারণত এর কয়েক শতাংশের মধ্যেই থাকে, কারণ embedding এবং output layer-গুলো বাকি অংশের তুলনায় বেশি precision-এ রাখা হয়। 4 bits-এর 3B model-এর আকার প্রায় 1.8 GB। 8B model-এর আকার 4.8 GB। 32B model-এর আকার 19.2 GB, এবং 70B model-এর আকার 42 GB।

কেন context length weights-এর চেয়ে বেশি RAM খরচ করে

KV cache (key value cache, অর্থাৎ বর্তমানে conversation-এর প্রতিটি token-এর জন্য model যে attention state ধরে রাখে) হলো দ্বিতীয় বড় খরচ। Model load হওয়ার সময় এটি allocate করা হয়। আপনি যে context length চেয়েছেন, সেই অনুযায়ী এর আকার নির্ধারিত হয়। এই length বাড়লে cache সরলরেখায় বাড়ে।

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama-র default context-এ ওই 8B model cache-এর জন্য অর্ধেক gigabyte RAM ব্যবহার করে। 8192 token-এ এটি 1 GB ব্যবহার করে। Model card-এ দেওয়া 128k context-এ এটি 16 GB ব্যবহার করে, যা weights-এর তিন গুণেরও বেশি। 70B model-এর ক্ষেত্রে চিত্রটি উল্টো: 128k context-এ এর cache 40 GB, যা নিজস্ব weights-এর চেয়ে কম। কারণ grouped query attention প্রতি token-এর খরচকে parameter count-এর মতো দ্রুত বাড়তে দেয় না।

CPU-only server-এ Ollama-র default context length হলো 4096 token। GPU থাকলে এটি VRAM অনুযায়ী default বেছে নেয়: 24 থেকে 48 GiB-এর মধ্যে হলে 32k, এবং 48 GiB বা তার বেশি হলে 256k। Server-এ OLLAMA_CONTEXT_LENGTH variable ব্যবহার করে এটি বাড়ান। তারপর চলমান model আসলে কত পেয়েছে, তা ollama ps-এর CONTEXT column-এ দেখুন। ওই একটি setting-এর পেছনের memory arithmetic num_ctx এবং context length নিয়ে পোস্টে ধাপে ধাপে ব্যাখ্যা করা হয়েছে।

Cache-এর আকার কমানোর দুটি উপায় আছে। Model card-এ দেওয়া context নয়, আপনার প্রয়োজনীয় context চেয়ে নিন। অধিকাংশ chat এবং coding কাজ 8k থেকে 32k-এর মধ্যে সম্পন্ন হয়। অথবা cache নিজেই 8 bit-এ quantise করুন। এতে cache অর্ধেক হয়, তবে দীর্ঘ context থেকে তথ্য মনে রাখার ক্ষমতা কিছুটা কমতে পারে।

RAM-এ থাকা মডেল কোনো কিছু unload না করা পর্যন্ত মেমরি ধরে রাখে

শেষ request-এর পর Ollama একটি মডেল 5 মিনিট মেমরিতে রাখে, তারপর unload করে। এই default একটি laptop-এর জন্য উপযোগী, কিন্তু server-এর জন্য নয়। কারণ প্রতিটি idle gap-এর পরের প্রথম request-এ আবার model load হওয়ার সময় লাগে।

ollama ps
ollama stop qwen3:4b

ollama ps resident অবস্থায় থাকা মডেলগুলোর তালিকা দেখায়। এর SIZE column-এ মডেলটি কত memory ধরে রেখেছে এবং UNTIL column-এ কখন তা expire হবে, তা দেখা যায়। কোনো মডেল স্থায়ীভাবে memory-তে রাখতে service-এ OLLAMA_KEEP_ALIVE=-1 সেট করুন। 0 মান ব্যবহার করলে প্রতিটি response শেষ হওয়ার সঙ্গে সঙ্গে মডেলটি unload হয়ে যায়।

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

একটি prompt পাঠান। এরপর 10 মিনিট পরে আবার ollama ps চালান। মডেলটি তখনও তালিকায় থাকবে। এটাই প্রত্যাশিত আচরণ: কেউ ব্যবহার না করলেও মডেলটি ওই RAM ধরে রাখে। Pinned model অতিরিক্ত capacity নয়। 16 GB VPS-এ 8k context-সহ একটি 8B মডেল service চলা পর্যন্ত প্রায় 6 GB memory ধরে রাখতে পারে। তাই server-এর capacity নির্ধারণ করুন model এবং আপনার application—উভয়ের প্রয়োজন ধরে; শুধু model-এর প্রয়োজন ধরে নয়। মেমরিতে মডেল pin করা অংশে cold start latency-এর সঙ্গে এর বিনিময়টি ব্যাখ্যা করা হয়েছে।

4 GB VPS-এ কী চালানো যায়

অপারেটিং সিস্টেম এবং model server-এর জন্য প্রায় 1 GB বরাদ্দ রাখুন। এতে প্রায় 3 GB অবশিষ্ট থাকে। 4 bits-এ, default 4096 token context ব্যবহার করলে এই মেমরিতে 1B থেকে 4B model চালানো যায়। August 2026 অনুযায়ী এই শ্রেণিতে Llama 3.2-এর 3B, Qwen 3-এর 1.7B ও 4B এবং ছোট Gemma ও Phi releases অন্তর্ভুক্ত। এগুলোকে আকারের উদাহরণ হিসেবে দেখুন, সুপারিশ হিসেবে নয়। Model-এর নাম কয়েক মাস পরপর বদলে যায়, কিন্তু হিসাব বদলায় না।

প্রতি সেকেন্ডে প্রায় 6 থেকে 14 token পাওয়ার আশা করুন। এই আকারের model-গুলো classification, tag extraction, সংক্ষিপ্ত summary এবং কোনো paragraph-কে নির্দিষ্ট house style অনুযায়ী rewrite করার মতো সীমিত কাজে ভালো করে। Multi-step reasoning এবং একাধিক file জুড়ে থাকা code-এর ক্ষেত্রে এগুলো দুর্বল। কোনো prompting দিয়েই এই সীমাবদ্ধতা দূর করা যায় না।

এই স্তরে প্রধান ব্যর্থতার কারণ হলো swap। Model মেমরিতে না ধরলে Linux সেটি load করতে অস্বীকার করে না। বরং মেমরির কিছু অংশ disk-এ লিখে রাখে। একটি token তৈরি করার সময় প্রতিটি weight একবার পড়তে হয় বলে generation-এর গতি কমে প্রতি token-এ কয়েক সেকেন্ডে নেমে আসে। Model উত্তর দেওয়ার সময় free -h এবং si ও so column-এর vmstat 1 monitor করুন। Generation চলাকালে swap in এবং swap out-এর মান non-zero হলে বুঝতে হবে model-টি এই plan-এর জন্য খুব বড়।

8 থেকে 16 GB VPS-এ কী চালানো যায়

এই পরিসরে self-hosted model সাধারণভাবে ব্যবহারযোগ্য হয়ে ওঠে। 8 GB RAM-এ আপনি 4-bit-এ 7B বা 8B model চালাতে পারবেন। এতে প্রায় 4.8 GB weights এবং 8k context থাকবে। 16 GB RAM-এ 4-bit-এ 13B বা 14B model চালানো যাবে। এতে প্রায় 8.4 GB weights থাকবে। অথবা parameter count-এর বদলে precision-এ memory ব্যবহার করতে চাইলে 8B model-কে 8-bit-এ চালাতে পারবেন।

সমস্যা হলো গতি। CPU-তে 8B model প্রতি সেকেন্ডে প্রায় 3 থেকে 7 token তৈরি করে। 14B model তৈরি করে প্রায় 1.5 থেকে 3.5 token প্রতি সেকেন্ডে। একজন মানুষ প্রতি সেকেন্ডে প্রায় 5 থেকে 10 token পড়ে। তাই CPU VPS-এ 8B model ব্যবহার করলে ধীরগতির টাইপিস্টের লেখা দেখার মতো অনুভূতি হয়। Background job-এর জন্য এটি যথেষ্ট। Interactive chat-এর জন্য এটি ক্লান্তিকর। VPS-এ 8B এবং তার চেয়ে বড় Qwen 3-এর পরিমাপ করা রান বাস্তবে এর গতি কেমন, তা দেখায়।

32 থেকে 64 GB VPS-এ কী চালানো যায়

4 bits-এ একটি 32B মডেলের আকার প্রায় 19.2 GB, তাই এটি 32 GB plan-এ সংক্ষিপ্ত context নিয়ে চালানো যায় এবং 48 GB বা 64 GB-এ স্বাচ্ছন্দ্যে চলে। 4 bits-এ একটি 70B মডেলের আকার প্রায় 42 GB, তাই কোনো cache যোগ করার আগেই এর জন্য 64 GB প্রয়োজন।

এরপর গতি বাস্তবভাবে বিবেচনা করুন। CPU-তে 32B মডেল প্রতি সেকেন্ডে প্রায় 0.6 থেকে 1.5 token তৈরি করে, আর 70B মডেল 0.2 থেকে 0.5 token তৈরি করে। ওই 70B মডেল দিয়ে 500 token-এর একটি উত্তর তৈরি করতে প্রায় বিশ মিনিট লাগে। এগুলো batch tool হিসেবে ব্যবহার করার উপযোগী। রাতে document-এর একটি queue চালালে গতি গুরুত্বপূর্ণ নয়। এগুলো chat window-এর পেছনে চালালে গতি অত্যন্ত গুরুত্বপূর্ণ হয়ে ওঠে।

Mixture of experts routing এই হিসাব পরিবর্তন করে, এবং এটিই শেখার মতো একমাত্র architecture-এর বিবরণ। একটি MoE model প্রতিটি token-কে তার weights-এর কেবল একটি ছোট অংশের মধ্য দিয়ে পাঠায়। মোট 30B parameter এবং প্রতি token-এ 3B active parameter থাকা একটি model-এর memory প্রয়োজন 30B model-এর মতো, কিন্তু এটি dense 3B model-এর কাছাকাছি গতিতে text তৈরি করে, কারণ প্রতিটি token কেবল active expert-গুলো পড়ে। 32 GB box-এ এই ধরনের একটি MoE model, dense 30B model-এর তুলনায় অনেক বেশি ব্যবহারযোগ্য। মনে রাখার নিয়ম: মোট parameter memory নির্ধারণ করে, আর active parameter গতি নির্ধারণ করে।

CPU inference বাস্তবে কত দ্রুত?

একটি token তৈরি করতে প্রতিটি সক্রিয় weight একবার করে memory থেকে পড়তে হয়। এটি এড়ানোর কোনো উপায় নেই। তাই CPU-তে generation speed core count নয়, memory bandwidth দ্বারা নির্ধারিত হয়। সর্বোচ্চ গতি হিসাব করা যায় usable memory bandwidth-কে weight-এর byte-এ থাকা আকার দিয়ে ভাগ করে। একটি ছোট shared VPS সাধারণত তার vCPU-গুলোর মধ্যে 10 থেকে 25 GB per second memory bandwidth দেয়। তাই 4.8 GB model-এর সর্বোচ্চ গতি প্রায় 2 থেকে 5 tokens per second।

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

এগুলো সাধারণ VPS hardware-এ প্রচলিতভাবে পাওয়া range। এগুলো কোনো একটি machine-এর benchmark নয়। আপনার ফল memory generation, host-এর channel count এবং একই memory bandwidth-এর জন্য প্রতিদ্বন্দ্বিতা করা প্রতিবেশী workload-এর সংখ্যার ওপর নির্ভর করে। আপনার কাছে থাকা যেকোনো model tag ব্যবহার করে নিজেই মাপুন:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

উত্তর শেষ হওয়ার পরে মুদ্রিত summary-তে eval rate: ... tokens/s লেখা একটি line থাকে। এটিই generation speed। কোনো session-এর প্রথম run-টি উপেক্ষা করুন, কারণ একই summary-তে load duration disk থেকে weight পড়ার সময়ও অন্তর্ভুক্ত করে। তুলনাযোগ্য একটি ফল পাওয়ার পদ্ধতি প্রতি second-এ token সঠিকভাবে মাপা অংশে দেখানো হয়েছে।

এখানে দুটি বিষয় মানুষকে অবাক করে। vCPU যোগ করলে দ্রুতই তার উপকার বন্ধ হয়ে যায়, কারণ প্রায় 8 core-এর পরে অতিরিক্ত core-গুলো arithmetic করার বদলে memory-এর জন্য অপেক্ষা করে। Shared plan-এ একই command থেকে hour অনুযায়ী ভিন্ন ফলও পাওয়া যায়। এটি noisy neighbour-এর CPU steal time, আপনার configuration-এর ভুল নয়।

আপনার prompt পড়া এবং উত্তর তৈরি করা আলাদা কাজ। Prompt processing compute bound, তাই এটি core count বাড়লে দ্রুত হয়। এখানেই GPU সবচেয়ে বেশি এগিয়ে থাকে। একটি দীর্ঘ document পড়তে CPU-এর minutes লাগে, কিন্তু GPU-এর seconds লাগে। আপনার host করা model-এ coding agent নির্দেশ করা শুরু করলে এটিই প্রথম বড় সীমাবদ্ধতা দেখা দেয়, কারণ প্রতিটি turn-এ উত্তর থেকে একটি token আসার আগেই file context এবং tool definitions আবার পাঠানো হয়।

GPU যোগ করলে কী পরিবর্তন হয়

গণনার পদ্ধতি বদলায় না; শুধু এটি যে pool-এর ক্ষেত্রে প্রযোজ্য, সেটি বদলে যায়। VRAM একটি কঠোর সীমা। তাই ভাড়া নেওয়ার আগে কোন মডেলটি এতে ধরে তা হিসাব করুন:

• 8 GB VRAM-এ 4 bits-এ 7B বা 8B মডেল short context-সহ ধরে।
• 16 GB-এ real context-সহ 4 bits-এ 14B মডেল, অথবা 8 bits-এ 8B মডেল ধরে।
• 24 GB-এ context short রাখলে 4 bits-এ 32B মডেল ধরে।
• 48 GB বা তার বেশি VRAM-এ cache এবং concurrency-এর জন্য কিছু জায়গা রেখে 4 bits-এ 70B মডেল ধরে।

কোনো মডেল পুরোপুরি না ধরলে Ollama মডেলটি ভাগ করে: কিছু layer GPU-তে এবং বাকি layer CPU-তে চালায়। ollama ps তার PROCESSOR column-এ এই বিভাজন 78%/22% CPU/GPU-এর মতো দেখায়। এটিকে feature হিসেবে নয়, warning হিসেবে বিবেচনা করুন। CPU-তে থাকা অংশই গতি নির্ধারণ করে, কারণ প্রতিটি token-এর জন্য ওই layer-গুলোর কাজ শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয়। তাই কোনো মডেলের এক-চতুর্থাংশ layer CPU-তে থাকলে সেটি GPU speed-এর চেয়ে CPU speed-এর কাছাকাছি চলে। আপনি অনিচ্ছাকৃত split দেখলে প্রথমে context length কমান। সাধারণত cache-এর কারণেই সীমা অতিক্রম করে।

Concurrency বাড়ানোর আরেকটি কারণ। একাধিক simultaneous request-এর মধ্যে weights shared থাকে। কিন্তু প্রতিটি active request-এর জন্য আলাদা KV cache দরকার। তাই 8k context-এ 8B মডেল ব্যবহারকারী 10 জন concurrent user-এর জন্য weights-এর অতিরিক্ত দশ গুণ 1 GB cache দরকার। একটি self-hosted model থেকে concurrent user পরিবেশন করা এই সীমাটি কোথায় পড়ে, তা ব্যাখ্যা করে।

GPU ভাড়া করা সার্থক কি না, সেটিও একটি হিসাবের বিষয়। মূল প্রশ্ন হলো, প্রতি মাসে আপনি বাস্তবে কত token generate করেন। GPU VPS এবং API token-এর মধ্যে break-even হিসাব-এ সেই সংখ্যাগুলো দেওয়া আছে।

আপনি যা self-host করতে পারবেন না

এখানে দুটি ভিন্ন সীমাবদ্ধতা আছে। আপনি কোনটির মুখোমুখি হচ্ছেন, তা জানা সহায়ক।

প্রথমটি হলো closed weights। Frontier commercial model বিতরণ করা হয় না। তাই ডাউনলোড করার মতো কোনো file নেই, এবং RAM বাড়ালেও এর পরিবর্তন হয় না। এর চারপাশের সবকিছু self-host করতে পারেন: interface, retrieval layer, agent loop এবং logs। কিন্তু model নিজে remote API হিসেবেই থাকে। আপনি Claude self-host করতে পারবেন কি না বিষয়টি বিস্তারিতভাবে ব্যাখ্যা করে।

দ্বিতীয়টি হলো এমন open weights, যেগুলো বাস্তবে অতিরিক্ত বড়। সবচেয়ে বড় open release-গুলো mixture of experts design ব্যবহার করে এবং মোট parameter-এর সংখ্যা শত শত বিলিয়ন। এগুলোর ক্ষেত্রেও একই নিয়ম প্রযোজ্য: 4 bits-এ 400B total parameter-এর একটি model-এর শুধু weights-এর জন্যই প্রায় 240 GB প্রয়োজন, কোনো cache ধরার আগেই। এর জন্য specialist hardware দরকার। মাসিক ভাড়ায় সেই hardware ব্যবহার করতে গেলে অধিকাংশ মানুষ এক বছরে API token-এর পেছনে যত খরচ করে, তার চেয়ে অনেক বেশি ব্যয় হয়। Kimi class model self-host করতে কী প্রয়োজন বাস্তব requirement ব্যাখ্যা করে।

দুটির মধ্যে বাস্তব সিদ্ধান্তটি হলো: load স্থির থাকলে এবং data আপনার server-এর বাইরে যাওয়া উচিত না হলে self-host করুন। Load অনিয়মিত হলে, অথবা আপনার প্রকৃত প্রয়োজন যদি frontier-এর answer quality হয়, তাহলে token কিনুন।

আপনি নির্বাচন করার আগে আপনার হাতে থাকা সম্পদ যাচাই করুন

free -h
nproc
lscpu | grep 'Model name'

free -h-এর available কলাম ধরে পরিকল্পনা করুন, total কলাম ধরে নয়। কারণ total-এ সিস্টেম ইতিমধ্যে যে মেমোরি ব্যবহার করছে, সেটিও অন্তর্ভুক্ত থাকে। অপারেটিং সিস্টেম এবং model server-এর জন্য প্রায় 1 GB বাদ দিন। অবশিষ্ট পরিমাণকে 0.6 দিয়ে ভাগ করুন। এতে 4 bits-এ আপনি সর্বোচ্চ কত বিলিয়ন parameter ধারণ করতে পারবেন, তা জানা যাবে। এরপর আপনি যে context ব্যবহার করতে চান, তার জন্য প্রয়োজনীয় KV cache বাদ দিন। অবশিষ্ট পরিমাণই আপনার উত্তর। model-এর নামের তালিকার মতো এই হিসাব পুরোনো হয়ে যায় না।

FAQ

8B model চালাতে কত RAM প্রয়োজন?

4 bit quantisation-এ weights-এর জন্য প্রায় 4.8 GB, আপনার context length অনুযায়ী KV cache, এবং operating system ও model server-এর জন্য আরও প্রায় 1 GB প্রয়োজন। 8192 token context হলে cache আরও প্রায় 1 GB যোগ করে। তাই 8 GB plan কাজ করবে, কিন্তু 4 GB plan কাজ করবে না। Model card-এ উল্লেখিত পূর্ণ 128k context ব্যবহার করতে চাইলে শুধু cache-এর জন্যই 16 GB লাগবে। সে ক্ষেত্রে 32 GB plan প্রয়োজন হবে।

VPS-এ পর্যাপ্ত vCPU থাকা সত্ত্বেও আমার model ধীর কেন?

কারণ generation cores নয়, memory bandwidth দ্বারা সীমাবদ্ধ। প্রতিটি token-এর জন্য সক্রিয় weights-এর সম্পূর্ণ সেট RAM থেকে পড়তে হয়। তাই কয়েকটি core memory channel সম্পূর্ণ ব্যবহার করতে শুরু করলে বাকি core-গুলো অপেক্ষা করে। আরেকটি সাধারণ কারণ হলো swap। Model উত্তর দেওয়ার সময় vmstat 1-এ non zero si এবং so দেখা গেলে weights RAM-এ পুরোপুরি ধরছে না। ফলে প্রতিটি token-এর একটি অংশ disk থেকে পড়তে হচ্ছে। এতে প্রত্যাশার তুলনায় অনেক বেশি সময় লাগে।

দীর্ঘতর context window-এর জন্য কি সত্যিই বেশি memory দরকার?

হ্যাঁ। Token-এর সংখ্যা বাড়ার সঙ্গে memory ব্যবহার linear হারে বাড়ে। একটি সাধারণ 8B model প্রতি token-এ প্রায় 128 KiB KV cache ব্যবহার করে। তাই 8192 token-এর জন্য 1 GB এবং 131072 token-এর জন্য 16 GB লাগে। Conversation বড় হওয়ার সময় cache বরাদ্দ হয় না। Model load হওয়ার সময়ই cache বরাদ্দ করা হয়। তাই 128k context নির্ধারণ করলে সঙ্গে সঙ্গে ওই memory reserve হয়, আপনি পাঠানো প্রতিটি prompt মাত্র 200 token দীর্ঘ হলেও।

আমার কি একটি বড় model 2 bits-এ, নাকি ছোট model 4 bits-এ চালানো উচিত?

4 bits-এ ছোট model বেছে নিন। 8 bits থেকে 4 bits পর্যন্ত quality ধীরে কমে, কিন্তু 4 bits-এর নিচে দ্রুত কমে যায়। তাই একই model generation-এর 70B model-কে 2 bits-এ সংকুচিত করলে সাধারণত 4 bits-এর 32B model-এর চেয়ে খারাপ উত্তর পাওয়া যায়। Heavy quantisation error message হিসেবে দেখা যায় না। এর পরিবর্তে repetition এবং instruction বাদ পড়ার মতো সমস্যা দেখা দেয়। তাই সমস্যার কারণ prompt বলে মনে হতে পারে। 4 bits-কে সর্বনিম্ন সীমা হিসেবে ধরুন এবং তার বদলে parameter count পরিবর্তন করুন।

বড় commercial model-এর মতো সক্ষম কোনো model কি self-host করতে পারি?

সাধারণ VPS-এ নয়। সবচেয়ে শক্তিশালী open weight model-গুলোর parameter সংখ্যা শত শত বিলিয়নে পৌঁছায়। 4 bits-এ এগুলোর জন্য কোনো KV cache ছাড়াই 200 GB-এর বেশি RAM লাগে। আর সবচেয়ে শক্তিশালী commercial model-গুলো আদৌ বিতরণ করা হয় না। সাধারণ hardware একটি নির্দিষ্ট কাজের জন্য ভালো 8B থেকে 32B model চালাতে পারে। সংকীর্ণ কাজের জন্য ভালোভাবে লেখা prompt-সহ ছোট model অনেক সময় general model-এর সমতুল্য ফল দিতে পারে। Frontier quality প্রয়োজন হলে hardware কেনার আগে API-এর খরচের সঙ্গে hardware-এর খরচ তুলনা করুন।