Kimi K3 को self-host कैसे करें: हार्डवेयर और गणित

Kimi K3 को self-host करने के लिए आवश्यक संसाधन

Kimi K3 को self-host करने का अर्थ है 2.8 ट्रिलियन parameters के लिए जगह बनाना। Moonshot ने open weights को MXFP4 format में प्रकाशित किया है, जो प्रति weight लगभग आधा byte है। इसलिए, cache के लिए एक भी token allocate करने से पहले, केवल weights का आकार लगभग 1.4 TB होता है। वर्तमान में बाजार में उपलब्ध कोई भी accelerator इसे अकेले धारण नहीं कर सकता है। एक GPU के लिए इसका उत्तर 'नहीं' है। एक सर्वर के लिए इसका उत्तर दो रूपों में 'हाँ' है। पहला है 288 GB accelerators वाला 8-GPU node, जिसका उपयोग सबसे छोटे प्रकाशित multi-user serving recipes में किया जाता है। दूसरा है लगभग 1.6 TB combined RAM और VRAM वाली एक मशीन, जो llama.cpp में Unsloth के lossless Q8 GGUF को चलाती है, चाहे GPU हो या न हो, और एक समय में एक user को serve करती है।

यह अंतिम निष्कर्ष है। नीचे दी गई हर चीज़ इसके पीछे का गणित है, क्योंकि यही वह गणित है जिसे आप अगले release पर फिर से उपयोग करेंगे। 16 July 2026 को हुई घोषणा के बाद के हफ्तों में कई infrastructure vendors ने K3 deployment guides प्रकाशित कीं, और प्रत्येक ने यह मान लिया कि आपके पास पहले से ही एक cluster है। यह पृष्ठ दूसरे छोर से शुरू होता है: इसकी लागत क्या है, आप इसके बजाय क्या चला सकते हैं, और यह कैसे पता लगाएं कि आप उन दो स्थितियों में से किसमें हैं।

कुल पैरामीटर्स और सक्रिय पैरामीटर्स की संख्या समान नहीं है

K3 एक mixture of experts मॉडल है। MoE (mixture of experts) नेटवर्क को कई सब-नेटवर्क्स में विभाजित करता है और एक राउटर को प्रति टोकन उनमें से कुछ को चुनने की अनुमति देता है। मॉडल कार्ड में 2.8T कुल पैरामीटर्स और प्रति टोकन 104B सक्रिय पैरामीटर्स सूचीबद्ध हैं, जो 896 रूट किए गए एक्सपर्ट्स में से हैं, जिनमें से 93 लेयर्स में किसी भी टोकन के लिए 16 एक्सपर्ट्स सक्रिय होते हैं।

ये दोनों पैरामीटर काउंट अलग-अलग सवालों के जवाब देते हैं, और "क्या मैं इसे चला सकता हूँ" वाले हर थ्रेड में इन्हें आपस में बदल देना सबसे आम गलती है।

सक्रिय पैरामीटर्स कंप्यूट लागत निर्धारित करते हैं। एक टोकन लगभग 104B पैरामीटर्स के माध्यम से गुणा होता है, इसलिए आपको जो थ्रूपुट मिलना चाहिए वह 2.8T मॉडल के बजाय 104B डेंस मॉडल जैसा होता है। MoE बनाने का पूरा कारण यही है।

कुल पैरामीटर्स मेमोरी लागत निर्धारित करते हैं। राउटर किसी भी टोकन पर किसी भी एक्सपर्ट को चुन सकता है, इसलिए पहली रिक्वेस्ट आने से पहले हर एक्सपर्ट को कहीं तेज मेमोरी में स्टोर करना पड़ता है। केवल हॉट एक्सपर्ट्स को VRAM में रखने और बाकी को मांग पर लाने की तकनीक मौजूद है: llama.cpp का --moe-cache-mib एक्सपर्ट्स का एक GPU कैश रखता है जो अन्यथा सिस्टम RAM में रहते हैं और राउटर द्वारा चुने जाने पर गायब एक्सपर्ट्स को अपलोड कर देता है। हालाँकि, यह कुल संख्या को कम नहीं करता है। बाकी एक्सपर्ट्स को अभी भी RAM में रहना पड़ता है, और एक PCIe लिंक HBM के टेराबाइट्स प्रति सेकंड के मुकाबले प्रति सेकंड दसियों गीगाबाइट्स डेटा ट्रांसफर करता है, इसलिए हर कैश मिस में समय लगता है। NVMe से एक्सपर्ट्स को स्ट्रीम करना, क्योंकि मॉडल RAM में भी फिट नहीं होता, और भी धीमा है, और Unsloth की K3 गाइड चेतावनी देती है कि डिस्क ऑफलोडिंग बहुत धीमी गति से चलती है।

इसलिए, इसे कंप्यूट करना सस्ता है और स्टोर करना महंगा। हार्डवेयर का आकार 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 को quantisation aware तरीके से train किया गया था और इसे MXFP4 weights और MXFP8 activations के साथ release किया गया है, इसलिए 4-bit वाली पंक्ति ही वास्तविक है। इसके ऊपर की पंक्तियाँ केवल तुलना के लिए हैं: bf16 पर उसी मॉडल को 5.6 TB की आवश्यकता होगी। MXFP4 हर 32 weights के ब्लॉक के लिए एक साझा 8-bit scale भी स्टोर करता है, जो लगभग 6 प्रतिशत अतिरिक्त जगह लेता है। साथ ही, Moonshot का कॉन्फ़िगरेशन attention, साझा experts और vision tower को 4-bit फॉर्मेट से बाहर रखता है। इस कारण Unsloth की गणना के अनुसार पूरा चेकपॉइंट 1.56 TB का होता है, न कि सटीक 1.4 TB का।

यह सामान्य बचाव के रास्ते को पूरी तरह बंद किए बिना सीमित कर देता है। जारी किया गया चेकपॉइंट पहले से ही 4-bit में है, इसलिए आसान बचत पहले ही की जा चुकी है, लेकिन इससे भी कम पर जाने से संख्या में बदलाव आता है। 27 अक्टूबर 2026 तक, K3 के डायनामिक GGUF quantisations जिन्हें Unsloth ने मापा है, वे 2-bit UD-Q2_K_XL के लिए 861.3 GB से लेकर 1-bit UD-IQ1_S के लिए 594 GB तक हैं। Unsloth इनकी लागत भी प्रकाशित करता है: पूर्ण मॉडल के साथ top-1 टोकन एग्रीमेंट UD-Q2_K_XL पर 90.390 प्रतिशत, 711.1 GB वाले UD-IQ2_XXS पर 84.127 प्रतिशत और UD-IQ1_S पर 78.875 प्रतिशत है। इसके Hugging Face रिपॉजिटरी में छोटी 1-bit फाइलें भी मौजूद हैं, जो UD-Q1_0 के लिए 466 GB तक कम हो जाती हैं, लेकिन उनके साथ कोई एग्रीमेंट आंकड़ा प्रकाशित नहीं किया गया है। यह एक मापी गई सटीकता की हानि है, और सबसे छोटी फाइल भी सबसे बड़े सिंगल कार्ड की तुलना में लगभग 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
  }
]

इन्हें लक्ष्य के बजाय न्यूनतम सीमा (floor) के रूप में पढ़ें। ये केवल weights की गणना करते हैं: इसमें KV cache, activation buffers, allocator fragmentation, या एक साथ आने वाले दूसरे अनुरोध के लिए कोई जगह शामिल नहीं है। विभाजन का समान रूप से विभाजित होना आवश्यक नहीं है: vLLM का pipeline parallelism मॉडल को layers के आधार पर विभाजित करता है और असमान विभाजन का समर्थन करता है, और SGLang की K3 prefill recipes 93 layers पर 8 और 16 pipeline stages चलाती हैं।

प्रकाशित मार्गदर्शन इस न्यूनतम सीमा से ऊपर है। Moonshot के लॉन्च मार्गदर्शन ने 64 या उससे अधिक accelerators के एक supernode की सिफारिश की थी। 27 October 2026 तक, SGLang cookbook चार 8-GPU nodes से बनी एक H100 configuration प्रदान करता है, जिसमें 32 GPUs और 2,560 GB की कुल memory है, जो 18 cards की न्यूनतम सीमा के मुकाबले है। यह एक 8-GPU B300 node और एक 8-GPU MI350X या MI355X node पर single-node recipes को भी सूचीबद्ध करता है, जिसमें 288 GB प्रति card के हिसाब से 2,304 GB memory है। न्यूनतम सीमा से ऊपर का यह अंतर व्यर्थ नहीं है। यह KV cache, activation memory, और वह headroom है जो सर्वर को एक साथ कई अनुरोधों को batch करने की अनुमति देता है। सबसे अनुकूल पंक्ति, 5 GB300 class cards, व्यवहार में ठीक उसी प्रकार के 8-GPU node तक पहुँच जाती है, जो कि सबसे छोटी मशीन है जिसके लिए कोई भी multi-user K3 serving recipe प्रकाशित करता है।

KV cache वह हिस्सा है जो लोगों को हैरान करता है

Weights एक निश्चित लागत (fixed cost) हैं। 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 मिलते हैं, यानी प्रति 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 है। पूरे एक मिलियन context पर एक user की लागत 128 GiB है, जो कि एक भी weight लोड होने से पहले, एक conversation के लिए 288 GB कार्ड का लगभग आधा हिस्सा है।

K3 सामान्य attention का उपयोग नहीं करता है, और वह आखिरी संख्या इसी कारण से है। इसकी 93 layers में 69 KDA (Kimi Delta Attention) layers और 24 Gated MLA (multi-head latent attention) layers हैं। KDA हर token के साथ बढ़ने वाले cache के बजाय एक निश्चित आकार की recurrent state रखता है, और 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 values। 24 layers में 2 bytes प्रत्येक के हिसाब से यह 27,648 bytes है, लगभग 27 KiB प्रति token, या पूरे 1,048,576 token conversation के लिए लगभग 27 GiB, साथ ही निश्चित KDA state। इसे एक माप के बजाय एक अनुमान मानें: engines अपने तरीके से cache को pad और layout करते हैं, और 8-bit cache इसे लगभग आधा कर देता है।

यह देखने के लिए कि आपका अपना deployment क्या रखता है, --max-model-len बढ़ाते समय nvidia-smi को monitor न करें। vLLM अपने KV cache pool को पहले से allocate करता है, जिसका आकार --gpu-memory-utilization (वर्तमान docs में डिफ़ॉल्ट रूप से 0.92) या एक स्पष्ट per-GPU cache budget से निर्धारित होता है, इसलिए कुल GPU memory एक conversation के बजाय pool को दिखाती है। इसके बजाय startup log पढ़ें, जहाँ vLLM आपके context length पर tokens में KV cache का आकार और अधिकतम concurrency की रिपोर्ट करता है।

reasoning का स्वरूप अगले release में भी बना रहेगा। यदि कोई model एक मिलियन token context का विज्ञापन करता है और अपने attention design के बारे में कुछ नहीं कहता है, तो यह मान लें कि cache ही मुख्य बाधा (binding constraint) है, जब तक कि कोई अन्यथा साबित न कर दे।

Tier 1: क्लस्टर को प्रति घंटे के आधार पर किराए पर लेना

यह वह टियर है जो एक साथ कई उपयोगकर्ताओं को K3 को उसके shipped precision पर सर्व करता है। पर्याप्त RAM वाली एक मशीन Unsloth के Q8 GGUF के माध्यम से K3 को उसके released precision पर भी चला सकती है, जिसे Unsloth पूर्ण precision lossless कहता है, लेकिन वह तरीका एक बार में केवल एक उपयोगकर्ता को सेवा देता है और टियर 2 में कवर किया गया है। यहाँ आप हार्डवेयर नहीं खरीदते हैं। आप इसे उन घंटों के लिए किराए पर लेते हैं जिनकी आपको आवश्यकता है और बाद में इसे बंद कर देते हैं।

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

यह दर एक अनुमान है, कोई निश्चित quote नहीं। On-demand दरें प्रदाता और GPU जनरेशन के आधार पर बहुत भिन्न होती हैं, 288 GB वाले पार्ट्स जिनकी single-node recipes को आवश्यकता होती है, वे H100 की तुलना में प्रति घंटे अधिक महंगे होते हैं, और reserved capacity सस्ती होती है। अपने प्रदाता की वास्तविक संख्या लें और गुणा फिर से करें: GPUs गुना घंटे गुना दर। चार्ट का उद्देश्य अनुपात दिखाना है। दिन में चार घंटे के लिए 8 GPU नोड को burst करने की लागत 2,400 USD प्रति माह है, जबकि SGLang के आकार के 32 GPU H100 कॉन्फ़िगरेशन को लगातार चलाने की लागत 57,600 USD है।

दोनों मुख्यधारा के सर्वर मॉडल कार्ड पर एक 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

इनमें से कोई भी bare command वह नहीं है जिसे आप वास्तविक क्लस्टर पर चलाते हैं। अपने हार्डवेयर से मेल खाने वाले parallelism flags जोड़ें: SGLang tensor parallel के लिए --tp-size, pipeline parallel के लिए --pp-size और expert parallel के लिए --ep-size लेता है। Tensor parallel गुना pipeline parallel आपके पास मौजूद वास्तविक GPUs के बराबर होना चाहिए, और expert parallel उस समूह के भीतर experts को विभाजित करता है, यही कारण है कि 32 GPU H100 रेसिपी --tp-size 32 और --ep-size 32 दोनों सेट करती है।

वास्तविक traffic भेजने से पहले जाँचें कि सर्वर चालू हो गया है या नहीं:

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

एक स्वस्थ सर्वर मॉडल id को सूचीबद्ध करने वाले JSON ऑब्जेक्ट के साथ उत्तर देता है। Connection refused का अर्थ है कि प्रक्रिया अभी भी weights लोड कर रही है या पहले ही exit हो चुकी है, इसलिए पुनः प्रयास करने से पहले सर्वर लॉग पढ़ें।

पहले कुछ हफ्तों में सामान्य विफलता यह थी कि runtime मॉडल से पुराना था। K3 को KDA और एक नई MoE लेयर के साथ ship किया गया था जिसे स्थिर vLLM और SGLang releases ने लॉन्च के समय शामिल नहीं किया था, और इसका लक्षण यह है कि सर्वर स्टार्टअप के दौरान Model architectures [...] are not supported for now के रूप का एक लाइन दिखाकर exit हो जाता है। कोई भी config परिवर्तन इसे ठीक नहीं करता है, क्योंकि उन लेयर्स को चलाने के लिए कोड आपके build में नहीं है। अब यह बदल गया है: 27 October 2026 तक SGLang ने v0.5.17 के बाद से अपने releases में K3 सपोर्ट शामिल किया है, जिसमें v0.5.22 नवीनतम है, और vLLM के v0.28.0 से v0.32.0 release notes में K3 का काम शामिल है। एक वर्तमान release इंस्टॉल करें। कुछ हार्डवेयर-विशिष्ट paths अभी भी एक समर्पित image का नाम लेते हैं, उदाहरण के लिए Blackwell पर SGLang के NVFP4 builds, इसलिए अपने कार्ड के लिए रेसिपी की जाँच करें।

लागत संबंधी एक नोट जो लोगों को परेशान करता है। मीटर तब शुरू होता है जब instance शुरू होता है, न कि तब जब मॉडल तैयार होता है। 1 GB/s पर 1.56 TB का डाउनलोड पहले token से पहले लगभग 26 मिनट का क्लस्टर समय लेता है। Weights को ऐसे वॉल्यूम पर stage करें जो instance के बंद होने के बाद भी बना रहे, ताकि दूसरा रन मिनटों में शुरू हो सके।

Tier 2: एक accelerator पर छोटा model चलाना

इस tier में आप K3 नहीं चला रहे हैं। शुरू करने से पहले इसे स्पष्ट रूप से समझ लें, क्योंकि "run K3 locally" वाले अधिकांश threads बिना यह स्वीकार किए समाप्त हो जाते हैं।

Fit rule का सूत्र वही है, बस छोटे पैमाने पर: parameters को bytes per weight से गुणा करें, उसमें KV cache जोड़ें, और लगभग 2 GB runtime overhead जोड़ें। यह कुल योग आपकी VRAM से कम होना चाहिए। 4-bit पर यह प्रति parameter लगभग आधा byte होता है, जिससे ये pairings सुविधाजनक रहती हैं:

• 16 GB card: 4-bit पर 7B model, जिसमें long 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 चाहिए होता है। यही वह trade-off है जिसे Ollama's NUM_PARALLEL and MAX_QUEUE settings आपके लिए parallel slots, queued requests और बची हुई VRAM के बीच मैनेज करता है।

K3 को एक ही बड़े machine पर चलाने का एक तरीका है, जो इस tier और पिछले tier के बीच आता है। Unsloth, llama.cpp में K3 के GGUF builds को document करता है। ये 1-bit और 2-bit quantisations से लेकर UD-Q8_K_XL तक होते हैं, जिसे यह full precision lossless कहता है, और इसके लिए NVIDIA DGX Station को hardware के रूप में नामित करता है। इसका सामान्य नियम यह है कि RAM और VRAM का योग लगभग quant size के बराबर होना चाहिए। यह 1-bit UD-IQ1_S build के लिए लगभग 610 GB से लेकर Q8 के लिए लगभग 1.6 TB तक होता है। इससे कम होने पर model disk पर चला जाता है और उसकी गति काफी धीमी हो जाती है। GPU वैकल्पिक है: Unsloth के build instructions में CUDA को बंद किया जा सकता है "यदि आपके पास GPU नहीं है या आप केवल CPU inference चाहते हैं"। 1-bit और 2-bit builds, K3 के भारी quantised संस्करण हैं, जिनकी accuracy cost ऊपर मापी गई है। Q8 build, K3 का वही precision है जिस पर वह release हुआ था, जिसे एक user को RAM की गति पर serve किया जाता है। इनमें से कोई भी छोटा model नहीं है।

GPU वाले VPS पर working server बनाने के लिए Ollama सबसे छोटा रास्ता है:

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

ollama run पहली बार उपयोग करने पर model को download करता है, और फिर आपको prompt पर ले आता है। यदि कोई tag मौजूद नहीं है, तो Error: model "..." not found error आता है, इसलिए tags को याददाश्त से टाइप करने के बजाय library page से copy करें। systemd unit और remote access सहित पूरी प्रक्रिया running Ollama on a VPS में दी गई है।

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 को पढ़ें: यह बताता है कि कितनी layers offload की गई हैं। जो layers system RAM में चली जाती हैं, वे HBM bandwidth के बजाय RAM bandwidth पर चलती हैं। इसलिए, जैसे ही model पूरी तरह fit नहीं होता, generation की गति काफी कम हो जाती है। इन दोनों tools के बीच के trade-offs Ollama and llama.cpp side by side में कवर किए गए हैं।

टियर 3: होस्टेड API, सेल्फ-होस्टेड ऑर्केस्ट्रेशन

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

यह एंडपॉइंट OpenAI के साथ संगत है, इसलिए बेस URL बदलने के बाद मौजूदा क्लाइंट काम करने लगता है।

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 ऑब्जेक्ट लौटाती है जिसमें choices ऐरे होता है। 401 का मतलब है कि ऑथेंटिकेशन विफल रहा: जांचें कि की सही है, समाप्त नहीं हुई है या डिसेबल नहीं की गई है, और हेडर में Authorization: Bearer के बाद की (key) मौजूद है। मॉडल-नॉट-फाउंड एरर का मतलब आमतौर पर यह होता है कि ID बदल गई है, क्योंकि प्रोवाइडर चेकपॉइंट्स के बीच ID को रिटायर कर देते हैं।

अब ऊपर दिए गए अनुमानित रेंटल रेट का उपयोग करके ब्रेक-ईवन (लाभ-हानि बराबर होने की स्थिति) को देखें। एक 8 GPU वाला नोड जो हमेशा चालू रहता है, उसकी लागत 14,400 USD प्रति माह है, और 15.00 USD प्रति मिलियन आउटपुट टोकन की दर से, उतनी ही राशि में API से लगभग 960 मिलियन आउटपुट टोकन खरीदे जा सकते हैं। लागत में लाभ पाने के लिए आपको प्रति माह लगभग एक बिलियन आउटपुट टोकन जनरेट करने होंगे, यानी लगभग 30 मिलियन प्रतिदिन, और क्लस्टर को हर समय व्यस्त रखना होगा, क्योंकि खाली (idle) GPU भी व्यस्त GPU की तरह ही बिल किए जाते हैं। प्रॉम्प्ट-हैवी एजेंट वर्कलोड इस सीमा को और आगे बढ़ा देते हैं: बार-बार उपयोग होने वाला कॉन्टेक्स्ट 3.00 USD प्रति मिलियन की कैश-मिस दर के बजाय 0.30 USD प्रति मिलियन की कैश-हिट दर पर बिल किया जाता है।

इस टियर में आप मॉडल के आसपास की हर चीज को सेल्फ-होस्ट करते हैं: एक गेटवे जो API की (key) को सुरक्षित रखता है ताकि वह कभी क्लाइंट तक न पहुंचे, रिक्वेस्ट और रिस्पॉन्स लॉग्स, रिट्राय, रेट लिमिट्स, और प्रति-उपयोगकर्ता बजट। यह बिना GPU वाले एक छोटे VPS पर चलता है। यही विभाजन क्लोज्ड वेट्स (closed weights) पर भी लागू होता है, जहां Claude को सेल्फ-होस्ट करना मॉडल स्तर पर संभव नहीं है और ऑर्केस्ट्रेशन ही वह एकमात्र हिस्सा है जिसे आप नियंत्रित करते हैं।

कौन सा सर्विंग स्टैक किस टियर (tier) में आता है

vLLM और SGLang क्लास के सर्वर्स टियर 1 में आते हैं। इनका उद्देश्य एक साथ कई requests को सर्व करना है, जिसके लिए ये continuous batching और paged KV cache का उपयोग करते हैं, साथ ही कई nodes पर tensor और expert parallelism फैलाते हैं। ये datacentre accelerators और उनके बीच एक fast interconnect की अपेक्षा रखते हैं। एक सिंगल consumer card पर इन्हें इंस्टॉल करना भारी पड़ता है और आपको कोई खास लाभ महसूस नहीं होगा।

llama.cpp और Ollama टियर 2 में आते हैं। ये एक मशीन, GGUF quantisation, मॉडल फिट न होने पर CPU offload, और कम concurrency को लक्षित करते हैं। llama.cpp एक विशाल MoE को system RAM (--cpu-moe या --n-cpu-moe) में expert weights रखकर लोड करेगा और, --moe-cache-mib के साथ, GPU पर उपयोग किए जाने वाले experts को कैश करेगा; इसी तरह Unsloth के K3 GGUF बिल्ड्स एक सिंगल मशीन पर चलते हैं। गति तब RAM bandwidth और इस बात पर निर्भर करती है कि router कितनी बार कैश मिस करता है, और यदि फाइल RAM और VRAM के योग से बड़ी है तो यह डिस्क पर चली जाती है। यह एक यूजर के लिए काम करने योग्य सेटअप है। यह ऐसी सर्विस नहीं है जिस पर आप कई यूजर्स को डाल सकें। पूरी तुलना Ollama बनाम vLLM में दी गई है, और यह मॉडल के साथ नहीं बदलती: प्रश्न हमेशा यह होता है कि क्या आप shared hardware पर कई यूजर्स को सर्व कर रहे हैं या अपने स्वयं के हार्डवेयर पर एक यूजर को।

वे चार संख्याएँ जो इस चेकपॉइंट के बाद भी प्रासंगिक रहती हैं

1. कुल पैरामीटर्स को प्रति वेट बाइट्स से गुणा करने पर मेमोरी की न्यूनतम सीमा (memory floor) प्राप्त होती है। शिप किए गए प्रिसिजन (precision) पर इससे कम मेमोरी में कुछ भी नहीं चलता है, और 4-bit रिलीज से नीचे क्वांटाइज करने पर आपको सटीकता की कीमत पर अधिकतम 70 प्रतिशत तक की बचत मिलती है, न कि एक ऑर्डर ऑफ मैग्नीट्यूड (order of magnitude) की।
2. एक्टिव पैरामीटर्स थ्रूपुट क्लास निर्धारित करते हैं। 104B एक्टिव पैरामीटर्स वाला 2.8T MoE मॉडल 104B मॉडल की तरह ही कंप्यूट करता है।
3. प्रति टोकन KV cache, जिसे कॉन्टेक्स्ट लेंथ और कॉनकरेंसी (concurrency) से गुणा किया जाता है, वह लागत है जो वेट्स के लिए भुगतान करने के बाद भी लगातार बढ़ती रहती है।
4. प्रति डॉलर टोकन प्रति सेकंड ही एकमात्र ऐसी संख्या है जो टियर का चयन करती है। ऊपर दी गई बाकी सभी चीजें इसके इनपुट हैं।

इन चारों को किसी भी रिलीज पर लागू करें और वेंडर गाइड खोलने से पहले ही आपको सही उत्तर मिल जाएगा। अगली रिलीज की घोषणा पहले ही हो चुकी है: Moonshot ने 23 अक्टूबर 2026 को Kimi Code में K3 पर आधारित और अतिरिक्त पोस्ट-ट्रेनिंग के साथ K3.1 Pro रोल आउट किया है, और इसके API क्विकस्टार्ट के अनुसार पूर्ण वेट्स 4 नवंबर तक रिलीज कर दिए जाएंगे। इसके बाद, आपके द्वारा लिखी गई प्रत्येक संख्या पर तारीख अंकित करें। K3 लॉन्च होने के दो सप्ताह के भीतर कीमतें और समर्थित-आर्किटेक्चर (supported-architecture) की सूचियां दोनों बदल गई थीं। इस पेज पर लॉन्च के आंकड़े जुलाई 2026 में प्रकाशित किए गए थे, और सर्विंग रेसिपी, रनटाइम रिलीज और क्वांटाइजेशन संख्याओं की दोबारा जांच 27 अक्टूबर 2026 को की गई थी।

FAQ

क्या मैं Kimi K3 को एक सिंगल GPU पर चला सकता हूँ?

नहीं। Moonshot द्वारा शिप किए गए MXFP4 प्रिसिजन पर weights लगभग 1.4 TB के हैं। K3 का सबसे छोटा पब्लिश किया गया क्वांटाइजेशन, Unsloth की 466 GB की UD-Q1_0 फाइल भी, सबसे बड़े उपलब्ध एक्सेलेरेटर्स की 288 GB क्षमता से लगभग 1.6 गुना बड़ी है। llama.cpp सिस्टम RAM में एक्सपर्ट्स को रख सकता है और सक्रिय एक्सपर्ट्स को GPU पर कैश कर सकता है, लेकिन इसके लिए भी RAM और VRAM में लगभग क्वांट साइज के बराबर जगह चाहिए। इससे कम होने पर मॉडल डिस्क पर चला जाता है और बहुत धीमा हो जाता है। सबसे छोटी पब्लिश की गई सर्विंग रेसिपी में B300 या MI350X/MI355X कार्ड्स का एक 8-GPU नोड उपयोग होता है, और H100 रेसिपी में 32 GPU का उपयोग होता है।

Kimi K3 को कितनी VRAM की आवश्यकता है?

केवल weights के लिए 1.4 TB से शुरुआत करें, जो कि 18 H100 80GB कार्ड्स या 5 GB300 क्लास कार्ड्स के बराबर है। इसके ऊपर KV कैश और एक्टिवेशन मेमोरी जोड़ें। Moonshot की लॉन्च गाइडेंस में 64 या उससे अधिक एक्सेलेरेटर्स की सिफारिश की गई थी। 27 अक्टूबर 2026 तक, SGLang कुकबुक 8 B300 या 8 MI350X/MI355X कार्ड्स (कुल 2,304 GB) और 32 GPU H100 कॉन्फ़िगरेशन (कुल 2,560 GB) पर सिंगल-नोड रेसिपी पब्लिश करती है, इसलिए weights के आंकड़े को एक न्यूनतम सीमा मानें, न कि आवश्यकता।

क्या क्वांटाइजेशन से Kimi K3 एक नोड पर फिट हो सकता है?

शिप किया गया 4-bit चेकपॉइंट पहले से ही एक नोड पर फिट हो जाता है यदि वह नोड आठ 288 GB कार्ड्स वाला हो, जो SGLang की B300 और MI355X रेसिपी में उपयोग होता है। साथ ही, Unsloth के लॉसलेस Q8 GGUF के माध्यम से लगभग 1.6 TB RAM और VRAM वाली एक मशीन पर भी यह फिट हो जाता है। कम क्वांटाइजेशन छोटे मशीनों के लिए मददगार है: Unsloth के डायनामिक GGUF बिल्ड्स 2-bit पर 861.3 GB से लेकर 1-bit पर 594 GB तक हैं, और इसकी रिपॉजिटरी में 1-bit फाइलें 466 GB तक सूचीबद्ध हैं, जबकि लॉसलेस मॉडल लगभग 1.56 TB का है। सटीकता की लागत मापी गई है: फुल मॉडल के साथ टॉप-1 एग्रीमेंट UD-Q2_K_XL पर 90.390 प्रतिशत और UD-IQ1_S पर 78.875 प्रतिशत तक गिर जाता है। इनमें से कोई भी एक सिंगल कार्ड पर फिट नहीं होता है।

क्या GPU किराए पर लेना Kimi K3 API से सस्ता है?

केवल उच्च और स्थिर वॉल्यूम पर। 2.50 USD प्रति GPU घंटे की अनुमानित दर पर, एक हमेशा चालू रहने वाला 8 GPU नोड प्रति माह 14,400 USD का पड़ता है। इतनी ही राशि में 15.00 USD प्रति मिलियन की पब्लिश की गई दर पर लगभग 960 मिलियन आउटपुट टोकन खरीदे जा सकते हैं। आपको आइडल घंटों, वेट डाउनलोड और क्लस्टर को चालू रखने वाले व्यक्ति के लिए भी भुगतान करना पड़ता है। बर्स्ट के लिए प्रति घंटे के हिसाब से किराए पर लें, और अनुमान लगाने के बजाय अपने स्वयं के मापे गए टोकन वॉल्यूम से तुलना करें।

गति के लिए 104B एक्टिव पैरामीटर्स का क्या अर्थ है?

इसका अर्थ है कि प्रति टोकन अंकगणितीय गणना 104B मॉडल के समान है, इसलिए थ्रूपुट 2.8T क्लास के बजाय उस क्लास में आता है। यह मेमोरी के बारे में कुछ नहीं कहता: सभी 2.8T पैरामीटर्स रेजिडेंट रहते हैं, क्योंकि राउटर किसी भी टोकन पर किसी भी एक्सपर्ट को कॉल कर सकता है। टोकन प्रति सेकंड का अनुमान लगाने के लिए एक्टिव काउंट का उपयोग करें, और VRAM का आकार निर्धारित करने के लिए टोटल काउंट का उपयोग करें।