Self-Hosted AI Alternatifleri vs OpenAI API: Net Maliyet ve Mimari Rehberi

Günümüzde geliştiricilerin en sık karşılaştırdığı iki yaklaşım self-hosted AI (kendi sunucunuzda model çalıştırma) ve OpenAI API (dış servis üzerinden erişim). Bu ikisi sadece “fiyat” meselesi değildir; gecikme (latency), veri güvenliği, ölçekleme ve bakım yükü doğrudan mimarinizi etkiler. Bu rehberde, hangi durumda self-hosted daha rasyonel olur, hangi durumda API daha net avantaj sağlar sorusunu somut senaryolar ve hesap mantığıyla yanıtlıyorum.

1) Önce karar çerçevesi: Aynı şeyi mi satın alıyorsunuz?

Self-hosted AI ile OpenAI API arasında ortak görünen şey “sohbet/makine öğrenmesi çıktısı”dır. Ancak altta farklı katmanlar var:

• Self-hosted AI: Model ağırlıkları (weights), çıkarım altyapısı (inference), GPU/CPU kaynağı, model güncellemeleri, izleme ve güvenlik sizde.
• OpenAI API: Model sağlayıcının altyapısı, ölçekleme ve bazı optimizasyonlar hazır geliyor; siz sadece istek atıp sonuç alıyorsunuz.

Bu yüzden aynı performansı hedefleseniz bile toplam sahip olma maliyeti (TCO) farklı çıkar. Kararı doğru vermek için 4 metriğe bakın:

1.1 Gecikme hedefi (latency) ve istek dağılımı

• Kullanıcı etkileşimi anlık (chat/assistant) ise p95/p99 latency önemlidir.
• İş yükü “toplu üretim” (batch) ise throughput daha kritik olur.

1.2 Veri hassasiyeti ve uyumluluk

• KVKK (Türkiye) ve benzeri düzenlemelerde veri işleme süreçleri önem taşır.
• Bazı işletmeler “veri dışarı çıkmasın” yaklaşımıyla self-hosted tarafına net eğilir.

1.3 Ölçekleme paterni

• Gün içinde dalgalanma varsa (ör. kampanya günleri) API yaklaşımı daha “operasyonel” rahatlık sağlar.
• Sürekli yüksek trafik varsa self-hosted daha hızlı maliyet avantajı üretebilir.

1.4 Bakım ve model yaşam döngüsü

• Self-hosted tarafında model güncellemeleri, GPU sürümleri, konteyner imajları, cache stratejileri ve sürüm uyumluluğu sizdedir.
• API tarafında bu sorumluluk sağlayıcıya devredilir.

2) Maliyet kıyası: “Model fiyatı” tek başına yeterli değil

Self-hosted AI’da maliyeti oluşturan parçalar:

• GPU/CPU bulut maliyeti (ör. 1 adet büyük GPU yerine 2 adet orta GPU ile ölçek gibi)
• Depolama (model dosyaları + loglar)
• Ağ egress/ingress maliyeti (kullanıcılar + servis içi çağrılar)
• İşletim giderleri: izleme (monitoring), yedekleme (backup), güvenlik güncellemeleri

OpenAI API’de maliyet parçaları:

• Token bazlı kullanım bedeli (prompt + completion)
• Rate limit ve abonelik/plan etkileri
• Gerekirse ek modüller (ör. embeddings veya reranking)

2.1 Somut hesap şablonu (kendi verinizle)

Aşağıdaki mantıkla iki tarafı da aynı birimde kıyaslayın.

Self-hosted aylık maliyet formülü

• Aylık GPU maliyeti = GPU_saatlik_birim * aylık_kullanım_saat
• Aylık depolama + ağ = (model boyutu + log hacmi) * birim fiyat
• Operasyon maliyeti = (yaklaşık ekip/saat) * saat maliyeti

OpenAI API aylık maliyet formülü

• Aylık maliyet = aylık_toplam_token * token_birim_fiyat
• Ek modüller = embeddings/rerank gibi ek tokenlar

Bu şablonu NetKıyas mantığıyla düşünün: sadece “sunucu fiyatı” değil, ay sonu toplam fatura çıkaran tüm kalemleri toplayın.

2.2 Kıyas tablosu (yük türüne göre)

Aşağıdaki tablo, maliyetin hangi yönde artacağını hızlı görmeniz için tasarlandı.

3) Performans ve mimari: Aynı istek farklı sonuç verir

Performans konusu yalnızca “model hızlı mı?” değil; şu 3 katmana da bağlı:

1) Prompt hazırlama (preprocessing) 2) Model inference (çıkarım) 3) Sonuç sonrası işlemler (postprocessing, streaming, araç çağrıları)

3.1 Gecikme (latency) kaynakları

Self-hosted tarafında gecikme şu adımlarda artabilir: - İlk model yükleme / warmup - KV cache yönetimi (özellikle uzun bağlamlarda) - Batch/queue stratejisi - GPU doyumu (GPU utilization)

API tarafında gecikme: - Sağlayıcının altyapı tüneli - Bölgesel erişim (region) - Rate limit kuyruğu (yük arttıkça)

3.2 Bölge seçimi (region) ve ağ mesafesi

• Chat akışında gecikme p95, kullanıcı memnuniyetini doğrudan etkiler.
• Self-hosted kurulumda sunucu lokasyonu sizin kitleye yakın olmalıdır.
• API kullanımında da uygulamanızın bulunduğu bölge önemlidir; eğer altyapınız Türkiye’deyse API çağrıları Türkiye’den çıkıyorsa p95 gecikme daha hissedilir olabilir.

3.3 Model seçimi: Kalite/latency dengesi

Self-hosted’da aynı bütçeyle daha küçük model çalıştırıp hız kazanmak mümkündür. API tarafında ise “en iyi kalite modeli” seçimi daha hızlı uygulanır ama token maliyeti daha yüksek olabilir.

Net yaklaşım: - İlk aşamada amaç “ürün prototipi” ise API ile model kalitesini test edin. - Kaliteyi yakaladıktan sonra “kullanım yoğunluğu” belli olunca self-hosted’e geçiş eşiğini hesaplayın.

4) Güvenlik ve veri kontrolü: Teknik olarak ne değişiyor?

AI entegrasyonunda güvenlik “SSL/TLS” ile bitmez. Şunları ayırın:

4.1 Veri hareketi

• OpenAI API’de prompt ve gerekli veriler dış servise gider.
• Self-hosted’da promptlar kendi kontrolünüzdeki ağ içinde kalır (daha güçlü veri kontrolü).

4.2 Erişim kontrolü ve anahtarlar

OpenAI API: - API anahtarlarınız uygulama tarafında saklanmalı ve sunucuya erişimle korunmalı. - Anahtar rotasyonu (rotation) planınız olmalı.

Self-hosted: - İnference endpoint’ini (ör. reverse proxy arkasında) otentikasyonla kilitleyin. - Uygulama kullanıcılarını tenant bazında ayırın.

4.3 Günlük loglar ve yedek (backup) disiplini

• Chat loglarını tutuyorsanız: PII maskeleme (kişisel veri maskeleme) ve saklama süresi belirleyin.
• Hem API entegrasyonunda hem self-hosted’da loglardan veri sızabilir; fark, loglar sizin altyapınızda mı yoksa sağlayıcının süreçlerinde mi?

4.4 Jailbreak ve prompt enjeksiyonu

Her iki yaklaşımda da risk vardır; fark, self-hosted’da prompt filtreleme ve ek güvenlik katmanlarını doğrudan siz kurarsınız. Net uygulama: - Sistem prompt’unuza sınır koyun (policy) - Araç çağrısı (tool calling) yetkilerini kısıtlayın - İçeriği modele göndermeden önce doğrulayın

5) Ölçekleme ve operasyon: Kim ne kadar “sırtlar”?

5.1 Self-hosted operasyon kontrol listesi

Self-hosted geçmeden önce şu başlıkları netleştirin:

• GPU kapasite planı: Beklenen eşzamanlı kullanıcı sayısı ve ortalama/tepe istek oranı
• Queue yönetimi: Burst trafiği için kuyruk ve timeout stratejisi
• Otomatik ölçek (auto-scaling): Mümkünse saat bazlı ölçek veya Kubernetes HPA tarzı yaklaşım
• Yedekleme (backup) ve geri dönüş: Model dosyaları, konfigürasyon, prompt şablonları ve uygulama kodu için
• İzleme (monitoring): CPU/GPU utilization, VRAM, p95 latency, hata oranı
• Güvenlik: WAF, rate limit, endpoint yetkilendirme

Bu başlıklar “ek iş” gibi görünse de doğru kurulmazsa maliyet farkı hızla kapanır.

5.2 API tarafında kontrol noktaları

OpenAI API’de operasyonda genelde şunlar sizin sorumluluğunuzda kalır: - Uygulama katmanında retry/backoff mantığı - Token maliyetini izlemek (cost tracking) - Rate limit uyumu - Cache (aynı promptlar için) ve sonuç tekrarlarını azaltma

Net fayda: Bu kontroller daha az altyapı gerektirir.

6) Hangisi daha mantıklı? 6 net senaryo

Aşağıdaki eşleştirme, karar vermeyi hızlandırmak için tasarlandı.

6.1 OpenAI API’nin net avantajlı olduğu senaryolar

• Kullanım ilk etapta düşük/orta ve dalgalı (kampanya günleri gibi)
• Hızlı ürün çıkarma, model kalitesini test etme öncelik
• Ekipte GPU altyapısı kurup işletmek için zaman sınırlı
• Veri dışarı çıkmaması kritik “mutlak” bir gereklilik değil

6.2 Self-hosted AI’nin net avantajlı olduğu senaryolar

• Trafik sürekli yüksek ve tahmin edilebilir
• Token kullanım maliyeti hızla büyüyor ve bütçe öngörülebilirliği gerekiyor
• Veri kontrolü kritik (promptlar hassas, regülasyon/iş politikası sıkı)
• Kurumsal güvenlik süreçleri: kendi ağınızda endpoint, kendi loglama ve maskeleme standardınız

6.3 Hibrit (API + self-hosted) yaklaşımı: Pratik çözüm

Birçok ekip tek modele kilitlenmek yerine: - Kritik, hassas içerikler self-hosted - Genel içerik ve uzun kuyruk işleri API - Aynı zamanda cost tracking ile otomatik rota

Bu yaklaşım, hem maliyet hem risk dengesini iyileştirir.

7) Net geçiş stratejisi: “Deney → ölç → eşiği bul → karar ver”

Geçişi belirsiz bırakmayın. Şu planı uygulayın:

7.1 2 haftalık ölçüm dönemi

• 2 senaryo çıkarın: kısa chat ve uzun içerik (ör. uzun doküman özetleme)
• Ortalama prompt token ve completion token değerlerini toplayın
• p95 latency hedefini belirleyin

7.2 Maliyet eşiğini hesaplayın

• OpenAI API aylık token maliyetini hesaplayın
• Self-hosted için planlanan GPU/CPU altyapısının aylık maliyetini ve “idle” durumunu dahil edin
• Self-hosted kâra geçtiği noktayı belirleyin: aylık token eşiği (token eşiği)

7.3 Başarısız olursa geri dönüş planı

Self-hosted geçişinde şu durumlar görülebilir: - p95 latency hedefini tutturamama - Kalite farkı - Operasyonel arızalar (GPU driver, servis çökmeleri)

Geri dönüş için API fallback stratejisi kurun.

Sonuç

Self-hosted AI ile OpenAI API arasında “hangisi daha iyi?” sorusunun tek cevabı yok; doğru cevap, kullanım paterni (dalgalı mı sürekli mi), veri hassasiyeti (dışarı çıkma zorunluluğu var mı), gecikme hedefleri ve ek operasyon kapasitenize bağlı. Net aksiyon: Önce 2 haftalık kullanım ölçümü yapın, token tabanlı API maliyetini ve GPU tabanlı self-hosted TCO’yu aynı şablonla çıkarın; ardından self-hosted’in kâra geçtiği eşiği belirleyip pilot geçiş yapın. Bu eşik netleşmeden “tam geçiş” kararı vermeyin; ölçüm, karar kalitesini doğrudan yükseltir.