KV Cache ve Prompt Cache Arasındaki Farklar

KV cache ve prompt cache: kısa cevap

KV cache ve sağlayıcı tarafındaki prompt cache, aynı kelimeyi paylaşsalar da neredeyse hiçbir ortak noktaya sahip değildir. KV cache, istek bazlı bir çalışma belleğidir. Bir isteğin yaşam döngüsü boyunca sunucunuzun RAM veya VRAM biriminde tutulur; bağlam uzunluğu ve aynı anda çalıştırılan istek sayısıyla birlikte büyür. Sağlayıcı tarafındaki prompt caching ise faturalandırma ve gecikme süresini iyileştirmeye yönelik bir özelliktir. İsteğinizin değişmeyen bir ön eki, sağlayıcının sunucularında depolanır ve bu kısmı tekrar gönderdiğinizde indirimli olarak ücretlendirilirsiniz.

Biri donanım olarak satın aldığınız bir bellek, diğeri ise başkasının elinde tuttuğu ve sizden kira bedeli aldığı bir bellektir.

Pratik fark, tanımından daha önemlidir. KV cache kapasiteniz tükenebilir; bu durumda model yüklenmeyi reddeder veya istek geri çevrilir. Prompt cache kapasitesini tüketmeniz mümkün değildir. Yalnızca önbellek isabeti sağlayamayabilirsiniz; bu durumda da sessizce tam ücreti ödersiniz.

KV önbelleğinin içeriği ve varlık nedeni

500 numaralı token'ı üreten bir transformer modeli, kendisinden önceki 499 token'ın tamamına dikkat (attention) göstermek zorundadır. Bu token'ların her biri için her katmanın bir anahtar (key) vektörüne ve bir değer (value) vektörüne ihtiyacı vardır. Her yeni token için bunların tamamını yeniden hesaplamak, üretim süresinin dizi uzunluğunun karesiyle orantılı olarak artmasına neden olur; bu nedenle çalışma zamanı (runtime) bunları saklar. Bu depolama alanı KV cache (anahtar/değer önbelleği) olarak adlandırılır.

Bu, istek bazlı bir durumdur çünkü ilgili isteğin tam token dizisinden oluşturulur. Farklı istemler (prompt) gönderen iki kullanıcı, çalışma zamanı daha sonra açıklanacak ayrı bir özellik olan prefix caching (önek önbellekleme) yapmadığı sürece bu önbelleği paylaşamaz.

Sunum işlemi iki aşamada gerçekleşir. Prefill (ön doldurma) aşaması, isteminizin tamamını okur ve önbelleği doldurur; bu aşama işlem gücü ile sınırlıdır. Decode (kod çözme) aşaması ise her seferinde bir token üretir ve bunu önbelleğe ekler; bu aşama bellek bant genişliği ile sınırlıdır. İstem işleme ve token üretimi hızlarının farklı raporlanmasının nedeni bu ayrımdır; kendi sunucunuzda saniyedeki token sayısını ölçerken bunu görebilirsiniz.

KV önbelleği ne kadar bellek kullanır?

Bir üretici tablosu aramanıza gerek yoktur. Boyut, herhangi bir model için yeniden hesaplayabileceğiniz aritmetik bir işlemdir:

bytes per token = 2 * layers * kv_heads * head_dim * bytes per element

Buradaki 2 sayısı, anahtar (key) ve değer (value) çiftini temsil eder. Diğer tüm sayılar, modelin Hugging Face sayfasında yayınlanan config.json değerinden gelir.

Llama 3.1 8B modelini ele alalım. Yapılandırmasında num_hidden_layers 32 ve num_key_value_heads 8 olarak listelenmiştir. 4096 olan hidden_size değerinin 32 dikkat kafasına (attention head) dağıtılması, 128'lik bir kafa boyutu sağlar. f16 formatında her bir öğe 2 bayttır:

2 * 32 * 8 * 128 * 2 = 131072 bytes = 128 KiB per token

Bu değeri talep ettiğiniz bağlam (context) uzunluğuyla ve ardından aynı anda çalıştırdığınız istek sayısıyla çarpın.

[
  {
    "label": "2k context",
    "one_request_gib": 0.25,
    "four_requests_gib": 1
  },
  {
    "label": "8k context",
    "one_request_gib": 1,
    "four_requests_gib": 4
  },
  {
    "label": "32k context",
    "one_request_gib": 4,
    "four_requests_gib": 16
  },
  {
    "label": "128k context",
    "one_request_gib": 16,
    "four_requests_gib": 64
  }
]

8k bağlam uzunluğunda önbellek 1 GiB'dir. 32k bağlamda bu değer 4 GiB olur; bu da 4-bit ağırlıkların kendisiyle aynı aralıktadır. Modelin tam 128k bağlam kapasitesinde, tek bir istek için 16 GiB, her biri önbelleği dolduran dört istek için ise 64 GiB yer kaplar. Ağırlıklar değişmemiştir, sadece önbellek miktarı artmıştır.

Grouped query attention (GQA) bu rakam üzerinde büyük bir etkiye sahiptir. Llama 3.1 8B, 32 sorgu kafasına hizmet eden 8 anahtar/değer kafasına sahiptir; yani dört sorgu kafası, depolanan tek bir anahtar/değer çiftini paylaşır. num_key_value_heads değeri num_attention_heads değerine eşit olan bir model, aynı parametre sayısında dört kat daha fazla önbellek kullanır. İki farklı 8B modelinin sunum maliyetinin aynı olduğunu varsaymadan önce bu alanı mutlaka kontrol edin.

2k'da çalışan bir modelin 32k'da yüklenmeyi reddetme nedeni

Çalışma zamanı, model yüklendiğinde KV önbelleğini (KV cache), gönderdiğiniz isteme göre değil, yapılandırdığınız bağlam uzunluğuna (context length) göre boyutlandırarak rezerve eder. Ollama'nın varsayılan bağlam penceresi 4096 belirteçtir (token). Bunu 32k'ya yükselttiğinizde, henüz tek bir belirteç bile gelmeden 4 GiB ek bellek tahsisi talep etmiş olursunuz.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Etkileşimli istemden, oturum başına aynı ayar:

ollama run llama3.1:8b
/set parameter num_ctx 32768

Hata, her yığında farklı görünür. vLLM, başlatma sırasında aritmetik hesaplamayı kontrol eder ve çalışmayı reddeder:

ValueError: The model's max seq len (131072) is larger than the maximum number of tokens that can be stored in KV cache (78336). Try increasing `gpu_memory_utilization` or decreasing `max_model_len` when initializing the engine.

Yalnızca CPU kullanan bir VPS üzerinde böyle bir kontrol yoktur, çünkü tahsis edilen alan standart sistem RAM'idir. Çekirdeğin bellek yetersizliği sonlandırıcısı (OOM killer) süreci durdurur ve kanıtları çekirdek halka arabelleğinde (kernel ring buffer) bırakır:

dmesg -T | grep -i "killed process"

Sunum sürecinizi adlandıran bir satır, sunucunun sahip olduğundan daha fazla bellek vaat ettiği anlamına gelir. Çözüm, daha büyük bir swap dosyası değil, daha küçük bir bağlamdır: diske sayfalanmış bir KV önbelleği, oluşturulan her bir belirteçte okunduğu için üretim hızı kullanılamayacak kadar yavaşlar. Mantıklı bir sayı seçimi, Ollama'da num_ctx ve bağlam uzunluğu rehberimizde ele alınmıştır.

Eşzamanlılığın sayı üzerindeki etkisi

İşlem halindeki her istek kendi KV önbelleğini taşır. Kapasite planlarının çoğunda gözden kaçırılan nokta budur. Her biri 32k bağlam tutan dört kullanıcı, ağırlıkların üzerine ek olarak toplamda 16 GiB bellek gerektirir.

Çalışma zamanları (runtime) bu konuda farklı katılık seviyelerine sahiptir. Ollama ve llama.cpp, model yüklendiğinde talep edilen bağlamı rezerve eder; bu nedenle bellek, birisi kullansa da kullanmasa da tahsis edilmiş olur. vLLM ise havuzu sabit boyutlu bloklara böler ve her istek büyüdükçe bu blokları dağıtır; böylece 500 token'lık bir istek yalnızca 500 token'lık yer kaplar. Her iki durumda da havuz sınırlıdır ve dolduğunda yeni istekler çalışmak yerine kuyruğa alınır. Bu kuyruğa almanın yanıt sürelerini nasıl etkilediği kendi kendine barındırılan bir LLM'in kaç eşzamanlı kullanıcıya hizmet verebileceği konusunda detaylandırılmıştır.

KV önbelleğini küçültmenin dört yolu

1. Bağlam uzunluğunu (context length) düşürün. Bu en etkili yöntemdir ve genellikle en düşük maliyetlisidir. Çoğu sohbet iş yükü 32k sınırına asla yaklaşmaz.
2. Önbelleğin kendisini nicemleyin (quantise). Ollama'nın OLLAMA_KV_CACHE_TYPE varsayılanı f16 değeridir; bellek kullanımını yaklaşık yarıya indiren q8_0 ve dörtte bire indiren q4_0 seçeneklerini de destekler. llama.cpp tarafındaki karşılıkları -ctk q8_0 ve -ctv q8_0 şeklindedir.
3. Daha az anahtar/değer (key/value) başlığına veya daha az katmana sahip bir model seçin. 40 GB ağırlık indirmeden önce config.json belgesini okuyun.
4. Aynı anda daha az istek sunun ve geri kalanını kuyruğa alın.

q4_0 seviyesinde Llama 3.1 8B figürü, token başına 128 KiB değerinden yaklaşık 32 KiB değerine düşer; böylece 32k bağlam, 4 GiB yerine yaklaşık 1 GiB maliyet oluşturur. Bu tasarruf bedelsiz değildir. Anahtarlar ve değerler daha düşük hassasiyetle saklandığından, kalıcı hale getirmeden önce kendi istemlerinizle çıktıları karşılaştırın.

Sağlayıcı istem önbelleğe almanın gerçek getirisi

Sağlayıcı istem önbelleğe alma (provider prompt caching), farklı bir birim maliyet yapısına sahip ayrı bir üründür. Sabit bir önek (prefix) belirlersiniz, sağlayıcı bunu depolar ve aynı öneki içeren sonraki çağrılar, tam girdi fiyatı yerine indirimli bir oranda ücretlendirilir.

Ağustos 2026 itibarıyla Anthropic tarafından yayınlanan çarpanlar şöyledir: 5 dakikalık önbellek yazma işlemi, temel girdi token fiyatının 1,25 katına mal olur. 1 saatlik yazma işlemi 2 katına, önbellekten okuma işlemi ise 0,1 katına mal olur. Bu rakamları 20.000 token'lık bir sistem istemine uyguladığınızda, anlaşmanın yapısı netleşir.

[
  {
    "label": "No caching, every call",
    "billed_token_equivalents": "20,000"
  },
  {
    "label": "First call, 5 minute cache write",
    "billed_token_equivalents": "25,000"
  },
  {
    "label": "First call, 1 hour cache write",
    "billed_token_equivalents": "40,000"
  },
  {
    "label": "Every later call, cache hit",
    "billed_token_equivalents": "2,000"
  }
]

Bunu aritmetik bir hesap olarak değerlendirin. 5 dakikalık yazma primi, ilk çağrıda 5.000 token eşdeğeridir: Önbelleksiz gönderim için 20,000 yerine 25,000 ödenir. Süre içindeki her sonraki çağrı, 20,000 yerine 2,000 üzerinden ücretlendirilir; bu da 18.000 token'lık bir tasarruf sağlar. Dolayısıyla 5 dakikalık önbellek, ikinci çağrıdan itibaren kâra geçer.

1 saatlik önbellek farklı bir stratejidir. Yazma işleminde 40,000 tutarında, yani 20.000 token eşdeğeri bir prim ücretlendirilir; bu yüzden kâra geçmesi için bir saat içinde iki başarılı isabet (hit) gerekir. Bu, modelle ilgili değil, trafik düzeninizle ilgili bir sorudur. Pencere seçiminin nasıl yapılacağını da içeren tam hesaplama Claude istem önbelleğe alma için başa baş noktası hesaplaması bölümündedir.

Önbelleğe ulaşıp ulaşmadığınızı iki detay belirler. Birincisi, modelin minimum uzunluğunun altındaki bir önek sessizce önbelleğe alınmaz: Ağustos 2026 itibarıyla belgelenen minimum uzunluk Claude Opus 5 için 512 token, Claude Sonnet 5 için 1.024 token'dır; daha kısa istekler hata döndürülmeden normal şekilde işlenir. İkincisi, yaşam süresi girişi yazan veya okuyan isteğin başlangıcından itibaren ölçülür ve her okuma işlemi, ek bir maliyet olmaksızın süreyi yeniler. Bu nedenle yoğun bir uç nokta, 5 dakikalık bir önbelleği süresiz olarak canlı tutar. Her on dakikada bir çağrılan bir uç nokta ise her seferinde yazma primini öder ve hiçbir tasarruf sağlayamaz.

Varsayımda bulunmak yerine yanıtı kontrol edin. usage nesnesi cache_creation_input_tokens ve cache_read_input_tokens değerlerini raporlar. Her çağrıda sıfır okuma sayısı görmeniz, yazma işlemi için ödeme yaptığınız ancak karşılığında hiçbir şey almadığınız anlamına gelir.

İki önbelleğin kesiştiği nokta

Uzun bir sistem istemi (system prompt), bu iki kavramın buluştuğu yerdir ve her iki tarafta da eş zamanlı olarak maliyet oluşturur.

Yerel tarafta, 20.000 token'lık bir sistem istemi, f16 hassasiyetinde bir Llama 3.1 8B sunucusunda yaklaşık 2.4 GiB KV önbelleği kaplar ve bunu, istemi içeren her eş zamanlı istek için ayrı ayrı yapar. Uzak tarafta ise aynı önek (prefix), bir kez önbellek yazma maliyeti oluşturur ve sonraki her çağrıda girdi boyutunun 0.1 katı kadar maliyet yaratır. Yerel maliyet kullanıcı sayınızla ölçeklenirken, uzak maliyet trafiğinizle ölçeklenir ve boşta kaldığınız sürelerde sıfırlanır.

Yerel tarafta, sağlayıcı tarafındaki istem önbelleğe alma (prompt caching) özelliğiyle sürekli karıştırılan bir özellik bulunur: önek önbelleğe alma (prefix caching). vLLM dokümantasyonu, otomatik önek önbelleğe almayı "mevcut sorguların KV önbelleğini saklayarak, yeni bir sorgunun aynı öneki paylaşması durumunda KV önbelleğini doğrudan yeniden kullanabilmesi" şeklinde tanımlar. llama.cpp sunucusu varsayılan olarak her yuva (slot) için bir istem önbelleği tutar ve --cache-reuse N, yeniden kullanmaya çalışacağı en küçük parçayı belirler.

Önek önbelleğe almanın sağladığı tasarruf, ön dolum (prefill) hesaplama maliyetidir. 20.000 token'lık sistem isteminiz her istekte değil, yalnızca bir kez işlenir; bu da ilk token'a ulaşma süresini ciddi oranda kısaltır. vLLM'de paylaşılan bloklar kopyalanmak yerine yeniden kullanıldığı için bellek kullanımı da iyileşir. Bu yöntem, halihazırda aktif olan token'lar için tutmanız gereken önbelleği asla küçültmez. Ağırlıkların istekler arasında bellekte tutulması, bununla ilişkili ancak ayrı bir yöntemdir ve bir Ollama modelini istekler arasında yüklü tutma konusunda ele alınmıştır.

Kendi sunucunuzda neleri ölçmelisiniz

Modeli hedef bağlamınızda yükleyin ve tahminlere güvenmek yerine gerçek değerleri okuyun.

ollama ps
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
free -g

ollama ps, yüklenen modeli boyutuyla birlikte listeler ve GPU üzerinde mi yoksa CPU üzerinde mi çalıştığını belirtir. Tamamının GPU üzerinde çalışmasını beklediğiniz bir model CPU üzerinde bir bölümleme bildiriyorsa, KV cache bir kısmını dışarı itmiş demektir ve üretim hızı buna bağlı olarak düşecektir. nvidia-smi gerçek VRAM değerini verir, free -g ise yalnızca CPU kullanılan bir VPS üzerinde aynı işi yapar. Bağlamı kademeli olarak artırın, yeniden yükleyin ve sayının değişimini izleyin. Sizin yaptığınız hesaplama ile bildirilen değer birbirine yakın olmalıdır. Uyuşmazlık durumunda aradaki fark, genellikle formüldeki bir hatadan ziyade çalışma zamanının kendi hesaplama arabelleklerinden kaynaklanır.

Bu sayılar sizi kiralamak istemediğiniz bir donanıma yönlendiriyorsa, token başına ödeme ile karşılaştırma GPU VPS ile API token karşılaştırması bölümünde açıklanmıştır.

FAQ

KV cache ile prompt caching aynı şey midir?

Hayır. KV cache, servis süreci içinde her istek için ayrılan ve mevcut bağlamdaki her token'a ait anahtar ve değer vektörlerini tutan bellektir. RAM veya VRAM üzerinde bulunur ve istek sona erdiğinde serbest bırakılır. Sağlayıcı tarafındaki prompt caching ise, sabit bir prompt önekini sağlayıcının altyapısında saklayan ve bu öneki tekrar gönderdiğinizde indirimli ücret uygulayan bir faturalandırma özelliğidir. KV cache'in tükenmesi modelin yüklenmesini engeller. Prompt cache'in kullanılamaması ise yalnızca faturanızı ve ilk token'a ulaşma sürenizi artırır.

Modelim neden 2k bağlamda yükleniyor da 32k'da hata veriyor?

Çünkü çalışma zamanı, gönderdiğiniz prompt'a göre değil, yapılandırdığınız bağlam uzunluğuna göre KV cache'in tamamını yükleme anında ayırır. Llama 3.1 8B modeli f16 formatında token başına 128 KiB yer kaplar; dolayısıyla 2k bağlam 0.25 GiB, 32k bağlam ise 4 GiB maliyet oluşturur. Model ağırlıkları her iki durumda da sığar ancak ayrılan bellek miktarı yetersiz kalır. vLLM bu durumu, depolayabileceği maksimum token sayısını belirten bir ValueError ile raporlar ve gpu_memory_utilization değerini artırmanızı veya max_model_len değerini düşürmenizi önerir. Yalnızca CPU kullanılan bir sunucuda ise çekirdeğin bellek yetersizliği sonlandırıcısı (OOM killer) süreci durdurur; bunu dmesg -T | grep -i "killed process" ile doğrulayabilirsiniz.

Modelim için KV cache boyutunu nasıl hesaplarım?

Katman sayısını, anahtar/değer başlıklarının sayısını, başlık boyutunu ve eleman başına düşen bayt miktarını 2 ile çarpın. Bu işlem token başına düşen bayt miktarını verir. Ardından bu sonucu bağlam uzunluğunuz ve eşzamanlı istek sayınızla çarpın. Katman ve başlık sayılarını modelin config.json dosyasından okuyun. f16 veya bf16 için eleman başına 2 bayt kullanın. q8_0 cache bunun yaklaşık yarısı, q4_0 ise yaklaşık dörtte biri kadardır.

Prompt caching kendi sunucumun bellek ihtiyacını azaltır mı?

Sağlayıcı tarafındaki prompt caching donanımınız üzerinde bir etki yaratmaz, çünkü depolama sağlayıcının tarafında gerçekleşir. Bunun yerel karşılığı, hem vLLM hem de llama.cpp sunucusu tarafından sunulan prefix caching özelliğidir. Bu özellik, paylaşılan bir önek için önceden hesaplanmış anahtar ve değer vektörlerini yeniden kullanarak prefill hesaplama yükünü azaltır ve ilk token'a ulaşma süresini kısaltır. vLLM'de paylaşılan bloklar kopyalanmak yerine yeniden kullanıldığı için bellek kullanımı da iyileşir. Ancak bu özelliklerin hiçbiri, o an işlenmekte olan token'lar için gereken cache miktarını küçültmez; dolayısıyla bağlam ve eşzamanlılık hesaplamalarınız alt sınırı belirlemeye devam eder.

Sadece bir kez gönderdiğim bir prompt'u önbelleğe almaya değer mi?

Hayır. Ağustos 2026 itibarıyla 5 dakikalık seçenek için bir cache yazma işlemi, temel ücretin 1,25 katı maliyetindedir; bu nedenle pencere süresi içinde tekrar göndermediğiniz bir önek doğrudan zarar demektir. Önbelleğe alma işlemi, uzun bir sistem prompt'u veya hakkında birkaç soru soracağınız bir belge gibi aynı önekin tekrarlandığı durumlarda kazanç sağlar. Yazma ücreti ödemek yerine isabet (hit) aldığınızı doğrulamak için API yanıtındaki cache_read_input_tokens değerini kontrol edin.