Stable Diffusion API için sunucu seçimi: VDS mi, Dedicated mi?

Stable Diffusion tabanlı bir uygulamada kullanıcı isteği geldiğinde (prompt + parametre) modelin üretim süresi kadar, isteklerin sıraya girme etkisi ve görsellerin teslimi de deneyimi belirler. Bu yazıda Stable Diffusion API host etmek için hangi sunucu tipinin doğru olduğuna; GPU modeli, CPU/RAM dengesi, disk ve ağ planlamasıyla karar vermenize yardımcı olacak net bir çerçeve sunuyorum. Ayrıca tipik senaryolar için hedef gecikme, kapasite ve maliyet dağılımını nasıl hesaplayacağınızı adım adım anlatıyorum.

Stable Diffusion API’de asıl darboğaz GPU’dur

Stable Diffusion (özellikle SDXL ve daha yeni varyantlar) tek başına “genel amaçlı” bir hesaplama işi değildir. Üretim (inference) GPU’da çalışır; aynı anda kaç istek işleyebileceğiniz doğrudan GPU belleği (VRAM) ve üretim süresine bağlıdır.

API tarafında (HTTP endpoint, kuyruk yönetimi, dosya saklama) CPU ve RAM kritik rol oynar; ancak görüntünün gerçek üretimi GPU kaynaklarını kullanır. Bu yüzden sunucu seçimi yaparken önce “kaç eşzamanlı job” hedeflediğinizi netleştirmeniz gerekir.

Eşzamanlı istek kapasitesi nasıl tahmin edilir?

Tek bir GPU üzerinde aynı anda kaç job çalıştırabileceğiniz, çoğunlukla şu üç şeye bağlıdır: - VRAM kapasitesi (GB): Model + batch + çözünürlük + istemci parametreleri VRAM’i tüketir. - Her job’ın ortalama üretim süresi: Prompt karmaşıklığı değil, ağırlıklar ve ayarlar daha çok etkiler. - Kuyruk/worker tasarımı: İşleri sıraya alıp tek tek GPU’ya vermek mi, yoksa paralel çalışan worker sayısını artırmak mı kullanıyorsunuz.

Pratik yaklaşım: Önce tek işin ortalama süresini ölçün, sonra hedef kullanıcı eşzamanlılığını kuyruk sistemiyle eşleştirin.

Aşağıdaki tabloda tipik hedefler için “yaklaşık” planlama veriyorum (gerçek değerler modele, çözünürlüğe ve ayarlara göre değişir):

Senaryo	Tipik hedef (P95)	Yaklaşım	Beklenen GPU ihtiyacı
Dahili test / düşük trafik	3-8 sn	Tek worker, sırayla iş	1x küçük GPU (8–12 GB VRAM)
Küçük müşteri API (günde yüzlerce istek)	8-15 sn	1–2 worker, kuyruk toleransı	1x orta GPU (12–16 GB VRAM)
Ticari kullanım (dakikada onlarca istek)	10-25 sn	Worker ölçekleme + kuyruk	1x güçlü GPU (16–24+ GB VRAM) veya ölçekleme
Pik dönemler (kampanya)	15-40 sn	Otomatik ölçek + kuyruk	Çoklu GPU veya kademeli kapasite

VDS ile Dedicated arasındaki fark: esneklik vs. garanti

Stable Diffusion API’yi host etmek için iki ana yola bakılır: VDS (Virtual Dedicated Server) / bulut sunucusu ve Dedicated (birebir donanım).

VDS ne zaman yeterli?

VDS genellikle şu durumlarda mantıklıdır: - Trafik dalgalanıyor ve kaynakları ölçeklemek gerekiyor. - Bütçe kontrolü kritik, tek GPU ile başlanacak. - Container tabanlı dağıtım (Docker) ve otomatik yeniden başlatma kullanıyorsunuz.

VDS’in avantajı hızlı başlama ve ölçekleme esnekliğidir. Dezavantajı ise GPU performansında “paylaşımlı” hissi veren durumların bazen yaşanabilmesidir (özellikle aynı fiziksel host üzerinde yoğunluk varsa).

Dedicated ne zaman daha doğru?

Dedicated sunucu şu durumlarda daha iyi sonuç verir: - Eşzamanlı job sayısı yüksek ve SLA benzeri istikrar isteniyor. - Pik dışı dönemlerde bile gecikmenin stabil kalması önemli. - Aynı GPU ile tutarlı performans hedefleniyor.

Dedicated ile genelde daha tutarlı gecikme elde edilir; buna karşılık giriş maliyeti ve kurulum/operasyon yükü VDS’e göre daha yüksek olabilir.

Donanım seçimi: GPU, VRAM, CPU/RAM ve disk

Sunucu tipini belirledikten sonra asıl karar noktası donanım bileşenleridir. Stable Diffusion API için hedefleri “iş üretimi” ve “istekleri yönetme” olarak ikiye ayırın.

1) GPU ve VRAM (en kritik kalem)

GPU alırken şu kriterleri netleştirin: - Hangi model(ler)? SD 1.5, SDXL, ControlNet varyantları VRAM ihtiyacını değiştirir. - Hedef çözünürlük aralığı? 512x512 ile 1024x1024 arasında tüketim büyür. - Batch ve sampler ayarları: Batch arttıkça VRAM yükselir.

Net öneri yaklaşımı: - SD 1.5 (512-768 civarı) ve düşük eşzamanlılık: 8–12 GB VRAM bandı genelde başlangıç için yeterlidir. - SDXL veya 1024’e yaklaşan çözünürlükler: 16 GB ve üzeri daha güvenli olur. - ControlNet / yoğun ek bileşenler: Mümkünse 24 GB VRAM bandı ile daha rahat kapasite planlanır.

2) CPU: GPU’yu aç bırakmayın

CPU’nun görevi üretimi doğrudan hızlandırmaktan çok: - ön hazırlık (tokenizasyon, pre-processing), - dosya/metadata yönetimi, - kuyruk ve worker orchestration, - model ağırlıklarının yüklenmesi ve servis katmanı işlerini yönetmek.

Burada “en pahalı CPU” değil, GPU’yu bekletmeyen yeterli çekirdek/IO kombinasyonu önemlidir.

3) RAM: Worker sayısına göre planlayın

RAM ihtiyacı şunlarla artar: - birden fazla worker çalıştırma, - önbellek (cache), - prompt/parametre geçmişi ve loglama, - görüntülerin geçici tutulması.

Pratik planlama: - Tek GPU ile sınırlı worker: 32 GB RAM genellikle rahat bir başlangıçtır. - Birden fazla worker ve yoğun istek: 64 GB RAM hedefleyin.

4) Disk: Model ağırlıkları ve geçici görsel akışı

Stable Diffusion model dosyaları (checkpoint, LoRA, VAE) disk tüketir; ayrıca API’nin ürettiği görseller için geçici veya kalıcı depolama gerekir.

Disk stratejisi için iki net kural: 1. Model dosyaları hızlı okunmalı: NVMe SSD tercih edin. 2. Görselleri kalıcı tutma planı yapın: Yerel diske “biriktirmek” yerine nesne depolamaya (S3 uyumlu) geçmek daha ölçeklenebilir.

Yerel disk kullanacaksanız bile en azından: - düzenli temizleme (TTL cleanup), - doluluk alarmı, - yedekleme planı olmalıdır.

Ağ (Bant genişliği) ve gecikme: Görsel teslimi boyutu belirler

Gecikme (latency) sadece üretim süresi değildir. Görselin API yanıtı olarak teslim edilmesi bandwidth ve aradaki gecikmeden etkilenir.

Stable Diffusion API’de tipik veri akışı: - İstek: prompt (küçük), parametreler (küçük) - Yanıt: base64 veya dosya URL’si (bazen büyük) - Sonuçlar: önbelleklenebilir ya da kullanıcıya doğrudan iletilebilir.

URL ile teslim mi base64 mü?

Base64: Yanıt boyutu büyür, CDN/cache verimi düşebilir.
Dosyayı nesne depolamaya yazıp URL dönmek: API yanıtı küçülür, bant genişliği daha öngörülebilir olur.

Bu nedenle üretim sunucusunda bant genişliği planlarken şu hesabı yapın: - ortalama görsel dosya boyutu (örn. 300 KB – 2 MB) - günlük/azami istek adedi - eşzamanlı piklerde tekrar deneme (retry) olasılığı

Örnek kapasite hesabı (varsayım): - Ortalama 800 KB - Günde 50.000 istek - Toplam veri ≈ 50.000 x 0.8 MB = 40.000 MB ≈ 40 GB/gün

Üretim tarafındaki trafik artışıyla birlikte bu değerler katlanabilir. Bu yüzden “GPU için aldım ama ağ yetişmedi” durumu yaşamamak için görsel teslim stratejisini baştan belirleyin.

Ölçekleme planı: Tek GPU + kuyruk mu, çok GPU mu?

Stable Diffusion API için en sağlıklı ölçekleme çoğu zaman kuyruk üzerinden yapılır.

Kademeli ölçekleme için önerilen akış

Başlangıç: 1 GPU, 1-2 worker, tek kuyruk
İzleme: P50/P95 üretim süresi, kuyruk uzunluğu, CPU/RAM kullanım
Eşik: Kuyruk uzunluğu veya P95 gecikme belirli seviyeyi aştığında ikinci worker veya ikinci GPU ekle
Pik: Otomatik ölçek (scale-out) ile kapasiteyi artır

Bu yaklaşım, “hemen büyük dedicated aldım ama kullanılmadı” riskini azaltır.

Spot/planlı kademeler

Pik öncesi artırma: Kampanya saatlerinde kaynak artırın.
Pik sonrası azaltma: Saatlik ölçekleme ile maliyeti kontrol edin.
Kuyruk limiti: Sistem çökmeden hata mesajı dönecek sınır tanımlayın.

Doğru kontrat maddeleri: Sunucu siparişinde nelere bakılır?

Teknik olarak GPU yeterli olsa bile, sağlayıcı sözleşmesi performansı etkiler. Stable Diffusion API için aşağıdaki maddeler “kontrol edilebilir” ve “ölçülebilir” konulardır.

GPU tipi ve VRAM netliği: “GPU var” ifadesi değil, model sınıfı ve VRAM miktarı.
Ayrılmış (dedicated) CPU/RAM garantisi: Oversubscription yaşanıyor mu?
Network sınıfı: paylaşımlı mı, garanti bant genişliği var mı?
Disk türü: NVMe/SSD mi? IO limiti var mı?
Backup (yedekleme) yaklaşımı: Model ve konfig dosyaları için; veri depolama stratejisi ile uyumlu olmalı.
İzleme ve erişim: log erişimi, restart mekanizması, temel metrikler.

Kurulum mimarisi: API’yi güvenilir ve yönetilebilir yapın

Sunucu seçiminin yanında mimari de kritik. Stable Diffusion API’yi çalıştıran servis katmanı genelde şu bileşenlere ayrılır: - API gateway: Kullanıcıdan istek alır. - Queue/worker: Job’ları sıraya koyar ve GPU worker’larına dağıtır. - Model servis katmanı: Inference’i yürütür. - Depolama: Üretilen görseller ve gerekirse prompt kayıtları.

Yedekleme ve dayanıklılık

Stable Diffusion üretimi tek seferlik değildir; konfig ve model dosyalarınız kaybolursa tekrar kurulum maliyeti çıkar.

Minimum yedekleme (backup) planı: - model ağırlıkları + LoRA dosyaları (kaynak deposu / image registry) - API konfig (env dosyaları, worker ayarları) - kuyruk ve veritabanı (kullanıyorsanız)

Ayrıca üretim ortamında dosya sisteminde biriktirmeyi sınırlayıp nesne depolama kullanmak, disk doluluk riskini düşürür.

Güvenlik ve erişim

API dışarı açılacaksa temel güvenlik kontrollerini standardize edin: - sadece gerekli portlar - anahtar tabanlı erişim (SSH key) - API rate limit (tek IP’den aşırı istek engelleme) - üretim loglarında hassas bilgileri maskeleme

Bu başlıklar sunucu seçiminden bağımsız görünse de, yanlış kurulum performans sorunlarını da büyütür (ör. saldırı benzeri trafik kuyruk taşırır).

Karar matrisi: Hangi sunucu tipini seçmelisiniz?

Aşağıdaki listeyi kendi senaryonuza uyarlayarak net karar verin.

Eğer şu kriterleri karşılıyorsanız VDS ile başlayın

İlk 30 günde trafik tahmini düşük veya ölçümsüz.
1 GPU ile başlayıp kuyruk üzerinden kapasiteyi artırmak istiyorsunuz.
Otomatik yeniden başlatma ve log/izleme var.

Eğer şu kriterleri karşılıyorsanız Dedicated düşünün

P95 gecikme hedefi sabit kalmalı.
Eşzamanlı job sayısı düzenli olarak yüksek.
Oversubscription kaynaklı dalgalanmalar kabul edilemez.

Sonuç: Hemen “en güçlü GPU” yerine ölçümle kapasiteyi sabitleyin

Stable Diffusion API host etmekte doğru seçim, sadece “GPU aldım” demek değildir; VRAM + kuyruk tasarımı + dosya teslim stratejisi + bant genişliği birleşince tutarlı gecikme oluşur. Aksiyon önerim: İlk aşamada tek GPU ile bir benchmark senaryosu çalıştırın (hedef çözünürlük ve sampler ayarlarıyla), P50/P95 üretim süresini ve kuyruk davranışını ölçün. Sonra ihtiyaç doğrultusunda worker sayısını ve gerekirse ikinci GPU’yu ölçekleyin; görselleri base64 yerine URL mantığıyla nesne depolamaya vererek bant genişliği riskini azaltın.

Bu ölçümler NetKıyas’taki VDS ve dedicated seçeneklerinde karşılaştırmanızı somutlaştırır ve “fazla ödeme” riskini düşürür.