KVSplit - Apple Silicon'da 2-3 kat daha uzun bağlam çalıştırma

 (github.com/dipampaul17)
1 puan yazan GN⁺ 2025-05-18 | 1 yorum | WhatsApp'ta paylaş
  • KVSplit, Apple Silicon üzerinde büyük LLM'leri ve uzun bağlam pencerelerini çalıştırmayı mümkün kılan açık kaynaklı bir projedir
  • Anahtar ve değerler için ayrılmış hassasiyet ataması sayesinde %72'ye kadar bellek azalması ve %1'in altında kalite kaybı sağlar
  • M1/M2/M3 çipleri ve Metal framework'ü için optimize edilmiştir
  • Çalışma hızı iyileştirmeleri ile bellek tasarrufunu ölçülmüş benchmark'lar ve görselleştirme araçlarıyla kanıtlar
  • Kolay kurulum, tek komutla karşılaştırma ve çeşitli benchmark ile analiz araçları sunar

Giriş: KVSplit neden önemli

KVSplit, KV cache içindeki anahtar ve değerlere farklı hassasiyetlerde niceleme uygulayarak Apple Silicon (M1/M2/M3) ortamında büyük LLM'lerin ve çok daha uzun bağlam pencerelerinin çalıştırılmasını mümkün kılan açık kaynaklı bir araçtır. Mevcut projelerin anahtar ve değerleri aynı şekilde niceleme sınırlamasını aşar; bellek kullanımını çarpıcı biçimde azaltırken kalite kaybını da neredeyse fark edilmeyecek düzeyde tutar. Gerçek benchmark, hız ve kalite metriklerinin tamamı açıkça paylaşılmıştır, bu da projeyi güvenilir kılar; ayrıca Metal desteği ile sezgisel karşılaştırma ve görselleştirme araçları geliştirme verimliliğini artırır.

Benzer projelere kıyasla başlıca avantajları şunlardır:

  • Anahtar-değer hassasiyet ayrımı ile daha verimli bellek yönetimi
  • Apple Silicon'a özel ve tam Metal framework optimizasyonu desteği
  • Benchmark, perplexity, bellek/hız/kalite ölçümü ve görselleştirme araçlarının entegre sunulması
  • Tek komutla kurulum, model uyumluluğu, llama.cpp entegrasyonu
  • Gerçek zamanlı bellek tasarrufu görselleştirmesi ve çeşitli karşılaştırma test araçları

Öne çıkan özellikler ve temel içerik

Genel bakış

  • KVSplit ile Apple Silicon üzerinde eskisinden çok daha büyük LLM'ler ve daha uzun bağlam uzunlukları çalıştırılabilir
  • Anahtar ve değerler için farklı niceleme hassasiyetleri atayarak hem bellek tasarrufu hem de hız artışı elde edilir
  • %72'ye kadar bellek tasarrufu ve hız artışı (%5-15↑) sağlanırken kalite kaybının %1'in altında kaldığı doğrulanmıştır
  • Metal tam desteklenir ve Apple Silicon için en iyi hızlandırma etkisi sağlanır

Başlıca benchmark sonuçları

  • K8V4 (anahtar 8 bit, değer 4 bit) yapılandırmasında
    • %59 bellek tasarrufu ve %0,86 kalite kaybı (perplexity bazında)
    • FP16'ya kıyasla %5,7 hız artışı
  • K4V4 (anahtar/değer her ikisi de 4 bit) yapılandırmasında
    • En fazla %72 bellek tasarrufu
    • Yaklaşık %6 kalite kaybı oluşur. Kalite hassasiyetinin düşük olduğu kullanım senaryoları için önerilir

Bellek tasarrufu etkisi karşılaştırması

  • FP16 bazında 176MB'den (8K token)
    • K8V8 (8 bit anahtar/değer) : 93.5MB (%47)
    • K8V4 (8 bit anahtar, 4 bit değer) : 71.5MB (%41)
    • K4V4 (4 bit anahtar/değer) : 49.5MB (%28)

Temel işlevler

  • KV cache anahtar/değerlerini ayrı niceleme özelliği
  • Apple Silicon ve Metal için tam optimizasyon
  • Benchmark/kalite (perplexity)/bellek kullanımı analiz script'leri
  • Görselleştirme araçları ve yayın kalitesinde grafik üretimi
  • Tek komutla kurulum ve gerçek zamanlı karşılaştırma

Proje klasör yapısı

  • llama.cpp: Metal optimize derleme dahil
  • models: model dosyalarını saklar
  • scripts: benchmark/kurulum/karşılaştırma/görselleştirme script'lerini içerir
  • results, plots: benchmark sonuçları ve görselleştirme dosyalarını saklar
  • README.md

Bilimsel içgörüler ve deney sonuçları

KV cache'in temel olgusu

  • Anahtar vektörleri, nicelemeye değer vektörlerinden çok daha duyarlıdır → kaliteyi korumak için anahtarlara daha yüksek hassasiyet atanmalıdır
  • K8V4 tatlı nokta: anahtar 8 bit / değer 4 bit dağılımı, kalite-bellek dengesi açısından en iyi noktadır
    • %59 bellek tasarrufu, perplexity'de yalnızca %0,86 kötüleşme ve FP16'dan daha yüksek hız
  • K4V8, K8V4 ile aynı toplam bit sayısına sahip olsa da 7 kattan fazla daha büyük kalite kaybı üretir → anahtar tarafındaki hassasiyetin önemini kanıtlar

Genel çıkarımlar

  • Bellek verimliliği ile model kalitesinin korunması aynı anda başarılır → tüketici donanımında çok daha uzun bağlamlar ve daha büyük modeller çalıştırılabilir

Kullanım örnekleri ve yapılandırma önerileri

Farklı niceleme hassasiyetleriyle çalıştırma örnekleri

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

Uzun bağlam örneği

  • 32K bağlam: FP16 yaklaşık ~1.4GB gerektirirken K8V4 yaklaşık ~400MB ile çalışabilir

Komut satırı bayraklarının açıklaması

  • -t 8: thread sayısı, M1/M2/M3 için 8 önerilir
  • --flash-attn: Apple Silicon optimizasyonu
  • --kvq N: anahtar/değerlerin ikisini de N bit olarak ayarlar
  • --kvq-key, --kvq-val: ayrı ayar desteği
  • -c N: bağlam token sayısı (uzadıkça KVSplit etkisi maksimize olur)
  • -n N: üretilecek token sayısı
  • -f FILE: belge giriş dosyası
  • -m MODEL: model yolu

Gelişmiş benchmark ve görselleştirme

  • benchmark_kvsplit.py ile yapılandırmaya, sekans uzunluğuna, bellek/hız/perplexity/ölçek özelliklerine göre ölçüm yapılır
  • visualize_results.py ile makale düzeyinde grafikler üretilir
  • Sonuçlar CSV/JSON olarak otomatik kaydedilir ve özet sunulur

Apple Silicon optimizasyonu ve bellek görselleştirmesi

  • Metal framework'ü tam olarak kullanılır
  • Bellek yükü yüksek M1/M2/M3 cihazlarında kritik etki sağlar
  • capture_memory.sh ile gerçek zamanlı bellek tasarrufu görselleştirilebilir
  • Özel sayfa hizalaması nedeniyle gerçek tasarruf miktarı teorik değerden bir miktar farklı olabilir

Özet işlev listesi

  • Bağımsız anahtar/değer bit hassasiyeti ve özelleştirilebilir niceleme
  • Apple Silicon ve Metal için tam optimizasyon
  • Bellek/hız/kalite için kapsamlı benchmark sunumu
  • Makale kalitesinde görselleştirme ve gerçek zamanlı karşılaştırma, bellek yakalama desteği
  • Son derece kolay kurulum/kullanım arayüzü

Alıntılar ve ilgili araştırmalar

  • "More for Keys, Less for Values: Adaptive KV Cache Quantization" (2024)
  • "Unifying KV Cache Compression for Large Language Models with LeanKV" (2025)
  • Temel implementasyon: [llama.cpp], test modeli: [TinyLlama]

Yapılandırma önerileri ve gelecek planları

  • K8V4 (anahtar 8 bit / değer 4 bit) : %0,86 kalite kaybı, %59 bellek tasarrufu, +%5,7 hız ile en iyi denge
  • K4V4: maksimum bellek tasarrufu (%72), yaklaşık %6 kalite düşüşü. Belleğin en yüksek öncelik olduğu kullanım senaryolarına uygundur
  • Özellikle uzun bağlam çalıştırmada güçlüdür, 2-3 kat daha uzun bağlam kullanılabilir

Gelecek yol haritası

  • Token önemine dayalı uyarlamalı hassasiyet
  • Katman bazlı ayrı niceleme
  • Modele özel optimizasyonlar (Mistral, Phi-3 vb.)
  • Web demosu ve mobil (iOS/iPadOS) desteği planlanıyor

Lisans ve katkı bilgisi

  • MIT lisansı
  • Geliştiriciler ve yapay zeka araştırmacıları Issue ve PR ile katkıda bulunabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-18
Hacker News görüşleri

  • İlgi çekici bulduğunu belirten bir yorum; bunun neden ortaya çıktığına dair sezgi ve nasıl keşfedildiğine ilişkin sorular; kurulum betiğinde yama uygulama adımının tamamlanmamış olması ve git submodule kullanımı gibi kullanıcı dostu iyileştirme önerileri; ayrıca farklı Python ortamları düşünülerek llama.cpp ile Python bağımlılıklarının ayrılması gerektiği önerisi

    • Bunun iyi bir soru olduğuna dair yanıt; temel farkın attention’ın çekirdek rolüyle ilişkili olduğu açıklaması; key’lerin hangi token’lara dikkat edileceğini belirleyerek attention desenini oluşturduğu, value’ların ise yalnızca verilen bilgiyi taşıdığı vurgusu; key vektörlerinin fazla agresif kuantizasyonunda tüm token etkileşimlerinde bozulmanın büyüdüğü, buna karşılık value vektörlerindeki hatanın yalnızca ilgili token’ın bilgisini etkilediği karşılaştırması; kütüphane raf numarası (key) yanlışsa tamamen alakasız bir kitabın bulunacağı benzetmesi; matematiksel olarak da key’lerin softmax’e girdiği için küçük hataların büyük ölçüde büyütüldüğü, value’ların ise lineer ortalama olduğundan hataların dengelendiği bilgisi; kendisinin de makalede bu asimetriyi gördükten sonra Apple Silicon üzerindeki etkisini nicel olarak doğrulamaya çalıştığı deneyimi; kurulum geri bildirimi ve Python bağımlılıklarını iyileştirme sözü
    • Yamanın gerçekte llama.cppye uygulanmadığı, argüman ayrıştırma kodunun zaten arg.cppye taşındığı için anlamsız olduğu eleştirisi; K/V kuantizasyon seçeneğinin de 2023’te zaten llama.cppye eklendiği açıklaması; bu yamanın neden var olduğunun sorgulanması ve yalnızca komut satırı argümanlarını farklılaştırmış gibi göründüğü görüşü; böyle basit bir yama dosyasını uygulamak için yeni bir deponun install.sh dosyasını çalıştırmaktan özellikle kaçınılması gerektiği yönünde güçlü uyarı

  • Bunun MLX’te de mümkün olup olmayacağını soran yorum; MLX’te hızın daha iyi olduğu ve bu yaklaşımın Mac kullanıcılarına gerçek kullanım hızında uzun diyalog desteği sağlayabileceği beklentisi

    • Muhtemelen mümkün olabileceği, ancak kendisinin şu sıralar MLX’i derinlemesine incelediği; framework’ün iyi tasarlanmış olsa da örnek kod ve benchmark bilgisinin az olması nedeniyle henüz olgunlaşmamış hissettirdiği değerlendirmesi; hatta en çok Haskell binding’lerini heyecan verici bulduğu kişisel izlenimi; lazy evaluation özelliğinin uygun olabileceği ve saf fonksiyonel derleme grafiği yapısının da iyi uyum sağlayabileceği görüşü; Haskell’de makine öğrenmesinin ilginç olacağı beklentisi

  • --cache-type-k, --cache-type-v seçeneklerinden pratikte bir farkı olup olmadığını soran yorum

    • Bunun LLM’in sadece GitHub yıldızı toplamaya yönelik bir girişimi gibi göründüğü, gerçekte mevcut işlevlerden farklı olmadığı yönünde sert görüş
    • MLX/MPS’te 4 bit desteğinin olmadığını ya da 8 bit desteğinin bile eksik olduğunu hatırladığı; bf16 desteğinin de yakın zamanda eklendiği; geçmişte Apple GPU’larda type_k/v yöntemiyle en düşük 16 bit (f16/bf16) seviyesine kadar inilebildiği için llama.cpp iç yapısını net bilmemekle birlikte biraz farklı bir yaklaşım olabileceği tahmini
    • Kendisinin de bu farkı merak ettiğini belirten kısa katılım

  • Kodu okuduktan sonra yamanın gereksiz olduğu sonucuna vardığını; ilgili özelliğin zaten 2023’te llama.cppye eklendiğini PR bağlantısıyla doğruladığını; fork depo yerine yama uygulama yöntemiyle install.sh çalıştırmaya yönlendirilmesinin temkin gerektirdiğini; depoda birden fazla yama dosyası, tekrar eden kod ve yama dosyalarının üzerine yazılması gibi kafa karıştırıcı bir yapı bulunduğunu belirten yorum; aslında yalnızca --kvq seçeneğini eklediğini, halbuki ayrı K/V kuantizasyon seçeneklerinin zaten mevcut olduğunu; yazarın bu mevcut işlevleri bilmiyor olamayacağından şüphelendiğini; karmaşık betikler sunan depolardaki betiklerin çalıştırılmasını önermediğini; HN gönderisi ve GitHub yıldız sayısı yüksek olsa da içeriğin yanıltıcı olduğu eleştirisini; yazarın soruları sürekli geçiştirmesini de kaygı verici bulduğunu; ayrıca depo ve betiklerin eski llama.cpp kod tabanıyla karışık halde olduğunu ve güncel yapıyla uyuşmadığını, bunun da ek kafa karışıklığı yarattığını söyleyen sonuç değerlendirmesi

    • Kendisinin de birçok şüpheli nokta gördüğünü, ama belki bir şeyi gözden kaçırmış olabileceğini düşünerek yazarın açıklamasını beklediğini söylemesi; ancak çok sayıda kırmızı bayrak bulunduğu ve GitHub etkinlik geçmişine bakıldığında LLM ile üretilmiş kodlarla popüler projeleri doldurma niyetinden şüphe duyulduğunu belirtmesi
    • Nihayet mantıklı konuşan birinin çıktığını söyleyen yorum; yamayı uygulamak yerine doğrudan orijinal projenin fork’u şeklinde ilerlenmesi gerektiğinin tek başına bile bir güven riski işareti olduğu; yazarın GitHub varlığının bile şüpheli göründüğü ve popüler projelere çok sayıda LLM kalıntısı PR göndererek kendini katkıcı gibi göstermeye çalıştığı; bunun bilgi kirliliği ya da yapay zeka kaynaklı güven erozyonunun başlangıcı olabileceğine dair endişe

  • Zaten dönüştürülmüş .gguf formatlı modellerde de ayrımlı KV kuantizasyonunun (K8V4 vb.) uygulanıp uygulanamayacağını, model türü ya da tokenizer ayarları açısından bir sınırlama olup olmadığını soran yorum

    • KVSplit’in ana avantajının, mevcut .gguf modellerle özel bir dönüştürme olmadan doğrudan kullanılabilmesi olduğu açıklaması; kuantizasyonun model ağırlıklarından bağımsız olarak yalnızca çalışma anındaki KV cache’e uygulandığı; --kvq-key ve --kvq-val bayraklarının sadece bellekte saklama biçimini belirlediği; kendisinin LLama-3, Mistral, Phi-2/Phi-3, TinyLlama, Qwen gibi çeşitli modellerde bunu başarıyla test ettiği; ancak bunun llama.cpp Metal backend’ine özgü olduğu ve Flash Attention’ın şu anda kullanıcı tanımlı KV cache formatını baypas ettiği için -fa 0 seçeneğinin gerektiği; bunun dışında attention kullanan transformer yapılarında genel olarak uygulanabilir olduğu

  • 64GB, 128GB gibi yüksek kapasiteli Apple Silicon sistemlerde bu yamanın daha hızlı ya da daha iyi olup olmadığını soran yorum; Apple Silicon’da context window genişletmenin pratikte yavaş olduğuna dair söylentiler olduğu ve büyük bellekte bunun gerçekten anlamlı olup olmadığını merak ettiğini belirtiyor

    • KVSplit’in bellek tasarrufu etkisinin context uzunluğuyla orantılı olduğu için yüksek kapasiteli Mac’lerde mutlak faydanın daha büyük olduğu; 128GB Mac Studio’da yüz binlerce token’lık context’lerin ele alınabildiği; ancak bunun temel hesaplama hızını artırmadığı, yalnızca bellek verimliliğini iyileştirdiği; benchmarklarda K8V4 ayarında %14,5 throughput artışı görüldüğü ama bunun bellek erişim verimliliğinden kaynaklandığı; büyük modellerdeki “yavaşlık” sorununun esasen hesaplama performansı sınırlarından geldiği, dolayısıyla RAM veya KV cache optimizasyonundan bağımsız olduğu; yani KVSplit’in bellek sınırına çarpılan durumlarda faydalı olduğu ve pratik kullanımda 7B~13B gibi daha küçük modellere daha büyük context window ayırmanın daha ideal olduğu; hem büyük model hem de ultra uzun pencere gerekiyorsa sunucu sınıfı GPU’ların hâlâ daha uygun olduğu, ancak Apple donanımının sınırlarını genişletmesi açısından anlamlı olduğu açıklaması

  • İlgi çekici bulan ve biraz daha üst düzey bir açıklama isteyen yorum; 2048 token’lık bir modelin 4~6k gibi genişletmelerde kullanılıp kullanılamayacağını, 128k context modelinin 256k+ pencereyle kullanılıp kullanılamayacağını ve yerel modeller için ideal kullanım senaryolarını soruyor

    • K8V4 yapılandırmasında %59 bellek tasarrufu sağlanabildiği, bu nedenle azami context uzunluğunun 2,4 kata kadar artabildiği; yani 2048 token’lık bir modelin yaklaşık 5000 token’a, 8K’lık bir modelin ise yaklaşık 19,5K’ya genişletilebildiği; pratikte MacBook’ta bir kitabın tamamını tek seferde işlemek, büyük kod tabanlarını analiz etmek veya etkileşimli uygulamalarda uzun konuşma geçmişini korumak gibi kullanım örnekleri olduğu; bellek tasarrufu etkisinin context uzunluğuna göre doğrusal arttığı; kendi deneyiminde 8K context’te KV cache’in 176MB’den 72MB’ye düştüğü ve 128k’de tasarrufun gigabayt seviyesine çıktığı; özellikle giriş uzunluğu sınırı nedeniyle OOM yaşanan durumlarda en etkili çözüm olduğu açıklaması
    • Bellek tasarrufu sayesinde belirli bir modelin kaynak gereksinimini düşürdüğü için, kullanım amacına göre çeşitli şekillerde uygulanabileceği; ancak context window’yu gerçekten büyütmenin uzman olmayanlar için kolay olmadığı, bu nedenle daha büyük pencere için eğitilmiş modellerin tercih edilmesinin daha iyi olduğu; yerel modellerin çevrimdışı kullanım, güvenlik ve deney amaçlı çeşitli şekillerde değerlendirilebildiği ve çoğu kullanımın model ayarlama deneyleri etrafında toplandığı görüşü

  • Gerçekten iyi bir fikir ve deneme olduğunu söyleyen övgü; bunun GPU’larda da uygulanıp uygulanamayacağını ve diğer kuantizasyon teknikleriyle birlikte kullanılıp kullanılamayacağını soran ek yorum

    • Bu yaklaşımın muhtemelen NVIDIA/AMD GPU’larda da aynı şekilde uygulanabileceği; key’lerin value’lara göre daha yüksek hassasiyet gerektirmesi ilkesinin donanımdan bağımsız olduğu; llama.cppnin CUDA backend’inin de zaten --cache-type-k, --cache-type-v seçenekleriyle ayrı yapılandırmayı desteklediği; mevcut yamanın Metal’e özel olsa da ilkenin doğrudan taşınabilir olduğu; diğer kuantizasyon teknikleriyle birlikte de kullanılabildiği ve KV cache kuantizasyonunun yalnızca çalışma sırasında uygulandığı için ağırlık kuantizasyonuyla çakışmadığı; bunun dönüştürme hattında ayrı bir aşama olduğu; ancak vLLM, TensorRT-LLM gibi farklı cache yapıları kullanan motorlarda ayrı uygulama gerektiği; GPU’da en büyük etkinin FlashAttention yapısına doğrudan entegre edildiğinde görüleceği ve bellek tasarrufunun hız artışına da dönüşebileceği açıklaması

  • Tam olarak anlayamadığı noktalar olduğunu ve bir tuhaflık sezdiğini söyleyen yorum; ilgili betiğin çalıştırılmamasını tavsiye ediyor ve bunu raporladığını belirtiyor

  • Performansın nasıl değiştiğini merak eden yorum; daha uzun context’i belleğe sığdırmanın sonunda hesaplama hızını yine de değiştirmeyebileceğini soruyor

    • Aynı model ve aynı prompt’ta fp16, q8, q4 gibi farklı cache türlerini denediğinde iterasyon hızlarının benzer hissettirdiğini; iç işleyişi doğrulamadığını ama 4~8 bit SIMD toplu işlemle vektörlerin paketlenmesini beklediğini, pratikte ise bunun yapılmıyor gibi göründüğünü belirtiyor