LLM Maliyet Optimizasyonu: Token Ekonomisi, Prompt Caching ve Semantic Cache

TL;DR — Son bir yılda danışmanlık yaptığım her kurumda aynı sahneyi yaşadım: proje demo aşamasında büyülüyor, sonra ilk gerçek fatura geliyor ve oda birden sessizleşiyor. LLM maliyeti, doğru kurgulanmadığında sessizce katlanıyor; çünkü token başına fiyat küçük görünse de ölçek çarpanı acımasız. Bu yazıda size token ekonomisinin nasıl işlediğini, çıktı token'larının neden girdi token'larından kat kat pahalı olduğunu, prompt caching ve semantic caching'in faturanızı nasıl yarıya indirebileceğini, model routing ile "ucuz model + pahalı model" stratejisini, batching, prompt sıkıştırma, agent döngülerinin kontrolü ve maliyet gözlemlenebilirliğini pratik örneklerle anlatacağım. Temmuz 2026 sonundaki gerçek fiyat hareketlerini —OpenAI'nin GPT-5.6 "Luna" modelini yüzde 80 indirmesi, Anthropic'in Claude Opus 5'i, DeepSeek V4-Flash ve Google Gemini 3.6 Flash— referans alarak, model seçiminin ve cache stratejisinin bugün elinizdeki en büyük maliyet kaldıracı olduğunu göstereceğim. Sonunda KVKK bağlamında self-hosting ile API kullanımı arasındaki dengeyi ve Türkiye'den bir kurumsal maliyet örneğini de bulacaksınız.

Bir üretim ortamına LLM koyduğunuzda, önce doğruluk ve gecikme üzerine konuşuyoruz. Ama işin sırrı şu: gerçek zorluk, sistem çalışmaya başladıktan üç ay sonra ortaya çıkıyor. Kullanım artıyor, prompt'lar büyüyor, agent'lar daha fazla araç çağırıyor, ve bir bakmışsınız aylık fatura üç katına çıkmış — hiç kimse "kötü bir şey" yapmadan. Ben bunu birden fazla müşterimde gördüm: bir e-ticaret firmasında müşteri destek asistanının aylık maliyeti altı ayda beş kat arttı, çünkü sistem prompt'u sürekli büyüdü ve kimse cache mekanizmasını devreye almadı. Bu yazı, o üç aylık gecikmeli şokun önüne geçmeniz için yazıldı.

Maliyet optimizasyonunu "sonradan eklenecek bir performans ayarı" gibi görmeyin. Bence bu, mimari bir karardır ve en verimli olduğu an, sistemi ilk tasarladığınız andır. Sonradan eklemek de mümkün, ama çok daha zahmetli oluyor çünkü prompt yapınız, agent akışlarınız ve veri modeliniz zaten "cache dostu olmayan" bir şekilde kurulmuş oluyor.

Token ekonomisinin temelini anlamadan hiçbir optimizasyon stratejisi anlamlı olmuyor. Basitçe söyleyeyim: LLM sağlayıcıları neredeyse istisnasız, çıktı (output) token'larını girdi (input) token'larından belirgin şekilde daha pahalıya fiyatlandırıyor — genelde beş ila on kat arasında bir fark görüyorsunuz. Bunun nedeni teknik: girdi token'ları modele bir kere "okutulur" ve paralel olarak işlenebilir; ama çıktı token'ları otoregresif olarak, yani bir öncekine bağlı olarak sırayla üretilir. Her yeni token, modelin tüm önceki bağlamı yeniden değerlendirmesini gerektirir. Bu da hesaplama açısından çok daha pahalı bir iştir, dolayısıyla fiyat da buna yansır.

Bu ayrımın pratik sonucu şudur: bir uygulamanın maliyetini düşürmek istiyorsanız, önce şu soruyu sormalısınız — "Bu sistemde para nereye gidiyor, girdiye mi çıktıya mı?" RAG (retrieval-augmented generation) sistemlerinde genelde girdi hâkimdir, çünkü büyük bağlam pencereleri, belgeler, geçmiş konuşmalar modele sürekli beslenir. Kod üretimi veya uzun rapor yazımı gibi işlerde ise çıktı hâkim olur. İki durumda da uygulanacak strateji farklıdır: girdi ağırlıklı sistemlerde cache'leme kraldır; çıktı ağırlıklı sistemlerde ise çıktı uzunluğunu kısıtlamak, gereksiz "düşünme" adımlarını azaltmak ve doğru modeli seçmek öne çıkar.

Bir de şunu unutmayın: fiyatlandırma tabloları genelde "1 milyon token başına" verilir, ve bu rakam küçük göründüğü için insanlar tehlikeyi hafife alıyor. Ama günde 50 bin kullanıcı isteği alan bir sistemde, her istek 2.000 girdi + 500 çıktı token içeriyorsa, ayda 3.75 milyar token'dan bahsediyorsunuz demektir. O noktada, 1 milyon token başına 1 dolarlık bir fark bile aylık binlerce dolara dönüşür.

2026 yazının sonunda, LLM sağlayıcıları arasında gördüğüm fiyat hareketleri, bu alanda danışmanlık yapan biri olarak beni gerçekten heyecanlandırdı — çünkü müşterilerime artık "bekleyin, fiyatlar düşecek" demek yerine somut rakamlarla konuşabiliyorum. 30 Temmuz 2026'da OpenAI, GPT-5.6 ailesindeki "Luna" modelini yüzde 80 oranında indirerek 1 milyon token başına 0,20 dolar girdi / 1,20 dolar çıktı seviyesine çekti. Aynı ailenin daha güçlü modeli "Terra" ise yüzde 20 indirimle 1 milyon token başına 2 dolar girdi / 12 dolar çıktı fiyatına geldi. 24 Temmuz 2026'da piyasaya çıkan Anthropic'in Claude Opus 5'i ise, yaklaşık Fable 5 seviyesine yakın bir zeka sunarken fiyatını kabaca yarıya indirdi ve üstüne bir "effort dial" (çaba kadranı) ekledi — yani artık bir istek için modelin ne kadar "düşünme çabası" harcayacağını, dolayısıyla maliyetini, siz ayarlayabiliyorsunuz. 31 Temmuz 2026'da DeepSeek V4-Flash, 1 milyon token başına 0,14 dolar girdi / 0,28 dolar çıktı fiyatıyla fiyat-performans dengesinde öne çıkan bir seçenek olarak duyuruldu. Ve 21 Temmuz 2026'da Google'ın Gemini 3.6 Flash modeli, daha ucuz ve daha verimli bir "işçi model" olarak geldi — özellikle gereksiz akıl yürütme (reasoning) adımlarını azaltarak, aynı kalitede yanıtı daha az token harcayarak üretiyor.

Aşağıdaki tabloda bu dört hareketi özetliyorum:

Model / Sağlayıcı	Duyuru tarihi	Girdi fiyatı (1M token)	Çıktı fiyatı (1M token)	Öne çıkan özellik
GPT-5.6 "Luna" (OpenAI)	30 Temmuz 2026	$0,20 (yüzde 80 indirim)	$1,20	Ucuz, yüksek hacimli işler için
GPT-5.6 "Terra" (OpenAI)	30 Temmuz 2026	$2,00 (yüzde 20 indirim)	$12,00	Daha yetenekli, orta-üst segment
Claude Opus 5 (Anthropic)	24 Temmuz 2026	Fable 5'e yakın zeka, ~yarı fiyat	~yarı fiyat	"Effort dial" ile maliyet/kapasite ayarı
DeepSeek V4-Flash	31 Temmuz 2026	$0,14	$0,28	Fiyat-performans lideri
Gemini 3.6 Flash (Google)	21 Temmuz 2026	Daha verimli, düşük maliyetli	Daha verimli, düşük maliyetli	Daha az gereksiz reasoning adımı

Buradan çıkardığım en önemli ders şu: model seçimi, bugün elinizdeki en büyük tek maliyet kaldıracı. Aynı iş için Terra yerine Luna kullanmak, girdi maliyetinizi onda bire, çıktı maliyetinizi ona kat kadar düşürebiliyor. Ama tabii bu bir "hep ucuzu seç" tavsiyesi değil — asıl mesele, iş yüküne göre doğru modeli seçmek ve bunu statik değil dinamik yapmak. Bu da bizi bir sonraki konuya, model routing'e götürüyor. Ama önce en temel ve en hızlı kazanımı sağlayan tekniğe, prompt caching'e bakalım.

Prompt caching, bence çoğu ekibin fark etmeden masada bıraktığı en büyük paradır. Mantığı basit: birçok üretim sisteminde her isteğe gönderilen prompt'un büyük bir kısmı değişmiyor — sistem talimatları, marka sesi kuralları, araç tanımları, few-shot örnekleri, sık kullanılan referans belgeler. Sadece kullanıcının son mesajı değişiyor. Hem Anthropic hem OpenAI, bu sabit "önek" (prefix) kısmını sunucu tarafında önbelleğe alıp, aynı önekle gelen sonraki isteklerde bu kısmı yeniden işlemeden, çok daha düşük maliyetle kullanmanıza izin veriyor.

Bunun iki faydası var: birincisi maliyet, ikincisi gecikme. Cache'lenen kısım yeniden hesaplanmadığı için hem daha ucuza mal oluyor hem de yanıt daha hızlı geliyor — bu da kullanıcı deneyimini doğrudan iyileştiriyor. Ben müşterilerime hep şunu söylüyorum: "Prompt caching'i açmak, kod tarafında neredeyse hiç efor gerektirmeyen ama etkisi hemen görülen nadir optimizasyonlardan biri."

Prompt caching'den en çok fayda görecek sistemler şunlar:

• Sabit, uzun bir sistem prompt'u olan müşteri destek botları
• Aynı belge setine defalarca referans veren RAG sistemleri (belge içeriğini her seferinde cache'leyebilirsiniz)
• Çok adımlı agent'lar; burada her adımda aynı araç tanımları ve talimatlar tekrar tekrar gönderilir
• Kod asistanları; büyük bir kod tabanının bağlamını her istekte yeniden göndermek yerine cache'lemek

Pratikte dikkat etmeniz gereken birkaç şey var. Birincisi, cache'lenebilir içeriğin prompt'un başında olması gerekiyor — çünkü caching mekanizması önek eşleşmesine dayanıyor; yani değişen kısmı (kullanıcı sorusu, güncel tarih, oturum bilgisi) her zaman en sona koymalısınız. İkincisi, cache'in bir geçerlilik süresi var; belirli bir süre kullanılmazsa düşüyor, bu yüzden çok düşük trafikli sistemlerde beklenen kazanç azalabilir. Üçüncüsü, cache'lenen içeriği sık sık değiştirirseniz (örneğin sistem prompt'unu her gün güncelliyorsanız) cache isabet oranınız düşer. Bu yüzden prompt mühendisliğinde "değişmeyen kısım" ile "değişen kısım" arasına net bir sınır çizmek, mimari bir disiplin haline gelmeli.

Bir müşterimde, 4.000 token'lık bir sistem prompt'u (ürün kataloğu özeti, marka tonu kuralları, güvenlik kısıtları) her istekte tam maliyetle gönderiliyordu. Sadece bu içeriği sabitleyip başa alarak ve caching'i açarak, girdi maliyetlerinde yüzde 60'ın üzerinde bir düşüş gördük — çıktı tarafına hiç dokunmadan. Bu, "düşük efor, yüksek getiri" optimizasyonlarının klasik bir örneği.

Prompt caching, aynı önekle gelen istekleri hızlandırıyor. Ama ya kullanıcı sorusu tam olarak aynı değilse, sadece anlamca benziyorsa? İşte burada semantic cache devreye giriyor. Fikir şu: gelen her sorguyu bir embedding modeliyle vektöre çeviriyorsunuz, bu vektörü daha önce sorulmuş ve yanıtlanmış sorguların vektörleriyle karşılaştırıyorsunuz. Eğer belirlediğiniz bir benzerlik eşiğinin üzerinde bir eşleşme varsa, LLM'i hiç çağırmadan, önceden üretilmiş yanıtı (veya onun küçük bir varyasyonunu) doğrudan döndürüyorsunuz.

Bu, özellikle şu senaryolarda çok değerli: sıkça sorulan sorular (SSS) botları, ürün destek asistanları, iç kurumsal bilgi tabanı sorgulama sistemleri. Bir insan kaynakları chatbotunda "izin günlerimi nasıl kullanırım" ile "yıllık izin hakkımı nasıl talep ederim" cümleleri kelime olarak farklı ama anlamca neredeyse aynı — semantic cache bu ikisini aynı yanıta yönlendirebilir, LLM çağrısını tamamen atlayarak.

Ama burada bir uyarı yapmam gerekiyor, çünkü bu tekniği yanlış uygulayan ekipler gördüm: semantic cache, her bağlamda güvenli değil. Eğer sorular arasında ince ama önemli anlam farkları varsa (örneğin "iade süresi kaç gün" ile "değişim süresi kaç gün"), çok agresif bir benzerlik eşiği yanlış yanıtları kullanıcıya döndürebilir — ve bu, maliyetten kazandığınızdan çok daha pahalıya, güven kaybına mal olabilir. Bu yüzden ben müşterilerime şu üç kuralı öneriyorum: eşik değerini muhafazakâr tutun ve gerçek trafik üzerinde test edin; cache'lenen yanıtların bir geçerlilik süresi (TTL) olsun, özellikle fiyat, stok, politika gibi zamanla değişen bilgiler için; ve kritik, yüksek riskli konularda (sağlık, hukuki, finansal tavsiye) semantic cache'i ya hiç kullanmayın ya da çok dar bir eşikle kullanın.

Teknik olarak semantic cache genelde bir vektör veritabanı (Pinecone, Weaviate, pgvector, Redis'in vektör eklentisi gibi) ile embedding modelinin (bunlar da genelde çok ucuz, LLM çağrısına kıyasla neredeyse bedava sayılabilir) birleşiminden oluşur. Maliyet karşılaştırması nettir: bir embedding çağrısı genelde bir LLM çağrısının binde biri, hatta daha azı maliyetindedir. Yani cache isabet oranınız yüzde 30 bile olsa, sisteminizin toplam maliyetinde ciddi bir düşüş görürsünüz.

Burada bence en çok yanlış anlaşılan ama en yüksek getirili strateji yatıyor. Birçok ekip, tek bir "en iyi" modeli seçip tüm trafiği ona yönlendiriyor — "en iyisini kullanalım, kaliteden ödün vermeyelim" mantığıyla. Ama gerçek şu: gelen isteklerin büyük çoğunluğu, en pahalı modelin kapasitesine ihtiyaç duymuyor. Basit bir sınıflandırma sorusu, bir format dönüşümü, kısa bir özet — bunlar için Claude Opus 5'in tam gücünü kullanmak, bir kamyonu markete ekmek almaya sürmek gibi.

Model routing (bazen cascading olarak da anılır) mantığı şudur: gelen her isteği önce ucuz ve hızlı bir modelle (veya basit bir sınıflandırıcıyla) değerlendirin. Eğer bu model soruyu güvenle çözebiliyorsa, yanıtı orada bitirin. Eğer model belirsizlik gösteriyorsa (düşük güven skoru, tutarsız yanıtlar, kendi kendine "emin değilim" diyor gibi sinyaller) isteği bir üst seviye, daha pahalı modele "yükseltin" (escalate edin). Bu, tıpkı bir çağrı merkezinde önce birinci seviye destek temsilcisinin bakması, çözemezse uzman ekibe yönlendirmesi gibi işliyor.

2026 yazının fiyat hareketleri, bu stratejiyi daha da cazip kılıyor. Örneğin bir sistemde şu üçlü kademeyi kurabilirsiniz: basit sınıflandırma ve kısa yanıtlar için Gemini 3.6 Flash veya DeepSeek V4-Flash (1 milyon token başına ondalık dolar seviyesinde); orta karmaşıklıktaki görevler için GPT-5.6 Luna ($0,20 / $1,20); ve gerçekten zor, çok adımlı akıl yürütme gerektiren görevler için Claude Opus 5, effort dial'ı yüksek ayarlanmış şekilde. Bu üçlü kademede, isteklerin yüzde 70-80'i ilk iki katmanda çözülüyorsa (ki gerçek dünya trafiğinde bu oran genelde bu civarda çıkıyor), toplam maliyetiniz tek bir premium modeli her şeyde kullanmaya kıyasla kat kat düşer.

Claude Opus 5'teki "effort dial" özelliği burada özellikle ilginç, çünkü routing kararını model-seçimi seviyesinden, tek bir model içinde "ne kadar çaba" seviyesine indiriyor. Yani her zaman en iyi modeli kullanabilirsiniz, ama o modelin ne kadar "derin düşüneceğini" göreve göre ayarlayarak maliyeti kontrol edebilirsiniz. Bu, routing mimarisini basitleştiren güzel bir gelişme.

Routing'i kurarken pratik bir tavsiyem: sınıflandırıcıyı kendiniz eğitmek zorunda değilsiniz. Basit bir heuristik (istek uzunluğu, anahtar kelimeler, geçmiş konuşma bağlamı) veya en ucuz modelin kendisini "bu soruyu yanıtlayabilir misin, evet/hayır" diye bir ön-kontrol olarak kullanmak bile işe yarıyor. Mükemmeli aramayın; yüzde 60 doğrulukta bir routing bile, hiç routing yapmamaktan çok daha iyi bir maliyet profili verir.

Gerçek zamanlı olmayan iş yüklerinde (raporlama, toplu veri işleme, gece çalışan analiz görevleri) batching, gözden kaçan ama etkili bir maliyet aracı. Hem OpenAI hem Anthropic, gerçek zamanlı yanıt gerektirmeyen istekler için batch API'ler sunuyor — bu istekler, sağlayıcının sunucu kapasitesini daha esnek kullanmasına izin verdiği için standart fiyata göre belirgin bir indirimle işleniyor, karşılığında yanıt süresi dakikalar yerine saatler mertebesinde olabiliyor.

Ben müşterilerime şunu soruyorum: "Bu işin sonucu kullanıcıya şu anda mı lazım, yoksa birkaç saat içinde mi?" Eğer cevap ikinciyse (örneğin haftalık müşteri segmentasyonu, toplu içerik etiketleme, geçmiş kayıtların özetlenmesi) bu işi mutlaka batch kuyruğuna almalısınız. Gerçek zamanlı bir chat deneyimini batching ile yavaşlatmak elbette anlamsız, ama arka planda çalışan onlarca süreç genelde gereksiz yere senkron ve gerçek zamanlı API'ler üzerinden çalıştırılıyor, sırf "daha basit kodlanıyor" diye.

Asenkron işleme de benzer bir mantıkla çalışıyor: sistemi, kullanıcıyı bekletmeden arka planda paralel istekler göndererek tasarlarsanız, hem toplam işlem süresi kısalır hem de bazı sağlayıcı indirimlerinden faydalanabilirsiniz. Özellikle çok adımlı agent iş akışlarında, birbirine bağımlı olmayan alt görevleri paralelleştirmek (sıralı yerine) hem gecikmeyi hem de bazı durumlarda maliyeti azaltır, çünkü gereksiz bekleme sürelerinde tekrar tekrar bağlam yeniden gönderilmesinin önüne geçer.

Bağlam penceresi büyüdükçe, "daha fazla bilgi = daha iyi yanıt" diye düşünmek cazip geliyor, ama bu her zaman doğru değil ve kesinlikle her zaman ucuz değil. Ben burada üç teknik öneriyorum.

Birincisi, gerçekten gerekli olanı seçmek. RAG sistemlerinde, retrieval adımında getirdiğiniz her belge parçası (chunk) doğrudan maliyete dönüşüyor. Getirilen chunk sayısını ve uzunluğunu sıkı tutmak, alaka düzeyini iyi ölçen bir reranker kullanmak (embedding araması sonrası ikinci bir eleme katmanı), gereksiz token'ları en baştan sisteme sokmamak demek.

İkincisi, konuşma geçmişini özetlemek. Uzun süren bir chat oturumunda, her yeni mesajla birlikte tüm geçmişi tekrar tekrar göndermek, token maliyetini katlanarak artırır. Bunun yerine, belirli bir mesaj sayısından sonra eski geçmişi bir özet (summary) haline getirip, sadece bu özeti ve son birkaç mesajı göndermek, hem maliyeti hem de gecikmeyi kontrol altında tutar. Bu, uzun soluklu müşteri destek konuşmalarında özellikle etkili.

Üçüncüsü, prompt sıkıştırma araçları. Bazı açık kaynak araçlar (LLMLingua gibi) veya basitçe kendi kurallarınız (gereksiz nezaket ifadelerini, tekrarlayan talimatları, aşırı ayrıntılı örnekleri kırpmak), prompt'un anlamını kaybetmeden token sayısını yüzde 20-40 civarında azaltabiliyor. Bunu yaparken dikkatli olun: agresif sıkıştırma, modelin talimatları yanlış yorumlamasına yol açabilir, bu yüzden her değişiklikten sonra yanıt kalitesini gerçek trafikle test etmek şart.

Son bir nokta: çıktı tarafında da trimming uygulanabilir. max_tokens parametresini gereğinden büyük bırakmak, modelin gereksiz yere uzun yanıtlar üretmesine (ve bunun için ödeme yapmanıza) yol açabilir. Özellikle yapılandırılmış çıktı (JSON, kısa kategori etiketleri) beklediğiniz durumlarda, çıktı uzunluğunu net şekilde sınırlamak basit ama etkili bir tasarruf yöntemi.

Bunu özellikle vurgulamak istiyorum çünkü son bir yılda gördüğüm en büyük "sürpriz fatura" vakalarının neredeyse tamamı buradan geliyor. Bir agent, bir görevi tamamlamak için birden fazla adımda araç çağırıyor, sonucu değerlendiriyor, gerekirse tekrar araç çağırıyor. Bu döngü doğası gereği güçlü, ama kontrolsüz bırakıldığında maliyeti hiç beklemediğiniz şekilde patlatabiliyor.

Bir müşterimde şöyle bir vaka yaşadık: bir araştırma agent'ı, belirsiz bir arama sonucuyla karşılaştığında "bir daha deneyeyim" mantığıyla aynı aracı defalarca, bazen 40'ın üzerinde kez çağırıyordu, her seferinde önceki tüm bağlamı da modele yeniden gönderiyordu (çünkü cache doğru kurulmamıştı). Tek bir kullanıcı isteği, normalde birkaç sentlik bir işlemken, bazı durumlarda birkaç dolara çıkıyordu. Bunu fark etmemizin tek sebebi, o ay faturanın alışılmadık şekilde yüksek gelmesiydi — hiçbir alarm, hiçbir üst sınır yoktu.

Bunun önüne geçmek için önerdiğim somut kontroller şunlar:

• Maksimum adım sayısı (max iterations): Her agent döngüsüne, göreve uygun sert bir üst sınır koyun. "Bir kere daha dene" mantığının sonsuza kadar sürmesine izin vermeyin.
• Bütçe bazlı kesme (token/dolar budget): Bir agent oturumu, önceden belirlenmiş bir token veya dolar bütçesini aştığında otomatik olarak durmalı, kullanıcıya veya operatöre bir uyarı ile.
• Döngü tespiti: Aynı aracı aynı parametrelerle art arda çağırma gibi örüntüleri tespit edip erken kesin.
• Zaman aşımı: Adım başına ve toplam oturum başına zaman sınırları koyun; bu hem maliyeti hem kullanıcı deneyimini korur.
• İnsan onayı eşiği: Belirli bir maliyet veya adım sayısını aşan agent akışlarında, devam etmeden önce insan onayı isteyin.

Bu kontrolleri "sonradan eklenecek güvenlik ağı" değil, agent mimarisinin ayrılmaz bir parçası olarak tasarlamanızı öneririm. Bir agent framework'ü seçerken veya kendi agent döngünüzü yazarken, bu limitlerin ilk günden itibaren kodda yer alması gerekiyor.

Bu, belki de en çok göz ardı edilen adım. Birçok ekip, LLM maliyetini yalnızca ay sonunda gelen toplu faturadan öğreniyor — bu, arabanızı hız göstergesine bakmadan sürmeye benziyor. Üretim sistemlerinde, her isteğin maliyetini gerçek zamanlı olarak izlemeniz gerekiyor.

Pratikte bunun anlamı şu: her LLM çağrısını, hangi kullanıcı/müşteri, hangi özellik, hangi model, kaç girdi/çıktı token'ı ve hesaplanan dolar maliyetiyle etiketleyip loglamak. Bu veriyi bir dashboard'a (Grafana, Datadog veya kendi basit iç aracınız) taşıyarak; günlük, özellik bazlı, müşteri bazlı maliyet trendlerini görebilmelisiniz. Ben müşterilerime her zaman şunu soruyorum: "Şu anda, geçen hafta hangi özelliğiniz en çok maliyete neden oldu diye sorsam, cevap verebilir misiniz?" Çoğu zaman cevap hayır oluyor — ve bu, optimizasyonun neden bu kadar zor ilerlediğinin en net göstergesi.

Per-request maliyet takibi ayrıca şu avantajları sağlıyor: anormal kullanım örüntülerini (örneğin bir agent döngüsünün kontrolden çıkması) erken yakalamak; hangi müşteri segmentinin veya özelliğin kârlılığınızı en çok etkilediğini görmek; ve model routing veya caching gibi optimizasyonların gerçekten işe yarayıp yaramadığını A/B test ederek kanıtlamak. "Bu değişikliği yaptık, maliyet düştü mü?" sorusuna veriyle cevap veremiyorsanız, aslında optimizasyon yapmıyorsunuz, tahmin yürütüyorsunuz.

Son olarak, bütçe alarmları kurmanızı şiddetle öneririm — hem sağlayıcı seviyesinde (OpenAI, Anthropic konsollarındaki harcama limitleri) hem de kendi uygulama seviyenizde (belirli bir müşteri veya özellik günlük/aylık bütçesini aştığında bildirim). Bu, sürpriz faturaların önüne geçen en basit ve en ucuz sigorta.

Bu soru bana en sık sorulan sorulardan biri ve cevap hemen hemen hiçbir zaman tek yönlü değil. API üzerinden büyük sağlayıcıları kullanmanın avantajı net: sıfır altyapı yükü, sürekli güncellenen en yeni modeller, ölçeklenebilirlik dert etmeden büyüme, ve — özellikle 2026 yazındaki fiyat düşüşleriyle birlikte — artık çoğu iş yükü için maliyet de rekabetçi. DeepSeek V4-Flash gibi $0,14/$0,28 seviyesindeki modeller, kendi GPU altyapınızı kurup işletmenin sabit maliyetini (donanım, elektrik, DevOps ekibi, model güncelleme yükü) haklı çıkarmayı orta ölçekli birçok şirket için zorlaştırıyor.

Ama self-hosting'in (kendi sunucularınızda veya özel bulutta açık ağırlıklı model çalıştırmanın) hâlâ güçlü olduğu senaryolar var: çok yüksek, sürekli ve öngörülebilir hacimli iş yükleri (burada sabit maliyet, değişken API maliyetinin altına düşebilir); çok düşük gecikme gerektiren, gerçek zamanlı sistemler; ve en kritik olanı, veri egemenliği ve düzenleyici gereksinimler.

Türkiye bağlamında bu son nokta özellikle önemli. KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında, özellikle sağlık, finans, kamu ve bazı e-ticaret senaryolarında kişisel verilerin yurt dışına aktarımı sıkı kurallara tabi. Bir müşteri destek sisteminde kullanıcıların kimlik bilgileri, sağlık geçmişi veya finansal verileri LLM'e prompt olarak gönderiliyorsa, bu verinin hangi ülkede işlendiği, hangi sağlayıcının veri işleme sözleşmesinin KVKK'nın aradığı garantileri sağlayıp sağlamadığı ciddi bir hukuki inceleme konusu. Bu noktada üç yol var: birincisi, sağlayıcının EU/uygun bölge veri işleme garantisi olan kurumsal anlaşmasını kullanmak; ikincisi, açık ağırlıklı modelleri (DeepSeek, Llama, Gemma ailesi gibi) Türkiye içinde veya KVKK uyumlu bir bulut bölgesinde self-host etmek; üçüncüsü, hassas veriyi modele göndermeden önce maskelemek/anonimleştirmek (PII redaction) ve sadece gerekli, anonimleştirilmiş bağlamı LLM'e iletmek.

Ben danışmanlık verirken şu basit çerçeveyi kullanıyorum: eğer veri hassasiyeti yüksekse ve hacim de yüksekse, self-hosting'i ciddi olarak değerlendirin. Eğer veri hassasiyeti düşükse (örneğin genel ürün bilgisi soruları), API her zaman daha hızlı ve daha ucuz bir başlangıç noktası. Ve eğer veri hassasiyeti yüksek ama hacim düşükse, PII maskeleme + kurumsal API sözleşmesi genelde self-hosting'in operasyonel yüküne göre çok daha mantıklı bir orta yol oluyor.

Somutlaştırmak için, danışmanlık deneyimlerimden esinlenen basitleştirilmiş bir örnek üzerinden gidelim. Orta ölçekli bir Türk e-ticaret şirketinin, aylık 2 milyon müşteri destek sorgusu işlediğini varsayalım. Her sorguda, ortalama 3.000 token'lık sabit bir sistem prompt'u (ürün kataloğu özeti, marka tonu, iade/değişim politikaları) ve 150 token'lık kullanıcı sorusu gönderiliyor; yanıt ortalama 300 token uzunluğunda.

Bu senaryoyu, temmuz 2026'da açıklanan gerçek fiyatlarla ve caching/semantic cache için makul (bu örneğe özgü, varsayımsal) tasarruf oranlarıyla karşılaştıralım:

Senaryo	Model	Girdi/çıktı fiyatı (1M token)	Aylık girdi token	Aylık çıktı token	Yaklaşık aylık maliyet
Cache yok, güçlü model	Terra	$2,00 / $12,00	6,3 milyar	0,6 milyar	~$19.800
Cache yok, ucuz model	Luna	$0,20 / $1,20	6,3 milyar	0,6 milyar	~$1.980
Prompt caching açık (varsayım: sabit 3.000 token'lık kısım tekrar tekrar tam fiyata değil, çok daha düşük bir oranla faturalanıyor), Luna	Luna	$0,20 / $1,20	~0,9 milyar efektif	0,6 milyar	~$900
Semantic cache + routing (varsayım: sorguların yüzde 35'i önceden yanıtlanmış benzer sorulardan karşılanıyor, LLM hiç çağrılmıyor), Luna	Luna	$0,20 / $1,20	~0,6 milyar efektif	0,4 milyar	~$600

Bu tablodaki son iki satır, gerçek şirket verisi değil, bu makale için kurduğum açıkça varsayımsal bir hesaplama örneği; amacım kesin bir rakam iddia etmek değil, doğru tekniklerin bir araya geldiğinde maliyetin nasıl kademeli olarak düştüğünü göstermek. Ama yapı gerçek: sadece doğru modeli seçmek (Terra yerine Luna) maliyeti yaklaşık 10 kat düşürüyor; buna prompt caching eklemek girdi maliyetini daha da aşağı çekiyor; buna semantic cache ve routing eklemek toplamda ilk senaryoya göre yüzde 95'in üzerinde bir tasarruf potansiyeli ortaya koyuyor. Bu, "her optimizasyonu tek tek küçük bir kazanım" olarak değil, "üst üste binen, çarpan etkisi yaratan bir sistem" olarak düşünmeniz gerektiğini gösteriyor.

Burada KVKK boyutunu da unutmamak lazım: eğer bu müşteri destek sorgularında kimlik numarası, adres veya ödeme bilgisi gibi kişisel veriler geçiyorsa, hangi modeli/sağlayıcıyı seçtiğiniz sadece maliyet değil, aynı zamanda hukuki uyum sorusu. Bu yüzden mimariyi kurarken maliyet optimizasyonunu veri koruma gereksinimleriyle birlikte, tek bir tasarım kararı olarak ele almanızı öneririm.

Bunca teknik arasında nereden başlayacağınızı soracaksanız, benim önerim şu sırayla ilerlemeniz: önce mevcut maliyetinizi per-request seviyesinde gözlemlenebilir hale getirin — göremediğinizi optimize edemezsiniz. Sonra, en düşük efor / en yüksek getiri olan prompt caching'i açın; genelde bir haftadan kısa sürede uygulanabilir ve hemen sonuç verir. Ardından model routing'i devreye alın; basit bir sınıflandırıcıyla başlayın, mükemmelliği beklemeyin. Agent kullanıyorsanız, adım/bütçe limitlerini hemen, "sonra eklerim" demeden koyun — bu, en riskli maliyet kaynağı. Semantic cache'i, düşük riskli ve tekrarlayan sorgu hacmi yüksek alanlarda (SSS, genel destek) pilot olarak başlatın, sonuçları izleyerek genişletin. Ve son olarak, self-hosting'i sadece hacminiz ve veri hassasiyetiniz gerçekten bunu haklı çıkardığında değerlendirin — çoğu şirket için bugünkü API fiyatları, özellikle temmuz 2026'daki düşüşlerle birlikte, kendi altyapınızı işletmekten daha ucuz ve çok daha az operasyonel yük getiriyor.

Bir kurumla çalışırken en çok gördüğüm hata, bu tekniklerden sadece birini uygulayıp "optimizasyonu yaptık" demek. Gerçek kazanım, bunların hepsinin birlikte, birbirini besleyen bir sistem olarak kurulmasından geliyor. Token ekonomisini anlamak size nereye bakmanız gerektiğini gösterir; caching ve routing size o maliyeti nasıl düşüreceğinizi gösterir; gözlemlenebilirlik ise bu değişikliklerin gerçekten işe yarayıp yaramadığını kanıtlar. Üçü birlikte olmadan, LLM maliyeti kontrolden çıkmaya mahkûmdur — ve ben bunu, işini iyi yapan onlarca ekibin bile fark etmeden yaşadığını gördüm.