Yapay Zekâ İçin Hosting: GPU’lu Sunucu, VPS ve Hibrit Bulut

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

Model, kütüphaneler ve veri setleri seçilirken altyapı ve kapasite planlaması da ele alınmalıdır. Örneğin, yerelde çalışan bir model sunucuda yavaşlayabilir veya GPU belleğine sığmayabilir. Hosting seçimi ve kaynak boyutlandırması bu sorunların olası nedenleri arasındadır; yazılım ortamı ve çalışma ayarları da değerlendirilmelidir.

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 bu prensiplere dayalı pratik mimari seçeneklerini ö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, modelin ve veri setinin ölçeğine bağlı olarak şunlarla karşılaşabilirsiniz:

• Çok uzun süren epoch’lar (saatler hatta günler)
• Yüksek CPU kapasitesi ve özellikle güçlü GPU ihtiyacı; sanal sunucudaki vCPU sayısı ile fiziksel çekirdek sayısı birebir eşdeğer kabul edilmemelidir
• 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 yükler sürekli ve kaynak kullanımı yüksekse GPU’lu dedicated sunucu veya uygun bir veri merkezinde colocation ile kendi GPU sunucunuzu barındırmak değerlendirilebilir. Aylık sabit ücretli bir sözleşme bütçeyi öngörülebilir kılabilir; toplam maliyet hesabında güç, trafik, işletim ve boşta kalma süreleri de hesaba katılmalıdır.

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

Sıfırdan model eğitmek yerine hazır bir modeli kendi verinizle ince ayar yaparak özelleştirebilirsiniz. Ö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ı; model boyutuna, ince ayar yöntemine, veri miktarına ve hedef süreye bağlıdır. Örnek bir küçük iş yükünde tek bir güçlü GPU veya uygun biçimde dağıtılmış çalışmada iki orta seviye GPU yeterli olabilir; bu, genel bir kapasite kuralı değildir. Eğitim süresini de birkaç saat olarak varsaymak yerine temsilî bir iş yüküyle ölçmek gerekir.

Burada GPU’lu dedicated sunucu, toplam kullanım süresi maliyetini haklı çıkarıyorsa değerlendirilebilir. Modeli servis eden API, arayüz veya toplu iş kuyrukları da aynı sunucuda barındırılabilir. Eğitim ve çıkarımın (inference) aynı donanımı paylaşması kullanım oranını artırabilir; ancak CPU, RAM ve VRAM kapasitesi ile gecikme hedefleri korunmalıdır. Eşzamanlı kullanıma kaynak yetmiyorsa işleri farklı zamanlara ayırın veya ayrı kapasite planlayın.

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, uygulamanın gecikme hedefine göre milisaniyeler veya 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ı ya da toplu inference için CPU/GPU seçimi yalnızca isteklerin zamanlamasına değil, modelin hesaplama ve bellek ihtiyacına, istek hacmine ve gecikme hedefine bağlıdır. Hafif modellerde iyi boyutlandırılmış CPU ağırlıklı VPS kümeleri yeterli olabilir; ağır toplu işler de GPU’lu sunucu gerektirebilir. Optimize edilmiş CPU inference seçeneğini hedef yük altında performans ve maliyet açısından karşılaştırabilirsiniz.

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

Altyapı tasarımında GPU’lu dedicated sunucuları, CPU ağırlıklı klasik VPS’leri ve bulut GPU kaynaklarını karşılaştırabilir, bunları hibrit bir yapıda birleştirebilirsiniz. Bunlar birbirini tamamen dışlayan kategoriler değildir: VPS de bulut üzerinde sunulabilir. Buradaki karşılaştırmada ayrılmış GPU donanımını, GPU içermeyen sanal sunucuları ve süreli GPU kullanımı için değerlendirilen bulut kaynaklarını ayırıyoruz.

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

Şu durumlarda GPU’lu dedicated sunucu değerlendirilebilir; ancak bu ölçütler tek başına onu VPS veya buluttan daha uygun kılmaz:

• Her ay düzenli olarak model eğitimi yapıyorsanız
• Model boyutlarınız büyük, VRAM ihtiyacınız örneğin 24 GB ve üzerindeyse; bu değer tek başına dedicated seçimi için bir eşik değildir
• Çok sayıda kullanıcıya gerçek zamanlı inference sağlıyorsanız
• Kurumunuzun belirli bir veri konumu veya donanım ayrımı şartı varsa; bu şartı karşılayan VPS ve bulut seçenekleri de ayrıca değerlendirilmelidir

Dedicated tarafta avantajınız; ayrılmış donanım kaynakları ve daha öngörülebilir performans potansiyelidir. Donanım üzerinde yapabileceğiniz değişiklikler sözleşmeye bağlıdır; uzun vadede daha düşük birim maliyet ise yeterli kullanım oranı gerektirir. 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.

Bakım durumu kontrolü, 4 Kasım 2026: Model sunum yazılımını seçerken model ve donanım uyumluluğunu, erişim kontrollerini ve kullanacağınız sürümün destek durumunu doğrulayın. TorchServe’ün resmi projesi artık aktif bakım yapılmadığını, hata düzeltmesi veya güvenlik yaması planlanmadığını belirtiyor. Bu nedenle onu yeni kurulumlar için bakımı süren varsayılan bir seçenek olarak değerlendirmeyin.

VPS: API katmanı, orkestrasyon ve yan servisler

Tüm mimariyi GPU’lu büyük sunuculara taşımak zorunda değilsiniz. Şu bileşenler genellikle GPU gerektirmez:

• 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, bağımsız ölçekleme ve kaynak ayrımı sağlayabilecek bir seçenektir. Ek sunucu, ağ ve işletim maliyetlerini tek makine seçeneğiyle karşılaştırın. İhtiyaç varsa GPU’lu dedicated sunucunuzu model eğitimi ve inference için çekirdek bir rolde tutup etrafındaki servisleri CPU ağırlıklı VPS’lerde çalıştırabilirsiniz.

Bu ayrım bileşenleri bağımsız ölçeklemeyi kolaylaştırabilir; buna karşılık servisler arası ağ, erişim kontrolü ve izleme yönetimini de planlamak gerekir. Daha geniş bir perspektif için VPS ve bulut barındırmada yeni trendler ve altyapı yenilikleri rehberimizi de inceleyebilirsiniz.

Bulut entegrasyonları ve hibrit senaryolar

GPU kullanımınız kısa süreli veya düzensizse bulut GPU kaynaklarını dedicated sunucuyla karşılaştırabilirsiniz. Seçeceğiniz planda GPU modeli ve VRAM’i, bölgesel bulunabilirliği, kotaları, ücretlendirme süresini, kaynak kapatıldıktan sonra süren depolama ücretlerini ve veri çıkış maliyetlerini doğrulayın. Sürekli yükte ise aynı dönem için toplam maliyeti karşılaştırın; bulut kullanımı otomatik olarak daha ucuz veya sınırsız kapasite anlamına gelmez.

Hibrit bir seçenek, çekirdek veriyi ve kritik sistemleri ana altyapınızda tutup, gerektiğinde ek GPU gücünü kısa süreli bulut kaynaklarıyla tamamlamaktır. Örneğin:

• Modeli ana altyapınızdaki GPU’lu dedicated sunucuda eğitirsiniz.
• Modeli saklar, versiyonlarsınız; çıkarım tarafını yine ana altyapınızda barındırırsınız.
• 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 çıkarım trafiğini ana altyapınızda tutup ek eğitim gücünü süreli olarak dışarıdan alabilirsiniz. Ancak bulutta eğitim, eğitim verilerinin ve model kopyalarının da dış ortamda işlenmesini gerektirebilir; veri üzerindeki kontrol kendiliğinden garanti edilmez. 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, aynı anda bellekte tutulacak veri, batch’ler ve ön işleme çıktıları için marj bırakın; veri setinin tamamının belleğe sığması ancak işleme yöntemi bunu gerektiriyorsa hedeflenmelidir.

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 seçiminde yalnızca “kaç GB VRAM var?” sorusuna bakmak yeterli değildir. Ş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?
• Çoklu GPU kullanımı: Yazılımınız işi GPU’lar arasında nasıl dağıtacak? Ayrı kartların VRAM’i kendiliğinden tek bellek havuzu olmaz; dağıtım yönteminin bellek ihtiyacını ve GPU’lar ile sunucular arası iletişim yükünü kapasite planına katın.

INT8 quantization, model ağırlıklarının bellek ihtiyacını azaltarak daha düşük VRAM’li bir GPU kullanmayı mümkün kılabilir. Ancak toplam VRAM ihtiyacı aynı oranda azalmak zorunda değildir; çalışma belleği ve eşzamanlı istekler de hesaba katılmalıdır. Model kalitesi ve donanım/yazılım desteği de değerlendirilmelidir. Diğer taraftan, gerçek zamanlı bir sohbet botunda büyük batch size ve istekleri toplamak için beklemek gecikmeyi artırabilir. Gecikme hedefi içinde kalan batch size ve kuyruk sınırlarını belirledikten sonra, kapasite yetmiyorsa çoklu GPU veya birden fazla GPU’lu sunucu stratejisini değerlendirebilirsiniz.

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 verileri ise erişim sıklığı ve gecikme hedefine göre sıcak veya ılık katmanda tutulabilir
• Soğuk veri: Arşivlenmiş eski eğitim setleri, log arşivleri, backup’lar

Sıcak veri için, özellikle disk erişiminin darboğaz olduğu işlerde NVMe SSD uygundur. Eğitim sırasında veri okuma ve checkpoint yazma hızları, disk beklemesi oluşuyorsa eğitim süresini ve GPU verimliliğini etkiler. Detaylı karşılaştırmayı NVMe SSD, SATA SSD ve HDD disk karşılaştırması rehberimizde uzun uzun anlattık; AI projelerinde kazanç, veri erişim örüntüsüne ve mevcut darboğaza bağlıdır.

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 verisi: Okuma ve yazma ihtiyacına göre NVMe SSD değerlendirilebilir.
• Model ve checkpoint saklama: Kapasite, erişim hızı ve kullanılan yazılımın erişim yöntemine göre SSD veya object storage seçilebilir.
• Arşiv ve yedekler: Saklama süresi ve geri yükleme hedeflerine uygun HDD veya maliyeti düşük depolama çözümleri değerlendirilebilir.

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, hesaplama katmanı için kullanıcıya yakın bölge seçimini düşünün. CDN, statik içerik ve güvenle önbelleklenebilen yanıtlar için yararlı olabilir; modelin hesaplama süresini ortadan kaldırmaz.
• 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 izleyin. Bunun için htop, iotop, Netdata ve Prometheus ile VPS kaynak kullanımını izleme rehberimizde anlattığımız araç seti, GPU’lu sunucunun CPU, RAM, disk ve ağ tarafını değerlendirirken de yardımcı olabilir. GPU kullanımı, VRAM ve sıcaklık gibi ölçümler için ayrıca donanımla uyumlu GPU izleme araçları veya metrik entegrasyonları planlayın.

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

Üç farklı profil üzerinden mimari seçeneklerine bakalım. Aşağıdaki ekip büyüklükleri, GPU ve sunucu sayıları örnektir; hazır kapasite reçetesi değildir. Modelin belleğe sığmasını, hedef gecikmeyi, eşzamanlı istek sayısını ve arıza durumunda gereken yedek kapasiteyi temsilî yükle değerlendirin.

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ı sunucuyu eğitim ve inference için paylaşma; VRAM ve gecikme bütçesi eşzamanlı kullanıma yetmiyorsa işleri ayrı zamanlarda çalıştırma
• Modele erişen basit bir API ve küçük bir veritabanı aynı makinede

Avantajı: Az bileşenli ve yönetimi görece kolaydır; başlangıç maliyetinin uygunluğu GPU seçimine ve kullanım süresine bağlıdır. Dezavantajı: Eğitim sırasında inference yavaşlayabilir veya kaynak yetersizliğinden çalışamayabilir. 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 (inference için ayrılmış ve optimize edilmiş)
• 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 ayrı bir GPU sunucusunda gerçekleştirme; alternatif olarak aynı GPU’lar paylaşılacaksa inference kapasitesi ve gecikme hedeflerini koruyacak kaynak veya zaman ayrımı yapma

Bu yapıda API katmanı durumsuz tasarlanır ve istekler yük dengeleyiciyle dağıtılırsa yeni VPS’lerle yatay ölçeklenebilir; veritabanı gibi ortak bileşenlerin kapasitesi ayrıca izlenmelidir. GPU tarafında ise gecikme hedefini aşmadan batch size ve kuyruk sınırlarını ayarlar, kapasite yetmediğinde ek GPU’lu sunucu değerlendirirsiniz.

Senaryo 3: Kurumsal ekip, hassas veri ve KVKK gereksinimleri

Durum: Kurumsal bir şirket, müşteri verileri üzerinde model eğitiyor. Veri hassas; bu senaryoda kurumun veriyi yurt içinde tutma şartı olduğunu varsayalım. KVKK/GDPR kapsamındaki yükümlülükler ayrıca değerlendirilmelidir. Aynı zamanda IT ve güvenlik ekipleri sürece aktif olarak dahil.

Önerilen mimari:

• Kurumun konum ve güvenlik şartlarını karşılayan bir 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ı ve object storage için uygun yurt içi konum; yedekler için aynı yerelleştirme şartını karşılayan, üretimden ayrı bir hata alanı
• 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 iş yükünün veri akışları, modelleri ve yedekleri açısından ayrıca değerlendirmek gerekir. Bu senaryodaki yurt içinde tutma şartı, genel bir KVKK/GDPR zorunluluğu olarak okunmamalıdır. Veri setlerinde ve loglarda gereksiz kişisel veriyi azaltın; saklama ve silme sürelerini belirleyin. Anonimleştirme veya takma adlandırma seçeneklerini değerlendirin, ancak bunları birbirine eşdeğer ya da tek başına uyum garantisi saymayın. Modelin hassas bilgi üretme riskini de değerlendirme planına katın.

Güvenlik, yedekleme ve maliyet optimizasyonu

Yapay zekâ projeleri genellikle “deneysel” bir havayla başlıyor ama üretime çıktığında klasik kurumsal uygulamalar gibi işletim disiplini gerektiriyor. Bu noktada üç başlık kritik: güvenlik, yedekleme ve maliyet.

Güvenlik: Model de veri kadar kritiktir

Veriyi korumak kadar modelin erişim güvenliğini de planlamak gerekir:

• İnce ayar yapılmış özel modeliniz, ciddi bir fikri mülkiyet değeri taşıyabilir.
• Model dosyalarına izinsiz erişim, modelin kopyalanmasına ve eğitim verilerinin açığa çıkma riskinin artmasına yol açabilir.
• 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.
• İstemci, API ve model servisleri arasındaki bağlantıları TLS ile koruyun; özel ağ kullanımı şifrelemenin yerine geçmez.
• 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

Yedekleme planını yalnızca veri tabanı ve ham veriyle sınırlamayın. Yapay zekâ projelerinde şu üç grubu kapsayın:

• 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 verinin yanında kaydedilmiş modeli de geri yükleyebilirsiniz. Aynı modeli yeniden eğiterek birebir üretmek ise bu yedeklerle garanti edilmez; yazılım ortamı ve rastlantısallık gibi etkenler de sonucu etkiler. Yedekleri farklı bir hata alanında ve üretimden ayrı erişim yetkileriyle tutmak ek koruma sağlar. Farklı depolama tipi kullanmak tek başına izolasyon değildir; fidye yazılımı ve silme riskine karşı çevrimdışı veya değiştirilemez kopyalar ile geri yükleme kontrolleri planlanmalıdır.

Maliyet optimizasyonu: GPU kullanımını artırın, CPU kaynaklarını esnek planlayın

Altyapı maliyetlerini yönetirken gecikme ve kullanılabilirlik hedeflerini koruyarak GPU’nun boş kaldığı süreleri azaltmayı, CPU kaynaklarını ise yüke göre esnetmeyi hedefleyin. Bunun anlamı:

• Inference hizmetinin çalışma saatleri uygunsa GPU’lu dedicated sunucuyu gece eğitim, gündüz inference için paylaşmak; sürekli hizmette yeterli inference kapasitesini ayırmak.
• 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.

İş yükünün asgari gereksinimlerini karşılayan bir konfigürasyonla başlayıp kaynak kullanımını izleyerek büyümek, kapasiteyi ölçülen ihtiyaca göre planlamaya yardımcı olabilir.

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, CPU ağırlıklı VPS, süreli bulut GPU kaynağı veya hibrit yapı seçeneklerini kullanım süresi, kapasite ve toplam maliyetle karşılaştırın.
3. Yan servislerin yerleşimini seçin: Küçük bir iş yükünde API, veritabanı ve yan servisler aynı makinede kalabilir. Kaynak ihtiyacı, izolasyon veya bağımsız ölçekleme gerektiriyorsa bunları ayrı VPS’lere dağıtmayı değerlendirin.
4. Depolamayı ihtiyaca göre katmanlayın: NVMe, object storage ve arşiv diskini erişim örüntüsü, darboğazlar, kapasite ve geri yükleme hedeflerine göre değerlendirin; her projede üçünün birlikte kullanılması gerekmez.
5. Güvenlik ve yedeklemeyi en baştan planlayın: Sonradan eklemek, mimari değişiklik ve veri taşıma gerektirebilir.

Yapay zekâ projeniz için altyapı seçerken, gereken donanımı ve hizmet kapsamını teklif üzerinde netleştirin. GPU’lu özel sunucu konfigürasyonu, çoklu VPS mimarisi veya colocation değerlendiriyorsanız GPU modeli ve VRAM kapasitesini, ağ bağlantılarını ve donanım yönetimi sorumluluklarını gereksinim listenize ekleyin.

Elinizde hâlihazırda çalışan bir prototip varsa, hedef iş yükünü temsil eden bir deneme ortamında kaynak kullanımını ölçmek, uzun vadeli GPU’lu dedicated veya colocation kararına temel sağlayabilir. VPS üzerinde API ve yan servisleri ölçebilirsiniz; GPU gerektiren modelin kapasite planlaması için hedef GPU konfigürasyonunda da ölçüm yapın. Kararı yalnızca kaynak kullanımına değil, hedef gecikmeye, beklenen trafik artışına ve toplam işletme maliyetine göre verin.