Teknik not
Yapay Zekâda Prompt Caching: Maliyeti ve Gecikmeyi Azaltma Rehberi
Yapay zekâ uygulamalarında uzun sistem talimatları, örnekler, araç tanımları ve JSON şemaları her istekte yeniden gönderildiğinde API maliyeti ve yanıt gecikmesi hızla büyüyebilir. Prompt caching, değişmeyen prompt öneklerini yeniden kullanarak bu yükü azaltmaya yardımcı olan pratik bir optimizasyon yaklaşımıdır. Ancak yalnızca “aynı konuya benzeyen” istekleri değil, sağlayıcının kurallarına göre aynı veya eşleşen prompt başlangıcını yeniden kullanır.
Bu rehberde prompt caching nedir, cache hit ve cache miss nasıl oluşur, prompt yapısı nasıl düzenlenir ve kazanım nasıl ölçülür sorularını uygulamalı biçimde ele alacağım. Konu özellikle destek botu, RAG, AI ajanı ve yüksek trafikli içerik üretim API’leri geliştiren ekipler için önemlidir.
Prompt caching nedir?
Prompt caching, bir yapay zekâ API’sine gönderilen promptun tekrar eden bölümünün sağlayıcı tarafından geçici olarak önbelleğe alınmasıdır. Sonraki istek aynı sabit başlangıçla geldiğinde model, bu kısmı yeniden işlemek yerine önbelleğe alınmış temsilden yararlanabilir. Böylece giriş tokenlarının işlenme süresi ve bazı API’lerde giriş maliyeti azalabilir.
Buradaki kritik kavram prompt önekidir. Önek; sistem talimatlarını, örnekleri, araç tanımlarını, çıktı formatını ve sabit bağlamı içerebilir. Kullanıcıya özel soru, tarih, oturum kimliği veya değişken belge içeriği ise genellikle öneğin sonuna konmalıdır. Önek değiştiğinde sistem bunu yeni bir içerik olarak değerlendirebilir.
Cache hit ve cache miss arasındaki fark
Cache hit, yeni isteğin başlangıç bölümü mevcut önbellek girdisiyle eşleştiğinde oluşur. Cache miss ise eşleşen bir kayıt bulunmadığında ya da istek, önbellekleme için gereken koşulları karşılamadığında gerçekleşir. Cache hit semantik benzerlik anlamına gelmez; iki prompt aynı amaca hizmet etse bile kelime sırası, araç sırası veya şema değişmişse eşleşme bozulabilir.
Basit bir destek botu örneği düşünelim. Her çağrıda aşağıdaki sabit parçalar gönderiliyor olsun:
- Güvenlik ve ton kuralları
- Yanıt formatı ve birkaç örnek
- Arama ve sipariş sorgulama araçlarının tanımları
- JSON çıktı şeması
İlk çağrı bu uzun öneği oluşturur. İkinci çağrıda aynı parçalar aynı sırayla gönderilir, yalnızca müşteri sorusu değişirse cache hit ihtimali yükselir. Sistem talimatına her seferinde güncel saat eklemek, araçların sırasını değiştirmek veya örneklerden birini rastgele yenilemek ise cache miss riskini artırır.
Prompt caching ne kazandırır?
Prompt caching’in iki temel kazanımı vardır: tekrarlanan giriş içeriğinin işlenme gecikmesini azaltmak ve desteklenen modellerde önbelleğe alınan giriş tokenları için daha düşük ücretlendirmeden yararlanmak. Etki, sabit promptun uzunluğuna, trafik yoğunluğuna, modelin önbellek politikasına ve isteklerin ne kadar tutarlı olduğuna bağlıdır.
Bu nedenle sabit bir yüzde tasarruf sözü vermek doğru değildir. Çıktı tokenları, yeni eklenen kullanıcı içeriği ve cache miss olan istekler normal şekilde hesaplanabilir. Prompt caching ayrıca modelin bilgisini güncellemez, RAG aramasının yerine geçmez ve kötü tasarlanmış bir promptu otomatik olarak hızlandırmaz. Kazanım ancak gerçek trafik üzerinden ölçüldüğünde anlaşılır.
Önbelleğe uygun prompt nasıl tasarlanır?
1. Sabit içeriği promptun başına taşıyın
Sistem talimatları, politika metinleri, birkaç atışlı örnekler, araç tanımları ve çıktı şeması gibi tüm ortak bileşenleri başlangıçta tutun. Bu bölüm farklı kullanıcı istekleri arasında aynı kalmalıdır. Özellikle AI ajanlarında function calling araçlarının tanım ve sırası, ortak öneğin bir parçası olarak ele alınmalıdır.
2. Değişken içeriği sona bırakın
Kullanıcı sorusu, konuşma özeti, güncel tarih, oturum bilgisi ve sorgu sonuçları gibi değişkenleri promptun sonuna ekleyin. Değişken veriyi sistem talimatlarının arasına serpiştirmek, her isteğin önekini parçalar ve cache hit oranını düşürür. RAG kullanıyorsanız geri getirilen parçaları da ortak talimatlardan sonra yerleştirin.
3. Sıralamayı ve biçimi sabit tutun
Aynı araçları her çağrıda farklı sırada göndermeyin. JSON şemasında alan sırasını, örneklerin dizilimini ve sistem mesajlarının yapısını mümkün olduğunca koruyun. Gereksiz boşluk, otomatik eklenen tarih bilgisi veya her istekte değişen bir sürüm numarası bile prefix eşleşmesini bozabilir. Bir prompt şablonu ve sürüm numarası kullanmak bu sorunu yönetmeyi kolaylaştırır.
4. Sağlayıcıya özgü önbellek anahtarını bilinçli kullanın
Bazı API’ler aynı iş yüküne ait istekleri yönlendirmeye yardımcı olmak için prompt_cache_key gibi bir alan sunar. Böyle bir alan kullanıyorsanız destek botu, içerik üretimi veya kod asistanı gibi iş yüklerine göre istikrarlı bir anahtar seçin. Bu alanın adı, davranışı ve sınırları sağlayıcıya göre değişebileceği için kullandığınız modelin güncel dokümantasyonunu kontrol edin.
5. Minimum uzunluk ve saklama kurallarını hesaba katın
Önbellekleme her promptta otomatik olarak oluşmaz. Birçok modelde promptun belirli bir token eşiğini geçmesi gerekir; bu eşik ve cache kontrol noktaları modele göre değişebilir. Çok kısa bir sistem mesajında caching beklemek yerine, gerçek uygulamanızın uzun ortak öneği üzerinde test yapın. Önbellek girişlerinin saklanma süresi ve yeniden kullanılabilirliği de sağlayıcının politikasına bağlıdır.
6. Cache hit oranını ölçün
Toplam token sayısı tek başına yeterli bir metrik değildir. API yanıtındaki önbellekten okunan token alanını, toplam giriş tokenlarını ve istek gecikmesini birlikte izleyin. Örneğin OpenAI Responses API’de usage.input_tokens_details.cached_tokens, Chat Completions API’de ise usage.prompt_tokens_details.cached_tokens alanları raporlama için kullanılabilir. Uygulamanızda cache hit oranını, p50 ve p95 gecikmeyi, giriş maliyetini ve cache miss nedenlerini ayrı ayrı takip edin.
Uygulama şablonu
Aşağıdaki örnek, sağlayıcıdan bağımsız bir tasarım fikridir. Gerçek API’de alan adlarını kullandığınız SDK’nın formatına göre uyarlayın:
{
"model": "model-adi",
"prompt_cache_key": "destek-botu-v1",
"input": [
{
"role": "system",
"content": "Sabit güvenlik kuralları, araçlar, örnekler ve çıktı şeması"
},
{
"role": "user",
"content": "Değişken müşteri sorusu ve oturum bağlamı"
}
]
}Bu yapıda sistem mesajının ilk bölümü her çağrıda aynı tutulur. Kullanıcı mesajı ise değişebilir. Prompt şablonunu kod içinde tek bir fonksiyonda üretmek, farklı ekiplerin aynı kuralları yanlışlıkla değiştirmesini önler.
En sık yapılan prompt caching hataları
- Zaman damgasını başa koymak: Her çağrıda değişen saat bilgisi tüm öneği geçersiz kılabilir.
- Rastgele kimlikleri sistem mesajına eklemek: İzleme için gereken request ID’sini değişken bölümde tutun.
- Araç ve şema sırasını değiştirmek: Mantıksal olarak aynı görünen ama farklı sıralanan tanımlar eşleşmeyebilir.
- Cache hit’i garanti sanmak: Önbellek politikası, model ve trafik davranışı sağlayıcı tarafından belirlenir.
- Sadece toplam maliyeti izlemek: cached token, hit oranı ve gecikme ölçülmeden optimizasyonun etkisi anlaşılamaz.
- Özel veriyi ortak öneğe koymak: Kullanıcıya veya kuruma özel verileri yeniden kullanılabilir sabit bölüme taşımadan önce gizlilik ve saklama politikasını değerlendirin.
Ölçülebilir bir test planı
Prompt caching optimizasyonunu canlıya almadan önce küçük bir test matrisi hazırlayın. Aynı sabit önekle farklı kullanıcı soruları gönderin ve cached token değerinin oluşup oluşmadığını kontrol edin. Daha sonra sistem talimatının bir kelimesini, araç sırasını veya şema yapısını değiştirerek cache miss davranışını gözlemleyin.
| Test | Beklenen sonuç | Kontrol edilecek metrik |
|---|---|---|
| Aynı önek, farklı kullanıcı sorusu | Cache hit ihtimali yüksek | cached tokens, p50 gecikme |
| Araçların sırasını değiştirme | Cache miss ihtimali artar | Önek eşleşmesi ve maliyet |
| Çok kısa ortak prompt | Eşik altında kalabilir | Modelin caching koşulları |
| Özel veriyi sabit bölüme koyma | Gizlilik riski | Saklama ve veri izolasyonu |
Testleri tek bir istekle değil, gerçekçi bir dizi çağrıyla yapın. İlk çağrı cache oluşturma maliyetini, sonraki çağrılar ise yeniden kullanımı temsil eder. Trafik arttığında p95 gecikmenin, eşzamanlı isteklerin ve farklı prompt_cache_key değerlerinin sonucu nasıl değiştirdiğini ayrıca ölçün.
Prompt caching, RAG ve fine-tuning aynı şey mi?
Hayır. Prompt caching, tekrar eden prompt parçalarının işlenmesini optimize eder. RAG, güncel veya kuruma özel bilgiyi arayıp prompta ekler. Fine-tuning ise model davranışını örneklerle uyarlamayı hedefler. Bir uygulamada bu yöntemler birlikte kullanılabilir: sabit güvenlik kuralları ve araç şemaları önbelleğe alınırken, RAG sonuçları değişken bölümde tutulabilir.
RAG sistemlerinde belge parçalama ve güvenlik tasarımını da ihmal etmeyin. Sitenizdeki RAG chunking rehberi doğru parçalama yaklaşımını, prompt injection rehberi ise dış içerikten gelen talimat risklerini ele alıyor. Ajan araçları için ayrıca function calling rehberine bakabilirsiniz.
Canlıya almadan önce kontrol listesi
- Sabit talimat, örnek, araç ve şema bölümleri promptun başında mı?
- Kullanıcıya özel ve zamanla değişen veriler promptun sonunda mı?
- Araçların ve JSON alanlarının sırası çağrılar arasında aynı mı?
- Modelin minimum token eşiği ve caching politikasını kontrol ettiniz mi?
- cached tokens, cache hit oranı, p50/p95 gecikme ve giriş maliyeti ölçülüyor mu?
- Özel verilerin önbellekte tutulmasıyla ilgili güvenlik ve saklama değerlendirmesi yapıldı mı?
- Cache miss durumunda uygulamanın doğru ve maliyet kontrollü bir geri dönüşü var mı?
Sonuç
Prompt caching, yapay zekâ uygulamalarında performans ve maliyet optimizasyonu için küçük ama etkili bir tasarım katmanıdır. Başarının anahtarı, ortak prompt önekini istikrarlı tutmak, değişken içeriği sona taşımak ve sonucu gerçek metriklerle ölçmektir. Cache hit oranını yükseltmek için promptu sürekli büyütmek yerine, hangi içeriğin gerçekten ortak olduğunu belirleyin ve gizlilik sınırlarını koruyun.
Başlangıç için bir prompt şablonu oluşturun, sabit ve değişken bölümleri ayırın, birkaç yüz gerçekçi istekle test edin ve API kullanım raporlarını karşılaştırın. Böylece prompt caching’i sihirli bir ayar olarak değil, ölçülebilir bir mühendislik pratiği olarak uygulayabilirsiniz.