Paano mag-self host ng Kimi K3: VRAM at hardware guide

Mga kinakailangan para sa self-hosting ng Kimi K3

Ang self-hosting ng Kimi K3 ay nangangahulugan ng paghahanap ng espasyo para sa 2.8 trillion parameters. Inilathala ng Moonshot ang open weights sa MXFP4, na humigit-kumulang kalahating byte bawat weight, kaya ang weights pa lamang ay aabot sa humigit-kumulang 1.4 TB bago ka pa maglaan ng kahit isang token ng cache. Walang accelerator na ibinebenta ngayon ang kayang maglaman nito nang mag-isa. Ang K3 ay isang multi-node model, at para sa iisang server, ang sagot ay hindi.

Iyan ang hatol. Ang lahat ng nasa ibaba ay ang aritmetika sa likod nito, dahil ang aritmetika ang bahaging magagamit mo muli sa susunod na release. Maraming infrastructure vendor ang naglathala ng mga deployment guide para sa K3 sa mga linggong sumunod sa anunsyo noong 17 July 2026, at bawat isa ay nag-assume na mayroon ka nang cluster. Ang pahinang ito ay magsisimula sa kabilang dulo: kung magkano ang gastos, ano ang maaari mong patakbuhin sa halip nito, at kung paano malalaman kung alin sa dalawang sitwasyong ito ang kinabibilangan mo.

Hindi magkapareho ang bilang ng total parameters at active parameters

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

Ang dalawang bilang ng parameter na ito ay sumasagot sa magkaibang tanong, at ang pagpapalit sa mga ito ang pinakakaraniwang pagkakamali sa bawat thread na nagtatanong kung "kaya ko ba itong patakbuhin."

Ang active parameters ang nagtatakda ng compute cost. Ang isang token ay nagmu-multiply sa humigit-kumulang 104B parameters, kaya ang throughput na dapat mong asahan ay kahalintulad ng isang 104B dense model at hindi ng 2.8T. Iyan ang buong dahilan kung bakit gumagawa ng MoE.

Ang total parameters ang nagtatakda ng memory cost. Maaaring pumili ang router ng kahit anong expert sa kahit anong token, kaya kailangang nakalagak na ang bawat expert bago pa dumating ang unang request. Hindi mo maaaring i-load ang 104B sa VRAM at kunin ang iba kapag kailangan na, dahil ang pag-fetch ay dapat matapos sa loob ng microseconds, samantalang ang PCIe link ay naglilipat lamang ng sampu-sampung gigabytes bawat segundo. May mga sumusubok nito. Ang pag-stream ng mga expert mula sa NVMe ay nagpapabagal sa model na dapat ay naglalabas ng dose-dosenang token bawat segundo tungo sa isa na naglalabas lamang ng isang token bawat ilang segundo.

Kaya naman, mura itong i-compute pero mahal itong i-store. Ibase ang laki ng hardware sa 2.8T. Ibase ang inaasahang bilis sa 104B.

Bytes bawat weight, at kung saan nanggagaling ang mga terabyte

Parameter count na pinarami ng bytes bawat weight. Para sa mga weight, iyan 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
  }
]

Ang K3 ay sinanay nang may quantisation awareness at inilabas na may MXFP4 weights at MXFP8 activations, kaya ang 4-bit row ang siyang totoo. Ang mga row sa itaas nito ay naroon para sa scale: sa bf16, ang parehong model ay mangangailangan ng 5.6 TB. Ang MXFP4 ay nag-iimbak din ng isang shared 8-bit scale para sa bawat block ng 32 weights, na nagdaragdag ng humigit-kumulang 6 na porsyento, kaya ang inilabas na repository ay mas malapit sa 1.5 TB kaysa sa malinis na 1.4 TB.

Isinasara nito ang karaniwang escape hatch. Hindi nakakatulong dito ang "i-quantise na lang," dahil ang inilabas na checkpoint ay 4-bit na. Ang pagbaba sa 2-bit ay magdadala sa mga weight sa 0.7 TB at magdudulot ng pagbaba sa accuracy na wala pang sumusukat sa checkpoint na ito. Lalampas ka pa rin nang malayo sa kapasidad ng kahit anong single 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 na requirement, hindi target. Binibilang lang nito ang mga weight: walang kasamang KV cache, activation buffers, allocator fragmentation, at walang espasyo para sa pangalawang sabay na request. Ipinapalagay din nito ang parallel split na pantay ang pagkakahati, na hindi laging posible dahil sa 93 layers at 896 experts.

Ang inilathalang gabay ay mas mataas kaysa sa minimum na ito. Simula noong Agosto 2026, inirerekomenda ng Moonshot ang isang supernode na may 64 o higit pang accelerator. Ang SGLang cookbook ay naglalabas ng H100 configuration na binuo mula sa apat na 8-GPU node, 32 GPU, at 2,560 GB ng aggregate memory, kumpara sa minimum na 18 na card. Ang agwat na iyon ay hindi sayang. Ito ay para sa KV cache, activation memory, at ang headroom na nagpapahintulot sa server na mag-batch ng maraming request nang sabay-sabay. Kahit ang pinaka-friendly na row, ang 5 GB300 class cards, ay naglalarawan ng isang machine na hindi karaniwang inuupahan ng mga provider bilang isang solong SKU.

Ang KV cache ang bahaging nakakagulat sa mga tao

Ang mga weight ay fixed cost. Ang KV (key value) cache ay hindi: lumalaki ito kasabay ng context length at 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 imumultiply ito sa context length at sa concurrency.

Narito ang isang halimbawa, at ito ay halimbawa lamang: 64 layers, 8 KV heads, head dimension 128, fp8. Nagreresulta ito sa 2 64 8 128 1 = 131,072 bytes, kaya 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 nagkakahalaga ng 16 GiB. Ang isang user sa full million ay nagkakahalaga ng 128 GiB, na mas malaki kaysa sa kayang hawakan ng kahit anong single card para sa isang usapan.

Hindi gumagamit ang K3 ng ordinary attention, at iyon ang dahilan kung bakit ganoon ang huling numero. Ang 93 layers nito ay binubuo ng 69 KDA (Kimi Delta Attention) layers at 24 Gated MLA (multi-head latent attention) layers. Ang KDA ay nagpapanatili ng fixed size recurrent state sa halip na cache na lumalaki sa bawat token, at ang MLA ay nagko-compress ng key at value sa isang low rank latent vector, kaya ang totoong per-token cost ay mas mababa nang malayo sa halimbawa. Hindi pa inilalathala ng Moonshot ang mga latent dimension, kaya hindi ako maglalagay ng per-user figure para sa K3 mismo. Sukatin na lang ang sa iyo: simulan ang server gamit ang maliit na --max-model-len, bantayan ang memory gamit ang nvidia-smi, at itaas ang limit hanggang sa mag-fail ang allocation.

Ang hugis ng reasoning ay mananatili sa susunod na release. Kung ang isang model ay nag-a-advertise ng million token context at walang sinasabi tungkol sa attention design nito, ipagpalagay na ang cache ang binding constraint hangga't walang nagpapatunay ng iba.

Tier 1: pag-arkila ng cluster kada oras

Ito lang ang tier na nagpapatakbo mismo ng K3. Hindi mo bibilhin ang hardware. Uuupahan mo lang ito para sa mga oras na kailangan mo at ititigil 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 pagtatantya lamang, hindi pinal na presyo. Ang on-demand list prices para sa mga datacentre accelerator ay nasa pagitan ng 2 hanggang 5 USD kada GPU hour hanggang 2026, at mas mura ang reserved capacity. Kunin ang totoong numero mula sa iyong provider at ulitin ang pag-multiply: GPUs beses hours beses rate. Ang layunin ng chart ay ipakita ang ratio. Ang pag-burst ng 8 GPU node sa loob ng apat na oras kada araw ay nagkakahalaga ng 2,400 USD kada buwan, habang ang pag-iwan sa SGLang na may 32 GPU configuration ay nagkakahalaga ng 57,600 USD.

Parehong naglalathala ng launch command ang mga mainstream server 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 ang mga bare command na ito ang pinapatakbo sa isang totoong cluster. Idagdag ang mga parallelism flag na tugma sa iyong hardware: gumagamit ang SGLang ng --tp-size para sa tensor parallel at --ep-size para sa expert parallel, at ang product ng mga ito ay dapat katumbas ng bilang ng GPUs na mayroon ka.

Siguraduhing tumatakbo na ang server bago ka magpadala ng totoong traffic:

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

Ang isang healthy na server ay sasagot ng JSON object na naglilista ng model id. Ang Connection refused ay nangangahulugang naglo-load pa ang process ng weights o kaya ay nag-exit na ito, kaya basahin ang server log bago mo subukan ulit.

Ang karaniwang failure sa unang araw ay ang runtime na mas luma kaysa sa model. Ang K3 ay inilabas kasama ang KDA at isang bagong MoE layer na wala sa stable vLLM at SGLang releases noong launch, at ang sintomas nito ay ang pag-exit ng server habang nag-i-startup na may linyang katulad ng Model architectures [...] are not supported for now. Walang config change ang makakaayos nito, dahil wala sa iyong build ang code para patakbuhin ang mga layer na iyon. I-install ang nightly version na nakasaad sa model card, o maghintay para sa release na may kasama nito.

Isang paalala sa gastos na madalas makaligtaan. Nagsisimula ang metro kapag nag-start ang instance, hindi kapag ready na ang model. Ang 1.5 TB na download sa bilis na 1 GB/s ay aabutin ng mga 25 minuto ng cluster time bago ang unang token. I-stage ang mga weight sa isang volume na hindi nabubura kasabay ng instance, para ang pangalawang run ay magsimula sa loob lamang ng ilang minuto.

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

Hindi ka nagpapatakbo ng K3 sa tier na ito. Sabihin mo ito nang malinaw bago ka magsimula, dahil karamihan sa mga thread na "magpatakbo ng K3 nang lokal" ay humihinto rito nang hindi ito inaamin.

Ang fit rule ay pareho lang na formula sa mas maliit na scale: parameters na pinarami sa bytes per weight, dagdagan ng KV cache, at dagdagan ng humigit-kumulang 2 GB na runtime overhead, dapat ay kasya ito sa loob ng iyong VRAM. Sa 4-bit, ito ay humigit-kumulang kalahating byte bawat parameter, na nagbibigay ng mga komportableng pairing:

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

Ang bawat pairing sa itaas ay nag-aassume ng isang request sa bawat pagkakataon. Sa sandaling magpadala ng prompt ang pangalawang tao, ang bawat concurrent slot ay mangangailangan ng sarili nitong KV cache. Ito ang trade-off na ginagawa para sa iyo ng Ollama's NUM_PARALLEL and MAX_QUEUE settings sa pagitan ng mga parallel slot, queued requests, at ang natitirang VRAM mo.

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

Ang ollama run ay nagda-download ng model sa unang gamit, pagkatapos ay dadalhin ka sa isang prompt. Ang tag na hindi umiiral ay magbabalik 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. Ang buong walkthrough, kasama ang systemd unit at remote access, ay nasa running Ollama on a VPS.

Ang llama.cpp ay nagbibigay sa iyo ng mas malawak na kontrol sa quantisation at 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

Ang -ngl 99 ay humihiling na ilagay ang bawat layer sa GPU. Basahin ang load log: ipinapakita nito kung ilang layers ang na-offload. Ang mga layer na napupunta sa system RAM ay tumatakbo gamit ang RAM bandwidth sa halip na HBM bandwidth, kaya ang bilis ng generation ay bumabagsak nang malaki sa sandaling hindi na kasya ang model. Ang mga trade-off sa pagitan ng dalawang tool na ito ay tinalakay sa Ollama and llama.cpp side by side.

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

Ang endpoint ay OpenAI compatible, kaya gagana ang isang existing client kapag binago 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 isang working key ay nagbabalik ng JSON object na may choices array. Ang 401 ay nangangahulugang mali ang key o kulang ang Bearer prefix. Ang model-not-found error ay kadalasang nangangahulugan na nagbago ang id, dahil nagreretiro ang mga provider ng mga id sa pagitan ng mga checkpoint.

Ngayon, ang break-even point gamit ang assumed rental rate sa itaas. Ang isang always-on 8 GPU node ay nagkakahalaga ng 14,400 USD kada buwan, at sa 15.00 USD kada isang milyong output tokens, ang parehong halaga ay makakabili ng humigit-kumulang 960 milyong output tokens mula sa API. Para makatipid, kailangan mong mag-generate ng halos isang bilyong output tokens kada buwan, humigit-kumulang 30 milyon kada araw, at panatilihing busy ang cluster sa buong oras, dahil ang mga idle GPU ay may parehong singil gaya ng mga busy na GPU. Ang mga prompt-heavy agent workload ay lalong nagpapalayo sa linyang ito: ang paulit-ulit na context ay sinisingil sa cache-hit rate na 0.30 USD kada milyon sa halip na cache-miss rate na 3.00 USD.

Ang self-hosted mo sa tier na ito ay lahat ng nasa paligid ng model: isang gateway na humahawak sa API key para 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. Ang parehong split ay nalalapat sa closed weights, kung saan ang self-hosting Claude ay hindi posible sa model level at orchestration lamang ang bahaging pagmamay-ari mo.

Aling serving stack ang nabibilang sa bawat tier

Ang mga server na gaya ng vLLM at SGLang ay nabibilang sa tier 1. Nilikha ang mga ito para mag-serve ng maraming request nang sabay-sabay, gamit ang continuous batching at paged KV cache, pati na ang tensor at expert parallelism na nakakalat sa maraming node. Ipinapalagay ng mga ito na mayroon kang mga datacentre accelerator at mabilis na interconnect sa pagitan ng mga ito. Sa isang consumer card, mas mabigat ang mga ito i-install at halos wala kang mapapansing benepisyo.

Ang llama.cpp at Ollama ay nabibilang sa tier 2. Nakatuon ang mga ito sa iisang machine, GGUF quantisation, CPU offload kapag hindi kasya ang model, at mababang concurrency. Sa teknikal na aspeto, kayang mag-load ng llama.cpp ng napakalaking MoE sa pamamagitan ng pagpapanatili ng karamihan sa mga layer sa system RAM, at para sa isang 2.8T model, ang bilis nito ay sinusukat sa segundo bawat token. Pinapatunayan nito na gumagana ang pag-parse ng file. Hindi ito isang serbisyo na maaari mong paglagyan ng mga user. Ang buong paghahambing ay nasa Ollama laban sa vLLM, at hindi ito nagbabago base sa model: ang tanong ay palaging kung nagse-serve ka ba ng maraming user sa shared hardware o isang user lang sa sarili mong machine.

Ang apat na numero na mananatiling may saysay paglampas sa checkpoint na ito

1. Ang kabuuang parameters na pinarami sa bytes bawat weight ang nagtatakda ng minimum na memory. Walang tatakbong model sa ibaba nito, at walang quantisation trick ang makakapagpababa nito nang malaki kapag ang release ay nasa 4-bit na.
2. Ang active parameters ang nagtatakda ng throughput class. Ang isang 2.8T MoE na may 104B active ay nag-compute gaya ng isang 104B model.
3. Ang KV cache bawat token, na pinarami sa context length at concurrency, ang gastos na patuloy na lumalaki matapos mong bayaran ang mga weight.
4. Ang tokens per second per dollar ang tanging numero na nagtatakda ng tier. Lahat ng nasa itaas ay input lamang para rito.

Ilapat ang apat na ito sa anumang release at makukuha mo ang tamang sagot bago mo pa buksan ang vendor guide. Lagyan ng petsa ang bawat figure na isusulat mo. Ang mga presyo at listahan ng supported-architecture ay parehong nagbago sa loob ng dalawang linggo matapos ilunsad ang K3, at bawat numero sa pahinang ito ay inilathala noong July 2026.

FAQ

Maaari ko bang patakbuhin ang Kimi K3 sa iisang GPU?

Hindi. Ang mga weight ay nasa 1.4 TB sa MXFP4 precision na inilabas ng Moonshot, at ang pinakamalaking single accelerator na mabibili ay may 288 GB lamang. Hindi kayang i-stream ng isang MoE model ang mga inactive expert nito mula sa disk sa bilis na magagamit, dahil maaaring pumili ang router ng kahit anong expert sa bawat token at ang PCIe fetch ay mas matagal kaysa sa pinapayagan ng token budget. Ang pinakamaliit na makabuluhang deployment ng K3 ay isang multi-GPU node, at ang mga published recipe ay gumagamit ng 32 accelerators o higit pa.

Gaano karaming VRAM ang kailangan ng Kimi K3?

Magsimula sa 1.4 TB para sa mga weight lamang, na katumbas ng 18 H100 80GB cards o 5 GB300 class cards. Idagdag pa rito ang KV cache at activation memory. Simula noong Agosto 2026, inirerekomenda ng Moonshot ang 64 o higit pang accelerators, at ang SGLang cookbook ay naglalathala ng 32 GPU H100 configuration na may 2,560 GB aggregate, kaya ituring ang figure ng mga weight bilang minimum at hindi bilang sapat na requirement.

Kasya ba ang Kimi K3 sa isang node gamit ang quantisation?

Hindi ito praktikal. Ang inilabas na checkpoint ay 4-bit na at dumaan sa quantisation-aware training, kaya nakuha na ang madaling matitipid na space. Kung hahatiin pa ito sa 2-bit, ang mga weight ay magiging 0.7 TB, na higit pa rin sa doble ng kapasidad ng pinakamalaking card, at ang epekto ng 2-bit sa accuracy ay hindi pa nasusukat sa model na ito.

Mas mura ba ang mag-renta ng GPU kaysa sa Kimi K3 API?

Lamang ito kung mataas at tuloy-tuloy ang volume. Sa presyong 2.50 USD bawat GPU hour, ang isang 8 GPU node na laging naka-on ay nagkakahalaga ng 14,400 USD kada buwan, at ang halagang ito ay makakabili ng humigit-kumulang 960 million output tokens sa published rate na 15.00 USD bawat milyon. Magbabayad ka rin para sa mga idle hours, pag-download ng weights, at sa taong magpapanatiling operational ng cluster. Mag-renta kada oras para sa mga burst, at ikumpara ito sa sarili mong nasukat na token volume sa halip na sa hula lamang.

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

Ibig sabihin nito, ang arithmetic bawat token ay katumbas ng isang 104B model, kaya ang throughput ay nasa class na iyon sa halip na sa 2.8T class. Wala itong kinalaman sa memory: ang lahat ng 2.8T parameters ay dapat manatiling resident, dahil maaaring tumawag ang router ng kahit anong expert sa bawat token. Gamitin ang active count para i-predict ang tokens per second, at ang total count para i-size ang VRAM.