Kimi K3 self-host করতে কী কী দরকার

Kimi K3 self-host করতে যা প্রয়োজন

Kimi K3 self-host করতে 2.8 trillion parameter-এর জন্য পর্যাপ্ত জায়গা প্রয়োজন। Moonshot open weights-গুলো MXFP4-এ প্রকাশ করেছে। এতে প্রতি weight-এর জন্য প্রায় আধা byte লাগে। তাই cache-এর জন্য একটি token বরাদ্দ করার আগেই শুধু weights-এর আকার প্রায় 1.4 TB হয়। বর্তমানে বিক্রি হওয়া কোনো accelerator একা এই পরিমাণ ধারণ করতে পারে না। K3 একটি multi-node model। তাই একটি server-এর ক্ষেত্রে উত্তর হলো: সম্ভব নয়।

এটাই চূড়ান্ত সিদ্ধান্ত। নিচের অংশে এর পেছনের arithmetic দেখানো হয়েছে। কারণ পরবর্তী release-এর ক্ষেত্রে এই arithmetic আবার ব্যবহার করা যাবে। 17 July 2026 তারিখে ঘোষণার পরের কয়েক সপ্তাহে একাধিক infrastructure vendor K3 deployment guide প্রকাশ করেছিল। প্রতিটি guide-এই ধরে নেওয়া হয়েছিল যে আপনার কাছে আগে থেকেই একটি cluster আছে। এই পৃষ্ঠা বিপরীত দিক থেকে শুরু করছে: এর খরচ কত, এর পরিবর্তে কী চালানো যায়, এবং আপনি এই দুই অবস্থার কোনটিতে আছেন তা কীভাবে শনাক্ত করবেন।

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

K3 একটি mixture of experts model। MoE (mixture of experts) network-কে অনেক sub-network-এ ভাগ করে এবং প্রতিটি token-এর জন্য router সেগুলোর মধ্যে কয়েকটি বেছে নেয়। Model card-এ 2.8T total parameter এবং প্রতি token-এ 104B activated parameter উল্লেখ করা হয়েছে। এই হিসাবটি 896 routed expert-এর মধ্যে করা হয়, যার 16টি যেকোনো নির্দিষ্ট token-এর জন্য সক্রিয় হয়, এবং model-এ মোট 93টি layer আছে।

এই দুটি parameter count ভিন্ন প্রশ্নের উত্তর দেয়। প্রতিটি “can I run this” আলোচনায় এগুলো অদলবদল করাই সবচেয়ে সাধারণ ভুল।

সক্রিয় parameter compute cost নির্ধারণ করে। একটি token প্রায় 104B parameter-এর মধ্য দিয়ে গণনা করে। তাই প্রত্যাশিত throughput 2.8T model-এর চেয়ে 104B dense model-এর কাছাকাছি হবে। MoE তৈরির মূল কারণ এটাই।

মোট parameter memory cost নির্ধারণ করে। যেকোনো token-এর জন্য router যেকোনো expert বেছে নিতে পারে। তাই প্রথম request আসার আগেই প্রতিটি expert memory-তে উপস্থিত থাকতে হবে। VRAM-এ 104B parameter রেখে বাকি parameter প্রয়োজনমতো আনা সম্ভব নয়। কারণ fetch কয়েক microsecond-এর মধ্যে শেষ করতে হবে, অথচ PCIe link প্রতি second-এ কয়েক দশ gigabyte data স্থানান্তর করে। কেউ কেউ এটি চেষ্টা করেন। NVMe থেকে expert stream করলে প্রতি second-এ কয়েক ডজন token output দেওয়ার কথা এমন model-এর গতি কমে প্রতি কয়েক second-এ একটি token হয়ে যায়।

তাই compute করা তুলনামূলকভাবে সস্তা, কিন্তু store করা ব্যয়বহুল। Hardware-এর capacity 2.8T parameter অনুযায়ী নির্ধারণ করুন। Speed-এর প্রত্যাশা 104B parameter অনুযায়ী নির্ধারণ করুন।

প্রতি weight-এ byte এবং terabyte-এর উৎস

Parameter count × প্রতি weight-এ byte। Weight-এর ক্ষেত্রে পুরো হিসাবটি এটাই।

[
  {
    "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 quantisation-aware পদ্ধতিতে প্রশিক্ষিত এবং MXFP4 weight ও MXFP8 activation-সহ released হয়েছে। তাই 4-bit সারিটিই বাস্তব পরিস্থিতি দেখায়। এর উপরের সারিগুলো তুলনার জন্য রাখা হয়েছে: bf16 ব্যবহার করলে একই model-এর জন্য 5.6 TB প্রয়োজন হতো। MXFP4 প্রতি 32টি weight-এর প্রতিটি block-এর জন্য একটি shared 8-bit scale-ও সংরক্ষণ করে। এতে প্রায় 6 শতাংশ অতিরিক্ত স্থান লাগে। তাই published repository-এর আকার সরল হিসাবে নির্ণীত 1.4 TB-এর চেয়ে 1.5 TB-এর কাছাকাছি।

এতে প্রচলিত শেষ অবলম্বনটিও কার্যকর থাকে না। এখানে "শুধু quantise করুন" বললে কোনো লাভ নেই, কারণ released checkpoint ইতিমধ্যেই 4-bit। 2-bit-এ নামালে weight-এর আকার 0.7 TB-এ নেমে আসত। তবে এই checkpoint-এ এর ফলে accuracy কতটা কমবে, তা কেউ পরিমাপ করেনি। তবুও এটি যেকোনো একটি card-এর ক্ষমতার অনেক বাইরে থাকবে।

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 এবং একই সময়ে দ্বিতীয় request চালানোর জন্য অতিরিক্ত জায়গা ধরা হয়নি। এগুলো এমন একটি parallel split-ও ধরে নেয়, যা সমানভাবে ভাগ করা যায়। কিন্তু 93টি layer এবং 896টি expert সব সময় এভাবে ভাগ করা সম্ভব নয়।

প্রকাশিত নির্দেশনায় ন্যূনতম সীমার চেয়ে অনেক বেশি ক্ষমতার কথা বলা হয়েছে। August 2026 অনুযায়ী Moonshot 64 বা তার বেশি accelerator-সহ একটি supernode সুপারিশ করে। SGLang cookbook-এ চারটি 8-GPU node দিয়ে তৈরি একটি H100 configuration রয়েছে। এতে মোট 32টি GPU এবং 2,560 GB aggregate memory আছে। এর বিপরীতে weights-এর ন্যূনতম সীমা হলো 18টি card। এই পার্থক্য অপচয় নয়। এর মধ্যে KV cache, activation memory এবং server-কে একসঙ্গে অনেক request batch করার জন্য প্রয়োজনীয় অতিরিক্ত capacity অন্তর্ভুক্ত। এমনকি সবচেয়ে সুবিধাজনক সারিটিও—5 GB300 class card—এমন একটি machine বোঝায়, যা অধিকাংশ provider একক SKU হিসেবে rent দেয় না।

KV cache-ই সেই অংশ, যা অনেককে অবাক করে

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

নিচে একটি হিসাবের উদাহরণ দেওয়া হলো। এটি শুধু একটি উদাহরণ: 64টি layer, 8টি KV head, head dimension 128 এবং fp8। এতে 2 64 8 128 1 = 131,072 bytes হয়। অর্থাৎ প্রতি token-এ 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-এ একজন user-এর জন্য 16 GiB লাগে। পূর্ণ এক million context-এ একজন user-এর জন্য 128 GiB লাগে। একটি conversation-এর জন্য এই পরিমাণ যেকোনো একক card-এর ধারণক্ষমতার চেয়ে বেশি।

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

পরবর্তী release-এও এই যুক্তির কাঠামো প্রযোজ্য থাকবে। কোনো model যদি এক million token context সমর্থনের কথা বলে কিন্তু তার attention design সম্পর্কে কিছু না জানায়, তাহলে কেউ বিপরীতটি প্রমাণ না করা পর্যন্ত ধরে নিন যে cache-ই প্রধান সীমাবদ্ধতা।

স্তর 1: ঘণ্টাভিত্তিক cluster ভাড়া নিন

একমাত্র এই স্তরেই K3 নিজে চালানো হয়। hardware কিনতে হয় না। যত ঘণ্টা প্রয়োজন, তত ঘণ্টার জন্য ভাড়া নিন এবং কাজ শেষে এটি বন্ধ করুন।

[
  {
    "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"
  }
]

এখানে ব্যবহৃত rate একটি অনুমান, কোনো provider-এর quotation নয়। 2026 সাল পর্যন্ত datacentre accelerator-এর on-demand list price মোটামুটি প্রতি GPU ঘণ্টায় 2 থেকে 5 USD-এর মধ্যে ছিল। reserved capacity-এর দাম কম। আপনার provider-এর প্রকৃত rate নিয়ে হিসাবটি আবার করুন: GPUs times hours times rate। chart-এর উদ্দেশ্য অনুপাত দেখানো। প্রতিদিন 4 ঘণ্টা 8 GPU node চালালে মাসে 2,400 USD খরচ হয়। অন্যদিকে SGLang-এর জন্য নির্ধারিত 32 GPU configuration চালু রাখলে মাসে 57,600 USD খরচ হয়।

প্রধান দুই server-ই model card-এ launch command প্রকাশ করে।

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

বাস্তব cluster-এ চালানোর জন্য কোনো bare command-ই যথেষ্ট নয়। আপনার hardware অনুযায়ী parallelism flag যোগ করুন: tensor parallel-এর জন্য SGLang-এ --tp-size এবং expert parallel-এর জন্য --ep-size ব্যবহার করা হয়। এই দুই মানের গুণফল আপনার কাছে থাকা GPU-এর সংখ্যার সমান হতে হবে।

বাস্তব network traffic পাঠানোর আগে server চালু হয়েছে কি না পরীক্ষা করুন:

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

সুস্থ server model id-সহ একটি JSON object ফেরত দেয়। Connection refused মানে process এখনও weight load করছে অথবা ইতিমধ্যে বন্ধ হয়ে গেছে। তাই আবার চেষ্টা করার আগে server log পরীক্ষা করুন।

প্রথম দিনের সাধারণ সমস্যা হলো model-এর তুলনায় runtime পুরোনো। K3-এর সঙ্গে KDA এবং একটি নতুন MoE layer প্রকাশিত হয়েছিল, কিন্তু stable vLLM ও SGLang release-এ launch-এর সময় সেগুলোর support ছিল না। এর লক্ষণ হলো startup-এর সময় server Model architectures [...] are not supported for now ধরনের একটি line দেখিয়ে বন্ধ হয়ে যায়। কোনো configuration পরিবর্তনে এটি ঠিক হবে না, কারণ ওই layer চালানোর code আপনার build-এ নেই। model card-এ উল্লেখ করা nightly install করুন, অথবা support-সহ release প্রকাশ হওয়া পর্যন্ত অপেক্ষা করুন।

আরেকটি খরচের বিষয় মনে রাখুন। instance চালু হওয়ার সময় meter শুরু হয়, model ready হওয়ার সময় নয়। 1 GB/s গতিতে 1.5 TB download করতে প্রায় 25 মিনিট লাগে। অর্থাৎ প্রথম token পাওয়ার আগেই cluster-এর প্রায় 25 মিনিটের খরচ হয়। এমন একটি volume-এ weight রাখুন, যা instance বন্ধ হলেও টিকে থাকে। তাহলে দ্বিতীয়বার চালু করতে কয়েক মিনিট লাগবে।

Tier 2: একটি accelerator-এ ছোট model চালান

এই tier-এ আপনি K3 চালাচ্ছেন না। শুরু করার আগে এটি স্পষ্টভাবে মনে রাখুন, কারণ “K3 locally চালানো” নিয়ে অধিকাংশ আলোচনা এখানেই শেষ হয়, কিন্তু তা স্বীকার করা হয় না।

Fit rule একই formula-এর সংক্ষিপ্ত সংস্করণ: parameters × প্রতি weight-এ bytes, তার সঙ্গে KV cache এবং প্রায় 2 GB runtime overhead যোগ করলে মোট পরিমাণ আপনার VRAM-এর মধ্যে থাকতে হবে। 4-bit-এ প্রতি parameter-এর জন্য এটি প্রায় আধা byte, তাই নিচের pairing-গুলোতে যথেষ্ট headroom থাকে:

• 16 GB card: 4-bit-এ একটি 7B model, এবং দীর্ঘ context-এর জন্য অতিরিক্ত জায়গা
• 24 GB card: 4-bit-এ একটি 14B model
• 48 GB card: 4-bit-এ একটি 32B model
• 80 GB card: 4-bit-এ একটি 70B model, অথবা 8-bit-এ 30B class MoE

উপরের প্রতিটি pairing একসঙ্গে একটি request ধরে নেওয়া হয়েছে। দ্বিতীয় কোনো ব্যক্তি prompt পাঠানোর সঙ্গে সঙ্গে প্রতিটি concurrent slot-এর নিজস্ব KV cache দরকার হয়। আপনার অবশিষ্ট VRAM অনুযায়ী parallel slot, queued request এবং VRAM-এর মধ্যে এই trade Ollama-এর NUM_PARALLEL এবং MAX_QUEUE settings আপনার হয়ে নির্ধারণ করে।

GPU সংযুক্ত একটি VPS-এ কার্যকর server চালু করার সবচেয়ে সংক্ষিপ্ত পথ হলো Ollama:

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

প্রথমবার ব্যবহারের সময় ollama run model download করে, তারপর আপনাকে prompt-এ নিয়ে যায়। অস্তিত্বহীন tag দিলে Error: model "..." not found ফেরত আসে। তাই tag মনে করে লেখার বদলে library page থেকে copy করুন। systemd unit এবং remote access-সহ সম্পূর্ণ নির্দেশনা VPS-এ Ollama চালানো-এ আছে।

Quantisation এবং offload-এর ওপর 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-তে প্রতিটি layer load করার অনুরোধ করে। Load log পরীক্ষা করুন: সেখানে কতটি layer offload হয়েছে তা দেখানো হয়। যেসব layer system RAM-এ চলে যায়, সেগুলো HBM bandwidth-এর বদলে RAM bandwidth ব্যবহার করে। তাই model আর fit না করলেই generation speed এক order of magnitude কমে যায়। দুটি tool-এর trade-off Ollama এবং llama.cpp পাশাপাশি-এ ব্যাখ্যা করা হয়েছে।

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 compatible, তাই 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 বাতিল করে।

এখন উপরে ধরা rental rate ব্যবহার করে break-even হিসাব করা যাক। সবসময় চালু থাকা 8 GPU node-এর মাসিক খরচ 14,400 USD। একই অর্থে 15.00 USD প্রতি million output tokens হারে API থেকে প্রায় 960 million output tokens কেনা যায়। খরচের দিক থেকে self-hosting লাভজনক করতে মাসে প্রায় এক billion output tokens, অর্থাৎ দিনে প্রায় 30 million output tokens, generate করতে হবে এবং পুরো সময় cluster-কে ব্যস্ত রাখতে হবে। কারণ idle GPU এবং ব্যস্ত GPU একই হারে bill হয়। Prompt-heavy agent workload হলে ব্যবধান আরও বাড়ে: বারবার ব্যবহৃত context-এর জন্য cache-hit rate অনুযায়ী প্রতি million tokens-এ 0.30 USD দিতে হয়, cache-miss rate অনুযায়ী 3.00 USD নয়।

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

কোন serving stack কোন tier-এর অন্তর্ভুক্ত

vLLM এবং SGLang শ্রেণির server tier 1-এর অন্তর্ভুক্ত। এগুলো একই সময়ে অনেক অনুরোধ পরিবেশনের জন্য তৈরি। এতে continuous batching, paged KV cache এবং একাধিক node জুড়ে tensor ও expert parallelism থাকে। এগুলো datacentre accelerator এবং accelerator-গুলোর মধ্যে দ্রুত interconnect ধরে নিয়ে কাজ করে। একটি consumer card-এ এগুলো install করা তুলনামূলকভাবে বেশি জটিল। সেখানে আপনি খুব কম বাস্তব সুবিধা পাবেন।

llama.cpp এবং Ollama tier 2-এর অন্তর্ভুক্ত। এগুলো একটি machine, GGUF quantisation, model memory-তে না ধরলে CPU offload এবং কম concurrency-এর জন্য তৈরি। llama.cpp বেশির ভাগ layer system RAM-এ রেখে একটি অত্যন্ত বড় MoE technically load করতে পারে। তবে 2.8T model-এর ক্ষেত্রে এই পদ্ধতিতে প্রতি token-এ কয়েক সেকেন্ড সময় লাগে। এতে শুধু প্রমাণ হয় যে file-টি parse করা যায়। এটি এমন service নয় যেখানে users-কে যুক্ত করা যায়। সম্পূর্ণ তুলনা Ollama বনাম vLLM-এ আছে। model পরিবর্তন হলেও মূল সিদ্ধান্ত বদলায় না: আপনি shared hardware-এ অনেক user-কে service দিচ্ছেন, নাকি নিজের machine-এ একজন user-কে service দিচ্ছেন।

এই checkpoint-এর পরেও কার্যকর থাকা 4টি সংখ্যা

1. মোট parameter-সংখ্যাকে প্রতি weight-এর byte-সংখ্যা দিয়ে গুণ করলে memory floor পাওয়া যায়। এর নিচে কিছুই চালানো যায় না। Release ইতিমধ্যে 4-bit হলে কোনো quantisation কৌশলও এই সীমা উল্লেখযোগ্যভাবে কমাতে পারে না।
2. Active parameter-সংখ্যা throughput class নির্ধারণ করে। 2.8T MoE-তে 104B active parameter থাকলে সেটি 104B model-এর মতো compute করে।
3. প্রতি token-এর KV cache, context length এবং concurrency দিয়ে গুণ করলে সেই খরচ পাওয়া যায়, যা weight-এর জন্য অর্থ পরিশোধ করার পরেও বাড়তে থাকে।
4. প্রতি dollar-এ tokens per second-ই একমাত্র সংখ্যা, যা একটি tier নির্বাচন করে। উপরের সবকিছু এই হিসাবের input।

যেকোনো release-এর ক্ষেত্রে এই 4টি বিষয় প্রয়োগ করলে vendor guide খোলার আগেই সঠিক উত্তর পাওয়া যায়। এরপর আপনি লিখে রাখা প্রতিটি figure-এর তারিখ উল্লেখ করুন। K3 launch হওয়ার পরের দুই সপ্তাহে price এবং supported-architecture list—উভয়ই পরিবর্তিত হয়েছে। এই page-এর প্রতিটি সংখ্যা July 2026-এ প্রকাশিত।

FAQ

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

না। Moonshot যে MXFP4 precision-এ এটি প্রকাশ করে, তাতে weights-এর আকার প্রায় 1.4 TB, আর বাজারে বিক্রি হওয়া সবচেয়ে বড় single accelerator-এ 288 GB ধারণক্ষমতা থাকে। একটি MoE model তার inactive expert-গুলো disk থেকে ব্যবহারযোগ্য গতিতে stream করতে পারে না, কারণ router যেকোনো token-এর জন্য যেকোনো expert বেছে নিতে পারে এবং PCIe fetch সম্পন্ন হতে token budget-এর অনুমোদিত সময়ের চেয়ে অনেক বেশি সময় লাগে। K3 চালানোর জন্য বাস্তবসম্মত সর্বনিম্ন deployment হলো একটি multi-GPU node। প্রকাশিত recipe-গুলোতে 32টি accelerator বা তার বেশি ব্যবহার করা হয়।

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

শুধু weights-এর জন্য 1.4 TB থেকে শুরু করুন। এটি 18টি H100 80GB card অথবা 5টি GB300 class card-এর সমান। এর সঙ্গে KV cache এবং activation memory যোগ করতে হবে। August 2026 অনুযায়ী Moonshot 64টি বা তার বেশি accelerator ব্যবহারের সুপারিশ করে। SGLang cookbook-এ 2,560 GB aggregate memory-সহ 32 GPU H100 configuration প্রকাশিত হয়েছে। তাই weights-এর হিসাবটিকে minimum floor হিসেবে ধরুন, সম্পূর্ণ requirement হিসেবে নয়।

Quantisation করলে কি Kimi K3 একটি node-এ fit করবে?

ব্যবহারযোগ্যভাবে নয়। প্রকাশিত checkpoint-টি quantisation-aware training-সহ ইতিমধ্যে 4-bit, তাই সহজে পাওয়া memory saving আগেই করা হয়েছে। আবার 2-bit-এ নামালে weights-এর আকার 0.7 TB হবে। এটিও সবচেয়ে বড় card-এর ক্ষমতার দ্বিগুণের বেশি। এই model-এ 2-bit quantisation-এর accuracy cost এখনও মাপা হয়নি।

GPU rent করা কি Kimi K3 API ব্যবহারের চেয়ে সস্তা?

শুধু উচ্চ এবং স্থিতিশীল volume থাকলে। প্রতি GPU hour 2.50 USD ধরে নিলে, সবসময় চালু থাকা 8 GPU node-এর মাসিক খরচ 14,400 USD। একই অর্থে প্রকাশিত 15.00 USD প্রতি million output token rate-এ প্রায় 960 million output token কেনা যায়। এর বাইরে idle hour, weights download এবং cluster সচল রাখার দায়িত্বে থাকা ব্যক্তির খরচও দিতে হবে। burst workload-এর জন্য hour হিসেবে rent করুন। অনুমানের বদলে নিজের মাপা token volume-এর সঙ্গে তুলনা করুন।

Speed-এর ক্ষেত্রে 104B active parameters বলতে কী বোঝায়?

এর অর্থ প্রতি token-এ arithmetic-এর পরিমাণ 104B model-এর সমতুল্য। তাই throughput 2.8T class-এর বদলে 104B class-এর কাছাকাছি হবে। এটি memory সম্পর্কে কিছু বলে না। সব 2.8T parameter memory-তে resident থাকে, কারণ router যেকোনো token-এর জন্য যেকোনো expert call করতে পারে। প্রতি second-এ কত token প্রক্রিয়াকরণ হবে তা অনুমান করতে active count ব্যবহার করুন। VRAM-এর capacity নির্ধারণ করতে total count ব্যবহার করুন।