Cache'i fp8 veya int4'e quantize edebilir miyim?

Self-hosted (vLLM, SGLang) için evet, çok yaygın. KV cache fp8 quantization 2× memory tasarrufu, ~1% quality loss. Anthropic/OpenAI/Gemini ne kullanıyor belli değil (kapalı kaynak), muhtemelen fp8 veya mixed precision.

KV Cache Memory Layout: 200K Context Kaç GB?

Name: KV Cache Memory Layout: 200K Context Kaç GB?
Author: Şükrü Yusuf KAYA

KV cache mantığını biliyoruz; ama gerçek bir model için bellekte ne kadar yer kaplıyor? Bu derste Llama-3-70B ve Claude Sonnet için gerçek hesaplar yapacak ve neden GPU bellek darboğazı caching'i provider tarafında karmaşık yaptığını göreceksin.

Şükrü Yusuf KAYA

14 dakikalık okuma

14.05.2026

Orta

KV Cache: Bellekte Ne Kadar Yer Kaplar?

Caching güzel ama bedava değil. KV cache bellekte tutuluyor — provider'da disk/RAM, self-hosted'da GPU VRAM. Şimdi gerçek sayılarla hesaplayalım.

Formül#

Her token için KV cache boyutu:

Burada:

2 = K ve V için (ikisi de saklanır)
n_layers = transformer layer sayısı (Llama-3-70B için 80)
n_kv_heads = KV head sayısı (GQA varsa azaltılmış)
d_head = head boyutu (genelde 128)
bytes = parametre başına byte (fp16 = 2, fp8 = 1, int4 = 0.5)

Vanilla Multi-Head Attention (MHA)#

Eski yaklaşımda: (n_{\text{kv_heads}} = n_{\text{query_heads}}).

Llama-2-70B (MHA, fp16): 80 layer × 64 head × 128 d_head × 2 (KV) × 2 byte = 2.6 MB / token.

200K tokenlık cache = 200.000 × 2.6 MB = 520 GB.

VRAM koymak imkansız (A100 80GB, H100 80GB). Bu yüzden bunu kimse vanilla yapmıyor.

Bellek Patlaması

520 GB cache! İşte bu yüzden modern modeller GQA (Grouped Query Attention) veya MQA (Multi-Query Attention) kullanıyor — KV head sayısını azaltıyor.

Grouped Query Attention (GQA)#

Llama-3-70B'de inovasyon: Query head 64 ama KV head sadece 8. Yani 8 query head, 1 KV head'i paylaşıyor.

Yeni hesap — Llama-3-70B (GQA, fp16):

80 layer × 8 KV head × 128 d_head × 2 × 2 byte = 328 KB / token.

200K cache = 200.000 × 328 KB = 64 GB.

Hâlâ büyük ama yönetilebilir. fp8 quantization ile yarıya iner: 32 GB.

python

def kv_cache_size_gb(
    context_tokens: int,
    num_layers: int,
    num_kv_heads: int,
    d_head: int,
    bytes_per_param: float = 2.0,  # fp16
) -> float:
    """KV cache boyutu (GB)."""
    bytes_per_token = 2 * num_layers * num_kv_heads * d_head * bytes_per_param
    total_bytes = bytes_per_token * context_tokens
    return total_bytes / (1024 ** 3)
 
# Popüler modeller
models = [
    ("Llama-3-70B (GQA-8) fp16, 128K", 128_000, 80, 8, 128, 2.0),
    ("Llama-3-70B (GQA-8) fp8,  128K", 128_000, 80, 8, 128, 1.0),
    ("Llama-3-70B (GQA-8) fp16, 1M",  1_000_000, 80, 8, 128, 2.0),
    ("Llama-2-70B (MHA-64) fp16, 200K", 200_000, 80, 64, 128, 2.0),
    ("Mistral-7B (GQA-8) fp16, 128K", 128_000, 32, 8, 128, 2.0),
    ("Gemma-7B (MQA-1) fp16, 8K",      8_000, 28, 1, 128, 2.0),
]
 
print(f"{'Model':<40} {'KV Cache':>10}")
print("─" * 55)
for label, n, L, kvh, d, b in models:
    size = kv_cache_size_gb(n, L, kvh, d, b)
    print(f"{label:<40} {size:>8.2f} GB")

Kendi modelinin KV cache boyutunu hesapla

Provider Tarafındaki Anlamı#

Anthropic, OpenAI, Gemini — hepsi caching'i sunucu tarafında yapıyor. Senin modelin bilmediği şey: provider'ın paylaşımlı bir cache fleet'i var.

[Senin sorgu] → Load Balancer → Cache Server (Redis/SSD) → GPU Cluster
                                      ↓
                          "Bu prefix var mı cache'te?"
                          Var → KV matrislerini yükle, prefill atla
                          Yok → Normal prefill, cache'e yaz

Provider'ın iki sınırı var:

Cache storage — toplam ne kadar GB tutabilir
Cache retrieval bandwidth — saniyede ne kadar GB yükleyebilir

İşte bu yüzden:

5dk TTL ucuz — eviction politikası agresif
1h TTL pahalı — daha fazla storage tüketir
Az kullanılan cache eviction'a uğrar (LRU genelde)

Self-Hosted (vLLM) Tarafı#

vLLM ile kendin host edersen GPU VRAM'in sınırlı. Llama-3-70B fp16 ağırlıkları zaten 140 GB. H100 80GB'a sığmaz; multi-GPU şart.

Cache memory = "kalan VRAM". Örnek: 2× H100 (160 GB total) → ~140 GB model + ~20 GB cache margin.

Bu yüzden Modül 10'da vLLM ve SGLang'ın PagedAttention ve RadixAttention tekniklerini göreceğiz — KV cache'i daha verimli yönetmek için.

✓ Pekiştir#

Bir Sonraki Derste#

Prefix sharing teoremini kuracağız: matematiksel olarak neden aynı prefix → aynı KV. Bu, caching'in doğru olduğunu kanıtlamak için lazım.

Sık Sorulan Sorular

Pratikte çok az düşüş veya hiç. Llama-3'ün hem 8B hem 70B GQA kullanıyor ve önceki nesil MHA modellerden iyi performans veriyor. Tradeoff: %95-99 accuracy, %85-90 daha az KV cache memory.

Yorumlar & Soru-Cevap

(0)

Yorum yazmak için giriş yap.

Yorumlar yükleniyor...

İlgili İçerikler

1. Temeller — Context Penceresi Ekonomisi