LLM Maliyetini Düşürmenin 2026 Rehberi: Prompt Caching, Model Routing, Quantization ve Gözlemlenebilirlik

TL;DR — LLM maliyetini düşürmenin sihirli tek bir düğmesi yok; katmanlı bir oyun bu. En yüksek kaldıraç prompt caching (Anthropic'te tekrar eden girdide %90'a varan indirim). Hemen ardından model routing/cascade geliyor: her işi frontier modele yollamayı bırak, sınıflandırma ve özetlemeyi ucuz modele ver. Asenkron işleri batch API ile yüzde 50 ucuza al. Kendi sunucunda çalışıyorsan quantization (INT8/INT4) ile bellek ve maliyeti yarıya indir, continuous batching + PagedAttention ile aynı GPU'dan 3-5 kat iş çıkar. Ve hepsinin üstüne gözlemlenebilirlik koy; çünkü ölçmediğin maliyeti yönetemezsin. Aşağıda her birini sahadan örneklerle, gerçek 2026 fiyatlarıyla ve KVKK bağlamıyla anlatıyorum.

Son iki yılda masama gelen kurumsal yapay zeka projelerinin neredeyse hepsinde aynı sahneyi yaşadım. Ekip harika bir prototip çıkarıyor, demo herkesi büyülüyor, proje canlıya alınıyor ve üçüncü ayın sonunda finans ekibinden gelen e-posta geliyor: "Bu fatura da ne?"

Gerçek şu ki, bir LLM uygulamasını canlıya almak ile onu kârlı bir şekilde canlıda tutmak iki ayrı meslek. Prototip aşamasında token maliyeti kimsenin umurunda olmuyor; günde birkaç yüz istek atıyorsun, fatura kahve parası kadar. Ama trafik gerçek kullanıcıyla çarpılınca, o masum görünen sistem promptu, her istekte tekrar tekrar işlenen o devasa bağlam penceresi, en basit soruyu bile en pahalı modele yollayan o "hep en iyisini kullanalım" refleksi birikiyor ve aylık fatura beş haneli rakamlara tırmanıyor.

İyi haber: bu maliyetin büyük kısmı israf. Ve israfı temizlemek için modelinizi değiştirmenize, kaliteden ödün vermenize çoğu zaman gerek yok. Sadece doğru mühendislik kararlarını doğru sırayla almanız yeterli. Bu yazıda size sahada uyguladığım, ölçülebilir sonuç veren oyun kitabını veriyorum.

Bir LLM çağrısının faturası iki kalemden oluşur: girdi (input) token'ları ve çıktı (output) token'ları. Çoğu insanın gözden kaçırdığı nokta şu: çoğu üretim uygulamasında parayı çıktı değil, girdi yakar. Çünkü RAG ile beslenen bağlam, uzun sistem promptları, araç (tool) şemaları, geçmiş konuşma — bunların hepsi her istekte tekrar tekrar modele gönderilir.

2026 itibarıyla referans olması açısından güncel Anthropic fiyatları (milyon token başına, girdi/çıktı):

Model	Girdi	Çıktı
Claude Opus 4.8	$5,00	$25,00
Claude Sonnet 4.6	$3,00	$15,00
Claude Haiku 4.5	$1,00	$5,00

Görünüşte küçük rakamlar, değil mi? Ama hesabı ölçeklendirince iş değişir. Diyelim ki bir müşteri destek asistanınız var; her istekte 4.000 token'lık bir sistem promptu + araç şeması, 3.000 token'lık RAG bağlamı ve 1.000 token'lık konuşma geçmişi gönderiyorsunuz. Bu, istek başına ~8.000 girdi token'ı demek. Günde 50.000 istek alıyorsanız:

"

8.000 token × 50.000 istek = 400 milyon girdi token / gün Sonnet 4.6 ile: 400M × ($3 / 1M) = günde $1.200, yani ayda ~$36.000.

Ve bu hesapta çıktı henüz yok. İşte bu noktada "acaba modeli mi değiştirsek" diye düşünmeye başlarsınız. Oysa o 8.000 girdi token'ının belki 7.000'i her istekte birebir aynı. İşte ilk büyük kaldıracımız tam burada.

Prompt caching, 2026'da üretim LLM mühendisliğindeki en yüksek getirili maliyet kaldıracı. Mantığı çok basit: promptunuzun değişmeyen ön eki (sistem promptu, araç şemaları, sabit talimatlar, hatta statik RAG dokümanları) bir kez işlenir, modelin hesapladığı key-value tensörleri saklanır ve sonraki isteklerde o kısım baştan işlenmez. Sadece okunur.

Rakamlar ciddi. Anthropic'te:

• Cache yazma (write): İlk seferinde, normal girdi fiyatından %25 daha pahalı ödersiniz (cache'i oluşturma maliyeti).
• Cache okuma (read): Sonraki her isteğde o token'lar normal fiyatın %90 altında faturalanır.
• Süre: Varsayılan 5 dakika; açık konfigürasyonla 1 saate uzatılabilir.

Somut etkiye bakalım. Yukarıdaki örnekte 8.000 girdi token'ının 7.000'i (sistem promptu + araç şeması + statik bağlam) sabitse:

"

Önbelleksiz: 7.000 token × $3/1M = istek başına $0,021 Önbellekle (okuma): 7.000 token × $0,30/1M = istek başına $0,0021

Yani o 7.000 token için maliyet onda birine düşüyor. Günlük 50.000 istekte bu, sadece bu kısımda günde ~$945, ayda ~$28.000'lik bir tasarruf. Sahada gördüğüm rakamlar literatürle örtüşüyor: prompt caching, API maliyetlerini tipik olarak %45-80 azaltabiliyor ve bir yan bonus olarak ilk token süresini (time-to-first-token) de %13-31 arası iyileştiriyor — yani uygulamanız hem ucuzlar hem hızlanır.

OpenAI tarafında caching otomatik çalışır ama indirim %50 ile sınırlıdır (1.024 token üzeri promptlarda devreye girer). Anthropic'in %90'ı ile arasındaki fark, ağır önbellek kullanan bir üretim yükünde yılda binlerce dolara denk gelebiliyor.

Sahadan pratik notlar:

• Promptunuzu statikten dinamiğe doğru sıralayın. Değişmeyen kısımlar (sistem promptu, araç tanımları, few-shot örnekleri) en başta olmalı ki cache ön eki uzun olsun. Kullanıcının değişen sorusu en sonda.
• Cache'i 5 dakikada bir "sıcak" tutmak için trafik düzeniniz seyrekse, ufak bir keep-alive isteği bile cache miss'i önleyip net tasarruf getirebilir.
• Cache miss'in en sık sebebi: prompt'un başında değişen bir zaman damgası, oturum kimliği veya rastgele bir selamlama. Bu tür dinamik parçaları ön ekten çıkarın.

Provider'ın prompt cache'i prompt'un ön ekini önbelleğe alır. Ama bir de şu var: kullanıcılar aynı şeyi farklı kelimelerle soruyor. "İade politikanız nedir?" ile "Ürünü nasıl geri gönderebilirim?" anlam olarak aynı; klasik cache bunu yakalayamaz çünkü metinler farklı.

İşte burada semantik cache devreye girer. Gelen sorunun embedding'ini (vektörünü) çıkarır, daha önce yanıtladığınız sorularla benzerliğini ölçer ve yeterince yakınsa LLM'i hiç çağırmadan eski yanıtı döner. GPTCache gibi açık kaynak kütüphaneler (Zilliz tarafından geliştirildi) bunu modüler bir mimariyle sunuyor: embedding modeli, vektör deposu, benzerlik değerlendirici ve cache deposu — her biri bağımsızca değiştirilebilir.

Gerçek dünya rakamları cesaret verici: GPTCache, %97'nin üzerinde isabet doğruluğuyla %61-69 cache hit oranlarına ulaşabiliyor. Tek GPU'lu bir yığında %60 hit oranı aylık ~$846 tasarruf anlamına gelebiliyor. Düşünün: gelen isteklerin neredeyse üçte ikisi LLM'e hiç ulaşmıyor; ne token harcanıyor, ne latency oluşuyor.

Benim sahada kurduğum mimari genelde üç katmanlı olur ve bu katmanlar üst üste biner, çakışmaz:

1. Tam eşleşme (exact) cache — en ucuz, kurması en kolay. Birebir aynı istek mi? Redis'ten dön.
2. Semantik cache — paraphrase'leri yakalar. Embedding benzerliği eşiğin üstünde mi? Eski yanıtı dön.
3. Provider prompt cache — yukarıda anlattığım, cache miss durumunda bile token maliyetini düşüren katman.

Bu üçünü birlikte kullanan iyi tasarlanmış bir ajan, AI faturasını %50-90 aralığında kısabiliyor.

Gördüğüm en yaygın ve en pahalı hata: her şeyi en güçlü modele yollamak. "En iyisi Opus, o zaman hep Opus kullanalım." Bu, çivi çakmak için balyoz kiralamak gibi.

Gerçek üretim trafiğinin büyük kısmı basit işlerden oluşur: niyet sınıflandırma, kısa özetleme, veri çıkarma, format dönüştürme. Bunlar için frontier modele ödeme yapmak para yakmaktır. Model routing, her isteği kalite gereksinimini karşılayan en ucuz yola yönlendirmektir.

Tipik bir routing stratejisi şöyle kurulur:

İş tipi	Model seçimi	Mantık
Sınıflandırma, veri çıkarma, basit format	Haiku 4.5 (veya ucuz açık model)	Düşük zorluk, yüksek hacim, ucuz
Orta seviye akıl yürütme, çoğu RAG yanıtı	Sonnet 4.6	Çoğu üretim işinin varsayılanı
Karmaşık akıl yürütme, kritik kararlar	Opus 4.8	Sadece benchmark ölçülebilir fark gösteriyorsa

İki ana yaklaşım var:

• Routing (yönlendirme): Gelen isteği önce sınıflandırırsınız (genelde ucuz bir model veya basit bir sınıflandırıcıyla), sonra uygun modele yollarsınız.
• Cascade (basamaklama): Önce ucuz modeli denersiniz; yanıtın güveni düşükse veya bir kalite kontrolünden geçmezse bir üst modele yükseltirsiniz. Böylece pahalı modeli yalnızca gerçekten gerektiğinde kullanırsınız.

Burada kritik bir uyarı: Bir router, onu doğrulayan eval kadar iyidir. Routing'i körlemesine kurarsanız, ucuz modele yollanan ama aslında karmaşık olan istekler kalite sorunlarına yol açar ve bu da müşteri kaybı olarak size daha pahalıya patlar. Bu yüzden ben her routing kurulumunda 200-500 temsili sorudan oluşan, kalite etiketli bir hold-out seti oluştururum ve modeli ya da eşikleri her değiştirdiğimde bu eval'i baştan koştururum.

Production'da bunu yönetmek için genelde bir LLM gateway (Helicone, Portkey, LiteLLM gibi) kullanırım; tek bir endpoint'in arkasında routing, fallback, rate limiting ve cache'i merkezi olarak yönetiyor.

Her iş gerçek zamanlı olmak zorunda değil. Gecelik rapor üretimi, toplu doküman sınıflandırma, veri zenginleştirme, değerlendirme (eval) koşuları, içerik moderasyonu — bunlar saniyeler içinde yanıt beklemez.

Hem Anthropic hem OpenAI, asenkron toplu işler için %50 indirim sunuyor. Anthropic'in Message Batches API'si istekleri 24 saat içinde asenkron işliyor ve tüm token'larda (hem girdi hem çıktı) tam yarı fiyat uyguluyor. Yani gerçek zamanlı olması gerekmeyen tüm iş yükünüzü bu hatta taşırsanız, o işin maliyeti otomatik olarak yarıya iner.

En güzel kısım: batch indirimi prompt caching ile istiflenebilir. Tekrar eden girdide %90 indirim + her şeyde %50 batch indirimi üst üste binince, maliyet eğrisi gerçekten dramatik şekilde aşağı kıvrılır.

Şimdiye kadar konuştuğum her şey API üzerinden, yani token başına ödediğiniz senaryolar içindi. Ama bir noktadan sonra — özellikle yüksek ve öngörülebilir hacimde, ya da KVKK/veri egemenliği gereksinimi olan kurumlarda — kendi modelinizi kendi sunucunuzda çalıştırmak hem daha ucuz hem de daha güvenli hale gelir.

İşte burada quantization (niceleme) devreye girer. Modelin ağırlıklarını FP16'dan INT8 veya INT4'e indirirsiniz; bu, bellek kullanımını 2-4 kat azaltır ve inference maliyetini kabaca yarıya düşürürken, orijinal doğruluğun %95-99'unu korur. Pratik etki büyük: 70B'lik bir modeli INT4 ile (örneğin llama.cpp üzerinden) çalıştırdığınızda, 140 GB'lik bir model ~35 GB'a iner; yani çok daha küçük ve ucuz bir GPU'ya sığar.

2026'da bu alan hızla ilerledi. Google'ın TurboQuant'ı (Mart 2026) KV cache'in kendisini değer başına 3 bite sıkıştırarak ölçülebilir doğruluk kaybı olmadan KV cache belleğini 6 kat azaltıyor. TensorRT-LLM, mimariye duyarlı kalibrasyonla FP8 ve INT8 quantization kullanarak H100 ve B200 donanımında saniyedeki token sayısını ciddi ölçüde artırıyor.

Ama quantization tek başına yetmez; serving katmanı da en az o kadar önemli. Burada vLLM gibi motorlar oyunu değiştiriyor:

• PagedAttention: Belleği küçük, yeniden kullanılabilir sayfalara böler; bellek israfını %90'a kadar azaltır (%4'ün altında israfla) ve verimi 2-3 kat artırır.
• Continuous batching: Yeni istekleri devam edenlerle dinamik olarak harmanlar, GPU asla boş kalmaz; aynı donanımda 3-10 kat daha yüksek verim sağlar.
• Speculative decoding: Küçük bir taslak model birden çok token tahmin eder, büyük model bunları tek seferde paralel doğrular; her iterasyonda birden çok token üretilir.

Bunlar üst üste binince, vLLM aynı H100 üzerinde naif bir PyTorch döngüsünden 3-5 kat daha fazla trafiği kaldırabiliyor. Yani GPU'nuzdan sıktığınız her ekstra token, doğrudan birim maliyetinizi düşürüyor.

Maliyet kararı nasıl verilir? Basit bir kural: aylık API faturanız, eşdeğer bir GPU sunucusunun (amortisman + işletme) maliyetini geçmeye başladığında self-hosting'i ciddi ciddi masaya koyun. Düşük hacimde API her zaman daha ucuzdur; yüksek ve istikrarlı hacimde tablo tersine döner.

Türkiye'deki kurumlarla çalışırken maliyet denklemine ikinci bir değişken eklenir: veri egemenliği ve uyum. KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) kapsamında, özel nitelikli kişisel verinin geçerli bir hukuki dayanak olmadan kurum dışına çıkmaması kritik öneme sahip. Bir hukuk bürosu, bir hastane veya bir banka, müşteri dosyalarını ABD merkezli bir API'ye prompt olarak göndermeyi çoğu zaman göze alamaz.

Bu noktada self-hosting + quantization sadece bir maliyet optimizasyonu değil, bir uyum stratejisi haline gelir. Yerel ortamda çalışan, KVKK'ya tam uyumlu bir mimari kurduğunuzda iki kazancı birden elde edersiniz: veri kurum sınırlarını hiç terk etmez ve token bazlı bulut maliyetleri ortadan kalkar. 2026'da gördüğüm trend net: Gartner, 2030'a kadar Avrupa ve Orta Doğu'daki kurumların %75'inden fazlasının jeopolitik riski azaltmak için iş yüklerini coğrafi olarak yerelleştireceğini öngörüyor. Türkiye'deki kurumsal müşterilerimde de bu yönelimi her geçen ay daha net hissediyorum.

Benim önerdiğim pratik orta yol genelde hibrit oluyor: KVKK'ya tabi hassas verileri yerel, quantize edilmiş bir açık model işliyor; hassas veri içermeyen, genel bilgi gerektiren işler ise cache ve routing ile optimize edilmiş bulut API'lerine gidiyor. Böylece hem uyum hem maliyet hem de kalite arasında sağlıklı bir denge kuruluyor.

Şimdiye kadar saydığım her taktik, üstüne gözlemlenebilirlik (observability) koymadığınız sürece havada kalır. Çünkü hangi endpoint'in, hangi kullanıcının, hangi prompt'un parayı yaktığını görmüyorsanız, neyi optimize edeceğinizi de bilemezsiniz.

2026 itibarıyla bu alanda olgunlaşmış birkaç araç var ve her birinin tatlı noktası farklı:

• Langfuse — açık kaynak, detaylı tracing, prompt yönetimi. Kendi sunucunuzda barındırabilmeniz KVKK açısından da bir artı.
• Helicone — en hızlı kurulum. Bir proxy katmanı olarak çalışır; tek satır endpoint değişikliğiyle istek başına maliyet, model dağılımı ve kullanıcı bazlı kırılım verir.
• LangSmith — LangChain/LangGraph kullananlar için en sıkı entegrasyon; ajan yürütmesini görselleştirir, token kullanımı ve maliyeti çağrı bazında yakalar.
• LiteLLM, Portkey — gateway tarafında çoklu sağlayıcı maliyet atfı ve enforcement.

Sahada gördüğüm en sağlam kurulum genelde 2-3 aracın kombinasyonu oluyor: hızlı maliyet takibi için bir gateway (Helicone/Portkey), derin tracing için bir tracing aracı (Langfuse/Phoenix) ve mevcut APM yığınınıza bağlamak için OpenLLMetry gibi bir köprü.

Mutlaka izlemeniz gerekenler: prompt seviyesinde trace'ler, latency, token kullanımı ve maliyet, kullanıcı oturumları ve hata/başarısızlık desenleri. Bunları kullanıcı, endpoint ve model bazında kırabildiğinizde, faturanın %80'ini yakan o %5'lik trafiği tespit etmek dakikalar sürer. Genelde sürpriz bir şey çıkar: tek bir kötü yazılmış sorgu, tek bir cache miss'e düşen endpoint, ya da test ortamında unutulmuş bir döngü.

İşte sahada uyguladığım, etkiye ve uygulama zorluğuna göre sıralanmış oyun kitabı:

Taktik	Tipik tasarruf	Uygulama zorluğu	Ne zaman başla
Prompt caching (provider)	Girdide %45-80	Düşük	Hemen, ilk gün
Statik→dinamik prompt sıralama	Cache verimini katlar	Çok düşük	Caching ile birlikte
Exact + semantik cache	%40-80 (hit oranına bağlı)	Orta	Tekrarlı trafik varsa
Model routing / cascade	%30-70	Orta-yüksek (eval şart)	Trafik çeşitliyse
Batch API (asenkron işler)	%50	Düşük	Gerçek zamanlı olmayan her iş
Quantization + self-host	Birim maliyette ~%50+	Yüksek	Yüksek/istikrarlı hacim, KVKK
Gözlemlenebilirlik	Dolaylı; hepsini görünür kılar	Düşük-orta	En baştan

Dikkat ederseniz tablonun üstündeki hamleler hem ucuz hem yüksek getirili. Benim tavsiyem her zaman aynı: yukarıdan başlayın. Önce caching ve prompt sıralaması (bir günlük iş, devasa getiri), sonra gözlemlenebilirlik (neyi optimize edeceğinizi görmek için), sonra routing ve batch, en sonda — gerçekten gerekiyorsa — quantization ve self-hosting.

Baştaki örneğe dönelim: günde 50.000 istek, istek başına 8.000 girdi token'ı, Sonnet 4.6, aylık ~$36.000 sadece girdide.

Şimdi sırayla optimize edelim:

1. Prompt caching: 8.000 token'ın 7.000'i sabit. O kısım %90 ucuzlar. Sadece bu, girdi maliyetini kabaca dörtte birine indirir → aylık ~$10.000 civarına.
2. Semantik cache: İsteklerin %40'ı tekrar eden/benzer sorular ise, bu isteklerin önemli kısmı LLM'e hiç gitmez → bir %25-30 daha düşer.
3. Model routing: Trafiğin %50'si aslında basit işler (sınıflandırma, kısa yanıt) ve bunları Haiku'ya yönlendirirsiniz; Haiku, Sonnet'in üçte biri fiyat → bu segmentte ciddi düşüş.
4. Batch: Gecelik analiz/raporlama işlerini batch'e taşırsanız, o iş yükü yarı fiyat.

Bu hamleler tek tek değil, üst üste biner. Sahada bu tarz bir kombinasyonun aylık faturayı beşte birine indirdiğine defalarca tanık oldum — hem de tek bir kullanıcının kaliteden şikayet etmesine fırsat vermeden. Çünkü işin güzel yanı şu: bu optimizasyonların neredeyse hiçbiri kaliteyi düşürmez. Cache, aynı yanıtı döner. Routing, basit işi zaten yeterli olan modele verir. Batch, sadece zamanlamayı değiştirir. Quantization'da bile doğruluğun %95-99'unu korursunuz.

Maliyet optimizasyonu, çoğu insanın sandığı gibi "daha kötüsüne razı olmak" değil. İsrafı temizlemek. Ve bir LLM uygulamasındaki israf miktarı, ilk faturayı gördüğünüzde tahmin ettiğinizden çok daha fazla. Bu rehberdeki katmanları sırasıyla uygulayın, gözlemlenebilirliği en baştan kurun, her routing kararınızı bir eval ile koruyun — gerisi disiplinli mühendislik. Ve unutmayın: Türkiye bağlamında maliyet kararı hiçbir zaman sadece para değildir; KVKK ve veri egemenliği masada olduğu sürece, doğru mimari hem cebinizi hem kurumunuzun hukuki güvenliğini korur.