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

Modern bir LLM tabanlı uygulama geliştirirken ilk reflex genellikle aynıdır: Birkaç satır kod yaz, yerelde çalıştır, ardından modern cloud architecture standartlarına uyup kodu bir serverless fonksiyona at. Ancak basit sohbet botlarından çıkıp otonom AI agents dünyasına adım attığınızda, seçtiğiniz runtime ortamı birdenbire en büyük kabusunuz haline gelebilir.

Kendi kendine web taraması yapan, kod derleyen, hata aldığında strateji değiştiren ve nihai bir rapor hazırlayan o harika ajanınız, sunucuya çıktığı anda 504 Gateway Timeout duvarına çarpıyorsa yalnız değilsiniz. Bu yazıda lafı dolandırmadan deneyeceğiz, ölçeceğiz ve şu sorunun cevabını arayacağız: 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.) harika bir felsefeye sahiptir: İstek gelir, kod birkaç yüz milisaniyede çalışır, veritabanına yazar ve yok olur. Sıfır boşta bekleme maliyeti, pürüzsüz ölçeklenme.

Fakat çok adımlı bir yapay zeka ajanı 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...

Burada CPU sürekli tam gaz çalışmaz; vaktin %80’i dış API çağrılarını ve ağ gecikmelerini beklemekle geçer. İşte serverless mimarinin tıkandığı üç kritik nokta:

• 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) Laneti: Fonksiyon kapandığı an belleğindeki tüm context uçar. Ajanın o anki çalışma belleğini (scratchpad) harici bir Redis veya 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.

[Görsel: Cloud Function üzerinde 30. saniyede kesilen API gateway timeout hatası ve agent’ın yarım kalmış düşünce zinciri log ekranı]

Test Senaryosu: Derin Araştırma Ajanı Masada

Konuyu netleştirmek için laboratuvara indik. Basit bir senaryo kurguladık: Ajanımız verilen bir şirket hakkında 10 farklı web sayfasını scrape edecek, sayfaları parseleyip bir LLM’e (GPT-4o) özetletecek ve 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ç: 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ı ikiye katladı. Dedicated Worker ise işleri sırayla, hiç acele etmeden, kesintisiz bir biçimde 6-8 dakika aralığında başarıyla tamamladı.

Karşılaştırma: Cloud Function vs. Dedicated Worker

Mesele sadece “çalıştı / çalışmadı” ikiliği değil. Mimari kararlar bakımından iki yaklaşımın net bir röntgenini çekelim:

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)

Modern Çözüm: Hibrit Mimari ve Workflow Motorları

“Peki her agent için devasa sunucular mı kiralamak zorundayız?” Tabii ki hayır. 2024 ve sonrasında modern bulut dünyası 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 veya LLM yanıt üretirken süreci durdurur (suspend eder). Yanıt geldiğinde kaldığı değişken değerleriyle devam eder. Böylece hem serverless gibi kaynak tasarrufu yaparsınız hem de timeout endişeniz kalmaz.

[Görsel: Trigger.dev panelinde adım adım duraklatılarak (wait for event) ilerleyen bir AI agent akışının zaman çizelgesi]

2. Container-Based On-Demand Runtimes (Fly.io, Modal)

Özellikle Modal veya Fly.io Machines gibi yapılar, bir 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.

Cüzdan Raporu: Fiyatlar ve Ücretsiz Alternatifler

Mühendislik kararları günün sonunda bütçeye bağlanır. Projenizin büyüklüğüne göre maliyet tablosu şu şekilde ş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 veya Celery kuyruğu bağlayarak yüzlerce ajan görevini kafanız rahat 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çmelisiniz? Karar Ağacı

Yol haritanızı çizmek için şu basit formülü kullanabilirsiniz:

Eğer ajanın yapacağı iş deterministik ise, 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.

Ancak ajanın ne zaman duracağı önceden kestirilemiyorsa, kendi kendine internette gezinecekse (Playwright/Puppeteer), lokalde Python kodu çalıştırıp çıktıları analiz edecekse: Hiç düşünmeden bir Dedicated Worker veya 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.