Stable Diffusion API için sunucu seçimi: CPU/GPU, gecikme, ölçek

Stable Diffusion gibi görsel üretim işlerini API üzerinden sunmak, klasik web siteleri gibi davranmaz. En kritik fark; işlem yükünün büyük kısmının GPU üzerinde olması, kullanıcı isteklerinin ise saniyeler içinde “yanıt süresi” beklentisi oluşturmasıdır. Bu rehberde Stable Diffusion API host etmek için hangi sunucu türünün gerektiğini, hangi mimarinin daha az gecikme verdiğini ve kapasiteyi nasıl net hesaplayacağınızı öğreneceksiniz. Ayrıca güvenlik, kuyruk (queue) yönetimi ve maliyet kontrolü için pratik karar kriterleri bulacaksınız.

1) Stable Diffusion API’de asıl darboğaz: GPU değilse bile gecikme nerede olur?

Stable Diffusion’u “API” yapmanın amacı, kullanıcıdan gelen parametreleri alıp (ör. prompt, seed, boyut, adım sayısı) model inferansı çalıştırmak ve sonucu döndürmektir. Bu akışta darboğaz genellikle şu sırayla oluşur:

• Inferans (model çalıştırma): GPU yoksa süre katlanır.
• Ön/son işlem (pre/post-processing): Özellikle PNG çıktısı, resize/normalize, base64 dönüşümü.
• İstek kuyruklama: Aynı anda gelen istekler GPU’yu tek başına meşgul eder; kuyruk yoksa zaman aşımı olur.
• Model yükleme: Her istekte modeli diskten yüklemek gereksiz gecikme üretir.
• Dosya ve depolama: Sonuçları diskten alıp API yanıtına eklemek I/O gecikmesi çıkarır.

Bu yüzden “hosting kaliteli olsun” gibi soyut yaklaşımlar yerine, hedefinizi netleştirmeniz gerekir: Aynı anda kaç istek, ortalama kaç saniyede yanıt ve kuyrukta en fazla kaç saniye bekleme kabul edilebilir?

API gecikme hedefi için net test

Bir deneme için aşağıdaki metrikleri hedefleyin: - TTFT (time to first token / ilk çıktıya kadar süre değil): Stable Diffusion’da her zaman “token” olmadığı için pratik karşılık: “ilk görselin hazır olmasına kadar süre”. - P95 yanıt süresi: Trafik artınca kullanıcıların çoğu değil, %95’inin kabul edeceği süre. - Kuyruk bekleme süresi: GPU meşgulse istek kaç saniye bekliyor?

Örnek hedef: 1 kullanıcı aynı anda 1 istek gönderdiğinde 10-20 saniye, yoğunlukta P95 30-60 saniye gibi.

2) CPU ile host etmek mümkün mü? Net karar: GPU şart

Stable Diffusion’u CPU ile çalıştırmak teknikte mümkün olsa da pratikte “API” kullanım beklentisini karşılamaz. CPU tarafında gecikme; model boyutu, adım sayısı ve görsel boyutu büyüdükçe hızla artar. Bu nedenle gerçek kullanım senaryolarında şu kuralı esas alın:

• Kendi içinde prototip / çok düşük kullanım: CPU kabul edilebilir.
• Ürünleştirilmiş API (kullanıcı bekliyor, reklam gibi değil): GPU gerekir.
• Eşzamanlı istek: GPU olmadan ölçeklenme olmaz.

CPU senaryosunda bile planlanması gerekenler

CPU ile ilerleyecekseniz bile şu iki şeyi net yapın: - Modeli sürekli açık tutun (her istek “model load” yapmasın). - Kuyruk kullanın; istekleri paralel işleyip sistemi kilitlemeyin.

3) GPU seçimi: VRAM (video belleği) ve hızdan fazlası

GPU seçerken yalnızca “yüksek VRAM” demek yetmez. Stable Diffusion API’de şu parametreler doğrudan maliyet ve performansı belirler:

• VRAM kapasitesi (GB): Daha büyük çözünürlük ve batch/parallel denemeleri için kritik.
• Hız (compute): Aynı parametrelerde inferans süresi.
• Sanallaştırma türü: Paylaşımlı GPU yaklaşımında kaynak etkilenebilir.
• Driver / CUDA uyumu: Model kütüphaneleriyle uyumlu sürümle çalışmak zaman kazandırır.
• Depolama ve ağ: Model dosyaları ve çıktı transferi gecikmeyi etkiler.

VRAM ihtiyacı için pratik aralıklar

Aşağıdaki aralıklar “genel planlama” içindir; kullandığınız model varyantı ve çözünürlük hedefinize göre değişir: - 4–6 GB VRAM: Düşük çözünürlük ve daha sınırlı ayarlar. - 8–12 GB VRAM: Tipik API denemeleri; 512x512 ve yakın profillerde rahat. - 16 GB VRAM ve üzeri: Daha yüksek çözünürlük, daha geniş batch/parallel planları.

4) Sunucu tipi karşılaştırması: GPU planı, VDS/VPS/dedicated

Stable Diffusion API için sunucu seçimi “hosting paketi” kadar “sunucu mimarisi” meselesidir. Aşağıdaki tablo, tipik seçenekleri performans ve operasyon açısından kıyaslar.

“Dedicated şart mı?” net kriter

• P95 gecikme hedefiniz 60 saniyenin altıysa ve aynı anda birden fazla kullanıcı bekleniyorsa GPU dedicated veya kaynak garantili GPU planı daha güvenlidir.
• Trafik düşük ve kullanım seyrekse, doğru ayarlanmış GPU VPS ile başlamak daha rasyonel olur.

5) Kapasite planı: Aynı anda kaç istek çalıştırabilirsiniz?

Stable Diffusion API’de ölçek hesabının temeli şudur: - Bir isteğin ortalama inferans süresi = T - Eşzamanlılık = kuyrukta bekleyen istek sayısı + GPU’nun çalışma kapasitesi

Net bir yaklaşım için şu adımları uygulayın:

Hız testi (benchmark) yapın

Aşağıdakileri aynı anda değişmeden tutun: - Aynı model - Aynı çözünürlük - Aynı adım sayısı - Aynı sampler (varsa) - Aynı batch kuralı (genelde batch=1)

Sonra 20-50 istek çalıştırın ve süre istatistiği çıkarın. Hedef “ortalama” değil P95’tir.

Basit kapasite modeli

GPU’nun “tek iş” çalıştırma varsayımıyla (çoğu kurulumda pratikte böyle yönetilir): - 1 GPU ile teorik servis oranı ≈ 1 / T (istek/saniye) - P95 kullanırsanız planlama daha gerçekçi olur: oran ≈ 1 / P95

Örnek: P95 = 20 saniye ise 1 GPU teorik ≈ 0.05 istek/saniye. Dakikada ≈ 3 istek.

Buna göre: - Dakikada 60 istek bekliyorsanız: 60/3 = yaklaşık 20 GPU iş kapasitesi gerekir. Bu, sadece GPU sayısı gibi görünür ama gerçek hayatta kuyruk, I/O ve servis katmanı payı da vardır. O yüzden yukarı yuvarlayın.

6) Ölçekleme mimarisi: tek sunucu değil, kuyruk + worker

Stable Diffusion API’yi “tek process” gibi düşünmek hızla sorun üretir. Doğru mimari yaklaşımı:

• API katmanı: istekleri alır, doğrular, kuyruğa yazar.
• Worker katmanı: kuyruktaki işleri sırayla alır ve GPU üzerinde inferansı yapar.
• Sonuç depolama: çıktıyı kalıcı depolamaya yazar (object storage gibi) ve kullanıcıya link/yanıt döner.

Neden kuyruk şart?

Kuyruk yoksa aynı anda gelen istekler: - GPU belleğini taşır - Zaman aşımı (timeout) hataları üretir - Yanıt sürelerini P95 seviyesinde kontrol edilemez hale getirir

Worker sayısı nasıl belirlenir?

• Tek GPU için ilk kurulumda 1 worker ile başlayın.
• VRAM taşmasını önlemek için batch paralelliğini artırmadan önce T ve P95’yi ölçün.
• İkinci worker ancak GPU ve VRAM izin verdiğinde eklenmelidir.

7) Güvenlik ve dayanıklılık: API’yi hedefe göre kilitleyin

Stable Diffusion API “görsel üretim” yaptığı için kaynak tüketimi üzerinden saldırılara açıktır (ör. aşırı boyut, aşırı adım sayısı, devasa istek hacmi). Bu nedenle sunucu planlarken güvenlik kurallarını de facto mimarinin parçası yapın.

İnferans parametrelerini sınırlandırın

Sunucu tarafında şu limitleri koyun: - Maksimum çözünürlük: ör. 1024x1024 üstü varsayılan kapalı - Maksimum adım sayısı - Maksimum istek boyutu ve kimlik doğrulama olmadan rate limit

Rate limit ve kimlik doğrulama

• Kimlik doğrulaması (API key, token)
• IP bazlı rate limit
• Kullanıcı başına kota

Dosya ve çıktı yönetimi

• Çıktıları sunucu diskinde sınırsız tutmayın
• Belirli süre sonra temizleme (retention)
• Sonuçları mümkünse dış depolamada saklayın

8) Maliyet hesabı: En pahalı şey GPU değildir, kötü yönetimdir

Stable Diffusion API maliyeti üç kalemde büyür: - GPU saat maliyeti - İstek başına süre (P95 uzadıkça aynı zamanda daha fazla GPU saati gerekir) - Depolama/transfer (özellikle büyük görseller)

Net maliyet planı için şunu yapın: - İstek başına ortalama üretim süresini P95 ile hesaplayın. - Günlük planlanan istek sayısını belirleyin. - GPU kullanımını kuyrukla simüle edin.

Önemli not: Saatlik faturalama yapan GPU bulutlarında “idle” GPU’yu azaltmak için worker’ları trafik yokken ölçeklemeyle kapatmak gerekir.

9) Operasyon kontrol listesi: Kurduktan sonra gerçekten çalışan sistem

Sunucu kurduktan sonra “şu çalışıyor” kontrolü yetmez. Stable Diffusion API’de şu operasyon kalemleri kritiktir:

Model ve dependency yönetimi

• Model dosyalarını başlatma anında indirip saklayın; her istek indirmeyin.
• Driver/CUDA uyumunu sabitleyin.

Loglama ve ölçüm

• İstek başına süre (P50/P95)
• Kuyruk uzunluğu
• Hata oranı (OOM, timeout, invalid param)

Yedekleme (backup) konusu

Stable Diffusion için “veritabanı” bazen temel değildir; ama: - API kullanıcı verileri varsa (API key, kota) - İş geçmişi/sonuç metadatası tutuluyorsa - Konfigürasyonlar ve worker ayarları varsa

Bunlar için yedekleme (backup) planı yapın. Görselleri üretim sonrası disk yerine dış depoda tutmak, sunucu yeniden kurulumlarında süreyi düşürür.

Sonuç: Stable Diffusion API için doğru ilk karar

Stable Diffusion API’yi host etmek için en net yol şudur: GPU ile başlayın, kuyruk + worker mimarisi kurun, kapasiteyi P95 ölçümüyle hesaplayın. Prototipte CPU denenebilir, ancak ürün kullanımında CPU planı gecikme hedeflerine çarpar.

İlk aksiyon olarak şu sırayı izleyin: 1) Model, çözünürlük ve adım hedefinizi sabitleyin. 2) Aynı ayarlarla 20-50 istek test edip P95 süreyi çıkarın. 3) 1 GPU ile başlarken worker sayısını 1’de tutun. 4) P95 ve kuyruk beklemesine göre ikinci GPU/instance ihtiyacını netleştirin.

NetKıyas üzerinden GPU’lu sunucu seçeneklerini karşılaştırırken “CPU/RAM” değil; GPU sınıfı, VRAM, sanallaştırma yaklaşımı, saatlik maliyet ve ölçülebilir gecikme kriterlerini önceliklendirin. Bu yaklaşım, hem maliyeti hem de kullanıcı deneyimini kontrol altına alır.