Prompt caching'i açmak bana hiçbir şey kazandırmadı; hatta OpenAI-API faturam yaklaşık dörtte bir oranında arttı. Suçlu, her istekte değişen tek bir satırdı: sistem istemine (system prompt) gömülmüş bir zaman damgası (timestamp).

LLM sağlayıcıları, token işleme maliyetlerini düşürmek için geliştiricilerin istem parçalarını (prompt fragments) önbelleğe almasına olanak tanır. Bir önbellek okuması ("hit"), normal oranın onda biri kadar düşük bir maliyete sahipken, bir önbellek yazımı ("miss") normal fiyatın yaklaşık 1,25 katına mal olur. Eğer bir yazma işlemi gerçekleşir ancak önbelleğe alınan parça asla okunmazsa, fazladan alınan %25'lik ücret boşa gider. Zaman damgası istemin mevcut herhangi bir önbellek girişiyle eşleşmesini engellediğinde tam olarak bu yaşandı.

Önbelleğe almanın neden ters tepebileceği

Prompt caching, önbelleğe alınan kısmın tam bayt dizilimini eşleştirerek çalışır. Sağlayıcı girdiyi hash'ler; eğer hash, saklanan bir girişle eşleşirse sistem önceki hesaplamayı yeniden kullanır ve ucuz okuma oranını uygular. Herhangi bir değişiklik —tek bir karakter bile— eşleşmeyi bozar ve daha yüksek yazma oranıyla faturalandırılan yeni bir hesaplamayı zorunlu kılar.

Benim durumumda sistem istemi şununla başlıyordu:

Current session started: 2026-07-14T09:41:07Z

Zaman damgası her API çağrısında güncellendiği için isteğin ilk birkaç baytı asla aynı değildi. Sağlayıcı her çağrıyı yeni bir önbellek girişi olarak değerlendirdi, yazma primini tahsil etti ve hiçbir zaman bir okuma kaydetmedi. Sonuç, cache_read_input_tokens sıfırda kalırken cache_creation_input_tokens değerinde sürekli bir artış oldu; bu, önbelleğin asla tetiklenmediğinin (hit olmadığının) açık bir göstergesiydi.

Bozuk bir önbellek nasıl tespit edilir?

API tarafından sağlanan kullanım günlükleri iki ana sayaç sunar:

  • cache_creation_input_tokens – yazma işlemini tetikleyen tokenlar.
  • cache_read_input_tokens – okumadan yararlanan tokenlar.

İlki yükselirken ikincisi sabit kalıyorsa, önbellek yeniden kullanılmıyor demektir. Hızlı bir kontrol yöntemi, aynı isteği iki kez tekrarlamaktır; eğer önbellek düzgün çalışıyorsa, ikinci çağrı okuma tokenlarında bir artış göstermelidir.

Sorunu düzeltme

Çözüm basit: önbelleğe alınan bölgenin çağrılar boyunca statik olduğundan emin olun. Şu iki kuralı izleyin:

  1. Değişmez (immutable) içeriği başa koyun. Sistem istemleri, araç tanımları veya asla değişmeyen herhangi bir talimat, isteğin en başındaki baytları işgal etmelidir.
  2. Değişken (mutable) içeriği sona ekleyin. Zaman damgaları, kullanıcı tarafından oluşturulan metinler, istek kimlikleri (request IDs) veya her çağrıda değişen herhangi bir veri, önbelleğe alınan segmentten sonra gelmelidir.

Tek bir karakter bile kayarsa, hash değişir ve önbellek kaçırma (cache miss) durumu devam eder. Zaman damgasının sonda yer alacağı şekilde istemi yeniden düzenlemek, önbellek isabet oranını (cache hit rate) geri kazandırır ve faturayı beklenen düşük maliyet seviyesine indirir.

Önbelleğe alma gerçekte ne zaman yardımcı olur?

Prompt caching, aynı talimat setinin birçok kez yeniden kullanıldığı senaryolarda parlar:

  • Bir yapay zekanın sabit bir araç setini tekrar tekrar çağırdığı Agent döngüleri (Agent loops).
  • Sadece kullanıcının son sorgusunun değiştiği, uzun ve statik bir belgeye atıfta bulunan Sohbet oturumları (Chat sessions).
  • Aynı ayrıştırma isteminin birçok kayda uygulandığı Toplu veri çıkarma (Bulk data extraction) işlemleri.

Her seferinde yeni bir bağlam içeren tek seferlik (single-shot) çağrılar için —benzersiz bir giriş metni olan tek seferlik bir soru gibi— önbelleğe alma hiçbir fayda sağlamaz ve eğer istek istem dışı bir yazma işlemini tetiklerse maliyeti daha da artırabilir.

Gizli tuzaklar

İstem (prompt) statik olsa bile, istek süreç ilerledikçe (downstream) değiştirilebilir:

  • Sıralamayı değiştiren veya boşluk ekleyen Proxy'ler veya toplayıcılar (aggregators), bayt bayt eşleşmeyi bozabilir.
  • Kimlik doğrulama başlıklarını (authentication headers) başa ekleyen veya JSON formatını değiştiren Geçit servisleri (Gateway services), önbelleğe alınan parçayı istem dışı değiştirebilir.

Geçit üzerinden aynı isteği iki kez gönderip okuma sayaçlarını kontrol ederek test yapmak, önbelleğe alma yolunun bozulmadan kaldığını doğrulamaya yardımcı olur.

Daha geniş maliyet tablosu

Yazma işlemlerindeki %25'lik ek ücret, önbelleğe alma kullanıldığı için verilen bir ceza değildir; parçayı gelecekte yeniden kullanmak üzere saklamak için gereken ekstra hesaplama gücünü yansıtır. Bir önbellek isabeti (cache hit) gerçekleştiğinde maliyet dramatik bir şekilde düşer —genellikle normal oranın çok küçük bir kısmına iner. Önemli olan, sistemin gerçekten önbelleğe erişmesini (hit yapmasını) sağlamaktır. Aksi takdirde, herhangi bir tasarruf sağlamadan bu prim ücretini ödersiniz.

Karşı argüman: önbelleğe alma ölmedi

Bazı geliştiriciler, statik ve dinamik istem bölümlerini yönetmenin karmaşıklığının sağlanan tasarruftan daha ağır bastığını savunuyor. Bu görüş, birçok üretim hattının yapılandırmayı (statik) kullanıcı verisinden (dinamik) halihazırda ayırdığı gerçeğini göz ardı ediyor. İstemleri bu doğrultuda yapılandırarak, API'nin orijinal geliştiricilerine tasarruf sağlayan aynı önbelleğe alma mekanizması, ekstra çaba sarf etmeden kullanılabilir. Buradaki ödün, teknolojideki temel bir kusur değil, istem tasarımında gösterilmesi gereken makul bir disiplindir.

Sırada neye dikkat edilmeli

  • Kullanım panelinizdeki iki önbellek sayacını haftalık olarak izleyin.
  • Herhangi bir değişken öğenin önbelleğe alınan bloktan sonra geldiğinden emin olmak için istem oluşturma sürecini denetleyin.
  • Gerçek tasarrufu ölçmek için temsilci bir iş yükü üzerinde önbelleğe alma ile ve önbelleğe alma olmadan A/B testleri yapın.
  • Herhangi bir proxy öncesi ve sonrası ham istek yüklerini (payload) karşılaştırarak ağ geçidini (gateway) doğrulayın.

Özet

İstem önbelleğe alma, LLM API maliyetlerini ciddi oranda düşürebilir; ancak bu, yalnızca önbelleğe alınan segmentin çağrılar arasında tamamen aynı olması durumunda mümkündür. Bir istemin başında yer alan rastgele bir zaman damgası veya başka bir dinamik belirteç (token), her seferinde maliyetli bir yazma işlemine zorlayarak faturayı kabartır. Statik talimatları başa alıp değişen verileri sona bırakarak, önbelleğin işini yapmasına izin verir ve harcamalarınızı kontrol altında tutarsınız.