Long-Running AI Agents İçin Runtime Seçimi: Cloud Function vs. Dedicated Worker

LLM tabanlı bir uygulama geliştirirken ilk refleks genellikle aynıdır: Birkaç satır kod yaz, yerelde çalıştır, sonra bulut mimarisi standartlarına uyup kodu bir serverless fonksiyona at. Basit sohbet botlarından çıkıp otonom AI agents işine girdiğinizde ise seçtiğiniz runtime birdenbire en büyük başağrınıza dönüşebilir.

Kendi kendine web taraması yapan, kod derleyen, hata aldığında strateji değiştiren ve nihai bir rapor hazırlayan ajanınız sunucuya çıktığı anda 504 Gateway Timeout duvarına çarpıyorsa yalnız değilsiniz. Bu yazıda lafı dolandırmadan deneyip ölçeceğiz. Cevaplamaya çalıştığımız soru şu: Uzun süren (long-running) ajan işleri için hafif Cloud Function modelleri mi, yoksa arkada sessizce çalışan Dedicated Worker makineleri mi doğru tercih?

“5 dakikada biter sanmıştım”: serverless neden çuvallıyor?

Geleneksel web mimarisinde sunucusuz fonksiyonlar (AWS Lambda, Google Cloud Run functions vb.) iyi bir fikre dayanır: İstek gelir, kod birkaç yüz milisaniyede çalışır, veritabanına yazar ve yok olur. Boşta bekleme maliyeti sıfırdır, ölçeklenme pürüzsüzdür.

Çok adımlı bir yapay zeka ajanı ise geleneksel bir web isteği gibi davranmaz. Bir ajan döngüsü kabaca şuna benzer:

Düşün -> Tool Seç -> Web Sayfasına Git (Bekle 4sn) -> Sayfayı Oku -> LLM'e Sor (Bekle 12sn) -> Kod Yaz -> Sandbox'ta Çalıştır (Bekle 8sn) -> Hata Aldı, Başa Dön...

CPU burada sürekli tam gaz çalışmaz. Vaktin %80’i dış API çağrılarını ve ağ gecikmelerini beklemekle geçer. Serverless mimari de tam burada üç yerden tıkanır:

• Sert zaman aşımı (hard timeouts): Birçok API gateway 30 saniyede bağlantıyı keser. AWS Lambda en fazla 15 dakika çalışabilir. Kapsamlı bir araştırma yapan ajanın 20 dakika sürmesi işten bile değildir.
• Durumsuzluk (statelessness): Fonksiyon kapandığı an belleğindeki tüm context uçar. Ajanın o anki çalışma belleğini (scratchpad) harici bir Redis’e ya da veritabanına taşımak ciddi bir ek gecikme yaratır.
• Bekleme süresine para ödemek: Serverless servisler genelde tahsis edilen RAM ve geçen milisaniye üzerinden fatura keser. LLM’in token üretmesini boş boş beklerken faturanız tıkır tıkır yazmaya devam eder.

Test senaryosu: derin araştırma ajanı

Konuyu netleştirmek için küçük bir deney kurduk. Ajanımız verilen bir şirket hakkında 10 farklı web sayfasını scrape edecek, sayfaları parseleyip bir LLM’e (GPT-4o) özetletecek, sonuçları birleştirip tek bir analiz raporu üretecek.

Bu ajanı iki farklı ortamda aynı görevle 10’ar kez koşturduk:

1. Kurulum A: AWS Lambda (2 GB RAM, Node.js runtime).
2. Kurulum B: Dedicated Worker (Hetzner üzerinde en ucuz CPX11 VPS + Docker).

Sonuç şöyle oldu. AWS Lambda tarafında 10 denemenin 4’ü ağ gecikmeleri ve API rate limit bekleme süreleri yüzünden 15 dakikalık hard timeout sınırına takılıp çöpe gitti. Çalışan 6 testin ortalama maliyeti, sürekli açık tutulan küçük bir VPS’in günlük masrafının iki katına çıktı. Dedicated Worker ise işleri sırayla, acele etmeden ve kesintisiz biçimde 6-8 dakika aralığında tamamladı.

Karşılaştırma: Cloud Function ve Dedicated Worker

Mesele “çalıştı / çalışmadı” ikiliğinden ibaret değil. Mimari kararlar açısından iki yaklaşımı yan yana koyalım:

Kriter	Cloud Function (Serverless)	Dedicated Worker (VPS / Container)
Maksimum Çalışma Süresi	Kısıtlı (Genelde 15 dk sınır)	Sınırsız (Günlerce sürebilir)
State & Bellek Yönetimi	Zor; her adımda dış DB’ye yazılmalı	Kolay; süreç boyunca RAM’de tutulabilir
Ölçeklenme (Scaling)	Otomatik, sıfırdan binlere anında	Kuyruk (queue) yönetimi ve manuel yapılandırma gerektirir
Maliyet Modeli	Kullanım başına ödeme (Bekleme dahil)	Sabit aylık ödeme
Lokal Araçlar (Browser, Sandbox)	Çok zor (Lambda layer boyut limitleri)	Çok kolay (Playwright, Docker-in-Docker rahatça çalışır)

Hibrit mimari ve workflow motorları

Her agent için büyük sunucular kiralamak zorunda mıyız? Hayır. 2024 ve sonrasında bulut tarafı bu ikilemi çözmek için yeni nesil ara katmanlar geliştirdi.

1. Durable execution motorları (Temporal, Inngest, Trigger.dev)

Bu araçlar ajanın kodunu adım adım (step-by-step) yürütür. Ajan bir web sayfasını beklerken ya da LLM yanıt üretirken süreci durdurur (suspend eder), yanıt gelince kaldığı değişken değerleriyle devam eder. Böylece serverless gibi kaynak tasarrufu yapar, timeout derdinden de kurtulursunuz.

2. Container tabanlı on-demand runtime’lar (Fly.io, Modal)

Modal ya da Fly.io Machines gibi yapılar, ajan tetiklendiğinde bir Docker konteynerini saniyeler içinde ayağa kaldırır. Konteyner 45 dakika boyunca ajanın işini bitirmesini bekler, iş bitince kendini imha eder. Klasik serverless gibi kullanılır ama timeout limitleri saatlerle ölçülür.

Fiyatlar ve ücretsiz alternatifler

Mühendislik kararları sonunda bütçeye bağlanır. Projenizin büyüklüğüne göre maliyet tablosu şöyle şekilleniyor:

• Sıfır bütçe / hobi projeleri:
  • Fly.io: Ücretsiz planda sunduğu kaynaklarla ufak bir worker konteynerini sürekli açık tutabilirsiniz.
  • AWS Lambda Free Tier: Ayda 1 milyon istek ücretsiz. Ancak ajanınız 5 dakikadan uzun sürmüyorsa ve browser otomasyonu gibi ağır kütüphaneler barındırmıyorsa.
• Giriş seviyesi üretim (production):
  • Hetzner Cloud (CPX11/CPX21): Ayda ~4-8 Euro bandında sabit ücret. Arkasına bir BullMQ ya da Celery kuyruğu bağlayarak yüzlerce ajan görevini rahatça yönetirsiniz.
  • Modal: Her ay 30 dolar ücretsiz kullanım kredisi veriyor. GPU ve uzun süren CPU işleri için şu an piyasadaki en pratik ortam.

Hangisini seçmeli: karar ağacı

Yol haritanızı çizmek için şu basit ölçüyü kullanabilirsiniz.

Ajanın yapacağı iş deterministikse, yani 2-3 API çağrısıyla en geç 30 saniyede biteceği belliyse Serverless / Cloud Function tercih edin. Altyapı yönetmekle uğraşmayın.

Ajanın ne zaman duracağı önceden kestirilemiyorsa, kendi kendine internette gezinecekse (Playwright/Puppeteer) ya da lokalde Python kodu çalıştırıp çıktıları analiz edecekse hiç düşünmeden bir Dedicated Worker ya da Workflow Engine (Inngest/Temporal) mimarisine geçin. Timeout hatalarını debug etmekle harcayacağınız saatler, birkaç dolarlık sunucu faturasından çok daha pahalıdır.