Pagpapatakbo ng 2.78 Trilyong Parameter sa 8GB Laptop: Pagbubukas sa kimi-k3-in-c

Isang proyekto sa open-source community ang nagpapatigil at tumingin: kimi-k3-in-c — isang Kimi K3 inference engine na isinulat sa portable C99, 176KB ng code, walang BLAS, walang framework, walang GPU, na nagpapatakbo ng 2.78 trilyong parameter na modelo sa karaniwang 8GB laptop. Hindi ito marketing copy: may buong validation ladder at measurement data ang repository — ang sinusukat na peak RSS ay 8.24GB, at ang output ay byte-identical mula 8GB hanggang 224GB na makina — ang orasan lamang ang nagbabago.

Ano ba talaga ang proyektong ito

Sinimulan ni developer FareedKhan-dev ang kimi-k3-in-c sa ilalim ng Apache-2.0, kasalukuyang bersyon 1.1.0. Sa isang pangungusap: isinusulat nitong muli ang Kimi K3 inference bilang pinakasimpleng portable C, at nagbubunga ng magkaparehong resulta sa anumang budget ng memory.

Ang mahalaga: ang disk ang gate, hindi ang computer. Humigit-kumulang 1.7TB libreng storage ang kailangan ng checkpoint; nagsisimula sa 8GB ang RAM; sapat na ang GCC 9+ o Clang 10+ para mag-build. Sa madaling salita, isang ordinaryong dev machine kasama ang isang malaking drive — walang GPU cluster.

Apat na desisyong inhinyeriya

Ang 2.8T-parameter na modelo ay humihingi ng terabyte-class na memory. Pinipiga ito ng proyekto sa 8GB gamit ang apat na desisyon:

Isa, nananatiling naka-pack sa 4-bit ang mga expert. Ang 1.45TB ng routed expert weights ay hindi kailanman buong nareresidente; direktang minu-multiply ito mula sa kalahating-byte na packed form. Iba ito sa decompress-then-compute na nagpaparami nang ilang beses sa memory.

Dalawa, KDA attention na hindi lumalaki ang memory. Lumalaki nang linear ang conventional attention sa context, kaya sumasabog ito sa mahabang context. Pinananatili ng KDA (stateful attention) ang attention state sa fixed na laki, kaya halos zero ang dagdag-memory ng mahabang context.

Tatlo, MLA: isang latent sa halip na 96 na head. Ang KV cache ang pinakamalaking kumakain ng memory; kino-compress ng MLA ang per-head KV sa iisang latent representation, malaki ang nababawas sa cache.

Apat, streamed trunk plus LRU expert cache. Ang 93-layer dense trunk ay binabasa mula sa disk on demand (isang basa bawat layer), at ang expert weights ay nasa likod ng LRU cache. Mas maraming memory, mas maraming trunk ang nananatili; mas kaunti, mas maraming disk read.

Sinusukat na latency ladder

Mga nai-publish na measurement (parehong makina: 124 core, mabilis na NVMe; parehong maikling prompt):

Dalawang totoong batch run mula sa README:

# 8GB laptop
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
         --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental
8 tokens in 261.5 s, 32.69 s/token average
PEAK RSS for the whole run: 8.24 GB

# 128GB+ workstation
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset server \
         --tok ~/k3model --prompt "def fibonacci(n):" --gen 28 --incremental
28 tokens in 299.3 s, 10.69 s/token average
PEAK RSS for the whole run: 127.92 GB

Ang punto ay hindi ang absolute na bilis kundi ang hugis ng curve: mas maraming memory, mas mabilis, at hindi nagbabago ang sagot. Ginawa ng 1.1.0 ang math bawat token na humigit-kumulang walong beses na mas magaan kaysa 1.0.0, 3.9× na mas mabilis ang follow-up na tanong sa chat, at kalahati ang gastos ng mahabang prompt — mabilis pa ring ino-optimize ang proyekto.

Isang-minutong pag-verify — walang checkpoint

Ang pinaka-instruktibong desisyon dito: ang pag-verify ay tumatagal nang humigit-kumulang isang minuto at hindi nangangailangan ng model weights.

git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

make -j        # compile: ilang segundo
make test      # buong suite: mas mababa sa isang minuto

Nagpi-print ang output ng tatlong gate — teacher forcing 32/32, greedy decode 20/20, incremental decode (KV cache + dala-dalahang KDA state) 20/20 — na nagtatapos sa VERDICT: ENGINE MATCHES THE REFERENCE EXACTLY. Kahit walang checkpoint, na-ve-verify mo ang bawat kernel, streaming cache, safetensors reader, config reader, at tokenizer laban sa naka-commit na PyTorch reference sa repository.

Sa ibang salita: makukumpirma mong mapagkakatiwalaan ang engine bago gumastos ng libu-libong dolyar sa storage. Ito ay mature na open-source engineering, at eksaktong praktikang dapat i-highlight ng ecosystem content lane.

Ang daan patungo sa aktwal na teksto

Para makabuo ng teksto kailangan mo ang opisyal na Kimi K3 checkpoint. Ang landas: i-clone ang repo → patakbuhin ang ./scripts/k3-doctor.sh (suriin ang toolchain, i-size ang RAM sa preset, sukatin ang storage, i-print ang eksaktong susunod na command) → i-download ang checkpoint (1.56TB) → i-pack ang trunk → patakbuhin.

• --preset ang pumipili ng budget: laptop (8GB pataas) hanggang server (malalaking-memory workstation), plus ang mas bagong ultra preset
• Interactive mode: may chat REPL (XTML) ang proyekto para sa multi-turn na usapan
• Expert-cache tracing: python3 tools/sim_cache.py tests/fixtures/expert_trace.bin ay nagre-replay ng na-record na trace ng 100,096 expert request para muling likhain ang cache-capacity table — walang checkpoint

Ano ang ibig sabihin nito para sa mga developer

Kung gumagawa ka ng inference engine o systems optimization: halos textbook-grade na reference implementation ito — mula pagbasa ng safetensors headers, config parsing, byte-for-byte na tokenizer, hanggang sa attention variant at MoE routing. Binubuo ng Part II ng README ang bawat bahagi mula sa simula, mas konkreto kaysa magbasa ng papel.

Kung gusto mong maunawaan kung bakit "nakakatipid ng compute pero hindi ng memory" ang MoE: sinasagot ito ng proyekto sa pamamagitan ng konstruksyon. Kailangang mayroon ang expert weights sa isang lugar (dito, disk), ngunit iisang subset lamang ang ina-activate bawat token, kaya nananatiling hangganan ang compute. Ang cache hit rate ang nagdidikta ng disk I/O — kaya bumaba ang 128GB machine mula 26 segundo sa 5.6 segundo bawat token.

Kung gusto mong maranasan ang K3 nang mura: sa totoo lang, ang 26 segundo/token ay hindi karanasang pang-chat. Ang halaga ng proyekto ay pag-aaral, offline na eksperimento, at ang tanong sa inhinyeriya kung paano ipasok ang higanteng modelo sa maliit na makina. Para sa tunay na usapan, mas angkop ang cloud API — ang kimi-k3 ng EXAIV ay nagse-serve ng parehong modelo sa segundo-escalang latency.

Pagbasa nang patas sa mga numero ng proyekto

Bawat performance figure sa artikulong ito ay mula sa sariling dokumentasyon ng repository sa ilalim ng docs/data/ — ibig sabihin, nai-publish na measurement ng proyekto, hindi independenteng benchmark. Mahalaga ang pagkakaibang ito kapag sinusuri ang anumang engine:

• Hardware disclosure: kinuha ang mga timing sa iisang makina (124 core, mabilis na NVMe); ang mas mabagal na drive ay nagpapabagal sa mga disk-bound na row, na mismo ring binabanggit ng proyekto
• Ano ang na-ve-verify vs. sinusukat: ang correctness claims ay ma-ve-verify ninuman — i-clone, i-build, patakbuhin ang weightless test suite laban sa naka-commit na PyTorch oracle. Ang latency claims ay nakadepende sa hardware
• Ano ang unang pagkatiwalaan: ang byte-identical na katangian ay nasa antas ng arkitektura (deterministic compute path) kaya tumatawid ito sa mga makina; ang absolute na timing ay hindi

Ito ang tamang tindig sa anumang open-source performance claim: i-reproduce ang kaya, basahin ang iba na bitbit ang konteksto ng hardware. Pinapadali ito ng repository sa pamamagitan ng pagpapadala ng raw measurement output sa halip na buod ng marketing.

FAQ

Ano ang sinasagot ng artikulong ito

• paano tumatakbo ang K3 sa 8GB laptop
• paano gumagana ang CPU inference dito
• paano ipinapatupad ang disk streaming

Mabilisang mapa ng senaryo

Tumingin sa hinaharap

Nagpapatuloy na nagbabago ang catalog at mga weights; ang mga integration at calling convention dito ay sumusunod sa opisyal na dokumento sa oras ng paglalathala.

Mga pinagmulan at beripikasyon

Ang mga pangunahing katotohanan sa artikulong ito ay mula sa README ng kimi-k3-in-c project at Kimi K3 checkpoint at na-verify noong 2026-11-09. Ang model ID, presyo at availability ay sumusunod sa live catalog ng platform — sinadyang walang nakapirming numerong mabilis mals. Ang mga sample code ay sumusunod sa API contract sa oras ng paglalathala; tingnan ang opisyal na dokumento bago ikonekta sa production.

Saklaw at audience

Audience: mga developer na nag-aaral ng inference engine at lokal na deployment. Saklaw: mga engineering trade-off at measured data ng proyekto. Hindi saklaw: payong sa performance tuning o komersyal na deployment.

Tala ng patnugot at pagwawasto

Isinulat ng EXAIV content team mula sa mga mapapatunayang katotohanan, na may sinusuri na mga pinagmulan at code bago ilathala. Kung may luma o mali, ang opisyal na release page at live catalog ang batayan — magbigay-alam sa feedback channel ng page para maayos namin ito.

Kaugnay na babasahin

• Gabay sa Kimi K3
• Pag-deploy ng Kimi K3 open-weight
• Paghahambing ng GGUF quantizer
• Local deployment playbook
• Local compute cost model