Menjalankan Kimi K3 di RAM 29GB pada 0,50 tok/s

 (github.com/sqliteai)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • WASTE adalah engine inferensi berbasis C yang mengonversi model open-weight Kimi K3 lengkap dengan 2,78 triliun parameter, tanpa pengecilan, menjadi kontainer 982GiB dan menjalankannya di laptop konsumen
  • Hanya trunk residen model yang disimpan di memori, sementara sekitar 4% bobot expert yang aktif tiap token dibaca dari NVMe, dan sisa RAM digunakan sebagai cache expert berukuran terbatas
  • Kimi K3 dapat dibuka dengan RAM minimum 29,05GB pada konteks 4K, tetapi konfigurasi praktisnya adalah anggaran 46GB pada MacBook Pro 64GB, yang mencatat 0,45~0,62 tok/s
  • Dengan menumpangtindihkan pembacaan expert dan komputasi, performa meningkat sekitar 1,6×; dengan menjalankan router layer berikutnya satu residual lebih awal, hit rate cache naik dari 14% menjadi 38%, tanpa mengubah total jumlah baca maupun logit
  • Model sangat besar dapat dijalankan secara lokal tanpa koneksi internet, biaya per token, atau pengiriman data eksternal, tetapi membutuhkan NVMe internal dan sekitar 1TB ruang penyimpanan; jika anggaran RAM 52GB atau lebih, paging sistem operasi justru dapat membuatnya melambat tajam

Tujuan dan bentuk implementasi WASTE

  • WASTE(Weight-Aware Streaming Tensor Engine) adalah engine inferensi C yang dapat di-embed tanpa dependensi eksternal saat runtime
    • Hanya menggunakan libwaste.a dan executable waste, serta tidak memerlukan BLAS, CUDA, ONNX, atau Python selain libc dan pthreads
    • Python hanya digunakan untuk konversi model dan validasi terhadap baseline PyTorch, tidak masuk ke jalur inferensi
    • API publik terdiri dari 26 fungsi dan mendukung pembukaan model, penetapan batas atas RAM, generasi, penyimpanan sesi, dan penghentian
  • Target validasi saat ini adalah model penuh Kimi K3 2.78T
    • Sumber publiknya berukuran 1,42TB, dan setelah dikonversi kontainernya menjadi 982GiB
    • Ini bukan versi hasil distilasi, pruning, atau pengecilan
    • Kimi-Linear 48B juga mencatat kontainer 19GiB, RAM minimum 1,87GB, dan 10,7 tok/s dengan engine dan format yang sama
  • Nama proyek ini berasal dari tujuan mengurangi situasi ketika model yang bisa dijalankan di perangkat keras di atas meja justru dijalankan di pusat data cloud sambil mengonsumsi biaya token dan daya sekaligus

Struktur streaming disk

  • Karena K3 berarsitektur Mixture of Experts dan hanya sekitar 4% model yang aktif per token, bobot yang tidak aktif tidak perlu tetap berada di RAM dan diatur agar dapat diakses saat dibutuhkan
  • Kontainer .waste terdiri dari manifes JSON, trunk residen, dan bank expert per layer
    • Setiap record expert disejajarkan ke 4KiB
    • Matriks gate, up, dan down ditempatkan berdekatan sehingga satu expert dibaca tepat dengan satu kali pread
    • Page cache dilewati dengan F_NOCACHE di macOS, O_DIRECT di Linux, dan FILE_FLAG_NO_BUFFERING di Windows
  • Jika page cache tidak dilewati, kontainer uji yang lebih kecil daripada RAM dapat masuk ke cache sistem operasi dan menghasilkan hit rate yang tidak akan tereproduksi pada model 982GiB
  • Saat membaca record, magic, ID expert, dan rentang offset selalu diperiksa agar bank yang terpotong atau salah digabung tidak menjawab dengan bobot yang keliru
    • Pemeriksaan crc32 pada payload diaktifkan dengan --verify
    • Biaya verifikasi sekitar 5% pada Kimi-Linear dan sekitar 1% pada K3, dan secara default dimatikan
    • Disarankan memverifikasi sekali kontainer yang telah disalin, diunduh, atau ditempatkan pada disk yang tidak tepercaya
    • Trunk dan codebook tidak memiliki checksum

Prefetch baca dan prediksi router

  • Ketika router suatu layer menentukan 16 ID expert, tiap pembacaan diminta pada thread terpisah, dan komputasi mengonsumsi data yang tiba lebih dulu
    • Tumpang tindih baca dan komputasi meningkatkan K3 sekitar 1,6×
    • Pekerjaan yang dilakukan dan statistik cache sama sebelum dan sesudah fitur diaktifkan
  • Sebelum hidden state aktual layer berikutnya dibuat, router berikutnya yang residen dijalankan pada hidden state saat ini untuk mengambil 6 expert lebih awal
    • Prediksi satu residual lebih awal akurat 92% pada rank 1 dan 81% pada 6 teratas
    • Output tetap persis karena router aktual menentukan expert final
    • Demand hit rate naik dari 14% menjadi 38% dan total byte baca tidak berubah
    • Dapat dinonaktifkan dengan WASTE_LOOKAHEAD=0
  • Implementasi yang menerapkan teknik yang sama pada prefill telah dihapus
    • Layer decode menempati 16 slot cache, tetapi layer chunk menempati sekitar 550
    • Record yang dibaca lebih awal terdepak sebelum digunakan, sehingga jumlah baca naik 6,9% dan waktu tidak berkurang

Kuantisasi dan akurasi

  • Bobot expert disimpan dengan kuantisasi vektor residual 3 tahap, menggunakan codebook 256 entri untuk vektor berdimensi 8, dan memakai 3,00 bit per bobot
    • Alih-alih merekonstruksi seluruh matriks, dibuat tabel inner product parsial lalu setiap baris diproses dengan 3 lookup tabel dan 2 penjumlahan
  • Trunk mempertahankan 4-bit dan 8-bit
    • Karena model dilatih dengan kesadaran kuantisasi hanya untuk expert, output runtuh pada trunk 3-bit
    • Prediksi cache memang benar, tetapi throughput juga tidak membaik sehingga dihapus
  • Semua layer dibandingkan dengan implementasi baseline PyTorch
    • Selisih logit akhir adalah 3.6e-06
    • Vision tower dibandingkan dengan baseline internal pada 2.3e-06
    • Transformasi cache latent KV mempertahankan logit yang sama pada tingkat 1.2e-05

Anggaran RAM dan rentang performa yang sempit

  • K3 menggunakan 16 expert pada masing-masing dari 92 layer, membentuk working set 17,0GB per token
    • Jika cache lebih kecil dari ukuran ini, expert yang disimpan pada satu token terdepak sebelum token berikutnya sehingga hit rate menjadi 0%
  • Hasil pengukuran pada sistem 64GB menunjukkan bahwa mengalokasikan RAM lebih besar tidak selalu membuatnya lebih cepat
    • Anggaran 32GB, cache 3,32GB: hit rate 0%, 0,50 tok/s
    • Anggaran 46GB, cache 17,32GB: hit rate lama 17%, 0,53~0,55 tok/s
    • Anggaran 52GB, cache 23,32GB: tidak tereproduksi pada 0,04~0,15 tok/s
    • Anggaran 58GB, cache 29,32GB: 0,02~0,03 tok/s
  • Lookahead router menaikkan hit rate dari sekitar 14% menjadi 38% pada 46GB, tetapi kehancuran performa pada 52GB atau lebih disebabkan paging sistem operasi, bukan cache miss
    • Pada 58GB, meski hit rate lebih tinggi, kecepatannya sekitar 20× lebih lambat daripada 46GB
    • Setelah sistem dipaksa masuk kondisi paging dengan anggaran besar, pengukuran 46GB pun dapat turun hingga 0,02 tok/s
  • Anggaran default dipilih di bawah 7/8 RAM fisik, diturunkan dalam satuan working set token
    • Pada MacBook Pro 64GB, digunakan 46,24GB dan 17,56GB dialokasikan untuk cache expert
    • Jika anggaran yang ditentukan lebih kecil dari minimum, proses menolak mulai alih-alih berjalan dengan swapping
    • Pada sistem 128GB, anggaran rekomendasi penuh yang setara trunk plus 3× working set dapat digunakan

Performa K3 dan kebutuhan perangkat keras

  • Sistem pengukuran adalah MacBook Pro M5 Pro 64GB dengan SSD internal
    • RAM minimum konteks 4K: 29,05GB
    • 32K: 30,54GB, 128K: 35,63GB, 1M: 83,21GB
    • Trunk residen: 27,28GB
    • Pemuatan model: 20 detik
    • Decode: 0,45~0,62 tok/s pada anggaran default
    • Prefill: chunked 0,47 tok/s, sekuensial 0,29 tok/s
  • Model dapat dibuka dengan minimum 29,05GB, tetapi sistem 32GB dapat mengalami paging parah, sehingga 64GB adalah spesifikasi rekomendasi praktis
  • Dalam kondisi cold, 17,0GB expert dibaca per token; pada hit rate lookahead 38%, yang dibaca adalah 10,5GB
  • SSD internal terukur 12,78GB/s, sedangkan enclosure USB eksternal 0,94GB/s
    • Karena satu token membaca 17GB expert, pemrosesan yang sama di penyimpanan eksternal membutuhkan sekitar 13 detik
    • Unduhan sumber dapat ditempatkan di disk eksternal, tetapi kontainer hasil konversi harus ditempatkan di NVMe internal
  • Diperlukan 982GiB untuk kontainer hasil konversi dan 1,42TB untuk staging shard sumber; ruang staging dapat dilepas setelah konversi

Attention dan pemrosesan multimodal

  • Attention K3 menggabungkan Kimi Delta Attention dan gated multi-head latent attention dengan rasio 3:1
    • KDA mempertahankan recurrent state berukuran tetap, bukan KV cache yang bertambah
    • MLA meng-cache latent lebar 512 tanpa memperluas key/value per head
  • Dengan menyerap kv_b_proj ke query dan output, cache konteks 4K berkurang dari 11,25GB menjadi 0,21GB
    • Ini adalah penurunan 53× dibanding sebelumnya
    • Pada 128K, layout diperluas membutuhkan 360GB, sedangkan layout latent membutuhkan 7,2GB
  • Jalur multimodal mendukung ViT 401M parameter, 27 layer, patch 14
    • Encoding gambar 1024 patch memerlukan 15,7 detik
    • Gambar 896×896 menempati 256 posisi sequence pada konfigurasi default
    • Karena embedding gambar juga melewati 92 layer MoE, sebagian besar biaya setara dengan text prefill, bukan vision tower
    • Jika max_patches di vision.json dikurangi setengah, jumlah posisi prompt juga berkurang setengah
  • Mendukung PNG, JPEG, GIF, BMP, TGA, PSD, dan gambar dapat digunakan pada run, chat, eval
    • Posisi gambar yang sudah dienkode selama percakapan tetap berada di attention state dan tidak dienkode ulang pada giliran berikutnya
    • Vision tower hanya dimuat saat ada gambar, menggunakan bobot 434MB dan total memori reservasi 1,12GB

Konversi, eksekusi, dan server

  • Build hanya memerlukan compiler C11 dan make
    • make check lulus 23 pemeriksaan dan melewati 11 dengan kontainer sintetis tanpa model sungguhan
    • Jika dua kontainer sungguhan tersedia, total pemeriksaannya 36
  • Konversi K3 menggunakan langsung 96 shard safetensors dari moonshotai/Kimi-K3 yang dipublikasikan
    • Dengan 3 proses, dibutuhkan sekitar 4,7 jam pada M5 Pro
    • Encoder PyTorch murni membutuhkan 23,7 jam
    • Proses dapat dilanjutkan per layer, sehingga saat terhenti hanya layer yang sedang diproses yang diulang
    • Downloader mendukung resume file parsial, exponential backoff dan jitter, pemeriksaan Content-Length, serta pencatatan status shard yang selesai
  • CLI menyediakan run, chat, eval, plan, dan lainnya; dengan --json, hasil eval, tokenize, plan, info, bench dapat dikeluarkan dalam bentuk yang dapat dibaca mesin
  • serve/ adalah server HTTP kompatibel OpenAI yang memanggil API C publik melalui ctypes
    • Menyediakan /v1/chat/completions, /v1/completions, /v1/models, /health
    • Menangani streaming, definisi dan hasil tool, typed call arguments, skema respons JSON, tool_choice, think channel, thinking_effort, dan gambar
    • Renderer prompt mem-porting encoding_k3.py dari rilis K3, dan jika direktori bobot tersedia, membandingkan 38 percakapan per segmen

Platform dan batasan saat ini

  • macOS arm64, Linux arm64, dan Linux x86_64 mencatat 23 pass dan 11 skip pada pengujian yang sama dan tidak bergantung model, serta lulus sanitizer dan 400 fuzz case
  • Windows x86_64 dikompilasi silang dengan MinGW-w64 dan telah memverifikasi kontainer sintetis, CLI, serta forward pass, tetapi belum dijalankan pada kontainer model sungguhan
    • MSVC dan Windows ARM64 tidak didukung
    • Bypass page cache di Windows hanya dikonfirmasi pada filesystem CI dan belum diverifikasi pada beban kontainer nyata yang lebih besar daripada RAM
  • SIMD x86 memilih AVX-512 atau AVX2 sesuai CPUID, tetapi jalur AVX-512 belum dijalankan pada CPU yang benar-benar mendukungnya
  • Backend Metal akurat, tetapi karena bentuk pekerjaan memunculkan matvec dependen kecil ratusan kali, performanya 22% lebih lambat daripada CPU sehingga dinonaktifkan secara default
  • API belum dibekukan, dan konversi otomatis format chat saat ini hanya mendukung K3
    • Kimi-Linear berjalan dalam mode raw tanpa menebak template
  • Alokasi bit non-seragam per expert tidak akan diperkenalkan
    • Nilai bit ketiga hanya berbeda hingga 1,15× antar expert dalam satu layer dan 1,01× antar layer, sehingga alokasi optimal tidak memberikan keuntungan
    • Alokasi berbasis routing frequency juga mengurangi ruang penyimpanan, tetapi hampir tidak mengurangi bottleneck I/O
  • Lisensinya adalah Apache 2.0

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News

  • Sangat keren. Ini bukan proyek yang berusaha lebih praktis daripada penyedia cloud saat ini, melainkan proyek yang menunjukkan batas kemungkinan
    Jika peningkatan efisiensi model dan performa perangkat lokal saling bertemu, suatu hari model lokal berkualitas tinggi juga bisa dijalankan secara ekonomis

  • 0,5 token per detik menurut saya tidak berguna bahkan untuk tugas panjang. Saya lebih memilih mengeluarkan uang untuk dua 4060 Ti 16GB dan menerapkan paralelisme tensor
    Mungkin cocok 20 tahun lagi untuk robot lambat bergaya cyberpunk yang berjalan dengan tenaga surya sambil memotong rumput atau membersihkan trotoar, atau robot di kebun yang nyaris hanya bisa mengikuti laju pertumbuhan bonsai lalu memangkas cabangnya

    • Saat ini memang nyaris tidak bisa dipakai, tetapi saya senang proyek seperti ini terus disempurnakan karena pada akhirnya bisa mencapai versi yang praktis

  • Katanya membayar biaya token lalu membiarkan penyedia inferensi menanggung tagihan listrik itu boros, tetapi saya tidak paham apa bedanya dengan membeli mentimun lalu petani yang membayar biaya air dan pupuknya. Semoga ini bukan logika yang baru dicocok-cocokkan setelah ada LLM
    Idenya sendiri menarik, dan saya ingin mencobanya dengan model yang lebih kecil. Jika menghasilkan 0,5 token per detik sambil membaca beberapa GB per detik dari SSD, itu masih terlalu besar untuk laptop konsumen biasa, tetapi justru bisa lebih praktis untuk model 250~500GiB

    • Kalau menanam tomat sendiri, Anda bisa mendapatkan tomat gratis. Mungkin tidak cukup untuk membuat BLT, tetapi karena bukan dari supermarket, setidaknya Anda sedikit menyelamatkan dunia /s

  • Jika diasumsikan penggunaan berkelanjutan 42W dan tarif listrik 20 sen per kWh, maka biayanya sekitar 5 dolar per 1 juta token, belum termasuk biaya lain seperti perangkat keras

    • Sebulan kira-kira 2,6 juta detik, dan pada 0,5 token per detik itu menghasilkan 1,3 juta token per bulan. Bahkan jika biaya tambahan diperhitungkan, menganggap biaya operasional perangkat bulanan setara dengan biaya per 1 juta token tampaknya masih cukup masuk akal
    • Saya penasaran bagaimana perhitungannya berubah jika memakai pembangkit listrik tenaga surya

  • llama.cpp standar juga bisa melakukan mmap pada GGUF, sehingga bagian yang tidak muat di memori tetap berada di disk, dan page cache kernel akan mempertahankan chunk residen yang sering dipakai. Saya penasaran apa keuntungan membuat implementasi sendiri

    • Pertanyaan yang sama juga muncul pada proyek serupa beberapa hari lalu, dan katanya setelah mencoba mmap terlebih dahulu lalu membuat implementasi sendiri, hasilnya 10 kali lebih cepat
      Alasannya sama seperti mesin basis data yang mengimplementasikan cache sendiri. Paging kernel bersifat umum dan berbasis permintaan, tetapi jika pola akses aktualnya diketahui, data yang diperlukan bisa dibaca lebih dulu dan dipipeline-kan
    • Pada skala seperti ini, jika SSD dipakai sebagai ruang swap, daya tahan tulis kumulatif bisa habis hanya dalam beberapa bulan. Saya ingin melihat statistik total write dan keausan di SMART setelah dijalankan lebih dari sekadar uji jangka pendek
      Untuk model yang seluruhnya muat di RAM, saya merasa lebih baik menjalankan llama-server dengan --no-mmap. Tentu saja, untuk memuat seluruh Kimi K3 dan konteks 1 juta token, dibutuhkan server 2TB

  • README-nya sangat terasa seperti tulisan LLM, jadi saya penasaran apakah codebase-nya juga ditulis oleh LLM

    • Saya tidak ingin meremehkannya secara dangkal, tetapi dokumentasinya kontradiktif sendiri soal apakah model benar-benar dijalankan pada presisi asli. Kuantisasi 3-bit yang diklaim mungkin menarik, tetapi K3 sendiri memiliki sekitar 115GB parameter dense pada presisi asli, ditambah sekitar 25GB expert sparse aktif per token serta KV cache, jadi klaim 2 detik per token dengan RAM 29GB sulit dipahami
    • Saya telah banyak menulis perangkat lunak sendiri dan bahkan membuat bahasa pemrograman: https://github.com/marcobambini/gravity
      Sekarang saya memakai keahlian saya untuk mengorkestrasi LLM dan agen agar bisa menulis kode yang lebih baik jauh lebih cepat. Pengembang harus memilih antara beradaptasi dengan teknologi baru atau tersingkir
    • Saya berharap para penulis setidaknya membaca sendiri README yang dihasilkan LLM. LLM kurang memahami sudut pandang pembaca, sehingga mengasumsikan pembaca luar juga mengetahui seluruh konteks proyek dan proses pengambilan keputusan
      Keputusan internal yang penting bagi pengguna tetapi tidak relevan bagi pembaca yang melihat hasil akhirnya, serta istilah-istilah rumit khas Claude, masuk begitu saja. Saya akui saya juga sering memakai LLM dan itu sangat berguna untuk menulis kode kompleks, tetapi kualitas draf tulisannya sangat buruk
    • Ada claude di daftar kontributor, jadi bahkan tidak perlu menebak. Jika sampai commit pun diserahkan ke Claude, kemungkinan kode itu ditinjau langsung juga tampak rendah
    • Di README, gaya khas Claude terasa paling kuat. Seperti kita mengenali gaya tulisan tiap orang, sekarang rasanya gaya pendek, terputus-putus, dan terlalu berirama yang sering dihasilkan Claude secara default juga sudah menempati kategori tersendiri di kepala saya

  • Nilainya bisa menjadi besar jika teknologinya berkembang sampai kita dapat memilih model yang tepat secara akurat untuk tugas yang dikerjakan. Kita bisa membayangkan masa depan di mana dalam proses pencarian otomatis, model besar dijalankan hanya sekitar 30 menit per hari dan di sisa waktunya memakai model kecil

    • Saya rasa masa depan seperti itu tidak akan datang. Bahkan waktu yang dibutuhkan pun baru diketahui setelah item backlog selesai, dan tanpa benar-benar menjalankannya, tidak ada cara untuk mengetahui kompleksitas tugas sebelumnya