LLM Maliyet Optimizasyonu: Yapay Zeka Maliyetini Kaliteyi Bozmadan Düşürmek

LLM maliyetini düşürmenin en etkili yolu daha ucuz bir model aramak değil, her isteğin neye harcandığını görmek ve gereksiz token'ı sistemden çıkarmaktır. Pratikte tasarrufun büyük kısmı beş yerden gelir: tekrar eden bağlamı önbelleğe almak, kolay işleri küçük modele yönlendirmek, modele gönderilen bağlamı kırpmak, acil olmayan işleri toplu (batch) çalıştırmak ve yeterli hacim varsa açık ağırlıklı modelleri kendi sunucunuzda çalıştırmak. Bunların hiçbiri, maliyeti "çağrı başına" değil "başarılı iş başına" ölçmeden doğru yönetilemez.

Bu rehber, yapay zeka özelliği canlıda çalışan ve fatura büyüdükçe ne yapacağını düşünen ürün sahipleri, teknik liderler ve CTO'lar için hazırlandı. Önce maliyetin nereden oluştuğunu, ardından her bir optimizasyon tekniğinin ne zaman işe yaradığını ve ne zaman kalite kaybına yol açtığını ele alıyoruz. Yazıdaki rakamların tamamı temsilidir; sağlayıcı fiyatları sık değiştiği için kendi hesabınızı güncel fiyat listesiyle yapmanız gerekir.

LLM maliyeti tam olarak nereden oluşur?

Faturadaki tek satır "token" gibi görünse de yapay zeka maliyeti birkaç farklı kalemin toplamıdır. Hangisinin büyük olduğunu bilmeden yapılan optimizasyon genellikle yanlış yere yatırım olur.

• Girdi token'ları: Sistem talimatı, araç tanımları, RAG ile getirilen doküman parçaları, konuşma geçmişi ve kullanıcının sorusu. Çoğu üretim sisteminde en büyük kalem budur, çünkü aynı uzun bağlam her istekte yeniden gönderilir.
• Çıktı token'ları: Modelin ürettiği metin. Birim fiyatı genellikle girdiden yüksektir. Gereksiz uzun cevaplar, açıklama isteyen formatlar ve "düşünme" token'ları bu kalemi büyütür.
• Tekrar denemeler ve hatalar: Geçersiz JSON, zaman aşımı veya doğrulamadan geçemeyen cevaplar yüzünden yapılan ikinci ve üçüncü çağrılar. Görünmez ama birikir.
• Ajan döngüleri: Araç çağıran bir ajan tek bir kullanıcı isteği için on ya da daha fazla model çağrısı yapabilir. Her adımda bağlam büyür, dolayısıyla maliyet adım sayısıyla doğrusal değil daha hızlı artar.
• Embedding ve arama altyapısı: Dokümanların vektöre çevrilmesi, vektör veritabanı ve yeniden sıralama (reranking) modelleri.
• Barındırma ve operasyon: Kendi sunucunuzda model çalıştırıyorsanız GPU, ölçekleme, izleme ve nöbet maliyeti.
• İnsan kontrolü: Düşük güvenli cevapları düzelten ekip zamanı. Kâğıt üzerinde ucuz görünen bir modelin gerçek maliyeti çoğu zaman burada saklıdır.

Maliyeti neden çağrı başına değil, başarılı iş başına ölçmelisiniz?

Çağrı başına maliyet yanıltıcıdır, çünkü işini yapamayan ucuz bir çağrı bedava değildir. Doğru metrik, kullanıcının işini gerçekten çözen bir sonucun toplam maliyetidir: başarısız denemeler, tekrar çağrılar ve insan düzeltmesi dahil.

Örnek hesap (temsili rakamlarla): Bir doküman sınıflandırma işinde A modeli çağrı başına 1 birim, B modeli 4 birim tutsun. A modeli işlerin yüzde 70'ini doğru yapıyor, kalan yüzde 30'u bir uzmanın 10 birimlik zamanıyla düzeltiliyor. B modeli işlerin yüzde 97'sini doğru yapıyor. A için iş başına ortalama maliyet 1 + 0,30 × 10 = 4 birim; B için 4 + 0,03 × 10 = 4,3 birim. Kâğıt üzerinde dört kat ucuz olan model, iş başına neredeyse aynı maliyete geliyor ve ekibinize daha fazla düzeltme yükü bırakıyor. Hata maliyeti büyüdükçe denge pahalı modelden yana döner.

Bu hesabı yapabilmek için iki şey gerekir: doğruluğu ölçen bir test seti ve her isteğin hangi işe ait olduğunu, başarılı olup olmadığını kaydeden bir izleme katmanı. İkisi yoksa aşağıdaki tekniklerin etkisini de ölçemezsiniz.

Önbellekleme ile LLM maliyeti nasıl düşer?

Önbellekleme, aynı işi iki kez ödememenin adıdır. Üç farklı türü vardır ve her biri farklı bir riski taşır.

Prompt önbelleği (prefix caching)

Büyük model sağlayıcılarının çoğu, art arda gelen isteklerde birebir aynı başlayan bağlamı önbelleğe alır ve o kısmı daha düşük ücretle ya da daha hızlı işler. Sistem talimatı, araç tanımları ve sabit referans dokümanlar her istekte aynıysa bu, kalite kaybı olmadan elde edilen en kolay tasarruftur. Kuralı basittir: değişmeyen içerik bağlamın başına, değişen içerik (kullanıcı sorusu, tarih, oturum bilgisi) sonuna. Sistem talimatının en başına saniyesine kadar güncel bir zaman damgası koymak, önbelleği her istekte bozan yaygın bir hatadır. Sağlayıcıların önbellek süreleri, minimum uzunluk şartları ve fiyatlandırması farklıdır; kullandığınız sağlayıcının dokümantasyonunu kontrol edin ve isabet oranını loglardan izleyin.

Birebir yanıt önbelleği

Aynı girdi aynı cevabı üretmesi gereken işlerde (ürün açıklaması üretmek, sabit bir metni çevirmek, bir dokümanı bir kez özetlemek) cevabın kendisini saklamak modeli hiç çağırmamak demektir. Anahtar olarak girdinin özeti, model adı, prompt sürümü ve parametreler birlikte kullanılmalıdır; prompt değiştiğinde eski cevaplar otomatik olarak geçersiz olmalıdır.

Semantik önbellek

Semantik önbellek, birebir aynı olmayan ama anlamca benzer soruları embedding benzerliğiyle eşleştirip önceki cevabı döndürür. Destek botu gibi aynı soruların farklı kelimelerle tekrar sorulduğu yerlerde ciddi tasarruf sağlayabilir, ama en riskli önbellek türüdür. "Siparişimi iptal edebilir miyim?" ile "Siparişimi iptal edemiyorum" benzer görünür ama farklı cevap ister. Kişiye özel bilgi içeren cevaplar başka kullanıcıya dönebilir, bu da KVKK açısından ciddi bir sorundur. Semantik önbelleği yalnızca genel bilgi cevaplarında, sıkı bir benzerlik eşiğiyle, kullanıcıya özel veri içermeyen kayıtlarla ve süreli geçersiz kılma ile kullanın. Eşiği de tahminle değil, gerçek soru çiftlerinden oluşan bir test setiyle belirleyin.

Model yönlendirme ve kademeli çağrı nasıl çalışır?

Her isteğe en güçlü modeli göndermek, her paketi uçakla taşımaya benzer. Gelen işlerin önemli bir kısmı sınıflandırma, alan çıkarma, kısa özet veya biçim dönüştürme gibi küçük modellerin rahatça yapabildiği işlerdir. İki yaygın desen vardır:

• Yönlendirme (routing): İstek, türüne göre baştan doğru modele gönderilir. Basit bir kural setiyle (iş tipi, girdi uzunluğu, müşteri seviyesi) ya da küçük bir sınıflandırıcı modelle yapılabilir. Kural tabanlı başlamak hem ucuz hem de hatası kolay ayıklanır.
• Kademeli çağrı (cascade): İstek önce küçük modele gider. Cevap bir doğrulamadan geçerse (şema kontrolü, iş kuralı, güven skoru, ikinci bir hızlı kontrol) kullanılır; geçmezse büyük modele yükseltilir. Kolay işlerin çoğu ucuz katmanda biter, zor işler yine doğru cevabı alır.

Yönlendirmenin bedeli ölçümdür. Hangi işin küçük modele bırakılabileceğine kanaatle değil, test setiyle karar verilmelidir. Model sağlayıcısı yeni bir sürüm çıkardığında aynı test seti yeniden çalıştırılır ve yönlendirme kuralları güncellenir. Modelden bağımsız bir çağrı katmanı (tek bir iç arayüz, arkasında değiştirilebilir sağlayıcılar) bu esnekliğin ön koşuludur.

Token bütçesi ve bağlam kırpma ile neler kazanılır?

Gönderilmeyen token için ödeme yapılmaz. Üretim sistemlerinde bağlamın şişmesinin tipik nedenleri ve çözümleri şunlardır:

• RAG'de fazla parça: "Ne olur ne olmaz" diye 20 doküman parçası göndermek hem maliyeti hem de yanlış pasaja dayanma riskini artırır. Yeniden sıralama (reranking) ile en ilgili birkaç parçayı seçmek genellikle hem daha ucuz hem daha doğrudur.
• Sınırsız konuşma geçmişi: Uzun sohbetlerde eski mesajları özetlemek ya da yalnızca son birkaç turu ve kalıcı önemli bilgileri tutmak.
• Kullanılmayan araç tanımları: Ajana her istekte 40 aracın tanımını göndermek yerine, işin türüne göre ilgili araç alt kümesini vermek.
• Kontrolsüz çıktı: Maksimum çıktı uzunluğu belirlemek, cevabı yapılandırılmış formatta (JSON şeması) istemek ve "adım adım açıkla" gibi gereksiz uzatan talimatları yalnızca gerçekten gerektiği yerde kullanmak.
• Ajan adım limiti: Her ajan görevine bir adım ve token bütçesi koymak. Bütçe aşıldığında ajan durur ve durumu insana devreder; sonsuz döngüye giren bir ajan bir gecede aylık bütçeyi tüketebilir.

Bağlam kırpmanın kaliteye etkisi mutlaka test setiyle ölçülmelidir. Gereğinden agresif kırpma, ucuz ama yanlış cevaplar üretir ve "başarılı iş başına maliyet" metriği bunu hemen gösterir.

Toplu (batch) işleme ne zaman mantıklı?

Kullanıcının cevabı anında beklemediği her iş toplu işleme adayıdır: gece çalışan doküman sınıflandırma, ürün kataloğunun zenginleştirilmesi, geçmiş kayıtların etiketlenmesi, embedding'lerin yeniden üretilmesi, değerlendirme (eval) koşuları. Büyük sağlayıcıların çoğu, sonucu birkaç saat içinde teslim etmeyi kabul eden toplu istekler için indirimli bir arayüz sunar. Burada dikkat edilecek nokta, iş akışının gerçekten bekleyebilir olmasıdır: kullanıcı ekranda bekliyorsa toplu işleme uygun değildir. Toplu işlerde de başarısız kayıtların tekrar kuyruğa alınması ve sonuçların doğrulanması gerekir.

Açık ağırlıklı modeller ve kendi sunucunuz ne zaman daha ucuz olur?

Açık ağırlıklı modeller son bir yılda ciddi biçimde güçlendi. Qwen 3.8 ile Max sınıfı bir model ilk kez açık ağırlıklarla geldi, Kimi K3 gibi modeller de bazı görevlerde kapalı modellere yaklaştı. Bu, "API mi, kendi sunucumuz mu?" sorusunu artık gerçek bir maliyet sorusu haline getiriyor.

İki maliyet yapısı temelden farklıdır. API'de maliyet değişkendir: kullandığınız kadar ödersiniz, kullanmadığınızda sıfırdır. Kendi sunucunuzda maliyet büyük ölçüde sabittir: GPU sunucusu, onu ayakta tutan mühendislik zamanı, izleme ve yedeklilik, trafik olsa da olmasa da ödenir. Bu yüzden kendi sunucunuz ancak yüksek ve düzenli bir kullanım hacminde ucuzlar.

Örnek hesap (temsili rakamlarla): Aylık sabit maliyeti (GPU, operasyon ve izleme dahil) 100 birim olan bir kurulumu, milyon token başına 2 birim ödenen bir API ile karşılaştıralım. Başa baş noktası aylık 50 milyon token'dır. Bunun altında API daha ucuzdur; üstünde, sunucunun kapasitesi yettiği sürece kendi kurulumunuz avantajlı hale gelir. Gerçek hesapta sunucunun ortalama doluluk oranını da hesaba katın: gece boş duran bir GPU'nun maliyeti gündüzki isteklere biner.

Maliyetin dışında iki neden kendi sunucunuzu öne çıkarabilir: KVKK ve veri sınırı gereği kişisel verinin yurt dışındaki bir sağlayıcıya gitmemesi gereken durumlar, ve gecikme ya da kullanılabilirlik şartları. En sık önerdiğimiz yapı hibrittir: hassas veya yüksek hacimli, görece basit işler kendi sunucunuzdaki açık modelde, nadir ve zor işler API üzerinden güçlü modelde çalışır. Yönlendirme katmanı ikisini tek bir arayüzün arkasında birleştirir.

LLM maliyetini nasıl izlemelisiniz?

Ölçülmeyen maliyet yönetilemez. Her model çağrısı için en azından şu alanların kaydedilmesi gerekir: hangi özellik ya da iş akışı için yapıldığı, hangi müşteri veya kiracıya ait olduğu, kullanılan model ve prompt sürümü, girdi, çıktı ve önbellekten okunan token sayıları, gecikme, tekrar deneme sayısı ve sonucun başarılı olup olmadığı. Bu kayıtlardan üç görünüm üretilir:

• Özellik bazlı maliyet: Hangi ürün özelliği ne kadar harcıyor, başarılı iş başına maliyeti ne.
• Müşteri bazlı maliyet: Özellikle SaaS ürünlerinde, fiyatlandırmanızın yapay zeka maliyetini karşılayıp karşılamadığını gösterir. Tek bir yoğun müşteri ortalamayı bozabilir.
• Anomali ve bütçe uyarıları: Günlük harcama belirlenen eşiği aşınca uyarı, ajan veya kullanıcı başına kota. Bir hata ya da döngü, fatura gelmeden yakalanmalıdır.

Sağlayıcı fiyatlarını kodun içine gömmek yerine sürümlenen bir fiyat tablosunda tutun; fiyat değiştiğinde geçmiş raporlar bozulmasın, yeni hesaplar doğru fiyatla yapılsın. İzleme verisinde kişisel veri varsa maskeleme ve saklama süresi baştan belirlenmelidir.

LLM maliyet optimizasyonu kontrol listesi

• Maliyeti çağrı başına değil, başarılı iş başına ölçüyor musunuz?
• Her çağrı özellik, müşteri, model ve prompt sürümüyle loglanıyor mu?
• Doğruluğu ölçen ve her değişiklikte yeniden çalıştırılan bir test setiniz var mı?
• Sabit bağlam (sistem talimatı, araç tanımları) prompt önbelleğinden yararlanacak şekilde başta mı?
• Tekrar eden girdiler için birebir yanıt önbelleği kullanılıyor mu?
• Semantik önbellek varsa kişisel veri içeren cevaplar önbellek dışında mı?
• Kolay işler küçük modele yönlendiriliyor ya da kademeli çağrı ile çözülüyor mu?
• RAG'de gönderilen parça sayısı ve konuşma geçmişi sınırlandırılmış mı?
• Maksimum çıktı uzunluğu ve yapılandırılmış çıktı tanımlı mı?
• Ajanların adım ve token bütçesi var mı?
• Bekleyebilen işler toplu (batch) arayüzle mi çalışıyor?
• Hacminiz için API ile açık ağırlıklı model karşılaştırmasını güncel fiyatlarla yaptınız mı?
• Günlük bütçe ve anomali uyarıları kurulu mu?

Detartech'te yapay zeka maliyetine nasıl yaklaşıyoruz?

Maliyeti projenin sonunda değil başında konuşuyoruz. Bir yapay zeka özelliğini tasarlarken önce başarının nasıl ölçüleceğini ve iş başına kabul edilebilir maliyeti yazılı hale getiriyoruz. Ardından modelden bağımsız bir çağrı katmanı, çağrı bazlı maliyet ve kalite kaydı ve bir test seti kuruyoruz; önbellek, yönlendirme ve bağlam kırpma kararlarını bu ölçümle veriyoruz. Hassas verinin söz konusu olduğu işlerde açık ağırlıklı modelleri kendi altyapınızda çalıştıran hibrit yapıları da değerlendiriyoruz. Bir partner seçerken maliyet kontrolüyle ilgili sormanız gereken sorular için yapay zeka entegrasyonu yapan şirket seçimi rehberimize bakabilirsiniz.

Yapay zeka faturanız ürününüzden hızlı büyüyorsa ya da yeni bir özelliğin maliyetini baştan doğru kurmak istiyorsanız, yapay zeka çözümleri sayfamızdan nasıl çalıştığımızı inceleyebilir ya da hızlı teklif formunu doldurabilirsiniz. İlk görüşmede mevcut kullanımınızın nereye harcandığını birlikte çıkarıyoruz.

Sıkça Sorulan Sorular

LLM maliyet optimizasyonu nedir? Yapay zeka destekli bir sistemin kalitesini düşürmeden model kullanım maliyetini azaltma çalışmasıdır. Önbellekleme, model yönlendirme, bağlam kırpma, toplu işleme ve gerektiğinde açık ağırlıklı modellere geçiş gibi teknikleri kapsar ve her zaman doğruluk ölçümüyle birlikte yapılır.

Daha ucuz bir modele geçmek maliyeti düşürür mü? Her zaman değil. Ucuz model daha sık hata yapıyorsa tekrar denemeler ve insan düzeltmesi nedeniyle başarılı iş başına maliyet artabilir. Geçiş kararı, aynı test setinde iki modelin doğruluğu ve iş başına toplam maliyeti karşılaştırılarak verilmelidir.

Prompt önbelleği kaliteyi etkiler mi? Hayır. Prompt önbelleği modelin aynı bağlamı yeniden işlemesini önler, cevabın içeriğini değiştirmez. Etkili olması için değişmeyen içeriğin bağlamın başında, değişen içeriğin sonunda yer alması gerekir.

Kendi sunucumuzda model çalıştırmak ne zaman mantıklı? Kullanım hacmi yüksek ve düzenliyse, verinin yurt dışına çıkmaması gerekiyorsa ya da gecikme ve kullanılabilirlik şartları sıkıysa. Düşük ve dalgalı hacimde API genellikle daha ucuzdur, çünkü kendi sunucunuzun maliyeti kullanmasanız da sabittir.

Yapay zeka maliyetini müşteri bazında nasıl takip ederiz? Her model çağrısını müşteri veya kiracı kimliğiyle birlikte loglayarak. Bu kayıt, hangi müşterinin ne kadar maliyet ürettiğini ve fiyatlandırmanızın bu maliyeti karşılayıp karşılamadığını gösterir; kota ve uyarılar da aynı veriden kurulur.