Yapay Zekâ ve Makine Öğrenimi İçin Hosting Rehberi: GPU’lu Sunucu, VPS ve Bulut

Yapay zekâ projelerinde doğru hosting seçimi neden bu kadar kritik?

Yapay zekâ ve makine öğrenimi projelerine giren ekiplerin çoğu, ilk etapta modeli, kütüphaneleri ve veri setlerini konuşuyor; altyapı ise çoğu zaman son dakikaya kalıyor. Sonra da şu cümleyi sık duyuyoruz: “Model yerelde gayet iyi çalışıyordu, sunucuya alınca ya çok yavaşladı ya da GPU belleği yetmedi.” Aslında sorun, çoğunlukla yanlış hosting türü ve eksik kapasite planlaması.

Bu rehberde DCHost ekibi olarak, GPU’lu dedicated sunucu, VPS ve bulut tabanlı mimariler arasında gerçekçi bir karşılaştırma yapacağız. Amaç; “hangi sağlayıcıyı seçmeliyim?” sorusundan çok, “iş yüküme göre nasıl bir altyapı kurmalıyım, hangi bileşeni nereye koymalıyım?” sorusunu netleştirmek.

Eğer tek bir GPU ile prototip geliştiren küçük bir ekipseniz de, onlarca GPU’lu cluster ile kurumsal bir yapay zekâ platformu kurmak istiyorsanız da, aynı temel prensipler geçerli: iş yükünü doğru tanımlamak, kaynakları gerçekçi boyutlandırmak ve büyümeye uygun bir mimari kurmak. Aşağıda, bu prensipleri adım adım ele alacağız ve DCHost tarafında nasıl pratik mimariler kurabileceğinizi örneklerle anlatacağız.

Yapay zekâ iş yüklerini anlamak: Eğitim, ince ayar ve çıkarım

Doğru hosting kararını verebilmek için önce yapay zekâ iş yükünüzün türünü netleştirmeniz gerekiyor. Hepsi “AI” ama altyapı ihtiyacı birbirinden çok farklı.

1. Tam model eğitimi (training)

Sıfırdan model eğitimi, özellikle de derin öğrenme tarafında, en ağır iş yükü türlerinden biri. Büyük dil modelleri (LLM), görüntü işleme ya da konuşma tanıma gibi alanlarda şunlarla karşılaşırsınız:

• Çok uzun süren epoch’lar (saatler hatta günler)
• Yüksek sayıda vCPU ve özellikle güçlü GPU ihtiyacı
• Yüksek hızlı disk erişimi (NVMe SSD gibi) ve geniş depolama alanı
• Sürekli yüksek güç tüketimi ve ısı üretimi

Bu tür bir yükte genellikle GPU’lu dedicated sunucu veya DCHost veri merkezinde colocation ile kendi GPU sunucunuzu barındırmak en mantıklı çözümler arasına girer. Çünkü maliyetleriniz süreklidir, kaynak kullanımı yüksektir ve “dakika başı” yerine “aylık sabit maliyet”le çok daha öngörülebilir bir tablo elde edersiniz.

2. İnce ayar (fine-tuning) ve transfer öğrenme

Bugün birçok ekip sıfırdan model eğitmek yerine hazır bir modeli alıp kendi verisiyle ince ayar yapıyor. Örneğin:

• Orta boyutlu bir dil modelini şirket içi dokümanlara göre ince ayarlamak
• Bir görüntü sınıflandırma modelini kendi ürün fotoğraflarınızla özelleştirmek

Bu senaryolarda GPU ihtiyacı hâlâ yüksek ama çoğu zaman tek bir güçlü GPU veya iki orta seviye GPU yeterli oluyor. Eğitimin süresi, tam eğitim kadar maraton değil; daha çok birkaç saatlik yoğun seanslar gibi düşünebilirsiniz.

Burada GPU’lu dedicated sunucu yine çok mantıklı, fakat GPU’nun boşta kaldığı zamanlarda modeli servis eden bir API, arayüz ya da batching kuyruk sistemleri de aynı sunucu üzerinde barındırılabilir. Böylece hem eğitim hem çıkarım (inference) aynı donanımı paylaşır, maliyeti yayarsınız.

3. Çıkarım (inference): Gerçek zamanlı mı, toplu mu?

Üretimde asıl sürekli çalışan kısım genellikle çıkarım tarafıdır. Burada iki temel senaryo var:

• Gerçek zamanlı inference: Sohbet botu, öneri motoru, gerçek zamanlı görüntü işleme gibi, her isteğe saniyeler içinde cevap vermeniz gereken durumlar.
• Toplu (batch) inference: Gece çalışan raporlar, büyük bir veri setine periyodik olarak model uygulamak gibi, zaman duyarlılığı daha düşük işler.

Gerçek zamanlı inference için genellikle GPU’lu sunucu veya CPU + küçük GPU karışımı gerekirken, toplu inference tarafında iyi boyutlandırılmış CPU ağırlıklı VPS kümeleri bile yeterli olabilir. Özellikle hafif modellerde, optimize edilmiş CPU inference ile GPU maliyetini ciddi şekilde azaltabilirsiniz.

GPU’lu dedicated sunucu, VPS ve bulut: Ne zaman hangisi mantıklı?

DCHost tarafında baktığımızda, üç ana yaklaşım görüyoruz: GPU’lu dedicated sunucular, klasik VPS tabanlı mimariler ve bunların üzerinde kurulan hibrit/bulut entegrasyonları. Her birinin güçlü yanlarını ve sınırlarını netleştirelim.

GPU’lu dedicated sunucu: Yoğun ve öngörülebilir yükler

Şu durumlarda GPU’lu dedicated sunucu neredeyse her zaman daha rasyonel bir seçim:

• Her ay düzenli olarak model eğitimi yapıyorsanız
• Model boyutlarınız büyük, VRAM ihtiyacınız 24 GB ve üzerindeyse
• Çok sayıda kullanıcıya gerçek zamanlı inference sağlıyorsanız
• Uyumluluk, veri gizliliği veya KVKK gereği veriyi ülke içinde ve kontrolünüz altındaki bir altyapıda tutmanız gerekiyorsa

Dedicated tarafta avantajınız; tam donanım kontrolü, daha öngörülebilir performans ve uzun vadede daha düşük birim maliyettir. Dezavantaj tarafında ise ilk kurulum ve kapasite kararlarının daha dikkatli verilmesi gerekir. Yani “fazla almış olayım, dursun” dediğiniz her GPU, boşa yanan elektrik ve boşuna ödenen kira gibi düşünülmelidir.

VPS: API katmanı, orkestrasyon ve yan servisler

Birçok ekip, tüm mimarisini GPU’lu büyük sunuculara taşımaya çalışıyor. Oysa çoğu bileşen GPU’ya dokunmaz bile:

• REST/GraphQL API katmanları
• Kimlik doğrulama, oturum yönetimi, panel/arayüz
• Veritabanı (PostgreSQL, MariaDB vb.)
• Önbellek (Redis, Memcached)
• Log toplama, izleme, kuyruk işçileri

Bu parçalar için VPS tabanlı mimari genellikle çok daha esnek ve ekonomiktir. GPU’lu dedicated sunucunuzu sadece model eğitimi ve inference için çekirdek bir rol olarak tutar, etrafındaki tüm servisleri DCHost üzerinde CPU ağırlıklı VPS’lerde çalıştırırsınız.

Bu yaklaşım; hem ölçeklemeyi kolaylaştırır, hem de altyapıyı parçalara ayırarak yönetilebilir hâle getirir. Bu vizyonu daha geniş perspektifte ele aldığımız VPS ve bulut barındırmada yeni trendler ve altyapı yenilikleri rehberimiz de mimari tasarım aşamasında oldukça işinize yarayacaktır.

Bulut entegrasyonları ve hibrit senaryolar

Her şeyi tek bir veri merkezine kapatmak zorunda değilsiniz. Birçok ekip için makul yol, çekirdek veriyi ve kritik sistemleri DCHost altyapısında tutup, gerektiğinde ek GPU gücünü kısa süreli bulut kaynaklarıyla tamamlamak. Örneğin:

• Modeli DCHost üzerindeki GPU’lu dedicated sunucunuzda eğitirsiniz.
• Modeli saklar, versiyonlarsınız; çıkarım tarafını yine DCHost üzerinde host edersiniz.
• Nadiren ihtiyaç duyulan devasa eğitim kampanyaları için kısa süreli ek GPU’ları bulut tarafında kullanırsınız.

Böylece veri ve kullanıcı trafiği her zaman kontrolünüzde olur; sadece ek eğitim gücünü süreli olarak dışarıdan alırsınız. Kritik nokta; ağ trafiği, veri transfer maliyetleri ve güvenlik politikalarının baştan planlanmasıdır.

Kaynak planlama: vCPU, RAM, GPU, disk ve ağ

Yapay zekâ projelerinde başarının önemli bir kısmı da “doğru kaynakları, doğru miktarda” seçmekten geçiyor. Aşırı güçlü bir sunucu almak bütçenizi yakar, yetersiz kaynak ise ekibi kilitler. Temel bileşenlere tek tek bakalım.

CPU (vCPU) ve RAM: Veri hazırlama ve orkestrasyon

GPU’ya odaklanmak doğal ama sistemin geri kalanı da en az GPU kadar önemlidir. Özellikle:

• Veri ön işleme (feature engineering, veri temizleme)
• İşlem sıraları ve kuyruk işçileri (background worker’lar)
• Web API katmanı
• Veritabanı sunucusu

Bu bileşenler çoğunlukla CPU ve RAM ağırlıklı çalışır. Bu yüzden:

• GPU’lu sunucunuzda makul miktarda CPU/RAM bırakın.
• Yoğun veri işleme yapan kısımları ayrı bir VPS’e dağıtmayı düşünün.
• RAM tarafında, veri setlerinin belleğe rahatça sığacağı (özellikle batch işlemlerde) bir marj bırakın.

Kapasite planlamasına nasıl yaklaşacağınızı merak ediyorsanız, e-ticaret tarafında anlattığımız prensipler yapay zekâ projeleri için de geçerli. Örneğin vCPU, RAM ve IOPS hesaplama mantığını anlattığımız kapasite planlama rehberindeki yaklaşımı burada da uygulayabilirsiniz.

GPU: VRAM, FP16/INT8 ve toplu çıkarım

GPU tarafında çoğu ekip sadece “kaç GB VRAM var?” sorusuna bakıyor. Oysa şunları da düşünmeniz gerekiyor:

• Hassasiyet türü: FP32 mi, FP16 mı, INT8 quantization mı kullanacaksınız?
• Toplu çıkarım (batch size): Aynı anda kaç isteği GPU üzerinde işlemek istiyorsunuz?
• Model sayısı: Aynı GPU üzerinde birden çok modeli paralel çalıştıracak mısınız?

Örneğin, INT8 quantization kullanarak 24 GB VRAM’e ihtiyaç duyan bir modeli 12 GB VRAM’e sığdırmak mümkün olabilir. Bu da daha uygun fiyatlı bir GPU ile aynı işi çözebileceğiniz anlamına gelir. Diğer taraftan, gerçek zamanlı bir sohbet botu için batch size’ı çok büyütmek gecikmeyi artıracağı için VRAM’i değil, çoklu GPU veya birden fazla GPU’lu sunucu stratejisini düşünmeniz gerekebilir.

Disk: NVMe SSD, HDD ve veri katmanları

Yapay zekâ projelerinde disk tarafı üç ana katmana ayrılır:

• Sıcak veri: Model dosyaları, eğitim sırasında kullanılan aktif veri setleri
• Ilık veri: Sık olmasa da düzenli erişilen veri setleri, feature store benzeri yapılar
• Soğuk veri: Arşivlenmiş eski eğitim setleri, log arşivleri, backup’lar

Sıcak veri için neredeyse her zaman NVMe SSD öneriyoruz. Çünkü eğitim sırasında okuma/yazma performansı doğrudan eğitim süresine ve GPU verimliliğine yansıyor. Detaylı karşılaştırmayı NVMe SSD, SATA SSD ve HDD disk karşılaştırması rehberimizde uzun uzun anlattık; AI projelerinde bu fark daha da belirginleşiyor.

Ilık ve soğuk veri tarafında ise daha büyük ama görece daha yavaş diskler, hatta harici depolama çözümleri gündeme gelir. Özellikle çok büyük veri setleri için Object Storage, Block Storage ve File Storage arasındaki farkları anlattığımız rehberdeki prensipler doğrudan uygulanabilir. Özetle:

• Aktif eğitim datası: NVMe SSD
• Model ve checkpoint saklama: SSD veya hızlı object storage
• Arşiv ve yedekler: HDD veya maliyeti düşük depolama çözümleri

Ağ (network): Veri transferi, bulut entegrasyonu ve latency

Yapay zekâ projelerinde çoğu zaman veri, farklı sistemler arasında sürekli hareket eder: veri tabanından feature store’a, oradan eğitim cluster’ına, sonra inference API’sine. Bu zincirde ağın rolü çok büyüktür:

• Veri merkezine veri taşıyorsanız, bant genişliği ve kota sınırlarını iyi hesaplayın.
• Inference API’niz küresel kullanıcıya hitap ediyorsa, gecikmeyi azaltmak için CDN ve yakın bölge seçimi düşünün.
• Bulut entegrasyonu varsa, veri çıkış maliyetlerini (egress) göz ardı etmeyin.

Özellikle yoğun eğitim dönemlerinde ağ ve disk kullanımını yakından izlemeniz gerekiyor. Bunun için htop, iotop, Netdata ve Prometheus ile VPS kaynak kullanımını izleme rehberimizde anlattığımız araç seti, GPU’lu sunucuların performansını takip ederken de işinizi kolaylaştırır.

Farklı ölçekler için örnek mimariler

Teoride her şey güzel ama pratiğe dökerken “bizim senaryoda nasıl olur?” sorusu geliyor. Gelin üç farklı profil üzerinden konuşalım.

Senaryo 1: Tek GPU ile başlayan küçük ekip

Durum: 3–4 kişilik bir ekip, orta boyutlu bir dil modeliyle Türkçe metin sınıflandırma veya soru-cevap sistemi geliştiriyor. Önce prototip, sonra sınırlı sayıda müşteriye pilot kullanım hedefleniyor.

Önerilen mimari:

• 1 adet GPU’lu dedicated sunucu (örneğin 1 güçlü GPU, yeterli VRAM, NVMe disk)
• Aynı sunucuda eğitim + inference birlikte; eğitim dışı zamanlarda GPU’yu inference’a ayırma
• Modele erişen basit bir API ve küçük bir veritabanı aynı makinede

Avantajı: Basit, yönetimi kolay, başlangıç maliyeti makul. Dezavantajı: Eğitim sırasında inference performansı düşebilir. Bunu hafifletmek için yoğun eğitim dönemlerinde pilot kullanımı azaltmak veya eğitimleri gece saatlerine kaydırmak gibi operasyonel çözümler kullanılabilir.

Senaryo 2: SaaS olarak AI API sunan ürün

Durum: Farklı müşterilere model üzerinden API sunan bir SaaS ürünü. Gün içinde değişken ama genel olarak sürekli bir trafik var. Müşterileriniz gecikmeye duyarlı.

Önerilen mimari:

• 1–2 adet GPU’lu dedicated sunucu (sadece inference için optimize)
• API, kimlik doğrulama, panel, billing vb. için 2–3 adet CPU ağırlıklı VPS
• Ayrı bir veritabanı VPS’i (PostgreSQL/MariaDB) ve Redis gibi bir önbellek
• Model eğitimini, trafiğin az olduğu dönemlerde aynı GPU’larda ya da ayrı bir GPU sunucusunda gerçekleştirme

Bu yapıda CPU VPS’leri yatayda ölçeklemek kolaydır; trafik arttıkça yeni VPS ekleyip API katmanını genişletebilirsiniz. GPU tarafında ise önce batch size ve kuyruk mimarisiyle verimi artırır, yetmediğinde ek GPU’lu sunucu eklersiniz.

Senaryo 3: Kurumsal ekip, hassas veri ve KVKK gereksinimleri

Durum: Kurumsal bir şirket, müşteri verileri üzerinde model eğitiyor. Veri hassas, yurt dışına çıkmamalı, sıkı KVKK/GDPR kuralları var. Aynı zamanda IT ve güvenlik ekipleri sürece aktif olarak dahil.

Önerilen mimari:

• DCHost veri merkezinde colocation veya GPU’lu dedicated sunucu kümesi
• Ayrı bir yönetim ağı ve VPN ile erişim; ofis–veri merkezi arası güvenli tünel
• Veri tabanı, object storage ve yedekleme sistemleri yine aynı veri merkezinde
• Gerekirse staging/test ortamı için ilave VPS’ler

Bu tür yapılarda sadece teknik değil, hukuki gereklilikler de devreye girdiği için KVKK ve GDPR uyumlu hosting seçimi rehberimizde anlattığımız veri yerelleştirme, loglama ve silme politikalarını AI tarafına da birebir uygulamak gerekir.

Güvenlik, yedekleme ve maliyet optimizasyonu

Yapay zekâ projeleri genellikle “deneysel” bir havayla başlıyor ama üretime çıktığında klasik bir kurumsal uygulamadan farksız hâle geliyor. Bu noktada üç başlık kritik: güvenlik, yedekleme ve maliyet.

Güvenlik: Model de veri kadar kritiktir

Birçok ekip veriyi korumaya odaklanırken modeli unutuyor. Oysa:

• İnce ayar yapılmış özel modeliniz, ciddi bir fikri mülkiyet değerine sahiptir.
• Model dosyalarına izinsiz erişim, sadece veri sızıntısı değil, ürününüzün kopyalanması anlamına gelir.
• Inference API’niz DDoS veya kötü niyetli isteklerle kötüye kullanılabilir.

Bu yüzden:

• Sunuculara erişimi VPN ve SSH anahtarlarıyla sınırlandırın.
• API’lerinizde oran sınırlama (rate limiting) ve WAF kullanın.
• Model ve veri dosyalarınızı, erişim kontrol listeleri (ACL) ve şifreleme ile koruyun.

Yedekleme: Sadece veriyi değil, modeli de yedekleyin

Yedek konuşulurken herkes veri tabanını ve ham veriyi düşünüyor. Oysa yapay zekâ projelerinde şu üçlü mutlaka yedeklenmeli:

• Ham veri ve işlenmiş veri setleri
• Eğitim script’leri, konfigürasyonlar, hiperparametreler
• Model checkpoint’leri ve final modeller

Bu sayede, bir sorun olduğunda sadece veriyi geri döndürmekle kalmaz, aynı modeli yeniden üretebilir hâlde olursunuz. Yedekleri, üretimden fiziksel ve mantıksal olarak ayrılmış bir konumda tutmak (farklı veri merkezi, farklı depolama tipi vb.) fidye yazılımı ve kullanıcı hatalarına karşı ek güvenlik katmanı sağlar.

Maliyet optimizasyonu: GPU’yu doldurun, CPU’yu bölün

Altyapı maliyetlerini düşürmenin en net kurallarından biri şudur: GPU’ları olabildiğince dolu, CPU’ları ise olabildiğince esnek kullanın. Bunun anlamı:

• GPU’lu dedicated sunucunuzu gece eğitim, gündüz inference için kullanarak boş zaman bırakmamak.
• API ve yan servisleri küçük–orta boy VPS’lere bölerek trafiğe göre esnetmek.
• Disk tarafında sıcak–ılık–soğuk veri katmanlaması yaparak NVMe’yi gerçekten ihtiyaç duyulan yerde kullanmak.

Başlangıçta daha mütevazı bir konfigürasyonla başlayıp, DCHost üzerinde kaynak kullanımını izleyerek adım adım büyümek, çoğu ekibin orta–uzun vadede en sağlıklı yolu oluyor.

DCHost ile pratik yol haritası

Toparlayalım. Yapay zekâ ve makine öğrenimi projeleri için hosting seçerken şu sırayı izleyebilirsiniz:

1. İş yükünü tanımlayın: Eğitim mi ağır, inference mı? Gerçek zamanlı mı, batch mi?
2. Çekirdek bileşeni belirleyin: GPU’lu dedicated sunucu mu, CPU ağırlıklı VPS mi, yoksa hibrit bir yapı mı?
3. Çevresini VPS’lerle örün: API, veritabanı, önbellek, log, izleme gibi bileşenleri uygun sayıda VPS’e dağıtın.
4. Depolama stratejisi kurun: NVMe + object storage + arşiv diski kombinasyonunu netleştirin.
5. Güvenlik ve yedeklemeyi en baştan planlayın: Sonradan yamamaya çalışmak her zaman daha pahalıdır.

DCHost ekibi olarak; domain, hosting, VPS, dedicated sunucu ve colocation hizmetlerimizi, yapay zekâ projelerinin ihtiyaçlarını da düşünerek sürekli güncelliyoruz. Proje aşamanız ne olursa olsun, GPU’lu özel sunucu konfigürasyonları, çoklu VPS mimarileri ve veri merkezi tarafındaki gereksinimleriniz için sizinle teknik bir mimari tasarım oturumu yapmaktan memnuniyet duyarız.

Elinizde hâlihazırda çalışan bir prototip varsa, birkaç günlük test için bir VPS veya deneme ortamı ile başlayıp kaynak kullanımını ölçmek, ardından uzun vadeli GPU’lu dedicated veya colocation kararını vermek genellikle en sağlıklı yaklaşım oluyor. Altyapınızı birlikte tasarlayalım; siz modeli ve veriyi konuşmaya devam edin, biz de arka planda bu yapının sağlam, ölçeklenebilir ve maliyet açısından sürdürülebilir kalmasını sağlayalım.