LLM prompt caching, tekrarlanan bağlam için premium bir API'yi yetersiz kullanılan yerel bir GPU'dan daha ucuz hâle getirebilir. Ancak hiç tasarruf sağlamaması da mümkündür. Belirleyici değişkenler model liste fiyatları değildir. Bunlar prefix yeniden kullanımı, cache-write maliyeti, read indirimleri, sona erme, eviction, kullanım oranı ve başarısız işlerin maliyetidir.
Hedef kitle: LLM platform maliyeti, gecikme süresi veya altyapı kararlarından sorumlu ileri düzey uygulayıcılar.
Pratik kural: GPU kapasitesi satın almadan önce gerçek iş yükünüzde cache read'lerini ve invalidation davranışını ölçün. Yeni bir kurumsal coding-agent vaka çalışması, dikkat çekici %99,3 cache-hit sonucu ile bu noktayı vurguluyor; ancak yazarlar tek bir geliştiriciyi, art arda gelen iki adet 28 günlük dönemi, farklı model ailelerini ve tek bir production codebase'i inceledi. Makaleyi cloud ve yerel sistemler arasında kesin bir hüküm olarak değil, bir ölçüm çağrısı olarak değerlendirin.
LLM prompt caching neyi değiştirir?
Bir LLM, girdiyi iki geniş aşamada işler:
Serving katmanında prefix caching, bir prompt prefix'i için yeniden kullanılabilir attention veya key-value state'lerini saklayabilir. Aynı uygun prefix'e sahip sonraki bir istek, tekrarlanan prefill işinin bir bölümünü atlayabilir. Değişen suffix'in yine işlenmesi gerekir ve model yeni bir yanıt üretmeye devam eder.
Bu ayrım önemlidir. Prompt caching, response caching değildir. Saklanmış bir yanıt döndürmez, çıktıyı kısaltmaz, zayıf bir prompt'u düzeltmez ve uçtan uca daha düşük gecikme süresini garanti etmez. Öncelikle tekrarlanan girdi hesaplamasını hedefler ve çoğu zaman ilk token'a kadar geçen süreyi iyileştirir.
Orijinal Prompt Cache makalesi, yeniden kullanılabilir prompt modüllerini biçimsel hâle getirdi ve prototype time-to-first-token iyileştirmelerinin GPU'larda 8×, CPU'larda ise 60× arasında olduğunu bildirdi. Bunlar makalenin test ettiği modeller, donanım, prompt'lar ve implementation için geçerli sonuçlardır; güncel ticari API'ler için bir tahmin değildir.
%99,3'lük vaka çalışması: dar sınırları olan yararlı kanıt
Temmuz 2026 tarihli bir preprint olan *Inference Economics of Enterprise Coding Agents*, tek bir production monorepo üzerinde art arda gelen iki adet 28 günlük dönemi karşılaştırdı:
Yazarlar LLM telemetry verilerini ve Git history'yi analiz etti. API dönemi için %99,3 prompt-cache hit rate, işlenen milyon token başına 0,573 $ effective API cost ve paylaşılan on-premise allocation için 2,83 $ amortized unit cost bildirdiler. API 16,9 kat daha fazla token işlerken yerel donanımın utilization oranı düşüktü; bu nedenle normalize edilmiş token fiyatları infrastructure sorusunu tek başına yanıtlamaz.
Toplam maliyet sonuçları allocation'a bağlı olarak farklı yönlere işaret ediyor. Makalenin Taiwan-market ve labor varsayımları altında, paylaşılan local capacity tahmini true total cost of ownership'ı %40,1 azalttı. Dedicated local reservation, cached API'den %43,8 daha pahalıydı. Yerel dönem aynı zamanda daha yüksek bir fix-commit ratio ile ilişkilendirildi: %74,9'a karşı %45,9.
Yazarlar neyi ölçtü?
Neyi çıkarsadılar?
Çalışma neyi ortaya koyamaz?
Tasarım non-randomized ve sequential'dı. Codebase, developer, task mix ve çalışma pratikleri dönemler arasında değişmiş olabilir. Model capability, serving stack, harness ve quantization birlikte değişti. İlk yazar hipotezi biliyordu. Fix-commit label, bağımsız bir defect audit değil, bir proxy'dir. Ham production telemetry ve eksiksiz replay environment yayımlanmadı.
Kalıcı sonuç, başlıktaki sayılardan daha dardır: prompt reuse ve GPU utilization, liste fiyatı karşılaştırmalarına hükmedebilir; repair work ise token tasarruflarına hükmedebilir.
Hit rate hesaplamadan önce measurement contract'ı tanımlayın
Payda açıkça belirtilmedikçe “cache hit rate” belirsizdir. Bir dashboard, cached token'ları eligible prefix token'larına bölebilir. Başka bir dashboard, herhangi bir cache read'i olan request'leri tüm request'lere bölebilir. Üçüncüsü ise uncached suffix'i de içeren toplam input'un payı olarak cached token'ları raporlayabilir.
Ayrı metrikler kullanın:
Provider tarafından raporlanan usage field'larını türettiğiniz metriklerden ayrı tutun. Token sayıları model tokenizer'ları ve template'lerle de değişebilir; LLM tokenizer tax açıklaması→, ham karakter sayılarının neden zayıf bir alternatif olduğunu gösteriyor.
Güncel API ve self-hosted davranışı tek tip değildir
Aşağıdaki snapshot 30 Temmuz 2026'da kontrol edilmiştir. Procurement veya billing için kullanmadan önce bağlantılı documentation'ı yeniden kontrol edin.
| Platform | Cache control | Observable signal | Operational constraint |
|---|---|---|---|
| --- | --- | --- | --- |
| OpenAI API | GPT-5.6 implicit ve explicit prompt caching'i destekler | `cached_tokens` ve `cache_write_tokens` | Güncel GPT-5.6 guidance, explicit write'ları uncached input'un 1,25× fiyatından; read'leri indirimli fiyatlandırır |
| Anthropic API | Automatic caching veya explicit block breakpoint'leri | Ayrı cache creation ve read usage bilgileri | Prefix sırası tools, system ve ardından messages'tır; default TTL 5 dakikadır, ücretli 1 saatlik seçenek vardır |
| Gemini Interactions API | Implicit context caching, Gemini 2.5 ve daha yeni modellerde varsayılan olarak etkindir | `usage.total_cached_tokens` | Common content başlangıçta yer almalıdır; güncel minimumlar modele göre 2.048 ile 4.096 token arasında değişir |
| vLLM | Automatic Prefix Caching engine'de etkinleştirilebilir | Engine metrics ve request timing | Capacity, eviction, isolation, upgrade ve observability sorumluluğu ekibinizdedir |
OpenAI'nin güncel model guidance'ı, GPT-5.6 kullanıcılarına explicit write'lar uncached input'tan daha pahalı olduğu için cache write ve read'lerini izlemelerini söylüyor. Anthropic'in prompt-caching documentation'ı, 5 dakikalık write'ların base input'un 1,25×'i, 1 saatlik write'ların 2×'si ve cache read'lerin 0,1×'i olduğunu belgeliyor. Google'ın context-caching guide'ı, implicit caching'in Interactions API'de otomatik olduğunu ve cached token'ların usage içinde raporlandığını söylüyor. vLLM'in Automatic Prefix Caching example'ı, aynı shared-prefix fikrini self-hosted bir engine'de gösteriyor.
Bu implementation'lar taşınabilir bir billing contract'ını değil, ortak bir prensibi paylaşır. Minimum prefix uzunlukları, cache scope'u, retention, storage charge'ları, usage field'ları ve isolation farklı olabilir.
*Infrastructure'ı değiştirmeden önce cache'i ölçün: prefix'i stabilize edin, cold ve warm testleri çalıştırın, invalidation'ı zorlayın, ardından toplam maliyeti karşılaştırın.*
Yeniden kullanılabilir prefix için break-even formülü
Şunları tanımlayalım:
Storage charge'larını göz ardı edersek, request başına ortalama yeniden kullanılabilir-prefix ücreti şöyledir:
`(W + (N - 1) × R) / N`
Caching, bu prefix'i uncached olarak işlemekten daha ucuz olduğunda:
`N > (W - R) / (U - R)`
Bu denklem yeniden kullanılabilir prefix'i izole eder. Değişen suffix'i, output token'larını, minimum cacheable length'i, storage fee'lerini, eviction kaynaklı miss'leri, concurrency etkilerini, engineering labor'ını ve başarısız task'leri kapsamaz.
30 Temmuz 2026 tarihli bir örnekte, Anthropic'in 5 dakikalık multiplier'ları `U = 1`, `W = 1.25` ve `R = 0.1` idi. Yalnızca input için eşik `N > 1.28` olur; yani cache lifetime içinde ikinci kullanım, uygun prefix için daha yüksek write ücretini amorti eder. Bu, toplam iki API call'un caching'i kârlı hâle getirdiği anlamına gelmez. Kısa bir prefix, uzun bir uncached suffix, cache miss veya pahalı bir output tasarrufu ortadan kaldırabilir.
Denklemi cost model'iniz için bir unit test olarak kullanın. Her değişkeni güncel provider contract'ından ve ölçülmüş iş yükünüzden gelen değerlerle değiştirin.
Görünüşte sabit prompt'lar neden cache'i kaçırır?
Çoğu miss modelde değil, prompt construction'da başlar.
Volatile data çok erken görünür
Başlangıca yakın bir timestamp, request ID, random nonce, user name veya yeni retrieval result, ardından gelen her token'ı değiştirir. Stable tools, policies, templates ve reusable documents'ı öne koyun. Request-specific data'yı reusable prefix'ten veya explicit breakpoint'ten sonra taşıyın.
Serialization request'ler arasında değişir
JSON key order, whitespace, tool ordering ve document ordering, aksi hâlde eşdeğer olan bir prefix'i değiştirebilir. Deterministic serialization kullanın. Anlamın izin verdiği yerlerde tool definition'larını ve retrieved document'ları stable identifier'lara göre sıralayın.
Context manager prefix continuity'yi yok eder
Aggressive pruning, input token'larını azaltırken cached prefix'leri geçersiz kılabilir. Haziran 2026 tarihli, geliştirme aşamasındaki bir preprint olan TokenPilot, bunu joint optimization problemi olarak ele alıyor. Yazarları ingestion'ı stabilize ediyor ve context task value'sunu kaybedene kadar eviction'ı erteliyor. İki benchmark ve iki execution mode genelinde, competitive task performance'ı korurken %56 ile %87 arasında cost reduction bildirdiler. Bu sonuçların makalenin workload'ları ve LightMem2 integration'ı dışında replication'a ihtiyacı vardır.
Cache gerçek yük altında sona erer veya eviction'a uğrar
Warm bir local test, TTL sınırlarını ve capacity pressure'ı gizleyebilir. Self-hosted prefix caching, diğer KV-cache sistemleriyle aynı finite-memory gerçekliğini paylaşır. Daha kapsamlı KV-cache eviction guide→, concurrency ve sequence length arttığında reuse'un neden çöktüğünü ele alıyor.
Model veya template değişir
Bir model version'ı, tokenizer, chat template, image detail setting, tool schema veya safety preamble yeni bir prefix oluşturabilir. Release'leri ve prompt migration'larını cache invalidation event'leri olarak ele alın.
Güncel vLLM engineering tartışmaları bu baskıyı gösteriyor. Bir context-aware retention proposal, concurrent agent workload'larının değerli prefix'leri eviction'a uğratabileceğini savunurken, bir semantic KV-cache proposal exact match'lerin ötesinde reuse'u araştırıyor. Bunlar open design discussion'lardır; production guarantee veya adoption measurement değildir.
Reproducible bir prompt-cache testi
Gerçek işler için AI modellerini benchmark etmek→ için kullanacağınız task set'in aynısını kullanın. Cache testi, kontrollü prefix mutation'ları ve infrastructure accounting ekler.
1. Temsili bir workload'u dondurun
Production traffic'ten veya privacy-safe bir replay set'ten 30 ila 100 task seçin. Prefix length, suffix length, output length, tools, documents ve concurrency dağılımının gerçeğini koruyun. Testi çalıştırmadan önce task success'i tanımlayın.
Tek bir uzun demo prompt'u üzerinde optimization yapmayın. Cache-friendly bir support workflow ile cache-hostile bir research workflow'un ekonomisi birbirinin tam tersi olabilir.
2. Stable ve volatile content'i ayırın
Her prompt segment'ini etiketleyin:
Deterministic bir prompt assembler oluşturun. Her request'in yeniden kullanmayı denediği prefix'i tanımlaması için opaque bir prefix version veya keyed hash kaydedin. Secret'ları veya ham customer content'i log'lara koymayın.
3. Kontrollü bir matrix çalıştırın
Her task class için şunları ölçün:
| Trial | Change | Answered question |
|---|---|---|
| --- | --- | --- |
| Cold | Reusable state olmadan yeni prefix | Baseline write veya prefill maliyeti nedir? |
| Warm | Identical eligible prefix | Provider veya engine bir read raporluyor mu? |
| Early mutation | Başlangıç yakınında tek token'ı değiştir | Ne kadar reuse kayboluyor? |
| Late mutation | Yalnızca suffix'i değiştir | Stable prefix yeniden kullanılabilir kalıyor mu? |
| TTL boundary | Expiry öncesi ve sonrası tekrarla | Production traffic ne sıklıkla zamanında ulaşacak? |
| Concurrency | Parallel request'leri adım adım artır | Eviction veya scheduling reuse'u azaltıyor mu? |
| Version change | Model, tools veya template'i değiştir | Hangi deployment'lar cache'i geçersiz kılıyor? |
Tek bir latency sayısı yerine distribution'ları raporlamak için yeterli tekrar yapın. p50 ve p95 time to first token'ı end-to-end latency'den ayrı tutun.
4. Billing ve quality'yi birlikte kaydedin
Şunları yakalayın:
Exact-prefix state reuse, tekrarlanan prefill computation'ını önlemelidir; ancak quality check'i ortadan kaldırmaz. Model, quantization level, routing policy veya serving stack değişikliği, cache mechanism doğru çalışsa bile output quality'yi değiştirebilir.
5. Üç maliyet görünümü hesaplayın
Yerel seçenek sustained utilization'a bağlıysa utilization varsayımını test edin. Bir GPU purchase, spreadsheet her idle hour'ı gelecekteki demand'e atadığı için ekonomik hâle gelmez.
Cloud API, local GPU veya hybrid routing?
Karar nadiren binary'dir.
Şu durumlarda cached API'yi tercih edin
Şu durumlarda shared local capacity'yi tercih edin
Şu durumlarda hybrid routing kullanın
Ücretsiz veya subsidized endpoint'ler prototype'lara yardımcı olabilir; ancak workload accounting ihtiyacını ortadan kaldırmaz. Free AI models API vaka çalışması→, access price ile production reliability'yi ayırmak için yararlı bir başlangıç noktasıdır.
Prompt-cache security kendi testini gerektirir
Caching, data-dependent timing oluşturur: yeniden kullanılan bir prefix, ilk token'ını miss durumundan daha hızlı döndürebilir. Bir ICML 2025 audit'i, gerçek API'leri test etmek için timing measurement kullandı ve çalışma döneminde yedi provider'da cross-user cache sharing kanıtı bildirdi.
Bu sonuç historical ve provider-specific bir kanıttır. Bu servislerin bugün cache'leri nasıl izole ettiğini ortaya koymaz.
Güncel provider'lara ve internal platform owner'larına şunları sorun:
Self-hosted sistemler için cross-tenant timing ve eviction test'lerini dâhil edin. Cache'i debug etmek için reusable sensitive prefix'leri log'lamayın. Hash, token count, version identifier ve policy-safe metadata saklayın.
Karar checklist'i
Yalnızca liste fiyatlarına dayanarak GPU purchase veya API migration'ını onaylamayın. Şunları talep edin:
Prompt caching değerlidir çünkü tekrarlanan context yaygındır. Ancak reuse workload'a özgü olduğu için procurement shortcut olarak risklidir. Prefix'i ölçün, miss'leri ölçün, ardından toplam maliyeti karşılaştırın.
Claim checks
| Important claim | Evidence type | Check and limitation |
|---|---|---|
| --- | --- | --- |
| Coding-agent study %99,3 prompt-cache hit rate bildirdi | Primary research, July 2026 preprint | Tek developer, tek codebase, art arda iki dönem; sonuç taşınabilir değildir |
| Makale, shared local allocation için işlenmiş API token'larında 0,573 $/M ve 2,83 $/M bildirdi | Primary research | API 16,9× daha fazla token işledi ve local utilization düşüktü; total spend ve TCO daha güçlü karşılaştırmalardır |
| Shared local capacity TCO'yu %40,1 azalttı, dedicated capacity ise %43,8 daha pahalıydı | Primary research | Makalenin hardware, allocation, Taiwan-market, labor ve quality varsayımlarına bağlıdır |
| Prefix caching, tekrarlanan prompt segment'leri için attention state'i yeniden kullanır | Peer-reviewed primary research ve official engine docs | Tekrarlanan prefill work'ünü azaltır; decoding ve değişen suffix work'ü devam eder |
| Anthropic'in 5 dakikalık cache write'ları 1,25×, read'leri base input'un 0,1×'idir | Official documentation, 30 Temmuz 2026'da kontrol edildi | Pricing ve desteklenen modeller değişebilir; örnek output, suffix ve storage'ı dışarıda bırakır |
| Gemini implicit caching, Interactions API'de Gemini 2.5 ve daha yeni modeller için varsayılandır | Official documentation, 7 Temmuz 2026'da güncellendi | Minimum token count'ları ve explicit-cache desteği API ve modele göre değişir |
| TokenPilot test edilen ayarlarda %56–%87 cost reduction bildirdi | Primary research, work-in-progress preprint | İki benchmark ve belirli bir integration; bağımsız replication gereklidir |
| Prompt-cache timing, cache scope kullanıcılar arasında geçiyorsa bilgi açığa çıkarabilir | ICML 2025 primary research | Test edilen provider'ların historical audit'i; güncel vendor davranışı çıkarımı yapmayın |