Jinsi ya ku-host Kimi K3 kwenye seva yako

Mahitaji ya ku-host Kimi K3 mwenyewe

Ku-host Kimi K3 mwenyewe kunamaanisha kutafuta nafasi ya vigezo (parameters) trilioni 2.8. Moonshot ilichapisha uzani (weights) wa wazi katika muundo wa MXFP4, ambao ni takriban nusu baiti kwa kila uzani, kwa hivyo uzani pekee unafikia takriban 1.4 TB kabla ya kutenga hata token moja ya cache. Hakuna kichapuzi (accelerator) kinachouzwa leo kinachoweza 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 inayothibitisha 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). Ukurasa huu unaanzia upande wa pili: gharama zake, nini unaweza kuendesha badala yake, na jinsi ya kutambua ni kundi lipi kati ya hayo mawili unalolihitaji.

Jumla ya vigezo na vigezo amilifu si idadi sawa

K3 ni modeli ya aina ya mixture of experts. MoE (mixture of experts) 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 kwa kila token, kutoka kwa experts 896 walioelekezwa ambapo 16 hufanya kazi kwa token yoyote ile, katika layers 93.

Idadi 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 vigezo takriban 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 awepo 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 experts kutoka NVMe hubadilisha 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 asili ya 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 activations za MXFP8, kwa hivyo safu ya 4-bit ndiyo halisi. 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 kizuizi cha uzito 32, jambo linaloongeza takriban asilimia 6, kwa hivyo hazina 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 hizo kama kiwango cha chini, si lengo. Namba hizo huhesabu uzito (weights) pekee: hazijumuishi KV cache, buffers za activation, fragmentation ya allocator, wala nafasi kwa ajili ya ombi la pili la 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 configuration ya H100 iliyojengwa kutoka nodes nne za 8-GPU, jumla ya GPU 32 na 2,560 GB ya kumbukumbu, ikilinganishwa na 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 hawakodishi kama SKU moja.

KV cache ndiyo sehemu inayowashangaza watu

Uzito (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 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), hivyo gharama halisi kwa kila token hushuka sana chini ya mfano uliotolewa. Moonshot haijachapisha vipimo vya latent, kwa hivyo sitaweka takwimu kwa 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.

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

Tier 1: kodi nguzo (cluster) kwa saa

Hii ndiyo tier pekee inayotumia K3 yenyewe. Hununui vifaa. Unavikodisha kwa saa unazohitaji na unavisitisha 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 hiki ni makadirio, si bei rasmi. Bei za soko za accelerators za vituo vya data zilikuwa kati ya 2 na 5 USD kwa saa kwa kila GPU hadi kufikia 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. 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 kadi ya modeli.

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 inayoweza kutumika kama ilivyo kwenye nguzo halisi. Ongeza flag za parallelism zinazolingana na vifaa vyako: 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.

Thibitisha seva imewaka kabla ya kutuma trafiki halisi:

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

Seva iliyo salama hujibu kwa JSON object inayoorodhesha kitambulisho cha modeli. Connection refused inamaanisha mchakato bado unapakia weights au umeshajifunga, kwa hivyo soma log ya seva kabla ya kujaribu tena.

Hitilafu ya kawaida siku ya kwanza ni runtime kuwa ya zamani kuliko modeli. K3 ilitoka ikiwa na KDA na safu mpya ya MoE ambayo matoleo thabiti (stable releases) ya vLLM na SGLang hayakuwa nayo wakati wa uzinduzi, na dalili yake ni seva kujifunga wakati wa kuanza ikiwa na mstari wa aina ya Model architectures [...] are not supported for now. Hakuna mabadiliko ya usanidi yanayoweza kurekebisha hilo, kwa sababu msimbo wa kuendesha safu hizo haupo kwenye build yako. Sakinisha toleo la nightly lililotajwa kwenye kadi ya modeli, au subiri toleo linalolijumuisha.

Ujumbe mmoja kuhusu gharama ambao huwashtua watu. Mita huanza kuhesabu wakati instance inapoanza, si wakati modeli inapokuwa tayari. Upakuaji wa 1.5 TB kwa kasi ya 1 GB/s huchukua takriban dakika 25 za muda wa nguzo kabla ya token ya kwanza. Hifadhi weights kwenye volume inayodumu zaidi ya instance, ili uanzishaji wa pili uwe wa dakika chache tu.

Tier 2: endesha modeli ndogo kwenye accelerator moja

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

Kanuni ya kutosheleza ni fomula ileile kwa kiwango kidogo: idadi ya parameters mara bytes kwa kila uzito (weight), pamoja na KV cache, na takriban 2 GB ya runtime overhead, lazima viwe ndani ya VRAM yako. Katika 4-bit, hii ni takriban nusu byte 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 30B ya aina ya MoE katika 8-bit

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 hukuweka kwenye prompt. Tag isiyokuwepo itarejesha Error: model "..." not found, kwa hivyo nakili tag kutoka kwenye 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: inaonyesha ni layers ngapi zimehamishiwa kwenye GPU (offloaded). Layers zinazozidi uwezo na kuingia kwenye system RAM hufanya kazi kwa kasi ya RAM badala ya kasi ya HBM, kwa hivyo kasi ya uzalishaji (generation speed) hupungua kwa kiasi kikubwa pindi tu modeli inapoacha kutoshea kwenye VRAM. Faida na hasara za zana hizi mbili zimefafanuliwa katika Ollama na llama.cpp kwa kulinganisha.

Ngazi ya 3: API inayohudumiwa, orchestration inayojiendesha

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

Ufunguo (key) unaofanya kazi hurejesha JSON object yenye array ya choices. 401 inamaanisha ufunguo 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 tuangalie sehemu ya usawa wa gharama, 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 hicho cha pesa hununua takriban milioni 960 za output tokens kutoka kwa 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 wakala (agent workloads) inayotumia prompt nyingi husogeza mstari huu mbali zaidi: muktadha unaorudiwa hutoza kwa kiwango cha cache-hit cha 0.30 USD kwa milioni badala ya kiwango cha cache-miss cha 3.00 USD.

Unachojiendeshea (self-host) katika ngazi hii ni kila kitu kinachozunguka modeli: gateway inayohifadhi API key ili isiwahi kufika kwa mteja, kumbukumbu za maombi na majibu (request and response logs), 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 self-hosting Claude haiwezekani katika ngazi ya modeli na orchestration ndiyo sehemu pekee unayomiliki.

Ni stack ipi ya kuhudumia inayohusika 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 kituo cha data na muunganisho wa kasi kati yao. Kwenye kadi moja ya mtumiaji wa kawaida, ni ngumu kusakinisha na hazikupi faida unayoweza kuiona.

llama.cpp na Ollama ni za tier 2. Zinalenga mashine moja, GGUF quantisation, CPU offload wakati model haitoshi, na concurrency ya chini. Kiufundi, llama.cpp itapakia MoE kubwa sana kwa kuhifadhi tabaka nyingi kwenye RAM ya mfumo, na kwa model ya 2.8T, njia hiyo huchukua 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 yaliyoshirikiwa au mtumiaji mmoja kwenye kifaa chako mwenyewe.

Nambari nne zinazodumu zaidi ya hatua hii ya ukaguzi

1. Jumla ya vigezo (parameters) ikizidishwa na baiti kwa kila uzito (weight) inatoa kiwango cha chini cha kumbukumbu kinachohitajika. Hakuna kinachoweza kufanya kazi chini ya kiwango hicho, na hakuna mbinu ya quantisation inayoweza kukipunguza kwa kiasi kikubwa mara tu toleo linapokuwa katika mfumo wa 4-bit.
2. Vigezo amilifu (active parameters) vinabainisha daraja la kasi ya uchakataji (throughput). Mfumo wa 2.8T MoE wenye 104B amilifu hufanya kazi kama modeli ya 104B.
3. KV cache kwa kila token, ikizidishwa na urefu wa muktadha (context length), ikizidishwa na idadi ya watumiaji kwa wakati mmoja (concurrency), ndiyo gharama inayozidi kuongezeka baada ya kulipia uzito wa modeli.
4. Idadi ya token kwa sekunde kwa kila dola ndiyo nambari pekee inayobainisha daraja la gharama. Mambo yote yaliyotajwa hapo juu ni vigezo vya kuipata nambari hii.

Tumia kanuni 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 hii ni takriban 1.4 TB katika usahihi wa MXFP4 ambao Moonshot hutoa, na kichapuzi (accelerator) kikubwa zaidi kinachouzwa kina 288 GB. Modeli ya MoE haiwezi kutiririsha wataalamu wake wasiofanya kazi kutoka kwenye diski kwa kasi inayofaa, kwa sababu router inaweza kuchagua mtaalamu yeyote kwa token yoyote na uletaji wa data kupitia PCIe huchukua muda mrefu zaidi kuliko muda uliotengwa kwa kila token. Usanidi mdogo zaidi wa Kimi K3 unaofaa ni node yenye GPU nyingi, na miongozo iliyochapishwa hutumia vichapuzi 32 au zaidi.

Kimi K3 inahitaji kiasi gani cha VRAM?

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 vichapuzi 64 au zaidi, na kitabu cha mapishi cha SGLang kinachapisha 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 hitaji la mwisho.

Je, quantisation inafanya Kimi K3 kutoshea kwenye node moja?

Si kwa njia inayofaa. Checkpoint iliyotolewa tayari ni ya 4-bit yenye mafunzo ya quantisation-aware, kwa hivyo akiba rahisi ya kumbukumbu imeshachukuliwa. Kupunguza zaidi hadi 2-bit kunaleta uzito kwenye 0.7 TB, ambayo bado ni zaidi ya mara mbili ya kadi kubwa zaidi, na gharama ya usahihi wa 2-bit haijapimwa kwenye modeli hii.

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

Ni nafuu tu kwa ujazo mkubwa na thabiti. 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 za matokeo kwa bei iliyochapishwa ya 15.00 USD kwa kila milioni. Pia unalipia saa za kutofanya kazi, upakuaji wa uzito, na mtu anayesimamia cluster hiyo ili iendelee kufanya kazi. Kodisha kwa saa kwa ajili ya matumizi ya muda mfupi, na ulinganishe na ujazo wako wa token uliopimwa badala ya kukisia.

Vigezo 104B vinavyofanya kazi (active parameters) vinamaanisha nini kwa kasi?

Inamaanisha kuwa hesabu kwa kila token ni ile ya modeli ya 104B, kwa hivyo throughput inafanana na daraja hilo badala ya daraja la 2.8T. Hii haisemi chochote kuhusu kumbukumbu: vigezo vyote 2.8T vinabaki kwenye kumbukumbu, kwa sababu router inaweza kuita mtaalamu yeyote kwa token yoyote. Tumia idadi ya vigezo vinavyofanya kazi kutabiri token kwa sekunde, na idadi ya jumla kupima ukubwa wa VRAM.