Kimi K3 ను self-host చేయడానికి ఎంత VRAM అవసరం?

Kimi K3 ను self-host చేయడానికి అవసరమైన వనరులు

Kimi K3 ను self-host చేయాలంటే 2.8 trillion parameters కు స్థలం కల్పించాలి. Moonshot open weights ను MXFP4 లో ప్రచురించింది. ఇందులో ప్రతి weight కు సుమారు half a byte అవసరం. కాబట్టి ఒక్క token cache ను కూడా కేటాయించకముందే weights కు మాత్రమే సుమారు 1.4 TB అవసరం. ప్రస్తుతం విక్రయంలో ఉన్న ఏ accelerator కూడా ఈ మొత్తాన్ని ఒంటరిగా నిల్వ చేయలేను. K3 ఒక multi-node model. కాబట్టి ఒక server తో ఇది సాధ్యం కాదు.

ఇదే తుది నిర్ధారణ. క్రింద ఉన్న మొత్తం సమాచారం దాని వెనుక ఉన్న arithmetic. ఎందుకంటే తదుపరి release సమయంలో మళ్లీ ఉపయోగించేది ఈ arithmetic నే. 17 July 2026న ప్రకటన వెలువడిన తరువాతి వారాల్లో అనేక infrastructure vendors K3 deployment guides ను ప్రచురించాయి. వాటిలో ప్రతి guide కూడా మీ వద్ద ఇప్పటికే cluster ఉందని ఊహించింది. ఈ పేజీ దీనికి విరుద్ధమైన దిశ నుంచి ప్రారంభమవుతుంది: దీనికి ఎంత ఖర్చవుతుంది, దాని బదులుగా మీరు ఏమి run చేయవచ్చు, అలాగే ఈ రెండింటిలో మీరు ఏ పరిస్థితిలో ఉన్నారో ఎలా గుర్తించాలి.

మొత్తం parameters సంఖ్య, active parameters సంఖ్య ఒకేలా ఉండవు

K3 అనేది mixture of experts మోడల్. MoE (mixture of experts) network ను అనేక sub-networkలుగా విభజిస్తుంది. ప్రతి token కోసం వాటిలో కొన్నింటిని router ఎంచుకుంటుంది. Model cardలో 2.8T మొత్తం parameters, ప్రతి tokenకు 104B activated parameters ఉన్నట్లు పేర్కొంది. మొత్తం 896 routed expertsలో, 93 layers ద్వారా ఏ tokenకైనా 16 experts సక్రియమవుతాయి.

ఈ రెండు parameter లెక్కలు వేర్వేరు ప్రశ్నలకు సమాధానమిస్తాయి. వాటిని పరస్పరం మార్చడం ప్రతి "can I run this" చర్చలో కనిపించే అత్యంత సాధారణ తప్పు.

Active parameters compute costను నిర్ణయిస్తాయి. ప్రతి token సుమారు 104B parameters ద్వారా గణించబడుతుంది. కాబట్టి మీరు ఆశించాల్సిన throughput, 2.8T dense model కంటే 104B dense model throughput‌కు దగ్గరగా ఉంటుంది. MoE నిర్మించడానికి ఇదే ప్రధాన కారణం.

Total parameters memory costను నిర్ణయిస్తాయి. ఏ tokenకైనా router ఏ expertనైనా ఎంచుకోవచ్చు. అందువల్ల మొదటి request రాకముందే ప్రతి expert memoryలో residentగా ఉండాలి. మీరు VRAMలో 104B parameters మాత్రమే ఉంచి, మిగిలిన వాటిని అవసరమైనప్పుడు fetch చేయలేరు. ఎందుకంటే ఆ fetch కొన్ని microsecondsలో పూర్తవ్వాలి, కానీ PCIe link సెకనుకు కొన్ని tens of gigabytes మాత్రమే తరలిస్తుంది. కొందరు దీన్ని ప్రయత్నిస్తారు. NVMe నుంచి expertsను stream చేస్తే, ప్రతి సెకనుకు dozens of tokens ఇవ్వాల్సిన model, ప్రతి కొన్ని secondsకు ఒక token ఇచ్చే modelగా మారుతుంది.

అందువల్ల compute చేయడం తక్కువ ఖర్చుతో కూడుకున్నది, కానీ store చేయడం ఖరీదైనది. Hardware పరిమాణాన్ని 2.8T ఆధారంగా నిర్ణయించండి. Speedపై మీ అంచనాలను 104B ఆధారంగా నిర్ణయించండి.

బరువుకు బైట్లు, టెరాబైట్లు ఎక్కడి నుంచి వస్తాయి

Parameter count ను bytes per weight తో గుణిస్తే సరిపోతుంది. Weights కోసం పూర్తి formula ఇదే.

[
  {
    "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 వద్ద ఇదే model కు 5.6 TB అవసరం అవుతుంది. ప్రతి 32 weights block కు MXFP4 ఒక shared 8-bit scale ను కూడా నిల్వ చేస్తుంది. దీనివల్ల సుమారు 6 శాతం అదనంగా చేరుతుంది. అందుకే published repository పరిమాణం ఖచ్చితమైన 1.4 TB కంటే 1.5 TBకు దగ్గరగా ఉంటుంది.

దీంతో సాధారణంగా ఉపయోగించే తప్పించుకునే మార్గం కూడా ఉండదు. "Just quantise it" అని చెప్పడం ఇక్కడ ఉపయోగపడదు, ఎందుకంటే విడుదల చేసిన checkpoint ఇప్పటికే 4-bitలో ఉంది. 2-bitకు తగ్గిస్తే weights పరిమాణం 0.7 TBకు తగ్గుతుంది. అయితే ఈ checkpointపై ఆ మార్పు accuracyపై చూపే ప్రభావాన్ని ఎవరూ కొలవలేదు. అయినా అది ఏ single 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 buffers, allocator fragmentation, అలాగే రెండో concurrent request కోసం అవసరమైన అదనపు స్థలం ఇందులో ఉండదు. అదనంగా, parallel split సమానంగా విభజించబడుతుందని అవి భావిస్తాయి. అయితే 93 layers మరియు 896 experts ను ఎల్లప్పుడూ సమానంగా విభజించడం సాధ్యం కాదు.

ప్రచురితమైన మార్గదర్శకాలు ఈ కనీస పరిమితికంటే చాలా ఎక్కువ సామర్థ్యాన్ని సూచిస్తున్నాయి. August 2026 నాటికి Moonshot 64 లేదా అంతకంటే ఎక్కువ accelerators కలిగిన supernode ను సిఫార్సు చేస్తోంది. SGLang cookbook నాలుగు 8-GPU nodes తో రూపొందించిన H100 configuration ను అందిస్తోంది. ఇందులో 32 GPUs మరియు మొత్తం 2,560 GB memory ఉన్నాయి. ఇది 18 cards అనే కనీస పరిమితితో పోల్చాలి. ఈ తేడా వృథా కాదు. ఇందులో KV cache, activation memory, అలాగే server ఒకేసారి అనేక requests ను batch చేయడానికి అవసరమైన headroom ఉంటాయి. అత్యంత అనుకూలమైన వరుసలో ఉన్న 5 GB300 class cards కూడా, చాలా providers ఒకే SKUగా అద్దెకు ఇవ్వని machine ను సూచిస్తాయి.

KV cache ఆశ్చర్యం కలిగించే భాగం

Weights ఒక స్థిరమైన ఖర్చు. KV (key value) cache అలా కాదు: context length పెరిగే కొద్దీ, అలాగే concurrent users సంఖ్య పెరిగే కొద్దీ ఇది పెరుగుతుంది. సాధారణ attention కోసం సూత్రం bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. తరువాత దాన్ని context length మరియు concurrencyతో గుణించాలి.

ఇది ఒక worked example మాత్రమే: 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 కోసం ఏ single card సామర్థ్యానికన్నా ఎక్కువ.

K3 సాధారణ attention ను ఉపయోగించదు. ఆ చివరి సంఖ్యే దానికి కారణం. దాని 93 layersలో 69 KDA (Kimi Delta Attention) layers మరియు 24 Gated MLA (multi-head latent attention) layers ఉన్నాయి. ప్రతి token తో పెరిగే cache బదులుగా KDA స్థిర పరిమాణం గల recurrent state ను ఉంచుతుంది. MLA key మరియు valueలను ఒకే low rank latent vectorగా compress చేస్తుంది. అందువల్ల వాస్తవ per-token ఖర్చు ఈ worked example కంటే చాలా తక్కువగా ఉంటుంది. Moonshot latent dimensions ను ప్రచురించలేదు. కాబట్టి K3 కోసం per-user figure ను ఇవ్వను. బదులుగా మీ deployment లో కొలవండి: చిన్న --max-model-lenతో server ప్రారంభించి, nvidia-smiతో memoryని monitor చేయండి. తరువాత allocation విఫలమయ్యే వరకు limit ను పెంచండి.

తదుపరి releaseలోనూ ఈ reasoning విధానం వర్తిస్తుంది. ఒక 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"
  }
]

ఇక్కడి రేటు ఒక అంచనా మాత్రమే; ఇది అధికారిక ధర కాదు. 2026 వరకు datacentre accelerators కు on-demand list prices GPU గంటకు సుమారుగా 2 నుంచి 5 USD మధ్య ఉన్నాయి. Reserved capacity ఇంకా చౌకగా ఉంటుంది. మీ provider ఇచ్చే వాస్తవ రేటును తీసుకుని లెక్కను మళ్లీ చేయండి: GPUs × hours × rate. ఈ chart ఉద్దేశం నిష్పత్తిని చూపడమే. రోజుకు నాలుగు గంటలపాటు 8 GPU node ను burst చేయడానికి నెలకు 2,400 USD ఖర్చవుతుంది. SGLang కోసం పరిమాణం నిర్ణయించిన 32 GPU configuration ను నిరంతరం నడిపితే 57,600 USD ఖర్చవుతుంది.

ప్రధానంగా ఉపయోగించే రెండు servers తమ 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 లో మీరు ఈ రెండు commands ను యథాతథంగా అమలు చేయరు. మీ hardware కు సరిపోయే parallelism flags ను జోడించాలి: tensor parallel కోసం SGLang --tp-size ను, expert parallel కోసం --ep-size ను ఉపయోగిస్తుంది. ఈ రెండింటి గుణితం మీ వద్ద వాస్తవంగా ఉన్న GPUs సంఖ్యకు సమానంగా ఉండాలి.

నిజమైన 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 తో విడుదలైంది. అయితే stable vLLM మరియు SGLang releases లో launch సమయంలో ఇవి లేవు. Startup సమయంలో server Model architectures [...] are not supported for now రూపంలోని పంక్తితో exit కావడం దీని లక్షణం. Configuration మార్చడం వల్ల ఇది పరిష్కరించబడదు, ఎందుకంటే ఆ layers ను నడిపే code మీ build లో లేదు. Model card సూచించిన nightly ను install చేయండి లేదా ఆ support ఉన్న release కోసం వేచి ఉండండి.

ఖర్చుకు సంబంధించిన ఒక ముఖ్యమైన విషయం ఉంది. Instance ప్రారంభమైన వెంటనే meter ప్రారంభమవుతుంది; model సిద్ధమైనప్పుడు కాదు. 1 GB/s వేగంతో 1.5 TB download చేయడానికి సుమారు 25 నిమిషాలు పడుతుంది. అంటే మొదటి token రాకముందే cluster సమయం ఖర్చవుతుంది. Instance కంటే ఎక్కువకాలం నిలిచే volume పై weights ను ముందుగానే stage చేయండి. అప్పుడు రెండో run కొన్ని నిమిషాల్లో ప్రారంభమవుతుంది.

Tier 2: ఒక accelerator పై చిన్న model నడపడం

ఈ tier లో K3 ను మీరు నడపడం లేదు. ప్రారంభించే ముందే దీనిని స్పష్టంగా చెప్పండి. ఎందుకంటే "run K3 locally" అనే చర్చల్లో చాలా వరకు ఈ దశ వద్దే ముగుస్తాయి, కానీ దాన్ని అంగీకరించవు.

సరిపోతుందో లేదో నిర్ణయించే నియమం అదే సూత్రం యొక్క చిన్న రూపం: parameters ను ప్రతి weight కు bytes తో గుణించిన మొత్తం, KV cache, అలాగే దాదాపు 2 GB runtime overhead కలిపిన మొత్తం మీ VRAM కంటే తక్కువగా ఉండాలి. 4-bit లో ఇది parameter కు సుమారు అర byte అవుతుంది. అందువల్ల ఈ కలయికలు సాధారణంగా సరిపోతాయి:

• 16 GB card: long 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

GPU అనుసంధానించిన VPS పై Ollama నడపడం ద్వారా పనిచేసే 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 నడపడం లో ఉంది.

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 ప్రతి layer ను GPU పై ఉంచాలని కోరుతుంది. load log ను చదవండి. అందులో offload చేసిన layers సంఖ్య కనిపిస్తుంది. system RAM లోకి వెళ్లిన layers, HBM bandwidth బదులుగా RAM bandwidth తో నడుస్తాయి. అందువల్ల model పూర్తిగా సరిపోని వెంటనే generation speed ఒక order of magnitude తగ్గుతుంది. ఈ రెండు tools మధ్య trade-offs ను Ollama మరియు llama.cpp పక్కపక్కన లో వివరించారు.

టియర్ 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 అంటే key తప్పుగా ఉందని లేదా Bearer prefix లేదని అర్థం. సాధారణంగా model-not-found error కు కారణం id మారడమే. ఎందుకంటే providers checkpoints మధ్య idలను retire చేస్తారు.

ఇప్పుడు, పైన ఊహించిన rental rate ఆధారంగా break-even ను చూద్దాం. ఎల్లప్పుడూ నడుస్తున్న 8 GPU node కు నెలకు 14,400 USD ఖర్చవుతుంది. ప్రతి million output tokens కు 15.00 USD చొప్పున అదే మొత్తంతో API ద్వారా సుమారు 960 million output tokens పొందవచ్చు. ఖర్చు పరంగా self-hosting ప్రయోజనకరంగా ఉండాలంటే నెలకు దాదాపు ఒక billion output tokens, అంటే రోజుకు సుమారు 30 million tokens, generate చేయాలి. అదనంగా cluster ను మొత్తం సమయం busyగా ఉంచాలి. ఎందుకంటే idle GPUs కు కూడా busy GPUs మాదిరిగానే billing జరుగుతుంది. Prompt-heavy agent workloads లో ఈ break-even మరింత దూరంగా ఉంటుంది. Repeated context కు cache-miss rate అయిన 3.00 USD కాకుండా, cache-hit rate అయిన ప్రతి million tokens కు 0.30 USD చొప్పున billing జరుగుతుంది.

ఈ tier లో మీరు self-host చేసేది model కాదు; model చుట్టూ ఉన్న మిగతా వ్యవస్థ. ఇందులో API key ను client కు ఎప్పటికీ చేరకుండా భద్రపరిచే gateway, request మరియు response logs, retries, rate limits, అలాగే ప్రతి user కు budgets ఉంటాయి. ఇవన్నీ GPU లేని చిన్న VPS పై నడుస్తాయి. Closed weights కు కూడా ఇదే విభజన వర్తిస్తుంది. అక్కడ model స్థాయిలో Claude ను self-host చేయడం సాధ్యం కాదు; మీరు స్వంతంగా నిర్వహించగలిగేది orchestration మాత్రమే.

ఏ serving stack ఏ tier కు చెందుతుంది

vLLM మరియు SGLang తరగతి servers tier 1 కు చెందుతాయి. ఇవి continuous batching, paged KV cache, అలాగే అనేక nodes మధ్య విస్తరించే tensor మరియు expert parallelism తో ఒకేసారి అనేక requests ను అందించడానికి రూపొందించబడ్డాయి. ఇవి datacentre accelerators మరియు వాటి మధ్య వేగవంతమైన interconnect ఉన్నాయని భావిస్తాయి. ఒకే consumer card పై వీటిని install చేయడం క్లిష్టంగా ఉంటుంది. మీరు గమనించగల ఉపయోగకరమైన ప్రయోజనం కూడా చాలా తక్కువగా ఉంటుంది.

llama.cpp మరియు Ollama tier 2 కు చెందుతాయి. ఇవి ఒక machine, GGUF quantisation, model సరిపోనప్పుడు CPU offload, అలాగే తక్కువ concurrency ను లక్ష్యంగా చేసుకుంటాయి. llama.cpp ఎక్కువ layers ను system RAM లో ఉంచి చాలా పెద్ద MoE model ను సాంకేతికంగా load చేయగలదు. అయితే 2.8T model కోసం ఆ విధానంలో ఒక్కో token కు సమయం seconds లో కొలవబడుతుంది. దాంతో file parse అవుతుందని మాత్రమే నిర్ధారించవచ్చు. Users కు అందించే service గా దీన్ని ఉపయోగించలేరు. పూర్తి పోలిక Ollama మరియు vLLM పోలిక లో ఉంది. Model మారినా ఈ విషయం మారదు: shared hardware పై అనేక users కు service అందిస్తున్నారా, లేక మీ స్వంత hardware పై ఒక user కు మాత్రమే service అందిస్తున్నారా అనేదే ఎల్లప్పుడూ ప్రధాన ప్రశ్న.

ఈ checkpoint ను మించినంత కాలం వర్తించే నాలుగు సంఖ్యలు

1. మొత్తం parameters ను ప్రతి weight కు bytes తో గుణిస్తే memory floor లభిస్తుంది. దాని కంటే తక్కువ memoryతో ఏదీ నడవదు. Release ఇప్పటికే 4-bitలో ఉంటే quantisation పద్ధతులు కూడా ఈ పరిమితిని పెద్దగా మార్చలేవు.
2. Active parameters throughput తరగతిని నిర్ణయిస్తాయి. 104B active parameters కలిగిన 2.8T MoE, 104B model లాగానే compute చేస్తుంది.
3. ప్రతి token కు KV cache, context length, concurrency — ఈ మూడింటి గుణితం weights కోసం ఇప్పటికే చెల్లించిన తర్వాత కూడా పెరుగుతూనే ఉండే ఖర్చు.
4. Tokens per second per dollar మాత్రమే ఏ tier ఎంచుకోవాలో నిర్ణయించే సంఖ్య. పైవన్నీ దానికి input.

ఈ నాలుగు అంశాలను ఏ release‌కైనా వర్తింపజేస్తే vendor guide తెరవకముందే సరైన సమాధానం లభిస్తుంది. తరువాత మీరు నమోదు చేసే ప్రతి సంఖ్యకు తేదీని కూడా జతచేయండి. K3 launch అయిన తర్వాత రెండు వారాల్లో prices మరియు supported-architecture lists రెండూ మారాయి. ఈ పేజీలోని ప్రతి సంఖ్య July 2026లో ప్రచురించబడినదే.

FAQ

నేను Kimi K3 ను ఒకే GPU పై నడపవచ్చా?

లేదు. Moonshot విడుదల చేసిన MXFP4 precision లో weights పరిమాణం సుమారు 1.4 TB ఉంటుంది. ప్రస్తుతం విక్రయంలో ఉన్న అతిపెద్ద single accelerator సామర్థ్యం 288 GB మాత్రమే. MoE model లో active లో లేని experts ను disk నుంచి ఉపయోగకరమైన వేగంతో stream చేయడం సాధ్యం కాదు. Router ఏ token కు అయినా ఏ expert ను ఎంచుకోవచ్చు. PCIe fetch కు పట్టే సమయం token budget అనుమతించే సమయం కంటే చాలా ఎక్కువగా ఉంటుంది. K3 కోసం కనీసం multi-GPU node అవసరం. ప్రచురించిన recipes లో 32 లేదా అంతకంటే ఎక్కువ accelerators ఉపయోగిస్తున్నారు.

Kimi K3 కు ఎంత VRAM అవసరం?

Weights కోసం మాత్రమే 1.4 TB నుంచి ప్రారంభించాలి. ఇది 18 H100 80GB cards లేదా 5 GB300 class cards కు సమానం. దీనికి అదనంగా KV cache మరియు activation memory అవసరం. August 2026 నాటికి Moonshot 64 లేదా అంతకంటే ఎక్కువ accelerators ను సిఫార్సు చేస్తోంది. SGLang cookbook లో మొత్తం 2,560 GB aggregate memory తో 32 GPU H100 configuration ప్రచురించబడింది. అందువల్ల weights సంఖ్యను కనీస పరిమితిగా పరిగణించాలి, తుది అవసరంగా కాదు.

Quantisation చేస్తే Kimi K3 ఒకే node లో సరిపోతుందా?

ప్రయోజనకరంగా సరిపోదు. విడుదలైన checkpoint ఇప్పటికే quantisation-aware training తో 4-bit గా ఉంది. అందువల్ల సులభంగా పొందగల memory saving ఇప్పటికే సాధించబడింది. దాన్ని మళ్లీ 2-bit కు తగ్గిస్తే weights పరిమాణం 0.7 TB అవుతుంది. ఇది ఇప్పటికీ అతిపెద్ద card సామర్థ్యానికి రెండింతలకంటే ఎక్కువ. ఈ model పై 2-bit వల్ల కలిగే accuracy నష్టాన్ని ఇంకా కొలవలేదు.

Kimi K3 API కంటే GPUs అద్దెకు తీసుకోవడం చౌకగా ఉంటుందా?

అధికంగా, నిరంతరంగా ఉండే workload ఉన్నప్పుడు మాత్రమే. GPU hour కు 2.50 USD అని ఊహిస్తే, ఎల్లప్పుడూ నడిచే 8 GPU node కు నెలకు 14,400 USD ఖర్చవుతుంది. అదే మొత్తంతో ప్రచురించిన 15.00 USD per million రేటు వద్ద సుమారు 960 million output tokens కొనవచ్చు. Idle hours, weights downloads మరియు cluster ను నడుస్తూ ఉంచే వ్యక్తి ఖర్చు కూడా చెల్లించాలి. Burst workloads కోసం hour ఆధారంగా rent చేయాలి. అంచనాపై కాకుండా, మీరు కొలిచిన token volume తో పోల్చాలి.

Speed విషయంలో 104B active parameters అంటే ఏమిటి?

ప్రతి token కు అవసరమైన arithmetic 104B model స్థాయిలో ఉంటుందని దీని అర్థం. కాబట్టి throughput 2.8T స్థాయిలో కాకుండా 104B స్థాయిలో ఉంటుంది. Memory అవసరంపై ఇది ఏమీ చెప్పదు. మొత్తం 2.8T parameters memory లోనే resident గా ఉంటాయి, ఎందుకంటే router ఏ token కు అయినా ఏ expert ను పిలవవచ్చు. Tokens per second అంచనా వేయడానికి active count ను ఉపయోగించాలి. VRAM పరిమాణాన్ని నిర్ణయించడానికి total count ను ఉపయోగించాలి.