Yapay Zeka API'sinin Maliyeti Gerçekte Neye Göre Hesaplanır? Token Ekonomisini Basitçe Anlamak

Geçen ay bir kurucu bana geldi: “Ürüne yapay zeka özelliği ekledik, ilk haftanın sonunda faturayı görünce panik yaptık.” Kullanıcı sayısı değişmemişti, kod aynıydı — ama fatura üç kattan fazla büyümüştü. Sorun kötü yazılmış bir kod değildi; kimse “token ekonomisi” dediğimiz şeyi baştan hesaba katmamıştı. Bir yapay zeka API'sinin faturası, çoğu insanın sandığından çok daha fazla değişkene bağlı — ve bu değişkenleri bilmeden bir ürünü canlıya almak, ay sonunda sürpriz demek.

##Fatura Neden 'Token' Üzerinden Kesiliyor?

Bir LLM API'si kelime başına değil, token başına ücretlendirir. Token bir kelimenin parçası olabilir; 'kahvaltı' kelimesi tek bir token olabileceği gibi iki parçaya da bölünebilir — bu, modele ve dile göre değişir. Türkçe gibi eklemeli dillerde aynı anlamı ifade etmek İngilizceye göre genelde yüzde 20-40 daha fazla token tutar, çünkü modeller çoğunlukla İngilizce ağırlıklı verilerle eğitilmiştir ve Türkçe kelime kökleri kadar verimli parçalanmaz. Bu tek başına bile Türkçe bir ürünün faturasının İngilizce eşdeğerinden daha yüksek çıkmasına yeter.

Sağlayıcılar fiyatı milyon token başına belirler ve neredeyse her zaman girdi ile çıktı token'larını ayrı fiyatlandırır — çıktı, girdinin genelde 3-5 katı fiyata gelir. Bunun nedeni, modelin bir girdiyi okurken yaptığı işin, her çıktı token'ını sırayla üretirkenkinden çok daha ucuz olması: girdi tek seferde işlenir, çıktı ise token token, her birinde modelin tüm ağırlıkları yeniden çalıştırılarak üretilir.

Context window de bu tabloya dahil: bir modelin aynı anda görebildiği maksimum token sayısı. Bu sınır aşıldığında ya en eski mesajlar otomatik atılır ya da sistem hata verir — bu yüzden uzun süren sohbetlerde periyodik özetleme yapılır ya da geçmiş belli bir pencereye sıkıştırılır. Buradaki püf nokta şu: geniş bir context window'a sahip olmak (örneğin 200.000 token) onu kullanman gerektiği anlamına gelmez; her ekstra token, kullanılsa da kullanılmasa da parasal bir karşılığı olan bir seçimdir.

##Maliyeti Asıl Belirleyen Üç Şey

Aynı ürün, aynı kullanıcı sayısıyla bile çok farklı faturalar üretebilir. Bunu belirleyen üç ana değişken var:

• ▸Model seçimi: En yetenekli ve en büyük modeller, aynı işi yapan küçük bir modelden 10-20 kat daha pahalı olabilir. Basit sınıflandırma veya özetleme için büyük bir model kullanmak çoğu zaman gereksiz bir lüks.
• ▸Bağlam uzunluğu: Sistem promptu, konuşma geçmişi ve RAG'dan gelen belgeler her istekle birlikte tekrar tekrar gönderilir. 10 mesajlık bir sohbette, 10. mesajın maliyeti önceki 9 mesajın tamamını da taşır.
• ▸Çıktı uzunluğu ve çağrı sayısı: Modelin ne kadar konuştuğu, kaç kez çağrıldığı faturayı sessizce şişirir — özellikle kullanıcı bunu hiç görmese bile.

##Gerçek Bir Senaryo: Bir Destek Chatbotunun Aylık Faturasını Hesaplamak

Somutlaştıralım. Diyelim ki bir SaaS ürünü, müşteri destek sorularını yanıtlayan bir chatbot çalıştırıyor: ayda 10.000 konuşma, her konuşma ortalama 6-8 mesaj alışverişi. Sistem promptu ve ürün dokümantasyonundan gelen RAG bağlamı yaklaşık 1.200 token, kullanıcı mesajları ve model yanıtları toplamda konuşma başına 600-800 token ekliyor. Yani konuşma başına ortalama 1.800-2.000 girdi token'ı, 300-500 çıktı token'ı işleniyor.

Orta seviye bir modelin fiyatı milyon girdi token'ı için yaklaşık 2-3 dolar, milyon çıktı token'ı için yaklaşık 8-10 dolar civarında olsun. Gerçek fiyatlar sağlayıcıya ve modele göre değişir, bu sadece hesaplamayı somutlaştırmak için bir varsayım. Bu durumda konuşma başına maliyet kabaca binde birkaç dolar eder. 10.000 konuşma için bu, ayda seksen dolar civarı demek — makul görünüyor.

Ama şimdi gerçekçi bir değişiklik ekleyelim: ürün ekibi daha akıllı cevaplar için modeli bir üst segmente yükseltiyor (fiyat 4-5 kat artıyor) ve RAG bağlamına daha fazla doküman ekleniyor (girdi token'ları 1.900'den 4.500'e çıkıyor). Aynı 10.000 konuşma artık beş yüz-altı yüz dolar civarına geliyor — sadece iki 'küçük' karar yüzünden fatura 6-7 kat büyüdü. Panik yapan kurucuların gerçekte yaşadığı şey tam olarak bu: kod değişmedi, ama bağlam ve model seçimi sessizce büyüdü.

##Gözden Kaçan Maliyet: Ajan Zincirlerinde Token Nasıl Katlanır

Basit bir soru-cevap chatbotu ile 'ajan' tarzı bir sistem (bir görevi tamamlamak için art arda birden çok adım atan, araç çağıran bir yapı) arasındaki fark, faturada devasa bir uçurum yaratabilir. Her adımda model, o ana kadarki tüm geçmişi — önceki adımlar, araç sonuçları, ara adımlar — yeniden okur ve yeni bir token üretir. 5 adımlık bir ajan zinciri, tek seferlik bir soru-cevaba göre 5-15 kat daha fazla token tüketebilir, çünkü her adım öncekilerin tamamını bağlam olarak taşır. Bu, ajan tabanlı özellikler (otomatik araştırma, çok adımlı iş akışları) tasarlarken en çok gözden kaçan maliyet kalemidir; demoda birkaç istekle test edilir, üretimde binlerce kullanıcıyla çarpıldığında fatura kimseyi hazırlıksız yakalamamalı.

##Kim Ne Kadar Harcıyor? Müşteri ve Özellik Bazında Maliyeti İzlemek

Toplam aylık faturayı bilmek yeterli değil — hangi müşterinin, hangi özelliğin bu faturayı şişirdiğini bilmek asıl değerli olan. Her API isteğine hangi kullanıcıya, hangi özelliğe ait olduğunu gösteren bir etiket (metadata) eklemek, ay sonunda 'en pahalı yüzde 5 kullanıcı faturanın yüzde 40'ını oluşturuyor' gibi bir tabloyu ortaya çıkarır. Bu bilgi olmadan fiyatlandırma kararı vermek kör uçmaktır: bazı müşteriler zarar ettiriyor olabilir, bazı özellikler ise beklenenin çok üstünde token tüketiyor olabilir ama kimse fark etmiyor, çünkü fatura tek bir toplam rakam olarak görünüyor.

Pratikte bu, karmaşık bir sistem gerektirmiyor: çoğu sağlayıcının API'sinde her isteğe özel bir 'metadata' veya 'user' alanı eklenebiliyor, bu da sağlayıcının kendi kullanım panelinde filtrelenebiliyor. Daha ileri gitmek isteyenler, her isteğin token sayısını ve maliyetini kendi veritabanlarına loglayıp haftalık bir maliyet raporu çıkarabilir. Aylık bütçe aşıldığında uyarı veren basit bir eşik alarmı bile, sürpriz faturaların çoğunu önler.

##Maliyeti Düşürmenin Gerçek Yolları

Fatura büyüdüğünde ilk refleks 'daha ucuz bir sağlayıcıya geçelim' olur, ama asıl kazanç genelde mimaride saklı:

• ▸Bağlamı küçült: RAG'da belgenin tamamını değil, gerçekten ilgili parçaları gönder; konuşma geçmişinde eski mesajları özetleyerek taşı, ham haliyle değil.
• ▸İşe göre model seç: Basit sınıflandırma, yönlendirme veya kısa özetler için küçük ve ucuz bir model yeterli; büyük modeli sadece gerçekten zor adımlara sakla — bu bir 'model router' ile otomatikleştirilebilir.
• ▸Prompt caching kullan: Sistem promptu ve statik talimatlar gibi her istekte aynı kalan kısımları önbelleğe alan sağlayıcı özelliklerinden yararlan; bazı durumlarda aynı bağlamı tekrar göndermenin maliyetini yüzde 70'e kadar düşürebilir.
• ▸Çıktıyı sınırla: max_tokens gibi limitler koy, modele kısa ve öz cevap ver talimatı ekle; gereksiz açıklama ve tekrarlar doğrudan faturaya yansır.
• ▸Gerçek zamanlı olmayan işler için batch API kullan: Anlık yanıt gerekmeyen toplu işlemler çoğu sağlayıcıda yüzde 50 civarında indirimli batch uç noktalarından geçirilebilir.

##Sık Sorulan Sorular

>Çıktı token'ları neden girdi token'larından daha pahalı?

Çünkü işlem şekilleri farklı. Model bir girdiyi tek seferde, paralel olarak okur. Çıktıyı ise sırayla üretir; her yeni token için modelin milyarlarca parametresi yeniden çalıştırılır ve bir önceki token'ın sonucuna bağlıdır. Bu sıralı hesaplama donanımda çok daha fazla zaman ve enerji tüketir; fiyat farkı da bunu yansıtır.

>Ücretsiz veya düşük katman gerçek bir üründe yeterli mi?

Prototip aşamasında evet, genelde fazlasıyla yeterli. Ama üretime geçtiğinizde asıl sorun genelde maliyet değil, hız sınırları (rate limit) ve SLA eksikliği oluyor: ücretsiz katmanlar dakikada belirli sayıda istekle sınırlıdır ve kesinti garantisi vermez. Gerçek kullanıcı trafiği geldiğinde önce bu sınırlara takılırsınız, faturaya değil.

>Kendi sunucumda açık kaynak bir model çalıştırmak (self-host) daha mı ucuz?

Duruma göre değişir. Düşük ve değişken hacimde, API çağrı başına ödemek neredeyse her zaman daha ucuzdur, çünkü GPU altyapısının sabit bir maliyeti var — kullanmasanız bile o maliyet devam eder. Yüksek ve öngörülebilir hacimde self-host başa baş noktasına gelebilir, hatta daha ucuza çıkabilir, ama bu sefer bakım, ölçekleme ve uptime sorumluluğu size geçer. Çoğu küçük-orta ölçekli ürün için bu takas buna değmez.

>Streaming yanıt (kelime kelime akan cevap) maliyeti azaltır mı?

Hayır — streaming sadece kullanıcı deneyimini iyileştirir, cevap üretilirken parça parça gösterir. Ödediğiniz token sayısı aynıdır; tek fark kullanıcının cevabın tamamını beklemek yerine yazılırken görmesidir. Maliyeti düşüren şey token sayısını azaltmaktır, streaming değil.

>Fiyatlandırmayı kullanıcıya nasıl yansıtmalıyım?

İki yaygın yol var: kullanım bazlı (kullanıcı ne kadar token/istek harcarsa o kadar öder) veya sabit paket (aylık ücrete belirli bir kullanım hakkı dahil, üzeri kesilir veya ek ücretlendirilir). Kullanım bazlı modeller adil ama öngörülemez hissettirebilir; sabit paketler basittir ama ağır kullanıcılarda sizi zarara sokabilir. Çoğu SaaS, ikisinin karmasını kullanır: makul bir dahil kullanım artı üzeri için kullanım bazlı ek ücret.

>Aylık yapay zeka maliyetimi nasıl bütçeleyip izlerim?

En basit yöntem, sağlayıcının panelinde aylık harcama limiti ve e-posta uyarısı kurmak — çoğu sağlayıcı bunu destekler. Daha ürün odaklı bir yaklaşım için, her isteği hangi müşteriye veya özelliğe ait olduğunu etiketleyip kendi tarafınızda loglamak, hem bütçe aşımını erken görmenizi hem de fiyatlandırmanızı gerçek maliyete göre ayarlamanızı sağlar. Büyüyen bir üründe bu izleme genellikle bir 'olsa iyi olur' değil, ay sonunda zarar etmemek için gereklidir.

>Model fiyatları hızla düşüyor, şimdiden optimize etmek gerekli mi?

Evet. Fiyatlar geçtiğimiz birkaç yılda gerçekten hızla düştü ve düşmeye devam edebilir, ama bu optimizasyonu ertelemek için bir sebep değil — çünkü kullanım hacmi genelde fiyat düşüşünden çok daha hızlı büyüyor. Bir özellik popülerleştiğinde konuşma sayısı bir ayda 10 kata çıkabilir, fiyat ise aynı sürede yüzde 30-40 civarı düşer; net etki yine de faturanın büyümesidir. Ayrıca kötü tasarlanmış bir bağlam yönetimi, en ucuz modelde bile pahalıya mal olabilir — asıl kazanç modelin fiyatından değil, gereksiz token göndermemekten gelir.

Token'ların ve context window'un temelde ne olduğuna bakmak istersen, LLM'lerin nasıl çalıştığı üzerine yazdığım yazıya göz atabilirsin; kendi ürününün maliyet hesabını birlikte çıkarmak istersen de her zaman yazabilirsin.