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

Kimi K3 को self-host करने के लिए क्या आवश्यक है

Kimi K3 को self-host करने का अर्थ है 2.8 ट्रिलियन parameters के लिए जगह बनाना। Moonshot ने open weights को MXFP4 में प्रकाशित किया है, जो प्रति weight लगभग आधा byte है, इसलिए cache के लिए एक भी token allocate करने से पहले weights का आकार लगभग 1.4 TB हो जाता है। आज बाजार में उपलब्ध कोई भी accelerator इसे अकेले धारण नहीं कर सकता। K3 एक multi-node model है, और एक सर्वर के लिए इसका उत्तर 'नहीं' है।

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

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

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

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

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

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

यह सामान्य बचाव के रास्ते को बंद कर देता है। "बस इसे quantise कर दें" यहाँ काम नहीं आता, क्योंकि release किया गया checkpoint पहले से ही 4-bit में है। 2-bit पर जाने से weights का आकार 0.7 TB हो जाएगा और इससे सटीकता (accuracy) में ऐसी कमी आएगी जिसे इस checkpoint पर किसी ने मापा नहीं है। आप तब भी किसी भी एक कार्ड की क्षमता से बहुत आगे होंगे।

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, या एक साथ आने वाले दूसरे अनुरोध के लिए कोई जगह शामिल नहीं है। ये एक ऐसे समानांतर विभाजन (parallel split) को भी मानते हैं जो समान रूप से विभाजित होता है, जबकि 93 layers और 896 experts हमेशा इसकी अनुमति नहीं देते हैं।

प्रकाशित मार्गदर्शन इस न्यूनतम सीमा से काफी ऊपर है। अगस्त 2026 तक, Moonshot 64 या उससे अधिक accelerators के एक supernode की सिफारिश करता है, और SGLang cookbook में चार 8-GPU nodes, 32 GPUs और 2,560 GB aggregate memory से बना एक H100 configuration दिया गया है, जबकि इसकी न्यूनतम सीमा 18 cards है। यह अंतर बर्बादी नहीं है। यह KV cache, activation memory और वह headroom है जो सर्वर को एक साथ कई अनुरोधों को batch करने की अनुमति देता है। यहाँ तक कि सबसे अनुकूल श्रेणी, 5 GB300 class cards भी एक ऐसी मशीन का वर्णन करती है जिसे अधिकांश प्रदाता एकल SKU के रूप में किराए पर नहीं देते हैं।

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 है, जो एक conversation के लिए किसी भी एक card की क्षमता से अधिक है।

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 ने latent dimensions प्रकाशित नहीं किए हैं, इसलिए मैं K3 के लिए प्रति-user कोई आंकड़ा नहीं दूंगा। इसके बजाय अपना मापें: सर्वर को एक छोटे --max-model-len के साथ शुरू करें, nvidia-smi के साथ memory पर नज़र रखें, और फिर limit को तब तक बढ़ाएं जब तक allocation विफल न हो जाए।

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

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 के दौरान डेटासेंटर एक्सेलेरेटर्स के लिए ऑन-डिमांड सूची मूल्य लगभग 2 से 5 USD प्रति GPU घंटा रहे हैं, और आरक्षित क्षमता सस्ती होती है। अपने प्रदाता की वास्तविक संख्या लें और गणना को फिर से करें: GPU की संख्या गुणा घंटे गुणा दर। इस चार्ट का उद्देश्य अनुपात को समझना है। एक 8 GPU नोड को दिन में चार घंटे चलाने की लागत 2,400 USD प्रति माह है, जबकि SGLang के आकार वाले 32 GPU कॉन्फ़िगरेशन को लगातार चलाने की लागत 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 का अर्थ है कि प्रक्रिया अभी भी वेट्स (weights) लोड कर रही है या पहले ही बंद हो चुकी है, इसलिए पुनः प्रयास करने से पहले सर्वर लॉग पढ़ें।

पहले दिन होने वाली सामान्य विफलता मॉडल की तुलना में पुराना रनटाइम होना है। K3 को KDA और एक नई MoE लेयर के साथ जारी किया गया था, जो लॉन्च के समय स्थिर vLLM और SGLang रिलीज़ में उपलब्ध नहीं थी। इसका लक्षण यह है कि सर्वर स्टार्टअप के दौरान Model architectures [...] are not supported for now के रूप में एक लाइन के साथ बंद हो जाता है। कोई भी कॉन्फ़िगरेशन परिवर्तन इसे ठीक नहीं करता है, क्योंकि उन लेयर्स को चलाने के लिए आवश्यक कोड आपके बिल्ड में नहीं है। मॉडल कार्ड में बताए गए नाइटली (nightly) वर्ज़न को इंस्टॉल करें, या उस रिलीज़ की प्रतीक्षा करें जिसमें यह शामिल हो।

लागत संबंधी एक महत्वपूर्ण बात जो अक्सर लोगों को परेशान करती है: मीटर तब शुरू होता है जब इंस्टेंस शुरू होता है, न कि तब जब मॉडल तैयार हो जाता है। 1 GB/s की गति से 1.5 TB का डाउनलोड पहले टोकन से पहले क्लस्टर के लगभग 25 मिनट का समय लेता है। वेट्स को ऐसे वॉल्यूम पर रखें जो इंस्टेंस के समाप्त होने के बाद भी बना रहे, ताकि दूसरा रन कुछ ही मिनटों में शुरू हो सके।

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

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

Fit नियम का सूत्र छोटे पैमाने पर भी वही रहता है: 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

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

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

ollama run पहली बार उपयोग करने पर model को download करता है, और फिर आपको एक prompt पर ले आता है। जो tag मौजूद नहीं है, वह Error: model "..." not found लौटाता है, इसलिए tags को याददाश्त से टाइप करने के बजाय library page से copy करें। systemd unit और remote access सहित पूरी प्रक्रिया Ollama को 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 GPU पर हर layer की मांग करता है। Load log को पढ़ें: यह बताता है कि कितनी layers offload की गई हैं। जो layers system RAM में spill होती हैं, वे HBM bandwidth के बजाय RAM bandwidth पर चलती हैं, इसलिए जिस क्षण model fit होना बंद हो जाता है, generation speed दस गुना कम हो जाती है। इन दोनों tools के बीच के trade-offs 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 बदल गई है, क्योंकि providers checkpoints के बीच ids को retire कर देते हैं।

अब ऊपर दिए गए अनुमानित rental rate का उपयोग करके break-even point की गणना करते हैं। एक always-on 8 GPU node की लागत 14,400 USD प्रति माह है, और 15.00 USD प्रति मिलियन output tokens की दर से इतनी ही राशि में API से लगभग 960 मिलियन output tokens खरीदे जा सकते हैं। लागत के मामले में लाभ पाने के लिए आपको प्रति माह लगभग एक बिलियन output tokens generate करने होंगे, जो कि प्रतिदिन लगभग 30 मिलियन होते हैं, और cluster को पूरे समय व्यस्त रखना होगा, क्योंकि idle GPUs के लिए भी उतनी ही राशि का billing होता है जितनी busy GPUs के लिए। Prompt-heavy agent workloads इस सीमा को और आगे बढ़ा देते हैं: बार-बार उपयोग होने वाले context के लिए billing 3.00 USD के बजाय 0.30 USD प्रति मिलियन की cache-hit दर पर होती है।

इस tier में आप model के आसपास की हर चीज़ को self-host करते हैं: एक gateway जो API key को सुरक्षित रखता है ताकि वह कभी client तक न पहुँचे, request और response logs, retries, rate limits, और प्रति-उपयोगकर्ता बजट। यह बिना GPU वाले एक छोटे VPS पर चलता है। यही विभाजन closed weights पर भी लागू होता है, जहाँ self-hosting Claude model स्तर पर संभव नहीं है और orchestration ही एकमात्र हिस्सा है जिसे आप नियंत्रित करते हैं।

कौन सा serving stack किस tier में आता है

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

llama.cpp और Ollama tier 2 में आते हैं। ये एक मशीन, GGUF quantisation, मॉडल फिट न होने पर CPU offload, और कम concurrency को लक्षित करते हैं। तकनीकी रूप से llama.cpp अधिकांश layers को system RAM में रखकर एक विशाल MoE को load कर सकता है, लेकिन 2.8T मॉडल के लिए यह गति प्रति token कई सेकंड की होती है। यह केवल यह सिद्ध करता है कि file parse हो रही है। यह ऐसी service नहीं है जिसे आप users के लिए उपलब्ध करा सकें। पूर्ण तुलना Ollama बनाम vLLM में दी गई है, और यह मॉडल के साथ नहीं बदलती: प्रश्न हमेशा यही रहता है कि क्या आप shared hardware पर कई users को serve कर रहे हैं या अपने स्वयं के hardware पर एक user को।

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

1. कुल पैरामीटर्स को प्रति वेट बाइट्स से गुणा करने पर मेमोरी का न्यूनतम स्तर (memory floor) प्राप्त होता है। इससे कम मेमोरी पर कुछ भी रन नहीं होता, और एक बार जब release 4-bit पर आ जाए, तो कोई भी quantisation तकनीक इसे बहुत अधिक कम नहीं कर सकती।
2. सक्रिय पैरामीटर्स (active parameters) थ्रूपुट क्लास निर्धारित करते हैं। 104B सक्रिय पैरामीटर्स वाला 2.8T MoE मॉडल 104B मॉडल की तरह ही compute करता है।
3. प्रति टोकन KV cache, जिसे context length और concurrency से गुणा किया जाता है, वह लागत है जो weights के लिए भुगतान करने के बाद भी लगातार बढ़ती रहती है।
4. प्रति डॉलर टोकन प्रति सेकंड (Tokens per second per dollar) ही वह एकमात्र संख्या है जो टियर का चयन करती है। ऊपर दी गई सभी बातें इसके लिए इनपुट हैं।

इन चार बिंदुओं को किसी भी release पर लागू करें और आप वेंडर गाइड खोलने से पहले ही सही उत्तर प्राप्त कर लेंगे। इसके बाद, आपके द्वारा लिखी गई प्रत्येक संख्या पर तारीख अंकित करें। K3 के लॉन्च होने के दो सप्ताह के भीतर ही कीमतें और समर्थित-आर्किटेक्चर (supported-architecture) सूचियाँ बदल गई थीं, और इस पृष्ठ पर दी गई प्रत्येक संख्या जुलाई 2026 में प्रकाशित की गई है।

FAQ

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

नहीं। Moonshot द्वारा प्रदान किए गए MXFP4 precision पर weights का आकार 1.4 TB है, और बाजार में उपलब्ध सबसे बड़ा सिंगल एक्सीलरेटर 288 GB का है। एक MoE मॉडल अपने inactive experts को डिस्क से उपयोगी गति पर स्ट्रीम नहीं कर सकता, क्योंकि राउटर किसी भी टोकन के लिए किसी भी expert को चुन सकता है और PCIe फेच टोकन बजट की अनुमति से कहीं अधिक समय लेता है। Kimi K3 का सबसे छोटा व्यावहारिक डिप्लॉयमेंट एक मल्टी-GPU नोड है, और प्रकाशित रेसिपी में 32 या उससे अधिक एक्सीलरेटर का उपयोग किया जाता है।

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

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

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

उपयोगी रूप से नहीं। जारी किया गया चेकपॉइंट पहले से ही क्वांटाइजेशन-अवेयर ट्रेनिंग के साथ 4-बिट में है, इसलिए आसान बचत पहले ही की जा चुकी है। इसे फिर से आधा करके 2-बिट करने पर weights 0.7 TB हो जाते हैं, जो अभी भी सबसे बड़े कार्ड की क्षमता से दोगुने से अधिक है, और इस मॉडल पर 2-बिट की सटीकता लागत (accuracy cost) को मापा नहीं गया है।

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

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

गति के लिए 104B active parameters का क्या अर्थ है?

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