Ajan Maliyetini Düşürmenin Dört Yolu: Runtime Optimizasyonu

⏱️ 7 dk okuma📅 30 Ağustos 2026

Bir yapay zeka ajanı, aslında bir modelin etrafında dönen bir döngüdür: planlar, araç çağırır, sonucu okur, yeniden akıl yürütür. Bu yüzden tamamlanmış tek bir iş çıktısının ardında düzinelerce model isteği olabilir. İşletme için gerçek metrik de tokenin fiyatı değil, başarılı bir sonucun toplam maliyetidir. Microsoft Foundry ekibi, “The Economics of Agent Optimization” serisinin ikinci yazısında bu maliyeti runtime seviyesinde düşüren dört kaldıracı ele alıyor. Aşağıda kaynağın öne çıkardığı yaklaşımlar özetleniyor.

Prototip alışkanlığının üretimdeki bedeli

Çoğu yapay zeka uygulaması benzer biçimde başlar: en güçlü model seçilir, modelin ihtiyaç duyabileceği her şey prompt’a konur ve fikir doğrulanır. Prototip için doğru olan bu refleks, sessizce üretim mimarisine dönüştüğünde iki problem su yüzüne çıkar.

Birincisi, yapay zeka iş yükleri homojen değildir. Tek bir uygulama; niyet sınıflandırma, veri çıkarımı, biçimlendirme, özetleme ve gerçek anlamda çok adımlı akıl yürütme gerektiren istekleri bir arada barındırır. Bunların hepsini aynı sınır (frontier) modele yönlendirmek, o kapasiteye ihtiyaç duymayan çoğunluk için fazla ödemek demektir.

İkincisi, tek bir sonuç birçok istekten oluşur. Prototip tek bir çağrının bedelini öderken ajan tüm döngünün bedelini öder; israf da hatalar da çarpanla büyür. Yanlış araca sapan bir ajan, telafi için ek turlar harcar ve genellikle daha zayıf bir yanıtla sonuçlanır. Sonuç maliyeti, her turdaki tokenler kadar kaçındığınız turlar tarafından da belirlenir.

Runtime’da kontrol ettiğiniz dört kaldıraç

Microsoft Foundry, bu dengeleri prototipin tesadüfi tercihlerine bırakmak yerine bilinçli kurmanız için dört kaldıraç sunuyor. Her biri tek başına uygulanabilir, kalite eşiğinize göre ölçülebilir, tradeoff işe yaramazsa geri alınabilir.

1. Her isteği doğru modele yönlendirin

Temel ilke basit: sonucu görevin karmaşıklığına göre optimize edin. Rutin istekler sınır model ekonomisi ödemek zorunda değildir; karmaşık istekler de token tasarrufu için kaliteden feragat etmemelidir.

Foundry Models içindeki model router, gelen her isteği değerlendirip tek bir uç nokta ve tek bir dağıtımın arkasında en uygun alt modele gerçek zamanlı olarak yönlendirir. Yönlendirme modları maliyeti, kaliteyi veya ikisinin dengesini önceliklendirmenize izin verir. Model alt kümeleri artık Azure Policy ile hizalanabiliyor; uyumluluk sınırınızın gerektirdiği onaylı bir izin listesine yönlendirmeyi kısıtlayabilirsiniz. Yerleşik yük devretme, bir model kullanılamadığında isteği bir sonraki en iyi modele taşır; böylece yönlendirme aynı zamanda dayanıklılık kazandırır.

Aynı istek, nasıl dağıtıldığına bağlı olarak çok farklı ekonomilere sahip olabilir. Kuruluşların karar vermesi gereken üç konu var: verinin nerede işleneceği (Global, Data Zone veya Regional), kapasitenin nasıl satın alınacağı (token başına ödeme, sağlanan kapasite) ve hangi iş yüklerinin gerçekten etkileşimli yanıt gerektirdiği.

Foundry’nin sunduğu dağıtım seçenekleri bu tercihlerin iş gereksinimleriyle örtüşmesine izin veriyor:

Çoğu iş yükü, esneklik ve kullandıkça öde fiyatlaması sunan standart dağıtımlarla başlayabilir.
Daha hızlı ve tutarlı yanıt süresi bekleyen etkileşimli uygulamalar öncelikli işlemden faydalanabilir.
Tahmin edilebilir talebi olan yüksek hacimli iş yükleri, Provisioned Throughput Units (PTU) ile daha iyi bir ekonomi elde edebilir; taşan trafik kullandıkça öde kapasitesine yönlendirilebilir.
Belge işleme, sınıflandırma ve değerlendirme çalışmaları gibi büyük asenkron iş yükleri için Batch dağıtımlar, anlık yanıt gerektirmeyen işlerde kaynağa göre yüzde 50’ye varan maliyet düşüşü sağlar.

Tek bir uygulama içinde bile farklı deneyimlerin farklı stratejilerden yararlanabileceğini unutmayın: geliştiriciye dönük araçlar Standard üzerinde, etkileşimli sohbet öncelikli işlemede, sürekli throughput ihtiyacı olan ajanik uygulamalar PTU üzerinde çalışabilir; belge analizi gibi arka plan görevleri son kullanıcıyı etkilemeden Batch’e taşınabilir.

Fine-tuning, bu kaldıracın ileri düzey versiyonudur. Yönlendirme mevcut modeller arasından seçim yaparken fine-tuning, daha küçük bir modelin ne yapabileceğini değiştirir; ona görevinizi, tonunuzu veya biçiminizi büyük bir modelle yarışacak kadar iyi öğretir. Kazanç, daha düşük birim ücret ve daha kısa prompt’lardır. Davranış oturmuşsa ve hacim eforu geri kazanacak kadar yüksekse bu kaldıracı düşünün.

2. Aynı tokenları iki kez ödemeyin

Ajanlar önbelleğe son derece uygun yapılardır. Aynı sistem talimatları, araç şemaları ve politika metinleri her turda yeniden gönderilir; 10 tür süren bir ajan bu ön eki 10 kez öder.

Prompt caching, önceden işlenmiş bir ön ekin yeniden işlenmek yerine tekrar kullanılmasını sağlar. Standart dağıtımlarda önbellek okumaları normal giriş fiyatına göre indirimli faturalanır; provisioned dağıtımlarda indirim yüzde 100’e kadar çıkabilir. Maliyetle birlikte gecikme de iyileşir.

Değer üretmek büyük ölçüde prompt mimarisiyle ilgilidir. Kural açık: kararlı içerik önce, değişken içerik sonra. Sistem talimatları, araç tanımları ve few-shot örnekleri en üste; kullanıcı girişi, getirilen (retrieval) parçalar ve tür geçmişi en alta. Önbellek prompt’un başındaki birebir eşleşmeye bağlı olduğundan zaman damgası veya kullanıcı adı gibi istek başına değişen her şey bu bloğun altında kalmalıdır. Yukarıya koyarsanız eşleşme hiç oluşmaz.

Önbellekleme prompt seviyesinin üzerinde de işler. Foundry çıkarım API’lerinin önüne bir ağ geçidi koyduğunuzda Azure API Management içindeki AI Gateway gibi semantik önbellek farkındalığı olan bir seçenek önemlidir. Bu ağ geçidi aynı uç noktalara oturum yakınlığını koruyarak önbellek etkinliğini artırır ve oturumlar ile kullanıcılar arasında yakın-tekrar isteklerini eşleştirebilir. Deterministik araç sonuçları ise verinin değişim sıklığına göre ayarlanmış bir TTL ile kendi deponuzda önbelleğe alınabilir.

3. Önce prompt’u, sonra ajanı optimize edin

Model seçimi birim ücreti belirliyorsa, talimat da hacmi belirler. Üstelik altyapıya dokunmadan gönderildiği için düzeltilmesi en ucuz katman budur. Token azaltan pratikler yanıtları da iyileştirir: görevi bir yığın bağlamın ardına gömmek yerine önce yazın, çıktının nasıl ve ne uzunlukta olacağına dair net olun, paragraflarca açıklama yerine iyi seçilmiş birkaç örnek kullanın. Ardından turlar boyunca biriken içeriği kontrol altında tutun:

Tamamlanmış konuşmaları tam transkript yerine özetleyerek taşıyın.
Araç tanımlarını yalnızca ilgili göreve uygun araçlarla sınırlayın.
Çalışan durumu (working state) dış hafızada saklayın ve yalnızca ihtiyaç oldukça çekin.

Foundry, bir zamanlar elle yapılan bu ayarları artık otomatikleştiriyor. Prompt optimizer, prompt mühendisliği en iyi pratiklerini uygulayarak bir ajanın sistem talimatlarını yeniden yazar ve her değişiklik için gerekçesini gösterir; siz de yönlendirip yeniden çalıştırıp sonucu tek tıkla uygulayabilirsiniz.

Foundry Agent Service içindeki agent optimizer döngüyü kapatarak bir adım öteye gider. Ajanınızı gerçek görevlerden oluşan bir veri kümesine karşı çalıştırır, aday konfigürasyonlar üretir, her birini puanlar ve sıralar; siz de kazananı yayına alırsınız. Talimatları, becerileri (skills), araç tanımlarını ve model seçimini değiştirebilir; veri kümesi kendi ajan izlerinizden (traces) gelebilir.

4. Gözlemlenebilirlik ve değerlendirme ile görünür kılın

Göremediğinizi ayarlayamaz, ölçmediğiniz tasarrufu iddia edemezsiniz. Foundry’nin gözlemlenebilirlik yetenekleri diğer üç kaldıracı güvenle çekmenizi sağlayan istek başı sinyalleri sağlar: giriş ve çıkış tokenleri, önbellek isabet oranı, gecikme, isteği gerçekte hangi modelin karşıladığı ve kalitenin korunup korunmadığını gösteren değerlendirme skorları.

Burada iki sayı önemlidir. İstek başına maliyet, ucuz yolun hala eşiği geçip geçmediğini gösterir. Tamamlanmış sonuç başına maliyet ise iş birimine gerçekte ne ödediğinizi, oraya varmak için gereken tüm turlar ve yeniden denemeler dahil söyler. Birinciyi düşürüp tür sayısını artıran bir optimizasyon durumu kötüleştirmiştir; bunu ancak ikinci sayı gösterir.

Değerlendirme, bu görünürlüğü değişiklik yapma iznine dönüştürür. Maliyet, gecikme ve görev başarısını birlikte ölçün, her optimizasyonun yayına çıkmadan önce geçmesi gereken sabit bir değerlendirme kümesi tutun. Aynı izler ve değerlendirme kümeleri agent optimizer tarafından da tüketildiği için emek iki kez getiri sağlar. Azure tarafındaki bütçeler, uyarılar ve maliyet etiketleme ile eşleştirdiğinizde regresyonlar ay sonu sürprizi olarak değil bildirim olarak gelir.

Tek seferlik tasarruf değil, bir yokuş tırmanışı

Bu kaldıraçların hiçbiri tek seferlik bir kazanım değildir. Birlikte, her turda hem daha ucuz hem daha iyi hale gelen bir döngü oluştururlar. Microsoft AI ekibinin “hill-climbing machine” ifadesiyle kastettiği tam olarak bu: daha iyi veri ve daha keskin değerlendirmeyle döngü döngü ilerleme.

Model ve dağıtım her isteğin nerede çalıştığını belirler; fine-tuning ise ispatlanmış bir görevi kalıcı olarak daha ucuz hale getirir.
Önbellek her döngünün maliyetini düşürür; bu da döngüyü anlamlı bir sıklıkta çevirmenizi mümkün kılar.
Prompt ve ajan optimizasyonu bir sonraki adayı üretir ve değerlendirme kümenize karşı doğrular.
Gözlemlenebilirlik ve değerlendirme nerede olduğunuzu ve son değişikliğin tuttuğunu söyler.

Döngünün sabit bir başlangıcı yoktur ama çoğu ekip ölçümden girer. İzler değerlendirme veri kümelerine dönüşür, o veri kümeleri optimizer’ı besler, optimizer sonuçları hangi görevlerin fine-tuning için yeterince kararlı olduğunu gösterir. Fine-tune edilmiş modeller router’ın seçimini değiştirir, yeni yönlendirme yeni izler üretir.

Kaynaklar ve İleri Okuma

learn.microsoft.com

İç okuma önerileri:

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