KVSplit - Menjalankan konteks 2-3x lebih panjang di Apple Silicon

• KVSplit adalah proyek open-source yang memungkinkan menjalankan LLM besar dan jendela konteks panjang di Apple Silicon
• Melalui alokasi presisi terpisah untuk key dan value, proyek ini mencapai pengurangan memori hingga 72% dengan penurunan kualitas kurang dari 1%
• Dioptimalkan untuk chip M1/M2/M3 dan framework Metal
• Peningkatan kecepatan eksekusi serta penghematan memori dibuktikan melalui benchmark terukur dan alat visualisasi
• Menyediakan instalasi mudah, perbandingan satu perintah, serta berbagai alat benchmark dan analisis

---

Pengantar: Mengapa KVSplit penting

KVSplit adalah alat open-source yang memungkinkan menjalankan LLM berukuran besar dan jendela konteks yang jauh lebih panjang di lingkungan Apple Silicon (M1/M2/M3) dengan menerapkan kuantisasi dengan presisi berbeda pada key dan value di dalam KV cache. Proyek ini mengatasi keterbatasan pendekatan sebelumnya yang mengkuantisasi key dan value secara sama, serta secara drastis mengurangi penggunaan memori sambil menekan penurunan kualitas ke tingkat yang nyaris tidak terasa. Benchmark nyata, metrik kecepatan, dan kualitas semuanya dipublikasikan, sehingga dapat dipercaya, dan dukungan Metal bersama alat perbandingan dan visualisasi yang intuitif meningkatkan efisiensi pengembangan.

Keunggulan utama dibanding proyek sejenis adalah sebagai berikut:

• Pemisahan presisi key-value untuk manajemen memori yang lebih efisien
• Dikhususkan untuk Apple Silicon dan mendukung optimasi penuh framework Metal
• Menyediakan integrasi benchmark, perplexity, pengukuran memori/kecepatan/kualitas, dan visualisasi
• Instalasi satu perintah, kompatibilitas model, integrasi llama.cpp
• Visualisasi penghematan memori secara real-time dan berbagai alat uji perbandingan

Fitur utama dan poin inti

Gambaran umum

• Dengan KVSplit, kini dimungkinkan menjalankan LLM yang jauh lebih besar dan panjang konteks yang lebih besar di Apple Silicon
• Dengan memberikan presisi kuantisasi yang berbeda untuk key dan value, proyek ini mencapai penghematan memori sekaligus peningkatan kecepatan
• Terkonfirmasi penghematan memori hingga 72% dan peningkatan kecepatan (5-15%↑), dengan penurunan kualitas kurang dari 1%
• Dukungan penuh Metal, mewujudkan akselerasi optimal Apple Silicon

Hasil benchmark utama

• Pada konfigurasi K8V4 (key 8-bit, value 4-bit)
  • Penghematan memori 59% dan penurunan kualitas 0,86% (berdasarkan perplexity)
  • Peningkatan kecepatan 5,7% dibanding FP16
• Pada konfigurasi K4V4 (key/value sama-sama 4-bit)
  • Hingga 72% penghematan memori
  • Terjadi penurunan kualitas sekitar 6%. Direkomendasikan untuk penggunaan yang tidak terlalu sensitif terhadap kualitas

Perbandingan efek penghematan memori

• Berdasarkan FP16 176MB (8K token)
  • K8V8 (key/value 8-bit) : 93.5MB (47%)
  • K8V4 (key 8-bit, value 4-bit) : 71.5MB (41%)
  • K4V4 (key/value 4-bit) : 49.5MB (28%)

Fitur utama

• Fitur kuantisasi terpisah untuk key dan value pada KV cache
• Optimasi penuh untuk Apple Silicon dan Metal
• Skrip analisis benchmark/kualitas (perplexity)/penggunaan memori
• Alat visualisasi dan pembuatan grafik berkualitas publikasi
• Setup satu perintah dan fitur perbandingan real-time

Struktur folder proyek

• llama.cpp: termasuk build yang dioptimalkan untuk Metal
• models: menyimpan file model
• scripts: termasuk skrip benchmark/instalasi/perbandingan/visualisasi
• results, plots: menyimpan hasil benchmark dan file visualisasi
• README.md

Insight ilmiah dan hasil eksperimen

Fenomena inti pada KV cache

• Vektor key memiliki sensitivitas kuantisasi yang jauh lebih tinggi daripada vektor value → kualitas hanya bisa dipertahankan jika key diberi presisi lebih tinggi
• K8V4 adalah sweet spot: pembagian key 8-bit/value 4-bit adalah kompromi terbaik antara kualitas dan memori
  • Hemat memori 59%, perplexity hanya memburuk 0,86%, dan kecepatannya juga lebih cepat daripada FP16
• K4V8 meski memiliki jumlah bit yang sama dengan K8V4, menghasilkan penurunan kualitas lebih dari 7 kali lebih besar → membuktikan pentingnya presisi pada sisi key

Implikasi keseluruhan

• Berhasil mewujudkan efisiensi memori sekaligus menjaga kualitas model → memungkinkan menjalankan konteks yang jauh lebih panjang dan model yang lebih besar pada hardware konsumen

Contoh penggunaan dan rekomendasi pengaturan

Contoh menjalankan dengan berbagai presisi kuantisasi

• Dasar (FP16): ./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "prompt" -t 8 --flash-attn
• Rekomendasi K8V4: --kvq 8
• K4V8 (DEMO): --kvq-key 4 --kvq-val 8
• K4V4 (penghematan maksimum): --kvq 4

Contoh konteks panjang

• Konteks 32K: FP16 memerlukan ~1.4GB, tetapi K8V4 dapat dijalankan dengan ~400MB

Penjelasan flag command line

• -t 8: jumlah thread, disarankan 8 untuk M1/M2/M3
• --flash-attn: optimasi Apple Silicon
• --kvq N: menetapkan N-bit untuk key/value sekaligus
• --kvq-key, --kvq-val: mendukung pengaturan terpisah
• -c N: jumlah token konteks (semakin panjang, efek KVSplit semakin maksimal)
• -n N: jumlah token yang dihasilkan
• -f FILE: file input dokumen
• -m MODEL: path model

Benchmark lanjutan dan visualisasi

• Dengan benchmark_kvsplit.py, dapat mengukur karakteristik konfigurasi, panjang sekuens, memori/kecepatan/perplexity/skala
• Dengan visualize_results.py, dapat membuat grafik setingkat paper
• Hasil otomatis disimpan sebagai CSV/JSON dan ringkasan juga disediakan

Optimasi Apple Silicon dan visualisasi memori

• Memanfaatkan penuh framework Metal
• Sangat efektif untuk model M1/M2/M3 yang memiliki beban memori besar
• Dengan capture_memory.sh, penghematan memori dapat divisualisasikan secara real-time
• Karena penataan halaman yang disesuaikan, kapasitas penghematan aktual bisa sedikit berbeda dari nilai teoritis

Ringkasan fitur

• Presisi bit key/value independen dan kuantisasi yang dapat disesuaikan
• Apple Silicon dan Metal dengan optimasi penuh
• Menyediakan benchmark komprehensif untuk memori/kecepatan/kualitas
• Visualisasi berkualitas paper dan perbandingan real-time, dengan dukungan penangkapan memori
• Antarmuka instalasi/penggunaan yang sangat sederhana

Kutipan dan riset referensi

• "More for Keys, Less for Values: Adaptive KV Cache Quantization" (2024)
• "Unifying KV Cache Compression for Large Language Models with LeanKV" (2025)
• Implementasi dasar: [llama.cpp], model uji: [TinyLlama]

Rekomendasi pengaturan dan rencana ke depan

• K8V4 (key 8-bit/value 4-bit) : keseimbangan terbaik dengan kehilangan kualitas 0,86%, penghematan memori 59%, dan kecepatan +5,7%
• K4V4: penghematan memori maksimum (72%), kualitas turun sekitar 6%. Cocok untuk penggunaan yang memprioritaskan memori
• Sangat unggul untuk menjalankan konteks panjang, memungkinkan operasi konteks 2-3x lebih panjang

Roadmap ke depan

• Presisi adaptif berbasis tingkat pentingnya token
• Kuantisasi terpisah per layer
• Optimasi khusus per model (Mistral, Phi-3, dll.)
• Demo web dan dukungan mobile (iOS/iPadOS) direncanakan

Lisensi dan kontribusi

• Lisensi MIT
• Siapa pun, baik developer maupun peneliti AI, dapat berkontribusi melalui Issue dan PR

[GN⁺]

Komentar Hacker News

• Ungkapan ketertarikan karena terasa menarik, pertanyaan tentang intuisi mengapa fenomena ini muncul dan bagaimana proses penemuannya, saran perbaikan agar lebih ramah pengguna seperti tahap penerapan patch di skrip instalasi yang belum tuntas dan penggunaan git submodule, serta usulan agar llama.cpp dipisahkan dari dependensi Python dengan mempertimbangkan beragam lingkungan Python

  • Tanggapan bahwa itu pertanyaan yang bagus, penjelasan bahwa perbedaan utamanya terkait dengan peran inti attention, penekanan bahwa key menentukan token mana yang perlu diperhatikan untuk membentuk pola attention sedangkan value hanya menyampaikan informasi yang diberikan, perbandingan bahwa jika kuantisasi vektor key terlalu agresif maka distorsi pada semua interaksi token menjadi besar sedangkan error pada vektor value hanya memengaruhi informasi token tersebut, analogi bahwa jika nomor rak perpustakaan (key) salah maka kita bisa mencari buku yang sepenuhnya keliru, informasi bahwa secara matematis key masuk ke softmax sehingga error kecil pun bisa sangat teramplifikasi sedangkan value berupa rata-rata linear sehingga error cenderung saling meniadakan, pengalaman pribadi bahwa penulis juga menemukan asimetri ini di paper dan ingin memverifikasi dampaknya pada Apple Silicon secara kuantitatif, serta janji untuk memperbaiki umpan balik instalasi dan dependensi Python
  • Menunjukkan bahwa patch itu pada praktiknya tidak diterapkan ke llama.cpp, bahwa kode parsing argumen sudah dipindahkan ke arg.cpp sehingga menjadi tidak bermakna, serta bahwa opsi kuantisasi K/V juga sudah ditambahkan ke llama.cpp sejak 2023, mempertanyakan alasan keberadaan patch tersebut dan berpendapat bahwa tampaknya itu hanya membuat argumen command line sedikit berbeda, serta memberi peringatan keras agar tidak sembarang menjalankan file install.sh dari repositori baru hanya untuk menerapkan file patch yang sesederhana ini

• Pertanyaan apakah patch ini juga mungkin diterapkan di MLX, dengan harapan karena MLX lebih cepat maka pendekatan ini dapat membantu pengguna Mac mendapatkan dukungan percakapan panjang pada kecepatan yang layak dipakai sehari-hari

  • Mungkin saja, tetapi penulis sedang mendalami MLX secara langsung, dan kesannya framework-nya sendiri dirancang dengan baik namun masih terasa belum matang karena minim contoh kode dan informasi benchmarking, bahkan secara pribadi justru binding Haskell terasa paling menarik, dengan pendapat bahwa sifat lazy evaluation mungkin cocok dan struktur graph kompilasi yang murni fungsional juga bisa selaras, serta harapan bahwa machine learning di Haskell akan menarik

• Pertanyaan apakah ada perbedaan nyata dibanding opsi --cache-type-k, --cache-type-v

  • Pendapat keras bahwa ini terlihat seperti upaya LLM untuk sekadar mengumpulkan GitHub stars dan sebenarnya tidak berbeda dari fitur yang sudah ada
  • Ingatan bahwa dukungan 4-bit mungkin belum ada di MLX/MPS atau bahkan 8-bit pun dulu kurang memadai, dan dukungan bf16 juga baru ditambahkan belakangan, sehingga pada masa lalu di GPU Apple pendekatan type_k/v mungkin hanya bisa sampai minimum 16-bit (f16/bf16); karena itu meski tidak tahu pasti bagian dalam llama.cpp, mungkin ini pendekatan yang agak berbeda
  • Persetujuan singkat bahwa dirinya juga penasaran dengan perbedaannya

• Setelah membaca kodenya, penulis komentar menilai patch itu tidak perlu, dan memastikan lewat tautan PR bahwa fitur tersebut sudah masuk ke llama.cpp sejak 2023; ada alasan untuk waspada karena pengguna diarahkan menjalankan install.sh dengan cara menerapkan patch alih-alih memakai repositori fork, serta ditunjukkan bahwa struktur repositorinya membingungkan karena berisi beberapa file patch, kode duplikat, dan penimpaan file patch; pada praktiknya hanya menambahkan opsi --kvq, padahal opsi kuantisasi K/V terpisah sudah ada; muncul kecurigaan bahwa penulis repositori tidak mungkin tidak tahu soal fitur yang sudah ada ini; tidak disarankan menjalankan skrip dari repositori dengan skrip rumit seperti itu; sekalipun postingan HN dan jumlah GitHub star-nya tinggi, isinya dianggap menyesatkan; kekhawatiran juga muncul karena penulis terus menghindari pertanyaan; sebagai tambahan, repositori dan skripnya dinilai campur aduk dengan basis kode llama.cpp lama dan tidak sesuai dengan struktur terbaru sehingga makin membingungkan

  • Menyebut bahwa dirinya juga melihat banyak hal yang mencurigakan, tetapi sempat menunggu penjelasan penulis kalau-kalau ada sesuatu yang terlewat; namun karena ada banyak tanda bahaya dan riwayat aktivitas GitHub-nya terlihat seperti membanjiri proyek populer dengan kode hasil LLM, muncul kecurigaan akan niat semacam itu
  • Pendapat bahwa akhirnya ada orang yang berbicara masuk akal, dan fakta bahwa pendekatan ini tidak berupa penerapan patch melainkan seharusnya fork dari proyek asli saja sudah merupakan risiko kepercayaan; keberadaan GitHub si penulis sendiri juga terasa mencurigakan, dengan kecenderungan mengirim banyak PR berjejak LLM ke proyek populer untuk menyamar sebagai kontributor, serta kekhawatiran bahwa ini adalah awal dari polusi informasi atau runtuhnya kepercayaan akibat AI

• Pertanyaan apakah kuantisasi KV diferensial (K8V4 dan sejenisnya) bisa diterapkan juga pada model format .gguf yang sudah dikonversi, dan apakah ada batasan pada jenis model atau pengaturan tokenizer

  • Keunggulan utama KVSplit justru bahwa ia bisa langsung dipakai pada model .gguf yang sudah ada tanpa konversi khusus, karena kuantisasi hanya diterapkan pada KV cache saat runtime dan tidak terkait dengan bobot model; cukup menentukan format penyimpanan memori dengan flag --kvq-key dan --kvq-val; penulis mengaku berhasil menguji pada berbagai model seperti LLama-3, Mistral, Phi-2/Phi-3, TinyLlama, dan Qwen; namun ini khusus untuk backend Metal di llama.cpp, dan karena Flash Attention saat ini melewati format KV cache kustom maka opsi -fa 0 diperlukan; selain itu, selama arsitekturnya transformer berbasis attention maka seharusnya semuanya bisa diterapkan

• Pertanyaan apakah patch ini lebih cepat atau lebih baik pada Apple Silicon berkapasitas besar seperti 64GB atau 128GB, dengan menyebut adanya rumor bahwa perluasan context window di Apple Silicon sebenarnya lambat, dan ingin tahu apakah ini bermakna secara praktis untuk memori besar

  • Efek penghematan memori KVSplit berbanding lurus dengan panjang konteks sehingga pada Mac berkapasitas besar keuntungan absolutnya makin besar; pada Mac Studio 128GB bahkan bisa menangani konteks ratusan ribu token; namun ini tidak secara mendasar mempercepat komputasi dan hanya meningkatkan efisiensi memori; dalam benchmark, konfigurasi K8V4 menunjukkan peningkatan throughput 14,5%, tetapi itu lebih karena efisiensi akses memori; masalah "kecepatan lambat" pada model besar terutama berasal dari batas performa komputasi sehingga tidak terkait dengan ada tidaknya optimasi RAM atau KV cache; jadi KVSplit berguna ketika yang terasa adalah batas memori, dan dalam penggunaan nyata lebih ideal mengalokasikan context window yang lebih besar pada model kecil seperti 7B~13B; jika membutuhkan model besar plus context window sangat panjang sekaligus, GPU kelas server tetap lebih cocok, tetapi pendekatan ini tetap berarti karena memperluas batas yang bisa dicapai perangkat Apple

• Ketertarikan dan permintaan penjelasan dari sudut pandang yang sedikit lebih tinggi, pertanyaan apakah model 2048 token bisa dipakai untuk diperluas ke 4~6k dan model konteks 128k bisa dipakai untuk jendela 256k+, serta pertanyaan tentang use case ideal model lokal

  • Pada konfigurasi K8V4, penghematan memori bisa mencapai 59% sehingga panjang konteks maksimum dapat meningkat hingga 2,4 kali; artinya model 2048 token bisa diperluas menjadi sekitar 5000 token, dan model 8K menjadi sekitar 19,5K; dalam praktiknya ini bisa dipakai di MacBook untuk memproses satu buku penuh sekaligus, menganalisis codebase besar, atau mempertahankan riwayat percakapan panjang di aplikasi interaktif; efek penghematan memori meningkat secara linear mengikuti panjang konteks; berdasarkan pengalaman penulis, pada konteks 8K KV cache turun dari 176MB menjadi 72MB, dan pada 128k penghematannya menjadi berskala gigabita; ini paling efektif ketika OOM terjadi karena batas panjang input
  • Karena efek penghematan memori menurunkan kebutuhan resource model tertentu, ini bisa dimanfaatkan dengan berbagai cara sesuai tujuan; namun memperbesar context window itu sendiri tidak mudah bagi nonspesialis sehingga lebih baik memakai model yang memang dilatih untuk jendela lebih besar; model lokal bisa digunakan untuk tujuan offline/keamanan/eksperimen, dan bagi kebanyakan orang utamanya untuk eksperimen tuning model

• Pujian bahwa ini ide dan percobaan yang sangat bagus, serta pertanyaan lanjutan apakah ini juga bisa diterapkan ke GPU dan bisa digabungkan dengan teknik kuantisasi lain

  • Pendekatan ini kemungkinan dapat diterapkan sama pada GPU NVIDIA/AMD juga, karena prinsip bahwa key membutuhkan presisi lebih tinggi daripada value tidak bergantung pada hardware; backend CUDA di llama.cpp juga sudah mendukung pengaturan terpisah melalui opsi --cache-type-k, --cache-type-v; patch saat ini memang khusus untuk Metal, tetapi prinsipnya bisa dipindahkan apa adanya; ini juga dapat dipakai bersamaan dengan teknik kuantisasi lain, dan karena kuantisasi KV cache hanya diterapkan saat runtime maka tidak berbenturan dengan kuantisasi bobot; keduanya adalah tahap terpisah dalam pipeline konversi; namun untuk engine seperti vLLM atau TensorRT-LLM yang memakai struktur cache berbeda, implementasi terpisah akan diperlukan; efek terbesar di GPU kemungkinan muncul jika diintegrasikan langsung ke struktur FlashAttention, karena penghematan memori bisa langsung berubah menjadi peningkatan kecepatan

• Menyatakan ada bagian yang tidak benar-benar dipahami dan terasa janggal, menyarankan agar tidak menjalankan skrip tersebut, serta memberi tahu bahwa sudah melaporkannya

• Pertanyaan bagaimana perubahan performanya, apakah meski konteks yang lebih panjang bisa dimuat ke memori pada akhirnya kecepatan komputasi tetap sama

  • Kesan pribadi bahwa pada model dan prompt yang sama, ketika tipe cache diubah ke fp16, q8, q4, kecepatan iterasi terasa mirip; meski tidak memeriksa cara kerja internalnya, semula berharap vektor akan dipacking lewat pemrosesan batch SIMD 4~8 bit, tetapi kesannya ternyata tidak demikian