Jinsi ya ku-self-host Kimi K3: Mwongozo wa kiufundi

Mahitaji ya ku-self-host Kimi K3

Ku-self-host Kimi K3 kunamaanisha kutafuta nafasi kwa ajili ya parameta trilioni 2.8. Moonshot ilichapisha uzani (weights) wazi katika muundo wa MXFP4, ambao ni takriban nusu baiti kwa kila uzani, kwa hivyo uzani pekee hufikia takriban 1.4 TB kabla ya kutenga hata token moja ya cache. Hakuna accelerator inayouzwa leo inayoweza kuhifadhi kiasi hicho peke yake. K3 ni modeli ya nodi nyingi (multi-node), na kwa seva moja jibu ni hapana.

Hiyo ndiyo hukumu. Kila kitu hapa chini ni hesabu iliyo nyuma ya jibu hilo, kwa sababu hesabu ndiyo sehemu unayoweza kutumia tena kwenye toleo lijalo. Wauzaji kadhaa wa miundombinu walichapisha miongozo ya uwekaji wa K3 katika wiki zilizofuata tangazo la tarehe 17 Julai 2026, na kila mmoja alichukulia kuwa tayari unamiliki nguzo (cluster) ya seva. Ukurasa huu unaanzia upande wa pili: gharama zake, nini unaweza kuendesha badala yake, na jinsi ya kutambua ni kundi lipi kati ya hayo mawili unalopo.

Jumla ya vigezo na vigezo amilifu si idadi sawa

K3 ni modeli ya aina ya mixture of experts (MoE). MoE hugawanya mtandao katika sub-networks nyingi na kuruhusu router kuchagua chache kati ya hizo kwa kila token. Kadi ya modeli inaorodhesha jumla ya vigezo 2.8T na 104B vinavyotumika (activated) kwa kila token, kutoka kwa 896 routed experts ambapo 16 huwashwa kwa token yoyote ile, katika tabaka 93.

Hesabu hizo mbili za vigezo hujibu maswali tofauti, na kuzichanganya ndilo kosa la kawaida zaidi katika kila mjadala wa "je, ninaweza kuendesha hii".

Vigezo amilifu huamua gharama ya kompyuta. Token huzidishwa kupitia takriban vigezo 104B, kwa hivyo throughput unayopaswa kutarajia inafanana na ile ya modeli ya 104B dense badala ya ile ya 2.8T. Hiyo ndiyo sababu nzima ya kujenga MoE.

Jumla ya vigezo huamua gharama ya kumbukumbu. Router inaweza kuchagua expert yeyote kwa token yoyote, kwa hivyo kila expert lazima awe amehifadhiwa kwenye kumbukumbu kabla ya ombi la kwanza kufika. Huwezi kuhifadhi 104B kwenye VRAM na kuchota mengine unapoyahitaji, kwa sababu uchotaji huo ungelazimika kukamilika ndani ya microseconds na link ya PCIe husafirisha makumi ya gigabytes kwa sekunde. Watu hujaribu kufanya hivyo. Kutiririsha (streaming) experts kutoka NVMe hugeuza modeli inayopaswa kutoa makumi ya tokens kwa sekunde kuwa ile inayotoa token moja kila baada ya sekunde chache.

Kwa hivyo, ni nafuu kukokotoa lakini ni ghali kuhifadhi. Pima vifaa vyako kulingana na 2.8T. Pima matarajio yako ya kasi kulingana na 104B.

Baiti kwa kila uzito, na chanzo cha terabytes

Idadi ya vigezo ikizidishwa na baiti kwa kila uzito. Hiyo ndiyo fomula kamili ya uzito.

[
  {
    "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 ilifunzwa kwa kuzingatia quantisation na kutolewa ikiwa na uzito wa MXFP4 na activation za MXFP8, kwa hivyo safu ya 4-bit ndiyo sahihi. Safu zilizo juu yake zipo kwa ajili ya kulinganisha: katika bf16, modeli hiyo hiyo ingehitaji 5.6 TB. MXFP4 pia huhifadhi scale moja ya 8-bit inayoshirikiwa kwa kila block ya uzito 32, jambo ambalo huongeza takriban asilimia 6, kwa hivyo repository iliyochapishwa iko karibu na 1.5 TB kuliko 1.4 TB kamili.

Hii inafunga njia ya kawaida ya kuepuka tatizo hili. "I-quantise tu" haisaidii hapa, kwa sababu checkpoint iliyotolewa tayari ni 4-bit. Kushuka hadi 2-bit kungeleta uzito kufikia 0.7 TB na kupunguza usahihi ambao hakuna mtu aliyepima kwenye checkpoint hii. Bado ungekuwa mbali sana na uwezo wa kadi yoyote moja.

Kimi K3 inahitaji GPU ngapi

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

Chukulia namba hizi kama kiwango cha chini, si lengo. Namba hizi huhesabu uzito (weights) pekee: hazijumuishi KV cache, buffer za activation, mgawanyiko wa allocator, wala nafasi kwa ajili ya ombi la pili linalokuja kwa wakati mmoja. Pia, zinadhani mgawanyo wa sambamba (parallel split) unaogawanyika sawasawa, jambo ambalo tabaka 93 na wataalamu 896 hawaruhusu kila wakati.

Mwongozo uliotolewa uko juu zaidi ya kiwango hicho cha chini. Kufikia Agosti 2026, Moonshot inapendekeza supernode ya accelerators 64 au zaidi, na cookbook ya SGLang inatoa usanidi wa H100 ulioundwa kutoka node nne za GPU 8, jumla ya GPU 32 na kumbukumbu ya 2,560 GB, dhidi ya kiwango cha chini cha 18 kadi. Pengo hilo si upotevu. Ni kwa ajili ya KV cache, kumbukumbu ya activation, na nafasi ya ziada inayoruhusu seva kuchakata maombi mengi kwa wakati mmoja. Hata safu inayofaa zaidi, kadi za daraja la 5 GB300, inaelezea mashine ambayo watoa huduma wengi hawapangishi kama SKU moja.

KV cache ndiyo sehemu inayowashangaza watu

Weights ni gharama isiyobadilika. KV (key value) cache sivyo: hukua kulingana na urefu wa muktadha (context length) na pia kwa kila mtumiaji anayefanya kazi kwa wakati mmoja. Kwa attention ya kawaida, fomula ni bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, kisha unazidisha kwa urefu wa muktadha na kwa idadi ya watumiaji.

Huu hapa ni mfano wa hesabu, na ni mfano tu: tabaka 64, KV heads 8, ukubwa wa head 128, fp8. Hiyo inatoa 2 64 8 128 1 = 131,072 bytes, yaani 128 KiB kwa kila 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
  }
]

Mtumiaji mmoja mwenye muktadha wa 128k anagharimu 16 GiB. Mtumiaji mmoja mwenye muktadha kamili wa milioni moja anagharimu 128 GiB, ambayo ni zaidi ya uwezo wa kadi yoyote moja, kwa ajili ya mazungumzo moja tu.

K3 haitumii attention ya kawaida, na namba hiyo ya mwisho ndiyo sababu. Tabaka zake 93 zinajumuisha tabaka 69 za KDA (Kimi Delta Attention) na tabaka 24 za Gated MLA (multi-head latent attention). KDA huhifadhi hali ya mara kwa mara (recurrent state) yenye ukubwa usiobadilika badala ya cache inayokua kwa kila token, na MLA hubana key na value kuwa vector moja ya chini (low rank latent vector), kwa hivyo gharama halisi kwa kila token inashuka sana chini ya mfano uliotolewa. Moonshot haijachapisha vipimo vya latent, kwa hivyo sitaweka takwimu ya kila mtumiaji kwa K3 yenyewe. Pima yako badala yake: anzisha seva kwa --max-model-len ndogo, fuatilia kumbukumbu kwa nvidia-smi, kisha ongeza kikomo hadi allocation itakaposhindwa.

Umbo la hoja (reasoning) litadumu hadi toleo lijalo. Ikiwa modeli inatangaza muktadha wa token milioni moja na haisemi chochote kuhusu usanifu wake wa attention, chukulia kuwa cache ndiyo kizuizi kikuu hadi mtu mwingine atakapothibitisha vinginevyo.

Tier 1: kukodisha cluster kwa saa

Hii ndiyo tier pekee inayoendesha K3 yenyewe. Hununui maunzi. Unayakodisha kwa saa unazohitaji na unayasimamisha baadaye.

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

Kiwango cha bei ni makadirio, si nukuu rasmi. Bei za orodha za on-demand kwa accelerators za datacentre zilikuwa kati ya 2 na 5 USD kwa kila saa ya GPU hadi mwaka 2026, na uwezo uliotengwa (reserved capacity) ni nafuu zaidi. Chukua namba halisi ya mtoa huduma wako na ufanye hesabu upya: idadi ya GPU mara saa mara kiwango cha bei. Lengo la chati hii ni kuonyesha uwiano. Kuendesha node ya GPU 8 kwa saa nne kwa siku kunagharimu 2,400 USD kwa mwezi, wakati kuacha usanidi wa GPU 32 wa SGLang ukiendelea kuwaka kunagharimu 57,600 USD.

Seva zote mbili kuu huchapisha amri ya uzinduzi kwenye 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

Hakuna amri yoyote kati ya hizo mbili unayopaswa kuiendesha kama ilivyo kwenye cluster halisi. Ongeza flag za parallelism zinazolingana na maunzi yako: SGLang hutumia --tp-size kwa tensor parallel na --ep-size kwa expert parallel, na zao la namba hizo lazima liwe sawa na idadi ya GPU ulizonazo.

Hakikisha seva imewaka kabla ya kutuma traffic halisi:

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

Seva iliyo katika hali nzuri hujibu kwa JSON object inayoorodhesha model id. Connection refused inamaanisha mchakato bado unapakia weights au tayari umesimama, kwa hivyo soma log ya seva kabla ya kujaribu tena.

Hitilafu ya kawaida siku ya kwanza ni runtime kuwa ya zamani kuliko model. K3 ilitoka ikiwa na KDA na MoE layer mpya ambayo matoleo thabiti (stable releases) ya vLLM na SGLang hayakuwa nayo wakati wa uzinduzi, na dalili yake ni seva kusimama wakati wa kuanza ikiwa na mstari wa aina ya Model architectures [...] are not supported for now. Hakuna mabadiliko ya config yanayoweza kurekebisha hilo, kwa sababu code ya kuendesha layers hizo haipo kwenye build yako. Sakinisha toleo la nightly ambalo model card inataja, au subiri toleo litakalokuwa nalo.

Ujumbe mmoja kuhusu gharama unaowachanganya watu. Mita huanza kuhesabu wakati instance inapoanza, si wakati model inapokuwa tayari. Download ya 1.5 TB kwa kasi ya 1 GB/s inachukua takriban dakika 25 za muda wa cluster kabla ya token ya kwanza. Hifadhi weights kwenye volume inayodumu zaidi ya instance, ili uendeshaji wa pili uanze ndani ya dakika chache.

Tier 2: endesha modeli ndogo kwenye accelerator moja

Hauendeshi K3 katika tier hii. Tamka hili kwa sauti kabla ya kuanza, kwa sababu nyuzi nyingi za "run K3 locally" huishia hapa bila kukiri ukweli huo.

Kanuni ya kutosheleza (fit rule) ni fomula ileile kwa kiwango kidogo: idadi ya parameters mara baiti kwa kila uzito (bytes per weight), pamoja na KV cache, na takriban 2 GB ya runtime overhead, lazima viingie ndani ya VRAM yako. Katika 4-bit, hii ni takriban nusu baiti kwa kila parameter, jambo linalotoa uwiano mzuri:

• Kadi ya 16 GB: modeli ya 7B katika 4-bit ikiwa na nafasi ya kutosha kwa context ndefu
• Kadi ya 24 GB: modeli ya 14B katika 4-bit
• Kadi ya 48 GB: modeli ya 32B katika 4-bit
• Kadi ya 80 GB: modeli ya 70B katika 4-bit, au modeli ya daraja la 30B ya MoE katika 8-bit

Kila uwiano hapo juu unadhani ombi moja kwa wakati mmoja, na pindi mtu wa pili anapotuma prompt, kila slot inayofanya kazi kwa wakati mmoja inahitaji KV cache yake yenyewe, ambayo ndiyo biashara ambayo mipangilio ya NUM_PARALLEL na MAX_QUEUE ya Ollama inakufanyia kati ya slots zinazofanya kazi sambamba, maombi yaliyopangwa kwenye foleni, na VRAM uliyobaki nayo.

Ollama ndiyo njia ya haraka zaidi ya kupata seva inayofanya kazi kwenye VPS yenye GPU iliyounganishwa:

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

ollama run hupakua modeli wakati wa matumizi ya kwanza, kisha inakuweka kwenye prompt. Tag isiyokuwepo inarejesha Error: model "..." not found, kwa hivyo nakili tag kutoka ukurasa wa library badala ya kuziandika kwa kukumbuka. Mwongozo kamili, ikijumuisha systemd unit na ufikiaji wa mbali, uko kwenye kuendesha Ollama kwenye VPS.

llama.cpp inakupa udhibiti zaidi juu ya quantisation na 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 huomba kila layer iwekwe kwenye GPU. Soma log ya upakiaji: inachapisha ni layers ngapi zilizohamishiwa (offloaded). Layers zinazomwagika kwenye system RAM hufanya kazi kwa kutumia bandwidth ya RAM badala ya bandwidth ya HBM, kwa hivyo kasi ya uzalishaji (generation speed) hushuka kwa kiasi kikubwa pindi tu modeli inapoacha kutoshea. Biashara kati ya zana hizi mbili imeelezwa katika Ollama na llama.cpp kulinganisha.

Tier 3: API inayohudumiwa, orchestration inayojiendesha mwenyewe

[
  {
    "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 hii inaoana na OpenAI, kwa hivyo mteja aliyepo tayari atafanya kazi baada ya kubadilisha 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."}]}'

Key inayofanya kazi inarudisha JSON object yenye array ya choices. 401 inamaanisha key si sahihi au prefix ya Bearer haipo. Hitilafu ya model-not-found kwa kawaida inamaanisha id imebadilika, kwa sababu watoa huduma hustaafisha id kati ya checkpoints.

Sasa kuhusu gharama za usawa, tukitumia kiwango cha ukodishaji kilichotajwa hapo juu. Node ya GPU 8 inayowaka muda wote inagharimu 14,400 USD kwa mwezi, na kwa 15.00 USD kwa kila milioni ya output tokens, kiasi hicho cha pesa hununua takriban milioni 960 za output tokens kutoka kwenye API. Ili kupata faida ya gharama lazima utoe karibu bilioni moja ya output tokens kwa mwezi, takriban milioni 30 kwa siku, na uweke cluster ikifanya kazi muda wote, kwa sababu GPU zisizofanya kazi hutoza gharama sawa na zile zinazofanya kazi. Mizigo ya kazi ya mawakala inayotumia prompt nyingi husogeza mstari huo mbali zaidi: context inayorudiwa hutoza kwa kiwango cha cache-hit cha 0.30 USD kwa kila milioni badala ya kiwango cha cache-miss cha 3.00 USD.

Unachojiendeshea mwenyewe katika tier hii ni kila kitu kinachozunguka model: gateway inayoshikilia API key ili isiwahi kufika kwa mteja, logi za maombi na majibu, majaribio ya kurudia (retries), vikomo vya kasi (rate limits), na bajeti kwa kila mtumiaji. Hiyo huendeshwa kwenye VPS ndogo isiyo na GPU yoyote. Mgawanyo huo huo unatumika kwa closed weights, ambapo kujiendeshea Claude mwenyewe hakuwezekani katika kiwango cha model na orchestration ndiyo sehemu pekee unayomiliki.

Ni stack ipi ya kuhudumia inayomilikiwa na tier ipi

Seva za daraja la vLLM na SGLang ni za tier 1. Zipo ili kuhudumia maombi mengi kwa wakati mmoja, zikitumia continuous batching na paged KV cache, pamoja na tensor na expert parallelism iliyosambazwa kwenye nodes kadhaa. Zinahitaji accelerators za datacentre na muunganisho wa kasi kati yao. Kwenye kadi moja ya kawaida (consumer card), ni nzito kusakinisha na hazikupi faida yoyote unayoweza kuiona.

llama.cpp na Ollama ni za tier 2. Zinalenga mashine moja, GGUF quantisation, CPU offload wakati model haitoshi kwenye VRAM, na concurrency ya chini. Kiufundi, llama.cpp itapakia MoE kubwa sana kwa kuweka layers nyingi kwenye system RAM, na kwa model ya 2.8T, kasi hiyo hupimwa kwa sekunde kwa kila token. Hii inathibitisha kuwa faili inasomeka. Hii si huduma unayoweza kuwapa watumiaji. Ulinganisho kamili uko katika Ollama dhidi ya vLLM, na haubadiliki kulingana na model: swali ni kila mara kama unahudumia watumiaji wengi kwenye maunzi (hardware) ya pamoja au mtumiaji mmoja kwenye mashine yako mwenyewe.

Nambari nne zinazodumu zaidi ya hatua hii ya ukaguzi

1. Jumla ya vigezo (parameters) ikizidishwa na baiti kwa kila uzito (weight) hutoa kiwango cha chini cha kumbukumbu. Hakuna kinachoweza kufanya kazi chini ya kiwango hicho, na hakuna mbinu ya quantisation inayoweza kukipunguza kwa kiasi kikubwa mara tu toleo linapokuwa tayari katika 4-bit.
2. Vigezo amilifu (active parameters) hutoa daraja la uwezo wa kuchakata (throughput). MoE ya 2.8T yenye 104B amilifu hufanya kazi kama modeli ya 104B.
3. KV cache kwa kila token, ikizidishwa na urefu wa muktadha (context length), ikizidishwa na concurrency, ndiyo gharama inayoendelea kukua baada ya kulipia uzito wa modeli.
4. Idadi ya token kwa sekunde kwa kila dola ndiyo nambari pekee inayochagua daraja la huduma. Kila kitu kilichotajwa hapo juu ni ingizo la nambari hiyo.

Tumia nambari hizo nne kwa toleo lolote na utapata jibu sahihi kabla ya kufungua mwongozo wa muuzaji. Kisha weka tarehe kwenye kila takwimu unayoandika. Bei na orodha za usanifu (architecture) zinazoungwa mkono zote zilibadilika ndani ya wiki mbili baada ya K3 kuzinduliwa, na kila nambari kwenye ukurasa huu ni ile iliyochapishwa mnamo Julai 2026.

FAQ

Je, ninaweza kuendesha Kimi K3 kwenye GPU moja?

Hapana. Uzito wa modeli ni takriban 1.4 TB kwa usahihi wa MXFP4 ambao Moonshot inatoa, na accelerator kubwa zaidi inayouzwa ina 288 GB. Modeli ya MoE haiwezi kusoma experts wasiotumika kutoka kwenye diski kwa kasi inayofaa, kwa sababu router inaweza kuchagua expert yeyote kwa token yoyote na ucheleweshaji wa PCIe ni mkubwa kuliko muda unaoruhusiwa kwa kila token. Usanidi mdogo zaidi wa Kimi K3 unaofaa ni node yenye GPU nyingi, na miongozo iliyochapishwa hutumia accelerator 32 au zaidi.

Kimi K3 inahitaji VRAM kiasi gani?

Anza na 1.4 TB kwa ajili ya uzito pekee, ambayo ni sawa na kadi 18 za H100 80GB au kadi 5 za daraja la GB300. Kisha ongeza kumbukumbu ya KV cache na activation memory juu yake. Kufikia Agosti 2026, Moonshot inapendekeza accelerator 64 au zaidi, na kitabu cha maelekezo cha SGLang kinapendekeza usanidi wa GPU 32 za H100 zenye jumla ya 2,560 GB, kwa hivyo chukulia takwimu ya uzito kama kiwango cha chini kabisa badala ya mahitaji kamili.

Je, quantisation inafanya Kimi K3 kutoshea kwenye node moja?

Haitoshi kwa matumizi ya kawaida. Checkpoint iliyotolewa tayari iko katika 4-bit na imefanyiwa mafunzo ya quantisation-aware, kwa hivyo akiba rahisi ya kumbukumbu imeshachukuliwa. Kupunguza hadi 2-bit kunafanya uzito uwe 0.7 TB, ambayo bado ni zaidi ya mara mbili ya uwezo wa kadi kubwa zaidi, na gharama ya usahihi wa 2-bit haijapimwa kwenye modeli hii.

Je, kukodisha GPU ni nafuu kuliko kutumia API ya Kimi K3?

Ni nafuu tu ikiwa una matumizi makubwa na ya kudumu. Kwa makadirio ya 2.50 USD kwa saa kwa kila GPU, node ya GPU 8 inayowaka muda wote inagharimu 14,400 USD kwa mwezi, na kiasi hicho cha pesa kinaweza kununua takriban token milioni 960 kwa bei iliyochapishwa ya 15.00 USD kwa kila milioni. Pia unalipia saa ambazo mfumo haufanyi kazi, upakuaji wa uzito wa modeli, na gharama ya mtu anayesimamia cluster hiyo. Kodisha kwa saa kwa ajili ya kazi za muda mfupi, na ulinganishe na kiasi chako cha token unachopima badala ya kukisia.

104B active parameters inamaanisha nini kwa kasi?

Inamaanisha kuwa hesabu kwa kila token ni sawa na ile ya modeli ya 104B, kwa hivyo throughput inafanana na daraja hilo badala ya daraja la 2.8T. Hii haisemi chochote kuhusu kumbukumbu: parameters zote 2.8T lazima zibaki kwenye kumbukumbu, kwa sababu router inaweza kuita expert yeyote kwa token yoyote. Tumia idadi ya active parameters kukadiria token kwa sekunde, na idadi ya jumla kupima ukubwa wa VRAM.