দ্বারা Kimi K3 self-host করতে কী কী দরকার
Kimi K3-এর 2.8 trillion parameter চালাতে VRAM কত লাগে, KV cache-এর হিসাব কী, এবং 32 GPU cluster ছাড়া চালানোর 3টি বাস্তব উপায় জানুন।
Kimi K3 নিজে হোস্ট করতে যা প্রয়োজন
Kimi K3 নিজে হোস্ট করতে 2.8 trillion parameter-এর জন্য পর্যাপ্ত জায়গা প্রয়োজন। Moonshot open weights MXFP4-এ প্রকাশ করেছে। এতে প্রতি weight প্রায় half a byte লাগে। তাই cache-এর জন্য একটি token বরাদ্দ করার আগেই শুধু weights-এর আকার প্রায় 1.4 TB হয়। বর্তমানে বিক্রি হওয়া কোনো accelerator একাই এই পরিমাণ ধারণ করতে পারে না। একটি GPU-এর ক্ষেত্রে উত্তর হলো না। একটি server-এর ক্ষেত্রে দুটি উপায়ে উত্তর হলো হ্যাঁ। প্রথমটি হলো 288 GB accelerator-সহ 8-GPU node। প্রকাশিত সবচেয়ে ছোট multi-user serving recipe-গুলো এই ধরনের node ব্যবহার করে। দ্বিতীয়টি হলো প্রায় 1.6 TB সম্মিলিত RAM এবং VRAM-সহ একটি machine, যেখানে GPU থাকতেও পারে, নাও পারে, এবং Unsloth-এর lossless Q8 GGUF llama.cpp-এ চালিয়ে একবারে একজন user-কে service দেওয়া হয়।
এটাই সিদ্ধান্ত। পরের অংশে এর পেছনের হিসাব দেওয়া হয়েছে, কারণ পরবর্তী release-এও এই হিসাবই কাজে লাগবে। 16 July 2026-এর announcement-এর পরের কয়েক সপ্তাহে একাধিক infrastructure vendor K3 deployment guide প্রকাশ করেছে। প্রতিটি guide ধরে নিয়েছে যে আপনার কাছে আগে থেকেই একটি cluster আছে। এই page অন্য দিক থেকে শুরু করছে: খরচ কত, এর পরিবর্তে কী চালানো যায়, এবং ওই দুটি পরিস্থিতির কোনটিতে আপনি আছেন তা কীভাবে নির্ধারণ করবেন।
মোট parameter এবং সক্রিয় parameter-এর সংখ্যা এক নয়
K3 একটি mixture of experts মডেল। MoE (mixture of experts) নেটওয়ার্ককে অনেকগুলো sub-network-এ ভাগ করে এবং প্রতি token-এর জন্য একটি router সেগুলোর মধ্যে কয়েকটি বেছে নেয়। Model card-এ 2.8T মোট parameter এবং প্রতি token-এ 104B সক্রিয় parameter উল্লেখ করা হয়েছে। মোট 896টি routed expert-এর মধ্যে যেকোনো token-এর জন্য 16টি সক্রিয় হয়, এবং এই ব্যবস্থা 93টি layer জুড়ে প্রযোজ্য।
এই দুটি parameter count ভিন্ন প্রশ্নের উত্তর দেয়। প্রতিবার “এটি চালানো যাবে কি?” ধরনের আলোচনায় এগুলো অদলবদল করাই সবচেয়ে সাধারণ ভুল।
সক্রিয় parameter compute cost নির্ধারণ করে। একটি token প্রায় 104B parameter-এর মধ্য দিয়ে গণনা করে। তাই প্রত্যাশিত throughput 2.8T মডেলের চেয়ে 104B dense model-এর কাছাকাছি হবে। MoE তৈরির মূল কারণ এটাই।
মোট parameter memory cost নির্ধারণ করে। যেকোনো token-এর জন্য router যেকোনো expert বেছে নিতে পারে। তাই প্রথম request আসার আগেই প্রতিটি expert-কে দ্রুতগতির কোনো storage-এ রাখতে হবে। শুধু বেশি ব্যবহৃত expert-গুলো VRAM-এ রেখে বাকিগুলো প্রয়োজনমতো আনার ব্যবস্থাও আছে। llama.cpp-এর --moe-cache-mib system RAM-এ থাকা expert-গুলোর জন্য GPU cache রাখে এবং router কোনো অনুপস্থিত expert বেছে নিলে সেটি upload করে। তবে এতে মোট size কমে না। বাকি expert-গুলোকে RAM-এ রেখেই দিতে হয়। PCIe link প্রতি second-এ কয়েক দশ gigabyte data স্থানান্তর করে, যেখানে HBM প্রতি second-এ terabyte-পর্যায়ের data স্থানান্তর করতে পারে। তাই প্রতিটি cache miss সময় ব্যয় করে। Model RAM-এ না ধরলে NVMe থেকে expert stream করা আরও ধীর। Unsloth-এর K3 guide-এও বলা হয়েছে যে disk offloading অনেক ধীরগতিতে চলে।
তাই compute করা তুলনামূলক সস্তা, কিন্তু সংরক্ষণ করা ব্যয়বহুল। Hardware-এর capacity 2.8T অনুযায়ী নির্ধারণ করুন। Speed-এর প্রত্যাশা 104B অনুযায়ী নির্ধারণ করুন।
প্রতি weight-এ bytes, এবং terabyte-এর উৎস
Weight-এর সংখ্যা দিয়ে প্রতি weight-এ bytes গুণ করলেই ফল পাওয়া যায়। 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 weights ও MXFP8 activations সহ released হয়েছে। তাই 4-bit row-টিই প্রকৃত হিসাব। তার ওপরের row-গুলো তুলনার জন্য রাখা হয়েছে: bf16 ব্যবহার করলে একই model-এর 5.6 TB প্রয়োজন হতো। MXFP4 প্রতি 32টি weight-এর block-এর জন্য একটি shared 8-bit scale-ও সংরক্ষণ করে, এতে প্রায় 6 percent অতিরিক্ত স্থান লাগে। এছাড়া Moonshot-এর config attention, shared experts এবং vision tower-কে 4-bit format-এর বাইরে রাখে। তাই Unsloth-এর হিসাবে পুরো checkpoint-এর আকার প্রায় 1.56 TB, সরল 1.4 TB নয়।
এতে প্রচলিত বিকল্পটি সীমিত হয়, তবে পুরোপুরি বন্ধ হয় না। Released checkpoint ইতিমধ্যে 4-bit, তাই সহজে সাশ্রয় করার সুযোগটি ব্যবহার করা হয়ে গেছে। তবে আরও কম bit ব্যবহার করলে আকার এখনও কমে। 27 October 2026 পর্যন্ত Unsloth-এর পরিমাপ অনুযায়ী K3-এর dynamic GGUF quantisation-গুলোর আকার 2-bit UD-Q2_K_XL-এর 861.3 GB থেকে 1-bit UD-IQ1_S-এর 594 GB পর্যন্ত। এই কমানোর মূল্যও Unsloth প্রকাশ করেছে: full model-এর সঙ্গে top-1 token agreement UD-Q2_K_XL-এ 90.390 percent, 711.1 GB-এর UD-IQ2_XXS-এ 84.127 percent এবং UD-IQ1_S-এ 78.875 percent। Unsloth-এর Hugging Face repo-তে আরও ছোট 1-bit file-ও আছে, যার আকার UD-Q1_0-এর ক্ষেত্রে 466 GB পর্যন্ত নামেছে; তবে সেগুলোর পাশে কোনো agreement figure প্রকাশ করা হয়নি। এটি পরিমাপযোগ্য accuracy loss। এমনকি সবচেয়ে ছোট file-টির আকারও এখনও সবচেয়ে বড় single card-এর প্রায় 1.6 গুণ।
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 এবং একই সময়ে দ্বিতীয় অনুরোধ চালানোর জন্য অতিরিক্ত সক্ষমতা ধরা হয়নি। GPU ভাগটি সমান হওয়া বাধ্যতামূলক নয়। vLLM-এর pipeline parallelism মডেলকে layer অনুযায়ী ভাগ করে এবং অসম ভাগ সমর্থন করে। SGLang-এর K3 prefill recipe-গুলো 93টি layer-এর জন্য 8 এবং 16টি pipeline stage ব্যবহার করে।
প্রকাশিত নির্দেশনায় ন্যূনতম সীমার চেয়ে বেশি সক্ষমতা ধরা হয়েছে। Moonshot-এর launch guidance-এ 64 বা তার বেশি accelerator-সমৃদ্ধ একটি supernode ব্যবহারের সুপারিশ করা হয়েছিল। 27 October 2026 অনুযায়ী SGLang cookbook-এ চারটি 8-GPU node দিয়ে তৈরি একটি H100 configuration রয়েছে। এতে মোট 32টি GPU এবং 2,560 GB aggregate memory আছে, যেখানে ন্যূনতম সীমা হলো 18টি card। একই cookbook-এ একটি 8-GPU B300 node এবং একটি 8-GPU MI350X বা MI355X node-এর single-node recipe-ও আছে। সেখানে প্রতি card-এ 288 GB হিসেবে মোট 2,304 GB memory দেওয়া হয়েছে। ন্যূনতম সীমার চেয়ে এই অতিরিক্ত সক্ষমতা অপচয় নয়। এটি KV cache, activation memory এবং একসঙ্গে অনেক অনুরোধ batch করার জন্য প্রয়োজনীয় headroom সরবরাহ করে। সবচেয়ে সুবিধাজনক row-এর 5 GB300 class card-গুলো বাস্তবে এমন একটি 8-GPU node-এ round up করতে হয়। এটিই সবচেয়ে ছোট machine যার জন্য multi-user K3 serving recipe প্রকাশিত হয়েছে।
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টি layer, 8টি KV head, head dimension 128 এবং fp8। এতে 2 64 8 128 1 = 131,072 byte হয়, অর্থাৎ প্রতি 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-এর জন্যই 288 GB card-এর প্রায় অর্ধেক memory লাগে, কোনো weight load করার আগেই।
K3 সাধারণ attention ব্যবহার করে না, এবং শেষের সংখ্যাটিই এর কারণ। এর 93টি layer-এর মধ্যে 69টি KDA (Kimi Delta Attention) layer এবং 24টি Gated MLA (multi-head latent attention) layer। KDA এমন একটি fixed-size recurrent state রাখে, যা প্রতিটি token-এর সঙ্গে বাড়তে থাকা cache-এর পরিবর্তে ব্যবহৃত হয়। MLA key এবং value-কে একটি low-rank latent vector-এ compress করে। ফলে প্রতি token-এর প্রকৃত খরচ উপরের হিসাবের উদাহরণের তুলনায় অনেক কমে যায়। Moonshot-এর প্রকাশিত config.json-এ latent-এর আকার হিসেবে 512-এর একটি kv_lora_rank এবং 64-wide rotary key (qk_rope_head_dim) দেওয়া আছে। তাই প্রতি MLA layer-এ প্রতি token-এর জন্য মোট 576টি value থাকে। 24টি layer এবং প্রতিটি value-তে 2 byte ধরলে 27,648 byte হয়, অর্থাৎ প্রতি token-এ প্রায় 27 KiB। পূর্ণ 1,048,576 token-এর একটি conversation-এর জন্য এটি প্রায় 27 GiB, এর সঙ্গে fixed KDA state আলাদা যোগ হবে। এটিকে measurement নয়, estimate হিসেবে ধরুন: engine-গুলো cache নিজেদের পদ্ধতিতে pad ও layout করে, এবং 8-bit cache ব্যবহার করলে আকার প্রায় অর্ধেক হয়।
আপনার নিজস্ব deployment-এ কী রাখা হচ্ছে তা দেখতে --max-model-len বাড়ানোর সময় nvidia-smi monitor করবেন না। vLLM তার KV cache pool আগে থেকেই preallocate করে। এই pool-এর আকার --gpu-memory-utilization থেকে নির্ধারিত হয় (বর্তমান docs-এ default হিসেবে 0.92), অথবা প্রতি GPU-এর জন্য নির্দিষ্ট cache budget থেকে নির্ধারিত হয়। তাই মোট GPU memory একটি conversation-এর পরিবর্তে পুরো pool-এর আকার দেখায়। Startup log পড়ুন। সেখানে vLLM KV cache-এর আকার token-এ এবং আপনার context length-এ maximum concurrency দেখায়।
পরবর্তী release-এও এই যুক্তির কাঠামো অপরিবর্তিত থাকবে। কোনো model যদি million token context সমর্থনের কথা বলে কিন্তু তার attention design সম্পর্কে কিছু না বলে, তাহলে প্রমাণ না পাওয়া পর্যন্ত ধরে নিন যে cache-ই binding constraint।
Tier 1: ঘণ্টাভিত্তিকভাবে cluster ভাড়া নিন
এটি সেই tier, যেখানে K3-এর প্রকাশিত precision বজায় রেখে একসঙ্গে অনেক ব্যবহারকারীকে সেবা দেওয়া হয়। পর্যাপ্ত RAM থাকা একটি machine Unsloth-এর Q8 GGUF ব্যবহার করেও K3-কে প্রকাশিত precision-এ চালাতে পারে। Unsloth এটিকে full precision lossless হিসেবে চিহ্নিত করে। তবে সেই পদ্ধতিতে একবারে একজন ব্যবহারকারীকে সেবা দেওয়া যায় এবং এটি tier 2-তে আলোচনা করা হয়েছে। এখানে 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 নয়। Provider এবং GPU generation অনুযায়ী on-demand rate ব্যাপকভাবে পরিবর্তিত হয়। Single-node recipe-গুলোর জন্য প্রয়োজনীয় 288 GB অংশগুলোর hourly cost H100-এর চেয়ে বেশি। Reserved capacity আরও সস্তা। আপনার provider-এর প্রকৃত rate নিয়ে হিসাবটি আবার করুন: GPUs times hours times rate। Chart-এর উদ্দেশ্য হলো অনুপাতটি দেখানো। প্রতিদিন চার ঘণ্টার জন্য একটি 8 GPU node চালালে মাসে 2,400 USD খরচ হয়। অন্যদিকে SGLang-এর মাপ অনুযায়ী 32 GPU H100 configuration চালু রাখলে খরচ হয় 57,600 USD।
দুটি mainstream 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 যোগ করুন: SGLang tensor parallel-এর জন্য --tp-size, pipeline parallel-এর জন্য --pp-size এবং expert parallel-এর জন্য --ep-size গ্রহণ করে। Tensor parallel times pipeline parallel-এর মান আপনার কাছে থাকা GPU-এর সংখ্যার সমান হতে হবে। Expert parallel ওই group-এর মধ্যে experts ভাগ করে। এই কারণে 32 GPU H100 recipe-তে --tp-size 32 এবং --ep-size 32—দুটিই সেট করা হয়েছে।
বাস্তব traffic পাঠানোর আগে server চালু হয়েছে কি না পরীক্ষা করুন:
curl http://127.0.0.1:30000/v1/modelsসুস্থ server model id-সহ একটি JSON object দিয়ে উত্তর দেয়। Connection refused নির্দেশ করে যে process এখনও weights load করছে অথবা ইতিমধ্যে exit করেছে। তাই আবার চেষ্টা করার আগে server log পড়ুন।
প্রথম কয়েক সপ্তাহে সাধারণ সমস্যা ছিল model-এর তুলনায় runtime পুরোনো হওয়া। K3, KDA এবং একটি নতুন MoE layer-সহ প্রকাশিত হয়েছিল। Launch-এর সময় stable vLLM এবং SGLang release-গুলোতে এগুলোর support ছিল না। এর লক্ষণ হলো startup-এর সময় server এমন একটি line দেখিয়ে exit করে, যার রূপ Model architectures [...] are not supported for now। কোনো config পরিবর্তন এটি ঠিক করতে পারবে না, কারণ ওই layer-গুলো চালানোর code আপনার build-এ নেই। পরে পরিস্থিতি বদলেছে। 27 October 2026 অনুযায়ী SGLang v0.5.17 থেকে তার release-গুলোতে K3 support রেখেছে। সর্বশেষ version হলো v0.5.22। vLLM-এর v0.28.0 থেকে v0.32.0 release note-গুলোতেও K3-সংক্রান্ত কাজ অন্তর্ভুক্ত আছে। একটি current release install করুন। কিছু hardware-specific path-এর জন্য এখনও dedicated image-এর নাম দেওয়া থাকে। উদাহরণস্বরূপ, Blackwell-এর জন্য SGLang-এর NVFP4 build রয়েছে। তাই আপনার card-এর জন্য recipe পরীক্ষা করুন।
খরচের একটি বিষয় অনেকেই প্রথমে লক্ষ্য করেন না। Instance চালু হওয়ার সময় meter শুরু হয়, model ready হওয়ার সময় নয়। 1 GB/s গতিতে 1.56 TB download করতে প্রায় 26 মিনিট cluster time লাগে, এরপর প্রথম token পাওয়া যায়। Instance-এর lifecycle-এর বাইরে টিকে থাকে এমন একটি volume-এ weights আগে থেকেই stage করুন। তাহলে দ্বিতীয় run কয়েক মিনিটের মধ্যেই শুরু হবে।
Tier 2: একটি accelerator-এ ছোট model চালান
এই tier-এ আপনি K3 চালাচ্ছেন না। শুরু করার আগেই এটি স্পষ্টভাবে মনে রাখুন, কারণ “run K3 locally” নিয়ে অধিকাংশ আলোচনা এখানেই শেষ হয়, কিন্তু কেউ তা স্বীকার করে না।
Fit rule একই formula-এর ছোট সংস্করণ: parameters × প্রতি weight-এর bytes, তার সঙ্গে KV cache এবং প্রায় 2 GB runtime overhead যোগ করলে মোট পরিমাণ আপনার VRAM-এর মধ্যে থাকতে হবে। 4-bit-এ এটি প্রতি parameter-এ আনুমানিক অর্ধেক byte, ফলে নিচের pairing-গুলো স্বচ্ছন্দে ব্যবহার করা যায়:
- 16 GB card: দীর্ঘ context রাখার জন্য অতিরিক্ত জায়গাসহ 4-bit-এ একটি 7B model
- 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-off নির্ধারণ করে Ollama-এর NUM_PARALLEL এবং MAX_QUEUE settings।
একটি বড় machine-এ K3 নিজেই চালানোর একটি পদ্ধতি আছে। এটি এই tier এবং আগের tier-এর মাঝামাঝি। Unsloth llama.cpp-এ K3-এর GGUF build নথিভুক্ত করেছে। এতে 1-bit এবং 2-bit quantisation থেকে UD-Q8_K_XL পর্যন্ত বিভিন্ন option আছে। UD-Q8_K_XL-কে তারা full precision lossless হিসেবে চিহ্নিত করেছে। এগুলো চালাতে পারে এমন hardware হিসেবে তারা NVIDIA DGX Station-এর নাম দিয়েছে। তাদের rule of thumb হলো, RAM + VRAM মোটামুটি quant size-এর সমান হতে হবে। 1-bit UD-IQ1_S build-এর জন্য প্রায় 610 GB থেকে Q8-এর জন্য প্রায় 1.6 TB পর্যন্ত দরকার হয়। এর চেয়ে কম হলে model disk-এ fallback করে এবং গতি দ্রুত কমে যায়। GPU বাধ্যতামূলক নয়। Unsloth-এর build instruction-এ বলা আছে, “GPU না থাকলে বা শুধু CPU inference চালাতে চাইলে” CUDA বন্ধ করতে হবে। 1-bit এবং 2-bit build-গুলো K3-এর heavily quantised সংস্করণ; এতে উপরে মাপা accuracy কমে। Q8 build হলো released precision-এ K3, যা একজন user-কে RAM speed-এ serve করা হয়। কোনোটিই smaller model নয়।
Ollama দিয়ে কাজ করা server চালু করার সবচেয়ে সংক্ষিপ্ত পথ হলো GPU-যুক্ত একটি VPS-এ:
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14bollama run প্রথম ব্যবহারের সময় model download করে, তারপর আপনাকে prompt-এ নিয়ে যায়। অস্তিত্বহীন tag ব্যবহার করলে Error: model "..." not found ফেরত আসে। তাই tag মনে করে টাইপ না করে library page থেকে copy করুন। systemd unit এবং remote access-সহ সম্পূর্ণ walkthrough আছে VPS-এ Ollama চালানো-এ।
llama.cpp quantisation এবং offload-এর ওপর আরও বেশি নিয়ন্ত্রণ দেয়:
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 প্রতিটি layer GPU-তে চালানোর জন্য অনুরোধ করে। 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 ব্যবহার করলে একটি `choices array-সহ JSON object ফেরত আসে। 401 দেখা গেলে authentication ব্যর্থ হয়েছে। key সঠিক কি না, সেটির মেয়াদ শেষ হয়েছে বা disabled করা হয়েছে কি না, এবং header-এ key-এর আগে Authorization: Bearer` লেখা আছে কি না যাচাই করুন। সাধারণত model-not-found error-এর অর্থ id পরিবর্তিত হয়েছে। কারণ provider-রা checkpoint-এর মধ্যবর্তী সময়ে id বন্ধ করে দিতে পারে।
এখন উপরের ধরা rental rate ব্যবহার করে break-even হিসাব করা যাক। সব সময় চালু থাকা 8 GPU node-এর মাসিক খরচ 14,400 USD। প্রতি million output token-এর দাম 15.00 USD হলে একই অর্থে API থেকে প্রায় 960 million output token কেনা যায়। খরচের দিক থেকে লাভ করতে হলে মাসে প্রায় এক billion output token, অর্থাৎ দিনে প্রায় 30 million token generate করতে হবে এবং পুরো সময় cluster ব্যস্ত রাখতে হবে। কারণ idle GPU এবং busy GPU একই rate-এ bill হয়। Prompt-heavy agent workload-এ এই সীমা আরও দূরে সরে যায়। Repeated context-এর জন্য cache-hit rate-এ প্রতি million token-এর দাম 0.30 USD, cache-miss rate-এ নয়; 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-এর অন্তর্ভুক্ত। এগুলো একসঙ্গে অনেক request পরিবেশনের জন্য তৈরি; এতে 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 ধারণ না করলে CPU offload এবং কম concurrency-এর জন্য তৈরি। llama.cpp system RAM-এ expert weight রেখে একটি বিশাল MoE load করতে পারে (--cpu-moe অথবা --n-cpu-moe)। --moe-cache-mib ব্যবহার করলে এটি ব্যবহৃত expert-গুলো GPU-তে cache করে। এভাবেই Unsloth-এর K3 GGUF build একটি machine-এ চলে। তখন speed নির্ভর করে RAM bandwidth এবং router কত ঘন ঘন cache miss করে তার ওপর। file-এর আকার RAM এবং VRAM-এর মোট আকারের চেয়ে বড় হলে এটি disk-এ নেমে যায়। একজন user-এর জন্য এটি ব্যবহারযোগ্য setup। তবে অনেক user-কে এর ওপর চালানোর মতো service এটি নয়। সম্পূর্ণ তুলনা Ollama বনাম vLLM-এ আছে। Model পরিবর্তন হলেও বিষয়টি বদলায় না: shared hardware-এ আপনি অনেক user-কে serve করছেন, নাকি নিজের hardware-এ একজন user-কে serve করছেন—প্রশ্নটি সব সময় সেটিই।
এই checkpoint অতিক্রম করেও টিকে থাকা চারটি সংখ্যা
- মোট parameter-সংখ্যাকে প্রতি weight-এর byte-সংখ্যা দিয়ে গুণ করলে memory floor পাওয়া যায়। প্রকাশিত precision-এ এর নিচে কোনো কিছু চালানো যায় না। 4-bit release-এর নিচে quantise করলে সর্বোচ্চ প্রায় 70 percent সাশ্রয় হয়, তবে accuracy কমে; এক order of magnitude নয়।
- Active parameter-সংখ্যা throughput class নির্ধারণ করে। 104B active parameter-সহ 2.8T MoE একটি 104B model-এর মতো compute করে।
- প্রতি token-এর KV cache-কে context length এবং concurrency দিয়ে গুণ করলে সেই খরচ পাওয়া যায়, যা weights-এর খরচ পরিশোধ করার পরও বাড়তে থাকে।
- প্রতি dollar-এ tokens per second-ই একমাত্র সংখ্যা, যা tier নির্ধারণ করে। উপরের সবকিছু এর input।
যেকোনো release-এ এই চারটি প্রয়োগ করলে vendor guide খোলার আগেই সঠিক উত্তর পাওয়া যায়। পরবর্তী release ইতিমধ্যে ঘোষণা করা হয়েছে: Moonshot 23 October 2026-এ Kimi Code-এ K3-এর ওপর ভিত্তি করে, অতিরিক্ত post-training-সহ K3.1 Pro প্রকাশ করেছে। এর API quickstart-এ বলা হয়েছে, full weights 4 November-এর মধ্যে প্রকাশ করা হবে। এরপর আপনি যে প্রতিটি figure লিখবেন, তার সঙ্গে তারিখ উল্লেখ করুন। K3 launch-এর পরের দুই সপ্তাহের মধ্যে prices এবং supported-architecture lists—দুটিই পরিবর্তিত হয়েছে। এই পৃষ্ঠার launch figures July 2026-এ প্রকাশিত হয়েছিল। serving recipes, runtime releases এবং quantisation numbers 27 October 2026-এ পুনরায় যাচাই করা হয়েছে।
FAQ
আমি কি একটি GPU-তে Kimi K3 চালাতে পারি?
না। Moonshot যে MXFP4 precision-এ এটি release করেছে, তাতে weights-এর আকার প্রায় 1.4 TB। এমনকি K3-এর প্রকাশিত quantisation-গুলোর মধ্যে সবচেয়ে ছোট Unsloth-এর 466 GB UD-Q1_0 file-টিও বহুল ব্যবহৃত সবচেয়ে বড় accelerator-গুলোর 288 GB-এর প্রায় 1.6 গুণ। llama.cpp system RAM-এ experts রাখতে এবং সক্রিয় experts-গুলো GPU-তে cache করতে পারে। তবে এর জন্যও RAM ও VRAM মিলিয়ে প্রায় quantised size পরিমাণ memory প্রয়োজন। এর চেয়ে কম memory থাকলে model disk-এ চলে যায় এবং অনেক ধীর হয়। প্রকাশিত serving recipe-গুলোর মধ্যে সবচেয়ে ছোটগুলো B300 অথবা MI350X/MI355X card-সমৃদ্ধ একটি 8-GPU node ব্যবহার করে। H100 recipe-তে 32টি GPU ব্যবহার করা হয়।
Kimi K3-এর কত VRAM প্রয়োজন?
শুধু weights-এর জন্য 1.4 TB ধরে শুরু করুন। এটি 18টি H100 80GB card অথবা 5টি GB300-class card-এর সমান। এর সঙ্গে KV cache এবং activation memory যোগ করতে হবে। Moonshot-এর launch guidance-এ 64 বা তার বেশি accelerator ব্যবহারের সুপারিশ করা হয়েছিল। 27 October 2026 অনুযায়ী SGLang cookbook-এ 8টি B300 অথবা 8টি MI350X/MI355X card-সমৃদ্ধ single-node recipe প্রকাশিত হয়েছে, যার aggregate memory 2,304 GB। এতে 2,560 GB aggregate memory-সহ 32-GPU H100 configuration-ও আছে। তাই weights-এর পরিমাণকে minimum baseline হিসেবে ধরুন, সম্পূর্ণ requirement হিসেবে নয়।
Quantisation করলে কি Kimi K3 একটি node-এ fit করবে?
Shipped 4-bit checkpoint-টি একটি node-এ fit করে, যদি node-টিতে 288 GB-এর 8টি card থাকে। SGLang-এর B300 এবং MI355X recipe-তে এই configuration-ই ব্যবহৃত হয়। Unsloth-এর lossless Q8 GGUF ব্যবহার করেও প্রায় 1.6 TB RAM এবং VRAM-সহ একটি machine-এ এটি fit করে। আরও ছোট machine-এর জন্য আরও কম bit ব্যবহার করা যায়। Unsloth-এর পরিমাপ করা dynamic GGUF build-গুলোর আকার 2-bit-এ 861.3 GB থেকে 1-bit-এ 594 GB পর্যন্ত। তাদের repo-তে 466 GB পর্যন্ত 1-bit file-ও তালিকাভুক্ত আছে, যেখানে lossless আকার প্রায় 1.56 TB। Accuracy-র ক্ষতিও পরিমাপ করা হয়েছে: full model-এর সঙ্গে top-1 agreement UD-Q2_K_XL-এ 90.390 percent এবং UD-IQ1_S-এ 78.875 percent-এ নেমে আসে। এগুলোর কোনোটিই একটি single card-এ fit করে না।
Kimi K3 API-এর চেয়ে GPU ভাড়া করা কি সস্তা?
শুধু উচ্চ এবং স্থিতিশীল volume থাকলে। প্রতি GPU hour-এর জন্য 2.50 USD ধরে নিলে, সব সময় চালু থাকা একটি 8-GPU node-এর মাসিক খরচ 14,400 USD। একই অর্থে প্রকাশিত 15.00 USD per million rate-এ প্রায় 960 million output token কেনা যায়। Idle hour, weights download এবং cluster সচল রাখার দায়িত্বে থাকা ব্যক্তির খরচও আপনাকে বহন করতে হবে। Burst workload-এর জন্য hour অনুযায়ী ভাড়া নিন। অনুমানের বদলে নিজস্ব পরিমাপ করা token volume-এর সঙ্গে তুলনা করুন।
Speed-এর ক্ষেত্রে 104B active parameters-এর অর্থ কী?
এর অর্থ, প্রতি token-এ arithmetic-এর পরিমাণ একটি 104B model-এর সমান। তাই throughput 2.8T class-এর বদলে 104B class-এর কাছাকাছি হবে। এটি memory usage সম্পর্কে কিছু বলে না। সব 2.8T parameter memory-তে resident থাকে, কারণ router যেকোনো token-এর জন্য যেকোনো expert call করতে পারে। Tokens per second অনুমান করতে active count ব্যবহার করুন। VRAM-এর capacity নির্ধারণ করতে total count ব্যবহার করুন।