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

 (github.com/dipampaul17)
1 puan yazan GN⁺ 2025-05-18 | 1 yorum | WhatsApp'ta paylaş
  • KVSplit, Apple Silicon'da LLM'lerin attention KV cache'ine key ve value için farklı nicemleme hassasiyetleri uygulayarak aynı bellek bütçesi içinde daha uzun context ve daha ağır modeller çalıştırmayı hedefliyor
  • Temel sonuç K8V4 yapılandırması; 8K token için FP16 176.00MB'yi 71.50MB'ye düşürürken token işleme hızını 54,360 tokens/sec'den 57,438 tokens/sec'e çıkarıyor ve perplexity değişimi +0.86% olarak sunuluyor
  • Key'in value'ya göre nicemlemeye daha duyarlı olduğu sonucuna dayanarak, aynı toplam bit sayısını kullanan K4V8'in kalite düşüşünün K8V4'e göre yaklaşık 7 kat daha büyük olduğu özetleniyor
  • Sunulan özellikler arasında llama.cpp yamasının uygulanması, Metal destekli derleme, bellek·hız·perplexity benchmark'ları, CSV/JSON sonuç kaydı, görselleştirme araçları ve Activity Monitor tabanlı bellek tasarrufu ekran görüntüsü alma yer alıyor
  • Önerilen yapılandırma, kalite ile bellek tasarrufu arasında denge kurmak için K8V4; en yüksek bellek tasarrufu gerekirse K4V4 ile %72 tasarruf karşılığında yaklaşık %6 kalite kaybı göze alınabiliyor

KVSplit'in çözmeye çalıştığı sorun

  • KVSplit, Apple Silicon Mac'lerde LLM çıkarımı sırasında KV cache belleğini azaltmaya yönelik bir proje
  • Attention mekanizmasının KV cache'inde key ve value'ya farklı nicemleme hassasiyetleri uygulanıyor
  • Hedefler şunlar:
    • Bellek kullanımını en fazla %72 azaltmak
    • Aynı bellek bütçesi içinde 2-3 kat daha uzun context çalıştırmak
    • FP16'ya kıyasla çıkarım hızını korumak veya iyileştirmek
    • Apple Silicon'a uygun Metal desteği sunmak

Temel benchmark sonuçları

  • 8K token için yapılandırma bazlı sonuçlar şöyle:
    • 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%
  • Bellek azaltımı tablosunda K8V4'ün 8K token'da %59 tasarruf, K4V4'ün ise %72 tasarruf sağladığı belirtiliyor
  • Performans tablosunda K8V4'ün FP16'ya göre +%5.7, K4V8'in +%8.0, K4V4'ün ise +%1.5 hız artışı gösterdiği yer alıyor
  • K8V8, FP16'ya göre belleği azaltıyor ancak hız -%5.3 düşüyor

Dizi uzunluğuna göre bellek kullanımı

  • Context uzunluğu arttıkça KV cache bellek tasarrufu etkisi büyüyor
  • 8192 token için bellek kullanımı şöyle:
    • FP16: 176.00MB
    • K8V8: 93.50MB
    • K8V4: 71.50MB
    • K4V8: 71.50MB
    • K4V4: 49.50MB
  • 4096 token için de FP16 88.00MB'ye karşı K8V4/K4V8 35.75MB, K4V4 ise 24.75MB kullanıyor
  • 128 token için FP16 5.50MB, K8V4/K4V8 2.23MB, K4V4 1.55MB olarak veriliyor

Key ve value'nun asimetrisi

  • KV cache belleğinde baskın payı her token'ın key vektörü ve value vektörü depolaması oluşturuyor
  • Projenin temel gözlemi, key'in value'ya göre nicemlemeye çok daha duyarlı olması
  • K8V4, 8-bit key ve 4-bit value kullanarak şu denge noktasını sunuyor:
    • FP16'ya kıyasla %0.86 perplexity kaybı
    • %59 bellek tasarrufu
    • FP16'dan daha hızlı çıkarım hızı
  • K4V8, K8V4 ile aynı toplam bit sayısını kullanıyor ancak kalite düşüşünün K8V4'e göre yaklaşık 7 kat daha büyük olduğu belirtiliyor
  • Bu asimetri sayesinde consumer hardware üzerinde daha uzun context ve daha büyük modellerin çalıştırılabildiği açıklanıyor

Kurulum ve entegrasyon yöntemi

  • Kurulum, depoyu clone ettikten sonra scripts/install_kvsplit.sh çalıştırılarak yapılıyor
git clone https://github.com/dipampaul17/KVSplit.git
cd kvsplit

chmod +x scripts/install_kvsplit.sh
./scripts/install_kvsplit.sh
  • Kurulum betiği, Python ortamı kurulum yöntemi seçmeye izin veriyor
    • Virtual Environment: Proje klasörü içinde bağımsız bir Python ortamı oluşturur
    • System Python: Mevcut Python kurulumunu kullanır
    • Skip Python Setup: Python ortamını kullanıcı kendisi yönetir
  • llama.cpp entegrasyon yöntemi de seçilebiliyor
    • Standart yöntem: llama.cpp'yi clone edip KV split yamasını uygulamak
    • Git submodule yöntemi: geliştiriciler veya ileri seviye kullanıcılar için llama.cpp'yi submodule olarak eklemek
  • Kurulum süreci; Apple Silicon için Metal destekli llama.cpp kurulumu, differentiated KV cache quantization'ı etkinleştirme, isteğe bağlı test modeli indirme ve görselleştirme araçları kurulumu içeriyor

Kullanım örnekleri ve CLI seçenekleri

  • Hızlı karşılaştırma, kullanıcının elindeki GGUF model ile çalıştırılabiliyor
python scripts/quick_compare.py --model models/your-model.gguf
  • Karşılaştırma hedefleri FP16, K8V8, K8V4, K4V8, K4V4; bellek, hız ve kalite metriklerini birlikte gösteriyor
  • README'deki çalıştırma örneği, llama-cli ile --flash-attn ve KV nicemleme seçeneklerini birlikte kullanıyor
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq 8
  • K4V8 örneğinde key ve value bitleri ayrı ayrı belirtiliyor
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq-key 4 --kvq-val 8
  • 32K context örneğinde FP16 için yaklaşık 1.4GB, K8V4 için ise yaklaşık 400MB gerektiği belirtiliyor
./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
  • Başlıca CLI bayrakları şunlar:
    • -t 8: İş parçacığı sayısı, çoğu Apple Silicon çipte 8 öneriliyor
    • --flash-attn: Optimize edilmiş attention'ı etkinleştirir, Apple Silicon'da önerilir
    • --kvq N: key ve value bitlerini ayarlar
    • --kvq-key N: yalnızca key bitlerini ayarlar
    • --kvq-val N: yalnızca value bitlerini ayarlar
    • -c N: context boyutu
    • -n N: üretilecek token sayısı
    • -f FILE: giriş dosyası
    • -m MODEL: .gguf model dosyası yolu

Benchmark ve görselleştirme araçları

  • Tam benchmark scripts/benchmark_kvsplit.py ile çalıştırılıyor
python scripts/benchmark_kvsplit.py
python scripts/benchmark_kvsplit.py --config K8V4 --seq-len 4096
  • Görselleştirme scripts/visualize_results.py ile üretiliyor
python scripts/visualize_results.py
  • Benchmark şu öğeleri ölçüyor:
    • Memory Usage: VRAM ve KV cache belleği
    • Performance: dizi uzunluğuna göre tokens/sec
    • Quality: llama-perplexity kullanılarak perplexity
    • Scaling: dizi uzunluğuna göre bellek ve performans değişimi
  • Sonuçlar CSV/JSON biçiminde kaydediliyor ve otomatik özet istatistikleri ile görselleştirme grafikleri üretiliyor
  • capture_memory.sh, Activity Monitor'da bellek tasarrufunu yakalamaya yönelik bir araç

Apple Silicon optimizasyonu ve kısıtlar

  • KVSplit, Apple'ın Metal framework'üne göre optimize edilmiş
  • Apple Silicon M serisi gibi bellek kısıtlı cihazlarda bellek verimliliğine odaklanıyor
  • README, llama.cpp'nin 256B page alignment nedeniyle gerçek bellek tasarrufunun teorik hesaplamadan biraz farklı olabileceğini belirtiyor
  • Desteklenen hedefler arasında M1, M2, M3, M4 çipleri yer alıyor

Önerilen yapılandırma ve yol haritası

  • Önerilen yapılandırma K8V4
    • 8-bit key, 4-bit value
    • %59 bellek tasarrufu
    • %0.86 kalite kaybı
    • FP16'ya göre +%5.7 çıkarım hızı
  • En yüksek bellek tasarrufu K4V4
    • 4-bit key ve 4-bit value
    • %72 bellek tasarrufu
    • Yaklaşık %6 kalite kaybı
    • Daha az hassas uygulamalar için uygun olduğu belirtiliyor
  • Çok uzun context'ler için K8V4 veya K4V4 öneriliyor; context uzunluğu arttıkça bellek tasarrufu birikiyor
  • Gelecek planları şöyle:
    • Token önemine dayalı Adaptive Precision
    • Katman bazında farklı hassasiyet kullanan Layer-Specific Quantization
    • Mistral, Phi-3 vb. için modele özgü optimizasyon
    • Web demosu
    • iOS ve iPadOS desteği
  • Lisans MIT ve katkılar issue veya pull request ile kabul ediliyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-18
Hacker News yorumları

  • İlginç. Bu sonuçların neden ortaya çıktığına dair bir sezgi olup olmadığını merak ediyorum. Bunun o sezgiyle mi keşfedildiğini, yoksa rastgele deneylerle mi bulunduğunu da merak ediyorum.
    Kurulum betiğindeki "apply patch" adımında hâlâ bir yer tutucu kalmış gibi görünüyor. git clone sonrası yamayı uygulatmak yerine llama.cpp’yi fork’layıp bunu Git submodule olarak dahil etmek kullanıcı dostu olabilir.
    Ayrıca herkesin yerel Python kurulumu farklı olduğundan, Homebrew Python bağımlılığını sabitlemek yerine llama.cpp ile ilgili kısımla Python ile ilgili kısmı ayırabilmek iyi olurdu.

    • Sezgi sorusu iyi. Fark, attention’da her bileşenin üstlendiği temel rolden kaynaklanıyor.
      Key’ler hangi token’lara dikkat edileceğini belirler ve benzerlik hesabı üzerinden gerçek attention örüntüsünü oluşturur. Value’lar ise attention belirlendikten sonra aktarılacak bilgiyi saklar.
      Key vektörlerini fazla agresif quantize ederseniz tüm token etkileşimlerinin benzerlik hesabı bozulur. Key’deki küçük bir hata attention’ı tamamen yanlış bir token’a yöneltebilir.
      Value’lar çok daha toleranslıdır. Value vektörü quantization hatası, attention örüntüsü zaten belirlendikten sonra yalnızca ilgili tek token’ın bilgi içeriğini etkiler.
      Bu, kütüphane katalog sistemiyle kitapların kendisi arasındaki farka benzer. Katalog numarası (key) bozulursa tamamen yanlış rafa bakarsınız; ama kitabın bazı sözcükleri (value) bulanıklaşsa bile hâlâ doğru kitabı okursunuz ve yalnızca ara sıra gürültü oluşur.
      Matematiksel olarak key’ler softmax hesabına girer ve küçük hatalar normalizasyon sürecinde üstel olarak büyür. Value’lar ise yalnızca doğrusal ağırlıklı ortalamadan geçtiği için hatalar birbirini sönümleme eğilimindedir.
      İlk olarak bu asimetriyle "More for Keys, Less for Values", "KV-AdaQuant" gibi makalelerde karşılaştım ve Apple Silicon çıkarımında etkisinin tam olarak ne kadar olduğunu nicel olarak görmek istedim. Aynı bellekte K8V4 ile K4V8 arasındaki kalite farkının 7 kat olması etkileyiciydi.
      Kurulum geri bildirimi için de teşekkürler; yer tutucuyu düzeltecek ve Python bağımlılıklarını daha esnek hâle getireceğim.
    • Yama aslında llama.cpp’ye uygulanmıyor. Çünkü argüman ayrıştırma 8 ay önce arg.cppye taşındı.
      Yine de sorun olmamasının nedeni, K ve V quantization’ını ayarlayan seçeneklerin zaten 2023’te llama.cpp’ye eklenmiş olması.
      Bu yamanın neden var olduğunu anlamıyorum. Zaten mevcut olan ayarı başka komut satırı argümanlarına dönüştürüp yeniymiş gibi göstermeye çalışmak dışında bir neden göremiyorum.
      Bu tür yeni depolardaki install.sh dosyalarını kimsenin çalıştırmamasını şiddetle öneririm. Özellikle yalnızca bir yama dosyası uygulamak gibi basit bir iş için gereksiz olduğunda daha da öyle.

  • Bu, --cache-type-k ve --cache-type-v kullanmaktan farklı mı?

    • Hayır. GitHub yıldızı toplamaya yönelik LLM üretimi bir girişim gibi görünüyor.
      Depodaki diğer tuhaflıklardan bazılarını başka bir yorumda yazdım.
    • Biraz farklı olduğunu tahmin ediyorum. MLX/MPS’te yerel 4-bit desteği yok; yanlış hatırlamıyorsam 8-bit de olmayabilir. İlk çıktığında bf16 desteği de yoktu.
      Bu yüzden eski type_k/v yöntemiyle Apple GPU’da inilebilecek en düşük seviyenin 16-bit f16/bf16 olduğunu düşünüyorum. Yine de llama.cpp iç işleyişinde uzman değilim, yanılıyor olabilirim.

  • Bu yamayı MLX üzerinde de yapmanın mümkün olup olmadığını merak ediyorum. MLX’te daha iyi hız alıyorum; bu yaklaşımla birleşirse Mac kullanıcıları da makul hızlarda uzun sohbetler yapabilir gibi görünüyor.

    • Muhtemelen mümkündür; ama şu anda MLX’in derinlerine iniyorum ve iyi tasarlanmış bir framework olsa da, birinin "en iyi yol"u benchmark’layıp örnek kod olarak sunduğu şeyleri alıp kullanabileceğiniz olgunluk düzeyinden epey uzak olduğunu görüyorum.
      Kişisel olarak en çok heyecanlandığım şey, inanması zor gelebilir ama Haskell binding’leri. Birkaç gün önce biri, Haskell’in lazy evaluation özelliğinin bu paradigmaya oldukça iyi uyduğunu ve derleme grafiğine neredeyse saf fonksiyonel bir yaklaşımla bakmanın da yardımcı olduğunu belirtmişti. Haskell’de makine öğrenmesi yapmak eğlenceli olabilir.

  • Farklılaştırılmış KV quantization’ın (ör. K8V4) hâlihazırda .gguf biçimine dönüştürülmüş modellere uygulanıp uygulanamayacağını merak ediyorum. Yoksa özel destek ekleyip modeli yeniden build etmek mi gerekiyor?
    Herhangi bir .gguf dosyasıyla uyumluysa model türü (Mistral, Phi-3 vb.) veya tokenizer ayarları konusunda kısıtlamalar olup olmadığını da merak ediyorum.

    • Mümkün. KVSplit’in temel avantajlarından biri, mevcut .gguf modelleri yeniden yapılandırmadan veya özel dönüşümden geçirmeden olduğu gibi kullanabilmesi. Quantization, model yükleme ya da dönüştürme sırasında değil, çalışma anındaki KV cache üzerinde gerçekleşiyor.
      KV cache, token’lar işlenirken çıkarım sırasında oluşturulur ve model ağırlıklarından tamamen ayrı olduğu için bu mümkün olur. --kvq-key ve --kvq-val bayrakları llama.cpp’ye yalnızca bu ara tensörlerin bellekte nasıl saklanacağını bildirir.
      Llama-3, Mistral, Phi-2/Phi-3, TinyLlama ve Qwen varyantlarında başarıyla test edildi.
      Tek sınırlama, llama.cpp’nin Metal backend’inin gerekmesi ve şu anda llama.cpp’nin Flash Attention uygulamasının özel KV cache biçimlerini atlaması nedeniyle Flash Attention’ın -fa 0 ile kapatılması gerektiği. Tekniğin kendisi, standart attention mekanizmasını kullanan herhangi bir transformer mimarisinde çalışacaktır.

  • Kodu okumaya fırsat buldum. Bu PR’ı doğru anladıysam, bu özellik 2023’ten beri zaten llama.cpp’de bulunduğu için yamaya gerek yok: https://github.com/ggml-org/llama.cpp/pull/4312
    Değişiklikleri commit olarak uygulanmış bir llama.cpp fork’u sunmak yerine, depo install.sh betiğini çalıştırmanızı istiyor. Bu betik, revizyon belirtmeden llama.cpp’nin master dalını checkout ediyor ve ardından küçük bir yama uyguluyor. Tek başına bu bile bir şeylerin tuhaf olduğuna dair uyarı işareti
    Depoda 4 farklı yama dosyası var, ayrıca kurulum betiğinin içinde Heredoc olarak gömülü bir yama sürümü daha bulunuyor. Betikte depoyu klonlayıp yama uygulamayı deneyen kodun da iki sürümü var
    install.sh, cp patch/split_kv_quant.diff patch/fixed_kv_patch.diff satırıyla bir yama dosyasını başka bir yama dosyasının üzerine yazıyor. Bu yüzden depoya check-in edilmiş fixed_kv_patch.diff, uygulanmadan önce üzerine yazılmış oluyor
    Bana göre aslında şu yamayı kullanmak istiyorlar gibi: https://github.com/dipampaul17/KVSplit/blob/main/patch/split... (düzeltme: sondaki yoruma bakılırsa gerçekte şu gibi görünüyor: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... )
    Bu yamanın eklediği tek şey, K ve V kuantizasyonunu aynı anda ayarladığını söyleyen --kvq argümanı; oysa hemen üstünde K ve V kuantizasyonunu ayrı ayrı ayarlayan yerleşik argümanlar zaten var. Yazar, bu yamaları oradan oraya taşırken özelliğin zaten var olduğunu fark etmemiş olabilir mi?
    Böyle yeni depolardaki shell betiklerini çalıştırmamanızı şiddetle öneririm. Özellikle de betik bu kadar karmaşıksa
    HN yazısı 200’den fazla oy aldı, GitHub deposu da 200’den fazla yıldız topladı ve artmaya devam ediyor; ancak içerik yanıltıcı görünüyor. Bu thread’de soruna işaret edip bolca flag alan yorum aslında haklıydı. Yazarın bu thread’e yanıt vermeye devam ederken özelliğin zaten var olduğu sorusundan kaçınması da endişe verici
    Düzeltme: Shell betiğini yanlış okumuşum. Görünüşe göre aslında şu yamayı uyguluyor: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... Yamayı uyguladıktan sonra garip biçimde fixed_kv_patch.diff dosyasını split_kv_quant.diff ile ezip geçiyor, ama sonrasında hiçbir şey yapmıyor. Bunun vibe coding sonucu mu, yoksa sadece dikkatsiz bir kod düzenlemesi mi olduğunu bilmiyorum; ama tanımadığınız depolardaki böyle shell betiklerini çalıştırmamak gerektiğini yinelemek istiyorum
    Düzeltme 2: Daha da kafa karıştırıcı. install.sh betiği llama.cpp deposunun eski URL’sine (https://github.com/ggerganov/llama.cpp) atıfta bulunuyor; bu URL bir süre önce değişti ve artık yönlendiriliyor. Yamalar common.cpp içindeki argüman ayrıştırmayı değiştirmeye çalışıyor, ancak o kod 8 ay önce arg.cpp dosyasına taşındı (https://github.com/ggml-org/llama.cpp/commit/bfe76d4a17228bf...). Bu durumda bu kurulum betiği ve depo, 2024 civarındaki koda dayanıp 2023 civarında llama.cpp’ye eklenen bir seçeneği kullanıyor gibi. Burada neler oluyor?

    • Doğru. Belki benim kaçırdığım bir şey vardır ve yazar burada açıklayabilir diye, şüpheli gördüğüm diğer kısımları özellikle söylemedim
      Çok fazla uyarı işareti var. En iyi ihtimalle, GitHub profilini LLM üretimi kodla şişirmeye çalışan biri gibi görünüyor. Profilindeki 12 Mayıs etkinliğine bakmak yeterli
    • Sonunda mantıklı bir şeyler çıktı. Bu projenin, asıl projeyi fork’layıp değişiklikleri commit etmek yerine yamalar uygulayarak çalışması bile endişelenmek için yeterli neden
      Ama asıl gönderi yazarının GitHub etkinliğinin tamamı şüpheli. 12 Mayıs’ta birçok popüler projeye LLM çorbası PR göndermiş; yalnızca JAX tarafı reddetmiş. Buna rağmen bu sayede, sanki katkı yapmış gibi popüler projeleri profiline sabitleyebilmiş
      Bunun ne kadar iğrenç olduğunu anlatmak zor. Yapay zeka alanında çalışan herkes bilgi kirliliğine ortak oluyor ve sonuçlarını henüz öngöremiyoruz bile. Ölü internet ve yapay zeka çorbası seli daha sadece başlangıç

  • 64 GB ya da 128 GB Apple Silicon’da bunlar 36 GB veya 48 GB’a göre anlamlı ölçüde daha hızlı ya da daha iyi mi?
    Büyük bağlamların ve büyük modellerin, parayla alınabilecek en hızlı ve en büyük Apple Silicon’da bile acı verecek kadar yavaş olduğunu okuyup durdum
    Bu yüzden bunun daha büyük belleği daha iyi kullanmayı sağlayıp sağlamadığını, yoksa pratikte Apple Silicon’da hâlâ nispeten küçük modellerin mi doğru seçenek olduğunu merak ediyorum

    • KVSplit’in bellek tasarrufu bağlam uzunluğuyla orantılı olarak arttığı için, 64 GB/128 GB gibi yüksek RAM’li Mac’ler mutlak miktar açısından daha büyük fayda görür. 128 GB Mac Studio ile potansiyel olarak yüz binlerce token’lık bağlam pencereleri bile ele alınabilir
      Ancak KVSplit hesaplama hızını temelden değiştirmez, yalnızca bellek verimliliğini değiştirir. Benchmark’larda K8V4 ile throughput %14,5 arttı, ama bunun nedeni hesaplama miktarının azalması değil, bellek yerelliğinin iyileşmesidir
      Apple Silicon’da büyük modellerin “acı verecek kadar yavaş” olmasının başlıca nedeni bellek kısıtı değil, hesaplama performansı sınırıdır. 70B parametreli bir model, kullanılabilir RAM ya da KV cache optimizasyonundan bağımsız olarak benzer token üretim hızında çalışacaktır
      KVSplit kullanılabilir belleği daha iyi kullanmayı sağlar. Özellikle darboğaz model boyutundan çok bağlam uzunluğu olduğunda değerlidir
      Pratik Apple Silicon kullanımında uygun nokta hâlâ daha küçük modellere (7B~13B) genişletilmiş bağlam penceresi eklemektir. Böylece makul üretim hızını korurken çok daha fazla metin işlenebilir
      İş akışınız hem devasa bağlam hem de büyük model gerektiriyorsa hâlâ sunucu sınıfı GPU’ları düşünmek gerekir; ancak KVSplit, Apple donanımında mümkün olan sınırı biraz daha ileri iter

  • Harika bir çalışma ve çok ilginç görünüyor, ama anlamak için biraz daha üst düzey açıklamaya ihtiyaç var
    Örneğin 2048 token bağlam pencereli bir modeli 4~6K bağlam penceresiyle çalıştırmayı mı sağlıyor? Yoksa gemma3 gibi 128K’lık bir modeli 256K ve üzeri bağlam penceresiyle çalıştırmayı mı sağlıyor?
    Yerel modeller için ideal kullanım senaryosu nedir?

    • K8V4 ayarı bellekte %59 tasarruf sağladığı için aynı donanımda fiilen 2,4 kat daha uzun bağlam çalıştırabilirsiniz. 2048 token bağlamlı bir model yaklaşık 5000 token işleyebilir, 8K bağlamlı bir model ise yaklaşık 19,5K’ya kadar çıkabilir
      Pratikte bu, bir MacBook’ta tüm bir kitabı tek seferde işlemek, dosyaları bölmeden büyük bir codebase’i analiz etmek ya da sohbet uygulamalarında uzun konuşma geçmişini korumak anlamına gelir
      Bellek tasarrufu bağlam uzunluğuyla doğrusal orantılıdır. Bağlam penceresi ne kadar uzunsa, mutlak olarak tasarruf edilen bellek o kadar büyür. M4 MacBook’umda 8K bağlamda KV cache 176 MB’tan 72 MB’a düştü. 128K bağlamda aynı orandaki tasarruf gigabaytlarca belleği boşa çıkarır
      Bu optimizasyon, model parametre sınırından çok bağlam penceresi sınırına takıldığınızda en değerlidir. Büyük model ağırlıkları değil de uzun girdi yüzünden bellek yetersizliği hatası alıyorsanız, KVSplit doğrudan darboğazı çözer
    • Belirli bir modelin bellek kullanımını azaltır. Bu boşluğu nasıl kullanacağınıza kullanıcı olarak siz karar verirsiniz
      Eğitimden sonra bağlam penceresini büyütmek basit değildir; bu yüzden tam olarak ne yaptığınızı bilmiyorsanız daha büyük bağlam penceresiyle eğitilmiş bir model bulmanız daha iyi olur
      Yerel modellerin kullanımları çevrimdışı çalışma, gizlilik/güvenlik vb. olarak çeşitlidir. Ancak çoğu kişi bunları modelleri ayarlayıp denemeler yapmak için kullanır

  • Garip bir şeyler oluyor; bunu kurmamak ya da o script’i çalıştırmamak daha iyi olur
    Gönderiyi flag’ledim

  • Harika bir fikir ve deneme. Bu GPU’ya da uygulanıyor mu? Ayrıca diğer quantization teknikleriyle de uyumlu gibi görünüyor; muhtemelen her biri için ayrı patch gerektiğini mi düşünmeliyiz?

    • Evet. Bu yaklaşımın NVIDIA/AMD GPU’larda da mümkün olma olasılığı yüksek. Anahtarların değerlere göre daha yüksek precision gerektirdiği temel ilkesi donanımdan bağımsızdır
      llama.cpp’nin CUDA backend’i zaten --cache-type-k ve --cache-type-v flag’leriyle ayrı cache type ayarlarını destekliyor. Bu özel patch Metal’e özgü optimizasyona odaklanıyor, ancak temel teknik aynen taşınabilir
      Diğer quantization yöntemleriyle de uyumludur. Bu KV cache optimizasyonu, model ağırlığı quantization’ı (Q4_K_M, GPTQ, AWQ vb.) ile birbirini tamamlar. Asimetrik KV cache precision’ı herhangi bir model ağırlığı formatıyla birlikte kullanılabilir
      KV cache quantization’ı token işleme sırasında çalışma zamanında gerçekleşir ve model ağırlıklarından ayrıdır; bu yüzden modelin kendisinin nasıl quantize edildiğiyle çakışmaz. Inference pipeline’ının farklı kısımlarında çalışırlar
      Ek çalışma gerektiren kısım, vLLM veya TensorRT-LLM gibi özel KV cache işleme mantığına sahip özel inference engine’leriyle entegrasyondur. Her birinin asimetrik KV precision’ı ayrı ayrı uygulaması gerekir
      GPU’da en doğrudan kazanç muhtemelen bu içgörünün FlashAttention implementasyonlarına doğrudan entegre edilmesinden gelir. CUDA donanımında bellek bant genişliği tasarrufu daha büyük hız artışlarına dönüşebilir

  • Küçük bağlam boyutlarında perplexity +%0,86 oldukça büyük sayılmaz mı? 64~128K gibi daha gerçekçi bağlam boyutlarında durum nasıl?

    • Asıl nokta bellek kullanımını azaltmak gibi görünüyor. Aynı sınırlı bellekte daha önce mümkün olmayan daha uzun bağlamların çalıştırılmasını sağlıyor
      Ya da boşalan belleği IDE gibi başka amaçlar için de kullanabilirsiniz