AI Agent Hosting: Yapay Zeka Ajanlarınızı Kendi Sunucunuzda Çalıştırın

Üretimde çalışan bir AI agent genellikle tek bir uygulamadan oluşmaz. İstekleri alan agent katmanı, karar veren LLM, dış sistemlere erişen araçlar veya MCP sunucuları, oturum ve görev durumunu tutan veri katmanı, RAG için vektör veritabanı ve bütün bu servisleri dış dünyaya güvenli biçimde açan proxy katmanı birlikte çalışır.

Bu nedenle sunucu seçimini yalnız model adına göre yapmak yerine tüm akışı değerlendirmek gerekir. Örneğin model bir bulut API üzerinde çalışırken n8n, PostgreSQL ve Qdrant yerel sunucuda kalabilir; başka bir projede ise Ollama veya vLLM ile model de aynı altyapıya alınabilir.

Agent altyapısı yalnız chatbot barındırmak için değildir. Tekrarlanan işleri araç kullanarak tamamlayan otomasyonlar, şirket verisinden cevap üreten RAG sistemleri, CRM ve ERP entegrasyonları, e-posta veya ticket işleyen ajanlar, raporlama servisleri ve özel API tabanlı asistanlar aynı temel mimariden yararlanabilir.

Doğru mimari kullanım senaryosuna göre değişir. Basit bir webhook agentı küçük bir VPS üzerinde çalışabilirken yerel LLM, yüksek eş zamanlılık veya görsel üretim içeren bir sistem GPU ve daha yüksek bellek gerektirebilir.

Agent katmanının kendisi çoğu projede GPU istemez. n8n, MCP server, PostgreSQL, Redis ve API servisleri CPU üzerinde çalışabilir. GPU ihtiyacı çoğunlukla yerel LLM inference, embedding üretimi, görüntü veya video modeli gibi hesaplama yoğun bileşenler aynı altyapıda çalıştırıldığında ortaya çıkar.

RAM ihtiyacı yalnız agent uygulamasına göre değil; aynı anda çalışan workflow sayısı, veritabanı cache'i, vektör indeksleri, model boyutu ve container sayısına göre değerlendirilmelidir. Aşağıdaki tablo başlangıç sınıflarını anlatır; gerçek seçim iş yükü testiyle yapılmalıdır.

Hayır. Agentın kullandığı model OpenAI, Gemini, Claude veya başka bir harici API üzerinde çalışıyorsa sunucu ağırlıklı olarak orkestrasyon, API, veritabanı ve entegrasyon yükünü taşır. Bu senaryoda güçlü CPU, yeterli RAM ve hızlı NVMe çoğu zaman GPU'dan daha önemlidir.

Modeli kendi sunucunuzda çalıştırmak istediğinizde durum değişir. Ollama veya benzeri bir inference servisi CPU üzerinde de çalışabilir fakat model boyutu ve hedef hız büyüdükçe GPU önemli hale gelir. Burada GPU modelinden önce VRAM kapasitesi, model formatı, context ve aynı anda kaç istek çalışacağı hesaplanmalıdır.

Docker, reverse proxy, PostgreSQL, Redis, Qdrant, Python ve Node.js ağırlıklı agent sistemlerinde Ubuntu gibi Linux dağıtımları genellikle daha doğal bir üretim ortamı sunar. Container tabanlı servis yönetimi ve otomasyon araçları bu yapıda kolayca bir araya getirilebilir.

Windows Server; RDP gerektiren masaüstü uygulamaları, Windows'a bağımlı kurumsal yazılımlar veya mevcut iş akışınızın Windows servisleriyle sıkı bağlı olduğu projelerde anlamlı olabilir. n8n ve Ollama gibi bileşenler Windows üzerinde de kullanılabilir; seçim ekosistem ve operasyon ihtiyacına göre yapılmalıdır.

MCP, AI uygulamalarının araçlara ve veri kaynaklarına standart bir protokol üzerinden bağlanmasını sağlar. Remote MCP sunucusu internette veya özel ağda çalışan bağımsız bir servis olabilir; agent bu servis üzerinden belirli araçları keşfedebilir ve çağırabilir.

2026-07-28 MCP spesifikasyonunda ölçeklenebilir sunucu dağıtımlarını kolaylaştıran stateless protokol çekirdeği öne çıkıyor. Bu, MCP servislerini reverse proxy, load balancer ve birden fazla instance arkasında çalıştırmayı daha doğal hale getiriyor. Üretimde yine kimlik doğrulama, yetkilendirme, TLS, loglama ve tool kapsamı ayrı ayrı tasarlanmalıdır.

Aşağıdaki komutlar tek bir ürünü zorunlu kılmaz; tipik bir Linux agent sunucusunda Docker, Compose ve servis durumunu doğrulamak için kullanılabilecek başlangıç kontrolleridir. Üretim ortamında image sürümlerini sabitlemek, secrets yönetmek ve volume yedeklerini planlamak gerekir.

n8n, PostgreSQL, Redis, Qdrant ve özel MCP servisleri aynı Compose projesinde veya ayrı projelerde çalıştırılabilir. Dış dünyaya yalnız gerekli web giriş noktalarını açıp veritabanı ve vektör servisini private Docker ağı içinde tutmak daha kontrollü bir temeldir.

AI agentlar klasik web uygulamalarından daha geniş yetkilere sahip olabilir; dosya okuyabilir, API çağırabilir, kayıt oluşturabilir veya üçüncü taraf sistemlerde işlem yapabilir. Bu nedenle secrets, tool yetkileri ve ağ erişimi doğrudan güvenlik sınırı kabul edilmelidir.

Ollama'nın yerel API'si varsayılan yerel kullanımda ayrıca kimlik doğrulama istemez. Bu tür servisleri doğrudan public internete açmak yerine private bind, reverse proxy, VPN veya erişim kontrol katmanı kullanmak gerekir. Qdrant gibi veri servislerinde de API key, TLS ve ağ kısıtları üretim planına dahil edilmelidir.

Agent sistemi ilk testte cevap veriyor diye üretime hazır sayılmaz. Container restart politikaları, servis health check'leri, disk kullanımı, CPU/RAM trendleri, model gecikmesi, workflow hata oranı ve veritabanı yedekleri düzenli izlenmelidir.

Trafik büyüdüğünde her bileşeni aynı şekilde ölçeklemek zorunda değilsiniz. Agent API instance'ları yatay çoğaltılırken PostgreSQL ayrı sunucuya taşınabilir, Qdrant daha yüksek disk/RAM kaynağı alabilir veya yerel LLM için bağımsız GPU node kullanılabilir. Bu ayrıştırma maliyeti ve arıza alanını daha kontrollü yönetir.

Donanımı gereğinden fazla büyütmeden doğru başlangıç yapmak için projenin kullandığı model, agent framework'ü, veri katmanı ve tahmini trafik birlikte değerlendirilmelidir. Özellikle yerel model kullanılacaksa modelin tam adı ve quantization bilgisi kapasite planını doğrudan etkiler.

Teknik ekibe aşağıdaki bilgileri iletmeniz, VPS mi VDS mi yoksa GPU sunucu mu gerektiğini daha hızlı netleştirmemizi sağlar.