Uygulamaya yapay zekâ eklemek ne kadara mal olur?

Maliyet nerede oluşuyor?

Üç kalem var ve sıraları çoğu ekibin beklediğinin tersi. Birincisi geliştirme: özelliğin tasarlanması, istemlerin yazılması, değerlendirme setinin kurulması, arayüzün yapılması. İkincisi model kullanımı: her istek için ödenen belirteç ücreti. Üçüncüsü bakım: modeller değişiyor, istemler bayatlıyor, kullanıcı davranışı kayıyor.

Ekiplerin çoğu ikinci kaleme odaklanıyor çünkü tek görünen fiyat listesi o. Oysa küçük ve orta ölçekli bir üründe model faturası genellikle en küçük kalem; asıl para geliştirmeye ve — ilk yıldan sonra — bakıma gidiyor.

Ölçü birimi kullanıcı değil, belirteç

Model ücretlendirmesi belirteç (token) üzerinden yapılıyor: metnin modele giren kısmı girdi, modelin ürettiği kısmı çıktı olarak ayrı fiyatlanıyor ve çıktı her zaman daha pahalı. Bunun pratik sonucu, aynı kullanıcı sayısına sahip iki üründen birinin diğerinden kat kat pahalıya gelmesi.

Farkı yaratan şey akış. Her istekte kırk sayfalık bir dokümanı bağlam olarak gönderen bir ürün, kısa bir soruyu kısa bir cevapla karşılayan üründen onlarca kat fazla belirteç tüketiyor — kullanıcı sayısı aynı olsa bile. Bu yüzden "kaç kullanıcı" sorusu maliyeti tahmin etmeye yetmiyor; "her etkileşimde ne gönderiliyor" sorusu yetiyor.

Maliyeti düşüren üç mekanizma

• **İstem önbelleği.** Her istekte tekrarlanan sabit bağlam — sistem yönergesi, ürün kuralları, doküman — bir kez yazılıp sonraki isteklerde okunuyor. Anthropic'in fiyat sayfasında önbellekten okuma, normal girdi ücretinin yaklaşık onda birine denk geliyor. Tekrar eden bağlamı olan her üründe en büyük tek kaldıraç bu.
• **Toplu işlem.** Anlık cevap gerekmeyen işler — gece çalışan sınıflandırma, toplu özetleme, veri zenginleştirme — toplu uca gönderildiğinde standart fiyatın yarısına iniyor.
• **Model bölüştürme.** Sınıflandırma, yönlendirme ve biçimlendirme gibi mekanik adımları küçük modele, muhakeme gerektiren adımı güçlü modele vermek. Tek modelle her şeyi yapan mimari, en pahalı adımın fiyatını her adıma ödetiyor.

Bu üçü birlikte uygulandığında fark yüzde değil kat düzeyinde oluyor. Ama üçü de mimari kararı — özellik yazıldıktan sonra eklenen bir ayar değil. Maliyet optimizasyonunun tasarım aşamasında yapılmasının sebebi bu.

Faturayı patlatan üç hata

• **API anahtarını uygulamanın içine gömmek.** Mobil uygulamaya gömülen anahtar çıkarılabilir ve çıkarıldığı anda faturayı başkası belirler. Model çağrıları her zaman sizin sunucunuzdan geçmeli; istemci yalnızca sizin uç noktanızı görmeli.
• **Kullanıcı başına sınır koymamak.** Bir kullanıcının ayda kaç istek yapabileceği tanımlı değilse, tek bir otomatik betik aylık bütçeyi bir günde tüketebiliyor. Sınır ürünün parçası, güvenlik önlemi değil.
• **Bağlamı büyütmeye devam etmek.** Sohbet geçmişini kırpmadan biriktiren bir akışta her yeni mesaj bir öncekinden pahalı oluyor; maliyet konuşma uzadıkça doğrusal değil birikimli artıyor.

Sabit fiyat verilebilir mi?

Geliştirmeye evet, kullanıma hayır — ve bu ayrımı baştan yapmak iki tarafı da koruyor. Geliştirme kapsamı tanımlanabilir bir iş: özellik, arayüz, değerlendirme seti ve teslim. Model kullanımı ise kullanıcı davranışına bağlı; sabit fiyatlamak, riski fiyata gömüp size fazladan ödetmek demek.

İşleyen kurgu şu: geliştirme sabit fiyat, kullanım ise şeffaf ve ölçülür biçimde doğrudan sağlayıcıya. Üzerine baştan tanımlanmış bir aylık tavan ve tavana yaklaşıldığında tetiklenen bir uyarı. Böylece maliyet ne sürpriz oluyor ne de tahmine bağlı kalıyor.