Kimi K3 সেলফ-হোস্ট করার উপায় ও প্রয়োজনীয় হার্ডওয়্যার

Kimi K3 সেলফ-হোস্ট করার প্রয়োজনীয়তা

Kimi K3 সেলফ-হোস্ট করার অর্থ হলো 2.8 ট্রিলিয়ন প্যারামিটারের জন্য জায়গা খুঁজে বের করা। Moonshot এর ওপেন ওয়েটগুলো MXFP4 ফরম্যাটে প্রকাশ করেছে, যার মানে প্রতি ওয়েটের জন্য প্রায় আধা বাইট জায়গা লাগে। তাই কোনো টোকেন ক্যাশ বরাদ্দ করার আগেই ওয়েটগুলোর জন্য প্রায় 1.4 TB জায়গা প্রয়োজন। বর্তমানে বাজারে থাকা কোনো এক্সিলারেটর এককভাবে এটি ধারণ করতে পারে না। K3 একটি মাল্টি-নোড মডেল, তাই একটি সার্ভারে এটি চালানো সম্ভব নয়।

এটাই চূড়ান্ত সিদ্ধান্ত। নিচে এর গাণিতিক ব্যাখ্যা দেওয়া হলো, কারণ পরবর্তী রিলিজের ক্ষেত্রেও এই হিসাবগুলো আপনার কাজে লাগবে। 17 জুলাই 2026-এ ঘোষণার পরবর্তী কয়েক সপ্তাহে বেশ কয়েকজন ইনফ্রাস্ট্রাকচার ভেন্ডর K3 ডেপ্লয়মেন্ট গাইড প্রকাশ করেছিল, এবং প্রত্যেকেই ধরে নিয়েছিল যে আপনার কাছে আগে থেকেই একটি ক্লাস্টার আছে। এই পেজটি বিপরীত দিক থেকে শুরু করছে: এর খরচ কত, এর বদলে আপনি কী চালাতে পারেন এবং এই দুটির মধ্যে আপনি কোন অবস্থানে আছেন তা কীভাবে বুঝবেন।

মোট প্যারামিটার এবং সক্রিয় প্যারামিটারের সংখ্যা এক নয়

K3 একটি mixture of experts মডেল। MoE (mixture of experts) নেটওয়ার্কটিকে অনেকগুলো সাব-নেটওয়ার্কে বিভক্ত করে এবং একটি রাউটার প্রতিটি টোকেনের জন্য এর মধ্য থেকে কয়েকটি বেছে নেয়। মডেল কার্ড অনুযায়ী, এতে মোট 2.8T প্যারামিটার রয়েছে এবং প্রতিটি টোকেনের জন্য 104B প্যারামিটার সক্রিয় হয়। এটি 896টি রাউটেড এক্সপার্ট থেকে গঠিত, যার মধ্যে প্রতিটি টোকেনের জন্য 16টি এক্সপার্ট কাজ করে এবং এটি 93টি লেয়ার জুড়ে বিস্তৃত।

এই দুটি প্যারামিটার সংখ্যা ভিন্ন ভিন্ন প্রশ্নের উত্তর দেয় এবং "আমি কি এটি চালাতে পারব" বিষয়ক প্রতিটি আলোচনায় এদের গুলিয়ে ফেলা সবচেয়ে সাধারণ ভুল।

সক্রিয় প্যারামিটার কম্পিউট খরচ নির্ধারণ করে। একটি টোকেন প্রায় 104B প্যারামিটারের মধ্য দিয়ে গুণিত হয়, তাই আপনার প্রত্যাশিত থ্রুপুট 2.8T মডেলের পরিবর্তে 104B ডেন্স (dense) মডেলের মতো হওয়া উচিত। MoE তৈরির মূল কারণই এটি।

মোট প্যারামিটার মেমরি খরচ নির্ধারণ করে। রাউটার যেকোনো টোকেনের জন্য যেকোনো এক্সপার্ট নির্বাচন করতে পারে, তাই প্রথম অনুরোধ আসার আগেই প্রতিটি এক্সপার্টকে মেমরিতে থাকতে হয়। আপনি VRAM-এ 104B রেখে বাকিগুলো প্রয়োজনে আনতে পারবেন না, কারণ এই আনা বা ফেচ করার প্রক্রিয়াটি মাইক্রোসেকেন্ডের মধ্যে শেষ হতে হবে এবং একটি PCIe লিঙ্ক প্রতি সেকেন্ডে কয়েক দশ গিগাবাইট ডেটা স্থানান্তর করতে পারে। অনেকে এটি করার চেষ্টা করেন। NVMe থেকে এক্সপার্ট স্ট্রিমিং করলে যে মডেলটি প্রতি সেকেন্ডে কয়েক ডজন টোকেন তৈরি করতে পারত, তা প্রতি কয়েক সেকেন্ডে মাত্র একটি টোকেন তৈরি করতে সক্ষম হয়।

সুতরাং, এটি কম্পিউট করার জন্য সাশ্রয়ী কিন্তু স্টোর করার জন্য ব্যয়বহুল। আপনার হার্ডওয়্যার 2.8T অনুযায়ী নির্বাচন করুন। আপনার গতির প্রত্যাশা 104B অনুযায়ী নির্ধারণ করুন।

ওজনের প্রতি বাইট এবং টেরাবাইটের উৎস

প্যারামিটার সংখ্যা গুণিতক ওজনের প্রতি বাইট। ওজনের ক্ষেত্রে এটিই সম্পূর্ণ সূত্র।

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 মডেলটিকে quantization aware পদ্ধতিতে প্রশিক্ষণ দেওয়া হয়েছে এবং এটি MXFP4 ওয়েট ও MXFP8 অ্যাক্টিভেশনসহ রিলিজ করা হয়েছে, তাই 4-বিট সারিটিই প্রকৃত হিসাব। উপরের সারিগুলো স্কেল বোঝার জন্য দেওয়া হয়েছে: bf16 ফরম্যাটে একই মডেলের জন্য 5.6 TB মেমোরি প্রয়োজন হতো। MXFP4 প্রতিটি 32টি ওয়েটের ব্লকের জন্য একটি শেয়ারড 8-বিট স্কেল সংরক্ষণ করে, যা প্রায় 6 শতাংশ বাড়তি জায়গা নেয়। তাই প্রকাশিত রিপোজিটরিটির আকার 1.5 TB-এর কাছাকাছি, যা সরাসরি 1.4 TB হওয়ার কথা ছিল।

এটি সাধারণ সমাধানের পথ বন্ধ করে দেয়। "শুধু কোয়ান্টাইজ করুন" বললে এখানে কোনো লাভ হবে না, কারণ রিলিজ করা চেকপয়েন্টটি ইতিমধ্যেই 4-বিট। 2-বিটে নামিয়ে আনলে ওয়েটের আকার 0.7 TB হবে, কিন্তু এতে নির্ভুলতা (accuracy) কতটা কমবে তা এই চেকপয়েন্টের জন্য কেউ পরিমাপ করেনি। তবুও এটি যেকোনো একটি কার্ডের ধারণক্ষমতার চেয়ে অনেক বেশি থাকবে।

Kimi K3-এর জন্য কয়টি GPU প্রয়োজন

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

এই সংখ্যাগুলোকে লক্ষ্যমাত্রা হিসেবে না ধরে ন্যূনতম প্রয়োজনীয়তা হিসেবে বিবেচনা করুন। এগুলো শুধুমাত্র ওয়েট (weights)-এর হিসাব; এতে KV cache, activation buffer, allocator fragmentation বা একই সাথে একাধিক অনুরোধ প্রসেস করার কোনো জায়গা ধরা হয়নি। এছাড়া, এগুলো এমন একটি প্যারালাল স্প্লিট ধরে নেয় যা সমানভাবে ভাগ করা যায়, যা 93টি লেয়ার এবং 896টি এক্সপার্টের ক্ষেত্রে সবসময় সম্ভব হয় না।

প্রকাশিত নির্দেশিকা এই ন্যূনতম সীমার চেয়ে অনেক বেশি। 2026 সালের আগস্ট মাস পর্যন্ত, Moonshot 64টি বা তার বেশি এক্সিলারেটরের একটি সুপারনোড ব্যবহারের পরামর্শ দেয়। SGLang কুকবুক চারটি 8-GPU নোড, 32টি GPU এবং 2,560 GB সম্মিলিত মেমোরি দিয়ে তৈরি একটি H100 কনফিগারেশন সরবরাহ করে, যেখানে ন্যূনতম প্রয়োজনীয়তা হলো 18 কার্ড। এই পার্থক্যটি অপচয় নয়। এটি KV cache, activation মেমোরি এবং সার্ভারকে একসাথে অনেকগুলো অনুরোধ ব্যাচ করার সক্ষমতা প্রদান করে। এমনকি সবচেয়ে সহজলভ্য সারি, 5 GB300 ক্লাস কার্ডের ক্ষেত্রেও, এমন একটি মেশিনের বর্ণনা দেওয়া হয়েছে যা বেশিরভাগ প্রোভাইডার একক SKU হিসেবে ভাড়া দেয় না।

KV cache বিষয়টিই মানুষকে অবাক করে

Weights হলো একটি নির্দিষ্ট খরচ। কিন্তু KV (key value) cache তা নয়: এটি context length-এর সাথে বৃদ্ধি পায় এবং প্রতিটি concurrent user-এর জন্য পুনরায় বাড়ে। সাধারণ attention-এর ক্ষেত্রে সূত্রটি হলো bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, এবং এরপর একে context length ও concurrency দিয়ে গুণ করতে হয়।

এখানে একটি উদাহরণ দেওয়া হলো, তবে এটি কেবলই একটি উদাহরণ: 64 layers, 8 KV heads, head dimension 128, fp8। এটি থেকে পাওয়া যায় 2 64 8 128 1 = 131,072 bytes, অর্থাৎ প্রতি টোকেনে 128 KiB।

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

128k context-এ একজন ব্যবহারকারীর খরচ 16 GiB। পুরো এক মিলিয়ন context-এ একজন ব্যবহারকারীর খরচ 128 GiB, যা একটি একক কার্ডের ধারণক্ষমতার চেয়েও বেশি, শুধুমাত্র একটি কথোপকথনের জন্য।

K3 সাধারণ attention ব্যবহার করে না, এবং শেষোক্ত সংখ্যাটিই এর কারণ। এর 93টি লেয়ারের মধ্যে 69টি হলো KDA (Kimi Delta Attention) লেয়ার এবং 24টি হলো Gated MLA (multi-head latent attention) লেয়ার। KDA প্রতিটি টোকেনের সাথে বাড়তে থাকা ক্যাশের পরিবর্তে একটি নির্দিষ্ট আকারের recurrent state বজায় রাখে এবং MLA কি (key) ও ভ্যালু (value)-কে একটি low rank latent vector-এ সংকুচিত করে, তাই প্রকৃত প্রতি-টোকেন খরচ উপরের উদাহরণের চেয়ে অনেক কম হয়। Moonshot তাদের latent dimension প্রকাশ করেনি, তাই আমি K3-এর জন্য কোনো নির্দিষ্ট প্রতি-ব্যবহারকারী সংখ্যা উল্লেখ করব না। এর পরিবর্তে আপনার নিজের পরিমাপ করুন: একটি ছোট --max-model-len দিয়ে সার্ভার চালু করুন, nvidia-smi দিয়ে মেমোরি পর্যবেক্ষণ করুন, তারপর allocation ব্যর্থ না হওয়া পর্যন্ত সীমা বাড়াতে থাকুন।

Reasoning-এর কাঠামোটি পরবর্তী রিলিজগুলোতেও টিকে থাকবে। যদি কোনো মডেল এক মিলিয়ন টোকেন context-এর বিজ্ঞাপন দেয় কিন্তু তাদের attention design সম্পর্কে কিছু না বলে, তবে ধরে নিন যে ক্যাশই হলো মূল সীমাবদ্ধতা, যতক্ষণ না কেউ অন্য কিছু প্রমাণ করতে পারছে।

Tier 1: ঘণ্টা হিসেবে ক্লাস্টার ভাড়া নেওয়া

এটিই একমাত্র টিয়ার যেখানে K3 নিজে চলে। আপনি হার্ডওয়্যার কেনেন না। আপনার প্রয়োজনীয় ঘণ্টার জন্য এটি ভাড়া নেন এবং কাজ শেষে তা বন্ধ করে দেন।

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

এই রেট একটি অনুমান, কোনো চূড়ান্ত দর নয়। 2026 সাল পর্যন্ত ডেটাসেন্টার এক্সিলারেটরের অন-ডিমান্ড তালিকা মূল্য সাধারণত প্রতি GPU ঘণ্টা 2 থেকে 5 USD-এর মধ্যে ছিল এবং রিজার্ভড ক্যাপাসিটি আরও সস্তা। আপনার প্রোভাইডারের প্রকৃত সংখ্যাটি নিন এবং গুণফল পুনরায় হিসাব করুন: GPU সংখ্যা গুণ ঘণ্টা গুণ রেট। এই চার্টের মূল উদ্দেশ্য হলো অনুপাতটি দেখানো। দিনে চার ঘণ্টার জন্য একটি 8 GPU নোড ব্যবহার করলে মাসে 2,400 USD খরচ হয়, যেখানে 32 GPU-এর SGLang কনফিগারেশন সবসময় চালু রাখলে খরচ হয় 57,600 USD।

উভয় মেইনস্ট্রিম সার্ভারই মডেল কার্ডে একটি লঞ্চ কমান্ড প্রকাশ করে।

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

কোনো সাধারণ কমান্ডই আপনি আসল ক্লাস্টারে সরাসরি চালাবেন না। আপনার হার্ডওয়্যারের সাথে সামঞ্জস্যপূর্ণ প্যারালালিজম ফ্ল্যাগগুলো যোগ করুন: SGLang-এর ক্ষেত্রে টেনসর প্যারালালের জন্য --tp-size এবং এক্সপার্ট প্যারালালের জন্য --ep-size ব্যবহার করুন, এবং এদের গুণফল অবশ্যই আপনার বর্তমান GPU সংখ্যার সমান হতে হবে।

আসল ট্রাফিক পাঠানোর আগে সার্ভারটি চালু হয়েছে কি না তা পরীক্ষা করুন:

curl http://127.0.0.1:30000/v1/models

একটি সচল সার্ভার মডেল আইডি সম্বলিত একটি JSON অবজেক্ট দিয়ে উত্তর দেয়। Connection refused মানে হলো প্রসেসটি এখনো ওয়েট লোড করছে অথবা ইতিমধ্যে বন্ধ হয়ে গেছে, তাই পুনরায় চেষ্টা করার আগে সার্ভার লগ পড়ুন।

প্রথম দিনে সাধারণ ব্যর্থতার কারণ হলো মডেলের তুলনায় রানটাইম পুরোনো হওয়া। K3 যখন KDA এবং একটি নতুন MoE লেয়ারসহ রিলিজ হয়েছিল, তখন স্থিতিশীল vLLM এবং SGLang রিলিজগুলোতে তা ছিল না। এর লক্ষণ হলো স্টার্টআপের সময় সার্ভারটি Model architectures [...] are not supported for now ফরম্যাটের একটি লাইন দেখিয়ে বন্ধ হয়ে যায়। কোনো কনফিগারেশন পরিবর্তন এটি ঠিক করতে পারবে না, কারণ সেই লেয়ারগুলো চালানোর কোড আপনার বিল্ডে নেই। মডেল কার্ডে উল্লিখিত নাইটলি (nightly) ভার্সনটি ইনস্টল করুন অথবা সেই রিলিজের জন্য অপেক্ষা করুন যাতে এটি অন্তর্ভুক্ত আছে।

খরচ সংক্রান্ত একটি বিষয় যা অনেকের নজর এড়িয়ে যায়। মিটারটি মডেল প্রস্তুত হওয়ার সময় থেকে নয়, বরং ইনস্ট্যান্স চালু হওয়ার সময় থেকে গণনা শুরু করে। 1 GB/s গতিতে 1.5 TB ডাউনলোড হতে প্রথম টোকেনের আগে ক্লাস্টারের প্রায় 25 মিনিট সময় ব্যয় হয়। ওয়েটগুলো এমন একটি ভলিউমে রাখুন যা ইনস্ট্যান্স বন্ধ হওয়ার পরেও টিকে থাকে, যাতে দ্বিতীয়বার চালানোর সময় কয়েক মিনিটের মধ্যেই শুরু করা যায়।

Tier 2: একটি অ্যাক্সিলারেটরে ছোট মডেল চালানো

এই টায়ারে আপনি K3 চালাচ্ছেন না। শুরু করার আগেই এটি স্পষ্টভাবে জেনে নিন, কারণ "স্থানীয়ভাবে K3 চালান" সংক্রান্ত বেশিরভাগ আলোচনা এখানেই শেষ হয়, কিন্তু তা স্বীকার করা হয় না।

মডেলের আকার নির্ধারণের নিয়মটি ছোট পরিসরেও একই: প্যারামিটার সংখ্যা গুণিতক প্রতি ওয়েট বাইট, তার সাথে KV cache, এবং প্রায় 2 GB রানটাইম ওভারহেড—এই সবকিছুর যোগফল আপনার VRAM-এর ক্ষমতার নিচে থাকতে হবে। 4-bit কোয়ান্টাইজেশনে প্রতি প্যারামিটারে প্রায় অর্ধেক বাইট লাগে, যা নিচের কম্বিনেশনগুলোর জন্য উপযুক্ত:

• 16 GB কার্ড: 4-bit-এ একটি 7B মডেল, সাথে দীর্ঘ কনটেক্সটের জন্য পর্যাপ্ত জায়গা
• 24 GB কার্ড: 4-bit-এ একটি 14B মডেল
• 48 GB কার্ড: 4-bit-এ একটি 32B মডেল
• 80 GB কার্ড: 4-bit-এ একটি 70B মডেল, অথবা 8-bit-এ একটি 30B ক্লাসের MoE মডেল

GPU যুক্ত একটি VPS-এ দ্রুত সার্ভার চালু করার সবচেয়ে সহজ উপায় হলো Ollama:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run প্রথমবার ব্যবহারের সময় মডেলটি ডাউনলোড করে এবং আপনাকে সরাসরি প্রম্পটে নিয়ে যায়। এমন কোনো ট্যাগ ব্যবহার করলে যা বিদ্যমান নেই, তবে Error: model "..." not found ত্রুটি দেখাবে, তাই স্মৃতি থেকে টাইপ না করে লাইব্রেরি পেজ থেকে ট্যাগ কপি করুন। systemd unit এবং রিমোট অ্যাক্সেসসহ সম্পূর্ণ নির্দেশিকা running Ollama on a VPS-এ দেওয়া আছে।

llama.cpp আপনাকে কোয়ান্টাইজেশন এবং অফলোডের ওপর আরও বেশি নিয়ন্ত্রণ দেয়:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 প্রতিটি লেয়ারকে GPU-তে রাখার নির্দেশ দেয়। লোড লগটি পড়ুন: এটি দেখাবে কতগুলো লেয়ার অফলোড করা হয়েছে। যে লেয়ারগুলো সিস্টেম RAM-এ চলে যায়, সেগুলো HBM ব্যান্ডউইথের পরিবর্তে RAM ব্যান্ডউইথে কাজ করে, তাই মডেলটি VRAM-এ পুরোপুরি না ধরলে জেনারেশনের গতি বহুগুণ কমে যায়। এই দুটি টুলের মধ্যে পার্থক্য Ollama and llama.cpp side by side-এ আলোচনা করা হয়েছে।

Tier 3: hosted API, self-hosted orchestration

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

এই endpoint-টি OpenAI-এর সাথে সামঞ্জস্যপূর্ণ, তাই base URL পরিবর্তন করার পর আপনার বিদ্যমান client-টি কাজ করবে।

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

একটি কার্যকর key একটি JSON object প্রদান করে যাতে একটি choices array থাকে। একটি 401 নির্দেশ করে যে key-টি ভুল অথবা এতে Bearer prefix-টি অনুপস্থিত। model-not-found error সাধারণত নির্দেশ করে যে id পরিবর্তিত হয়েছে, কারণ provider-রা checkpoint-এর মধ্যবর্তী সময়ে id বাতিল করে দেয়।

এখন ব্রেক-ইভেন বা খরচের সমতা বিবেচনা করা যাক, উপরে উল্লেখিত ভাড়ার হার ব্যবহার করে। একটি সবসময় চালু থাকা 8 GPU node-এর মাসিক খরচ 14,400 USD এবং প্রতি মিলিয়ন output token-এর জন্য 15.00 USD হারে, একই খরচে API থেকে প্রায় 960 মিলিয়ন output token পাওয়া সম্ভব। খরচের দিক থেকে লাভবান হতে হলে আপনাকে মাসে প্রায় এক বিলিয়ন output token জেনারেট করতে হবে, যা প্রতিদিন প্রায় 30 মিলিয়ন, এবং পুরো সময় জুড়ে cluster-টিকে ব্যস্ত রাখতে হবে, কারণ idle GPU-এর বিল ব্যস্ত GPU-এর মতোই আসে। prompt-নির্ভর agent workload-এর ক্ষেত্রে এই লক্ষ্যমাত্রা আরও দূরে সরে যায়: বারবার ব্যবহৃত context-এর বিল cache-hit রেট অনুযায়ী প্রতি মিলিয়নে 0.30 USD হারে আসে, যা cache-miss রেট 3.00 USD-এর চেয়ে আলাদা।

এই tier-এ আপনি মডেলের চারপাশের সবকিছু self-host করেন: একটি gateway যা API key-কে ধরে রাখে যাতে এটি কখনোই client-এর কাছে না পৌঁছায়, request ও response লগ, retry, rate limit এবং প্রতি ব্যবহারকারীর বাজেট। এটি কোনো GPU ছাড়া একটি ছোট VPS-এ চলে। একই বিভাজন closed weight-এর ক্ষেত্রেও প্রযোজ্য, যেখানে Claude self-hosting মডেল লেভেলে সম্ভব নয় এবং orchestration-ই একমাত্র অংশ যা আপনার নিয়ন্ত্রণে থাকে।

কোন সার্ভিং স্ট্যাক কোন টায়ারের অন্তর্ভুক্ত

vLLM এবং SGLang ক্লাস সার্ভারগুলো টায়ার 1-এর অন্তর্ভুক্ত। এগুলো একসাথে অনেক অনুরোধ (request) প্রসেস করার জন্য তৈরি, যেখানে continuous batching, paged KV cache এবং একাধিক নোড জুড়ে tensor ও expert parallelism ব্যবহৃত হয়। এগুলো ডেটাসেন্টার-গ্রেড এক্সিলারেটর এবং সেগুলোর মধ্যে দ্রুত ইন্টারকানেক্টের ওপর নির্ভর করে। একটি সাধারণ কনজিউমার কার্ডে এগুলো ইনস্টল করা জটিল এবং এতে আপনি তেমন কোনো বাড়তি সুবিধা পাবেন না।

llama.cpp এবং Ollama টায়ার 2-এর অন্তর্ভুক্ত। এগুলো একটি নির্দিষ্ট মেশিনের জন্য তৈরি, যেখানে GGUF কোয়ান্টাইজেশন, মডেল মেমোরিতে না ধরলে CPU অফলোড এবং কম কনকারেন্সি (concurrency) ব্যবহার করা হয়। প্রযুক্তিগতভাবে, llama.cpp অধিকাংশ লেয়ার সিস্টেম RAM-এ রেখে বিশাল আকারের MoE মডেল লোড করতে পারে, তবে 2.8টি মডেলের ক্ষেত্রে প্রতিটি টোকেনের জন্য কয়েক সেকেন্ড সময় লাগতে পারে। এটি কেবল প্রমাণ করে যে ফাইলটি পার্স করা যাচ্ছে। এটি এমন কোনো সার্ভিস নয় যা আপনি সরাসরি ব্যবহারকারীদের জন্য উন্মুক্ত করতে পারেন। বিস্তারিত তুলনা Ollama বনাম vLLM-এ দেওয়া আছে, এবং মডেল পরিবর্তনের সাথে এই পার্থক্যের কোনো পরিবর্তন হয় না: মূল প্রশ্নটি হলো আপনি কি শেয়ার্ড হার্ডওয়্যারে অনেক ব্যবহারকারীকে সার্ভিস দিচ্ছেন, নাকি নিজের মেশিনে একজন ব্যবহারকারীর জন্য এটি চালাচ্ছেন।

যে চারটি সংখ্যা এই চেকপয়েন্টের পরেও টিকে থাকে

1. মোট প্যারামিটার এবং প্রতি ওয়েটের বাইট গুণ করলে মেমোরির সর্বনিম্ন সীমা পাওয়া যায়। এর নিচে কোনো কিছুই চলে না এবং একবার রিলিজ 4-বিটে চলে আসলে কোনো কোয়ান্টাইজেশন ট্রিকই একে খুব একটা পরিবর্তন করতে পারে না।
2. সক্রিয় প্যারামিটার থ্রুপুট ক্লাস নির্ধারণ করে। 104বি সক্রিয় প্যারামিটারসহ একটি 2.8টি এমওই (MoE) মডেল 104বি মডেলের মতোই কম্পিউটেশনাল ক্ষমতা রাখে।
3. প্রতি টোকেনে কেভি ক্যাশ (KV cache), কনটেক্সট লেন্থ এবং কনকারেন্সি গুণ করলে যে খরচ পাওয়া যায়, তা ওয়েটের জন্য খরচ করার পরেও ক্রমাগত বাড়তে থাকে।
4. প্রতি ডলারে প্রতি সেকেন্ডে টোকেন সংখ্যাই একমাত্র সংখ্যা যা একটি টিয়ার নির্ধারণ করে। উপরের সবকিছুই এর ইনপুট হিসেবে কাজ করে।

যেকোনো রিলিজের ক্ষেত্রে এই চারটি বিষয় প্রয়োগ করুন, তাহলে ভেন্ডর গাইড খোলার আগেই আপনি সঠিক উত্তর পেয়ে যাবেন। এরপর আপনার লেখা প্রতিটি সংখ্যার সাথে তারিখ উল্লেখ করুন। কে3 (K3) লঞ্চ হওয়ার দুই সপ্তাহের মধ্যেই দাম এবং সমর্থিত আর্কিটেকচারের তালিকা পরিবর্তিত হয়েছে, এবং এই পৃষ্ঠার প্রতিটি সংখ্যা জুলাই 2026-এ প্রকাশিত।

FAQ

আমি কি একটি মাত্র GPU-তে Kimi K3 চালাতে পারি?

না। Moonshot যে MXFP4 প্রিসিশনে এটি রিলিজ করেছে, তাতে এর ওয়েট বা ওজন প্রায় 1.4 TB, আর বর্তমানে বাজারে থাকা সবচেয়ে বড় একক এক্সিলারেটরে 288 GB মেমোরি থাকে। একটি MoE মডেলের নিষ্ক্রিয় এক্সপার্টদের ডিস্ক থেকে ব্যবহারের উপযোগী গতিতে স্ট্রিম করা সম্ভব নয়, কারণ রাউটার যেকোনো টোকেনের জন্য যেকোনো এক্সপার্টকে বেছে নিতে পারে এবং PCIe ফেচ করার সময় টোকেন বাজেটের চেয়ে অনেক বেশি সময় নেয়। Kimi K3 চালানোর জন্য সবচেয়ে ছোট কার্যকর সেটআপ হলো মাল্টি-GPU নোড, এবং প্রকাশিত রেসিপিগুলোতে 32টি বা তার বেশি এক্সিলারেটর ব্যবহারের পরামর্শ দেওয়া হয়েছে।

Kimi K3-এর জন্য কতটুকু VRAM প্রয়োজন?

শুধুমাত্র ওয়েটের জন্যই 1.4 TB দিয়ে শুরু করতে হবে, যার জন্য H100 80GB কার্ডের ক্ষেত্রে 18টি অথবা GB300 ক্লাসের কার্ডের ক্ষেত্রে 5টি কার্ড প্রয়োজন। এর সাথে KV ক্যাশ এবং অ্যাক্টিভেশন মেমোরি যোগ করতে হবে। আগস্ট 2026 অনুযায়ী Moonshot 64টি বা তার বেশি এক্সিলারেটর ব্যবহারের পরামর্শ দেয়। SGLang কুকবুকে 32টি H100 GPU-এর একটি কনফিগারেশন দেওয়া হয়েছে যেখানে মোট 2,560 GB মেমোরি রয়েছে, তাই ওয়েটের এই হিসাবটিকে একটি ন্যূনতম সীমা হিসেবে ধরুন, প্রয়োজনীয় মেমোরির চূড়ান্ত পরিমাণ হিসেবে নয়।

কোয়ান্টাইজেশন করলে কি Kimi K3 একটি নোডে চালানো সম্ভব?

কার্যকরভাবে সম্ভব নয়। রিলিজ করা চেকপয়েন্টটি ইতিমধ্যেই কোয়ান্টাইজেশন-অ্যাওয়ার ট্রেনিংয়ের মাধ্যমে 4-বিট করা হয়েছে, তাই সহজ উপায়ে মেমোরি কমানোর সুযোগ আর নেই। এটিকে 2-বিটে নামিয়ে আনলে ওয়েটের পরিমাণ দাঁড়ায় 0.7 TB, যা এখনো সবচেয়ে বড় কার্ডের ধারণক্ষমতার দ্বিগুণেরও বেশি। তাছাড়া এই মডেলে 2-বিটের ক্ষেত্রে নির্ভুলতা বা অ্যাকুরেসি কতটা কমবে তা এখনো পরিমাপ করা হয়নি।

Kimi K3 API ব্যবহারের চেয়ে GPU ভাড়া করা কি সাশ্রয়ী?

শুধুমাত্র উচ্চ এবং নিয়মিত ভলিউমের ক্ষেত্রে এটি সাশ্রয়ী হতে পারে। প্রতি GPU ঘণ্টা 2.50 USD হিসেবে, সবসময় চালু থাকা একটি 8 GPU নোডের মাসিক খরচ 14,400 USD। একই খরচে 15.00 USD প্রতি মিলিয়ন টোকেন রেটে প্রায় 960 মিলিয়ন আউটপুট টোকেন কেনা সম্ভব। এছাড়া আপনাকে অলস সময়ের খরচ, ওয়েট ডাউনলোড এবং ক্লাস্টার রক্ষণাবেক্ষণের জন্য জনবলের খরচও বহন করতে হবে। কাজের চাপের সময় ঘণ্টা হিসেবে ভাড়া নিন এবং অনুমানের ওপর ভিত্তি না করে আপনার নিজের পরিমাপ করা টোকেন ভলিউমের সাথে তুলনা করুন।

104B অ্যাক্টিভ প্যারামিটার গতির ক্ষেত্রে কী বোঝায়?

এর অর্থ হলো প্রতি টোকেনের জন্য গাণিতিক হিসাব 104B মডেলের সমান, তাই এর থ্রুপুট 2.8T ক্লাসের বদলে 104B ক্লাসের মতোই হবে। মেমোরির ক্ষেত্রে এর কোনো প্রভাব নেই: 2.8T প্যারামিটারের পুরোটাই মেমোরিতে থাকতে হয়, কারণ রাউটার যেকোনো টোকেনের জন্য যেকোনো এক্সপার্টকে কল করতে পারে। প্রতি সেকেন্ডে কতগুলো টোকেন জেনারেট হবে তা বোঝার জন্য অ্যাক্টিভ কাউন্ট ব্যবহার করুন এবং VRAM-এর আকার নির্ধারণের জন্য মোট প্যারামিটার কাউন্ট ব্যবহার করুন।