Ano ang Kailangan para i-Self-Host ang Kimi K3

Ano ang kailangan para i-self-host ang Kimi K3

Ang pag-self-host ng Kimi K3 ay nangangailangan ng sapat na kapasidad para sa 2.8 trilyong parameter. Inilabas ng Moonshot ang open weights sa MXFP4, na humigit-kumulang kalahating byte bawat weight. Dahil dito, umaabot sa tinatayang 1.4 TB ang weights pa lamang bago ka maglaan ng kahit isang token para sa cache. Walang accelerator na kasalukuyang ibinebenta ang kayang maglaman ng ganitong laki nang mag-isa. Multi-node model ang K3, kaya para sa isang server, hindi ito posible.

Iyan ang konklusyon. Nasa ibaba ang arithmetic na pinagbabatayan nito, dahil ang arithmetic ang magagamit mong muli sa susunod na release. Nag-publish ang ilang infrastructure vendor ng deployment guide para sa K3 sa mga linggo matapos ang announcement noong 17 July 2026, at ipinagpalagay ng bawat isa na mayroon ka nang cluster. Nagsisimula ang page na ito sa kabilang panig: magkano ang kakailanganin, ano ang maaari mong patakbuhin bilang alternatibo, at paano matutukoy kung alin sa dalawang sitwasyong ito ang kinalalagyan mo.

Hindi pareho ang kabuuang parameters at mga aktibong parameters

Ang K3 ay isang mixture of experts model. Hinahati ng MoE (mixture of experts) ang network sa maraming sub-network, at pinapapili ang router ng ilan sa mga ito para sa bawat token. Nakalista sa model card ang 2.8T na kabuuang parameters at 104B na activated per token, mula sa 896 routed experts na 16 lamang ang gumagana para sa bawat token, sa 93 layers.

Magkaibang tanong ang sinasagot ng dalawang bilang na ito. Ang pagpapalit sa mga ito ang pinakakaraniwang pagkakamali sa bawat thread na nagtatanong kung kayang patakbuhin ang model.

Tinutukoy ng active parameters ang compute cost. Dumadaan ang isang token sa humigit-kumulang 104B parameters, kaya ang throughput na dapat mong asahan ay mas kahawig ng 104B dense model kaysa sa 2.8T model. Ito ang pangunahing dahilan kung bakit gumagamit ng MoE.

Tinutukoy ng total parameters ang memory cost. Maaaring pumili ang router ng kahit anong expert para sa anumang token, kaya kailangang nasa memory ang lahat ng expert bago dumating ang unang request. Hindi puwedeng 104B lamang ang ilagay sa VRAM at kunin ang iba kapag kinakailangan, dahil kailangang matapos ang pagkuha sa loob ng microseconds, samantalang ang PCIe link ay naglilipat lamang ng ilang dosenang gigabytes bawat segundo. Sinusubukan pa rin ito ng ilang tao. Kapag nag-stream ng experts mula sa NVMe, ang model na dapat sana ay naglalabas ng dose-dosenang token bawat segundo ay naglalabas na lamang ng isang token bawat ilang segundo.

Kaya mura itong i-compute ngunit mahal itong i-store. I-size ang hardware batay sa 2.8T. I-base ang inaasahang bilis sa 104B.

Bytes bawat weight, at kung saan nanggagaling ang terabytes

Parameter count times bytes bawat weight. Para sa weights, iyon ang buong 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
  }
]

Sinanay ang K3 na may quantisation awareness at inilabas na may MXFP4 weights at MXFP8 activations, kaya ang 4-bit na row ang aktuwal na halaga. Nariyan ang mga row sa itaas nito bilang batayan: sa bf16, mangangailangan ang parehong model ng 5.6 TB. Nag-iimbak din ang MXFP4 ng isang shared 8-bit scale para sa bawat block na may 32 weights. Nagdaragdag ito ng humigit-kumulang 6 porsiyento, kaya mas malapit sa 1.5 TB ang published repository kaysa sa eksaktong 1.4 TB.

Inaalis nito ang karaniwang paraan ng pag-iwas sa problema. Hindi makatutulong dito ang “I-quantise na lang,” dahil 4-bit na ang inilabas na checkpoint. Kung ibababa sa 2-bit, magiging 0.7 TB ang weights, at bababa ang accuracy sa antas na wala pang nakasukat para sa checkpoint na ito. Lalampas pa rin ito nang malaki sa kapasidad ng isang card.

Ilang GPU ang kailangan ng Kimi K3

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

Ituring ang mga ito bilang minimum, hindi target. Mga weights lang ang binibilang ng mga ito: walang KV cache, activation buffers, fragmentation ng allocator, at espasyo para sa ikalawang concurrent request. Ipinapalagay din ng mga ito ang parallel split na pantay ang paghahati, na hindi palaging posible sa 93 layers at 896 experts.

Mas mataas sa minimum ang mga inilalathalang gabay. Noong August 2026, inirerekomenda ng Moonshot ang isang supernode na may 64 o higit pang accelerators, at may configuration ang SGLang cookbook para sa H100 na binubuo ng apat na 8-GPU node, 32 GPU, at 2,560 GB na pinagsamang memory, kumpara sa minimum na 18 cards. Hindi aksaya ang diperensiyang iyon. Para ito sa KV cache, activation memory, at headroom na nagpapahintulot sa server na mag-batch ng maraming request nang sabay-sabay. Kahit ang pinakamainam na row, ang 5 GB300 class cards, ay naglalarawan ng machine na hindi inirirenta ng karamihan ng provider bilang iisang SKU.

Ang KV cache ang bahaging nakakagulat sa maraming tao

Fixed cost ang weights. Hindi ganoon ang KV (key value) cache: lumalaki ito batay sa haba ng context at muli sa bawat concurrent user. Para sa ordinary attention, ang formula ay bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, at pagkatapos ay i-multiply ito sa context length at concurrency.

Narito ang isang worked example, at halimbawa lamang ito: 64 layers, 8 KV heads, head dimension na 128, at fp8. Nagbibigay ito ng 2 64 8 128 1 = 131,072 bytes, o 128 KiB bawat token.

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

Ang isang user na may 128k context ay kumokonsumo ng 16 GiB. Ang isang user sa buong million ay kumokonsumo ng 128 GiB, na mas malaki kaysa sa kayang ilaman ng anumang single card, para sa isang conversation.

Hindi gumagamit ang K3 ng ordinary attention, at iyon ang dahilan ng huling numerong iyon. Ang 93 layers nito ay binubuo ng 69 KDA (Kimi Delta Attention) layers at 24 Gated MLA (multi-head latent attention) layers. Pinananatili ng KDA ang fixed-size recurrent state sa halip na cache na lumalaki sa bawat token, at kino-compress ng MLA ang key at value sa isang low-rank latent vector. Dahil dito, mas mababa nang malaki ang aktuwal na per-token cost kaysa sa worked example. Hindi inilathala ng Moonshot ang latent dimensions, kaya hindi ako magbibigay ng per-user figure para sa K3 mismo. Sukatin na lang ang iyong setup: simulan ang server gamit ang maliit na --max-model-len, i-monitor ang memory gamit ang nvidia-smi, at pagkatapos ay taasan ang limit hanggang mabigo ang allocation.

Nananatili ang ganitong paraan ng pagsusuri sa susunod na release. Kung nag-a-advertise ang isang model ng million-token context at walang sinasabi tungkol sa attention design nito, ipagpalagay na ang cache ang binding constraint hanggang may makapagpatunay ng iba.

Tier 1: umupa ng cluster kada oras

Ito lamang ang tier na nagpapatakbo mismo ng K3. Hindi mo binibili ang hardware. Inuupahan mo ito para sa mga oras na kailangan mo, at itinitigil mo pagkatapos.

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

Ang rate ay isang palagay, hindi isang opisyal na quote. Ang on-demand list price para sa mga datacentre accelerator ay humigit-kumulang nasa pagitan ng 2 at 5 USD kada GPU hour hanggang 2026, at mas mura ang reserved capacity. Gamitin ang aktuwal na numero ng provider mo at ulitin ang multiplication: GPUs times hours times rate. Ang ipinapakita ng chart ay ang ratio. Ang pag-burst ng isang 8 GPU node nang apat na oras bawat araw ay nagkakahalaga ng 2,400 USD kada buwan, samantalang ang pagpapatakbo sa configuration na SGLang-sized para sa 32 GPU ay nagkakahalaga ng 57,600 USD.

Naglalabas ang dalawang pangunahing server ng launch command sa model card.

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

Hindi mo ginagamit ang alinman sa dalawang bare command sa isang aktuwal na cluster. Idagdag ang mga parallelism flag na tumutugma sa hardware mo: ginagamit ng SGLang ang --tp-size para sa tensor parallel at --ep-size para sa expert parallel, at kailangang katumbas ng aktuwal na bilang ng GPUs na mayroon ka ang product ng dalawang ito.

Tiyaking gumagana na ang server bago ka magpadala ng aktuwal na traffic:

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

Ang healthy na server ay sumasagot gamit ang isang JSON object na naglilista ng model id. Ibig sabihin ng Connection refused ay nilo-load pa ng proseso ang weights o nag-exit na ito, kaya basahin ang server log bago ka muling mag-retry.

Ang karaniwang failure sa unang araw ay runtime na mas luma kaysa sa model. Nag-release ang K3 kasama ang KDA at isang bagong MoE layer na wala sa stable vLLM at SGLang releases noong ilunsad ang model, at ang sintomas ay nag-e-exit ang server habang nagsisimula ito na may linyang may anyong Model architectures [...] are not supported for now. Walang config change na makapaglulutas nito, dahil wala sa build mo ang code para patakbuhin ang mga layer na iyon. I-install ang nightly na tinutukoy sa model card, o hintayin ang release na may suporta rito.

May isang cost detail na madalas nakakaligtaan. Nagsisimula ang meter kapag nagsimula ang instance, hindi kapag handa na ang model. Ang 1.5 TB download sa bilis na 1 GB/s ay humigit-kumulang 25 minuto ng cluster time bago lumabas ang unang token. I-stage ang weights sa volume na mananatili kahit matapos ang instance, para magsimula ang ikalawang run sa loob ng ilang minuto.

Tier 2: magpatakbo ng mas maliit na model sa isang accelerator

Hindi mo pinapatakbo ang K3 sa tier na ito. Sabihin ito nang malinaw bago magsimula, dahil dito nagtatapos ang karamihan sa mga thread tungkol sa “pagpapatakbo ng K3 locally” nang hindi ito inaamin.

Pareho ang formula ng fit rule, pero mas maliit ang saklaw: parameters times bytes per weight, dagdag ang KV cache at humigit-kumulang 2 GB na runtime overhead, ay kailangang magkasya sa iyong VRAM. Sa 4-bit, humigit-kumulang kalahating byte ito bawat parameter, kaya komportable ang mga sumusunod na pairing:

• 16 GB card: 7B model sa 4-bit, na may sapat na espasyo para sa mahabang context
• 24 GB card: 14B model sa 4-bit
• 48 GB card: 32B model sa 4-bit
• 80 GB card: 70B model sa 4-bit, o 30B class MoE sa 8-bit

Ang Ollama ang pinakamabilis na paraan para magkaroon ng gumaganang server sa isang VPS na may nakakabit na GPU:

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

Sa unang paggamit, dina-download ng ollama run ang model, pagkatapos ay dadalhin ka nito sa prompt. Kapag hindi umiiral ang isang tag, magbabalik ito ng Error: model "..." not found, kaya kopyahin ang mga tag mula sa library page sa halip na i-type ang mga ito mula sa memorya. Nasa pagpapatakbo ng Ollama sa isang VPS ang kumpletong walkthrough, kasama ang systemd unit at remote access.

Mas marami kang kontrol sa quantisation at offload kapag llama.cpp ang ginamit:

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

Hinihingi ng -ngl 99 na ilagay sa GPU ang bawat layer. Basahin ang load log: ipinapakita nito kung ilang layer ang na-offload. Ang mga layer na napupunta sa system RAM ay tumatakbo sa RAM bandwidth sa halip na HBM bandwidth, kaya bumababa nang isang order of magnitude ang generation speed kapag hindi na magkasya ang model. Tinalakay sa paghahambing ng Ollama at llama.cpp ang mga trade-off ng dalawang tool.

Tier 3: naka-host na API, self-hosted na 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"
  }
]

Compatible sa OpenAI ang endpoint, kaya gagana ang kasalukuyang client kapag pinalitan mo ang base 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."}]}'

Ang gumaganang key ay nagbabalik ng JSON object na may choices array. Ang 401 ay nangangahulugang mali ang key o nawawala ang Bearer prefix. Karaniwang nangangahulugan ang model-not-found error na nagbago ang id, dahil inaalis ng mga provider ang mga id sa pagitan ng mga checkpoint.

Ngayon, tingnan ang break-even gamit ang ipinagpalagay na rental rate sa itaas. Ang isang 8 GPU node na laging naka-on ay nagkakahalaga ng 14,400 USD bawat buwan. Sa halagang 15.00 USD bawat isang milyong output token, ang parehong halaga ay makakabili ng humigit-kumulang 960 milyong output token mula sa API. Para makatipid kumpara rito, kailangan mong makabuo ng halos isang bilyong output token bawat buwan, o humigit-kumulang 30 milyon bawat araw, at panatilihing abala ang cluster sa buong panahon. Pareho ang singil sa idle GPUs at sa mga GPU na ginagamit. Mas lumalayo pa ang break-even point sa prompt-heavy agent workloads. Ang paulit-ulit na context ay sinisingil sa cache-hit rate na 0.30 USD bawat isang milyon, sa halip na sa cache-miss rate na 3.00 USD.

Ang ise-self-host mo sa tier na ito ay ang lahat ng nasa paligid ng model: isang gateway na nagtatago ng API key upang hindi ito makarating sa client, request at response logs, retries, rate limits, at per-user budgets. Tumatakbo ito sa isang maliit na VPS na walang GPU. Pareho ang hatian para sa closed weights. Hindi posible ang pag-self-host ng Claude sa model level, kaya orchestration lamang ang pagmamay-ari mo.

Aling serving stack ang kabilang sa aling tier

Ang mga server na kabilang sa klase ng vLLM at SGLang ay nasa tier 1. Dinisenyo ang mga ito para mag-serve ng maraming request nang sabay-sabay, gamit ang continuous batching at paged KV cache, pati tensor at expert parallelism na ipinapamahagi sa ilang node. Ipinapalagay ng mga ito na gumagamit ka ng datacentre accelerators at mabilis na interconnect sa pagitan ng mga ito. Sa iisang consumer card, mas mahirap silang i-install at kakaunti ang mapapansing pakinabang.

Ang llama.cpp at Ollama ay nasa tier 2. Para ang mga ito sa isang machine, GGUF quantisation, CPU offload kapag hindi kasya ang model, at mababang concurrency. Teknikal na kayang i-load ng llama.cpp ang napakalaking MoE sa pamamagitan ng pagpapanatili ng karamihan sa mga layer sa system RAM, ngunit para sa 2.8T model, umaabot sa ilang segundo bawat token ang performance ng paraang ito. Pinatutunayan lamang nitong nababasa at napo-parse ang file. Hindi ito serbisyong maaaring paglagyan ng mga user. Nasa Ollama kumpara sa vLLM ang buong paghahambing, at hindi ito nagbabago batay sa model: ang tanong ay palaging kung nagse-serve ka ng maraming user sa shared hardware o isang user sa sarili mong machine.

Ang apat na numerong mananatiling mahalaga pagkatapos ng checkpoint na ito

1. Ang kabuuang parameters na minultiply sa bytes bawat weight ang nagbibigay ng minimum na memory requirement. Walang model na tatakbo nang mas mababa rito, at hindi na ito gaanong mababago ng quantisation trick kapag 4-bit na ang release.
2. Ang active parameters ang tumutukoy sa throughput class. Ang 2.8T MoE na may 104B active parameters ay nagko-compute na parang 104B model.
3. Ang KV cache bawat token, na minultiply sa context length at concurrency, ang patuloy na lumalaking cost matapos mong malaan ang memory para sa weights.
4. Ang tokens per second bawat dollar ang tanging numerong pumipili ng tier. Lahat ng nasa itaas ay input para rito.

Ilapat ang apat na ito sa anumang release upang makuha ang tamang sagot bago buksan ang vendor guide. Pagkatapos, ilagay ang petsa sa bawat figure na itatala mo. Nagbago ang mga presyo at listahan ng supported architecture sa loob ng dalawang linggo matapos ilunsad ang K3, at lahat ng numerong nasa page na ito ay inilathala noong July 2026.

FAQ

Maaari ko bang patakbuhin ang Kimi K3 sa iisang GPU?

Hindi. Humigit-kumulang 1.4 TB ang weights sa MXFP4 precision na inilabas ng Moonshot, at ang pinakamalaking single accelerator na mabibili ay may 288 GB lamang. Hindi maaaring i-stream ng MoE model mula sa disk ang mga inactive expert sa bilis na magagamit, dahil maaaring pumili ang router ng kahit anong expert sa bawat token at mas matagal nang malaki ang PCIe fetch kaysa sa token budget. Ang pinakamaliit na praktikal na deployment ng Kimi K3 ay multi-GPU node, at ang mga nailathalang recipe ay gumagamit ng 32 o higit pang accelerator.

Gaano karaming VRAM ang kailangan ng Kimi K3?

Magsimula sa 1.4 TB para sa weights lamang. Katumbas ito ng 18 H100 80GB cards o 5 GB300-class cards. Idagdag pa rito ang KV cache at activation memory. Noong August 2026, inirerekomenda ng Moonshot ang 64 o higit pang accelerator. Naglalathala rin ang SGLang cookbook ng 32 GPU H100 configuration na may pinagsamang 2,560 GB. Kaya ituring ang bilang para sa weights bilang minimum na basehan, hindi bilang eksaktong requirement.

Dahil ba sa quantisation ay magkakasya ang Kimi K3 sa isang node?

Hindi sa praktikal na paraan. 4-bit na at may quantisation-aware training ang inilabas na checkpoint, kaya nagamit na ang madaling matipid na memory. Kapag hinati pa ito sa 2-bit, magiging 0.7 TB ang weights. Mahigit dalawang beses pa rin ito sa kapasidad ng pinakamalaking card, at hindi pa nasusukat sa model na ito ang epekto ng 2-bit sa accuracy.

Mas mura ba ang pagrenta ng GPU kaysa sa Kimi K3 API?

Sa mataas at tuloy-tuloy na volume lamang. Kung ipagpapalagay ang halagang 2.50 USD bawat GPU hour, nagkakahalaga ang always-on na 8 GPU node ng 14,400 USD bawat buwan. Sa parehong halaga, makakabili ka ng humigit-kumulang 960 milyong output token sa inilathalang rate na 15.00 USD bawat milyon. Magbabayad ka rin para sa idle hours, pag-download ng weights, at taong nagpapanatiling gumagana ng cluster. Mag-rent kada oras para sa mga burst, at ikumpara ito sa aktuwal mong nasukat na token volume sa halip na sa hula.

Ano ang ibig sabihin ng 104B active parameters para sa speed?

Ibig sabihin, ang arithmetic bawat token ay katumbas ng sa 104B model. Kaya ang throughput ay nasa klase ng model na iyon, hindi sa 2.8T class. Wala itong sinasabi tungkol sa memory. Nanatili sa memory ang lahat ng 2.8T parameters dahil maaaring tawagin ng router ang kahit anong expert sa bawat token. Gamitin ang active count para tantiyahin ang tokens per second, at ang total count para sukatin ang kinakailangang VRAM.