Menjalankan Model 2.78 Triliun Parameter di Laptop 8GB: Bedah kimi-k3-in-c

Sebuah proyek baru di komunitas open-source yang membuat Anda berhenti dan melihat: kimi-k3-in-c — mesin inference Kimi K3 dalam C99 portabel, 176KB kode, tanpa BLAS, tanpa framework, tanpa GPU, menjalankan model 2.78 triliun parameter pada laptop 8GB biasa. Ini bukan jargon pemasaran: repositori membawa tangga validasi lengkap dan data pengukuran — peak RSS terukur 8.24GB, dan output byte-identical dari mesin 8GB hingga 224GB — hanya jam yang berubah.

Apa sebenarnya proyek ini

kimi-k3-in-c dimulai developer FareedKhan-dev di bawah Apache-2.0, kini versi 1.1.0. Satu kalimat ringkasnya: menulis ulang inference Kimi K3 dengan C portabel paling sederhana, dan menghasilkan hasil identik pada budget memori berapa pun.

Intinya: disk adalah gerbangnya, bukan komputer. Checkpoint butuh sekitar 1.7TB ruang kosong; RAM mulai 8GB; GCC 9+ atau Clang 10+ cukup untuk build. Artinya, satu mesin pengembangan biasa plus satu hard disk besar dapat menjalankannya — tanpa klaster GPU.

Empat keputusan rekayasa

Model 2.8T menuntut memori kelas TB. Proyek ini memampatkannya ke 8GB lewat empat keputusan:

Satu, expert tetap dalam bentuk paket 4-bit. Bobot routed experts 1.45TB tidak pernah seluruhnya residen; ia dikalikan langsung dari bentuk paket setengah byte. Ini berbeda dengan dekompresi-lalu-hitung, yang melipatgandakan kebutuhan memori.

Dua, KDA attention dengan memori yang tidak tumbuh. Attention konvensional tumbuh linear terhadap konteks dan meledak di konteks panjang. KDA (attention berstatus) menjaga attention state pada ukuran tetap, sehingga overhead memori konteks panjang nyaris nol.

Tiga, MLA: satu latent menggantikan 96 head. KV cache adalah pemakan memori terbesar; MLA memampatkan KV multi-head menjadi satu representasi latent, memangkas cache secara signifikan.

Empat, trunk stream plus LRU expert cache. Trunk padat 93 lapis dibaca dari disk sesuai kebutuhan (satu pembacaan per lapis), dan bobot expert berada di balik cache LRU. Lebih banyak memori berarti lebih banyak trunk residen; lebih sedikit memori berarti lebih banyak pembacaan disk.

Tangga latency terukur

Pengukuran yang dipublikasikan (mesin sama: 124 core, NVMe cepat; prompt pendek sama):

Dua run batch nyata dari README:

# Laptop 8GB
$ ./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

# Workstation 128GB+
$ ./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

Yang penting bukan kecepatan absolut melainkan bentuk kurvanya: lebih banyak memori lebih cepat, jawaban tidak berubah. Versi 1.1.0 membuat komputasi per token sekitar delapan kali lebih ringan dari 1.0.0, pertanyaan lanjutan di chat 3.9× lebih cepat, prompt panjang setengah lebih murah — proyek ini masih dioptimasi cepat.

Verifikasi satu menit — tanpa checkpoint

Pilihan desain paling instruktif di sini: verifikasi butuh sekitar satu menit dan tidak memerlukan bobot model.

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

make -j        # kompilasi: hitungan detik
make test      # seluruh suite: di bawah satu menit

Output mencetak tiga gate — teacher forcing 32/32, greedy decode 20/20, incremental decode (KV cache + KDA state yang dibawa) 20/20 — ditutup VERDICT: ENGINE MATCHES THE REFERENCE EXACTLY. Tanpa checkpoint Anda tetap memverifikasi setiap kernel, streaming cache, pembaca safetensors, pembaca config, dan tokenizer terhadap referensi PyTorch yang di-commit di repositori.

Dengan kata lain: Anda dapat memastikan mesin layak dipercaya sebelum menghabiskan ribuan dolar untuk storage. Itu rekayasa open-source yang matang, dan tepatnya praktik yang perlu disorot lini konten ecosystem.

Jalan menuju teks nyata

Untuk menghasilkan teks Anda memerlukan checkpoint Kimi K3 resmi. Jalurnya: clone repo → jalankan ./scripts/k3-doctor.sh (cek toolchain, cocokkan RAM ke preset, ukur storage, cetak perintah berikutnya persis) → unduh checkpoint (1.56TB) → paket trunk → jalankan.

• --preset memilih budget: laptop (8GB ke atas) hingga server (workstation memori besar), plus preset ultra yang lebih baru
• Mode interaktif: proyek menyediakan chat REPL (XTML) untuk percakapan multi-giliran
• Pelacakan expert cache: python3 tools/sim_cache.py tests/fixtures/expert_trace.bin memutar ulang trace 100,096 permintaan expert untuk mereproduksi tabel kapasitas cache — tanpa checkpoint

Apa arti proyek ini bagi developer

Jika Anda membangun inference engine atau optimasi sistem: ini referensi implementasi nyaris setingkat buku teks — dari membaca header safetensors, parsing config, tokenizer byte-for-byte, sampai varian attention dan routing MoE. README Part II membangun setiap komponen dari nol, jauh lebih konkret daripada membaca paper.

Jika ingin memahami mengapa MoE "hemat compute tapi tidak hemat memori": proyek menjawabnya lewat tindakan. Bobot expert harus ada di suatu tempat (di sini: disk), tetapi setiap token mengaktifkan sebagian saja, jadi compute terbatas. Rasio cache hit menentukan I/O disk — itulah sebabnya mesin 128GB turun dari 26 detik ke 5,6 detik per token.

Jika ingin merasakan K3 murah: terus terang, 26 detik/token bukan pengalaman chat. Nilai proyek ada pada pembelajaran, eksperimen offline, dan pertanyaan rekayasa memasukkan model raksasa ke mesin kecil. Untuk percakapan nyata, cloud API lebih tepat — kimi-k3 milik EXAIV melayani model sama dengan latency hitungan detik.

Membaca angka proyek secara adil

Setiap angka performa di artikel ini berasal dari dokumentasi repositori sendiri di docs/data/ — yaitu pengukuran yang dipublikasikan proyek, bukan benchmark independen. Pembedaan ini penting saat menilai mesin apa pun:

• Keterbukaan hardware: pengukuran diambil pada satu mesin (124 core, NVMe cepat); disk lebih lambat membuat baris terikat-disk lebih lambat, yang juga dicatat proyek
• Mana yang terverifikasi, mana yang terukur: klaim kebenaran dapat diverifikasi siapa pun — clone, build, jalankan suite tanpa bobot terhadap oracle PyTorch yang di-commit. Klaim latency bergantung hardware
• Yang dipercaya lebih dulu: sifat byte-identical bersifat arsitektural (jalur komputasi deterministik) sehingga berlaku lintas mesin; waktu absolut tidak

Ini sikap yang benar terhadap klaim performa open-source mana pun: reproduksi yang bisa direproduksi, baca sisanya dengan konteks hardware di tangan. Repositori memudahkannya dengan menyertakan output pengukuran mentah alih-alih ringkasan pemasaran.

Dua hal lagi yang layak dicatat sebelum Anda memutuskan ikut serta. Pertama, proyek ini membuktikan bahwa batas memori sering kali bukan batas kemampuan melainkan batas pilihan arsitektur: dengan memindahkan bobot ke disk dan hanya menyimpan working set kecil, model kelas TB menjadi dapat dijalankan pada perangkat yang secara nominal jauh di bawah spesifikasinya. Kedua, ia mengingatkan bahwa keterbukaan bukan hanya soal bobot — engine yang bisa dibaca, diuji, dan diaudit memberi nilai yang tidak bisa digantikan oleh layanan tertutup, betapa pun nyamannya layanan itu. Untuk tim yang bergantung pada satu pemasok, memiliki jalur alternatif yang terverifikasi adalah bentuk ketahanan tersendiri.

FAQ

Artikel ini menjawab apa

• K3 berjalan di laptop 8GB
• cara kerja CPU inference di sini
• cara disk streaming diimplementasikan

Peta skenario cepat

Pandang ke depan

Katalog dan bobot terus berubah; konvensi integrasi dan pemanggilan di sini mengikuti dokumen resmi saat publikasi.

Sumber dan verifikasi

Fakta kunci dalam artikel ini berasal dari README proyek kimi-k3-in-c dan checkpoint Kimi K3 dan diverifikasi pada 2026-11-09. ID model, harga, dan ketersediaan mengikuti katalog langsung platform — sengaja tidak menulis angka tetap yang cepat usang. Contoh kode mengikuti kontrak API saat publikasi; periksa dokumen resmi sebelum menghubungkan ke produksi.

Ruang lingkup dan audiens

Audiens: developer yang mempelajari inference engine dan deployment lokal. Cakupan: keputusan rekayasa dan data terukur dari proyek. Tidak mencakup: nasihat tuning performa atau deployment komersial.

Catatan editorial dan koreksi

Ditulis oleh tim konten EXAIV dari fakta yang dapat diverifikasi, dengan sumber dan kode diperiksa sebelum publikasi. Jika ada yang usang atau keliru, halaman rilis resmi dan katalog langsung yang berlaku — beri tahu lewat kanal masukan halaman agar kami memperbaikinya.

Bacaan terkait

• Panduan Kimi K3
• Deploy Kimi K3 open-weight
• Perbandingan quantizer GGUF
• Playbook deployment lokal
• Model biaya komputasi lokal