Microsoft Foundry ile Ajan Maliyetini Sınırlama ve ROI

⏱️ 8 dk okuma📅 20 Eylül 2026

Yapay zekâ ajanları pilot projelerden çıkıp kurumsal ölçeğe yayıldığında maliyet, tek bir fatura kaleminden ibaret olmaktan çıkıyor. Microsoft Azure blogunda Steve Sweetman imzasıyla yayımlanan “The Economics of Agent Optimization” serisinin dördüncü ve son yazısı, ajan yönetişimini tam da bu noktada ele alıyor: tüketimi görünür ve atfedilebilir kılmak, istek yolunda sınırlamak ve sonunda “bu ajan maliyetine değiyor mu?” sorusunu iş terimleriyle yanıtlamak. Bu yazıda, kaynağın aktardığı yaklaşımı ve Microsoft Foundry ile Azure API Management tarafındaki ilgili yetenekleri derli toplu biçimde özetliyorum.

Neden bütçe uyarısı tek başına yetmiyor

Ajan yönetişimi genellikle güvenlik, uyumluluk ve yaşam döngüsü yönetimi başlıklarıyla konuşuluyor; hangi ajanların var olduğu, sahibinin kim olduğu, neye erişebildiği ve hangi politikaların geçerli olduğu. Kaynak, bu tablonun aynı zamanda maliyet optimizasyonunun da temeli olduğunu vurguluyor. Tutarlı bir yönetişim yoksa her ekip model, araç, kapasite ve limit seçimlerini kendi başına yapar; küçük verimsizlikler her ajan ve her tür üzerinden katlanarak büyür.

Burada önemli bir ayrım var: Geleneksel maliyet yönetimi araçları harcamayı izleyebilir, gerçekleşen veya öngörülen maliyet için uyarı üretebilir; ancak tipik olarak faturalama verisi üzerinde çalışır, isteğin geçtiği yolda değil. Yeniden deneme döngüsüne takılmış bir ajan, bir sonraki bütçe değerlendirmesini beklemez. Yazının benzetmesiyle: Bütçe uyarısı bir duman dedektörüdür; ajanın ayrıca bir devre kesiciye ihtiyacı vardır. Etkili maliyet yönetişimi bu nedenle üç ayak üzerinde duruyor — harcamayı görmek, sınırlamak ve getiriyi kanıtlamak.

Harcamayı doğduğu yerde görmek

Maliyetler tek bir toplam rakam olarak geldiğinde yönetilmesi zorlaşır. Bir dağıtım birden fazla ajana hizmet verebilir, bir ajan birden fazla model ve araç kullanabilir, tek bir iş sonucu çok sayıda tür gerektirebilir. Bu bilgi faturaya yansıdığında iş bağlamı çoktan kaybolmuş olur.

Foundry içindeki maliyet yönetimi yetenekleri bu bağlamı, maliyeti üreten sisteme yaklaştırıyor. Ekipler projeler genelinde tahmini maliyetleri görebiliyor, tek tek ajanların maliyet ve token kullanımını inceleyebiliyor, model maliyetlerini izleyebiliyor. Kaynak burada net bir sınır çiziyor: Bu değerler operasyonel karar almak içindir; finansal mutabakatta kayıt sistemi Microsoft Cost Management ve faturalanan tutarlar olmaya devam eder.

Foundry ayrıca proje düzeyinde maliyet atfını destekliyor. Her Foundry projesi, altındaki kullanıma otomatik olarak bir proje etiketiyle ilişkilendiriliyor; FinOps ekipleri Cost Analysis’i bu etikete göre filtreleyerek harcamayı ilgili iş birimine, ekibe veya iş yüküne dağıtabiliyor. Kaynağa göre bu yetenek, Azure OpenAI dahil olmak üzere Microsoft Azure tarafından satılan modeller için şu an önizleme aşamasında.

Ağ geçidi katmanında Azure API Management’ın AI Gateway’i token metriklerini API, ürün, kullanıcı, abonelik, gateway ve arka uç kırılımıyla üretebiliyor. Foundry’deki izleme (tracing) ise bir ajan çalışması için araç kullanımını, yeniden denemeleri, gecikmeyi, token tüketimini ve maliyetleri kaydediyor.

Gözlemlenebilirlik sinyalleri bir araya geldiğinde sadece “ne kadar harcandı” değil, “neden harcandı” sorusunu da yanıtlıyor:

İzler (traces): Model çağrılarını, araç çağrımlarını, yeniden denemeleri, gecikmeyi ve token kullanımını açığa çıkarır.
İzleme (monitoring): Üretimdeki eğilimleri ve anormallikleri yüzeye taşır.
Değerlendirmeler (evaluations): Kalite, güvenlik, kaynağa dayalılık ve görev tamamlama ölçer. Sürekli çalıştırıldığında, “en büyük modele” varsayılan olarak yönelmek yerine daha küçük bir modelin kalite eşiğini karşılayıp karşılamadığını sınamak için kanıt üretir. Güvenlik değerlendiricileri, prompt injection, hassas veri sızıntısı ve zararlı içerik gibi sorunları üretime ulaşmadan işaretleyebilir.

Bu sinyaller birlikte okunduğunda, artan maliyetin müşteri talebinden mi, verimsiz ajan davranışından mı, kalite gerilemesinden mi yoksa mimari sorunlardan mı kaynaklandığı ayrıştırılabiliyor.

Her katmanda harcama sınırı koymak

Görünürlük paranın nereye gittiğini söyler; limitler ise akışın devam edip edemeyeceğini belirler. Kaynak kontrol sistemini farklı kapsam ve hızlarda çalışan üç katmanda tanımlıyor.

1. Foundry içinde limit uygulamak

AI Gateway yapılandırıldığında, Foundry Control Plane model dağıtımları için proje kapsamında dakika başına token oranı limitleri ve toplam token kotaları uygulayabiliyor. Oran limitini aşan bir istek 429 Too Many Requests, token kotasını tüketen bir çağıran ise 403 Forbidden yanıtı alıyor. Maliyet uyarısından farkı, uygulamanın doğrudan istek yolunda gerçekleşmesi: Bir projenin tüketimi paylaşılan kapasiteyi tekeline almadan sınırlanabiliyor ve projeler için farklı sınırlar tanımlanabiliyor. Kotalar saatlik, günlük, haftalık, aylık veya yıllık dönemlerde işleyebiliyor; Azure API Management destekli ağ geçidi ve token limitleri Foundry Control Plane üzerinden yönetilebiliyor.

2. Modeller ve sağlayıcılar genelinde politika

Projeler veya model sağlayıcıları arasında geçerli kontroller için llm-token-limit politikası, anahtar başına tüketimi oran, kümülatif kota veya her ikisiyle sınırlıyor. Anahtar; bir abonelik, uygulama, ekip, müşteri, iş yükü kimliği ya da başka bir iş sınırını temsil edebiliyor. AI Gateway aynı yönetişim modelini OpenAI uyumlu API’ler, Anthropic Messages API’si, ayrıca MCP sunucuları ve ajanlar arası API’ler için uygulayabiliyor. Arka uç yük dengeleme, kullandıkça öde dağıtımlarına taşmadan önce sağlanmış (provisioned) kapasiteyi önceliklendirebiliyor; devre kesiciler ise hata veren veya kısıtlanan bir arka uca istek göndermeyi geçici olarak durdurabiliyor.

Kaynak, dağıtık limitlerin doğal sınırlarını da açıkça belirtiyor: Sayaçlar her ağ geçidinde bağımsız tutulur ve nihai token tüketimi ancak yanıtlar döndükten sonra bilindiğinden, eşzamanlı istekler küçük ve geçici bir aşıma yol açabilir. Amaç mutlak kusursuzluk değil, sınırsız tüketimi öngörülebilir bir işletim sınırıyla değiştirmek.

3. Hesap verebilirlik için finansal bütçeler

Microsoft Cost Management bütçeleri token limitlerinden farklı bir amaca hizmet ediyor. Gerçek fiyatlar, krediler ve satın alma taahhütleri dahil Azure faturalama verisini kullanarak finans ve BT’ye kurumun ne harcadığına ve ne harcamasının öngörüldüğüne dair yetkili bir görünüm sunuyor. Ekipler bütçe eşikleri belirleyip gerçekleşen veya öngörülen maliyet bu eşiklere yaklaştığında sahipleri bilgilendirebiliyor; bütçeyi bir Azure Monitor eylem grubuna bağlayarak kayıt açma, operasyon ekibini uyarma ya da Logic App veya otomasyon runbook’u başlatma gibi kendi tasarladıkları iş akışlarını tetikleyebiliyor. Maliyet anomali tespiti de harcama tarihsel örüntüsünden saptığında ek bir uyarı sağlıyor.

Bunlar değerli hesap verebilirlik ve eskalasyon araçları; ancak anlık harcama tavanı değiller, çünkü tüketim gerçekleştikten sonra faturalama verisine tepki veriyorlar. Token limitleri ise her model isteğinin yolunda, daha erken devreye giriyor. Kurumların ikisine birden ihtiyacı var.

Kaynak, bu iki katmanın bugün farklı birimlerle çalıştığını da kabul ediyor: Platform tüketimi token cinsinden uyguluyor, finans ise yatırımı dolar üzerinden planlayıp dağıtıyor. Token fiyatları modele ve tekliflere göre değiştiği için bir token kotası tek ve sabit bir dolar tutarına çevrilmiyor. Microsoft, dolar cinsinden bütçeler, daha ince taneli atıf ve politika güdümlü kontrolleri ajanların çalıştığı yere yaklaştıracak gelecekteki yeteneklerle bu boşluğu kapatmak üzere çalıştığını belirtiyor.

Ajanın ürettiği değeri ölçmek: ROI

Tüketime tavan koymak sorunun yalnızca yarısını çözüyor. En ucuz ajan mutlaka en iyi yatırım değil: Daha pahalı olup belirgin biçimde daha fazla vakayı çözen bir ajan ek kapasiteyi hak edebilirken, ucuz ama görevini nadiren tamamlayan bir ajan hak etmeyebilir. Bu nedenle yönetişimin token ve dolara ek olarak üçüncü bir birime ihtiyacı var: iş sonuçları.

Foundry’de şu an özel önizlemede (private preview) olan “ROI for agents”, ajan maliyetlerini iş sonuçlarına bağlamayı hedefliyor. Ekipler izlemek istedikleri sonuçları tanımlıyor — başarılı görev tamamlama, müşteri memnuniyeti veya vaka yönlendirmesinin önlenmesi (case deflection) gibi — bu sonuçlara bir iş değeri atıyor ve başarının nasıl ölçüleceğini belirliyor. Foundry, ajanın hangi sonuçlara ulaştığını ve bu yolda oluşan model ile araç maliyetlerini izleyerek şunları hesaplıyor:

Üretilen değer: Başarılı iş sonuçlarına atfedilen toplam değer.
Toplam maliyet: Bu sonuçlara ulaşmak için oluşan model ve araç maliyetleri.
Net değer: Maliyetler düşüldükten sonra kalan değer.
ROI: Gereken yatırıma göre üretilen getiri.

Pano günlük eğilimleri gösteriyor ve model maliyetlerini araç maliyetlerinden ayırıyor. Ekipler ajan sürümlerini konuşma başına ortalama değer, geçme oranı ve iyileşme yüzdesi üzerinden karşılaştırabiliyor. Böylece optimizasyon kararları iş diliyle savunulabilir hale geliyor: “Yeni sürüm daha az token tüketiyor” yerine “yeni sürüm daha fazla net değer üretiyor”.

ROI görünümü mühendislik kanıtına da bağlı. Ekipler en düşük ROI’li konuşmaları ve izleri inceleyerek aşırı büyük bir modeli, tekrarlayan araç çağrılarını veya anlamlı sonuç üretmeden token tüketen bir iş akışını tespit edebiliyor. Düşük ROI’li bir iz; farklı yönlendirilmesi gereken bir isteğe, kaldırılması gereken bir bağlama ya da optimize edilmesi gereken bir ajan yapılandırmasına işaret edebiliyor.

Sorumluluk sınırı: Foundry ve Microsoft Agent 365

Serinin dört yazısı, üç hızda çalışan tek bir optimizasyon sistemini tarif ediyor: çalışma zamanında model yönlendirme, dağıtım seçimleri ve önbellekleme her isteği doğru boyutlandırıyor; günler ve haftalar içinde bağlam mühendisliği, hafıza, araçlar ve ajan optimizasyonu iş akışını iyileştiriyor; sürekli olarak da yönetişim tüketimi atfediyor, limitleri uyguluyor ve portföyün değer üretip üretmediğini ölçüyor. Aynı kanıt seti her katmanı birbirine bağlıyor: izler ajanın ne yaptığını, değerlendirmeler çıktının iyi olup olmadığını, maliyet atfı paranın nereye gittiğini, ROI ise işin buna değip değmediğini gösteriyor.

Kaynak sorumluluk sınırını da netleştiriyor. Foundry, ajan geliştiren ekipler için tasarlanmış; geliştiriciler burada inşa ediyor, test ediyor ve optimize ediyor. Foundry Control Plane, maliyet eğilimlerinden anormalliklere, token kullanımından yaşam döngüsü kontrollerine kadar yayımlanan her şeyin operasyonel görünümünü veriyor; Azure Policy, Microsoft Defender ve Microsoft Purview bu tabloya dokunuyor. Microsoft Agent 365 ise tüm kurumsal envanterden sorumlu olanlar için: BT yöneticileri ve güvenlik ekipleri, ister Foundry’den, ister Microsoft 365’ten, ister bir iş ortağı platformundan gelsin, tenant içindeki her ajanı keşfetmek, envanterlemek, güvenliğini sağlamak ve yönetmek için kullanıyor. Bu seride ele alınan FinOps yetenekleri çizginin Foundry tarafında duruyor.

Nereden başlamalı

Kaynağın önerdiği başlangıç sırası basit: Önce ajan tüketimini görünür ve atfedilebilir hale getirin, hangi ajanların ve ekiplerin kullanımı sürüklediğini belirleyin. Ardından beklenmedik tüketimi sınırlamak için istek zamanında limitler uygulayın ve bu kontrolleri finansal bütçeler ile uyarılarla eşleştirin. Son adımda maliyeti iş sonuçlarına bağlayarak hangi ajanı optimize edeceğinize, hangisini ölçekleyeceğinize, hangisini emekliye ayıracağınıza karar verin.

Özetle ajan optimizasyonu, her isteğin maliyetini sıfıra indirmek değil; ajanları ciddi bir yatırıma uygulanacak disiplinle işletmek anlamına geliyor: tasarım gereği verimli, ölçeklenirken sınırlandırılmış ve ürettiği değerden hesap verebilir ajanlar.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102