Prompt Caching Nedir ve API Maliyetini Nasıl Düşürür?

Prompt caching kullanılmadığında, 10. tura gelindiğinde geçmiş tüm adımların toplam token'ı kümülatif olarak katlanarak faturalandırılır. Prompt caching uygulandığında ise, önceki turların oluşturduğu sohbet geçmişi önbelleğe alınmış bir prefix olarak kabul edilir. Model her yeni adımda yalnızca son eklenen araç çıktısını veya kullanıcı mesajını ücretlendirir. Bu, otonom ajanların maliyet engelini kırarak karmaşık iş süreçlerinin otomatikleştirilmesini mümkün kılar.

Popüler Sağlayıcılarda Prompt Caching Entegrasyonu ve Farkları

Büyük dil modeli sağlayıcıları, prompt caching özelliğini farklı entegrasyon yöntemleri ve kullanım politikalarıyla sunmaktadır. Bir geliştiricinin veya teknik ürün yöneticisinin mimari tercih yaparken bu modeller arasındaki operasyonel farkları iyi anlaması gerekir.

OpenAI ve Otomatik Önbelleğe Alma

OpenAI (GPT-4o, GPT-4o-mini ve o1 serisi), prompt caching sürecini tamamen otomatik (implicit / automatic) olarak yönetir. Geliştiricinin API isteği içerisine özel bir parametre veya işaretleyici eklemesine gerek yoktur.

• Eşleşme Kuralı: 1024 token ve üzerindeki girdi dizileri otomatik olarak kontrol edilir.

• Artış Kademeleri: Önbellek 128 token'lık bloklar halinde genişler.

• Cache Süresi (TTL): Önbelleğe alınan bloklar genellikle 5 ila 10 dakika boyunca bellekte tutulur. İstek geldikçe bu süre otomatik olarak uzatılır (en fazla 1 saate kadar).

• Fiyatlandırma: Önbelleğe yazma için ek ücret alınmaz (standart girdi fiyatı geçerlidir); önbellekten okumalarda %50 indirim uygulanır.

• Metrik Takibi: API yanıtındaki usage nesnesi altında yer alan prompt_tokens_details.cached_tokens alanı üzerinden kaç token'ın önbellekten okunduğu doğrulanabilir.

Anthropic Claude ve Manuel Önbellek İşaretleme (Explicit Caching)

Anthropic (Claude 3.5 Sonnet, Claude 3.5 Haiku, Claude 3 Opus), geliştiriciye önbellek üzerinde tam denetim veren manuel (explicit) bir önbellek mimarisi sunar. Bu yöntemde geliştirici, sistem talimatının, araç tanımlarının veya dokümanların tam olarak hangi noktasına kadar önbelleğe alınacağını belirler.

• İşaretleme Yöntemi: İstek gövdesinde (JSON) önbelleğe alınacak bloğun sonuna cache_control: {"type": "ephemeral"} nesnesi eklenir. Bir istek içerisinde en fazla 4 farklı önbellek noktası (cache breakpoint) tanımlanabilir.

• Minimum Eşik: Claude 3.5 Sonnet ve Opus için minimum 1024 token, Claude 3.5 Haiku için minimum 2048 token gereklidir.

• Cache Süresi (TTL): Standart önbellek ömrü 5 dakikadır. İlgili noktaya yapılan her yeni çağrı bu süreyi 5 dakika daha sıfırlar.

• Fiyatlandırma: Önbellek oluşturma (yazma) işlemi standart fiyattan %25 daha pahalıdır ($3.75 / 1M token). Ancak önbellekten okuma işlemi standart fiyata göre **$0.30 / 1M token).

• Metrik Takibi: Yanıt başlığında ve gövdesinde cache_creation_input_tokens ve cache_read_input_tokens alanları yer alır.

{
  "model": "claude-3-5-sonnet-20241022",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Sen şirketimizin kurumsal destek asistanısın. Aşağıdaki 50 sayfalık teknik kılavuz verilerini referans alarak cevap ver: ...[DEVASA METİN]...",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Kullanıcı sorusu buraya gelir."
    }
  ]
}

DeepSeek ve Açık Kaynak / Lokal Çözümler (vLLM, SGLang)

DeepSeek, veri merkezlerinde disk tabanlı ve dağıtık KV önbellekleme mimarilerini agresif biçimde kullanarak sektördeki en rekabetçi fiyatlandırmayı sunmaktadır. DeepSeek-V3 ve R1 modellerinde prompt caching varsayılan olarak aktiftir ve önbellekten okuma birim fiyatı standart fiyatın onda birine ($0.014 / 1M token) kadar inmektedir.

Kendi donanımlarında açık kaynaklı modelleri (Llama 3, Mistral, Qwen vb.) barındıran şirketler için ise vLLM (PagedAttention) ve SGLang (RadixAttention) çıkarım motorları öne çıkar. RadixAttention mimarisi, gelen tüm prompt'ları bir ağaç (radix tree) yapısında saklayarak dinamik olarak prefix eşleşmelerini tespit eder ve GPU belleğindeki KV tensörlerini yeniden kullanır. Bu sayede lokal sunucu maliyetlerinde de benzer verimlilik elde edilebilir.

Prompt Caching Uygularken Dikkat Edilmesi Gereken Riskler ve Sınırlamalar

Prompt caching muazzam maliyet avantajları sunsa da, dikkatli tasarlanmamış bir yazılım mimarisinde beklenen faydayı sağlamayabilir, hatta operasyonel giderleri artırabilir. Bir teknoloji yöneticisinin göz önünde bulundurması gereken kritik kısıtlamalar şunlardır:

Minimum Token Eşikleri ve "Cold Start" Gecikmesi

Her sağlayıcı belirli bir minimum token eşiği uygular. OpenAI ve Anthropic'te bu sınır genellikle 1024 token'dır. 800 token uzunluğundaki bir sistem talimatı için önbellek asla tetiklenmez. Geliştiriciler bazen eşiği aşmak için prompt'a gereksiz dolgu metinleri (padding) ekleme hatasına düşer; bu durum token israfına yol açar.

Ayrıca, önbelleğin ilk kez oluşturulduğu an "Cold Start" (soğuk başlangıç) olarak adlandırılır. İlk istekte hem KV tensörleri hesaplanır hem de belleğe yazma işlemi gerçekleşir. Bu ilk istek, standart bir istekten birkaç yüz milisaniye daha yavaş tamamlanabilir.

Cache Ömrü (TTL) ve Dinamik Prompt Tasarımı Engeli

Önbelleğe alınan verilerin ömrü (Time-to-Live - TTL) genellikle 5 ila 10 dakika ile sınırlıdır. Eğer uygulamanız saatte yalnızca 2-3 istek alan düşük trafikli bir iç araç ise, her gelen istek önbelleğin süresi dolduktan sonra gelecektir. Bu durumda sistem sürekli "Cache Yazma" modunda kalır ve Anthropic gibi sağlayıcılarda %25 ek yazma ücreti ödendiği için toplam API maliyeti düşmek yerine artış gösterebilir.

En yaygın mimari hata ise dinamik değişkenlerin prompt'un yanlış konumuna yerleştirilmesidir:

• Hatalı Tasarım (Cache Bozan):

[Zaman Damgası: 2026-09-07 14:32] + [Kullanıcı ID: 48921] + [5.000 Token Statik Doküman] + [Soru]
_(Zaman damgası her saniye değiştiği için prefix eşleşmesi ilk karakterde bozulur, 5.000 token her defasında sıfırdan hesaplanır.)_

• Doğru Tasarım (Cache Dostu):

[5.000 Token Statik Doküman] + [Zaman Damgası: 2026-09-07 14:32] + [Kullanıcı ID: 48921] + [Soru]
_(İlk 5.000 token sabit kaldığı için başarıyla önbellekten okunur; yalnızca değişen son kısımlar işlenir.)_

Veri Gizliliği, Multi-Tenant İzolasyon ve Güvenlik

Kurumsal LLM entegrasyonlarında veri gizliliği ve yasal uyumluluk (KVKK, GDPR, HIPAA) birinci önceliktir. Şirket yöneticilerinin en sık sorduğu soru şudur: _"Bizim önbelleğe alınan dokümanlarımız başka bir şirketin API çağrısında kullanılabilir mi?"_

Önde gelen ticari sağlayıcıların (OpenAI, Anthropic, Google) güvenlik protokollerine göre önbellek havuzları kesin bir izolasyona tabidir:

1. Organizasyon Düzeyinde İzolasyon: Önbellek anahtarları (cache keys), istemcinin organizasyon kimliği (Organization ID / API Key) ile şifrelenir. A şirketinin önbelleğe aldığı bir metin, B şirketi tamamen aynı metni gönderse dahi B şirketi tarafından erişilemez.

2. Kalıcı Olmayan Bellek (Ephemeral Storage): Önbelleğe alınan veriler kalıcı disklerde saklanmaz, model çıkarım sunucularının geçici RAM/HBM katmanlarında tutulur ve TTL süresi dolduğunda güvenli biçimde silinir.

3. İnsan Denetimi (Human-in-the-Loop) Gerekliliği: Önbellekleme hızı artırsa da modelin çıktı güvenilirliğini garanti etmez. Üretilen kritik iş yanıtlarının doğrulanması için insan denetim süreçleri korunmalıdır.

Kurumsal LLM Projelerinde Prompt Caching Entegrasyon Adımları

Mevcut bir yapay zeka uygulamasını prompt caching uyumlu hale getirmek, yalnızca API parametrelerini değiştirmekten ibaret değildir; prompt yapısının ve veri akışının yeniden organize edilmesini gerektirir. Başarılı bir entegrasyon için aşağıdaki 4 temel adım izlenmelidir:

1. Prompt Hiyerarşisini Yeniden Yapılandırın (Statikten Dinamiğe Sıralama):

Tüm prompt şablonlarınızı gözden geçirin. Veri bileşenlerini değişim sıklığına göre en durağandan en değişkene doğru hiyerarşik olarak dizin:

• _Katman 1 (En Üst - Statik):_ Genel sistem rolü, tonlama kuralları ve katı güvenlik direktifleri.

• _Katman 2 (Orta - Yarı Statik):_ Kurumsal bilgi tabanı dokümanları, ürün katalogları veya few-shot örnekleri.

• _Katman 3 (Alt - Yarı Dinamik):_ Çok turlu sohbet geçmişi (Conversation History).

• _Katman 4 (En Alt - Tam Dinamik):_ Kullanıcının son sorusu, anlık saat/tarih ve tekil kullanıcı parametreleri.

1. Token Eşiklerini ve Trafik Yoğunluğunu Analiz Edin:

Uygulamanızın analitik verilerini inceleyin. Önbelleğe almayı planladığınız statik blokların 1024 token eşiğini geçtiğinden emin olun. Ayrıca uç noktalarınızın (endpoints) çağrı sıklığını ölçün. İstekler arasındaki süre 5 dakikayı aşıyorsa, kullanıcıları tek bir oturumda ardışık sorgulara teşvik eden arayüz tasarımlarına geçin veya sunucu taraflı "keep-alive" (önbelleği sıcak tutma) stratejilerini değerlendirin.

1. Sağlayıcıya Uygun Entegrasyonu Kodlayın:

OpenAI kullanıyorsanız statik blokların istek başında yer almasını garantiye alın. Anthropic kullanıyorsanız en yüksek token hacmine sahip olan bloğun sonuna cache_control parametresini açıkça tanımlayın.

1. Cache Hit Oranını (CHR) ve Finansal Metrikleri İzleyin:

LLMOps izleme araçlarınıza (Langfuse, Helicone, OpenLit veya özel dashboard'lar) cached_tokens ve cache_read_input_tokens metriklerini ekleyin. Temel hedef metriğiniz olan Cache Hit Rate (CHR) değerini takip edin:

Sağlıklı bir kurumsal RAG veya müşteri hizmetleri sisteminde bu oranın %70 ve üzerinde olması beklenir. Oranın %40'ın altına düşmesi, prompt yapısında dinamik verilerin prefix eşleşmesini bozduğunu gösterir.