Claude'un %92 cache hit oranına nasıl ulaştığına dair bir vaka çalışması
Bir AI ajanı her adım attığında bir vergi öder.
Her şeyi sıfırdan yeniden okur.
Sistem talimatlarını. Araç tanımlarını. Üç adım önce zaten yüklemiş olduğu proje bağlamını. Hepsini. Her bir adımda.
İşte bu bağlam vergisidir. Ve uzun süreli ajan iş akışları için, genellikle tüm AI altyapınızdaki en pahalı kalemdir.
İşte hesap: 50 adım boyunca çalışan 20.000 token'lık bir system prompt, tam fiyattan faturalanan 1 milyon token gereksiz hesaplama anlamına gelir ve sıfır yeni değer üretir.
Çözüm prompt caching'dir. Ancak onu iyi kullanmak için, perde arkasında gerçekte neler olduğunu anlamanız gerekir.
Değişen ve Değişmeyenle Başlayın
Bir şeyi optimize etmeden önce, bir ajanın isteminin (bağlamının) yapısını net bir şekilde düşünmeniz gerekir.
Ajanınızın gönderdiği her isteğin temelde iki farklı kısmı vardır:
Statik ön ek: Sistem talimatlarını, araç tanımlarını, proje bağlamını, davranış kurallarını içerir. Bu içerik, bir oturumun her adımında aynıdır.
Dinamik kuyruk: Kullanıcı mesajları, araç çıktıları, terminal gözlemleri. Bu, her isteğe özgüdür ve konuşma ilerledikçe büyür.
Bu ayrım her şeydir. Statik ön ek, hiçbir neden yokken yeniden hesapladığınız pahalı kısımdır. Dinamik kuyruk ise gerçekten taze hesaplama gerektiren tek kısımdır.
Prompt caching, statik ön ekin matematiksel durumunu depolayarak çalışır, böylece gelecekteki istekler onu tamamen yeniden hesaplamayı atlayabilir. Bu ön eki bir kez işlemek için ödeme yaparsınız. Sonraki her adım bunun yerine bellekten okur.
Bu Neden İşe Yarar: Bir Transformer Aslında Ne Yapar
Caching'in neden bu kadar etkili olduğunu gerçekten anlamak için, modelin isteminizi okurken içinde neler olduğunu anlamanız gerekir.
Her LLM çıkarım isteğinin iki aşaması vardır:
Aşama 1: Prefill
Modelin tam giriş isteminizi işlediği yerdir. Hesaplama sınırlıdır, yani bağlamınızdaki her token üzerinde yoğun matris çarpımları çalıştırır. Model her şeyi okur ve onun bir temsilini oluşturur. Bu yavaş ve pahalı aşamadır.
Aşama 2: Decode
Modelin çıktı token'larını birer birer oluşturduğu yerdir. Hesaplama sınırlı olmaktan çok bellek sınırlıdır çünkü model ağır hesaplamalar yapmaktan ziyade önceden hesaplanmış durumu okumak için zaman harcar.
Prefill aşaması sırasında transformer, her token için üç vektör oluşturur: Query, Key ve Value. Attention mekanizması, her token'ın dizideki diğer her token ile nasıl ilişkili olduğunu anlamak için bunları kullanır.
İşte kritik içgörü: Key ve Value vektörleri yalnızca kendilerinden önce gelen token'lara bağlıdır. Belirli bir ön ek için hesaplandıktan sonra asla değişmeleri gerekmez.
Aşağıdaki görsel, az önce tartıştığımız şeyi görsel olarak açıklamaktadır:
Önbellekleme olmadan, bu Key-Value tensorları bir istek tamamlandığı anda atılır. Bir sonraki istek sıfırdan başlar ve onları tekrar 20.000 token'ın tamamı için yeniden hesaplar.
KV caching, bu tensorları depolayarak bunu çözer. Altyapı, bunları giriş metninin kriptografik bir hash'i ile indekslenmiş olarak çıkarım sunucularında tutar. Aynı ön ek ile yeni bir istek geldiğinde, hash eşleşir, tensor'lar hemen alınır ve model tüm bu hesaplamayı atlar.
Bu, hesaplama karmaşıklığını üretilen token başına O(n²)'den O(n)'ye düşürür. 50 adım boyunca tekrarlanan 20.000 token'lık bir ön ek için bu muazzam bir azalmadır.
Ekonomisi
Fiyatlandırma yapısını anlamak, bu mimari kararı bu kadar önemli kılan şeydir.
Anthropic'in farklı model ailelerinde caching'i nasıl fiyatlandırdığına bakalım:
Akılda tutulması gereken üç rakam:
- Cache okumaları, temel giriş fiyatının %10'una mal olur, cache'den okunan her token için %90 indirim
- Cache yazmaları, temel giriş fiyatından %25 daha pahalıdır, KV tensor'larını depolamak için küçük bir prim
- Uzatılmış 1 saatlik caching, temel fiyatın 2 katıdır
Hesap yalnızca cache hit oranınız yüksek kalırsa işe yarar. Bu da bizi pratikte bunun nasıl göründüğünün en iyi gerçek dünya örneğine getiriyor.
Claude Code: 30 Dakikalık Bir Oturum İncelemesi
Claude Code tamamen tek bir hedef etrafında inşa edilmiştir: cache'i sıcak tutmak.
Bunun somut olarak ne anlama geldiğini anlamak için, tipik bir 30 dakikalık kodlama oturumunun nasıl göründüğünü adım adım inceleyelim ve tam olarak neyin faturalandığını ve neyin faturalanmadığını takip edelim.
0. Dakika: Oturum Başlangıcı
Claude Code, system prompt'unu ve araç tanımlarını yükler. Ayrıca proje kökünüzdeki, kod tabanını ve kuralları açıklayan CLAUDE.md dosyasını da okur. Bu yük düzenli olarak 20.000 token'ı aşar.
Bu, tüm oturumun en pahalı anıdır. Her token yenidir. Ancak bu maliyeti yalnızca bir kez ödersiniz.
1-5. Dakikalar: İlk Komutlar
İlk talimatınızı yazarsınız, "auth modülüne bak ve iyileştirmeler öner" gibi bir şey.
Claude Code bir Keşif Alt Ajanı gönderir. Kod tabanında gezinir, dosyaları açar, grep komutlarını çalıştırır ve ilgili kodun bir resmini oluşturur. Tüm bunlar dinamik kuyruğa eklenir.
20.000 token'lık statik temel? Zaten cache'te. $3,00/MTok yerine $0,30/MTok'den geri okunuyor. Yalnızca yeni araç çıktıları ve mesajınız için ödeme yapıyorsunuz.
6-15. Dakikalar: Derin Çalışma
Plan Alt Ajanı, Keşif Alt Ajanı'ndan gelen bulguları alır. Claude Code, ham sonuçları olduğu gibi iletmek (bu, dinamik kuyruğu gereksiz yere şişirir) yerine kısa bir özet iletir. Bu, kuyruğu yönetilebilir ve cache'i verimli tutar.
Planlayıcı, yapılandırılmış bir uygulama planı üretir. Siz onu inceler, onaylarsınız ve Claude Code değişiklikleri yapmaya başlar. Bu döngüdeki her adım, 20.000 token'lık ön eki cache'den okur. Her cache hit, TTL'yi sıfırlayarak cache'i gelecek adımlar için sıcak tutar.
16-25. Dakikalar: Yineleme
Ayarlamalar istersiniz. Claude Code yaklaşımını revize eder. Daha fazla araç çağrısı, daha fazla terminal çıktısı. Dinamik kuyruk büyüyor, ancak bu yalnızca bu oturumdaki yeni, benzersiz içeriği temsil eder.
Bu noktada, oturum toplamda yüz binlerce token işlemiştir. Ancak 20.000 token'lık temel, her adımda cache'den okunmuştur.
28. Dakika: /cost Çalıştırma
Önbellekleme olmadan, böyle bir oturum kolayca 2 milyon token'ı geçer. Sonnet 4.5 oranlarında bu yaklaşık $6,00 eder.
Yüksek verimlilikte çalışan önbellekleme ile:
- Token'ların büyük çoğunluğu cache'den $0,30/MTok'den okunur
- Yalnızca yeni dinamik kuyruk token'ları taze olarak hesaplanır
Pratikte, tek bir görevde %80+ maliyet düşüşü beklenir. Şimdi bunu her kullanıcı, her gün ile çarpın.
Özetlemek gerekirse, oturum devam ederken system prompt düzeninin nasıl göründüğü aşağıda açıklanmıştır:
Her Şeyi Bozan Kural
Prompt caching hakkındaki en sezgisel olmayan şey şudur.
1 + 2 = 3. Ama 2 + 1 bir cache miss'tir.
Altyapı, prompt'un hash'ini alır. Hash, kriptografi için bir tanımlayıcıdır. Bu sıradaki herhangi bir şey değişirse, hatta iki öğe farklı bir sıradaysa hash değişir. Cache boştur. Tüm ön ek tam fiyattan yeniden hesaplanır.
Bundan çıkan üç kural:
- Bir oturum sırasında araç eklemeyin veya kaldırmayın. Cache'lenen ön ek araçları içerir. Araçları değiştirmek, ondan sonra gelen her şeyi işe yaramaz hale getirir.
- Oturumun ortasında asla model değiştirmeyin. Cache'ler modele özgüdür. Konuşmanın ortasında daha ucuz bir modele geçmek, tüm cache'in yeniden oluşturulmasını gerektirir.
- Durumu değiştirmek için ön eki asla değiştirmeyin. Bunun yerine Claude Code, sistemi hatırlatan bir etiketi bir sonraki kullanıcı mesajına ekler. Ön ek asla değişmez.
Bu Sizin İçin Ne Anlama Geliyor
Yukarıdaki her şey Claude Code'un caching'i nasıl yönettiğini açıklıyor. Kendi ajanınızı yapıyorsanız aynı kurallar geçerlidir.
İstemlerinizi şu şekilde yapılandırın:
- En üstte sistem talimatları ve kurallar. Ortasında değiştirmeyin.
- İhtiyacınız olacak tüm araçları önceden yükleyin. Eklemeyin veya kaldırmayın.
- Onlardan sonra alınan bağlam ve belgeler. Süre boyunca statik.
- En altta, konuşmanın geçmişi ve araç çıktıları.
Otomatik caching etkinleştirildiğinde, kesme noktası konuşma ilerledikçe otomatik olarak ileriye doğru hareket eder.
Claude Code kendi cache'inden sorumludur. Anthropic az önce API'sine otomatik caching ekledi, böylece siz de kendi ajanınız için aynısını yapabilirsiniz.
Otomatik caching olmadan, token sınırlarının nerede olduğunu hatırlamanız gerekiyordu. Yanlış bir sınır, cache'e ulaşamama anlamına geliyordu.
Bağlam sınırı için sıkıştırma yapmak üzere cache-safe forking kullanın. Aynı system prompt'u, araçları ve konuşmayı kullanın, ardından sıkıştırmayı yeni bir mesaj olarak ekleyin.
Sıkıştırma çağrısı, son çağrıya neredeyse tamamen benzer. Cache'lenen ön ek tekrar kullanılır. Yeni olarak faturalanan tek şey sıkıştırma talimatıdır.
Bir API'nin çalışıp çalışmadığını görmek için, her yanıttaki şu üç alanı izleyin:
- cache_creation_input_tokens: belleğe konulan token'lar
- cache_read_input_tokens: bellekten okunan token'lar
- input_tokens: normal şekilde çalışılan token'lar
Cache verimlilik puanınız, oluşturma token'larına kıyasla okunan token sayısıdır. Bunu, çalışma süresini izlediğiniz gibi izleyin.
Önemli Çıkarımlar
Prompt caching açıp kapatacağınız bir özellik değildir. Etrafında inşa edeceğiniz mimari bir disiplindir.
Claude Code, bunun büyük ölçekte yapıldığında nasıl göründüğünün en iyi örneğidir.
%92 cache hit oranı. %81 maliyet düşüşü.
Ajan yapıyorsanız bu bir plan niteliğindedir. Vergiyi görmezden gelemezsiniz; var. Önemli olan tek şey, bunun için ödeme yapıp yapmadığınız veya ondan kurtulup kurtulmadığınızdır.
