AI token maliyeti nasıl hesaplanır: dört yanlış deneme

🇬🇧 English: Read this in English →

Ajansın senin işinde yapay zekâ kullanmaya başladıysa aslında bunun bedelini çoktan ödüyorsun. Sadece göremiyorsun. Sabit bir aylık paketin içinde bir yerde duruyor; ya da ajansın telaffuz etmek istemediği bir marj erimesiyle kapatılıyor. Her iki durumda da bu araçların sana getirmesi gereken üretkenlik kazancı, faturana sorgulayabileceğin, kıyaslayabileceğin, pazarlık edebileceğin bir kalem olarak yansımıyor.

The WP Clan olarak ben ters yolu seçtim. Yapay zekâ kullanımı, insan mesaisinin yanında kendi kalemi olarak faturaya iniyor; sağlayıcının kendi faturalama birimiyle. Kulağa basit geliyor, ta ki oturup «bu birim ne olacak» sorusunu cevaplayana kadar. Doğru cevaba dört yanlış denemeden geçerek vardım ve dördü de öğretici — çünkü bir gün bir ajans sana içi tutarsız bir «AI kalemi» sunduğunda, hangi hatanın hangi kalıba oturduğunu tanıyabilmen için işine yarar.

Bu, kısa bir serinin ikinci yazısı. İlk yazı bu kalemin neden var olması gerektiğini konuşuyordu. Bu yazı, o kalemin nasıl dürüstçe fiyatlanacağını ve iyi niyetli bir ajansın önce nasıl yanlış fiyatlayacağını anlatıyor.

Ajansının seçtiği baz, senin faturana biçim veriyor

Baz dediğim şey tek bir sorunun cevabı: bir birim yapay zekâ işi şu kadara mal olur, şöyle hesaplanır. Bazı değiştirdiğinde, aynı teslim edilen iş için fatura büyüklük mertebesinde değişebiliyor. Aşağıdaki dört deneme de gerçek bir şey ölçüyordu. Ama sadece dördüncüsü, senin gerçekte bedelini ödediğin şeyi ölçüyordu.

Kaynak, kendi iç kaydımız: 11-12 Eylül tarihli çalışma notları — şu an gerçek bir müşteride, gerçek bir proje yönetim aracının üzerinde işleyen faturalama modelinin altyapısı. Referans verdiğim liste fiyatları bugün claude.com/pricing üzerinden doğrulanmış güncel değerler.

Birinci deneme: API liste fiyatı, hiç almadığın işi cebine kesiyor

Akla ilk gelen baz, her sağlayıcının önüne koyduğu şey: yayımlanmış token başı liste fiyatı çarpı oturumun tükettiği token. Denetlenebilir görünüyor — transkripti aç, kuruşuna kadar yeniden hesapla.

İlk üç oturumu bu şekilde ölçünce fatura toplam $161 çıktı. Tepkim, temizlenmiş haliyle, açıktı: bu üç oturumdan iki kısa yazı çıkmıştı ve iki kısa yazının bedelinin yüz altmış dolara varması sayfada gördüğümüzle uyuşmuyordu. Bir şey sayacı şişiriyordu.

O bir şey, cache okumasıydı. Üç oturumdan biri tek başına 110 milyon token kaydetmişti. Uzun bir görüşme, önceki adımları, biriken talimatları, üzerinde çalışılan belgeleri defalarca yeniden okur — API liste fiyatı bu okumaların her birini fatura eder. Bu, hiçbir dürüst okumayla sana teslim edilen iş değil. Oturumun uzun olmasının yan etkisi. Ajansın bu okumaları liste fiyatıyla sana keserse, aslında projenin daha uzun bir konuşma gerektirmiş olmasının bedelini ödüyorsun — ki bu senin işinin değil, ajansın çalışma biçiminin bir özelliği.

İkinci deneme: aboneliği bölmek, senin faturanı başka müşterilerin ayına bağlıyor

İkinci deneme liste fiyatından uzaklaşıp ajansın fiilen ödediği sabit ücrete yaslandı. Yapay zekâ aboneliğimiz aylık $120. O ayki müşteri projelerine böldüğümde, bir müşterinin payı $8 çıktı.

Sekiz dolar, yüz altmış dolardan çok daha rahat görünüyordu. Ama kullanılamazdı. Çünkü o $8 rakamının pratikte söylediği şey şuydu: senin bu ayki AI ücretin, benim başka müşteriler için ne kadar AI çalıştığıma bağlı. Diğer projeler yoğun geçerse payın düşer, sakin geçerse yükselir. Bu bir faturalama bazı değil, bir çekiliş; ve hiçbir satın alma birimi böyle kurulmuş bir faturayı imzalamamalı.

Buradaki hata yapısal. Paylaşılan bir maliyet, bölünerek müşteri başı fiyata dönüşmüyor. Sadece «müşteri başı fiyat» kılığına girmiş paylaşılan maliyet olarak kalıyor.

Üçüncü deneme: aylık ortalama, tek bir oturuma uygulanmıyor

Üçüncü deneme daha zarif görünüyordu. Otuz günün verisini al, bir karma oran çıkar — şu kadar token ortalama şu kadara mal oluyor — ve bu oranı tek tek oturumlara uygula. Elektrik tarifelerinin ortalama alması gibi.

Zaten elle doğruladığımız iki oturuma uyguladığımda karma oran, gerçek bildiğimiz maliyeti kabaca ikiye katladı. Sebep, oturumdan oturuma çılgın biçimde değişen bir dengede: çıktı başına düşen cache okuması sayısı. Ay boyunca bu denge 370’e 1 gitmişti. O iki oturumda 197’ye 1 gidiyordu. Ortalama, sapmayı örter; oranı ortalamadan uzak bir oturuma o ortalamayı uyguladığında, kurgusal bir fiyat üretmiş olursun.

Buradan çıkan ders aslında yapay zekâyla ilgili değil. Herhangi bir tahsis modelini çökerten aynı ders: ortalama, bir kümenin iyi bir betimi olabilir; tek bir örneğin kötü bir fiyatıdır.

Dördüncü deneme: kullanım gibi görünen şeyin yarısı, iki kez sayılmış aynı mesajdı

Dördüncü deneme beni asıl korkutan oldu, çünkü önceki üç denemenin bozuk bir ölçümün üstünde yürüdüğünü ortaya çıkardı.

Belirli bir dönemin ham transkriptlerinde usage bloğu taşıyan 19.181 satır vardı — yani token tükettiğini bildiren satırlar. message.id‘ye göre gruplandığımda o satırların 8.355’i aynı mesajın tekrar kayıtlarıydı. İstemci tarafındaki günlük, oturum ilerledikçe aynı kullanım bloğunu yeniden ekliyordu. message.id‘ye göre tekilleştirmeden yapılan her hesap kabaca gerçek rakamın iki katıydı.

Bu ortaya çıkmasaydı diğer üç sorun ilk elde görünmezdi. Öğretici olan mükerrer kaydın kendisi değil. Muhasebenin bütün kalitesinin, kimsenin yazmayı düşünmediği iki satırlık bir ölçüm kodu değişikliğine bağlı olmasıydı. Ajansın bu tekilleştirmeyi yapmadan sana yapay zekâ ücreti kesiyorsa — ki çoğu yapmadı — eline verilen rakam, onların sandığı rakam değil.

Bu dört denemenin ortak şekli var. Hepsi oturumu ölçüyordu. Oysa ölçülecek şey teslim edilen işti. Ajansın bilmediği bir müşteri projesinde bir oturum uzun sürebilir, çünkü metodoloji geriye dönmek gerektiriyordur; kısa sürebilir, çünkü model bugün toparlıydı. İkisi arasındaki farkı sana yansıtacak dürüst bir baz yok — çünkü sen o farkı satın almadın. Sen çıktının kendisini satın aldın.

Ayakta kalan baz: teslim edilen iş, oturum değil

Ölçüm temizlenince baz sorusunun cevabı karmaşık olmaktan çıktı. Dört itirazı da geçen birim şu: teslim edilen işin kendi token maliyeti. Bütün oturum değil, aboneliğin bir payı değil, karma tarife değil, ham transkript değil. Müşteriye fiilen teslim edilen çıktı ve onu üreten girdi.

Bu yolla fiyatlanan iki adet 1.500 kelimelik makale, güncel liste fiyatlarında Opus 5’te yaklaşık $0,15, Sonnet 5’te $0,06 tutuyor. $161 değil. $8 değil. Geri kalan her şey — araştırma, deneme, geri alma, uzun bağlam okumaları — bizim tarafımızda genel gider olarak kalıyor; çünkü bunlar bizim nasıl çalıştığımızın, senin talep ettiğin işin değil, özellikleri. Süreç verimsizse bunu düzeltmek bize düşer, senin finanse edeceğin bir şey değil.

Yayımlanmış fiyatlarda küçük bir düzenlilik fark ettiğinde aritmetik hoş biçimde daralıyor. Güncel her katmanda — Opus 5, Sonnet 5, Haiku 4.5 — çıktı tokeni, girdi tokeninin tam beş katı fiyata satılıyor. Bu sayede girdi ve çıktı tek bir ağırlıklı sayıya inebiliyor:

ağırlıklı token = girdi + (5 × çıktı)
1 birim         = 100.000 ağırlıklı token

1.500 kelimelik makale kabaca 5.000 girdi artı 2.000 çıktı — 15.000 ağırlıklı token, yani 0,15 birim. Güncel liste fiyatına göre bir birim, marj öncesi Opus’ta 50 sent, Sonnet’te 20 sent, Haiku’da 10 sent civarında. Satış fiyatına giderken sabit ×2 uygulanır. Gizli hiçbir şey yok, fiyat kıpırdadığında sessizce dengelenen bir şey yok. Sağlayıcı listesini değiştirdiğinde birim maliyet onunla birlikte değişir; çarpan yerinde durur.

Gerçek bir faturada bu nasıl görünüyor

Bizden aldığın fatura, insan mesaisini insan mesaisi olarak taşır; yapay zekâ kullanımı üç ayrı satırdır — model katmanı başına bir tane — her biri 100.000 ağırlıklı token biriminde ölçülür. Başka sağlayıcılardan (görsel üretim, deşifre, çeviri) gelen dış API maliyetleri kendi satırlarındadır; her biri sağlayıcının kendi biriminde, her biri ×2. Hiçbir şey «AI ücreti» diye tek bir opak kaleme paketlenmez. Her satırın, sağlayıcının kamuya açık fiyat listesiyle karşılaştırılabileceği bir birimi vardır.

Bu düzeni kuran altyapı gösterişli değil. Oturum transkriptlerini okuyan, message.id‘ye göre gruplayıp mükerrer kayıtları düşüren, teslim çıktılarına filtreleyen, model başına ağırlıklı tokenleri hesaplayan ve sonucu proje yönetim aracına «Token Usage» iş tiplerine karşılık süre kaydı olarak yazan bir ölçüm işi. Kataloğun tekrar tekrar kırılmaması için bir de esnek kalem var — «External API Cost», sağlayıcının kendi euro tutarına ×2 uygulanır — böylece yeni bir servis çıktığında sistem çatlamıyor. Bir müşteri geçen ay projesinde bir birim yapay zekâ işinin ne anlama geldiğini sorduğunda, hangi teslim çıktısına ve hangi transkriptlere karşılık geldiğini gösterebiliyoruz.

Faturayı okurken işine yarayacak kaba bir insan karşılığı: bir birim yapay zekâ işi, asistanın aktif olarak çalıştığı 10-15 dakikaya denk geliyor. Yaklaşık dört birim, bir saat. Kafanda kurulacak karşılaştırma «AI maliyeti mi, sıfır mı» değil; «AI maliyeti, aynı projede eşdeğer insan mesaisinin bir saatine kıyasla ne».

Bu ay ajansına sormaya değer üç soru

Senin işinde yapay zekâ artık kritik yolun üzerindeyse, üç soruyu yazılı olarak sormaya değer. Bir: senin işinde kullandığın AI’yı bana fatura ediyor musun; etmiyorsan bu maliyet nerede duruyor? İki: fatura ediyorsan bazın nedir — liste fiyatı, abonelik payı, karma oran, teslim çıktısı — ve faturamdaki rakamın ham kullanımdan nasıl hesaplandığını görebilir miyim? Üç: bu kalemdeki marjın çarpan olarak ifade edildiğinde kaç?

Bu üç sorunun dürüst cevapları, AI’dan bağımsız olarak, ajansın nasıl çalıştığı hakkında çok şey söyler. Bunu düşünmüş bir ajansın kalem kalem okunabilir bir faturası vardır. Düşünmemiş olanı ya kaçamak cevaplar üretir ya da nereden geldiği kimsenin tam açıklayamadığı tek bir «AI ücreti» satırı sunar. Bu, dikkat etmeye değer bir sinyal — çünkü AI maliyeti fatura tarafında bu kadar gevşek tutuluyorsa, işin içinde de büyük ihtimalle bu kadar gevşek tutuluyor.

Serinin üçüncü yazısı bazdan kataloğa geçiyor: fatura kalem kalem nasıl görünüyor, proje yönetim aracı bunu fiilen nasıl taşıyor ve rakamların canlı bir müşteri projesinde ayakta kalması için hangi tuzaklardan geçtik.