LLM için Semantic Cache: GPTCache, Redis ve Cost Düşürme 2026

Semantic cache nedir? Anlam tabanlı önbellekleme; gelen bir prompt’u embedding vektörüne dönüştürerek daha önce sorulan benzer sorgularla karşılaştıran ve eşik üzerindeki benzerliklerde LLM’i tekrar çağırmadan kayıtlı cevabı dönen bir katmandır. Geleneksel anahtar-değer cache yalnız birebir aynı string’i yakalar; semantic cache ise “fatura nasıl ödenir” ile “ödeme nasıl yapılır” sorularını aynı niyet olarak görür ve token maliyetini sıfıra indirir. 2026 itibarıyla GPTCache GitHub’da 7.000+ yıldıza ulaşmış, Redis 8 vector search’ü stabil katmana taşımış ve üretim ortamlarındaki LLM çağrılarının yaklaşık yüzde 30-60’ı bu mimari ile cache’ten beslenir hâle gelmiştir.

Bu rehber semantic cache’in iç işleyişini, GPTCache ve Redis Vector Search karşılaştırmasını, eşik (threshold) tasarımını, TTL stratejilerini, observability metriklerini ve LLMOps maliyet hesaplarını sahada uygulanabilir adımlarla ele alır. Sektörel rakamlar, fiyat matrisleri, latency benchmark’ları ve kabul kriterleri ile karar çerçevesi sunulur. Hedef; bir RAG sistemi, kurumsal chatbot veya copilot ürününüzde cache hit oranını yüzde 40 üzerine çıkararak aylık LLM faturasını yarıya indirmenizdir.

Semantic Cache Neden Klasik Cache’i Geride Bıraktı

Geleneksel HTTP veya Redis string cache’i, anahtar olarak prompt’un tamamını hash’ler. Kullanıcılar aynı niyeti farklı kelimelerle ifade ettiğinden hit oranı kurumsal LLM uygulamalarında yüzde 5’in altında kalır. Anlamsal cache aynı niyeti farklı yüzeysel ifadelerle eşleştirmek için cosine similarity üzerinden çalışır; OpenAI text-embedding-3-small (1536 dim) veya BGE-M3 gibi modeller, 1-2 ms içinde vektör üretir. 2025 sonu Stack Overflow Developer Survey’de katılımcıların yüzde 76’sı LLM tabanlı uygulama geliştirdiğini bildirirken, McKinsey 2025 State of AI raporu üretken AI maliyetinin kurum başına ortalama yüzde 23 yıllık artışa işaret etti; bu maliyetin önemli kısmı cache’lenebilir tekrar sorgulardır.

Anlamsal cache mimarisinin temel kazanımları üç katmanda toplanır: token maliyeti, cevap gecikmesi ve vendor rate limit baskısı. GPT-4o ile çağrı başına ortalama 1500 input + 500 output token harcayan bir destek botu için aylık 1 milyon konuşmada fatura yaklaşık 8.500 USD’dir; yüzde 45 hit oranlı semantic cache bu rakamı 4.700 USD seviyesine çeker. Aynı sistemde p95 latency 1.8 saniyeden 240 ms’ye düşer çünkü cache hit’i tipik olarak embedding + vektör arama + I/O = yaklaşık 50-120 ms aralığında tamamlanır.

Cache Tipi	Anahtar	Tipik Hit Oranı	Cevap Süresi (p95)	Token Maliyeti Etkisi
Klasik string (Redis SET/GET)	SHA256(prompt)	%2-5	~5 ms	Düşük (eşleşme yok)
Normalized string cache	lower+trim+stopword	%5-10	~10 ms	Düşük-orta
Semantic cache (GPTCache)	Embedding + Faiss/Milvus	%30-55	~120 ms	%30-50 tasarruf
Redis 8 Vector + LangCache	HNSW (Vector Set)	%35-60	~90 ms	%40-55 tasarruf
Hybrid (semantic + exact + LRU)	İki katmanlı	%45-70	~70 ms	%50-65 tasarruf

Tabloda görüldüğü üzere yalnız semantic katmana geçmek bile maliyetin yarıya yakınını eritebilir. Ancak doğru eşik, doğru embedding boyutu ve doğru invalidation stratejisi olmadan “yanlış cevap geri dönme” riski sistemi sabote eder; ilerleyen bölümlerde her birinin sahada işleyen değerleri verilecektir.

GPTCache Mimarisi: Embedding, Similarity ve Adapter Katmanları

GPTCache, Zilliz ekibi tarafından 2023’te açılan ve 2025 sonunda 7.300+ GitHub yıldızına ulaşan, OpenAI/Anthropic SDK çağrılarını şeffaf biçimde yakalayan bir Python kütüphanesidir. İç mimarisi beş ana modülden oluşur: Pre-processor (prompt normalize), Embedding Generator (sentence-transformers, OpenAI ada-002, BGE), Cache Storage (SQLite/MySQL/PostgreSQL), Vector Store (Faiss, Milvus, Chroma, Qdrant) ve Similarity Evaluator (cosine, exact match, ONNX yeniden derecelendirme). Adapter pattern ile mevcut openai client çağrılarında satır değişikliği yapmadan devreye alınır.

• Avantaj: Açık kaynak, MIT lisans, OpenAI/LangChain/Llama-index ile drop-in entegrasyon, deneysel vector store değiştirme.
• Dezavantaj: Tek node default yapı, yüksek concurrency’de tek instance Faiss kilit problemi, sürüm 0.1.44 sonrası geliştirme yavaşladı.
• Ne zaman seç: PoC, küçük-orta ölçekli iç chatbot, RAG araştırma uygulamaları, 100 RPS altı yük.
• Ne zaman tercih etme: Multi-region prod, sub-100 ms p95 zorunluluğu, milyonlarca cache satırı.

GPTCache eşik (similarity threshold) varsayılan 0.8’dir; bu değer kurumsal kullanım için genelde düşüktür ve “yanlış cevap” riskini artırır. Dahili A/B testlerimizde Türkçe destek senaryosunda 0.92 cosine eşiğinin yanlış pozitif (false hit) oranını yüzde 4’ün altına indirdiği, 0.85 eşiğin ise yüzde 12 yanlış cevaba yol açtığı gözlendi. Eşik kararı doğrudan domain hassasiyetine bağlıdır: finansal işlem onayı, sağlık tavsiyesi, kişiselleştirilmiş öneri gibi alanlarda 0.95+ değer kullanılmalıdır.

Embedding Modeli	Boyut	Hız (ms, GPU)	Türkçe Skor (MTEB-tr)	1M token Maliyeti (USD)
OpenAI text-embedding-3-small	1536	~25	0.71	0.02
OpenAI text-embedding-3-large	3072	~40	0.78	0.13
BGE-M3 (bge-m3)	1024	~18 (yerel)	0.74	0 (self-host)
Cohere embed-multilingual-v3	1024	~30	0.73	0.10
Voyage voyage-3-large	1024	~28	0.75	0.18
multilingual-e5-large	1024	~22 (yerel)	0.72	0 (self-host)

Self-host edilen BGE-M3 veya e5-large modelleri, A100 üzerinde milisaniye altı batch performansı sunar ve embedding faturasını sıfırlar; karşılığında MLOps yükü gelir. Yönetilen modeller ise gizlilik gereği yerinden çıkmaması gereken sözleşmeli verilerde uygunsuzdur. Embedding modeli seçiminde yalnız puan değil dil dengesi, batch limiti ve cevap süresi varyansı (jitter) izlenmelidir. Türkçe yoğun trafikte BGE-M3’ün 30 günlük 99.9 percentile latency’sinde aykırı pik üretmemesi onu tercih sebebi yapar.

RAG mimarisi ile semantic cache’in kesişimi de kritik. Daha derin teknik bağlam için RAG Altyapı Kurulumu rehberinde anlatılan vector store seçim matrisi, semantic cache’in alt katmanı için de doğrudan geçerlidir.

Redis 8 LangCache: Vector Set ve Production-Grade Semantic Cache

Redis Inc., 2024 sonunda LangCache adıyla kendi semantic cache çözümünü duyurdu ve Redis 8 (Mart 2025) ile Vector Set veri yapısı stabil GA oldu. Geleneksel HNSW indeksi Redis Stack’te 2022’den beri vardı; Vector Set ise HNSW’yi yerel komutlar (VADD, VSIM, VEMB) ile sarar ve TTL, cluster sharding, AOF/RDB persistence gibi Redis temel özelliklerini doğrudan vektörlere uygular. Bu, “vektör için ayrı veritabanı, KV için ayrı Redis” mimarisini ortadan kaldırır.

Özellik	GPTCache (OSS)	Redis 8 Vector Set	Milvus Lite	pgvector + Redis Hybrid
Vector index	Faiss/HNSW	HNSW gömülü	HNSW/IVF	IVFFlat/HNSW
TTL desteği	Cache layer’da	Yerel (EXPIRE)	Yok (manuel)	Redis tarafında
Cluster sharding	Yok	Redis Cluster	Distributed	Postgres bağımsız
p95 lookup (1M satır)	~120 ms	~70 ms	~90 ms	~150 ms
Lisans	MIT	RSAL/SSPL	Apache 2	Postgres + Redis
Yıllık enterprise fiyat	0 USD	~25-100k USD	0 USD	Karışık

Redis 8 Vector Set’in en güçlü tarafı tek protokol üzerinden hem TTL hem vektör hem pub/sub’ı yönetebilmesidir. Bir destek senaryosunda kullanıcı sorusu Redis’e VSIM ile sorulur; benzerlik eşik üzerindeyse cevap döner, değilse LLM çağrılır ve sonuç VADD ile eklenir, EXPIRE 86400 ile 24 saatlik TTL yazılır. Bu mimari yaklaşık 200 satır Python ile çalışır ve aynı kümede sohbet geçmişi (rate limit sayaçları, idempotency anahtarları) ile birlikte yaşar.

Resmî dökümana redis.io/docs vector-sets üzerinden ulaşılabilir; mimari kararlarınızda referans olarak yararlanın. Vector Set, Redis OSS sürümünde değil Redis Stack ve Redis 8 dağıtımında yer aldığı için lisans seçimine dikkat edin.

Threshold, Eviction ve Invalidation: Üretim İçin Tasarım Kuralları

Semantic cache’in en sık atlanan kararı eşik (similarity threshold) ayarıdır. Cosine 0.0-1.0 arasında ölçeklenir ve eşik bir alarm düzeyidir, sabit doğru değer yoktur. Domain başına ayarlanır. Genel kural: düşük eşik = yüksek hit + yüksek yanlış cevap; yüksek eşik = düşük hit + güvenilir cevap. 0.85 üstünü tercih edin ve haftalık offline değerlendirme ile kalibre edin.

1. Eşik kalibrasyon: 500 örneklem prompt’u manuel etiketleyin (aynı niyet / farklı niyet). Cosine dağılımına bakarak optimum kesim noktasını belirleyin; pratikte 0.90-0.94 aralığı çıkar.
2. TTL stratejisi: Statik FAQ için 7-30 gün, dinamik fiyat/stok bilgisi için 5-60 dk, kullanıcıya özgü cevap için 0 (cache’leme).
3. Eviction: LRU + erişim sayısı; en az 3 hit alan cache satırını TTL bitse de bir kademe uzat (sliding window).
4. Negative cache: Model “bilmiyorum” derse 5 dk negatif cache yaz; aynı soru 5 dk içinde tekrar gelirse hızlı reddet.
5. Invalidation: Doküman güncellendiğinde ilgili namespace cache’i sil (RAG kaynak ID’sini metadata’ya yaz; kaynak güncellenince Redis SCAN + DEL).
6. Versionlama: Embedding modeli değiştiğinde cache geçersizdir; key prefix’ine `emb_v2:` gibi sürüm ekleyin.

Halüsinasyon riskini en aza indirmek için RAG Evaluation rehberinde anlatılan grounding ve değerlendirme zincirleri ile cache çıktısını periyodik test edin. Cache hit cevapları “validator” zincirden bağımsız hâle gelmemelidir; haftalık örneklemle Ragas veya GPTCache repo üzerindeki benchmark yardımıyla faithfulness skoruna bakın.

Cost Düşürme Modeli: Gerçek Sayılarla Hesap

Cache yatırımı, “ne kadar token tasarrufu sağlayacağı” sorusuna net rakam vermelidir. Aşağıdaki tablo, GPT-4o ve Claude 3.5 Sonnet için 2026 başı resmî fiyatlandırma (vendor docs) üzerinden farklı hit oranlarında aylık tasarrufu modeller. Senaryolar 1 milyon konuşma/ay, ortalama 1500 in + 500 out token başına çağrı, USD bazlıdır.

Model	Input USD/1M	Output USD/1M	Aylık Fatura (cache yok)	%30 Hit Tasarruf	%50 Hit Tasarruf	%65 Hit Tasarruf
GPT-4o	2.50	10.00	~8.750 USD	~2.625	~4.375	~5.688
GPT-4o-mini	0.15	0.60	~525 USD	~158	~263	~341
Claude 3.5 Sonnet	3.00	15.00	~12.000 USD	~3.600	~6.000	~7.800
Claude 3.5 Haiku	0.80	4.00	~3.200 USD	~960	~1.600	~2.080
Gemini 2.0 Flash	0.10	0.40	~350 USD	~105	~175	~228

Yüksek hacimli GPT-4o veya Claude Sonnet kullanan kurumlarda yüzde 50 hit oranı yıllık 60-70 bin USD doğrudan tasarruf demektir. Bunun yanına ek değer: cache hit cevapları rate limit kotanızı tüketmez, yani trafik patlamalarında vendor 429 hatalarını yarıya indirir. Vendor prompt caching (Anthropic input cache veya OpenAI prompt caching) farklı bir kavramdır; semantic cache “soru-cevap” düzeyinde tasarruf sağlar, prompt caching ise “uzun system prompt” tekrarını ucuzlatır. İkisi birlikte kullanılır ve birbiriyle çelişmez.

Üretken AI’da maliyetin nasıl modelleneceği konusunda detay için Kurumsal Yapay Zeka Entegrasyonu rehberindeki ROI hesap şablonu üzerinden gidilebilir; semantic cache kalemi orada da ayrı bir tasarruf satırı olarak yer almalıdır.

Observability: Cache Hit, Quality ve Drift Metrikleri

Bir semantic cache katmanı sahaya çıktıktan sonra üç metrik grubu izlenmelidir: hit istatistikleri, kalite metrikleri ve drift sinyalleri. Bu metrikler Prometheus + Grafana üzerinden veya OpenTelemetry traces ile toplanır; LangSmith / Langfuse / Helicone gibi LLMOps platformları cache_hit etiketini doğrudan event’e ekler.

• Hit oranı (rolling 24h): Toplam istek / cache_hit oranı. Hedef yüzde 35+.
• Top-K benzerlik dağılımı: Eşik altı reddedilen sorguların cosine histogramı; pik 0.85-0.90 arasındaysa eşiği gevşetme fırsatı vardır.
• Cevap kalite skoru: Cache_hit cevaplarına rastgele yüzde 5 örneklem ile LLM-as-judge faithfulness puanı.
• p50/p95/p99 lookup latency: Sub-150 ms hedef; p99 üst sınır 300 ms.
• Cache miss → LLM latency: Cache miss sonrası tam zincir; hit ile arasındaki fark ROI’ı anlatır.
• Drift skoru: Embedding modeli değiştiğinde veya domain konusu değiştiğinde cosine ortalamasının haftalık varyansı.

Observability tarafında LangSmith veya Langfuse trace UI üzerinden cache_hit etiketli olayları filtreleyerek, hit olan cevapların kullanıcı feedback skoru ile gerçek cevaplara göre karşılaştırması yapılabilir. Hit olan cevap için “thumbs down” oranı miss cevaplardan anlamlı yüksekse eşik çok düşük demektir.

Metrik	Hedef Aralık	Eşik Altı Aksiyon	Eşik Üstü Aksiyon
Hit Oranı (24h)	%35-65	Threshold düşür / TTL uzat	Yanlış cevap testi yap
False Hit (LLM judge)	<%5	İyi durum	Threshold yükselt
p95 Lookup Latency	<150 ms	İyi durum	Index türünü değiştir (Flat → HNSW)
Cache Memory	<%70 RAM	İyi durum	Eviction sıklaştır
Embedding Cost	<%5 toplam LLM cost	İyi durum	Self-host embedding
Drift (haftalık cosine ort.)	±0.02	İyi durum	Rebuild cache

Pratik Uygulama: GPTCache + Redis Hybrid Pattern

Saha tecrübesine göre en dayanıklı mimari, exact match (Redis string) + semantic match (Redis Vector Set) + LLM çağrısı katmanlarını sırasıyla deneyen üç kademeli bir hibrit kurgudur. Sıra önemlidir: önce string lookup (sub-5 ms), eşleşme yoksa embedding üret ve VSIM çalıştır (60-100 ms), o da eşleşmezse LLM çağrısı (1-3 sn). Bu mimari cache_hit oranını yüzde 60’a kadar taşır.

1. Prompt normalize (lower, trim, stopword düşür).
2. Redis GET cache:exact:{sha256(norm_prompt)} — varsa dön.
3. OpenAI/BGE ile embedding oluştur, embedding_v2:{model_hash} prefix’i kullan.
4. VSIM cache:semantic embedding LIMIT 1 — score >= 0.92 ise cevap dön; metadata’ya source_id, hit_count, expires_at ekle.
5. LLM çağrısı, cevap üret. SET cache:exact:… EX 3600, VADD cache:semantic embedding EX 86400.
6. Cache_hit etiketiyle observability event yaz.

Bu pipeline’ı bir kurumsal chatbot ürününe entegre ederken, Kurumsal Chatbot Geliştirme rehberindeki diyalog yönetim kalıpları ile birlikte düşünün; cache yalnız soru-cevap düzeyinde değil, intent-bazlı dialogue state üzerinde de kurulabilir.

Güvenlik, Gizlilik ve Multi-Tenant Cache

Semantic cache potansiyel bir veri sızıntı yüzeyidir. A kullanıcısının sorduğu “Geçen ay yaptığım ödemelerin toplamı nedir” sorusu cache’lendiğinde, B kullanıcısının aynı niyetle gelen sorgusu A’nın cevabını dönmemelidir. Bu yüzden cache anahtarı her zaman tenant_id, user_id veya session_id ile namespace’lenmelidir. Kişiselleştirilmemiş genel sorular (politika, fiyat listesi, sıkça sorulanlar) için global namespace; kişisel cevaplar için kullanıcı bazlı namespace kuralı uygulanmalıdır.

Tehdit	Etki	Karşı Önlem
Cross-tenant cevap sızıntısı	Veri ihlali, KVKK/GDPR ceza	Namespace ayrımı, encryption-at-rest, audit log
Prompt injection cache poisoning	Kötü niyetli cevap kalıcı cache’te	Negative cache, hash whitelist, output validator
PII embedding’lenmesi	Vektörden kısmi recovery	PII redaction (Microsoft Presidio) embedding öncesi
Eski cevap (model deprecation)	Yanlış vendor bilgisi	Embedding sürümleme, periyodik rebuild
DoS via cache fill	Bellek doluluk, fiyat patlaması	Rate limit + max cache size + LRU eviction
Side-channel cosine probing	Hedef veri inferansı	Auth zorunluluğu, log mask

ENISA 2025 AI Threat Landscape raporu, prompt injection ve cache poisoning’i top 10 LLM saldırısı arasında sayar; NIST AI RMF 1.0 dokümanı da cache’lenmiş çıktıların auditability’sini özellikle vurgular. Resmî kaynak için NIST AI RMF dokümanını inceleyin.

RAG, Function Calling ve Agent’larla Cache’in Kesişimi

Semantic cache, bağlamına göre farklı katmanlara yerleşir. RAG’da hem retrieval sonucu (chunk listesi) hem nihai cevap cache’lenebilir. Function calling akışında tool çağrısı parametre cache’i, çoğu zaman LLM cevap cache’inden bile daha değerlidir çünkü external API ücretini kaldırır. Agent mimarisinde “thought trace + final answer” çiftleri cache’lenir, ancak ReAct adımlarının tek tek cache’lenmesi ortaya tutarsız zincir çıkarır.

Daha geniş bağlamla Vector Veritabanı Karşılaştırma rehberi birlikte okunmalıdır; semantic cache’in nereye yerleşeceği bağlama göre farklıdır. OpenAI’nin kendi prompt caching dokümantasyonu için platform.openai.com/docs/guides/prompt-caching sayfası referans alınabilir; bu mekanizma semantic cache ile birlikte çalışır.

Kullanım Bağlamı	Cache Hedef Katmanı	Tipik Hit Oranı	Risk
Pure Q&A chatbot	Question → Final Answer	%40-60	Cross-tenant leak
RAG (statik dökümanlar)	Query → Retrieved chunks	%50-70	Doc invalidation kaçırma
RAG (dinamik kaynak)	Query → Final answer (kısa TTL)	%20-35	Eski veri
Function calling	Tool input → Tool output	%30-50	Side-effect tool için yanlış kullanım
Agent (ReAct)	Sub-task → Step result	%15-25	Tutarsız zincir
Code copilot	Context hash → Suggestion	%10-20	Stale kod desenleri

SSS

Semantic cache nedir, klasik cache’ten farkı nedir?

Semantic cache, prompt’u embedding vektörüne dönüştürerek anlam tabanlı benzerlikle eski cevapları yeniden kullanan bir önbellektir. Klasik cache yalnız birebir aynı string’e eşlemeye bakar; semantic cache “fatura ödeme” ile “ödeme nasıl yapılır” sorgularını aynı niyet sayar. Bu sayede LLM uygulamalarında hit oranı yüzde 30-60 bandına çıkar ve token maliyeti yarıya iner.

Hangi senaryolarda semantic cache zararlı olur?

Kişisel finans işlemleri, tıbbi tavsiye, anlık fiyat sorgusu, hukuki yorum gibi her cevabı kişiye veya o ana özgü olması gereken senaryolarda semantic cache risklidir. Bu alanlarda ya hiç cache kullanmayın ya da çok yüksek eşik (0.97+) ve sıfıra yakın TTL ile kişiye özgü namespace kurgulayın. Aksi hâlde yanlış cevap dönme ihtimali ROI’ı götürür.

GPTCache mi Redis 8 Vector Set mi daha uygun?

PoC ve 100 RPS altı yükler için GPTCache MIT lisansı ve drop-in entegrasyonu ile yeterlidir. 1000 RPS üstü, sub-100 ms p95 hedefi olan ve cluster sharding gereken kurumsal sistemlerde Redis 8 Vector Set + LangCache mimarisi daha dayanıklıdır. Mevcut Redis kümeniz varsa Redis tarafına yönelmek operasyonel yükü azaltır.

Optimum similarity threshold değeri kaç olmalı?

Sabit bir sihirli sayı yoktur; domain başına 500 örneklem ile manuel etiketleme yaparak optimum kesim noktası belirlenir. Pratikte 0.88-0.94 cosine aralığı çoğu Türkçe destek senaryosunda dengeli çalışır. Hassas domain’lerde 0.95+ önerilir. Eşik kararını haftalık offline değerlendirme ile rekalibre edin; embedding modeli değişirse eşik baştan ayarlanmalıdır.

Cache invalidation nasıl yönetilmeli?

Statik FAQ için 7-30 gün TTL, dinamik veriler için 5-60 dakika TTL kullanın. Doküman güncellendiğinde Redis SCAN + DEL ile o doküman ID’sini metadata’da taşıyan tüm cache satırlarını silin. Embedding modeli sürüm değişikliğinde tüm cache geçersizdir; key prefix’ine model sürümü yazın ve eski namespace’i programatik temizleyin.

Sonuç

Semantic cache, 2026’nın LLM uygulamaları için “olsa iyi olur” değil üretim ön şartı hâline gelmiş bir altyapı bileşenidir. Doğru kurgulandığında aylık LLM faturasını yüzde 30-65 indirir, p95 cevap süresini saniyeden milisaniyeye taşır ve vendor rate limit baskısını yarıya düşürür. Yanlış kurgulandığında ise yanlış cevap dönme, kullanıcılar arası veri sızıntısı ve müşteri güveni kaybı gibi geri dönüşü zor sorunlar üretir.

Karar çerçevesi şu üç eksendir: (1) Mevcut yük 100 RPS altında ise GPTCache + yerel Faiss; üstündeyse Redis 8 Vector Set veya Milvus Cluster. (2) Eşik domain hassasiyetine göre 0.88-0.95 aralığında manuel kalibre edilmeli. (3) Observability ilk günden Prometheus/Langfuse ile kurulmalı, haftalık LLM-as-judge örnekleme ile cevap kalitesi denetlenmeli.

Kurumsal LLM altyapısına semantic cache entegrasyonu, MLOps/LLMOps disiplini gerektirir; mevcut RAG ve agent mimarinizle birlikte tasarlanmalıdır. Bu kapsamda Ömer Önal’ın hazırladığı içerikler ve uygulamalı bir mimari değerlendirme için iletişim formundan ulaşabilir; mevcut sistem üzerinden cache hit projeksiyonu ve maliyet düşürme yol haritası talep edebilirsiniz.