LLM Çıkarım Maliyeti ve FinOps 2026: Token Değil, Başarılı Çıktı Başına Maliyet

TL;DR — 2026'da YZ'nin maliyet merkezi eğitim değil, çıkarım (inference). Sektör analistleri, kurumsal YZ GPU harcamasının %55-80'inin çıkarıma gittiğini söylüyor. İyi haber: olgun maliyet yönetimi olan kurumlar, yönetilmeyenlere göre çıkarım başına %40-60 daha düşük maliyet raporluyor. Anahtar teknikler: model yönlendirme (routing), prompt ve KV önbellekleme, batch'leme, kuantizasyon ve birim-maliyet takibi. Ama asıl metrik token başına maliyet değil — "başarılı çıktı başına maliyet" (cost-per-successful-output), yani kalite kapılarını geçen çıktı başına toplam maliyet. Bu yazıda bir LLM FinOps çerçevesini, somut tasarruf kaldıraçlarını ve Türkiye bağlamında bütçe planlamasını anlatıyorum.

Birkaç yıl önce YZ maliyeti denince akla eğitim gelirdi — devasa GPU kümeleri, haftalar süren eğitim koşuları. Ama üretime geçen kurumlar için tablo değişti. Bir modeli bir kez eğitirsiniz (veya hiç eğitmezsiniz, hazır API kullanırsınız), ama onu milyonlarca kez çağırırsınız. Her çağrı token tüketir, her token para eder. Sektör analistleri kurumsal YZ GPU harcamasının %55-80'inin çıkarıma gittiğini tahmin ediyor. Yani maliyet optimizasyonunun kalbi artık çıkarımda.

Bu, zihniyet değişikliği gerektiriyor. Eğitim maliyeti bir sermaye yatırımı (CapEx) gibi düşünülebilir; çıkarım maliyeti ise sürekli akan bir operasyonel gider (OpEx), tıpkı bulut faturası gibi. Ve tıpkı bulutta olduğu gibi, dikkat edilmezse fatura sessizce şişer. Bir chatbot'un günde 100 bin sorgu alması, her sorgunun binlerce token tüketmesi ve bunun aylık bir sürprize dönüşmesi çok kolay.

FinOps Foundation'ın işaret ettiği kritik bir nokta var: token başına maliyet temel bir metriktir ama yeterli değildir. Asıl önemli metrik "başarılı çıktı başına maliyet" (cost-per-successful-output) — yani kalite kapılarını geçen çıktı başına toplam çıkarım maliyeti. Neden? Çünkü ucuz ama kalitesiz çıktılar sizi yeniden denemeye, insan müdahalesine veya müşteri kaybına sürükler; bunların hepsi gizli maliyet.

Bir örnek: A modeli token başına ucuz ama %30 oranında kabul edilemez çıktı üretiyor; her başarısız çıktı bir insan tarafından düzeltiliyor. B modeli token başına iki kat pahalı ama %5 hata veriyor. Token başına baksanız A ucuz görünür; başarılı çıktı başına baktığınızda B çok daha ucuz olabilir, çünkü insan düzeltme maliyeti A'yı katlıyor. İşte bu yüzden birim ekonomisini mühendislik kararlarına bağlayan metrik, başarılı çıktı başına maliyettir.

Kurumların çıkarım maliyetini %30-60 kısmasını sağlayan başlıca teknikler şunlar. Birincisi model yönlendirme (routing): her sorguyu en pahalı modele göndermek yerine, sorgunun zorluğuna göre model seçmek. Basit sorgular küçük, ucuz bir modele; karmaşık sorgular güçlü, pahalı modele gider. Bu "model kademelemesi" (tiering), tek başına büyük tasarruf sağlar.

İkincisi önbellekleme (caching): tekrar eden veya benzer sorgular için sonuçları saklamak. İki katmanlı bir önbellek tasarımı — sık tekrarlanan sorgular için tam-eşleşme katmanı, benzer anlamlı sorgular için anlamsal katman — anlamsal örtüşmenin %30'un üzerinde olduğu iş yüklerinde çok etkili. Ayrıca KV önbellekleme, uzun bağlamlı çağrılarda tekrarlanan hesaplamayı azaltır. Üçüncüsü prompt sıkıştırma: gereksiz token'ları eleyerek girdi boyutunu küçültmek. Dördüncüsü batch'leme: birden çok isteği toplu işlemek verimliliği artırır. Beşincisi kuantizasyon: kendi altyapınızda model çalıştırıyorsanız, modeli düşük hassasiyete (örn. 4-bit) indirgemek bellek ve hesaplama maliyetini ciddi düşürür.

Tasarruf tekniklerinin etkisi

Teknik	Ne yapar	Tipik kazanç
Model yönlendirme	Sorguyu doğru modele gönderir	Yüksek
Çok-katmanlı önbellek	Tekrar eden sorguları saklar	Yüksek tekrar oranında çok yüksek
Prompt sıkıştırma	Girdi token'ını azaltır	Orta
Batch'leme	İstekleri toplu işler	Orta
Kuantizasyon	Model boyutunu küçültür	Self-host'ta yüksek

Maliyet optimizasyonunun ön koşulu görünürlük. Sadece API kullanıyorsanız bile Helicone, Langfuse veya LiteLLM gibi araçlar token tüketimini izler, önbelleği uygular ve maliyeti kullanıcı/özellik/uç nokta bazında dağıtır. Bu birim-maliyet takibi olmadan, hangi özelliğin bütçeyi yediğini bilemezsiniz. "Bu ay YZ faturası neden iki katına çıktı?" sorusuna cevap veremiyorsanız, FinOps disiplininiz eksik demektir.

Çok-katmanlı önbellekleme öngörülemeyen maliyetleri dizginler, uçtan uca gözlemlenebilirlik farklı iş yüklerinde çıkarım zamanlamasını yönetir, akıllı yönlendirme sorgu karmaşıklığı değişkenken bütçe kısıtlarını optimize eder. Bu üçü birlikte, maliyet yönetiminin operasyonel omurgasını oluşturur.

Bulut FinOps prensiplerini YZ'ye uyarlayan çerçeve, maliyeti şu kategorilere ayırır: çıkarım API harcaması, fine-tuning hesaplaması, vektör depolama, gözlemlenebilirlik ve insan-döngüde (human-in-the-loop) inceleme maliyetleri. Çoğu kurum sadece ilk kalemi görür; ama vektör depolama ve insan inceleme maliyetleri de sessizce büyür. Örneğin bir vektör veritabanı faturası, dikkatsiz ölçeklendirmede bütçenin 2.5-4 katına çıkabilir.

FinOps'un üç aşaması — görünürlük (inform), optimizasyon (optimize) ve yönetişim (operate) — YZ'ye de uyarlanır. Görünürlük: her harcamayı bir özelliğe/takıma etiketle. Optimizasyon: yönlendirme, önbellek, sıkıştırma uygula. Yönetişim: bütçe alarmları kur, birim-maliyet hedefleri belirle, düzenli gözden geçir. Olgun YZ maliyet yönetişimine sahip kurumlar, yönetilmeyenlere göre çıkarım başına %40-60 daha düşük maliyet raporluyor — bu, göz ardı edilemeyecek bir fark.

Türkiye'de LLM bütçesi planlarken ek bir değişken var: kur. Çoğu frontier API doları üzerinden fiyatlanır, geliriniz ise TL. Kur dalgalanması, öngörülen bütçenizi ay içinde bozabilir. Bu yüzden Türk kurumları için model kademeleme ve önbellekleme sadece maliyet değil, aynı zamanda kur riskini azaltan araçlar. Ayrıca token maliyetini TL bazında izlemek ve senaryo planlaması yapmak akıllıca.

Self-host kararı da hem maliyet hem KVKK açısından öne çıkıyor. Belirli bir ölçeğin üzerinde, açık ağırlıklı bir modeli kendi altyapınızda çalıştırmak, API'ye göre birim maliyette avantaj sağlayabilir — özellikle sabit, yüksek hacimli iş yüklerinde. Üstelik verinin yurt dışına çıkmaması gereken düzenlenmiş senaryolarda self-host bir zorunluluk olabilir. Ancak GPU, operasyon ve mühendislik maliyetlerini dürüstçe hesaba katın; küçük hacimlerde API neredeyse her zaman daha ekonomik.

Pratik başlangıç adımlarım: Önce görünürlük kurun — bir gözlemlenebilirlik aracıyla her çağrının maliyetini özellik bazında izleyin. Sonra başarılı çıktı başına maliyeti tanımlayın; sadece token'a değil, kalite kapılarını geçen çıktıya bakın. Model yönlendirmeyi ekleyin: basit sorguları ucuz modele kaydırın. Yüksek tekrarlı iş yüklerinde önbellekleme uygulayın. Bütçe alarmları ve birim-maliyet hedefleri koyun. Kur riskini senaryolayın ve belirli bir hacim eşiğinde self-host'u değerlendirin.

Çıkarım maliyeti, 2026'da YZ ekonomisinin belirleyici cephesi. Modeliniz ne kadar zeki olursa olsun, birim ekonomisi tutmuyorsa proje sürdürülebilir değil. İyi haber şu ki bu, çözülebilir bir mühendislik problemi: doğru görünürlük, doğru metrik ve birkaç disiplinli kaldıraçla çıkarım maliyetini yarıya indirmek gerçekçi bir hedef. FinOps'u sonradan eklenen bir yama değil, YZ mimarinizin bir tasarım prensibi olarak ele alın.