কোন AI model আপনি নিজে 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 প্রায় সম্পূর্ণভাবে weight নিয়ে গঠিত। প্রতিটি weight নির্দিষ্ট সংখ্যক bit-এ সংরক্ষিত হয়। Quantisation বলতে training-এর সময় ব্যবহৃত precision-এর তুলনায় কম bit-এ weight সংরক্ষণ করাকে বোঝায়। এতে সামান্য accuracy কমে, কিন্তু memory usage অনেক কমে। আকার সরাসরি এই হিসাব অনুসরণ করে:

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

Model 16 bit-এ release করা হয়। অর্থাৎ প্রতি 1 billion parameter-এ 2 GB লাগে। তাই প্রায় কেউই VPS-এ release precision ব্যবহার করে না। বাস্তবে আপনি যে quantisation-গুলো ব্যবহার করবেন, সেগুলোর প্রতি weight-এ প্রকৃত গড় bit হলো:

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

কাজের হিসাব হিসেবে প্রতি 1 billion parameter-এ 0.6 GB ধরুন। Memory সীমিত server-এ Q4_K_M একটি যুক্তিসঙ্গত default। অধিকাংশ কাজে 8 bit-এর তুলনায় quality loss কম, আর file-এর আকার প্রায় অর্ধেক। 4 bit-এর নিচে গেলে loss দ্রুত বাড়ে। তাই একই generation-এর 32B model 4 bit-এ সাধারণত 2 bit-এ সংকুচিত 70B model-এর চেয়ে ভালো উত্তর দেয়। Memory কম থাকলে 4 bit-এর নিচে নামার আগে model-এর 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-এ প্রতি 1 billion parameter-এ 0.6 GB-এর নিয়ম প্রয়োগ করা হয়েছে। প্রকৃত GGUF file সাধারণত এই হিসাবের কয়েক শতাংশের মধ্যে থাকে। কারণ embedding এবং output layer বাকি অংশের তুলনায় বেশি precision-এ রাখা হয়। 4 bit-এর 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, অর্থাৎ কথোপকথনে বর্তমানে থাকা প্রতিটি token-এর জন্য model যে attention state সংরক্ষণ করে) হলো RAM ব্যবহারের দ্বিতীয় বড় কারণ। Model load হওয়ার সময় এটি বরাদ্দ হয়। আপনি যে 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 আসলে কত context পেয়েছে, তা ollama ps-এর CONTEXT column-এ দেখুন। এই setting-এর পেছনের memory হিসাব num_ctx এবং context length নিয়ে পোস্টটিতে ধাপে ধাপে ব্যাখ্যা করা হয়েছে।

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

একটি resident model unload না হওয়া পর্যন্ত RAM দখল করে রাখে

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

ollama ps
ollama stop qwen3:4b

ollama ps resident model-এর তালিকা দেখায়। এর SIZE column-এ modelটি কত memory দখল করছে এবং UNTIL column-এ কখন এটি expire হবে তা দেখা যায়। কোনো model স্থায়ীভাবে pin করতে service-এ OLLAMA_KEEP_ALIVE=-1 সেট করুন। 0 মান ব্যবহার করলে প্রতিটি response শেষ হওয়ার সঙ্গে সঙ্গে modelটি 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 চালান। Modelটি তখনও তালিকায় থাকবে। এটাই মূল বিষয়: কেউ ব্যবহার না করলেও এটি RAM দখল করে রাখে। Pinned model অতিরিক্ত capacity নয়। 16 GB VPS-এ 8B model 8k context সহ service চালু থাকা পর্যন্ত প্রায় 6 GB memory দখল করে রাখতে পারে। তাই শুধু model নয়, model এবং আপনার application—উভয়কে ধরে server-এর আকার নির্ধারণ করুন। memory-তে model pin করা অংশে cold start latency-এর সঙ্গে এর trade-off ব্যাখ্যা করা হয়েছে।

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

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

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

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

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

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

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

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

4 bits-এ একটি 32B মডেলের জন্য প্রায় 19.2 GB লাগে। তাই short context ব্যবহার করলে এটি 32 GB plan-এ চলে এবং 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-এর একটি উত্তর তৈরি হতে প্রায় বিশ মিনিট লাগে। এই গতিতে model উত্তর শেষ করার আগেই request সাধারণত ব্যর্থ হয়, কারণ Ollama-এর সামনে থাকা কোনো client বা proxy-এর timeout আগে কার্যকর হয়। এখান থেকেই context deadline exceeded error আসে। এগুলো batch tool। রাতে এগুলোকে document-এর একটি queue দিলে গতি গুরুত্বপূর্ণ নয়। এগুলোকে chat window-এর পেছনে রাখলে গতি অত্যন্ত গুরুত্বপূর্ণ হয়ে ওঠে।

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

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

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

[
  {
    "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 ব্যবহার করছে—এসবের ওপর নির্ভর করে। আগে থেকে থাকা যেকোনো 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 পড়ার সময়ও অন্তর্ভুক্ত থাকে। তুলনা করার মতো নির্ভরযোগ্য সংখ্যা কীভাবে পেতে হয়, তা tokens per second সঠিকভাবে মাপা অংশে ব্যাখ্যা করা হয়েছে।

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

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

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

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

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

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

Concurrency-এর কারণেও বড় configuration প্রয়োজন হয়। একসঙ্গে চলা request-গুলোর মধ্যে weights ভাগ হয়, কিন্তু প্রতিটি active request-এর নিজস্ব KV cache প্রয়োজন। তাই 8k context-এ 8B model ব্যবহারকারী 10 জন concurrent user-এর weights-এর অতিরিক্ত প্রতি request-এর জন্য 1 GB cache প্রয়োজন, অর্থাৎ মোট দশ গুণ cache। একটি self-hosted model থেকে concurrent user পরিবেশন করলে এই ceiling কোথায় পৌঁছায়, তা বোঝা যায়।

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

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

এখানে দুটি আলাদা সীমাবদ্ধতা আছে। আপনি কোনটির মুখোমুখি হচ্ছেন, তা জানা গুরুত্বপূর্ণ।

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

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

দুটির মধ্যে বাস্তব সিদ্ধান্তটি হলো: 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 বাদ দিন। 4 bits-এ সর্বোচ্চ কত বিলিয়ন parameter রাখা যাবে, তা বের করতে অবশিষ্ট পরিমাণকে 0.6 দিয়ে ভাগ করুন। এরপর আপনি বাস্তবে যে 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 core-এর সংখ্যা নয়, memory bandwidth দ্বারা সীমাবদ্ধ। প্রতিটি token তৈরি করতে সক্রিয় weights-এর সম্পূর্ণ সেট RAM থেকে পড়তে হয়। কয়েকটি core memory channel-এর capacity পূর্ণ করলে বাকি 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 লাগে। model load হওয়ার সময়ই cache allocate করা হয়। conversation বড় হওয়ার সময় এটি ধাপে ধাপে allocate হয় না। তাই 128k context নির্ধারণ করলে memory সঙ্গে সঙ্গে reserve হয়, আপনি পাঠানো প্রতিটি prompt 200 token দীর্ঘ হলেও।

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

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

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

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