Token fiyatı yanlış kaldıraçtır: maliyet mimaride belirlenir

Tez#

Maliyet tartışması neredeyse her zaman bir fiyat tablosuyla başlıyor: hangi model 1M token başına kaça geliyor. Bu tablo gerekli ama yanıltıcı, çünkü faturanın yalnızca bir çarpanını gösteriyor. Fatura üç değişkenin çarpımıdır — birim fiyat, istek başına token ve istek sayısı — ve bu üçünden ekibin en az kontrol edebildiği birincisidir.

İkinci ve üçüncü değişken ise tamamen mimari kararlara bağlı. Aynı işi yapan iki sistem, istek başına on kat farklı token tüketebilir: biri her soruda tüm belgeyi bağlama koyuyor, diğeri yalnızca ilgili parçaları getiriyor. Biri konuşma geçmişini olduğu gibi taşıyor, diğeri periyodik özetliyor. Biri her turda sistem istemini yeniden gönderiyor, diğeri önbellekten yararlanıyor. Bu farklar model değiştirerek elde edilemez ve kalite kaybı gerektirmez — çoğu zaman kaliteyi artırır, çünkü daha az ve daha ilgili bağlam daha iyi cevap üretir.

Bağlam: dört kaldıraç ve gerçek etkileri#

Maliyet düşürmenin yolları aynı ağırlıkta değil. Aşağıdaki tablo, sık başvurulan müdahaleleri hangi çarpana dokunduklarına ve kalite üzerindeki etkilerine göre karşılaştırıyor.

Tablonun pratik okuması şu: kalite kaybı olmadan kazandıran iki müdahale — önbellek ve gereksiz bağlam eleme — en az başvurulanlar arasında. Bunun nedeni görünürlük: model değiştirmek bir satır yapılandırma, bağlam hattını yeniden tasarlamak bir sprint. Görünürlük ile etki arasındaki bu ters ilişki, yapay zekâ maliyet yönetiminin en tekrar eden hatası.

Kanıt: faturanın nereden geldiği#

Maliyet analizi yapabilmenin ön koşulu, faturayı iş akışı bazında ayırabilmektir. Etiketlenmemiş bir fatura tek bir sayıdır ve tek bir sayı üzerinde optimizasyon yapılamaz. Aşağıdaki adımlar, maliyeti karar verilebilir hâle getiriyor.

1. 1Her çağrıyı etiketleyin

   İş akışı, ortam, kullanıcı segmenti ve maliyet merkezi. Etiketsiz fatura, hangi akıştan geldiği bilinmeyen bir toplamdır.

2. 2İstek başına token dağılımını çıkarın

   Ortalama değil dağılım: en pahalı yüzde birlik dilim toplamın ne kadarını oluşturuyor? Genellikle şaşırtıcı bir orandır.

3. 3Bağlamı bölümlerine ayırın

   Sistem istemi, talimat, örnekler, geri getirilen parçalar, konuşma geçmişi. Her bölümün token payını ayrı ölçün.

4. 4En büyük bölümü budayın ve ölçün

   Budamanın kalite etkisini değerlendirme setinde ölçün. Kayıp yoksa budama kalıcıdır; varsa sınır bulunmuştur.

5. 5Önbellek isabetini izleyin

   Sabit önek ne kadar tekrar ediyor ve ne kadarı önbellekten karşılanıyor? Düşük isabet, istem yapısının kararsız olduğunu gösterir.

Üçüncü adım genellikle en aydınlatıcı olanı. Ekipler bağlamın büyük bölümünün geri getirilen belgelerden geldiğini varsayıyor; ölçtüklerinde sıklıkla konuşma geçmişinin ya da hiç güncellenmemiş uzun bir sistem isteminin baskın pay aldığını görüyorlar. Ölçmeden yapılan budama, yanlış bölümü budar.

Mekanizma: bağlam neden maliyetin merkezi#

Bağlam uzunluğunun maliyete etkisi iki katmanlı ve ikincisi sık atlanıyor. Birinci katman doğrudan: daha çok token, daha çok ücretlendirilen girdi. İkinci katman kapasite tarafında: dikkat mekanizmasının ara durumları bağlam uzunluğuyla birlikte büyür ve hızlandırıcı belleğini doldurur. Bellek dolduğunda aynı donanımda eşzamanlı hizmet verilebilen istek sayısı düşer; birim maliyet yükselir.

Bu ikinci katman, kendi altyapısını işleten ekipler için doğrudan bir kapasite sorunu, yönetilen API kullananlar için ise fiyatlandırmaya gömülü bir gerçek. Sonuç ikisinde de aynı: bağlam bütçesi yalnızca bir fiyat kalemi değil, bir tasarım kısıtıdır. Türkçe metinle çalışan ekipler için ek bir katman var — yaygın tokenleştiriciler Türkçeyi İngilizceden daha çok parçaya böldüğü için aynı anlamı taşıyan metin daha fazla token eder. Bu fark kendi metinlerinizle ölçülmeli; genel bir oran varsaymak yanıltır.

Karşı görüş#

İki güçlü itiraz var. Birincisi: model kademeleri arasındaki fiyat farkı gerçekten büyük; aynı ailede en ucuz ile en pahalı kademe arasında onlarca kat fark olabiliyor. Bu farkın yanında bağlam optimizasyonuyla elde edilen yüzdeler küçük görünüyor. İkincisi: mühendislik zamanı da maliyet; bağlam hattını yeniden tasarlamak için harcanan haftalar, tasarruf edilen tutarı aşabilir.

Altı hafta bağlam hattını optimize ettik, aylık maliyeti yarıya indirdik. Sonra hesapladık: o altı haftanın mühendislik maliyeti, on dört aylık tasarrufa denk geliyordu.

İkinci itiraz özellikle haklı ve analizin sınırını çiziyor: maliyet optimizasyonu yalnızca ölçek belirli bir eşiği geçtiğinde ekonomiktir. Düşük hacimde doğru hamle en ucuz makul modeli seçip mimariye hiç dokunmamaktır. Birinci itiraz için ise nüans şu: kademe farkı büyüktür ama kademeler yetenek olarak da ayrışır. Ucuz kademeye geçmek kalite kaybettirirse tasarruf değil, gizli bir kalite borcudur. Bağlam optimizasyonunun ayırt edici özelliği tam burada: kaliteden ödün vermeden — sıklıkla kaliteyi artırarak — kazandırıyor. İkisi alternatif değil; birlikte uygulanır ve sıralaması önemlidir.

Sınırlar ve belirsizlik#

Bu analiz nicel bir tasarruf oranı vermiyor ve vermemesi bilinçli: oran tamamen mevcut mimarinin ne kadar savurgan olduğuna bağlı. İyi tasarlanmış bir hatta budanacak bir şey kalmamış olabilir.

• Başlangıç noktası belirleyici: aynı müdahale bir ekipte yüzde altmış, başka ekipte yüzde beş kazandırır. Genel bir oran vermek yanıltıcı olurdu.
• Önbellek politikaları sağlayıcıya göre değişiyor: indirim oranları ve geçerlilik süreleri farklı; hesap her sağlayıcı için ayrı yapılmalı.
• Yönlendirme eşiklerinin kalite etkisi ölçülmeli: zorluk sınıflandırması yanlışsa ucuz modele giden zor sorular sessiz kalite kaybı üretir.
• Mühendislik maliyeti karşılaştırması ekibe özgü: optimizasyonun ekonomik olduğu ölçek eşiği kurumdan kuruma değişiyor.

Sonuç#

Token fiyatı bir maliyet göstergesidir, bir maliyet kaldıracı değil. Kaldıraç istek başına token ve istek sayısındadır; ikisi de mimari kararlarla belirlenir. Bu yüzden maliyet tartışması bir fiyat tablosuyla değil, bir bağlam bütçesi dökümüyle başlamalı: sistem istemi kaç token, geri getirilen parçalar kaç token, konuşma geçmişi kaç token.

Bu döküm çıkarıldığında kararlar kendiliğinden görünür hâle gelir ve sıralama neredeyse her zaman aynı çıkar: önce önbellek, sonra gereksiz bağlam eleme, sonra yönlendirme, en son model değişimi. Tersten başlayan ekipler, her model kuşağında bir kez daha ucuz modele geçip aynı savurgan mimariyle kalıyor.

Ne yapmalı?#

1. 1Faturayı etiketleyin

   Her çağrı iş akışına, ortama ve maliyet merkezine etiketlensin. Bu yapılmadan hiçbir optimizasyon ölçülemez.

2. 2Bağlam dökümünü çıkarın

   Sistem istemi, talimat, örnek, geri getirme ve geçmişin token paylarını ayrı ayrı ölçün. En büyük payın nerede olduğu genellikle sürpriz olur.

3. 3Önbelleği önce kurun

   Sabit öneki değişmez hâle getirip önbellek isabetini izleyin. Kalite kaybı olmayan tek müdahale bu.

4. 4Budamayı değerlendirme setiyle sınayın

   Her budama sonrası kaliteyi ölçün. Ölçmeden yapılan budama, tasarruf değil gizli kalite borcudur.

5. 5Yönlendirmeyi eşikle kurun

   Kolay soruları ucuz kademeye yönlendirirken sınıflandırma hatasının maliyetini de hesaplayın; yanlış yönlendirme sessizdir.

6. 6Kuyruk maliyetini bütçeye yazın

   Ortalama değil en pahalı yüzde birlik dilim bütçeyi belirler; özellikle ajan akışlarında bu dilim ortalamanın katlarıdır.