Self-hosted AI: OpenAI API’ye alternatif mi? Maliyet ve mimari rehberi

Self-hosted AI (kendi sunucunda çalışan model) ile OpenAI API gibi bulut tabanlı servisler arasında karar vermek, sadece “hangisi daha ucuz” sorusuna indirgenemez. Gecikme (latency), veri saklama politikaları, ölçekleme, güvenlik denetimi, model güncellemeleri ve operasyon yükü toplam maliyeti belirler. Bu rehberde, kendi altyapında çalıştıracağın bir yapay zeka çözümü ile OpenAI API kullanımı arasındaki farkları somut kalemlerle ele alacak; hangi senaryolarda hangisinin daha mantıklı olduğunu netleştireceksin.

1) Önce tanımları netleştirin: “Self-hosted” ile “API” farkı

Self-hosted AI; model ağırlıklarını (weights) veya en azından çıkarım katmanını (inference) kendi kontrolündeki VDS/VPS/dedicated ya da özel bulutta çalıştırdığınız senaryodur. API yaklaşımında (OpenAI API) ise model hesaplaması sağlayıcının tarafında yapılır; sen sadece istek gönderir, yanıt alırsın.

Bu iki modelin operasyonel farkı şu başlıklarda görünür: - Kontrol: Self-hosted’da GPU sürümleri, model seçimi, sınırlandırma (rate limit), log saklama, veri işleme akışı sende olur. API’da bu kontroller sınırlıdır. - Maliyet yapısı: API “kullanım bazlı” (token/istek) ilerler. Self-hosted’da maliyet daha çok altyapı sabit gider + elektrik + bakım şeklinde oluşur. - Performans: Self-hosted’da coğrafi konum ve ağ gecikmesi daha öngörülebilir olabilir. API’da sağlayıcıya uzaklık ve servis tarafı yük değişken olabilir. - Uyumluluk: Veri (prompt/çıktı) ve saklama politikaları kritikse, self-hosted genellikle daha net bir “izin verilen veri akışı” sunar.

Self-hosted için tipik mimari bileşenler

Self-hosted AI’da pratikte şu bileşenler gerekir: - Model servis katmanı: genellikle vLLM, TGI (Text Generation Inference) veya framework tabanlı çıkarım server’ı - Önbellek ve istek kuyruğu: concurrency yönetimi - Observability: loglama, metrik, hata takibi - Güvenlik: ağ segmentasyonu, disk şifreleme, erişim yetkileri - Yedekleme ve sürümleme: model/konfig, uygulama ve prompt şablonları

2) Maliyet modeli: Token bazlı API ile GPU sabit giderini karşılaştırma

Aşağıdaki tablo, karar verirken hangi maliyet kalemlerini aynı sepete koyman gerektiğini gösterir. Not: Sayılar sağlayıcıya ve GPU kapasitesine göre değişir; burada “hesap mantığını” netleştiriyoruz.

Net bir hesap için 5 metrik

Kendi senaryonu hesaplamak için şu 5 metriği topla: 1. Günlük ortalama istek (request/day) 2. Ortalama yanıt token ve prompt token (prompt + completion) 3. Tepe eşzamanlılık (peak concurrent) 4. Hedef gecikme (ör. p95 < 2s) 5. Model boyutu / kalite hedefi (ör. 7B, 13B, 34B gibi)

Bu metriklerle API tarafında “yaklaşık token maliyeti” çıkar, self-hosted’da ise “gerekli GPU sınıfı + concurrency + kuyruk” belirlenir.

Hızlı uygulama kuralı (pratik eşik)

Tek başına “self-hosted daha ucuz” demek yanlış olur. Net eşik genellikle şunlarla belirlenir: - Aylık token hacmi belirgin büyüyorsa ve talep düzenliyse, self-hosted’ın sabit gideri amorti olur. - Talep dalgalıysa (ör. kampanya dönemleri), API genellikle daha risksiz maliyet sağlar çünkü fazla kapasiteyi kendin satın almaya gerek kalmaz. - Gecikme hedefi çok sıkıysa ve model uzun cevap üretiyorsa, self-hosted’da doğru optimizasyon ve batching ile p95 daha stabil tutulabilir.

3) Gecikme (latency) ve ölçekleme: Sıcak yol haritası

Self-hosted AI’da gecikmeyi belirleyen ana etkenler GPU throughput, batchleme, context uzunluğu ve concurrency yönetimidir.

OpenAI API’da gecikmeyi etkileyen değişkenler

• Modelin sağlayıcı tarafında meşgul olma durumu
• Bölgesel erişim (servise uzaklık)
• İstek formatı ve streaming kullanımı

Self-hosted’da gecikmeyi etkileyen değişkenler

• GPU türü ve VRAM kapasitesi
• Modelin quantization düzeyi (ör. int4/int8) ve kalite/latency trade-off’u
• Context length büyüdükçe iş yükünün artması
• Queue/worker ayarları (concurrency)

Net kontrol listesi

Self-hosted kurulumunda latency hedefini tutturmak için şu kontrolleri yap: - Streaming: Kullanıcı deneyimi için token’lar gelmeye başladığında “bekleme hissi” azalır. - Concurrency sınırı: GPU’yu aşırı doldurup p95’i bozmak yerine kontrollü eşzamanlılık hedefle. - Context limit: Uygulama katmanında maksimum prompt+history uzunluğu koy. - Batching stratejisi: vLLM gibi sistemlerde otomatik batching latency/throughput dengesini etkiler.

4) Veri güvenliği, uyumluluk ve loglama: Karar burada netleşir

Self-hosted’ın en güçlü gerekçesi, verinin işlenmesi ve saklanması üzerindeki denetimdir. API kullanımında bu denetim sınırlıdır; sağlayıcının politikaları ve sözleşme şartları belirler.

Self-hosted’da net olarak kontrol edebileceğin şeyler

• Prompt/response loglarının tam olarak nerede ve ne kadar süre saklandığı
• Loglarda hassas verinin maskelenmesi (ör. kullanıcı e-postası, kimlik bilgisi)
• Disk şifreleme ve erişim yetkileri (IAM benzeri mantık)
• Ağ izolasyonu (private subnet / firewall)
• Model çıktısı saklama ve veri silme süreçleri

OpenAI API kullanımında genellikle daha az kontrol olan alanlar

• Sağlayıcının altyapısında veri saklama süreleri ve işleme süreçleri
• Üçüncü taraf log retention mekanizmaları

Net pratik öneri: Veri sınıflandırması yap. “Hangi prompt türleri saklanmamalı?” sorusunu yazılı hale getir. Bu listeyi karşılayamıyorsan self-hosted lehine karar güçlenir.

5) Operasyon yükü: Bakım, güncelleme ve maliyet sızıntılarını ölç

Self-hosted AI; sadece GPU almakla bitmez. Bir “model servis işletimi” disiplini gerektirir.

Self-hosted’da sık görülen maliyet sızıntıları

• GPU sürücüsü / CUDA uyumsuzluğu ile servis downtime
• Yeni model sürümünde performans düşüşü (quantization ayarı değişir)
• Context uzunluğu büyüdükçe maliyetin (veya latency’nin) kontrolsüz artması
• İstek kuyruğu ayarsızlığıyla p95’in bozulması
• Günlük log boyutunun disk maliyetine dönüşmesi

Net bir operasyon planı

• Otomatik yeniden başlatma (process manager)
• Health check: Liveness/readiness endpoint
• Canary deploy: Yeni model/parametreyi önce küçük trafiğe aç
• Sürümleme: Model + prompt şablonu + inference ayarları birlikte etiketlenmeli
• Yedekleme: Uygulama konfig + prompt şablonları + izinli veri setleri

6) Karar çerçevesi: Hangi senaryoda hangisi daha net avantajlı?

Aşağıdaki listeyi “evet/hayır” gibi düşün. 3-4 başlık aynı yöne çıkıyorsa karar netleşir.

OpenAI API lehine net sinyaller

• Aylık token hacmi henüz çok yüksek değil.
• Talep dalgalı (ör. haftalık kampanyalar, sezonluk sıçramalar).
• Kurulum/operasyon ekibin sınırlı.
• Veri saklama ve uyumluluk için sözleşme şartları yeterli geliyor.
• En düşük maliyet değil; en düşük operasyon riski hedefleniyor.

Self-hosted AI lehine net sinyaller

• Aylık token hacmi yüksek ve düzenli.
• Veri akışında sıkı kontrol gerekiyor (log/retention/maskeme).
• Türkiye içi kullanıcılar için daha öngörülebilir latency isteniyor.
• Model seçimi ve ince ayar süreçleri (fine-tuning) veya özel prompt pipeline zorunlu.
• Uzun vadede “sabit kapasite” satın alıp maliyeti yönetmek istiyorsun.

Somut karşılaştırma tablosu (senaryo bazlı)

7) Net uygulama: Geçiş stratejisi ve hibrit model (en az riskli yol)

Birçok ekip tek hamlede “tam API” ya da “tam self-hosted” seçmiyor. En az riskli yaklaşım hibrit bir plan kurmaktır: - Düşük riskli istekleri API ile karşıla. - Hassas veri içeren istekleri self-hosted’a yönlendir. - Aynı arayüzü koru (uygulama seviyesinde “LLM provider abstract” katmanı). - Başarı metriklerini karşılaştır: cevap süresi, hata oranı, maliyet/istek.

Hibritte net ölçüm kurgusu

Şu metrikleri her iki tarafta da aynı tanım ile topla: - Maliyet/istek - p50 / p95 latency - Başarısız istek oranı - Token kullanım oranı (prompt-to-output) - Kalite proxy (ör. insan değerlendirme puanı veya otomatik rubric)

Sonuç: Hemen seçim yapmanızı sağlayacak aksiyon

Önce bir hafta veri topla: günlük istek, ortalama prompt+completion token, tepe eşzamanlılık ve hedef p95 gecikme. Ardından iki hesap çıkar: OpenAI API için token bazlı maliyet ve self-hosted için gerekli GPU kapasitesi + kuyruk/latency ayarlarının getireceği sabit gider. Eğer veri saklama ve denetim ihtiyacı yüksekse self-hosted tarafı güç kazanır; talep dalgalıysa API daha net risk azaltır. Bu iki eksenden hangisi daha baskınsa, ilk aşamada hibritle ilerleyip metriklerle doğrula—kararı “varsayım” değil “ölçüm” üzerinden kilitle.