Token fiyatları gerçekten düşüyor. Bugün aynı düzeyde model kapasitesine birkaç yıl öncesine göre çok daha ucuza erişilebiliyor. Fiyat listesindeki rakamlarla hızlı bir hesap yapınca, yapay zeka özelliğinin maliyeti de yok denecek kadar az görünüyor.
Fakat bu hesap genellikle tek bir model çağrısında bitiyor. Üretimde ise prompt’a system prompt, konuşma geçmişi, getirilen belgeler ve araç tanımları ekleniyor. AI agent sistemi işi tamamlayana kadar modeli birkaç kez çağırabiliyor. Bu sırada başarısız denemeler tekrarlanıyor, bazı yanıtlar başka bir modelden, bazıları da bir insandan onay bekliyor. Pilotta faturayı hafifleten bulut kredisi de bir gün tükeniyor.
Fiyat sayfasında yanlış bir şey yok, ancak şirketin asıl merak ettiği soruyu yanıtlamıyor.
Token, faturalandırma için kullanışlı bir birim. Ürünün gerçekten kaça mal olduğunu görmek içinse başarıyla tamamlanan görev başına maliyete bakmak gerekiyor. Bir destek aracında bu, çözülen talebin maliyetidir. Fatura mutabakatında ise yeniden denemeler ve insan kontrolü dahil, kabul edilen işlem başına maliyettir.
Sübvansiyon tartışmasının karışmasının bir nedeni de bu. Fiyat listesinde yazan tutar, bugün ödenen fatura ve kredi bittikten sonra şirkete kalacak maliyet aynı olmayabilir.
LLM faturası neyi sayıyor?
Token, modelin işlediği küçük bir bilgi parçası. Kullanıcının sorusu, system prompt, getirilen bir belge, araç tanımı, görsel, modelin akıl yürütmesi ve verdiği yanıtın her biri token üretiyor.
Sağlayıcıların bunları ücretlendirme biçimi aynı değil. OpenAI girdi, çıktı, önbelleğe alınmış tokenlar ve akıl yürütme tokenları için ayrı kullanım bilgisi veriyor. Google’ın kullanım verilerinde girdi, çıktı, düşünme, önbelleğe alınmış içerik ve araç kullanımı bulunuyor. Anthropic ise normal girdiyi önbelleğe yazılan, önbellekten okunan ve çıktı olarak üretilen tokenlardan ayırıyor. Dolayısıyla “10.000 token harcadık” demek, maliyeti açıklamaya yetmiyor. Hangi tokenların harcandığı ve sonunda işe yarar bir sonuç alınıp alınmadığı da önemli. OpenAI Google Anthropic
Şirket içi destek asistanına bir müşterinin para iadesi alıp alamayacağını soran çalışanı düşünelim. Ekranda yalnızca soru ve yanıt görünse de arkada talep sınıflandırılıyor, güncel politika bulunuyor, müşteri hesabı açılıyor, modelden öneri alınıyor, yapılandırılmış yanıt doğrulanıyor ve son bir kontrol yapılıyor olabilir. Hesap sorgusu zaman aşımına uğrarsa zincirin bir bölümü yeniden çalışır. Kısacası kullanıcı tek işlem görürken faturaya küçük bir iş akışı yansır.
Tek bir görevin faturası
Ekranda tek sonuç görünür. Arkadaki iş akışı ise birkaç model çağrısı ve başarısız denemeler içerebilir.
Fiyatlar temsilidir
Hesapta bir milyon girdi tokenı $1, bir milyon çıktı veya akıl yürütme tokenı $5 kabul edildi.
Tek yanıt
Bir model çağrısı · 1.000 girdi · 300 çıktı tokenı · İlk denemede %80 başarı
$0.0031kabul edilen görev başına
Tek deneme $0.0025
RAG yanıtı
Yanıt ve kontrol · 8.000 girdi · 600 çıktı tokenı · İlk denemede %85 başarı
$0.0129kabul edilen görev başına
Tek deneme $0.0110
AI agent görevi
Altı model çağrısı · 30.000 girdi · 3.000 çıktı tokenı · İlk denemede %70 başarı
$0.0643kabul edilen görev başına
Tek deneme $0.0450
Çubuğun genişliği, kabul edilen görev başına beklenen model maliyetini gösterir. Belge ve araç bağlamı modele gönderilen içeriği kapsar. Veri tabanı, harici API, insan incelemesi ve altyapı maliyetleri bu grafikte yok.
Bu, RAG veya AI agent kullanımının gereksiz olduğu anlamına gelmiyor, çünkü her iki mimari de ek maliyetinin karşılığını verebilir. Mesele, tek model çağrısının fiyatıyla bütün iş akışının maliyetini birbirine karıştırmamak.
Ucuz model her zaman ucuz sonuç vermiyor
Aynı belgeden veri çıkarıp doğrulayan iki model olsun. Model A’nın girdi ve çıktı ücretleri daha düşük, fakat daha uzun bir prompt istiyor ve daha uzun yanıt veriyor. Üstelik her beş isteğin biri yeniden çalıştırılıyor. Model B ise token başına daha pahalı olmasına rağmen daha az bağlam kullanıyor ve geçerli sonucu ilk denemede daha sık üretiyor.
Fiyat listesinde Model A ucuz. Kabul edilen belge başına hesap yapıldığında ise Model B öne geçebilir.
2026 tarihli bir çalışma, karşılaştırılan model çiftlerinin yüzde 21,8’inde tam olarak bu durumla karşılaştı. Bu örneklerde token fiyatı daha düşük olan modelin gerçekleşen toplam maliyeti daha yüksekti. En büyük fark 28 kata ulaştı. The Price Reversal Phenomenon
Bunun şaşırtıcı olmayan birkaç nedeni var. Farklı tokenizer’lar aynı metni farklı sayıda tokena bölebiliyor. Modellerin akıl yürütme ve çıktı uzunlukları da değişiyor. İlk yanıt işe yaramadığında sistem aynı modeli tekrar çağırıyor, başka bir modele geçiyor veya işi insan incelemesine gönderiyor. Dolayısıyla ilk denemede doğru çalışan pahalı model, toplamda daha ucuz kalabiliyor.
Örneğin küçük bir model API faturasını yüzde 40 azaltırken kabul edilen görev oranını yüzde 90’dan yüzde 60’a düşürüyorsa ortada net bir tasarruf olmayabilir. Aradaki fark tekrar yapılan işlere, inceleme süresine ve müşteri şikayetlerine gider.
Bu nedenle önce kabul edilebilir sonucun ne olduğu belirlenmeli, ardından o sonucu en düşük toplam maliyetle üreten seçenek bulunmalı.
Token ucuzluyor, kullanım artıyor
American Economic Association’ın Journal of Economic Perspectives dergisinde yayımlanan bir analiz, yapay zeka kapasitesinin fiyatının yaklaşık bin kat düştüğünü tahmin ediyor. Benzer düzeydeki açık modeller de kapalı modellere göre çok daha ucuza sunuluyor. Düşüşün tam oranı seçilen benchmark’a ve döneme bağlı, ama yönü açık. American Economic Association
Şirket faturalarının aynı hızla düşmesi gerekmiyor. Model çağrısı ucuzlayınca ekipler daha fazla bağlam ekliyor, bir doğrulama adımı daha çalıştırıyor, daha çok çıktıyı değerlendiriyor veya AI agent sistemine ek adımlar veriyor. Bunların hepsi israf değil. Daha iyi kanıt yanıtı iyileştirebilir, ek bir kontrol de token maliyetinden çok daha pahalı bir hatayı önleyebilir.
Yine de ucuz kapasite, gereksiz harcamayı fark etmeyi zorlaştırıyor. Bağlam penceresine sığıyor diye bütün konuşma geçmişi her istekte yeniden gönderilebiliyor. İki sistem aynı belgeyi ayrı ayrı okuyabiliyor veya bir araç hata verince daha da büyümüş bağlam baştan işleniyor. Basit bir kuralın ya da örneklem kontrolünün yeterli olacağı yerde her çıktı başka bir modele puanlatıldığında, birim fiyat düşse bile kullanılan birim sayısı artıyor.
Stanford Digital Economy Lab’in kodlama görevleri üzerine yaptığı çalışma, aradaki farkın ne kadar büyüyebildiğini gösteriyor. AI agent kullanılan görevler, kod üzerinde akıl yürütme ve sohbet görevlerinden bin kata kadar daha fazla token tüketti. Aynı görevin farklı çalıştırmaları arasında 30 kata varan fark vardı. Üstelik daha çok token harcanan çalıştırma düzenli olarak daha iyi sonuç vermedi. En iyi performans çoğu zaman orta bir maliyet düzeyinde görüldü. Stanford Digital Economy Lab
Bu sayılar kodlama ortamından geldiği için her iş akışına doğrudan taşınamaz. Yine de çağrı sayısını model belirlediğinde maliyetin de sabit kalmadığını açıkça gösteriyor: Tutar ancak çalıştırma bittikten sonra belli oluyor.
Ortalama maliyet de bu farkı örtebilir. Çoğu görev ucuza tamamlanırken az sayıdaki uzun ve başarısız çalışma bütçenin büyük bölümünü yiyebilir. Bu yüzden medyanı ve pahalı uçtaki çalışmaları ayrı izlemek, ardından en pahalı hataların kayıtlarını tek tek okumak gerekir.
”Sübvanse edilmiş fiyat” derken neyi kastediyoruz?
Yapay zeka fiyatları konuşulurken “sübvanse ediliyor” sözü birkaç farklı durum için kullanılıyor. Müşterinin faturasında benzer görünen bu durumların ekonomik anlamı aynı değil.
Bulut kredisi doğrudan bir sübvansiyon. Örneğin Google, koşulları karşılayan yapay zeka odaklı girişimlere önemli miktarda kredi vererek normalde girişimin ödeyeceği kullanımı karşılıyor. Deneme yapmak için değerli olan bu destek, promosyon bittiğinde ürünün model faturasını taşıyabileceğini kanıtlamıyor. Google for Startups Cloud Program
Sabit ücretli abonelikte durum farklı. Aylık ücret, ürünü nadiren açanlarla yoğun kullananları aynı havuzda topluyor. Bu yüzden bir kullanıcının API fiyatlarıyla hesaplanan tüketimi abonelik ücretini aşarken bir başkası hizmeti neredeyse hiç kullanmayabilir. Fakat bu tüketim tutarı, sağlayıcının gerçek hesaplama maliyeti değil. API fiyatının içinde kâr marjı ve fiyatlandırma tercihi de bulunduğundan, şirketin iç maliyetlerini bilmeden yalnızca aradaki farka bakıp zarar ettiği sonucuna varılamaz.
Rekabet amacıyla düşük tutulan fiyatları dışarıdan anlamak daha da zor. Sağlayıcı pazar payı kazanmak için düşük kâr marjını kabul ediyor olabilir. Bulut şirketi geliri başka hizmetlerden elde ettiği için yapay zeka ürününde indirim yapabilir. Ya da fiyat gerçekten daha iyi donanım kullanımı ve önbellekleme sayesinde düşmüştür. Fiyat sayfası bunlardan hangisinin geçerli olduğunu söylemez.
Müşterinin bu tartışmayı dışarıdan çözmesi gerekmiyor. Onun açısından asıl risk, kalıcı olmayan bir fiyata bağımlı olmak. Ürün yalnızca belirli bir kredi veya olağan dışı düşük tarife devam ederken para kazanıyorsa bunun maliyet hesabında açıkça görülmesi gerekir.
Aynı iş, üç farklı maliyet
Tek bir ayın maliyeti, hesaba hangi kalemlerin girdiğine göre değişiyor.
Örnek: 10.000 istek, kabul edilen 8.000 sonuç ve $500 bulut kredisi.
Liste fiyatıyla kullanım
$500
İstek başına 5 sent
Model ve araç ücretleri $500
Bulut kredisi uygulanmadan önce
Kim ödüyor?
Kredi olmasaydı bu tutarı ürünü sunan şirket ödeyecekti.
Şirketin bugün ödediği
$4.400
Kredi sonrası model faturası $0
İnsan incelemesi $4.000
İzleme ve operasyon $400
Kim ödüyor?
Model faturasını kredi karşılar. İnceleme ve operasyon şirkette kalır.
Kredi bittikten sonra
$4.900
Kabul edilen görev başına 61 sent
$500 kullanım + $4.000 inceleme
+ $400 izleme ve operasyon
Kim ödüyor?
Şirket öder. Maliyet zamanla müşteriye veya kâr marjına yansır.
İnceleme ekibi saatlik $40 maliyetle 100 saat çalışıyor. Ürün geliştirme ve genel giderler hesaba dahil değil. Kamuya açık API fiyatı da sağlayıcının gerçek hesaplama maliyetini göstermiyor.
Kredi ve tanıtım fiyatlarından elbette yararlanılabilir, ancak aynı hesabı ikisi de yarın bitecekmiş gibi bir kez daha yapmak gerekir.
Sabit aboneliğin altında değişken maliyet var
Bulut kredisi bittiğinde kullanım ortadan kalkmıyor ve faturayı artık ürünü sunan şirket ödüyor. Müşteri sabit bir aylık ücret öderken arka plandaki yapay zeka maliyeti her istekte değişiyorsa bu fark kolayca büyüyebilir.
Aynı paketteki iki müşteri düşünelim. Biri ilk model çağrısında tamamlanan kısa istekler gönderiyor. Diğeri uzun belgeler yüklüyor, AI agent sisteminde çok sayıda adım çalıştırıyor ve daha fazla işi insan incelemesine bırakıyor. İkisinden gelen abonelik geliri aynı, hizmet maliyeti farklı.
Bu, müşteriye token üzerinden fatura kesmek gerektiği anlamına gelmiyor. Kullanıcı veya iş akışı başına ücretlendirme devam edebilir. Fakat şirketin, her paketin normal fiyatlarla ne kadar kabul edilmiş iş ürettiğini bilmesi gerekir. Sabit abonelik değişken maliyeti ortadan kaldırmaz, yalnızca şirketin tarafında bırakır.
Doğru metrik: kabul edilen işin maliyeti
Önce neyin başarılı görev sayılacağı belirlenmeli, çünkü bir yanıtın ekrana gelmiş olması tek başına başarı değil.
Destek asistanında başarı, daha sonra yeniden açılmayan bir talep olabilir. Belge işlemede, sonraki sistemin kabul ettiği doğrulanmış kayıt sayılabilir. Veriyi değiştiren bir AI agent sisteminde ise doğru kaydın değişmesi ve işlemin belirlenen kurallara uyması gerekir.
Temel hesap şu:
Başarıyla tamamlanan görev başına maliyet = iş akışının toplam işletme maliyeti / kabul koşulunu karşılayan görev sayısı
Toplam maliyete model tokenları, harici araçlar, retrieval altyapısı, yeniden denemeler, doğrulama, izleme ve gereken insan incelemesi girer. Yazılım geliştirme gibi sabit giderler, tam yatırım hesabı yapılacaksa ayrıca dağıtılabilir. Yeniden yapılması gereken veya sonraki aşamada düzeltme çıkaran işler başarılı görev sayısına eklenmez.
Örnek bir ayda 10.000 görev geldiğini düşünelim. Model çağrıları, araçlar ve yeniden denemeler 600 dolar, izleme 400 dolar tutuyor. İnceleme ekibi de saatlik toplam maliyeti 40 dolar olmak üzere 120 saat çalışıyor. Ay sonunda 8.000 görev kabul koşulunu karşılıyor.
Yalnızca API faturasına bakıldığında maliyet istek başına altı sent çıkıyor. İşletme maliyetinde ise 5.800 dolar kabul edilen 8.000 göreve bölünüyor ve başarılı görev başına yaklaşık 73 sent bulunuyor. İki hesap da doğru, fakat tamamlanan işin değeriyle karşılaştırılabilecek rakam ikincisi.
Bu hesap, farklı çözümleri aynı ölçüyle karşılaştırmayı da sağlıyor. Küçük model, inceleme yükünü artırmadan kabul edilen görev başına maliyeti düşürüyorsa işe yarıyor. Önbellekleme de sonucu değiştirmeden tekrarları azalttığı sürece fayda sağlıyor. Daha pahalı bir model ise yeterince yeniden denemeyi ortadan kaldırdığında yüksek token ücretini çıkarabiliyor.
API faturasındaki bir kalemin küçülmesi tek başına tasarruf değil. Kabul edilen işin de ucuzlaması gerekiyor.
Harcama başlamadan sınır belli olmalı
İzleme, bir çalıştırmanın ne kadar harcadığını bittikten sonra gösterir. Bütçe ise daha başlamadan sınırı belirler.
Tek model yanıtında çıktı sınırı yeterli olabilir. Birden fazla adımdan oluşan iş akışında model çağrısı, araç denemesi, yeniden deneme ve toplam maliyet için de sınır gerekir. Bir deneme daha yapmanın harcanacak paraya değip değmeyeceğini sisteme bırakmak iyi bir fikir değil.
Sınıra gelindiğinde ne olacağı işe göre değişir. Araştırma aracı, o ana kadar bulduklarını ve nerede durduğunu gösterebilir. Müşteri talebi, toplanan kanıtlarla birlikte bir çalışana aktarılabilir. Sonucu önemli bir işlemde ise eksik bilgiyle yanıt üretmek yerine durmak daha güvenli olabilir.
Bütçe yalnızca altyapı ekibinin göreceği bir ayar değil. Sınır dolduğunda kullanıcıya ne olacağını belirlediği için ürün kararının da bir parçası.
Hesabı daha kötü koşullarla da denemek gerekir. Promosyon kredisi kaldırılabilir, model fiyatı artırılabilir. Ortalama yerine gözlenen 95. yüzdelik çalışma kullanılabilir. İlk denemedeki başarı oranı düşürülüp pilot ekibinin şimdiye kadar görünmeden üstlendiği inceleme süresi hesaba eklenebilir. Ürün bu koşullarda da değer üretiyorsa maliyet hesabı sağlamdır. Kredi kalkınca hesap dağılıyorsa pilotun başarısını ürün kadar finansman koşulları da açıklıyor demektir.
Bir milyon token yerine yüz görevi takip edin
Başlangıç için şirket çapında bir maliyet projesine gerek yok. Üretimde çalışan tek bir iş akışını seçip yüz gerçek görevi, ilk istekten kabul edilen sonuca kadar izlemek yeterli.
Bu yüz görev için ekip model çağrılarını, token kullanımını, araç ücretlerini, yeniden denemeleri, inceleme süresini ve nihai sonucu kaydeder. Önce medyan çalışmayı inceler, ardından pahalı uçtaki kayıtları ayırıp tek tek okur. Son olarak kredi ve geçici indirimleri hesaptan çıkarır ve maliyeti yeniden hesaplar.
Çoğu zaman büyük bir mimari sorundan önce daha sıradan israflar bulunur: Aynı bağlam iki kez gönderiliyordur, yeniden deneme sınırı gereğinden yüksektir veya tamamlanmış görünen bir çıktı sonradan elle düzeltiliyordur.
Model, prompt, araçlar ya da kabul koşulları değiştikçe ekip aynı ölçümü yeniden yapar. Ucuzlayan tokenların ürün maliyetini gerçekten düşürüp düşürmediği ancak böyle anlaşılır. Belki de yalnızca daha fazla token harcamayı kolaylaştırıyordur.