Ajan Ekonomisi: Pilotlardan Ölçülebilir Getirilere

⏱️ 5 dk okuma📅 15 Ağustos 2026

Kurumsal yapay zeka tartışması artık beyaz tahtadan bütçe toplantısına taşındı. İki yıl önce sorulan “Bu teknoloji işe yarıyor mu?” sorusunun yerini bugün çok daha rahatsız edici bir soru aldı: “Kendini finanse ediyor mu?” Microsoft Foundry üzerinde çözüm geliştiren 100.000’i aşkın organizasyonun deneyimi, cevabın model seçiminden çok mali disipline bağlı olduğunu gösteriyor. Bu yazıda Microsoft’un dört bölümlük “The Economics of Agent Optimization” serisinin ilk yazısındaki çerçeveyi ve Foundry’nin bu çerçeveyi nasıl operasyonel hale getirdiğini ele alıyorum.

Bütçeler büyüyor, peki disiplin?

Microsoft’un IDC ile yürüttüğü ve 4.000’den fazla iş liderinin katıldığı ankete göre katılımcıların %71’i yapay zeka bütçesini artırmayı planlıyor. Kaynaklar hem BT hem de BT dışı birimlerden geliyor. Öne çıkan ekiplerin ortak noktası daha ucuz bir model bulmak değil; yapay zekayı tek seferlik pilotlar dizisi yerine yönetilen bir yatırım sistemi gibi çalıştırmaları. Her istek işine göre boyutlandırılıyor, her ajan çalıştıkça iyileştiriliyor, her dolarlık harcama sınırlanıp hesaba geçiriliyor.

Yapay zeka maliyeti aslında nereden doğuyor?

Maliyeti yalnızca seçilen model belirlemiyor; modelin etrafına inşa edilen uygulama veya ajan da şekillendiriyor. Her istek, girdi tokenlarını (sistem istemi, konuşma geçmişi, araç tanımları, getirilen içerikler) ve modelin ürettiği çıktı tokenlarını içerir. Modeller durumsuz (stateless) çalıştığı için tam bağlam her çağrıda yeniden gönderilir. Kullanıcı yalnızca kısa bir devam sorusu sorsa bile maliyet zamanla birikir.

Ajanlar bu tabloya bir katman daha ekler. Tek bir kullanıcı isteği; seçenek değerlendirme, yeniden deneme ve birden fazla araç çağrısı doğurabilir. Bu yüzden iş akışı tasarımı, model seçimi kadar belirleyicidir.

Görünürlük: tek fatura kaleminden fazlası

Yapay zeka harcaması tek bir toplam rakam olarak göründüğünde yönetilemez. Ekiplerin uygulama, ajan, iş akışı ve model bazında görünürlüğe ihtiyacı var. Bu düzeyde bir atıf olmadan maliyetleri açıklamak, iyileştirmeleri önceliklendirmek veya optimizasyon çalışmasının etkisini ölçmek zorlaşır.

Yapay zeka için FinOps yaklaşımı

FinOps, değişken bulut harcamalarına finansal hesap verebilirlik getirmek için doğmuş bir disiplindi; mühendislik, finans ve ürün ekiplerini aynı rakamlar üzerinde buluşturuyordu. Microsoft’un yapay zekaya uyarladığı FinOps yaklaşımı dört taahhüde dayanıyor:

Fonlaması öngörülebilir bir yapay zeka
Tasarım gereği verimli çalışma
Ölçekte optimize edilebilir olma
Değeri kanıtlanmış çıktılar

Bu yaklaşım, ekiplerin zaten kullandığı ürünlere gömülü olarak sunuluyor: ajanların geliştirilip çalıştırıldığı Microsoft Foundry ve GitHub, tahsis ve iç faturalandırma için Microsoft Cost Management, taahhüde dayalı tasarruf için Azure fiyatlandırma seçenekleri ve yapay zeka trafiğini ölçüp yöneten Azure API Management. Microsoft Agent 365 ise aynı disiplini tenant düzeyine taşıyor; Microsoft ve üçüncü taraf ajanlar için harcama politikalarını, bütçe tavanlarını ve departman bazlı iç faturalandırmayı tek yerde toplamayı hedefliyor.

Foundry’nin kapalı döngüsü: üç farklı hızda karar

Yönetilen bir yatırım sistemi üç farklı zaman ölçeğinde karar üretir: isteği anlık olarak, ajan iş akışını günler-haftalar içinde ve harcamayı sürekli olarak optimize eder. Foundry bu üç kararı da destekleyecek yeteneklerle geliyor.

1. İsteği çalışma anında optimize etmek

Amaç, basit işlerin sınır (frontier) model fiyatları ödememesi. Bunun için:

Model router: Her istemi maliyet, kalite ve dengeli modlar arasında yönlendirir.
Dağıtım ve fiyatlandırma seçenekleri: Global, Data Zone ve Regional dağıtımlar ile Standard, Priority, Provisioned Throughput ve Batch işleme modları arasında iş yükünün gereksinimine göre eşleme yapılır.
İstem (prompt) ve anlamsal önbellek: Tekrar eden bağlamı yeniden hesaplamak yerine yeniden kullanır.
Fine-tuning: Daha küçük ve ince ayarlı bir modelin belirli görevlerde daha büyük modele yaklaşmasını sağlayarak token başına maliyeti ve istem uzunluğunu düşürür.
Microsoft IQ ve Foundry IQ: Ajanlara izin duyarlı, yeniden kullanılabilir bilgi tabanları sunar; ajanik erişim (agentic retrieval) yalnızca en ilgili bağlamı seçerek gereksiz girdi tokenlarını azaltır.

2. İş akışını zamanla optimize etmek

Ajanlar öğrendikçe daha ucuz çalışmalı. Bu katmanda öne çıkan yetenekler:

Agent optimizer: İstemleri, modelleri, araçları ve becerileri kendi değerlendiricilerinize karşı test eder; çoğu zaman kaliteyi koruyarak daha küçük ve ucuz bir modele geçilmesini sağlar.
Toolboxes: Her isteğe tüm araç tanımları yerine yalnızca gereken araçları gönderir.
Memory: Prosedürel, kullanıcı ve oturum belleği ile bağlamı taşırken tüm geçmişi tekrar tekrar göndermeyi önler.

3. Harcamayı sürekli yönetmek

Ölçek büyüdükçe limitlerin tutması gerekir. Bu noktada:

Azure API Management AI Gateway: Foundry uç noktalarının önüne konumlandırılabilir; token oranı sınırları, kotalar ve önbellekleme uygulanır. Microsoft, AI Gateway işlevlerinin Foundry ile daha bütünleşik hale getirileceğini belirtiyor.
Foundry içi bütçeler ve zorlama: Yakında yerel olarak sunulacak; harcama limitleri ajanların çalıştığı yere yakınlaşacak.
Cost Management entegrasyonu: Foundry bugün model ve dağıtım düzeyinde maliyet raporlaması sunuyor; bütçeler, uyarılar ve faturalanan maliyetler için sistem kaydı Azure Cost Management. Ajan ve oturum düzeyinde daha ayrıntılı atıf yol haritasında yer alıyor.
Agent 365: Yönetişimi tenant genelinde birleştirmeyi hedefliyor.

Liderlerin bir sonraki bütçe toplantısında sorması gereken dört soru

Yazıdan tek bir çıktı alınacaksa bu dört soru olmalı. Bugün cevaplayamadığınız her soru, işe başlanacak noktayı gösterir.

Ne için ödediğimizi biliyor muyuz? Harcama model, ajan ve iş akışı bazında görünmeli, tek bir fatura satırında saklı kalmamalı.
Her istek için doğru miktarı mı ödüyoruz? Çoğu istek sınır model gerektirmez. Model router, dağıtım seçenekleri, önbellekleme, fine-tuning ve Foundry IQ, isteği ihtiyaç duyduğu yeteneğe eşler.
Ajanlarımız verimli mi çalışıyor? Ajan maliyetleri iş akışı olgunlaştıkça iyileşmeli. Agent optimizer, bellek yönetimi ve Toolboxes bu noktada devreye girer.
Kullanım sıçradığında sınırlarımız tutuyor mu? Bugün pek çok ekip Azure API Management’ı yapay zeka uç noktalarının önüne koyarak token oranı ve kotaları uyguluyor. Foundry içi yerel bütçeler ve Agent 365 ile tenant çapında kontroller bir sonraki adım olarak konumlandırılıyor.

İlk soru harcamayı anlamakla ilgili; sonraki üçü ise serinin ilerleyen yazılarında ele alınacak alanlar: istekleri doğru modellerle eşlemek, ajan verimliliğini artırmak ve ölçekte maliyeti yönetmek için yönetişim kontrolleri uygulamak.

Değerlendirme

Bence bu yazının en önemli katkısı, “yapay zeka maliyeti = model fiyatı” varsayımını kırması. Ajan tabanlı sistemlerde bir kullanıcı isteğinin arkasında ne kadar araç çağrısı, ne kadar bağlam gönderimi ve ne kadar yeniden deneme olduğunu görmeden bir “birim maliyet” konuşmak zor. Foundry’nin sunduğu üç katmanlı optimizasyon (istek, iş akışı, yönetişim) bu görünmez maliyetleri saydamlaştırmak için mantıklı bir çerçeve oluşturuyor. Öte yandan Foundry içi yerel bütçeler ve ajan/oturum düzeyinde atıf gibi bazı yeteneklerin yol haritasında olduğunu, yani bugünkü uygulamaların hala Azure API Management ve Cost Management kombinasyonuna yaslandığını unutmamak gerekiyor.

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