Self-hosted AI alternatifleri: OpenAI API’ye karşı teknik rehber

Bugün bir yapay zekâ modelini kullanmanın en hızlı yolu çoğu senaryoda OpenAI API gibi bulut servislerini tercih etmektir. Ancak yüksek veri hassasiyeti, maliyet kontrolü, yerel gecikme gereksinimi veya kullanımın büyümesi gibi nedenlerle self-hosted (kendi sunucunda çalıştırılan) AI alternatifleri giderek daha mantıklı hale geliyor. Bu rehberde, OpenAI API yerine kendi sunucunda çalıştırabileceğin çözümleri; mimari seçenekler, kaynak ihtiyaçları, güvenlik ve işletme maliyetleri açısından net bir çerçevede ele alıyorum.

Hedef: “Hangi senaryo için hangi yaklaşım?” sorusuna doğrudan yanıt verebilmek. Sonunda da kendi kullanımına uygun bir karar kontrol listesi bırakıyorum.

1) Karar çerçevesi: OpenAI API mi self-hosted mi?

Self-hosted AI’ya geçmeden önce, kararın temelini 4 başlık belirler:

• Gecikme (latency): API çağrısı ağ üzerinden gerçekleşir. Self-hosted modeli aynı lokalde çalıştırarak gecikmeyi azaltabilirsin.
• Toplam maliyet (TCO): OpenAI API’de birim maliyet kullanım miktarıyla artar. Self-hosted tarafında donanım + elektrik + bakım sabit maliyete döner.
• Veri kontrolü ve uyumluluk: Self-hosted, veriyi kendi sınırların içinde tutma avantajı sağlar; buna karşılık kendi güvenlik sorumluluğunu üstlenirsin.
• İşletme zorluğu: Modeli çalıştırmak, güncellemeleri takip etmek, ölçeklemek ve izlemek teknik operasyon gerektirir.

Aşağıdaki tablo, seçim mantığını hızlı görselleştirir:

Hangi durumda self-hosted daha mantıklı?

• Uygulamanın günde/ayda yüksek istek hacmi var ve birim maliyet farkı belirginleşiyor.
• Üretilen/veriyle ilişkili metinlerin işlenmesi daha sıkı kontrol gerektiriyor.
• Aynı modelin farklı kullanım senaryolarında (RAG, sohbet, araç çağırma) tutarlı performans üretmesi gerekiyor.
• “Birim gecikme” kullanıcı deneyimini doğrudan etkiliyor (ör. canlı asistan).

2) Self-hosted seçenekler: Modeli nerede ve nasıl çalıştırırsın?

Self-hosted dünyasında aynı hedefe farklı mimarilerle ulaşılır. En sık 3 yaklaşım var:

2.1 Doğrudan model çalıştırma (GPU ile)

• Model ağırlıklarını (weights) kendi altyapında çalıştırırsın.
• İdeal tarafı: kontrolün tam olması.
• Zorluk: GPU maliyeti, disk/IO, model yönetimi, ölçekleme.

Tipik bileşenler: - Bir VPS/VDS üzerinde GPU (GPU instance) veya on-prem donanım - Modeli çalıştıran servis (örn. vLLM, TGI, llama.cpp tabanlı farklı varyantlar) - Bir API katmanı (kendi backend’in veya model sunucu aracı) - İzleme + otomatik yeniden başlatma

2.2 CPU/GPU karışık: Quantized model ile maliyeti düşürme

Tam precision yerine quantization (örn. 4-bit/8-bit) ile model boyutunu ve gereken hesap gücünü azaltabilirsin. - İdeal tarafı: daha düşük donanımla başlama. - Zorluk: çıktı kalitesi ve hız profili modele göre değişir.

Bu yaklaşım, “her istek için ağır model” yerine “kademeli kullanım” yapmak isteyenler için daha uygundur (ör. basit sorgular hafif model, zor işler daha güçlü model).

2.3 “AI API benzeri” yerel katman: OpenAI-uyumlu endpoint (compatibility)

Amaç, uygulamayı OpenAI API formatından koparmadan self-hosted tarafa geçmektir. Bunun için: - OpenAI-uyumlu API (OpenAI API style) sunan bir gateway/servis kullanırsın. - Uygulamanın tarafında sadece base URL ve kimlik bilgilerini güncellersin.

Bu, geliştirici maliyetini azaltır. Operasyon tarafında ise kendi gateway’in ve model servisin sorumluluğu sana geçer.

3) Kaynak planlama: Self-hosted AI’da gerçek maliyet ve minimum spec

Self-hosted kararının kalbinde donanım vardır. Burada “tek doğru” yok; model boyutu, istek türü ve eşzamanlılık belirleyicidir.

3.1 Basit bir kapasite tahmini nasıl yapılır?

Şu değişkenler net şekilde belirlenmeli: - Günlük/saatsel istek sayısı - Ortalama prompt uzunluğu (token) - Beklenen çıktı uzunluğu (max tokens) - Eşzamanlı kullanıcı - Kullanım şekli: tek tur sohbet mi, çok adımlı araç çağırma mı, RAG var mı

Bu verileri olmadan “şu kadar GPU yeter” demek teknik olarak hatalı olur.

3.2 Ollama gibi yerel runtime’lar neden popüler?

Ollama ve benzeri araçlar: - Model download/yönetimini kolaylaştırır - API entegrasyonunu hızlandırır - Yeni başlayanlar için daha az konfigürasyonla çalışmaya başlatır

Ancak üretim ölçeğinde; izleme, performans kararlılığı, concurrency yönetimi ve güncelleme stratejisi ayrıca ele alınmalıdır.

3.3 Disk ve RAM tarafı: sadece GPU değil

Sadece GPU’ya odaklanmak yanlış olur. Pratikte: - Model dosyaları ve önbellekler disk tüketir. - Token işleme için RAM ve sistem tamponları gerekir. - Loglama ve retrieval (RAG) için ek bellek/IO gerekebilir.

Net kontrol: “GPU yetiyor ama yük bindirince latency artıyor” problemi genellikle disk/IO ve CPU tarafından da gelir.

4) OpenAI API ile self-hosted performans karşılaştırması

Performans tek boyutlu değildir. Gecikme (latency), throughput (dakikadaki/ saniyedeki işleme), hata oranı ve kuyruklama davranışı birlikte değerlendirilir.

4.1 Gecikme: kısa cevaplar mı, uzun üretim mi?

• OpenAI API’de ağ mesafesi ve servis kuyrukları etkilidir.
• Self-hosted’de ağ mesafesi daha düşük olabilir; fakat modelin kendi hesap süresi belirleyicidir.

Uzun üretim (yüksek max tokens) kullanan uygulamalarda self-hosted throughput avantajı sağlayabilir; çünkü yerel altyapı kaynaklarını doğrudan yöneteceksin.

4.2 Throughput ve kuyruk (queue) yönetimi

Self-hosted tarafında concurrency artınca şu 3 şey kritik olur: - Aynı anda gelen istekleri yönetebilen bir scheduler - Cihaz kaynaklarını (özellikle GPU) verimli kullanma - Otomatik ölçekleme (ister stateless API, ister container ile)

Bu yüzden üretimde “tek makine, tek model” ile başlamak yerine, büyüme senaryosunu en baştan planlamak gerekir.

4.3 Maliyet: birim hesap değil, kullanım profili

OpenAI API maliyeti genellikle token başına birim üzerinden yürür. Self-hosted’de ise: - GPU saat maliyeti - Eşzamanlılık nedeniyle ek CPU/RAM ihtiyacı - İşletme süresi (24/7 mi, günün belirli saatleri mi) - Yedekleme ve model güncelleme süreçleri

Özet: Kendi kullanım profilini çıkarmadan “hangisi daha ucuz” demek mümkün değildir.

5) Veri güvenliği ve operasyon: sorumluluk dönüşümü

Self-hosted’e geçtiğinde sorumluluk tersine döner.

5.1 Veri nerede kalır?

• OpenAI API kullanırken, verinin bulut servisinde işlenmesi söz konusudur.
• Self-hosted’de promptlar ve gerekirse RAG dokümanları senin kontrolündeki sistemde kalır.

Bu avantaj önemli; ancak doğru güvenlik tasarımı şart.

5.2 Pratik güvenlik kontrolleri (minimum set)

• Üretim ortamında sadece güvenli erişim: SSH yerine uygulama katmanı üzerinden erişim, yönetim paneli için IP kısıtlama
• API endpoint’te kimlik doğrulama (token tabanlı) ve rate limit
• Disk şifreleme ve parola yönetimi (secrets)
• Loglarda kişisel veri filtreleme
• Model ve servis için düzenli güncelleme planı

Önemli nokta: Self-hosted “veri kontrolü” sağlar; fakat veri güvenliğini garanti etmez. Güvenliği kurmak ve işletmek zorundasın.

6) Self-hosted AI’da mimari desenler: OpenAI API’ye en yakın kurulum

OpenAI API’ye benzer davranışı yakalamak için genellikle şu desenler kullanılır:

6.1 RAG (Retrieval-Augmented Generation) ile cevap kalitesini sabitleme

• Sadece “sohbet” yerine bilgi tabanından parçaları getirip modele verirsin.
• Böylece modelin “uydurma” eğilimi azalır.

Burada ana fark: RAG için indeksleme ve veri güncelliği senin sorumluluğunda.

6.2 Araç çağırma (tool calling) ve arka plan işleri

OpenAI tarafında araç çağırma akışları kolaydır. Self-hosted’de de: - Aracı tanımlayan bir “orchestrator” katmanı - İş kuyruğu (background job) ve idempotency - Hata durumunda geri alma

kurmalısın.

6.3 OpenAI-uyumlu istemci ile geçiş maliyetini düşürme

Eğer kodunu OpenAI formatında yazdıysan, self-hosted için OpenAI uyumlu endpoint kullanan bir servisle geçişi hızlandır.

Bunu yaparken şu iki noktayı karşılaştır: - Response formatı bire bir aynı mı? - Streaming ve hata kodları uyumlu mu?

Bu uyumsuzluklar projelerde “beklenmedik entegrasyon maliyeti” yaratır.

7) Net seçim kontrol listesi (kendi kararını 30 dakikada netleştir)

Aşağıdaki maddeleri “Evet/Hayır” şeklinde yanıtla:

1. Uygulama için günlük token tüketimi ve eşzamanlılık net ölçülebiliyor mu?
2. Ortalama prompt ve yanıt uzunluğu uzun metin mi, kısa metin mi?
3. Veri hassasiyeti nedeniyle veri işleme lokasyonunu kontrol etmem gerekiyor mu?
4. 24/7 çalışma hedefleniyor mu, yoksa kullanım saatleri sınırlı mı?
5. GPU donanımı için bütçe ve işletme takvimi var mı?
6. Rate limit, kimlik doğrulama, log maskeleme gibi güvenlik adımlarını uygulayacak ek var mı?
7. Model güncelleme ve rollback planım var mı?
8. RAG kullanacaksam indeksleme/yenileme otomasyonu kuracak mıyım?

Bu sorulara “Evet” sayısı artıyorsa self-hosted AI alternatifleri anlam kazanır. “Hayır” sayısı yüksekse OpenAI API veya hibrit yaklaşım (bazı işlemler API, bazıları local) daha doğru olur.

Sonuç: Aksiyon önerisiyle bitirelim

Önce kullanım profilini ölç (günlük token, ortalama prompt/cevap, eşzamanlılık). Ardından hedeflenen gecikme ve veri kontrol ihtiyacını netleştir. Self-hosted AI’ya geçeceksen tek hamlede “her şeyi kendi sunucuma alacağım” yaklaşımı yerine; OpenAI-uyumlu bir endpoint, temel güvenlik seti (kimlik doğrulama + rate limit), mümkünse RAG ve net bir izleme planıyla kademeli ilerle. En pratik aksiyon: 2 haftalık bir pilot çıkarıp maliyet/latency/hata oranı metriklerini kıyasla; kararını bu sayılara göre ver.