LLM Maliyet Optimizasyonu: Prompt Caching, Batching ve Model Routing Rehberi

LLM maliyet optimizasyonu nedir? LLM maliyet optimizasyonu, üretimde çalışan büyük dil modeli (LLM) uygulamalarının token bazlı işletme maliyetini, yanıt kalitesini koruyarak sistematik biçimde düşürme disiplinidir. Amaç harcamayı körlemesine kısmak değil; her harcanan token'ın gerçek bir değer üretmesini sağlamaktır.

Bir LLM uygulaması demoda ucuz görünür; ama trafik büyüdükçe token maliyeti sessizce katlanır ve bir gün fatura, iş modelini tehdit eder hale gelir. İyi haber şu: LLM maliyetinin büyük kısmı, kaliteden ödün vermeden geri kazanılabilir. Bu rehberde llm maliyet optimizasyonu neden gereklidir, token maliyeti nasıl oluşur, prompt caching (önbellekleme), batching (toplu işleme) ve model routing (göreve göre model seçimi) tam olarak nasıl çalışır, prompt sadeleştirme ve çıktı sınırlama token'ı nasıl azaltır, RAG ile bağlam kısaltma ve küçük model artı fine-tuning ne zaman devreye girer, FinOps ile maliyet nasıl izlenir, kalite-maliyet dengesi nasıl kurulur, hangi teknik hangi senaryoya uygundur ve yaygın hatalar nelerdir sorularını bir AI mühendisi ve danışman titizliğiyle ele alıyoruz.

Tanım

LLM Maliyet Optimizasyonu

Üretimde çalışan büyük dil modeli (LLM) uygulamalarının token bazlı işletme maliyetini, yanıt kalitesini koruyarak sistematik biçimde düşürme disiplini. Başlıca teknikler prompt caching (önbellekleme), batching (toplu işleme), model routing (göreve göre model seçimi), prompt sadeleştirme, çıktı sınırlama, RAG ile bağlam kısaltma ve küçük model artı fine-tuning'dir. Bir FinOps ölçüm çerçevesiyle birleştiğinde maliyet tahmin edilebilir ve yönetilebilir hale gelir.

Ayrıca: LLM cost optimization, token maliyeti optimizasyonu, LLM FinOps, yapay zeka maliyet yönetimi

LLM maliyet optimizasyonu, en yalın haliyle, bir dil modeli uygulamasının ürettiği değeri korurken ya da artırırken faturasını düşürme sanatı ve mühendisliğidir. "Optimizasyon" kelimesi burada kritiktir: amaç, maliyeti sıfıra indirmek veya en ucuz modeli her yerde kullanmak değildir; amaç, belirli bir kalite eşiğini en düşük maliyetle karşılamaktır. Yani bu bir kısıtlı eniyileme problemidir: kaliteyi kısıt olarak sabit tut, maliyeti amaç fonksiyonu olarak küçült.

Bunu somutlaştırmak için bir benzetme yardımcı olur. Bir LLM uygulamasını işleten ekip, aslında bir enerji faturasını yöneten tesis müdürü gibidir. Nasıl ki tesis müdürü aydınlatmayı kapatmadan (kaliteyi düşürmeden) verimli ampuller, zamanlayıcılar ve akıllı sayaçlarla faturayı düşürürse; LLM ekibi de yanıt kalitesini bozmadan önbellekleme, toplu işleme ve doğru model seçimiyle token maliyetini düşürür. İki durumda da anahtar, körlemesine kısıntı değil, nerede israf olduğunu ölçüp oraya müdahale etmektir. Bu bakış açısı, llm maliyet optimizasyonunu bir kesinti operasyonundan çıkarıp bir verimlilik mühendisliğine dönüştürür; amaç az harcamak değil, doğru harcamaktır.

Bu disiplinin tek bir "sihirli ayar"ı yoktur; birbirini tamamlayan tekniklerin bir portföyüdür. Prompt caching tekrar eden bağlamı ucuzlatır, batching acil olmayan işleri indirimli çalıştırır, model routing her işi doğru modele yönlendirir, prompt sadeleştirme ve çıktı sınırlama token sayısını azaltır. Bu tekniklerin temelini anlamak için dil modellerinin nasıl çalıştığını gösteren LLM nedir ve maliyetin birimi olan token'ı açıklayan token nedir rehberleri iyi bir başlangıçtır. Çünkü llm maliyet optimizasyonu, özünde token ekonomisini yönetmektir.

Bir llm maliyet optimizasyonu programına neden ihtiyaç duyulduğunu anlamak için önce maliyetin nasıl sessizce büyüdüğünü görmek gerekir. Bir prototip, günde birkaç yüz çağrıyla çalışırken fatura ihmal edilebilir düzeydedir; kimse maliyeti düşünmez. Ama uygulama üretime geçip günde yüz binlerce, milyonlarca çağrıya ulaştığında, her çağrıdaki küçük bir israf, devasa bir toplama dönüşür. Maliyetin doğrusal büyümesi, çoğu ekibi hazırlıksız yakalar.

Kontrolden çıkışın ilk nedeni şişkin bağlamdır. Ekipler kaliteyi artırmak için promptu uzatır: daha çok talimat, daha çok örnek, daha çok doküman. Her eklenen kelime bir girdi token'ıdır ve her çağrıda yeniden faturalanır. "Ne olur ne olmaz, hepsini bağlama koyalım" refleksi, kaliteye katkısı olmayan ama her istekte para yakan bir bağlam şişkinliği yaratır. Bu, en yaygın ve en görünmez maliyet kalemidir.

İkinci neden yanlış model seçimidir. Basit bir sınıflandırma, kısa bir özet veya bir formatlama işi için en güçlü ve en pahalı model kullanmak, çekiç yerine balyoz kullanmaya benzer; iş biter ama maliyet gereksiz yere yüksektir. Ekipler genellikle tek bir güçlü modeli her işe koşar, çünkü kurulumu basittir; ama bu, ortalama maliyeti yapay olarak yükseltir. Üçüncü neden kontrolsüz çıktıdır: modele "istediğin kadar uzun yaz" demek, çıktı token'ını ve çıktı genellikle daha pahalı olduğu için maliyeti şişirir.

Her llm maliyet optimizasyonu çabası, tek bir temel birimi anlamakla başlar: token maliyeti. Dil modelleri metni token adı verilen parçalara böler; kabaca bir token, birkaç harf ile bir kısa kelime arasında bir uzunluktur. Faturalama da bu token'lar üzerinden yapılır. Token kavramının ayrıntısını token nedir yazısında ele alıyoruz; burada odağımız bu token'ların nasıl maliyete dönüştüğüdür.

Kritik ayrım şudur: bir çağrının maliyeti iki kalemden oluşur. Birincisi girdi (input) token'ları — modele gönderdiğiniz her şey: sistem promptu, talimatlar, örnekler, dokümanlar, kullanıcı sorusu ve varsa konuşma geçmişi. İkincisi çıktı (output) token'ları — modelin ürettiği yanıt. Çoğu sağlayıcıda çıktı token'ı, girdi token'ından belirgin biçimde daha pahalıdır; çünkü üretim, girdiyi okumaktan daha yoğun bir hesaplama gerektirir. Bu asimetri, optimizasyonda çıktıyı kısmanın neden değerli olduğunu açıklar.

Bir isteğin maliyeti kabaca şöyle formüle edilir: (girdi token sayısı × girdi birim fiyatı) + (çıktı token sayısı × çıktı birim fiyatı). Buna iki indirim kalemi eklenir: prompt caching ile önbelleğe alınmış girdi token'ları normal girdiden ucuza faturalanır; batching uç noktaları ise tüm çağrı için indirim sağlar. Gerçek birim fiyatlar sağlayıcıya ve modele göre değişir ve zamanla güncellenir; bu yüzden bu rehberdeki tüm sayısal örnekler illüstratiftir ve kendi sağlayıcınızın güncel fiyat sayfasından teyit edilmelidir.

Bir LLM çağrısının maliyet kalemleri (kavramsal)

Kalem	Ne içerir	Maliyete etkisi
Girdi token'ları	Sistem promptu, örnekler, doküman, soru	Her çağrıda faturalanır; şişkinlik pahalı
Çıktı token'ları	Modelin ürettiği yanıt	Genellikle girdiden daha pahalı
Önbelleğe alınmış girdi	Tekrar eden sabit ön ek	İndirimli faturalanır (prompt caching)
Toplu (batch) çağrı	Acil olmayan toplu iş	Tüm çağrı indirimli (batching)
Model seçimi	Küçük vs büyük model	Birim fiyatı katlarca değiştirir

Bu tablo, optimizasyonun neden çok kaldıraçlı olduğunu gösterir: token maliyetini düşürmenin tek bir yolu yoktur; girdiyi kısaltabilir, çıktıyı sınırlayabilir, tekrar edeni önbelleğe alabilir, işi toplu çalıştırabilir veya daha ucuz bir modele yönlendirebilirsiniz. Usta bir yaklaşım, bu kaldıraçları körlemesine değil, ölçülen en büyük kaleme göre kullanır. Modelin ne kadar bağlam alabileceğinin sınırını ve bunun maliyetle ilişkisini context window nedir yazısında derinleştiriyoruz.

Bu rehberin kalbi budur: llm maliyet optimizasyonu, tek bir hamle değil, birbirini tamamlayan yedi ana tekniğin bir portföyüdür. Her teknik maliyetin farklı bir kalemine dokunur; bu yüzden etkileri çoğunlukla toplanır. Deneyimli bir ekip bu teknikleri körlemesine hepsini açarak değil, ölçülen en büyük maliyet kaleminden başlayarak katman katman uygular. Aşağıda tekniklerin her birini ayrı bölümlerde derinlemesine ele alacağız; ama önce panoramayı görelim.

Birinci teknik model routing (göreve göre model seçimi): her isteği, kalite gereksinimini karşılayan en ucuz modele yönlendirmek. İkinci teknik prompt caching (önbellekleme): sistem promptu ve doküman gibi tekrar eden bağlamı bir kez işleyip sonraki çağrılarda indirimli faturalamak. Üçüncü teknik batching (toplu işleme): acil olmayan işleri indirimli toplu uç noktalara devretmek. Dördüncü teknik prompt sadeleştirme: gönderilen girdi token'ını gereksiz kelimelerden arındırmak.

Beşinci teknik çıktı sınırlama: modelin ürettiği yanıt uzunluğunu ihtiyaca göre kısıtlamak. Altıncı teknik RAG ile bağlam kısaltma: tüm dokümanı bağlama koymak yerine yalnızca ilgili parçaları getirmek. Yedinci teknik küçük model artı fine-tuning: yüksek hacimli dar görevleri, eğitilmiş küçük bir modelle çok daha ucuza çalıştırmak. Bu yedi teknik, bir maliyet optimizasyonu araç kutusunu oluşturur.

Yedi ana LLM maliyet optimizasyonu tekniği ve dokundukları maliyet kalemi

Teknik	Dokunduğu kalem	En uygun olduğu durum
Model routing	Birim model fiyatı	Karışık zorlukta trafik
Prompt caching	Girdi token'ı	Uzun ve sabit ön ek
Batching	Tüm çağrı	Acil olmayan toplu iş
Prompt sadeleştirme	Girdi token'ı	Şişkin prompt
Çıktı sınırlama	Çıktı token'ı	Uzun/serbest yanıtlar
RAG ile bağlam kısaltma	Girdi token'ı	Büyük doküman tabanı
Küçük model + fine-tuning	Birim model fiyatı	Yüksek hacimli dar görev

Bu çerçevenin en önemli mesajı şudur: teknikler rakip değil, tamamlayıcıdır. Bir uygulama aynı anda model routing ile doğru modeli seçebilir, prompt caching ile bağlamı ucuzlatabilir, prompt sadeleştirme ile token'ı azaltabilir ve uygun işleri batching'e devredebilir. Şimdi bu tekniklerin en yüksek etkili üçünü — prompt caching, batching ve model routing — ayrı bölümlerde ayrıntısıyla inceleyelim.

Prompt caching, yani önbellekleme, llm maliyet optimizasyonunun en yüksek getirili ve çoğu zaman en az efor gerektiren tekniğidir. Temel fikir basittir: bir çağrının başında yer alan ve çağrıdan çağrıya değişmeyen bağlamı — uzun bir sistem promptu, sabit talimatlar, few-shot örnekler veya üzerinde soru sorulan bir doküman — her seferinde sıfırdan işlemek yerine, bir kez işleyip sonucu önbellekte tutmak ve sonraki çağrılarda bu ortak ön eki indirimli faturalamaktır.

Neden işe yarar? Çünkü gerçek uygulamalarda girdinin büyük bir kısmı tekrar eder. Bir müşteri destek asistanını düşünün: her çağrıda aynı uzun sistem promptu, aynı marka kuralları ve aynı ürün bilgisi gönderilir; yalnızca kullanıcının sorusu değişir. Önbellekleme olmadan bu sabit ön ek her çağrıda yeniden faturalanır. Önbellekleme ile ise bu bölüm bir kez tam fiyata işlenir, sonraki çağrılarda indirimli okunur. Sabit ön ek ne kadar uzunsa ve trafik ne kadar yoğunsa, tasarruf o kadar büyür.

Önbelleklemeden en yüksek verimi almanın anahtarı prompt tasarımıdır: promptu, sabit kısım en başta ve değişken kısım en sonda olacak şekilde düzenlemek. Çünkü önbellek genellikle ortak bir ön ek üzerinden çalışır; değişen bir parça ne kadar başa yakınsa, ondan sonrası önbelleklenemez. Bu yüzden usta bir mühendis, sistem promptunu ve dokümanları başa, kullanıcının değişen sorusunu sona koyar. Promptu bu şekilde yapılandırmanın yöntemlerini prompt engineering nedir ve sistem promptu nedir yazılarında ele alıyoruz.

Önbelleklemenin bir başka boyutu, yanıt önbelleklemesidir: tamamen aynı sorunun tekrar sorulması durumunda, modeli hiç çağırmadan daha önce üretilmiş yanıtı döndürmek. Sık tekrar eden sorular olan uygulamalarda (örneğin bir SSS botunda) bu, hem maliyeti hem gecikmeyi sıfıra yakın indirir. İki önbellekleme türü de aynı ilkeye dayanır: aynı işi iki kez yapıp iki kez ödememek. Önbellekleme, doğru kurulduğunda, token maliyetini en düşük riskle azaltan tekniktir; çünkü çıktının kalitesini hiç değiştirmez, yalnızca aynı girdiyi ucuzlatır.

Batching, yani toplu işleme, llm maliyet optimizasyonunun en az bilinen ama en yüksek tasarruf potansiyeli taşıyan tekniklerinden biridir. Fikir şudur: sonucun anında gerekmediği işleri tek tek gerçek zamanlı çağrılarla değil, bir toplu iş olarak indirimli bir uç noktaya göndermek. Sağlayıcılar, gecikmeye tolerans gösteren bu toplu işleri kendi altyapılarını daha verimli doldurdukları için belirgin bir indirimle sunar; karşılığında sonuç anında değil, saatler içinde döner.

Batching'in mantığını bir kargo benzetmesiyle düşünebilirsiniz: acil bir belgeyi kurye ile göndermek pahalıdır ama anında ulaşır; aynı belgeyi standart posta ile göndermek çok daha ucuzdur ama birkaç gün sürer. Kritik olan, hangi işin "kurye" (gerçek zamanlı) hangisinin "standart posta" (batch) olduğunu doğru ayırmaktır. Bir kullanıcı ekran karşısında yanıt bekliyorsa bu bir kurye işidir; ama gece boyunca on binlerce belgeyi sınıflandırmak, sonucu sabah hazır olacak bir standart posta işidir.

Batching için ideal aday işler bellidir: gecelik veya periyodik raporlama, büyük belge kümelerini sınıflandırma veya etiketleme, embedding üretimi (bir bilgi tabanını vektörleme), veri zenginleştirme, geriye dönük analiz ve içerik ön işleme. Bu işlerin ortak paydası, sonucun saniyeler içinde değil, saatler içinde gerekmesidir. Buna karşılık sohbet, canlı destek, gerçek zamanlı arama gibi kullanıcının beklediği senaryolar batching'e uygun değildir; oralarda gecikme deneyimi bozar. RAG bilgi tabanı için embedding üretiminin nasıl toplu yapıldığını embedding nedir ve RAG nedir yazılarında bağlamıyla ele alıyoruz.

Gerçek zamanlı çağrı ile batching (toplu işleme) karşılaştırması

Boyut	Gerçek zamanlı çağrı	Batching (toplu işleme)
Gecikme	Saniyeler	Dakikalar-saatler
Birim maliyet	Standart	İndirimli
Uygun iş	Sohbet, canlı destek, arama	Raporlama, sınıflandırma, embedding
Kullanıcı beklentisi	Anlık yanıt	Sonuç sonra hazır
Ölçek avantajı	Düşük	Yüksek (toplu verim)

Batching'in gücü, çoğu kurumsal iş yükünün aslında gerçek zamanlı olmadığını fark etmekte yatar. Ekipler alışkanlıkla her işi gerçek zamanlı çağırır; oysa raporlama, arşiv analizi, toplu sınıflandırma gibi işlerin büyük kısmı gece boyunca çalışabilir. Bu işleri batching'e taşımak, kaliteyi hiç değiştirmeden birim maliyeti belirgin biçimde düşürür. Pratik öneri: iş yükünüzü "kullanıcı bekliyor mu" sorusuyla ikiye ayırın; beklemeyen her şey bir batching adayıdır.

Model routing, yani göreve göre model seçimi, llm maliyet optimizasyonunun en stratejik tekniğidir; çünkü doğrudan çağrı başına birim fiyatı değiştirir. Temel fikir şudur: tek bir güçlü modeli her işe koşmak yerine, her isteği kalite gereksinimini karşılayan en ucuz modele yönlendirmek. Basit bir sınıflandırma veya kısa özet için küçük ve ucuz bir model; karmaşık bir akıl yürütme veya nüanslı bir üretim için güçlü ve pahalı bir model. Böylece ortalama maliyet, işlerin gerçek zorluk dağılımına göre düşer.

Bu neden işe yarar? Çünkü gerçek trafik nadiren tek tiptir. Çoğu uygulamada isteklerin büyük bir bölümü aslında basittir — bir selamlama, bir niyet tespiti, bir kısa yanıt — ve küçük bir modelle mükemmel karşılanır; yalnızca küçük bir azınlık gerçekten güçlü modelin muhakemesini gerektirir. Her işi en pahalı modele göndermek, bu basit çoğunluk için sistematik bir israftır. Model routing, bu israfı ortadan kaldırır: kolay işi ucuza, zor işi pahalıya, ama her işi kalitesine uygun fiyata çözer.

Bir model routing katmanı kurmanın birkaç yolu vardır. En basiti kural tabanlı yönlendirmedir: iş tipine göre statik kurallar (örneğin "sınıflandırma isteği küçük modele, uzun rapor üretimi büyük modele"). Daha gelişmişi sınıflandırıcı tabanlı yönlendirmedir: küçük ve hızlı bir modelin veya bir sınıflandırıcının, gelen isteğin zorluğunu tahmin edip doğru rotaya koyması. En sağlamı ise kademeli yükseltmedir (escalation): işi önce küçük modele göndermek, yanıtın güven skoru düşükse veya bir kalite kontrolünden geçmezse otomatik olarak güçlü modele yükseltmek.

Nasıl Yapılır

Bir model routing katmanı kurma adımları

Göreve göre model seçimini kaliteyi koruyarak devreye almanın temel adımları.

1. 1

   İş tiplerini ve zorluk sınıflarını tanımla

   Trafiğini analiz et; hangi istek tiplerinin basit, hangilerinin karmaşık olduğunu ayır ve her sınıf için bir kalite eşiği belirle.

2. 2

   Aday modelleri eşle

   Her zorluk sınıfına, o eşiği en düşük maliyetle karşılayan bir model ata (basit için küçük, karmaşık için güçlü).

3. 3

   Yönlendirme mantığını kur

   Kural tabanlı, sınıflandırıcı tabanlı veya kademeli yükseltmeli bir yönlendirici seç ve isteği doğru modele koy.

4. 4

   Yükseltme (escalation) kuralı ekle

   Küçük modelin düşük güvenli veya kalite kontrolünden geçmeyen yanıtlarını otomatik olarak güçlü modele yükselt.

5. 5

   Ölç ve ayarla

   Her rotanın kalite ve maliyetini sürekli izle; yanlış yönlendirmeleri bulup eşikleri düzelt.

Model routing'in en büyük riski yanlış sınıflandırmadır: zor bir işin yanlışlıkla küçük modele gitmesi ve kalitenin düşmesi. Bu riski yönetmenin yolu, her rota için net bir kalite eşiği tanımlamak, düşük güvenli yanıtları güçlü modele yükseltmek ve rotayı sürekli ölçmektir. Açık kaynak modelleri kendi altyapınızda çalıştırıp yönlendirmenin bir ucuz ucunu oluşturma seçeneğini açık kaynak LLM nedir yazısında değerlendiriyoruz. İyi kurulmuş bir yönlendirme, ortalama maliyeti düşürürken kaliteyi hedef eşikte tutar.

Model routing ve önbellekleme büyük yapısal kaldıraçlardır; ama her çağrının içinde de kazanılacak token vardır. Prompt sadeleştirme ve çıktı sınırlama, doğrudan gönderilen ve üretilen token sayısını azaltarak token maliyetini düşüren iki incelikli tekniktir. Bunlar küçük görünür ama yüksek trafikte toplamı büyüktür; çünkü her çağrıda tasarruf edilen birkaç yüz token, milyonlarca çağrıda devasa bir kaleme dönüşür.

Prompt sadeleştirme, promptu kaliteye katkısı olmayan kelimelerden arındırmaktır. Ekipler zamanla promptlara katman katman talimat ekler; bunların bir kısmı gereksiz tekrar, aşırı kibar dolgu veya artık işe yaramayan eski kurallardır. Promptu düzenli olarak gözden geçirip özünü koruyarak kısaltmak, kaliteyi düşürmeden girdi token'ını azaltır. Önemli bir ilke, örnekleri (few-shot) gözden geçirmektir: bazen beş örnek yerine iki iyi seçilmiş örnek aynı kaliteyi verir ve girdiyi belirgin biçimde kısaltır. Prompt tasarımının inceliklerini prompt engineering nedir ve prompt nedir yazılarında ele alıyoruz.

Çıktı sınırlama ise modelin ürettiği yanıtın uzunluğunu ihtiyaca göre kısıtlamaktır. Çıktı token'ı genellikle girdiden pahalı olduğu için, gereksiz uzun yanıtlar orantısız maliyet yaratır. Modele açık bir uzunluk yönlendirmesi vermek ("en fazla üç cümlede özetle", "yalnızca istenen alanları JSON olarak döndür") ve teknik olarak bir maksimum çıktı sınırı koymak, hem maliyeti düşürür hem de çoğu zaman yanıtı kullanıcı için daha kullanışlı hale getirir. Serbest bırakılan bir modelin gereğinden uzun ve dağınık yazma eğilimi, hem parayı hem kullanıcının zamanını harcar.

Token azaltma teknikleri ve kaliteye etkisi

Teknik	Nasıl azaltır	Kaliteye etkisi
Prompt sadeleştirme	Gereksiz talimat/dolgu çıkarma	Doğru yapılırsa nötr veya olumlu
Few-shot azaltma	Örnek sayısını optimize etme	İyi seçilmiş azsa nötr
Çıktı sınırlama	Yanıt uzunluğunu kısıtlama	Genellikle olumlu (öz yanıt)
Yapılandırılmış çıktı	Sadece gerekli alanları isteme	Olumlu (net format)
Geçmiş budama	Eski konuşma turlarını özetleme	Dikkatli yapılmazsa riskli

Bu tekniklerde bir uyarı gerekir: sadeleştirme ve sınırlama, kaliteyi bilinçsizce feda etme riski taşır. Prompttan çıkardığınız bir talimat aslında bir hatayı önlüyor olabilir; kestiğiniz bir çıktı aslında gerekli bir ayrıntıyı içeriyor olabilir. Bu yüzden her sadeleştirme, bir değerlendirme kümesiyle test edilmelidir. Altın kural: token'ı kes, ama kaliteyi ölçerek kes. Ölçülmeyen bir sadeleştirme, gizli bir kalite kaybı olabilir.

Büyük bir doküman tabanı üzerinde çalışan uygulamalarda, en büyük gizli maliyet kalemi genellikle bağlamdır. Naif bir yaklaşım, modele geniş bir doküman yığınını (veya tüm bir kılavuzu) bağlam olarak vermektir; bu, her çağrıda devasa bir girdi token'ı faturası yaratır ve modelin dikkatini de dağıtır. RAG (Retrieval-Augmented Generation), tam olarak bu israfı ortadan kaldırarak bir llm maliyet optimizasyonu tekniğine dönüşür: tüm dokümanı değil, yalnızca soruyla ilgili birkaç parçayı getirip bağlama koymak.

RAG'in maliyet etkisi çift yönlüdür. Birincisi, girdi token'ı dramatik biçimde azalır: yüzlerce sayfa yerine yalnızca ilgili birkaç paragraf gönderilir. İkincisi, daha küçük ve odaklı bir bağlam, modelin daha isabetli ve daha kısa yanıt üretmesini sağlar; bu da çıktı token'ını düşürür. Yani RAG hem girdi hem çıktı tarafında tasarruf sağlar. RAG'in nasıl çalıştığını ve mimarisini RAG nedir ve RAG mimarisi nasıl kurulur yazılarında ayrıntısıyla ele alıyoruz.

Ancak RAG'in kendisinin de bir maliyeti vardır ve bu göz ardı edilmemelidir: embedding üretimi (bir kez ve güncellemelerde), vektör veritabanı barındırma ve getirme adımının gecikmesi. Bu yüzden RAG, her senaryoda otomatik olarak ucuz değildir; asıl kazancını, bağlamın büyük ve tekrar eden olduğu, tüm dokümanı her çağrıda göndermenin savurgan olacağı durumlarda verir. Küçük ve sabit bir bağlam için RAG kurmak, gereksiz karmaşıklık ekleyebilir. Embedding üretiminin toplu (batch) yapılabileceğini hatırlayın; bu, RAG kurulum maliyetini de düşürür.

Bazı iş yükleri için en ucuz çözüm, büyük bir modeli optimize etmek değil, küçük bir modeli o işe özel eğitmektir. Küçük model artı fine-tuning, özellikle yüksek hacimli, dar ve tekrar eden görevlerde güçlü bir llm maliyet optimizasyonu stratejisidir. Fikir şudur: büyük bir modelin genel yeteneklerinin çoğuna ihtiyaç duymayan bir görev için (örneğin belge sınıflandırma, niyet tespiti, belirli bir formata çevirme), küçük bir modeli bu göreve özel örneklerle eğitmek, çok daha düşük birim maliyetle benzer kaliteyi verebilir.

Bu neden çalışır? Çünkü büyük modelin fiyatının bir kısmı, sizin görevinizde hiç kullanmadığınız geniş genel yetenekler içindir. Dar bir görev için o genel yeteneğe ödeme yapmak israftır; küçük bir modeli o dar göreve odaklayarak eğitmek, hem çağrı başına ucuzdur hem de genellikle daha hızlıdır. Fine-tuning'in ne olduğunu ve ne zaman uygun olduğunu fine-tuning nedir ve karar çerçevesini RAG mi fine-tuning mi yazılarında derinleştiriyoruz.

Ancak bu strateji her senaryoda kazandırmaz; bir eşik meselesidir. Fine-tuning'in bir kurulum maliyeti (veri hazırlama, eğitim, değerlendirme) ve bir bakım maliyeti (görev değişince yeniden eğitim) vardır. Bu maliyetlerin geri dönmesi için, görevin yeterince yüksek hacimli olması gerekir; günde birkaç yüz çağrılık bir iş için fine-tuning'in kurulum maliyeti geri dönmez, orada büyük bir modeli routing ve önbelleklemeyle kullanmak daha pratiktir. Karar, birim iş maliyetini iki senaryo için de ölçüp karşılaştırmakla verilir.

Büyük model + optimizasyon ile küçük model + fine-tuning karşılaştırması

Kriter	Büyük model + optimizasyon	Küçük model + fine-tuning
En uygun iş	Çeşitli, açık uçlu, düşük hacim	Dar, tekrar eden, yüksek hacim
Kurulum maliyeti	Düşük	Yüksek (veri + eğitim)
Birim çağrı maliyeti	Yüksek	Düşük
Bakım	Prompt güncelleme	Görev değişince yeniden eğitim
Esneklik	Yüksek	Göreve özel, dar

Pratik bir strateji, ikisini birleştirmektir: yüksek hacimli dar görevleri fine-tuned küçük modele, çeşitli ve nadir işleri optimize edilmiş büyük modele yönlendirmek. Bu, model routing'in bir uzantısıdır ve iki dünyanın en iyisini verir: sık işlerde düşük birim maliyet, nadir işlerde esneklik. Böyle bir hibrit mimari, olgun bir llm maliyet optimizasyonu programının işaretidir.

Buraya kadar yedi tekniği ayrı ayrı inceledik; şimdi onları bir arada, karar verme perspektifinden görelim. Bir llm maliyet optimizasyonu programında yanlış soru "hangi teknik en iyisi" sorusudur; doğru soru "benim maliyet profilime hangi teknik en çok dokunuyor" sorusudur. Çünkü her tekniğin en yüksek etkiyi verdiği bir senaryo vardır ve teknikleri önceliklendirmenin tek doğru yolu, ölçülen en büyük maliyet kaleminden başlamaktır.

Aşağıdaki tablo, tipik maliyet profillerini ve her biri için önce hangi tekniğe bakılması gerektiğini özetler. Bu bir reçete değil, bir başlangıç haritasıdır; her kurumun kendi ölçümüyle doğrulaması gerekir. Yine de deneyimli bir mühendisin sezgisini kodlar: sabit bağlam baskınsa önbellekleme, karışık zorluk baskınsa routing, toplu iş baskınsa batching öne çıkar.

Maliyet profiline göre önceliklendirilecek teknikler (illüstratif başlangıç haritası)

Maliyet profili	Önce bak	Sonra ekle
Uzun sabit sistem promptu	Prompt caching	Prompt sadeleştirme
Karışık zorlukta yoğun trafik	Model routing	Küçük model + fine-tuning
Acil olmayan toplu işler	Batching	Çıktı sınırlama
Büyük doküman tabanı	RAG ile bağlam kısaltma	Prompt caching
Uzun serbest yanıtlar	Çıktı sınırlama	Model routing
Yüksek hacimli dar görev	Küçük model + fine-tuning	Batching

Bu haritanın gösterdiği en önemli ders şudur: optimizasyon önceliği tahminle değil ölçümle belirlenir. İki farklı uygulama, tamamen farklı en büyük kalemlere sahip olabilir; birinde bağlam şişkinliği baskınken diğerinde model seçimi baskın olabilir. Bu yüzden herhangi bir tekniği uygulamadan önce, maliyeti model ve özellik bazında kırıp en büyük kalemi bulmak, her zaman ilk adımdır. Yanlış kaleme yapılan mükemmel bir optimizasyon, doğru kaleme yapılan ortalama bir optimizasyondan daha az kazandırır.

Tekniklerin nasıl birleştiğini somutlaştırmak için varsayımsal bir örnek üzerinden gidelim. Önemli uyarı: aşağıdaki tüm sayılar tamamen illüstratiftir ve gerçek fiyat veya benchmark değildir; amaçları yalnızca tekniklerin nasıl katmanlandığını göstermektir. Kendi tasarrufunuzu mutlaka kendi trafiğiniz, prompt yapınız ve kalite eşiğinizle A/B ölçerek doğrulayın.

Varsayalım ki bir kurumsal destek asistanı işletiyorsunuz. Her çağrıda uzun bir sistem promptu (marka kuralları, ürün bilgisi, örnekler) ve kullanıcının sorusu güçlü bir modele gönderiliyor; günde yüz binlerce çağrı var ve fatura hızla büyüyor. Başlangıç durumu: her çağrı tam bağlamla, tek ve pahalı bir modele, çıktı sınırı olmadan gidiyor. Bu, optimize edilmemiş bir temel senaryodur.

Şimdi teknikleri katman katman ekleyelim (tüm oranlar varsayımsal): Önce prompt caching — sabit sistem promptu artık her çağrıda değil, bir kez işleniyor ve sonraki çağrılarda indirimli faturalanıyor; tekrar eden büyük ön ek olduğu için bu tek başına girdi maliyetinde belirgin bir düşüş yaratıyor. Sonra model routing — çağrıların büyük bir bölümünün aslında basit olduğunu ölçüyorsunuz ve bunları küçük bir modele yönlendiriyorsunuz; yalnızca karmaşık azınlık güçlü modele gidiyor, ortalama birim fiyat düşüyor.

Ardından çıktı sınırlama — yanıtların gereksiz uzun olduğunu görüp öz ve net yanıt yönlendirmesi ekliyorsunuz; çıktı token'ı azalıyor. Sonra prompt sadeleştirme — sistem promptundaki gereksiz tekrarları ve işe yaramayan eski kuralları temizliyorsunuz; girdi biraz daha küçülüyor. Son olarak gecelik raporlama ve toplu sınıflandırma işlerini batching'e devrediyorsunuz; bu toplu işler indirimli çalışıyor. Her katman farklı bir maliyet kalemine dokunduğu için etkiler toplanıyor ve toplam fatura, kaliteyi hedef eşikte tutarken belirgin biçimde düşüyor.

Bu senaryonun asıl dersi, tekniklerin sırasında ve birleşiminde saklıdır. Dikkat edin: hiçbir katman tek başına faturayı çözmez; asıl kazanç, her tekniğin farklı bir kaleme dokunması ve etkilerin çarpışmadan üst üste binmesidir. Önbellekleme girdinin sabit kısmını, model routing birim fiyatı, çıktı sınırlama üretimi, sadeleştirme değişken girdiyi, batching ise tüm çağrıyı ucuzlatır; bunlar farklı eksenler olduğu için birbirini engellemez. Ayrıca sıra da önemlidir: önce ölçüp en büyük kalemden başlamak, aynı eforla çok daha büyük tasarruf getirir. Aynı beş tekniği rastgele sırayla ve ölçmeden uygulayan bir ekip, çok daha az kazanır; çünkü belki de en büyük kalemi hiç ellemeden küçük kalemlerle uğraşır. İşte bu yüzden llm maliyet optimizasyonu bir teknik listesi değil, ölçüme dayalı bir önceliklendirme disiplinidir.

Buraya kadarki tüm teknikler, tek bir ön koşula dayanır: ölçüm. Ölçülmeyen bir maliyet ne yönetilebilir ne de optimize edilebilir. LLM FinOps, bulut maliyet yönetiminin (FinOps) disiplinini token ekonomisine uyarlayan pratiktir ve olgun bir llm maliyet optimizasyonu programının bel kemiğidir. Tekniklerden önce kurulması gereken şey, bu ölçüm ve gözlemlenebilirlik altyapısıdır; çünkü nereye müdahale edeceğinizi ancak ölçerek bilirsiniz.

FinOps'un ilk adımı etiketlemedir: her LLM çağrısına, hangi modelin kullanıldığı, hangi özelliğe/uygulamaya ait olduğu, hangi kullanıcı segmentinden geldiği ve girdi-çıktı token sayıları gibi meta verileri iliştirmek. Bu etiketler olmadan fatura, tek ve anlamsız bir toplamdır; etiketlerle ise maliyeti model bazında, özellik bazında ve segment bazında kırabilir, en büyük kalemi bulabilirsiniz. Bu kırılım, optimizasyonun nereden başlayacağını söyleyen haritadır.

İkinci adım, doğru metrikleri panoya taşımaktır. Ham toplam fatura yeterli değildir; asıl önemli olan birim metriklerdir: istek başı maliyet, birim iş başına maliyet (örneğin çözülen destek talebi başına maliyet, işlenen belge başına maliyet), kullanıcı başına maliyet. Bu birim metrikler, maliyeti iş değeriyle ilişkilendirir ve "fatura büyüdü ama iş de büyüdü mü, yoksa verimlilik mi düştü" sorusuna cevap verir. Üçüncü adım, anomali ve ani artışlar için uyarı kurmaktır: bir kod değişikliğinin veya bir promptun yanlışlıkla maliyeti patlatması, ancak izleme varsa erken yakalanır. Bu izleme disiplininin genel çerçevesini LLMOps nedir ve model davranışını üretimde gözlemlemeyi LLM gözlemlenebilirliği nedir yazılarında ele alıyoruz.

LLM FinOps'ta izlenmesi gereken temel metrikler

Metrik	Ne söyler	Neden önemli
İstek başı maliyet	Ortalama çağrı maliyeti	Optimizasyon etkisini gösterir
Birim iş başına maliyet	İş değeri başına maliyet	Maliyeti değere bağlar
Model bazında kırılım	Hangi model ne harcıyor	Routing fırsatını bulur
Girdi/çıktı oranı	Token dağılımı	Sadeleştirme fırsatı
Önbellek isabet oranı	Önbeklemenin verimi	Caching etkinliğini ölçer

FinOps'un son ilkesi süreklilik ve sahiplenmedir. Maliyet izleme bir kez kurulup unutulan değil, düzenli olarak gözden geçirilen yaşayan bir disiplindir; ve bunun bir sahibi olmalıdır. "Herkesin işi olan, kimsenin işi değildir" tuzağı LLM maliyetinde özellikle yaygındır. Kaliteyle birlikte maliyeti düzenli gözden geçiren bir ritim (örneğin haftalık bir inceleme), tasarrufu kalıcı kılar. Kurumsal AI bütçesini planlarken bu izleme disiplininin rolünü kurumsal AI bütçesi planlama yazısında ele alıyoruz.

Her llm maliyet optimizasyonu kararının gölgesinde bir gerilim vardır: maliyeti düşürmek çoğu zaman kaliteyi tehdit eder. Küçük modele geçmek, promptu kısaltmak, çıktıyı sınırlamak — bunların her biri, dikkatsiz yapılırsa kaliteyi düşürebilir. Bu yüzden optimizasyonun asıl becerisi, maliyeti düşürmek değil; belirli bir kalite eşiğini koruyarak maliyeti düşürmektir. Kalite bir kısıt, maliyet ise amaç fonksiyonudur.

Bu dengeyi kurmanın tek sağlam yolu ölçümdür. Önce bir kalite eşiği tanımlarsınız: temsili bir soru-cevap değerlendirme kümesi ve kabul edilebilir minimum kalite. Sonra her optimizasyon değişikliğini bu küme üzerinde A/B test edersiniz: değişiklik kaliteyi eşiğin altına düşürüyorsa geri alırsınız, düşürmüyorsa tutarsınız. Böylece tasarruf, kaliteyi bilinçsizce feda etmeden yapılır. Modelin çıktısını sistematik değerlendirmenin yöntemlerini LLM değerlendirme nedir yazısında ele alıyoruz.

Kalite eşiğinin uygulamaya göre değiştiğini de unutmamak gerekir. Bir eğlence sohbet botunda kalite eşiği görece esnek olabilir ve agresif optimizasyona alan tanır; ama bir hukuki analiz veya tıbbi bilgi asistanında kalite eşiği çok yüksektir ve optimizasyon çok daha temkinli yapılmalıdır. Yani "ne kadar optimize edilebilir" sorusunun cevabı, işin kritikliğine bağlıdır. Yüksek riskli uygulamalarda maliyeti düşürmek için kaliteyi feda etmek, kısa vadeli tasarruf uğruna uzun vadeli güveni yakmaktır.

Türkiye'de faaliyet gösteren kurumlar için llm maliyet optimizasyonu, yalnızca token fiyatıyla değil, veri egemenliği ve KVKK (Kişisel Verilerin Korunması Kanunu) uyumuyla da iç içedir. Çünkü maliyet kararı çoğu zaman "hangi model" değil, "modeli nerede çalıştırırım" sorusuyla başlar: hazır bir bulut API'si mi, yoksa kendi altyapınızda (on-premises veya özel bulut) çalıştırdığınız açık kaynak bir model mi? Bu seçim hem maliyeti hem uyumu doğrudan etkiler. Aşağıdaki çerçeve bilgilendirme amaçlıdır, hukuki tavsiye değildir.

Bulut API'lerinin maliyet avantajı, sıfır kurulum ve kullandıkça öde modelidir: altyapı yönetmezsiniz, yalnızca token'ı ödersiniz; düşük ve orta hacimde bu genellikle en ucuz seçenektir. Dezavantajı, kişisel veya hassas veri işleniyorsa verinin nereye gittiği ve KVKK yükümlülükleridir. Buna karşılık açık kaynak bir modeli kendi altyapınızda çalıştırmak, yüksek hacimde birim maliyeti düşürebilir ve veriyi kurum sınırları içinde tutarak veri egemenliği sağlar; ama donanım, GPU ve operasyon maliyeti getirir. GPU'nun bu denklemdeki rolünü GPU nedir ve açık kaynak model seçeneğini açık kaynak LLM nedir yazısında ele alıyoruz.

Maliyet açısından kritik bir denge noktası hacimdir. Düşük hacimde bulut API'si neredeyse her zaman daha ekonomiktir; çünkü kendi altyapınızın sabit maliyeti (donanım, bakım, uzmanlık) az sayıda çağrıya bölününce birim maliyet yükselir. Ama hacim belirli bir eşiği aştığında, kendi altyapınızda açık kaynak model çalıştırmanın birim maliyeti bulut API'sinin altına inebilir. KVKK bir kısıt olarak devredeyse, denklem yalnızca maliyetle değil, uyum riskiyle de kurulur; bazı kurumlar için veriyi yurt içinde ve kurum sınırında tutmak, saf token maliyetinden daha ağır basar.

Bulut API ile kendi altyapıda açık kaynak model: maliyet ve KVKK boyutları

Boyut	Bulut API	Kendi altyapıda açık kaynak
Kurulum maliyeti	Düşük (sıfıra yakın)	Yüksek (donanım + kurulum)
Düşük hacimde	Genellikle daha ucuz	Sabit maliyet ağır basar
Yüksek hacimde	Token maliyeti birikir	Birim maliyet düşebilir
Veri egemenliği	Sağlayıcıya bağlı	Kurum sınırında
KVKK kontrolü	Sözleşme + inceleme gerekir	Daha doğrudan kontrol

Türkiye'nin üretken yapay zeka benimsemesindeki öncü konumu, bu maliyet-uyum dengesini daha da güncel kılıyor. We Are Social "Digital 2026" verilerine göre Türkiye, üretken yapay zeka araçlarından web'e yönlendirilen trafik payında dünya birincisidir; bu yüksek benimseme, kurumların LLM uygulamalarını hızla ölçeklendireceği ve dolayısıyla maliyet optimizasyonunun kritikleşeceği anlamına gelir. KVKK ile uyumlu bir mimari kurmanın maliyet boyutunu, kurum içi bir program tasarımıyla birlikte planlamak en sağlıklı yaklaşımdır; bu, hem token maliyetini hem uyum riskini birlikte yönetmeyi gerektirir.

Aşağıdaki kontrol listesi, bir llm maliyet optimizasyonu programını fikirden üretime sağlam biçimde yürütmenin pratik bir rehberidir. Bu adımları sırayla işaretleyebiliyorsanız, hem ölçülebilir hem sürdürülebilir bir tasarruf temeli kurmuşsunuz demektir. Sıranın önemli olduğuna dikkat edin: ölçüm her zaman tekniklerden önce gelir.

Nasıl Yapılır

LLM maliyet optimizasyonu uygulama kontrol listesi

Bir LLM uygulamasının maliyetini kaliteyi koruyarak, ölçülebilir biçimde düşürmenin adım adım kontrol listesi.

1. 1

   Ölçüm altyapısını kur

   Her çağrıyı model, özellik, segment ve girdi-çıktı token sayısıyla etiketle; istek başı ve birim iş başına maliyeti panoya taşı.

2. 2

   En büyük maliyet kalemini bul

   Maliyeti model ve özellik bazında kır; optimizasyonu tahminle değil, ölçülen en büyük kalemle önceliklendir.

3. 3

   Bir kalite eşiği tanımla

   Temsili bir değerlendirme kümesi ve kabul edilebilir minimum kalite belirle; her değişikliği bu kümeyle A/B test et.

4. 4

   Prompt caching'i uygula

   Sabit bağlamı başa, değişkeni sona koy; tekrar eden sistem promptu ve dokümanları önbelleğe al.

5. 5

   Model routing kur

   İş tiplerini zorluk sınıflarına ayır; her işi eşiğini karşılayan en ucuz modele yönlendir, yükseltme kuralı ekle.

6. 6

   Prompt sadeleştir ve çıktıyı sınırla

   Gereksiz talimat ve örnekleri çıkar; yanıt uzunluğunu ve formatını ihtiyaca göre kısıtla.

7. 7

   Uygun işleri batching'e devret

   Acil olmayan toplu işleri (raporlama, sınıflandırma, embedding) indirimli toplu uç noktalara taşı.

8. 8

   Ölç, doğrula, tekrarla

   Her katmanın tasarrufunu ve kaliteye etkisini ölç; kaliteyi koruyanları tut, sürekli gözden geçir.

Bu kontrol listesini küçük bir kapsamda uygulamak, büyük bir dönüşüm vaadinden çok daha değerlidir; çünkü ölçülebilir küçük bir tasarruf, belirsiz büyük bir plandan her zaman daha ikna edicidir. Bir LLM uygulamasının maliyetini uçtan uca optimize etmek ve doğru teknik yığınını seçmek için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu yetkinliği kazanması için kurumsal eğitim seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.

Bir llm maliyet optimizasyonu programını olgunlaştırırken, tekniklerin hepsini aynı anda açmak değil, doğru sırayla eklemek gerekir. Karmaşıklığı erken eklemek, RAG projelerinde olduğu gibi maliyet optimizasyonunda da yaygın bir hatadır; her yeni katman, bir bakım ve hata ayıklama yükü getirir. Bu yüzden bir olgunluk yolculuğu, en düşük efor-en yüksek etki tekniğinden başlar ve ihtiyaç ölçüldükçe ilerler.

Tipik bir olgunluk sırası şöyledir. Önce ölçüm: hiçbir teknik uygulanmadan, maliyet model ve özellik bazında kırılır ve en büyük kalem bulunur. Sonra düşük riskli hızlı kazançlar: prompt caching ve çıktı sınırlama, kaliteyi neredeyse hiç etkilemeden hızlı tasarruf verir. Ardından yapısal kaldıraçlar: model routing ve prompt sadeleştirme, biraz daha mühendislik gerektirir ama büyük etki yaratır. Son olarak ileri teknikler: RAG ile bağlam kısaltma ve küçük model artı fine-tuning, en yüksek kurulum maliyetine sahip olduğu için ancak ihtiyaç netleştiğinde eklenir.

Bu sıralamanın mantığı, her adımın bir öncekinin üzerine inşa edilmesi ve yalnızca ölçülen bir ihtiyaç olduğunda eklenmesidir. Örneğin, model routing kurmadan önce trafiğinizin gerçekten karışık zorlukta olduğunu ölçmelisiniz; eğer tüm işleriniz zaten karmaşıksa, routing size bir şey kazandırmaz. Aynı şekilde, fine-tuning'e geçmeden önce görevin yeterince yüksek hacimli ve dar olduğunu doğrulamalısınız. Her tekniğin bir ön koşulu vardır ve o koşul karşılanmadan teknik uygulanırsa, çözdüğünden fazla sorun yaratır.

LLM maliyetini teoride anlamak kolaydır; asıl zor olan, üretimde kaliteyi bozmadan sürdürülebilir tasarruf sağlamaktır. Deneyimli bir gözle bakıldığında, başarısız optimizasyon çabaları benzer hatalarla tökezler. En yaygınları şunlardır:

• Ölçmeden optimize etmek: En yaygın hata, maliyeti kırıp en büyük kalemi bulmadan tahmine dayalı optimizasyon yapmaktır. Yanlış kaleme yapılan mükemmel bir optimizasyon, doğru kaleme yapılan ortalama bir optimizasyondan az kazandırır.
• Kaliteyi bilinçsizce feda etmek: Bir değerlendirme kümesi olmadan agresif kısıntı yapmak, faturayı düşürür ama kaliteyi sessizce bozar; kayıp ancak kullanıcı şikayetleri biriktiğinde görülür.
• Her işe en pahalı modeli koşmak: Tek bir güçlü modeli her işe kullanmak kurulumu basitleştirir ama basit işlerin çoğunluğu için sistematik bir israftır; model routing'i atlamak büyük bir kayıptır.
• Bağlam şişkinliğini görmezden gelmek: "Ne olur ne olmaz, hepsini koyalım" refleksiyle promptu şişirmek, her çağrıda kaliteye katkısız token faturalar.
• Önbeklemeyi yanlış tasarlamak: Değişken kısmı prompt'un başına koymak, sonrasını önbellekleklenemez kılar; önbellekleme kurulu görünse de fiilen çalışmaz.
• Batching fırsatını kaçırmak: Acil olmayan toplu işleri gerçek zamanlı çağırmak, hiçbir kalite kazancı olmadan indirim fırsatını harcar.
• Çıktıyı sınırsız bırakmak: Modele "istediğin kadar yaz" demek, çıktı token'ını ve çıktı pahalı olduğu için maliyeti orantısız şişirir.
• Optimizasyonu bir kerelik proje sanmak: Maliyet, trafik ve promptlar değiştikçe evrilir; bir kez optimize edip unutmak, tasarrufun zamanla erimesine yol açar.

En pratik yol, küçük bir kapsamla başlayıp ölçerek büyümektir. Tüm uygulamayı bir anda optimize etmeye çalışmak yerine, en büyük maliyet kalemine sahip tek bir özellikten başlamak, riski düşürür ve öğrenmeyi hızlandırır. Küçük ama ölçülmüş bir tasarruf, büyük ama belirsiz bir vaatten her zaman daha değerlidir.

Bir llm maliyet optimizasyonu değişikliğinin gerçekten kazandırdığını nasıl bilirsiniz? Cevap, tahminle değil, kontrollü ölçümle. Bir tekniği uygulayıp "herhalde tasarruf ettik" demek, hem tasarrufun büyüklüğü hem de kaliteye etkisi konusunda körlemesine ilerlemektir. Sağlam bir doğrulama, iki şeyi aynı anda ölçer: maliyet düşüşü ve kalite koruması. İkisinden biri eksikse, sonuç güvenilir değildir.

Doğrulamanın omurgası A/B karşılaştırmasıdır. Bir değişikliği (örneğin küçük modele geçiş) tüm trafiğe uygulamadan önce, trafiğin bir bölümünde eski ve yeni yapılandırmayı paralel çalıştırıp hem maliyeti hem kaliteyi karşılaştırırsınız. Kalite, temsili bir değerlendirme kümesiyle ölçülür; maliyet, istek başı ve birim iş başına metriklerle. Bu karşılaştırma, "yeni yapılandırma kaliteyi eşikte tutarken maliyeti gerçekten düşürüyor mu" sorusuna kanıta dayalı cevap verir. Model çıktısını değerlendirmenin yöntemlerini LLM değerlendirme nedir yazısında ele alıyoruz.

Benchmark konusunda kritik bir uyarı gerekir: internetteki genel benchmark sayıları ve "şu teknik yüzde şu kadar tasarruf sağlar" iddiaları, sizin uygulamanız için doğrudan geçerli değildir. Her uygulamanın trafik dağılımı, prompt yapısı, kalite eşiği ve sağlayıcı fiyatları farklıdır; bu yüzden başkasının benchmark'ı sizin için ancak bir hipotezdir, bir sonuç değil. Tek güvenilir benchmark, kendi trafiğiniz üzerinde, kendi değerlendirme kümenizle yaptığınız ölçümdür. Bu rehberdeki tüm oransal ifadeler de bu nedenle illüstratiftir; onları birer başlangıç hipotezi olarak alın, birer vaat olarak değil.

Doğrulamanın sürekliliği de önemlidir. Bir kez ölçülüp geçilen bir optimizasyon, zamanla geçerliliğini yitirebilir: trafik değişir, promptlar evrilir, model güncellenir, fiyatlar değişir. Bu yüzden bir "maliyet-kalite regresyon testi" kurup her önemli değişiklikte tekrar çalıştırmak, hem tasarrufun hem kalitenin sessizce bozulmasını önler. Ölçmek bir kerelik bir eylem değil, sürekli bir disiplindir; ve bu disiplin, llm maliyet optimizasyonunu bir tahmin oyunundan bir mühendislik pratiğine dönüştüren şeydir.

Klasik prompt caching, ortak bir sabit ön eki tam eşleşme üzerinden ucuzlatır; ama bir de daha ileri bir önbellekleme türü vardır: semantik önbellekleme (semantic caching). Fark şudur: klasik önbellekleme yalnızca metin birebir aynıysa çalışır, semantik önbellekleme ise anlamca yeterince benzer sorular için önceden üretilmiş yanıtı yeniden kullanır. Böylece "iade politikası nedir" ile "ürünü nasıl iade ederim" gibi farklı kelimelerle sorulan aynı soru, tek bir önbellek girdisiyle karşılanabilir ve model hiç çağrılmadan yanıt döner.

Semantik önbellekleme, embedding ve benzerlik araması üzerine kurulur: gelen soru bir vektöre çevrilir, önbellekteki önceki soruların vektörleriyle karşılaştırılır ve benzerlik belirli bir eşiği aşarsa kayıtlı yanıt döndürülür. Bu, RAG'in getirme mantığının maliyet optimizasyonuna uyarlanmış halidir; embedding kavramını embedding nedir ve benzerlik aramasını semantik arama nedir yazılarında ele alıyoruz. Sık ve benzer soruların yoğun olduğu uygulamalarda (destek botları, SSS asistanları) semantik önbellekleme, hem token maliyetini hem gecikmeyi belirgin biçimde düşürebilir.

Ancak semantik önbellekleme dikkatli bir eşik ayarı gerektirir ve bir riski vardır: benzerlik eşiği çok gevşek tutulursa, aslında farklı olan iki soru aynı kabul edilir ve kullanıcıya yanlış bir önbellek yanıtı döner. Bu yüzden semantik önbellekleme, kritik doğruluk gerektiren senaryolarda temkinli kullanılmalı ve mutlaka bir değerlendirme kümesiyle test edilmelidir. Doğru eşikle kurulduğunda ise, klasik önbelleklemenin ulaşamadığı bir tasarruf katmanı açar; yani her çağrının başındaki tekrarı değil, çağrılar arasındaki yanıt tekrarını da ucuzlatır: yalnızca birebir aynı değil, anlamca aynı soruları da ucuzlatır.

Son yıllarda LLM uygulamaları tek çağrılık soru-cevaptan, çok adımlı ajan (agent) mimarilerine evriliyor. Bir ajan; planlar, araç çağırır, sonucu değerlendirir ve gerekirse tekrar dener. Bu güçlü bir yetenektir; ama llm maliyet optimizasyonu açısından ciddi bir tehlike de barındırır: bir ajanın tek bir kullanıcı isteği için onlarca model çağrısı yapması, maliyeti tek çağrılık bir uygulamaya göre katlarca artırabilir. Ajan mimarilerinin temelini AI agent nedir ve agentic AI nedir yazılarında ele alıyoruz.

Maliyetin patlama nedeni, adımların çarpan etkisidir. Klasik bir uygulamada bir kullanıcı isteği bir model çağrısıdır; bir ajanda ise aynı istek, planlama, birkaç araç çağrısı, ara değerlendirmeler ve nihai üretim olarak on veya daha fazla çağrıya bölünebilir. Üstelik her adım, önceki adımların çıktısını bağlam olarak taşıdığı için girdi token'ı da adım adım büyür. Kontrolsüz bir ajan, bir döngüye girip aynı işi tekrar tekrar deneyerek maliyeti sessizce şişirebilir; bu, en pahalı ve en fark edilmesi zor maliyet kalemlerinden biridir.

Ajan maliyetini kontrol etmenin birkaç yolu vardır. Birincisi adım bütçesidir: bir ajana bir istek için yapabileceği maksimum çağrı sayısı veya token bütçesi koymak; bütçe aşılırsa ajan durur veya bir insana devreder. İkincisi model routing'in ajan içinde uygulanmasıdır: planlama ve basit ara adımları küçük bir modele, yalnızca kritik muhakeme adımını güçlü modele yönlendirmek. Üçüncüsü ara sonuçların önbelleklenmesi ve gereksiz araç çağrılarının elenmesidir; aynı ara bilgiyi iki kez üretmemek, ajan maliyetinde gözden kaçan ama önemli bir tasarruf kalemidir. Bu tekniklerle bir ajan, gücünü korurken maliyeti öngörülebilir sınırlar içinde tutabilir.

LLM maliyet optimizasyonu yalnızca bir mühendislik problemi değil, aynı zamanda bir sahiplenme problemidir. Bir programın başarısız olmasının en yaygın nedenlerinden biri, maliyetin "herkesin işi ama kimsenin sorumluluğu olmaması"dır. Kim maliyeti izliyor, kim optimizasyon kararlarını veriyor, kim kalite eşiğini koruyor? Bu sorular baştan yanıtlanmazsa, tasarruf çabaları dağınık kalır ve sürdürülemez. Bu yüzden olgun bir program, teknikler kadar rolleri de netleştirir.

Tipik bir maliyet optimizasyonu programında birkaç rol öne çıkar. AI mühendisi: Önbellekleme, routing, prompt sadeleştirme gibi teknikleri kurar ve ölçer; teknik kaldıraçların sahibidir. FinOps/veri sahibi: Maliyet panosunu, etiketlemeyi ve birim metrikleri yönetir; "en büyük kalem nerede" sorusunun cevabını taşır. Ürün sahibi: Kalite eşiğini ve iş önceliklerini tanımlar; hangi uygulamada ne kadar optimizasyona alan olduğuna karar verir. Uyum/hukuk sorumlusu: KVKK ve veri egemenliği kısıtlarını belirler; bulut mu on-premises mi kararının uyum boyutunu taşır.

Bu rollerin ötesinde, çoğu programda eksik olan kritik bir sorumluluk vardır: optimizasyon sahipliği. Maliyet ve kalite zamanla değiştiği için, birinin sürekli olarak panoyu izlemesi, anomalileri yakalaması ve tasarrufun erimediğini doğrulaması gerekir. Bu sorumluluk kimseye verilmezse, tasarruf sessizce erir ve kimse fark etmez. Ekiplerin bu yetkinlikleri kazanması için gereken eğitim çerçevesini kurumsal yapay zeka eğitimi nedir yazısında ele alıyoruz. Küçük bir kurumda bu roller tek kişide birleşebilir; büyük bir kurumda ayrı ekipler olabilir. Önemli olan rol sayısı değil, her sorumluluğun bilinçli biçimde birine verilmesidir.

Bir LLM uygulamasını üretime almadan önce cevaplanması gereken kritik bir soru vardır: bu uygulama ölçekte ne kadara mal olacak? Maliyet tahmini yapılmadan başlatılan projeler, çoğu zaman bütçe masasında sürprizle karşılaşır. İyi bir llm maliyet optimizasyonu programı, yalnızca mevcut maliyeti düşürmekle kalmaz; gelecekteki maliyeti öngörülebilir kılar. Bu, teknik bir egzersiz olduğu kadar bir planlama disiplinidir.

Maliyet tahmininin temel formülü basittir ama girdileri dikkatli tahmin gerektirir: beklenen çağrı hacmi (günlük/aylık istek sayısı) çarpı çağrı başına ortalama maliyet (ortalama girdi ve çıktı token'ı çarpı birim fiyatlar). Buradaki en zor değişken çağrı başına ortalama token'dır; bunu doğru tahmin etmek için tipik bir prompt ve tipik bir yanıt üzerinden gerçek token sayımı yapmak gerekir. Token kavramını ve sayımını token nedir yazısında ele alıyoruz. Tahmini, optimizasyon öncesi ve sonrası için ayrı ayrı yapmak, tekniklerin bütçeye etkisini de gösterir.

Bütçelemede sık yapılan hata, doğrusal olmayan büyümeyi hesaba katmamaktır. Bir uygulama başarılı olursa trafik beklenenden hızlı büyür; ve optimizasyon yapılmamışsa maliyet trafikle doğru orantılı, hatta bağlam şişkinliği nedeniyle daha hızlı artar. Bu yüzden bütçe, iyimser değil, birkaç senaryo (düşük, orta, yüksek benimseme) üzerinden kurulmalıdır. Kurumsal AI bütçesini bütünsel planlamanın çerçevesini kurumsal AI bütçesi planlama yazısında ele alıyoruz. Bir güvenlik payı (buffer) ve bir maliyet tavanı (bütçe aşılırsa uyarı veya kısıtlama) eklemek, faturanın kontrolden çıkmasını önler.

LLM maliyet optimizasyonu nedir?

LLM maliyet optimizasyonu, üretimde çalışan büyük dil modeli uygulamalarının token bazlı işletme maliyetini, yanıt kalitesini koruyarak sistematik biçimde düşürme disiplinidir. Prompt caching ile tekrar eden bağlamın yeniden faturalanmasını önlemek, batching ile acil olmayan işleri indirimli toplu uç noktalarda çalıştırmak, model routing ile her işi kalitesini karşılayan en ucuz modele yönlendirmek, prompt sadeleştirme ve çıktı sınırlama ile token sayısını azaltmak başlıca kaldıraçlardır. Amaç, harcamayı körlemesine kısmak değil; her harcanan token'ın bir değer üretmesini sağlamaktır.

Token maliyeti nasıl hesaplanır?

Token maliyeti, bir çağrıda gönderilen girdi (input) token'ları ile modelin ürettiği çıktı (output) token'larının ayrı ayrı fiyatlanmasıyla oluşur. Çoğu sağlayıcıda çıktı token'ı, girdi token'ından daha pahalıdır; ayrıca prompt caching ile önbelleğe alınmış girdi token'ları indirimli, batching uç noktaları ise tüm çağrı için indirimli fiyatlanır. Bir isteğin maliyeti kabaca (girdi token sayısı × girdi birim fiyatı) + (çıktı token sayısı × çıktı birim fiyatı) şeklindedir. Gerçek birim fiyatlar sağlayıcıya ve modele göre değişir; kendi sağlayıcınızın güncel fiyat sayfasından teyit edin.

Prompt caching (önbellekleme) gerçekten tasarruf sağlar mı?

Evet, tekrar eden ve sabit bir bağlam varsa prompt caching belirgin tasarruf sağlar. Uzun bir sistem promptu, sabit talimatlar, few-shot örnekler veya aynı dokümanın üzerinde çok sayıda soru gibi durumlarda, bu ortak ön ek bir kez işlenir ve sonraki çağrılarda önbellekten indirimli faturalanır. Tasarruf, önbelleğe alınan bölümün toplam girdiye oranıyla artar. Buna karşılık her çağrının girdisi tamamen farklıysa önbellekleme fayda vermez. Bu yüzden promptu, sabit kısım başta, değişken kısım sonda olacak şekilde tasarlamak önbellekleme veriminin anahtarıdır.

Batching ne zaman kullanılır, ne zaman kullanılmaz?

Batching (toplu işleme), sonucun anında gerekmediği, gecikmeye tolerans gösteren işler için idealdir: gecelik raporlama, büyük belge kümelerini sınıflandırma, embedding üretimi, veri zenginleştirme, geriye dönük etiketleme gibi. Bu işler indirimli toplu uç noktalara gönderilir ve maliyet belirgin biçimde düşer; karşılığında sonuç saatler içinde döner. Batching, kullanıcının ekran karşısında yanıt beklediği gerçek zamanlı senaryolar (sohbet, canlı destek, arama) için uygun değildir; oralarda gecikme kullanıcı deneyimini bozar. Pratik kural: acil olmayan her toplu iş batching adayıdır.

Model routing kaliteyi düşürür mü?

Doğru kurulduğunda hayır; yanlış kurulduğunda evet. Model routing (göreve göre model seçimi), basit işleri küçük ve ucuz modele, karmaşık işleri güçlü modele yönlendirir. Kalite, yalnızca işin gerçek zorluğu yanlış sınıflandırıldığında düşer; yani zor bir iş yanlışlıkla küçük modele giderse. Bu riski yönetmenin yolu, her rota için bir kalite eşiği tanımlamak, düşük güvenli yanıtları güçlü modele yükseltmek (escalation) ve rotayı sürekli ölçmektir. İyi kurulmuş bir yönlendirme, ortalama maliyeti düşürürken kaliteyi hedef eşikte tutar; çünkü kolay işlerin çoğu zaten küçük modelle mükemmel yanıtlanır.

En hızlı tasarruf sağlayan LLM maliyet optimizasyonu tekniği hangisidir?

Tek bir evrensel cevap yoktur; en hızlı kazanç, uygulamanızın maliyet profiline bağlıdır. Sabit ve uzun bir sistem promptunuz varsa prompt caching genellikle en düşük eforla en yüksek tasarrufu verir. Trafiğinizin büyük kısmı basit işlerse model routing öne çıkar. Acil olmayan toplu işler baskınsa batching en etkilidir. Bu yüzden ilk adım her zaman ölçümdür: istek başı token maliyetini model ve özellik bazında kırıp, en büyük maliyet kalemini bulmak. Optimizasyon, tahmine göre değil, ölçülen en büyük kaleme göre önceliklendirilmelidir.

Küçük model mi yoksa büyük model + optimizasyon mu daha ucuz?

Bu, işin zorluğuna ve hacmine bağlıdır. Yüksek hacimli, dar ve tekrar eden bir görev için (örneğin belge sınıflandırma veya niyet tespiti) küçük bir modeli fine-tuning ile eğitmek, çoğu zaman büyük bir modeli sürekli çağırmaktan çok daha ucuza aynı kaliteyi verir. Buna karşılık çeşitli, açık uçlu ve düşük hacimli işler için büyük bir modeli prompt caching ve routing ile optimize etmek daha pratiktir; çünkü fine-tuning'in kurulum ve bakım maliyeti düşük hacimde geri dönmez. Karar, birim iş maliyetini iki senaryo için de ölçüp karşılaştırmakla verilir.

LLM maliyetini nasıl izlerim (FinOps)?

LLM FinOps, bulut FinOps disiplinini token ekonomisine uyarlar. Temel adımlar: her çağrıya model, özellik, kullanıcı/segment ve girdi-çıktı token sayısını etiketlemek; istek başı maliyet ve birim iş başına maliyet (örneğin çözülen destek talebi başına maliyet) gibi metrikleri panoya taşımak; anomali ve ani artışlar için uyarı kurmak; ve maliyeti düzenli olarak kaliteyle birlikte gözden geçirmek. Gözlemlenebilirlik olmadan optimizasyon körlemesine yapılır; bu yüzden ölçüm altyapısı, tekniklerden önce kurulmalıdır. Bu, kalıcı ve savunulabilir tasarrufun tek yoludur.

Prompt caching ve batching aynı anda kullanılabilir mi?

Evet, bu teknikler birbirini dışlamaz; aksine birlikte en iyi sonucu verir. Bir LLM maliyet optimizasyonu programı tipik olarak bir teknik yığını kurar: model routing ile doğru modeli seçer, prompt caching ile tekrar eden bağlamı ucuzlatır, prompt sadeleştirme ve çıktı sınırlama ile token'ı azaltır, uygun işleri batching'e devreder ve RAG ile bağlamı kısaltır. Her teknik farklı bir maliyet kalemine dokunduğu için etkileri çoğunlukla toplanır. Önemli olan, hepsini aynı anda körlemesine açmak değil; ölçülen en büyük kalemden başlayıp katman katman eklemektir.

Optimizasyon yaparken kaliteyi nasıl korurum?

Kalite-maliyet dengesini korumanın yolu, her optimizasyon değişikliğini bir değerlendirme (evaluation) kümesiyle A/B test etmektir. Önce temsili bir soru-cevap kümesi ve bir kalite eşiği tanımlarsınız; sonra her değişikliği (küçük modele geçiş, promptu kısaltma, çıktı sınırı) bu küme üzerinde ölçer, kalite eşiğin altına düşüyorsa geri alırsınız. Böylece tasarruf, kaliteyi bilinçsizce feda etmeden yapılır. Optimizasyonun altın kuralı şudur: ölçülmeyen tasarruf, gizli bir kalite kaybı olabilir. Kalite eşiğini önce tanımlayın, sonra maliyeti o eşiğin altında değil, o eşiği koruyarak düşürün.

Özetle, llm maliyet optimizasyonu nedir sorusunun cevabı: üretimde çalışan büyük dil modeli uygulamalarının token bazlı işletme maliyetini, yanıt kalitesini koruyarak sistematik biçimde düşürme disiplini. Bu, tek bir sihirli ayar değil, birbirini tamamlayan tekniklerin bir portföyüdür: prompt caching (önbellekleme) tekrar eden bağlamı ucuzlatır, batching (toplu işleme) acil olmayan işleri indirimli çalıştırır, model routing (göreve göre model seçimi) her işi doğru modele yönlendirir, prompt sadeleştirme ve çıktı sınırlama token'ı azaltır, RAG ile bağlam kısaltma girdiyi küçültür ve küçük model artı fine-tuning yüksek hacimli dar görevleri ucuzlatır.

En önemli mesaj şudur: llm maliyet optimizasyonu bir tahmin değil, bir ölçüm disiplinidir. Başarı, en pahalı tekniği körlemesine uygulamaktan değil; maliyeti kırıp en büyük kalemi bulmaktan, bir kalite eşiği tanımlayıp her değişikliği o eşiğe karşı ölçmekten ve tekniği ölçülen ihtiyaca göre katman katman eklemekten gelir. İyi kurulmuş bir FinOps çerçevesi, doğru önbellekleme, akıllı yönlendirme ve disiplinli ölçüm bir araya geldiğinde, maliyet kaliteyi feda etmeden düşer ve tahmin edilebilir hale gelir.

Temel kavramlar için LLM nedir, token nedir ve context window nedir yazılarına bakabilir; kuruma özel bir llm maliyet optimizasyonu programı ve doğru teknik yığını tasarlamak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz. Unutmayın: en pahalı optimizasyon, hiç ölçülmemiş olandır; en değerli tasarruf ise kaliteyi koruyarak, kanıtla yapılandır.