Agent Maliyeti: Token Fiyatı Değil, Görev Başı Maliyet

Doğru birim nedir?

“Milyon token başına şu kadar” bir fiyat listesidir, maliyet değil. Maliyeti veren şey, o token’ları kaç kez göndermek zorunda kaldığın.

gorev_basi = (tum_denemelerin_maliyeti) / (tamamlanan_gorev_sayisi)

# cloud:  maliyet = giris_token * giris_fiyat + cikis_token * cikis_fiyat
# kendi sunucun: maliyet = gpu_saniye * (saatlik_amortisman + elektrik) / 3600

# ornek (bizim gece raporu, once):
#   3 tur * ~39 bin token, 1 basarisiz deneme, 96 sn GPU
#   -> gorev basi 96 sn GPU (basarisiz deneme dahil 128 sn)

Başarısız denemeyi paya koymak önemli: bir görev ikinci denemede bitiyorsa, o görevin maliyeti iki denemenin toplamıdır. Bunu ayırmadığımız sürece “model ucuz ama sürekli tekrar ediyor” durumunu göremezsin.

Nereye gidiyor?

Koşu başına 118 bin token’lık ilk ölçümün dökümü:

İlk satır her şeyi anlatıyor: paranın %60’ı, zaten gönderilmiş veriyi yeniden göndermeye gidiyordu. Bunu düzeltmek bir model kararı değil, bir tool kararıydı — cevabı kırp, ham listeyi gönderme.

Sabit önek ve önbellek

İkinci kalem için basit bir kural var: değişmeyen kısmı başa koy. System prompt, tool tanımları ve sabit talimatlar hep aynı sırayla başta durursa, hem cloud sağlayıcıların önbelleği hem de yerel modelin KV cache’i işe yarıyor. Bizde başlangıçta tarih damgasını system prompt’un ikinci satırına koymuştuk — her istekte değişen bir satır, arkasındaki her şeyin önbelleğini iptal ediyordu. Tarihi sona taşımak koşu başına 9 saniye kazandırdı. Değişiklik: bir satırın yerini değiştirmek.

Ucuz model + 3 deneme mi, pahalı model + 1 mi?

İlk yazıda bu hesabı basitçe yapmıştık: küçük model 0,5 saniyede cevap veriyor ama 20 soruda 17 doğru; büyük model 11 saniyede 20/20. Şimdi aynı hesabı görev başı maliyetle yapalım:

Tablo tek bir cevap vermiyor; görev tipine göre veriyor. Basit sorularda küçük model 18 kat ucuz, çok adımlı analizde büyük model daha ucuz — çünkü küçük model iki buçuk kez deniyor ve üçte birinde yine de bitiremiyor.

Bu yüzden karar bir model seçimi değil, bir yönlendirme kararı oldu: soru tipi kapalı kümeden belirlenir, basit olan küçük modele, çok adımlı olan büyüğe gider. Yönlendirme sonrası görev başı maliyet %34 düştü ve doğruluk arttı; zor işler artık yanlış modelde üç kez denenmiyor.

Sahadan: üç hafta, üç düzeltme

Son satır önemli: maliyeti bilerek artırdığımız tek yer. Ayda bir çalışan, sabah toplantısına yetişmesi gereken bir iş için 2,8 kat token kabul edilebilir bir takas. Aynı takası günde 400 kez çalışan bir akışta yapsaydık cevap “hayır” olurdu. Maliyet kararı, iş sıklığıyla birlikte verilir.

Bütçe ve kill switch

Maliyeti ölçmek yetmiyor; bir yerde durması da gerekiyor. Üç sınır, üçü de akışta:

KOSU_TOKEN_BUTCE     = 120000    # bir kosu
KULLANICI_GUNLUK     = 2000000   # bir kullanici, bir gun
SISTEM_GUNLUK        = 60000000  # tum sistem

# asildiginda:
#   kosu durur, kismi sonuc kaydedilir, kullaniciya sebep yazilir
#   sistem sinirinda: yeni kosu kabul edilmez, kuyruga alinir
#   gece isleri kuyrugun onunde kalir (oncelik)

Sistem sınırına bir kez dayandık: bir kullanıcı aynı analizi 30 kez tetikleyen bir betik yazmıştı. Sınır olmasaydı gece raporları sıraya girecekti. Kill switch’in faydası parayı korumak değil, diğer işleri korumaktı.

Peki değer tarafı?

Maliyet tek başına anlamsız; karşılığına bakmak gerekiyor. Gece mutabakat raporu için:

• Elle: sabah bir kişi 12–15 dakika, haftada 5 gün.
• Agent ile: 19 saniye GPU + sabah 2 dakika kontrol.
• Kazanç: haftada yaklaşık 1 saat insan zamanı; buna karşılık bir bakım yükü ve bu yazıdaki ölçümler.

Dürüst olmak gerekirse: bu işi otomatikleştirmenin kendisi (akış, eval, iz, frenler) birkaç haftalık iş aldı. Tek bir rapor için yapılsa geri dönmezdi. Geri dönmesinin sebebi, aynı iskeletin üç işe daha hizmet etmesi. Agent’ın maliyeti görev başına düşer, yatırımı ise iskelet başına.

Ne izlemeli?

• Tamamlanan görev başına maliyet. Görev tipine göre ayrı ayrı; tek ortalama yanıltır.
• Tekrar gönderilen token oranı. Toplam ÷ benzersiz. 3’ün üstü kırpma işareti.
• Önbellek isabet oranı. Düşükse sabit önek bozulmuştur; ilk şüpheli prompt’un başındaki değişken bir satır.
• Görev başına deneme sayısı. 1,2’yi geçen görev tipi, yanlış modeldedir.
• Bütçe tetiklenmeleri. Hangi sınır, kaç kez, hangi kullanıcı?
• Boşta bekleyen GPU / kuyruk süresi. Kendi sunucunda gerçek darboğazı bu gösterir.

Kontrol listesi

Sonuç

“Token bedava” dediğim gün, aslında ölçmediğimi söylüyordum. Ölçünce görünen şey de model değildi: paranın çoğu, aynı veriyi tekrar tekrar göndermeye gidiyordu. Onu düzeltmek kırpma, tekrar koruması ve prompt’ta bir satırın yerini değiştirmekle oldu; görev başı 96 saniyeden 19 saniyeye indi.

Model seçimi de tek bir karar değil, bir eşleştirme çıktı: basit rapor sorusu küçük modele, çok adımlı analiz büyüğe. Bir tek yerde maliyeti bilerek artırdık ve bunu iş sıklığına bakarak yaptık.

Akılda kalacak cümle: pahalı olan model değil, tekrar etmektir. Faturayı düşürmek isteyen önce modele değil, kaç kez gönderdiğine baksın.