KV cache boyutu: formül ve gerçek modellerle örnekler

Bir dil modeli metin üretirken, önceki her token için her katmanda hesapladığı key ve value'ları saklar; böylece bir sonraki token için onları yeniden hesaplamaz. Bu depo KV cache'tir. Kaba hesapların atladığı GPU belleği kısmıdır ve uzun context'te ya da çok kullanıcıyla modelin ağırlıklarını geçer.

Formül

Her token için her katman, her key-value head başına bir key ve bir value vektörü saklar:

token başına KV byte = 2 × katman × key-value head × head boyutu × değer başına byte
KV cache             = token başına KV byte × context uzunluğu × eşzamanlı dizi

2, key ile value'yu sayar. Bir değer FP16 ya da BF16'da 2 byte, FP8'de 1 byte tutar. Katman, key-value head ve head boyutu mimariyle sabittir — modelin config.json dosyasında num_hidden_layers, num_key_value_heads ve head_dim — aynı boyuttaki iki modelin çok farklı önbellek istemesinin nedeni budur. Multi-head latent attention kullanan modellerde formülün ortası değişir; bkz. GQA, MQA ve MLA.

Çözümlü örnek: Llama 3.1 8B Instruct

Llama 3.1 8B Instruct 32 katmana, 8 key-value head'e ve 128 boyutlu head'lere sahiptir. FP16'da bu, token başına 2 × 32 × 8 × 128 × 2 = 131.072 byte, yani 128,0 KiB eder. Tek kullanıcı 8k token'da 1,00 GiB önbellek ister; 131.072 token'lık tam context'te 16,00 GiB — 14,96 GiB tutan BF16 ağırlıklarından fazla.

Bunu belirleyen parametre sayısı değildir. Qwen2.5 7B Instruct ile Llama 3.1 8B Instruct boyut olarak birbirine yakındır — 7,62B ve 8,03B parametre — ama Llama 3.1 8B Instruct token başına 128,0 KiB saklar, Qwen2.5 7B Instruct ise 56,0 KiB. Aradaki 2,3× fark katman ve key-value head sayısından gelir.

Popüler modellerde token başına önbellek

FP16, tek dizi. —: modelin maksimum context'inin ötesi. DeepSeek V3, head başına key ve value yerine sıkıştırılmış bir latent saklar. Gemma 2 ve gpt-oss bu tabloya alınmadı: sliding-window katmanları pencerede büyümeyi bırakır, bu yüzden token başına maliyetleri context uzadıkça düşer. Hesaplayıcı bunu katman katman sayar.

Eşzamanlılık onu çarpar

Her eşzamanlı dizinin kendi önbelleği vardır. 72,82 GiB kullanılabilir belleğiyle tek bir H100 SXM 80GB üzerinde Llama 3.1 8B Instruct, BF16'da kullanıcı başına 8k token ile 55, 32k ile 13, 128k ile 3 kullanıcıya yer bırakır. Ağırlıklar tabanı belirler; önbellek, üstüne kaç kişinin sığacağına karar verir.

Onu ne küçültür, ne küçültmez

• Daha az key-value head. Grouped-query ve multi-query attention key-value head'leri query head'ler arasında paylaştırır; multi-head latent attention sıkıştırılmış bir latent saklar. Bu, seçtiğin modelle birlikte gelir.
• FP8 KV cache. Değer başına iki yerine bir byte, önbelleği yarıya indirir. vLLM bunu --kv-cache-dtype fp8 olarak sunar; uzun context'li işlerde doğruluğa mal olabilir, önce doğrula.
• Daha düşük context sınırı. Önbellek bir dizinin tuttuğu her token'la büyür; dizi uzunluğunu sınırlamak — vLLM'de --max-model-len — en kötü durumu sınırlar.
• Ağırlık quantization'ı değil. INT4 ya da FP8 ağırlıklar yalnızca ağırlıkları küçültür; önbellek kendi hassasiyetinde kalır, bu yüzden context büyüdükçe kazanç daralır. Bkz. quantization ve VRAM.
• Paged attention ve prefix caching önbelleği küçültmez, daha iyi kullanır: bellek, baştan ayrılmak yerine diziler büyüdükçe bloklar hâlinde verilir ve aynı ön eki paylaşan istekler o blokları ortak kullanabilir. LLMScale bu verimliliği modellemez; sayıları ihtiyacın tamamıdır.

• Modelin için KV cache'i hesapla
• GQA, MQA ve MLA
• Quantization ve VRAM
• Modele göre VRAM