KV-Cache: LLM Belleğinin Sessiz Darboğazı

Sohbet uzadıkça niye yavaşlar?

Bir LLM ile uzun bir sohbet et. İlk yanıt hızlı gelir, beş cevap sonra biraz yavaşlar, on cevap sonra duraksamalar başlar. Bağlam 100K token'a yaklaşırsa fiyat da hızla artar.

Bunun teknik adı: KV-cache şişmesi.

Attention'ı hatırlat

Attention'da her token üç vektör üretir: query ($Q$), key ($K$), value ($V$). Yeni bir token üretilirken:

1. Yeni token'ın $Q_t$ hesaplanır.
2. Geçmiş tüm token'ların $K, V$'leri ile attention skoru hesaplanır.
3. Bu skorlarla ağırlıklı $V$ toplanır.

Eğer geçmiş $K, V$'leri her seferinde yeniden hesaplarsak, her yeni token için tüm geçmiş işlenir — $O(n^2)$ iş.

Çözüm: önbellekleme

Mantık basit: $K, V$ matrisleri geçmiş tokenlerden değişmez. Bir kez hesapla, sakla. Yeni token için sadece yeni $K_t, V_t$ ekle.

Bu önbellek KV-cache'tir. Her transformer üretim adımında en hızlı kazanç bu.

Boyut

KV-cache boyutu:

$$\text{boyut} = 2 \cdot n \cdot L \cdot h \cdot d_h \cdot \text{bytes}$$

• $n$: token sayısı
• $L$: katman sayısı
• $h$: attention başı sayısı
• $d_h$: başlık boyutu
• $2$: K ve V için
• $\text{bytes}$: float16 için 2

Llama 70B örneği ($L=80, h=64, d_h=128$): her token için $\sim$1.3 MB. 100K bağlam = 130 GB. Bir H100 GPU'nun toplam belleği 80 GB!

İşte bu yüzden uzun bağlam pahalıdır — model parametrelerinden bile büyük olabilir.

Yönetim teknikleri

1. GQA / MQA — başlık paylaşımı

Multi-Query Attention (MQA, 2019): Tüm attention başları tek bir $K, V$ paylaşır. KV-cache $h$ kat küçülür.

Grouped-Query Attention (GQA, 2023): Başlıkları gruplara böl, her grup bir $K, V$. Kalite ve bellek arasında orta yol. Llama 2/3, Mistral, Gemma standart olarak GQA kullanır.

2. Sayfa tabanlı yönetim — PagedAttention

vLLM (Berkeley, 2023) ekibinin önerisi: KV-cache'i işletim sisteminin sayfa belleği gibi yönet.

Klasik sorun: bir kullanıcının uzun bağlamı, kullanılmayan boş alanları yan yana getirir — fragmentation. PagedAttention 16'lık blok bloklarda yönetir, fragmentasyonu %4'e düşürür. Aynı GPU'da 5-10x daha çok eşzamanlı kullanıcı.

3. Quantization — KV-cache'i sıkıştır

INT8 ya da INT4 ile sakla: 2-4x daha küçük. Kalite kaybı küçük (etkili teknikler: GPTQ, AWQ).

4. KV-cache eviction — eskileri at

Önbellekten "önemsiz" tokenleri at. StreamingLLM (2023): ilk N "saplama" tokeni + son M tokeni tut, ortayı at. Sonsuz bağlamla başa çıkar ama hatırlama kaybı var.

5. Cross-layer paylaşım

Yeni mimariler (örnek: Llama 4 nightly), bazı katmanların KV-cache'ini paylaşır.

Prefix caching

İki kullanıcı aynı system prompt'la başlıyorsa, o prompt'un KV-cache'i tek seferlik hesaplanıp paylaşılabilir. Anthropic'in prompt caching özelliği bu mantıkla çalışır — %90'a varan maliyet düşüşü.

Etki

KV-cache yönetimi modern LLM ekonomisinin merkezindedir:

• Per-token fiyatı: %70 bellek bant genişliği ile sınırlı; KV-cache iyileştirmesi doğrudan fiyat düşürür.
• Eşzamanlı kullanıcı: Bir GPU'da kaç kullanıcı barındırırsın? KV-cache verimliliği belirler.
• Bağlam uzunluğu: 1M token bağlam vaat eden modellerin temel meselesi.

OpenAI, Anthropic, Google çıkarım maliyetlerindeki büyük düşüşün arkasındaki sebeplerden biri KV-cache yönetimidir (öbürü speculative decoding ve flash attention).

Klasik benzetme

Bir matematik dersinde tahta düşün. Hoca her teorem için bir önceki adımdan kaldığını silmeden ilerliyor: $a, a+b, a+b+c, \ldots$. Bu tahta KV-cache'tir. Sınıf büyüdükçe (token sayısı arttıkça) tahta yetmez. Çözümler: küçük tahta (MQA), bölümleyerek bak (PagedAttention), eski şeyleri sil (eviction), küçük yazı yaz (quantization).

Bağlam

Transformer için: [[transformer-attention-is-all-you-need]]. Çıkarım hızı için: [[flashattention-gpu-yu-akilli-kullanan-attention]], [[speculative-decoding-tahmin-ile-llm-leri-hizlandirma]]. Alternatif mimari için: [[mamba-transformer-a-meydan-okuyan-uzun-bagimli-model]]. Modellerin küçültülmesi için: [[quantization-modelleri-kucultup-hizlandirma]].