Gizli LLM faturaları: MCP tool şemaları ve skill'lerden kaynaklanan context şişkinliği, artı gölge eval harcaması

Agent yanıtlamadan önce iki token faturası

dev.to'da yayımlanan ilk analiz, bir kullanıcının henüz hiçbir şey yazmadan önce bir agent'ın context penceresinde zaten taşıdığı yükü ölçüyor. Yazar, OpenAI'nin tokenizer'ı tiktoken ile cl100k_base kodlamasını kullanarak referans bir kurulumu tokenize etti ve iki ayrı maliyet buldu.

İlki MCP tool şemaları. Bağlanan her Model Context Protocol sunucusu, sunduğu her tool'un tam JSON açıklamasını gönderir ve bu manifest her turda yeniden iletilir. Tam şema olarak render edilen 255 tool'luk bir katalog 71.929 token'a ulaştı — bu maliyet bir oturumda bir kez değil, her soruda bir kez ödeniyor.

İkinci, daha büyük maliyet ise skill'ler. Bir skill, isim artı şema değil; talimatlar, örnekler ve bir workflow'dan oluşan eksiksiz bir belge ve yazarın skills dizininde birleştirildiğinde toplam 1.109.242 token tutan 418 SKILL.md dosyası vardı. Bu bir context penceresine sığamayacağı için çoğu kurulum tahmini bir alt küme yüklüyor ve her turda skill başına birkaç bin token ödüyor. Yazar, bu maliyetin fark edilmemesinin nedeninin, birçok küçük ve makul görünen yükleme kararına yayılması olduğunu savunuyor.

Her iki durum için önerilen çözüm aynı: bir tool'u veya skill'i kullanıp kullanmaya karar vermek için yalnızca ismi yeterlidir; dolayısıyla yalnızca isimlerden oluşan bir index sunun ve tam içerikleri talep üzerine getirin. 255 tool'luk katalog, isim index'i olarak 581 token'a iniyor — yüzde 99,2'lik bir azalma — ve skills kataloğunun yerini 39 token'lık tek bir yerleşik işaretçi alıyor; her arama 501 token'a mal oluyor. Yazar bu pattern'i açık kaynak, bağımlılığı olmayan bir Python CLI olan mcptoon olarak yayımlıyor. Yazı ayrıca, aynı görevi bir CLI üzerinden 1.365 token, MCP üzerinden ise 44.026 token ile ölçen bir Firecrawl benchmark'ına atıf yapıyor — 32 katlık bir fark — ve bir Anthropic mühendislik yazısının şema tarafında bu savı zaten ortaya koyduğunu belirtiyor.

Her iki rakam da tek bir makineden geliyor ve yazar, bunların bir sabiti değil ölçek anlamına geldiğini açıkça belirtiyor: birkaç sunucu ve bir düzine skill'den oluşan küçük bir kurulum önce ölçmeli ve ekstra katmanı atlamalı.

Gölge fatura: çalıştığını kanıklamanın bedeli

dev.to'daki The Agent Loop'tan ikinci analiz ise çalıştıktan sonra gelen maliyere, yani değerlendirmeye (eval) bakıyor. Yaklaşımı şöyle: LLM-as-judge ile puanlama, kendi çarpanları olan ikinci bir inference iş yüküdür. Yazı Arize'ın formülünü aktarıyor: üretim değerlendirme maliyeti, trafik hacmi çarpı örnekleme oranı çarpı değerlendirme yüzeyleri çarpı değerlendirici maliyeti, artı insan incelemesi, artı elde tutma (retention).

Bu ne kadar büyük olabilir? Yazı, bir Monte Carlo raporunda bir veri liderinin değerlendirme maliyetlerini taban agent iş yükünün 10 katı olarak tanımladığına atıf yapıyor — ve bunun bir benchmark değil, tek bir anekdot olduğunu açıkça belirtiyor.

Savunulabilir çarpanlar literatürden geliyor. τ-bench makalesi, en iyi gpt-4o function-calling agent'ının ortalama görev başarısının yüzde 60'ı aştığını, buna karşılık pass^8'in yüzde 25'in altına düştüğünü raporluyor; yani güvenilirliği göstermek rollout gerektiriyor. Makale, görev başına tek denemeyi yaklaşık 200 dolara fiyatlıyor; görev başına agent için 0,38 dolar, simüle edilmiş kullanıcı için 0,23 dolar. Yazı bir uyarı ekliyor: pass^8 sekiz katlı bir rollout fırsatıdır, ama zorunlu olarak sekiz katlı bir dolar faturası değildir; çünkü arada caching, örnekleme ve trajectory uzunlukları vardır. Ayrıca bir judge-ayarlama makalesi (arXiv 2501.17178), 4.480 judge yapılandırmasını aramanın yaklaşık 2.000 dolar tuttuğunu, tam Alpaca-Eval tarzı bir değerlendirmenin ise kabaca 2 milyon dolar gerektirdiğini — tek bir annotasyonun yaklaşık 24 dolar olduğu — tahmin etmiş. The Agent Loop, "eval'ler bir çalıştırmanın 5–30 katına mal olur" şeklindeki evrensel bir sabit için birincil bir kaynak bulamadığını belirtiyor.

Önerilen merdiven gölge faturayı küçük tutuyor: önce deterministik kontroller — exit code'lar, şema doğrulaması ve nihai veritabanı durumunun karşılaştırılması; τ-bench de tam olarak böyle puanlar — her şeyi puanlamak yerine üretim trafiğinden örnek alın; belirsizlik ve sonuç büyüdükçe tırmandırın; kolay katman için küçük ve ucuz bir judge modeli kullanın; insanları kalibrasyon ve yüksek sonuçlu kuyruk için tutun.

Koda rahatsız edici: ucuz doğrulama otomatik olarak doğru doğrulama değildir. Yazı, Opus 4.5'in CORE-Bench'te yüzde 42 aldığı, ta ki bir araştırmacının yaklaşık 96,125 beklenen bir soruya 96,12 verilen yanıtı cezalandıran katı bir notlandırmayı bulana kadar — ve sonrasında puanın yüzde 95'e sıçradığı yönündeki Anthropic belglemesini aktarıyor.

Neden önemli

İki analiz de aynı sonuca varıyor: görünen inference faturası bütün fatura değil. Context yükü, kaç tool ve skill bağladığınızla ölçeklenen tur başına bir çarpan; değerlendirme ise ne kadar doğruladığınızla ölçeklenen, büyük ölçüde bütçelenmemiş bir iş yükü. Ne milyon token'lık skill kataloğu ne de 10 katlık eval anekdotu evrensel. Ortak reçet, önce kendi sayılarınızı ölçmeniz — bir tarafta tokenizer sayımı, diğer tarafta bir maliyet formülü — ve herhangi bir tekil oranı, kendi iş yükünüzde çalıştırmadan şüpheyle karşılamanız.