Kimi K3 ను స్వయంగా హోస్ట్ చేయడానికి ఎంత VRAM కావాలి?

స్వయంగా Kimi K3 ను హోస్ట్ చేయడానికి అవసరమైన వనరులు

Kimi K3 ను స్వయంగా హోస్ట్ చేయాలంటే 2.8 ట్రిలియన్ parameters కు స్థలం కల్పించాలి. Moonshot open weights ను MXFP4 లో విడుదల చేసింది. ఇందులో ఒక్క weight కు సుమారు సగం byte పడుతుంది. అందువల్ల cache కోసం ఒక్క token కేటాయించకముందే 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 మరియు క్రియాశీల parameters సంఖ్య ఒకటే కాదు

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

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

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

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

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

ఒక్కో weight కు bytes, అలాగే terabytes ఎక్కడి నుంచి వస్తాయి

Parameter count ను ఒక్కో weight కు ఉన్న bytes తో గుణించాలి. 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 row వాస్తవమైనది. దాని పైన ఉన్న rows పరిమాణాన్ని పోల్చి చూపడానికి మాత్రమే ఉన్నాయి: అదే model ను bf16 లో ఉంచితే 5.6 TB అవసరం అవుతుంది. MXFP4 ప్రతి 32 weights ఉన్న block కు ఒకే shared 8-bit scale ను కూడా నిల్వ చేస్తుంది. దీనివల్ల సుమారు 6 శాతం అదనంగా చేరుతుంది. అందువల్ల published repository పరిమాణం ఖచ్చితమైన 1.4 TB కంటే 1.5 TB కు దగ్గరగా ఉంటుంది.

దీంతో సాధారణంగా ఉపయోగించే తప్పించుకునే మార్గం కూడా ఉండదు. "దాన్ని quantise చేయండి" అనే సూచన ఇక్కడ ఉపయోగపడదు, ఎందుకంటే విడుదలైన 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గా rent కు ఇవ్వని machine ను సూచిస్తాయి.

KV cache ఆశ్చర్యపరిచే అంశం

Weights స్థిరమైన ఖర్చు. KV (key value) cache అలా కాదు: ఇది context length పెరిగే కొద్దీ, అలాగే concurrent users సంఖ్య పెరిగే కొద్దీ పెరుగుతుంది. సాధారణ attention కోసం formula 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 వద్ద ఒక user కు 128 GiB అవసరం. ఇది ఒక conversation కోసం ఏ single 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 చేస్తుంది. అందువల్ల వాస్తవ per-token ఖర్చు ఈ worked example కంటే చాలా తక్కువగా ఉంటుంది. Moonshot latent dimensions ను ప్రచురించలేదు. కాబట్టి K3 కోసం per-user figure ను ఇవ్వను. మీ వ్యవస్థలో మీరే కొలవండి: చిన్న --max-model-len తో server ప్రారంభించండి, nvidia-smi తో memory ను monitor చేయండి, తరువాత allocation విఫలమయ్యే వరకు limit ను పెంచండి.

తదుపరి release లోనూ ఈ reasoning విధానం వర్తిస్తుంది. ఒక model million token context ను ప్రకటించి, దాని attention design గురించి ఏమీ చెప్పకపోతే, వేరే నిర్ధారణ వచ్చే వరకు cache నే ప్రధాన పరిమితిగా భావించండి.

స్థాయి 1: క్లస్టర్‌ను గంటల ప్రాతిపదికన అద్దెకు తీసుకోవడం

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

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

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

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

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

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

• 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 తరగతి MoE

పైన పేర్కొన్న ప్రతి జత ఒకేసారి ఒక request ను మాత్రమే అనుమానిస్తుంది. రెండవ వ్యక్తి prompt పంపిన వెంటనే, ప్రతి concurrent slot కు స్వంత KV cache అవసరం అవుతుంది. మీ వద్ద మిగిలిన VRAM, parallel slots మరియు queued requests మధ్య సమతుల్యతను Ollama యొక్క NUM_PARALLEL మరియు MAX_QUEUE settings నిర్ణయిస్తాయి.

GPU జతచేసిన VPS పై పనిచేసే 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 ను చదవండి. అందులో ఎన్ని layers offload అయ్యాయో చూపిస్తుంది. కొన్ని layers system RAM లోకి వెళ్లిపోతే, అవి 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 ఖర్చవుతుంది. ప్రతి మిలియన్ output tokens కు 15.00 USD చొప్పున, అదే మొత్తంతో API నుంచి సుమారు 960 million output tokens కొనవచ్చు. ఖర్చు పరంగా self-hosting ప్రయోజనకరంగా మారాలంటే నెలకు దాదాపు ఒక billion output tokens ఉత్పత్తి చేయాలి. అంటే రోజుకు సుమారు 30 million tokens ఉత్పత్తి చేయాలి. అలాగే cluster మొత్తం సమయం busy గా ఉండాలి. ఎందుకంటే idle GPUs కు కూడా busy GPUs మాదిరిగానే bill చేస్తారు. Prompt-heavy agent workloads ఈ పరిమితిని ఇంకా దూరం చేస్తాయి. పునరావృతమయ్యే context కు cache-hit rate వద్ద ప్రతి మిలియన్ tokens కు 0.30 USD చెల్లించాలి; cache-miss rate వద్ద ప్రతి మిలియన్ tokens కు 3.00 USD చెల్లించాలి.

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

ఏ serving stack ఏ tier కు సరిపోతుంది

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

llama.cpp మరియు Ollama tier 2 కు సరిపోతాయి. ఇవి ఒక machine, GGUF quantisation, model సరిపోనప్పుడు CPU offload, మరియు low concurrency కోసం రూపొందించబడ్డాయి. llama.cpp చాలా పెద్ద MoE ను కూడా technically load చేయగలదు. ఇందుకోసం ఎక్కువ layers ను system RAM లో ఉంచుతుంది. అయితే 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 class‌ను నిర్ణయిస్తాయి. 104B active parameters ఉన్న 2.8T MoE, 104B model‌లా compute చేస్తుంది.
3. ఒక్కో token‌కు KV cache, context length, concurrency — ఈ మూడింటి గుణితం weights కోసం memory ఖర్చు చేసిన తర్వాత కూడా పెరుగుతూ ఉండే వ్యయం.
4. ఒక్కో dollar‌కు tokens per second మాత్రమే ఏ tier ఎంచుకోవాలో నిర్ణయించే సంఖ్య. పైవన్నీ దానికి input.

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

FAQ

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

లేదు. Moonshot విడుదల చేసిన MXFP4 precisionలో weights పరిమాణం సుమారు 1.4 TB ఉంటుంది. ప్రస్తుతం విక్రయానికి ఉన్న అతిపెద్ద single acceleratorలో 288 GB మాత్రమే ఉంటుంది. MoE modelలో inactive experts ను disk నుంచి ఉపయోగకరమైన వేగంతో stream చేయడం సాధ్యం కాదు. Router ఏ tokenకైనా ఏ expertనైనా ఎంచుకోవచ్చు. PCIe fetchకు పట్టే సమయం token budget అనుమతించే సమయం కంటే చాలా ఎక్కువగా ఉంటుంది. కాబట్టి Kimi 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 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ను rentకు తీసుకోవడం చౌకా?

అధికంగా, నిరంతరంగా ఉండే 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ను నడుస్తూ ఉంచే వ్యక్తి ఖర్చులు కూడా ఉంటాయి. తాత్కాలిక అధిక workload కోసం గంటల ప్రాతిపదికన rentకు తీసుకోండి. అంచనాకు బదులుగా మీరు కొలిచిన token volumeతో పోల్చండి.

Speedపై 104B active parameters అంటే ఏమిటి?

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