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

 (github.com/dipampaul17)
1 poin oleh GN⁺ 2025-05-18 | 1 komentar | Bagikan ke WhatsApp
  • KVSplit adalah proyek yang menargetkan konteks lebih panjang dan menjalankan model yang lebih besar dalam anggaran memori yang sama dengan menerapkan presisi kuantisasi berbeda untuk key dan value pada KV cache attention LLM di Apple Silicon
  • Hasil utamanya adalah konfigurasi K8V4, yang untuk 8K token menurunkan penggunaan memori dari 176.00MB pada FP16 menjadi 71.50MB, meningkatkan kecepatan pemrosesan token dari 54.360 tokens/sec menjadi 57.438 tokens/sec, dan menunjukkan perubahan perplexity sebesar +0.86%
  • Berdasarkan temuan bahwa key lebih sensitif terhadap kuantisasi dibanding value, proyek ini merangkum bahwa K4V8 yang memakai jumlah bit total yang sama mengalami penurunan kualitas sekitar 7x lebih besar dibanding K8V4
  • Fitur yang disediakan mencakup penerapan patch llama.cpp, build dengan dukungan Metal, benchmark memori/kecepatan/perplexity, penyimpanan hasil dalam CSV/JSON, alat visualisasi, dan pengambilan bukti penghematan memori berbasis Activity Monitor
  • Konfigurasi yang direkomendasikan adalah K8V4 untuk keseimbangan kualitas dan penghematan memori, sedangkan jika perlu penghematan maksimum tersedia opsi K4V4 dengan penghematan 72% dengan konsekuensi penurunan kualitas sekitar 6%

Masalah yang ingin diselesaikan KVSplit

  • KVSplit adalah proyek untuk mengurangi memori KV cache saat inferensi LLM di Mac berbasis Apple Silicon
  • Pada KV cache dari mekanisme attention, proyek ini menerapkan presisi kuantisasi yang berbeda untuk key dan value
  • Tujuannya adalah sebagai berikut
    • Mengurangi penggunaan memori hingga 72%
    • Menjalankan konteks 2-3x lebih panjang dalam anggaran memori yang sama
    • Mempertahankan atau meningkatkan kecepatan inferensi dibanding FP16
    • Menyediakan dukungan Metal yang disesuaikan untuk Apple Silicon

Hasil benchmark utama

  • Hasil tiap konfigurasi untuk 8K token adalah sebagai berikut
    • FP16: 176.00MB, 54.360 tokens/sec
    • K8V8: 93.50MB, 51.503 tokens/sec, perplexity +0.03%
    • K8V4: 71.50MB, 57.438 tokens/sec, perplexity +0.86%
    • K4V8: 71.50MB, 58.690 tokens/sec, perplexity +6.06%
    • K4V4: 49.50MB, 55.193 tokens/sec, perplexity +6.15%
  • Pada tabel penghematan memori, K8V4 ditunjukkan menghemat 59% pada 8K token, sedangkan K4V4 72%
  • Pada tabel performa, K8V4 menunjukkan peningkatan kecepatan +5.7% dibanding FP16, K4V8 +8.0%, dan K4V4 +1.5%
  • K8V8 memang mengurangi memori dibanding FP16, tetapi kecepatannya turun -5.3%

Penggunaan memori menurut panjang sekuens

  • Semakin panjang konteks, semakin besar efek penghematan memori dari KV cache
  • Penggunaan memori pada 8192 token adalah sebagai berikut
    • FP16: 176.00MB
    • K8V8: 93.50MB
    • K8V4: 71.50MB
    • K4V8: 71.50MB
    • K4V4: 49.50MB
  • Pada 4096 token, dibanding FP16 88.00MB, K8V4/K4V8 menggunakan 35.75MB dan K4V4 menggunakan 24.75MB
  • Pada 128 token, angkanya ditunjukkan sebagai FP16 5.50MB, K8V4/K4V8 2.23MB, dan K4V4 1.55MB

Asimetri key dan value

  • Memori KV cache didominasi oleh penyimpanan vektor key dan value untuk tiap token
  • Pengamatan inti proyek ini adalah bahwa key jauh lebih sensitif terhadap kuantisasi dibanding value
  • K8V4 menggunakan key 8-bit dan value 4-bit untuk memberikan titik keseimbangan berikut
    • Penurunan perplexity 0.86% dibanding FP16
    • Penghematan memori 59%
    • Kecepatan inferensi lebih cepat daripada FP16
  • K4V8 memakai jumlah bit total yang sama dengan K8V4, tetapi dirangkum mengalami penurunan kualitas sekitar 7x lebih besar daripada K8V4
  • Berkat asimetri ini, dijelaskan bahwa konteks lebih panjang dan model lebih besar dapat dijalankan pada consumer hardware

Instalasi dan cara integrasi

  • Instalasi dilakukan dengan clone repositori lalu menjalankan scripts/install_kvsplit.sh
git clone https://github.com/dipampaul17/KVSplit.git
cd kvsplit

chmod +x scripts/install_kvsplit.sh
./scripts/install_kvsplit.sh
  • Skrip instalasi memungkinkan pemilihan metode penyiapan lingkungan Python
    • Virtual Environment: membuat lingkungan Python terisolasi di dalam folder proyek
    • System Python: menggunakan instalasi Python yang sudah ada
    • Skip Python Setup: pengguna mengelola sendiri lingkungan Python
  • Cara integrasi dengan llama.cpp juga dapat dipilih
    • Cara standar: clone llama.cpp lalu menerapkan patch KV split
    • Cara Git submodule: menambahkan llama.cpp sebagai submodule untuk developer atau pengguna tingkat lanjut
  • Proses instalasi mencakup penyiapan llama.cpp dengan dukungan Metal untuk Apple Silicon, mengaktifkan differentiated KV cache quantization, unduhan opsional model uji, dan penyiapan alat visualisasi

Contoh penggunaan dan opsi CLI

  • Perbandingan cepat dapat dijalankan dengan model GGUF milik pengguna
python scripts/quick_compare.py --model models/your-model.gguf
  • Obyek perbandingan adalah FP16, K8V8, K8V4, K4V8, K4V4, dan hasilnya menampilkan metrik memori, kecepatan, serta kualitas
  • Contoh eksekusi di README menggunakan llama-cli bersama --flash-attn dan opsi kuantisasi KV
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq 8
  • Contoh K4V8 menetapkan bit key dan value secara terpisah
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq-key 4 --kvq-val 8
  • Contoh konteks 32K menunjukkan bahwa FP16 memerlukan sekitar 1.4GB, sedangkan K8V4 sekitar 400MB
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf \
  -c 32768 -n 4096 -t 8 --flash-attn --kvq 8 \
  -f your-long-document.txt
  • Flag CLI utama adalah sebagai berikut
    • -t 8: jumlah thread, 8 direkomendasikan untuk sebagian besar chip Apple Silicon
    • --flash-attn: mengaktifkan attention yang dioptimalkan, direkomendasikan di Apple Silicon
    • --kvq N: mengatur bit key dan value
    • --kvq-key N: hanya mengatur bit key
    • --kvq-val N: hanya mengatur bit value
    • -c N: ukuran konteks
    • -n N: jumlah token yang akan dihasilkan
    • -f FILE: file input
    • -m MODEL: path file model .gguf

Alat benchmark dan visualisasi

  • Benchmark penuh dijalankan dengan scripts/benchmark_kvsplit.py
python scripts/benchmark_kvsplit.py
python scripts/benchmark_kvsplit.py --config K8V4 --seq-len 4096
  • Visualisasi dibuat dengan scripts/visualize_results.py
python scripts/visualize_results.py
  • Benchmark mengukur hal-hal berikut
    • Memory Usage: VRAM dan memori KV cache
    • Performance: tokens/sec menurut panjang sekuens
    • Quality: perplexity menggunakan llama-perplexity
    • Scaling: perubahan memori dan performa menurut panjang sekuens
  • Hasil disimpan dalam format CSV/JSON serta menghasilkan statistik ringkasan dan plot visualisasi secara otomatis
  • capture_memory.sh adalah alat untuk menangkap penghematan memori dari Activity Monitor

Optimasi Apple Silicon dan keterbatasan

  • KVSplit dioptimalkan untuk framework Metal milik Apple
  • Proyek ini menekankan efisiensi memori pada perangkat dengan keterbatasan memori seperti Apple Silicon seri M
  • README menyebut bahwa karena 256B page alignment di llama.cpp, penghematan memori aktual bisa sedikit berbeda dari perhitungan teoretis
  • Dukungan mencakup chip M1, M2, M3, dan M4

Konfigurasi yang direkomendasikan dan roadmap

  • Konfigurasi yang direkomendasikan adalah K8V4
    • key 8-bit, value 4-bit
    • penghematan memori 59%
    • penurunan kualitas 0.86%
    • kecepatan inferensi +5.7% dibanding FP16
  • Penghematan memori maksimum adalah K4V4
    • key 4-bit dan value 4-bit
    • penghematan memori 72%
    • penurunan kualitas sekitar 6%
    • disajikan sebagai cocok untuk aplikasi yang kurang sensitif
  • Untuk konteks yang sangat panjang, K8V4 atau K4V4 direkomendasikan, dan semakin panjang konteks, semakin terakumulasi penghematan memorinya
  • Rencana ke depan adalah sebagai berikut
    • Adaptive Precision berbasis pentingnya token
    • Layer-Specific Quantization yang menggunakan presisi berbeda per layer
    • Optimasi per model untuk Mistral, Phi-3, dan lainnya
    • Demo web
    • Dukungan iOS dan iPadOS
  • Lisensinya adalah MIT, dan kontribusi dapat diajukan lewat issue atau pull request

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-18
Komentar Hacker News

  • Menarik. Saya penasaran apakah ada intuisi tentang mengapa hasil seperti ini muncul. Juga penasaran apakah ini ditemukan lewat intuisi itu, atau lewat eksperimen acak
    Pada tahap "apply patch" di skrip instalasi, sepertinya masih ada placeholder yang tertinggal. Daripada menerapkan patch setelah git clone, mungkin akan lebih ramah pengguna jika mem-fork llama.cpp lalu menyertakannya sebagai Git submodule
    Selain itu, karena setup Python lokal tiap orang berbeda-beda, akan bagus kalau bagian terkait llama.cpp dan bagian terkait Python bisa dipisahkan, alih-alih mematok dependensi Homebrew Python

    • Pertanyaan tentang intuisi itu bagus. Perbedaannya berasal dari peran inti yang dimainkan tiap komponen dalam attention
      Key menentukan token mana yang harus diperhatikan, dan membuat pola attention aktual melalui perhitungan kemiripan. Value hanya menyimpan informasi yang akan diteruskan setelah attention ditentukan
      Jika vektor key dikuantisasi terlalu agresif, perhitungan kemiripan untuk semua interaksi token akan terdistorsi. Kesalahan kecil pada key bisa mengalihkan attention ke token yang sama sekali keliru
      Value jauh lebih toleran. Kesalahan kuantisasi pada vektor value hanya memengaruhi isi informasi dari satu token tersebut setelah pola attention sudah ditetapkan
      Ini mirip perbedaan antara sistem katalog perpustakaan dan buku itu sendiri. Jika nomor katalog (key) rusak, Anda akan melihat rak yang sama sekali salah, tetapi jika beberapa kata dalam buku (value) menjadi kabur, Anda masih membaca buku yang benar dan hanya sesekali muncul noise
      Secara matematis, key masuk ke perhitungan softmax, sehingga kesalahan kecil diperkuat secara eksponensial dalam proses normalisasi. Value hanya melewati rata-rata berbobot linear, sehingga kesalahan cenderung saling meniadakan
      Awalnya saya menemukan asimetri ini di paper seperti "More for Keys, Less for Values" dan "KV-AdaQuant", lalu ingin mengukur seberapa besar dampaknya secara tepat pada inferensi Apple Silicon. Yang mengesankan adalah, pada memori yang sama, perbedaan kualitas antara K8V4 dan K4V8 mencapai 7x
      Terima kasih juga atas masukan soal instalasi; saya akan memperbaiki placeholder dan membuat dependensi Python lebih fleksibel
    • Patch itu sebenarnya tidak diterapkan ke llama.cpp. Alasannya, parsing argumen sudah dipindahkan ke arg.cpp 8 bulan lalu
      Namun itu tidak masalah, karena opsi untuk mengatur kuantisasi K dan V memang sudah ditambahkan ke llama.cpp pada 2023
      Saya tidak mengerti mengapa patch ini ada. Selain membuat konfigurasi yang sudah ada terlihat baru dengan mengubahnya menjadi argumen command-line lain, saya tidak tahu alasannya
      Saya sangat menyarankan agar tidak ada yang menjalankan file install.sh dari repositori baru seperti ini. Terutama ketika tidak diperlukan untuk hal sesederhana menerapkan satu file patch

  • Apakah ini berbeda dari memakai --cache-type-k dan --cache-type-v?

    • Tidak. Ini terlihat seperti upaya yang dibuat LLM untuk mendapatkan bintang GitHub
      Beberapa keanehan lain di repositori sudah saya tulis di komentar lain
    • Saya menduga sedikit berbeda. MLX/MPS tidak memiliki dukungan 4-bit native, dan kalau ingatan saya benar, mungkin juga tidak punya 8-bit. Saat pertama dirilis, dukungan bf16 pun belum ada
      Jadi dengan cara type_k/v lama, kemungkinan batas terendah yang bisa dicapai di GPU Apple adalah f16/bf16 16-bit. Namun saya bukan ahli internal llama.cpp, jadi bisa saja salah

  • Saya penasaran apakah patch ini juga bisa dilakukan di MLX. Di MLX kecepatannya lebih baik, jadi jika digabungkan dengan pendekatan ini, pengguna Mac mungkin bisa melakukan percakapan panjang dengan kecepatan yang layak

    • Kemungkinan bisa, tetapi saya sedang menggali bagian dalam MLX, dan meskipun ini framework yang dirancang dengan baik, saya menyadari tingkat kematangannya masih jauh lebih rendah untuk bisa sekadar mengambil contoh kode tempat seseorang sudah membenchmark "cara terbaik"
      Secara pribadi, hal yang paling saya nantikan—walau mungkin sulit dipercaya—adalah binding Haskell. Beberapa hari lalu seseorang menunjukkan bahwa lazy evaluation Haskell cukup cocok dengan paradigma ini, dan pendekatan yang hampir murni fungsional terhadap graph kompilasi juga membantu. Melakukan machine learning di Haskell sepertinya akan menyenangkan

  • Saya penasaran apakah kuantisasi KV diferensial (misalnya K8V4) bisa diterapkan pada model yang sudah dikonversi ke format .gguf. Atau apakah perlu membangun ulang model dengan dukungan khusus?
    Jika kompatibel dengan file .gguf apa pun, saya juga penasaran apakah ada batasan pada tipe model (Mistral, Phi-3, dan sebagainya) atau konfigurasi tokenizer

    • Bisa. Salah satu keunggulan utama KVSplit adalah bisa memakai model .gguf yang sudah ada apa adanya, tanpa rekonstruksi atau konversi khusus. Kuantisasi terjadi pada KV cache saat runtime, bukan saat pemuatan atau konversi model
      Ini dimungkinkan karena KV cache dibuat selama inferensi ketika token diproses, dan sepenuhnya terpisah dari bobot model. Flag --kvq-key dan --kvq-val hanya memberi tahu llama.cpp bagaimana menyimpan tensor perantara ini di memori
      Sudah berhasil diuji pada Llama-3, Mistral, Phi-2/Phi-3, TinyLlama, dan varian Qwen
      Satu-satunya batasan adalah perlu backend Metal llama.cpp, dan implementasi Flash Attention llama.cpp saat ini melewati format KV cache kustom, jadi Flash Attention harus dimatikan dengan -fa 0. Tekniknya sendiri seharusnya bekerja pada arsitektur transformer apa pun yang memakai mekanisme attention standar

  • Saya sempat punya waktu untuk membaca kodenya. Kalau saya memahami PR ini dengan benar, patch ini tidak diperlukan karena fitur ini sudah ada di llama.cpp sejak 2023: https://github.com/ggml-org/llama.cpp/pull/4312
    Alih-alih menyediakan fork llama.cpp yang menerapkan perubahan sebagai commit, repositori ini menyuruh menjalankan skrip install.sh. Skrip ini men-checkout branch master llama.cpp tanpa menentukan revisi, lalu menerapkan patch kecil. Itu saja sudah menjadi sinyal peringatan bahwa ada yang aneh
    Di repositori ada 4 file patch berbeda, dan di dalam skrip instalasi ada satu versi patch tambahan yang ditanam sebagai Heredoc. Di skripnya juga ada dua versi kode untuk meng-clone repositori dan mencoba menerapkan patch
    install.sh menimpa satu file patch dengan file patch lain lewat baris cp patch/split_kv_quant.diff patch/fixed_kv_patch.diff. Jadi fixed_kv_patch.diff yang di-check-in ke repositori akan ditimpa sebelum diterapkan
    Menurut saya, sepertinya patch yang awalnya ingin dipakai adalah ini: https://github.com/dipampaul17/KVSplit/blob/main/patch/split... (koreksi: melihat komentar di akhir, sepertinya sebenarnya yang ini: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... )
    Yang ditambahkan patch ini hanyalah argumen --kvq yang mengatur kuantisasi K dan V sekaligus, padahal tepat di atasnya sudah ada argumen bawaan untuk mengatur kuantisasi K dan V masing-masing. Mungkinkah penulis tidak menyadari bahwa fiturnya sudah ada saat memindah-mindahkan patch ini?
    Saya sangat menyarankan untuk tidak menjalankan skrip shell dari repositori baru seperti ini. Apalagi jika skripnya serumit ini
    Postingan HN sudah mendapat lebih dari 200 upvote dan repositori GitHub-nya juga terus bertambah hingga lebih dari 200 star, tetapi isinya tampak menyesatkan. Komentar yang mendapat banyak flag saat menyoroti masalah di thread ini ternyata benar. Juga mengkhawatirkan bahwa penulis terus membalas di thread ini tetapi menghindari pertanyaan soal fitur yang sudah ada
    Koreksi: saya salah membaca skrip shell-nya. Sepertinya yang sebenarnya diterapkan adalah patch ini: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... Setelah menerapkan patch, anehnya fixed_kv_patch.diff ditimpa dengan split_kv_quant.diff, tetapi setelah itu tidak melakukan apa-apa lagi. Entah ini hasil vibe coding atau sekadar penyuntingan kode yang ceroboh, tetapi saya ingin mengulangi bahwa skrip shell seperti ini dari repositori yang tidak dikenal tidak seharusnya dijalankan
    Koreksi 2: makin membingungkan. Skrip install.sh merujuk ke URL lama repositori llama.cpp (https://github.com/ggerganov/llama.cpp), yang sudah berubah beberapa waktu lalu dan sekarang dialihkan. Patch-nya mencoba mengubah parsing argumen di common.cpp, tetapi kode itu sudah dipindahkan ke arg.cpp 8 bulan lalu (https://github.com/ggml-org/llama.cpp/commit/bfe76d4a17228bf...). Jadi skrip instalasi dan repositori ini tampaknya berbasis kode sekitar 2024, sambil memakai opsi yang ditambahkan ke llama.cpp sekitar 2023. Sebenarnya apa yang terjadi?

    • Benar. Saya tidak menyebutkan bagian-bagian mencurigakan lainnya karena mungkin saja ada sesuatu yang saya lewatkan dan penulis bisa menjelaskannya di sini
      Ada banyak sinyal peringatan. Kalau dilihat secara paling baik pun, ini tampak seperti seseorang yang ingin menggembungkan profil GitHub dengan kode hasil LLM. Cukup lihat aktivitas profilnya pada 12 Mei
    • Akhirnya ada penjelasan yang masuk akal. Fakta bahwa proyek ini bekerja dengan menerapkan patch, bukan mem-fork proyek asli lalu meng-commit perubahannya, sudah cukup menjadi alasan untuk khawatir
      Namun seluruh aktivitas GitHub penulis postingan asli terlihat mencurigakan. Pada 12 Mei ia mengirim PR campur aduk LLM ke beberapa proyek populer, dan hanya JAX yang menolaknya. Meski begitu, lewat cara ini ia bisa menyematkan proyek-proyek populer di profilnya seolah-olah ia adalah kontributor
      Sulit diungkapkan dengan kata-kata betapa menjijikkannya ini. Siapa pun yang bekerja di bidang AI ikut berperan dalam pencemaran informasi, dan dampaknya bahkan belum bisa diprediksi. Internet mati dan banjir campur aduk AI baru permulaan

  • Pada Apple Silicon 64GB atau 128GB, apakah ini secara signifikan lebih cepat atau lebih baik dibanding 36GB atau 48GB?
    Saya pernah membaca bahwa konteks besar dan model besar tetap sangat lambat, bahkan di Apple Silicon tercepat dan terbesar yang bisa dibeli dengan uang
    Jadi saya penasaran apakah ini membuat memori yang lebih besar bisa dimanfaatkan dengan lebih baik, atau secara praktis model yang relatif kecil masih menjadi jawaban di Apple Silicon

    • Penghematan memori KVSplit meningkat sebanding dengan panjang konteks, jadi Mac dengan RAM besar seperti 64GB/128GB mendapat keuntungan lebih besar dalam nilai absolut. Dengan Mac Studio 128GB, secara potensial jendela konteks ratusan ribu token pun bisa ditangani
      Namun KVSplit tidak mengubah kecepatan komputasi secara mendasar, melainkan hanya mengubah efisiensi memori. Dalam benchmark, K8V4 meningkatkan throughput 14,5%, tetapi ini karena perbaikan lokalitas memori, bukan karena berkurangnya jumlah komputasi
      Alasan utama model besar terasa “sangat lambat” di Apple Silicon bukanlah batasan memori, melainkan batas kinerja komputasi. Model 70B parameter akan berjalan dengan kecepatan pembuatan token yang kurang lebih serupa, terlepas dari RAM yang tersedia atau optimasi cache KV
      KVSplit membuat memori yang tersedia digunakan lebih baik. Ini sangat bernilai ketika bottleneck-nya adalah panjang konteks, bukan ukuran model
      Untuk penggunaan Apple Silicon secara praktis, titik yang masuk akal masih model yang lebih kecil (7B~13B) dengan jendela konteks yang diperluas. Dengan begitu, jauh lebih banyak teks bisa diproses sambil tetap mempertahankan kecepatan pembuatan yang wajar
      Jika alur kerja membutuhkan konteks raksasa sekaligus model besar, GPU kelas server tetap perlu dipertimbangkan, tetapi KVSplit sedikit memperluas apa yang mungkin dilakukan di hardware Apple

  • Ini pekerjaan yang bagus dan terlihat sangat menarik, tetapi untuk memahaminya saya butuh sedikit lebih banyak penjelasan tingkat tinggi
    Misalnya, apakah ini memungkinkan model dengan jendela konteks 2048 token dijalankan dengan jendela konteks 4~6K? Atau memungkinkan model 128K seperti gemma3 dijalankan dengan jendela konteks 256K atau lebih?
    Apa use case ideal untuk model lokal?

    • Konfigurasi K8V4 menghemat memori 59%, jadi pada hardware yang sama pada dasarnya bisa menjalankan konteks 2,4 kali lebih panjang. Model dengan konteks 2048 token bisa memproses sekitar 5000 token, dan model konteks 8K bisa naik hingga sekitar 19,5K
      Secara praktis, ini berarti di MacBook Anda bisa memproses satu buku penuh sekaligus, menganalisis codebase besar tanpa memecah file, atau mempertahankan riwayat percakapan panjang di aplikasi chat
      Penghematan memori berbanding lurus dengan panjang konteks. Semakin panjang jendela konteks, semakin besar memori absolut yang dihemat. Di M4 MacBook saya, pada konteks 8K, cache KV berkurang dari 176MB menjadi 72MB. Pada konteks 128K, penghematan dengan rasio yang sama akan membebaskan memori dalam satuan gigabyte
      Optimasi ini paling bernilai ketika Anda terbentur batas jendela konteks, bukan batas parameter model. Jika error kehabisan memori terjadi karena input yang panjang, bukan bobot model yang besar, KVSplit mengatasi bottleneck langsungnya
    • Ini mengurangi penggunaan memori model tertentu. Bagaimana ruang kosong itu dipakai terserah pengguna
      Menaikkan jendela konteks setelah pelatihan tidaklah sederhana, jadi jika Anda tidak benar-benar tahu apa yang dilakukan, lebih baik mencari model yang memang dilatih dengan jendela konteks lebih besar
      Kegunaan model lokal beragam, seperti pekerjaan offline, privasi/keamanan, dan sebagainya. Namun kebanyakan orang memakainya untuk bereksperimen sambil menyesuaikan model

  • Ada sesuatu yang aneh terjadi, jadi sebaiknya jangan memasang ini atau menjalankan skrip itu
    Saya sudah menandai kiriman ini

  • Ide dan percobaan yang bagus. Apakah ini juga berlaku untuk GPU? Dan sepertinya kompatibel dengan teknik kuantisasi lain juga; apakah perlu dianggap bahwa masing-masing mungkin butuh patch terpisah?

    • Benar. Pendekatan ini kemungkinan besar juga bisa diterapkan di GPU NVIDIA/AMD. Prinsip dasarnya, bahwa key membutuhkan presisi lebih tinggi daripada value, tidak bergantung pada hardware
      Backend CUDA llama.cpp sudah mendukung pengaturan tipe cache terpisah lewat flag --cache-type-k dan --cache-type-v. Patch khusus ini berfokus pada optimasi khusus Metal, tetapi teknik intinya bisa dipindahkan apa adanya
      Ini juga kompatibel dengan metode kuantisasi lain. Optimasi cache KV ini saling melengkapi dengan kuantisasi bobot model (Q4_K_M, GPTQ, AWQ, dan sebagainya). Presisi cache KV asimetris bisa digunakan bersama format bobot model apa pun
      Kuantisasi cache KV terjadi saat runtime selama pemrosesan token dan terpisah dari bobot model, jadi tidak bertabrakan dengan bagaimana model itu sendiri dikuantisasi. Keduanya bekerja pada bagian berbeda dari pipeline inferensi
      Bagian yang membutuhkan pekerjaan tambahan adalah integrasi dengan engine inferensi khusus yang memiliki penanganan cache KV kustom, seperti vLLM atau TensorRT-LLM. Masing-masing perlu mengimplementasikan presisi KV asimetris secara terpisah
      Di GPU, keuntungan paling langsung mungkin datang dari mengintegrasikan insight ini langsung ke implementasi FlashAttention. Pada hardware CUDA, pengurangan bandwidth memori bisa menghasilkan peningkatan kecepatan yang lebih besar

  • Untuk ukuran konteks kecil, perplexity +0,86% bukankah itu cukup besar? Bagaimana pada ukuran konteks yang lebih realistis seperti 64~128K?

    • Intinya tampaknya ada pada pengurangan penggunaan memori. Ini memungkinkan menjalankan konteks yang lebih panjang yang sebelumnya tidak mungkin dalam batas memori yang sama
      Atau memori kosongnya juga bisa dipakai untuk keperluan lain seperti IDE