Yapay zekâ API maliyeti nasıl hesaplanır?

Yapay zekâ projelerinde en sık sorulan ikinci soru "ne kadar tutar?" sorusudur ve cevabı aslında hesaplanabilir. Bu yazıda hesabın nasıl yapıldığını anlatıyoruz.

Token nedir?

Dil modelleri metni kelime kelime değil, token denen parçalar hâlinde işliyor. Kabaca bir token, İngilizcede dört karaktere denk geliyor. Türkçede oran biraz daha düşük: aynı metin İngilizcesinden yaklaşık %30-50 daha fazla token tutuyor.

Bu ayrıntı önemli, çünkü Türkçe bir uygulamanın maliyeti aynı işi yapan İngilizce bir uygulamadan yüksek çıkıyor.

Maliyet iki kalemden oluşuyor

Girdi (input). Modele gönderdiğiniz her şey: sistem talimatı, kullanıcının sorusu ve varsa eklediğiniz belge içeriği.

Çıktı (output). Modelin ürettiği cevap. Genellikle girdiden pahalı fiyatlanıyor.

Kritik nokta: kendi dokümanlarınızdan cevap üreten sistemlerde maliyetin büyük kısmı girdiden geliyor. Her soruda ilgili doküman parçalarını da modele gönderiyorsunuz.

Bir istek ne kadar tutar? Örnek hesap

Diyelim ki müşteri sorularını kendi dokümanlarınızdan cevaplayan bir asistan kuruyorsunuz:

• Sistem talimatı: ~400 token
• Kullanıcının sorusu: ~60 token
• Eklenen doküman parçaları: ~2.000 token
• Üretilen cevap: ~300 token

Toplam: yaklaşık 2.460 girdi + 300 çıktı token.

Bu rakamları kullandığınız modelin token başına fiyatıyla çarpıyorsunuz. Sonra günlük istek sayısıyla, sonra 30 ile.

Yapılması gereken tek şey budur. Ama neredeyse hiç yapılmadığı için fatura sürpriz oluyor.

Maliyeti düşüren dört yöntem

Doğru modeli seçin. Her iş en güçlü modeli gerektirmiyor. Sınıflandırma, etiketleme, kısa özet gibi işler küçük ve ucuz modellerle gayet iyi çalışıyor. Karmaşık akıl yürütme gerektiren işlerde güçlü modele geçilir.

Gönderdiğiniz bağlamı kısaltın. Tüm dokümanı değil, soruyla gerçekten ilgili parçaları gönderin. Maliyetin en büyük kalemi genellikle burası ve en çok tasarruf da buradan çıkıyor.

Sık tekrarlanan girdiyi önbelleğe alın. Sistem talimatı her istekte aynıysa, sağlayıcıların sunduğu önbellekleme özellikleri bu kısmın maliyetini ciddi biçimde düşürüyor.

Cevap uzunluğunu sınırlayın. Çıktı token'ı pahalı. Modelden gereğinden uzun cevap istemeyin.

Bütçe kontrolü

Üretime geçmeden önce iki şey kurun:

Aylık tavan. Sağlayıcı panelinden harcama limiti tanımlayın. Beklenmedik bir döngü ya da kötüye kullanım durumunda fren görevi görüyor.

İstek başına ölçüm. Her isteğin kaç token tükettiğini kaydedin. Böylece maliyetin nereden geldiğini görebilir, tahmin yürütmek zorunda kalmazsınız.

Deneme aşamasında ölçün

Önerdiğimiz yöntem şu: gerçek verinizle 50 örneklik bir deneme yapın, ortalama token tüketimini ölçün ve tahmini hacimle çarpın.

Bu, üretime geçmeden önce gerçek bir sayı verir. Doğruluk yetersizse ya da maliyet mantıklı değilse, proje burada durur ve hiçbir şey kaybetmemiş olursunuz.

Fiyatlar düşüyor, ama hesap yine de gerekiyor

Model fiyatları son yıllarda sürekli düştü ve düşmeye devam ediyor. Bu, "nasıl olsa ucuzlar" demek için sebep değil.

İki sebeple: birincisi, fiyat düşerken kullanım artıyor ve toplam fatura genellikle aynı kalıyor. İkincisi, bir projenin ekonomik olup olmadığını bugünkü fiyatla bilmeniz gerekiyor.

Hesabı yapmanın asıl faydası da fatura tahmini değil. Hesap, projenin mantıklı olup olmadığını gösteriyor. Bir isteğin maliyeti, o isteğin işletmeye kazandırdığından yüksekse proje daha kod yazılmadan durmalı.

Gizli maliyet kalemleri

Token ücreti tek kalem değildir. Şunlar da faturaya giriyor:

Yeniden denemeler. Model bazen hatalı biçimde cevap veriyor ve istek tekrarlanıyor. Her tekrar tam ücret demektir. İyi kurulmuş bir sistemde tekrar oranı düşüktür ama sıfır değildir.

Kötüye kullanım. Herkese açık bir asistan, kötü niyetli kullanıcıların hedefi oluyor. İstek sınırı ve kullanıcı doğrulaması olmadan yayınlanan bir asistanın faturası bir gecede şişebiliyor.

Test ve geliştirme. Geliştirme sırasında yapılan yüzlerce deneme de ücretlidir. Küçük bir kalemdir ama bütçede yer almalıdır.

Gömme maliyeti. Kendi dokümanlarınızdan cevap üreten sistemlerde dokümanların bir kez işlenmesi gerekiyor. Doküman güncellendikçe bu işlem tekrarlanıyor.

Ne zaman yapay zekâ kullanmamalı

Bazı işler dil modeli gerektirmiyor ve model kullanmak hem pahalı hem gereksiz oluyor.

Sabit kurallarla çözülebilen bir sınıflandırma, basit bir arama ya da bir hesaplama için model çağırmak, çekiçle vida çakmaya benziyor. Sonuç çıkıyor ama pahalıya ve güvenilmez biçimde.

Pratik ölçüt şu: işin çıktısı her seferinde aynı olmalıysa ve kural yazılabiliyorsa, klasik kod hem ucuz hem kesin sonuç veriyor. Dil modeli, kuralın yazılamadığı yerlerde değerlidir.

Bu ayrımı ve ilk projede yapılan hataları yapay zekâ ajanı kurarken beş hata yazısında ayrıntılı anlattık.

---

Elinizde belirli bir kullanım varsa, maliyetini birlikte hesaplayabiliriz. Yapay zekâ entegrasyonları.