Microsoft’tan Prateek, Azure Architecture blogunda AI ajanlarının maliyet yönetimine dair yaygın bir yanılgıyı hedef alıyor: token fiyatı tek başına ajanlar için kötü bir ekonomik model. Yazının çıkış noktası sert bir tespit: token fiyatları düşerken agent maliyetleri düşmüyor, aksine öngörülemez hâle geliyor. Çözüm önerisi ise bir metrikten ibaret değil, Azure üzerine oturtulmuş bir kontrolör mimarisi.
Ucuz token tuzağı
Sabit bir yetenek seviyesine ulaşmanın fiyatı gerçekten sert düştü. Stanford’un 2025 AI Index raporu, GPT-3.5 seviyesindeki çıkarım maliyetinde 2022 sonu ile 2024 sonu arasında yaklaşık 280 kat düşüş raporluyor. Epoch AI de benchmark başına dik (ama düzensiz) fiyat düşüşleri izliyor.
Sezgisel sonuç şu olurdu: ajanları çalıştırmak ucuzluyor. Operasyonel gerçek ise tam tersi.
Çünkü ajanlar ucuzlayan çıkarımı daha uzun ve stokastik yörüngelere çeviriyor: büyüyen context window’lar, tekrar tekrar gönderilen tool şemaları, retry’lar, reflection döngüleri ve sub-agent fan-out’u. Agentic coding üzerine yapılan bir çalışmada, aynı ajanın aynı görevdeki tekrarlı koşuları token maliyetinde 30 kata varan fark göstermiş.
Yazarın vurgusu net: tek bir mantıksal görev, ajanın izlediği yola bağlı olarak otuz kat daha pahalıya mal olabiliyorsa, “token başına ortalama maliyeti optimize etmek” yanlış sistemi verimli göstermekten başka işe yaramıyor. Aynı argüman birden fazla deneme, birden fazla MCP çağrısı, reasoning ya da çoklu skill/hook/tool çağrısı gerektiren diğer agentic sistemler için de geçerli.
Dolayısıyla token ekonomisinin asıl sorusu “token fiyatı ne?” değil: “kabul edilebilir tek bir birim faydalı işi elde etmek ne kadara mal oluyor ve ajan çalışmadan önce bu sayıya ne kadar güvenebiliriz?”
Asıl önemli birim: kabul edilen görev başı maliyet
Yazar token ekonomisini “belirsizlik altında faydalı AI işinin birim ekonomisini yönetmek” olarak tanımlıyor. Anlamlı birim cost per accepted task, yani kabul edilen görev başı maliyet.
A = 1, bir görevin kabul kriterlerini (acceptance rubric) geçtiği anlamına gelsin. Bir π politikasının uzun vadeli birim maliyeti yaklaşık olarak şu:
Birim maliyet ≈ E[ C_task | π ] / P( A = 1 | π )Pay beklenen görev maliyeti, payda ise çıktının gerçekten kabul edilebilir olma olasılığı. Bu, FinOps’un başarılı ve başarısız AI çıktıları arasında yaptığı ayrımı ve maliyeti iş yükü değeriyle ilişkilendirme önerisini izliyor.
Formülün mühendislik problemini nasıl yeniden çerçevelediğini gösteren örnek çarpıcı: maliyeti yarıya indiren ama kabul oranını %95’ten %70’e düşüren “daha ucuz” bir politika, kabul edilen görev başına aslında daha pahalı. Ve bunu yalnızca bu oran görünür kılıyor.
Beş adımlı disiplin
Bu yeniden çerçeveleme, “en ucuz modeli seç” yaklaşımını beş adımlı bir disipline dönüştürüyor:
- Tahmin et: Tek bir token sayısı değil, bir dağılım öngör.
- Seç: Göreve ve riskine makul gelen bir maliyet politikası belirle.
- Uygula: Çalışma anında routing, context, cache ve bütçe kontrollerini zorla.
- Değerlendir: Çıktının iş yüküne özgü kalite tabanını hâlâ geçip geçmediğini ölç.
- Geri al ve kalibre et: Güvenli olmayan tasarrufları geri çevir, tahmin ile gerçek kullanımı mutabakatla, bir sonraki tahmini kalibre et.
Metrikten kontrolöre: stokastik optimizasyon
Maliyet rastgele bir değişkense hedef de stokastik oluyor. Amaç beklenen görev maliyetini iki kısıt altında minimize etmek:
- Kalite tabanı: Desteklenen her segment s için Q_s ≥ Q_min
- Şans kısıtı (chance constraint): Bütçe B’nin aşılma olasılığı tolere edilen ε değerini geçmemeli
Yazının dürüst tarafı, parçaların hepsinin ödünç alındığını açıkça söylemesi:
- Stokastik optimizasyon → beklenen maliyet hedefi
- FrugalGPT ve Confident Adaptive Language Modeling → performansı korurken maliyeti kesmenin LLM’deki emsalleri
- SRE service-level objective’leri → “kabul edilebilir servis”i aksiyon tetikleyen bir eşik olarak ele almak
- Group DRO → ortalamaların grup başarısızlıklarını gizlediği içgörüsü
- Charnes–Cooper chance-constrained programming → olasılıksal bütçe limiti
Yazarın katkısı olarak tanımladığı şey bunları icat etmek değil, hepsini tek bir agent kontrolörüne kablolamak.
İki dürüst çekince
Yazı, kendi modelinin sınırlarını da açıkça koyuyor:
- Q_s için güven aralığıyla düzeltilmiş alt sınır gerekiyor. Seyrek segmentler iki örnekle politika değişikliği tetiklememeli.
- Şans kısıtı bir garanti değil. Tahminin yüzdelik dilim kapsaması gerçek trace’lerle kalibre edilene kadar geçerli sayılamaz. Modellenmiş bir P95 bir planlama tahminidir, vaat edilmiş bir %5 aşım sınırı değil.
Döngünün iki yarısı: feed-forward ve feedback
Kontrolör, planlama ve çalışma zamanı olmak üzere iki yarıya ayrılıyor. Yazar bu ikisini iki prototip olarak geliştirmiş:
FutureTokenPredictor (feed-forward tarafı): İş akışı arketiplerini ve belirsiz iterasyon sayılarını modelleyerek çalıştırma öncesi P50/P95 tarzı planlama tahminleri üretiyor ve bir politika öneriyor. İstek yolunun (request path) dışında kalıyor.
TokenGov (feedback tarafı): İstek yolunda kabul edilmiş maliyet politikasını uyguluyor. Bant dışı (out-of-band) bir kontrol düzlemi sonuçları değerlendiriyor ve kalite geriletince dışsallaştırılmış politikayı değiştiriyor. Runtime telemetrisi daha sonra bir sonraki tahmin için kalibrasyon verisi olarak predictor’a geri akıyor.
Yazının belki de en akılda kalıcı cümlesi burada: “Kontrolsüz tahmin bir spreadsheet’tir. Kalite geri bildirimi olmayan kontrol ise en zor segmentlerinizi sessizce bozar.” Değer, ikisi arasındaki kabloda: zorlanabilir bir politikaya dönüşen tahmin, bir maliyet aksiyonunu geri alabilen eval verdict’i ve bir sonraki tahmini keskinleştiren gerçek kullanım verisi.
Denklem Azure’a nasıl oturuyor?
Yazının token ekonomisini bir metrikten mimariye dönüştürdüğü bölüm burası. Kontrolördeki her terim somut bir Azure kontrolüne eşleniyor:
- π (politika) → Azure App Configuration’da dışsallaştırılıyor; API Management GenAI gateway ile zorlanıyor (routing, context, cache, token politikaları)
- E[C_task | π] (beklenen maliyet) → APIM gateway, model ve Application Insights telemetrisinden yeniden kuruluyor
- Q_s (segment kalitesi) → Azure AI Foundry ile golden set’ler ve örneklenmiş production trace’leri üzerinde değerlendirme
- B, ε (bütçe ve aşım toleransı) → tahmin bilgilendirmeli limitler ve Azure Monitor uyarıları; tahsis için Cost Management
- Reversion (geri alma) → Monitor tarafından tetiklenen bir Azure Function, App Configuration’daki politikayı sıkılaştırıyor veya geri alıyor; kod deploy etmeden eval’den enforcement’a döngüyü kapatıyor
Yazar, bu primitiflerin çoğunun zaten var olduğunu ve tek tek dokümante edildiğini de belirtiyor: APIM token kotaları, semantic caching ve token metrikleri sunuyor; Foundry Model Router cost/balanced/quality routing modları veriyor; Foundry cloud evaluation dataset’leri ve örneklenmiş trace’leri skorluyor.
Kapatılmayan ilginç boşluk ise bağlı mekanizma: bir değerlendirme verdict’inin maliyet tasarrufu aksiyonunu kısıtlayabilmesi ya da geri çevirebilmesi, ve gerçek kullanımın bir sonraki tahmini iyileştirmesi.
Kavramdan uygulamaya
Versiyon 1 yayında: FutureTokenPredictor adında yerel bir MCP sunucusu ve basit bir UI. AI/agentic çözümünüzü tarif ediyorsunuz, araç bir topoloji öneriyor. Model seçiminize bağlı olarak stüdyo token kullanım aralığını ve tahmini maliyetlerini öngörüyor.
Tam versiyonda bu tahmin bir politika inşa etmek ve AI harcamanızı buna göre yönetmek için kullanılıyor. Versiyon 2 tam governance ve kontrol ile yakında yayınlanacak.
Proje TokenEconomics adıyla GitHub’da erişilebilir durumda; yazar klonlanmasını, denenmesini ve pull request ya da yorum üzerinden geri bildirim verilmesini istiyor.
Bu yazı, son dönemde giderek daha çok konuştuğumuz “AI maliyeti nasıl yönetilir” sorusuna alışılmadık derecede disiplinli bir cevap getiriyor. GitHub Copilot tarafındaki pratik taktikleri daha önce ele almıştık (GitHub Copilot Maliyet Optimizasyonu: 12 Pratik Adım); Prateek’in yazısı ise aynı problemi bir kademe yukarıdan, mimari ve kontrol teorisi düzleminde ele alıyor. En değerli katkısı bence “kabul edilen görev başı maliyet” formülü: maliyet düşürme çalışmalarının kalite üzerindeki gizli bedelini görünür kılan basit ama etkili bir çerçeve. Kurumsal FinOps ekiplerinin AI harcamalarını token grafiklerine bakarak yönetmeye çalıştığı bir dönemde, “ucuzlattık ama kabul oranı düştü, aslında pahalılaştık” tespitini yapabilmek ciddi bir olgunluk sıçraması olacaktır. APIM + App Configuration + Foundry eval + Monitor-tetiklemeli Azure Function zinciri de bunun Azure’da bugün kurulabilir olduğunu gösteriyor; eksik olan tek şey parçaları birbirine bağlayan mekanizma ve yazar tam olarak onu inşa ediyor.
Kaynak: https://techcommunity.microsoft.com/blog/azurearchitectureblog/token-economics-in-practice/4540472
