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

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

Kimi K3 को self-host करने का अर्थ है 2.8 ट्रिलियन पैरामीटर्स के लिए जगह बनाना। Moonshot ने open weights को MXFP4 में प्रकाशित किया है, जो प्रति weight लगभग आधा बाइट है। इसलिए, 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.4 TB के बजाय 1.5 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, और एक साथ आने वाली दूसरी request के लिए कोई जगह शामिल नहीं है। ये एक ऐसे 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 है जो सर्वर को एक साथ कई requests को 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 है। पूरे एक million 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 एक million 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 प्रति माह है, जबकि 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 का अर्थ है कि प्रक्रिया अभी भी वेट्स (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 को स्थानीय रूप से चलाने" वाले अधिकांश चर्चा सूत्र बिना यह स्वीकार किए यहीं समाप्त हो जाते हैं।

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

• 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 की आवश्यकता होती है। यही वह समझौता है जो Ollama की NUM_PARALLEL और MAX_QUEUE सेटिंग्स आपके लिए parallel slots, queued requests और बचे हुए VRAM के बीच करती हैं।

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 लौटाता है, इसलिए tags को याददाश्त से टाइप करने के बजाय library page से copy करें। systemd unit और remote access सहित पूरी प्रक्रिया 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 को पढ़ें: यह बताता है कि कितनी layers offload की गई हैं। जो layers system RAM में चली जाती हैं, वे HBM bandwidth के बजाय RAM bandwidth पर चलती हैं, इसलिए जिस क्षण model fit होना बंद हो जाता है, generation की गति काफी कम हो जाती है। दोनों tools के बीच के अंतर 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 की गणना करते हैं। एक 8 GPU वाला node जो हमेशा चालू रहता है, उसकी लागत 14,400 USD प्रति माह है, और 15.00 USD प्रति मिलियन output tokens की दर से, उतनी ही राशि में API से लगभग 960 मिलियन output tokens मिलते हैं। लागत के मामले में लाभ पाने के लिए आपको प्रति माह लगभग एक बिलियन output tokens generate करने होंगे, यानी प्रतिदिन लगभग 30 मिलियन, और cluster को पूरे समय व्यस्त रखना होगा, क्योंकि idle GPUs का बिल भी busy GPUs की तरह ही आता है। Prompt-heavy agent workloads इस सीमा को और आगे बढ़ा देते हैं: बार-बार उपयोग होने वाले context का बिल 3.00 USD के cache-miss rate के बजाय 0.30 USD के cache-hit rate पर आता है।

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

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

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 अधिकांश layers को system RAM में रखकर एक विशाल MoE मॉडल को लोड कर सकता है, और 2.8T मॉडल के लिए यह गति प्रति टोकन कई सेकंड हो सकती है। यह केवल यह सिद्ध करता है कि फाइल पार्स हो रही है। यह ऐसी सर्विस नहीं है जिसे आप सीधे users के लिए उपलब्ध करा सकें। पूरी तुलना Ollama बनाम vLLM में दी गई है, और यह मॉडल के साथ नहीं बदलती: प्रश्न हमेशा यही रहता है कि क्या आप shared hardware पर कई users को सर्व कर रहे हैं या अपने स्वयं के hardware पर एक user को।

वे चार आंकड़े जो इस चेकपॉइंट के बाद भी प्रासंगिक रहते हैं

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

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

FAQ

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

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

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

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

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

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

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

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

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

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