Kazanimlar:
- Yönetilen API, VPC ve on-prem barındırma arasındaki ödünleşimleri değerlendirebilme
- Veri egemenliği, hacim ve operasyonel kapasiteye göre barındırma kararı verebilme
- Toplam sahip olma maliyetini (TCO) tam kalemlerle hesaplayıp hibrit mimariyi tasarlayabilme
Bazı kurumlar için "veriyi bir sağlayıcıya göndermek" — ne kadar güvenli olursa olsun — kabul edilebilir değildir. Savunma sanayii, kamu, bankacılık ve bazı sağlık senaryolarında veri kurum sınırının dışına hiç çıkmamalıdır. Bu noktada gündeme kendi modelini barındırma gelir: açık ağırlık (open-weight) modeller, kendi bulut ağınızda (VPC) veya kendi sunucularınızda (on-prem) çalıştırma. Bu ünitede yönetilen API ile kendi barındırma arasındaki ödünleşimleri (tradeoff), ne zaman hangisinin mantıklı olduğunu ve toplam sahip olma maliyetini (TCO) öğreneceğiz.
Kavramlar
- Yönetilen API (managed API): Model sağlayıcının altyapısında çalışır; siz istek gönderir, yanıt alırsınız. Operasyon yükü minimum, ama veri sağlayıcıya gider.
- Açık ağırlık model (open-weight): Model parametreleri (ağırlıkları) indirilebilir; kendi donanımınızda çalıştırabilirsiniz. "Açık kaynak" ile aynı şey olması şart değil (lisans farklı olabilir).
- VPC barındırma (Virtual Private Cloud): Modeli kendi izole bulut ağınızda çalıştırma; veri sizin ağ sınırınızda kalır ama altyapı yine bulutta.
- On-prem (on-premises): Modeli tamamen kendi veri merkezinizdeki donanımda çalıştırma; en yüksek kontrol, en yüksek operasyon yükü.
Dikkat: "Kendi barındırma her zaman daha güvenli" bir yanılgıdır. Güvenlik, veriyi nerede tuttuğunuzdan çok, orayı ne kadar iyi yönettiğinize bağlıdır. Yamasız, kötü yapılandırılmış bir on-prem sunucu, olgun bir yönetilen API'den daha risklidir.
Karar Ekseni: Ne Zaman Hangisi?
Kararı üç soru yönlendirir:
- Veri egemenliği: Yasa veya sözleşme, verinin kurum/ülke dışına çıkmasını yasaklıyor mu? Evetse VPC/on-prem'e doğru itilirsiniz.
- Hacim ve maliyet: Kullanım çok yüksek ve öngörülebilir mi? Çok yüksek hacimde kendi barındırma birim maliyeti düşürebilir; düşük/düzensiz hacimde yönetilen API neredeyse her zaman ucuzdur.
- Operasyonel kapasite: GPU altyapısı, model güncelleme, ölçekleme ve güvenlik yamasını sürdürecek ekibiniz var mı? Yoksa kendi barındırma gizli bir maliyettir.
Ödünleşim Tablosu
Boyut
Yönetilen API
VPC
On-Prem (açık ağırlık)
Veri egemenliği
Sağlayıcıya güven
Yüksek (ağ sınırınızda)
En yüksek (hiç çıkmaz)
Operasyon yükü
Çok düşük
Orta
Yüksek
Başlangıç maliyeti
Düşük (kullandıkça öde)
Orta
Yüksek (donanım)
Ölçekleme
Otomatik
Yönetilir
Sizin sorumluluğunuz
Model kalitesi/güncelliği
En yeni, otomatik
Değişir
Siz güncellersiniz
Kontrol
Düşük
Yüksek
Tam
Adım Adım: Barındırma Kararı
- Veri sınıfını belirleyin. Hangi gizlilik seviyesindeki veri işlenecek?
- Yasal kısıtı doğrulayın. Veri dışarı çıkabilir mi? (KVKK, sektör düzenlemesi, sözleşme.)
- Hacmi tahmin edin. Aylık istek/token hacmi ve büyüme eğrisi.
- TCO hesaplayın. Yalnızca GPU değil; enerji, bakım, ekip, güvenlik, yedeklilik.
- Hibrit düşünün. Hassas veriyi on-prem/VPC'de, hassas olmayanı yönetilen API'de işleyen karma model çoğu zaman en dengelisidir.
Dört Kopyalanabilir Şablon
Barındırma karar promptu:
Şu kullanım için barındırma kararı ver: {{ senaryo }}Sorular:- İşlenecek verinin gizlilik sınıfı ne? (genel/iç/gizli/çok gizli)- Yasa/sözleşme veriyi kurum dışına çıkmaya izin veriyor mu?- Aylık hacim tahmini ve öngörülebilirliği?- Operasyon/GPU ekibi kapasitesi var mı?Öneri: "Yönetilen API / VPC / On-prem / Hibrit" + gerekçe.
TCO kalem listesi (kendi barındırma için):
Toplam sahip olma maliyetini şu kalemlerle hesapla:- Donanım (GPU) satın alma/kiralama- Enerji ve soğutma- İnsan: MLOps + güvenlik ekibi zamanı- Model güncelleme ve test iş gücü- Yedeklilik/felaket kurtarma- Güvenlik yaması ve izlemeBunu yönetilen API'nin aylık faturasıyla 12-24 ay ufkunda karşılaştır.
Hibrit yönlendirme kuralı:
Her isteği veri sınıfına göre yönlendir:- "gizli / çok gizli" veri -> on-prem/VPC model- "genel / iç" veri -> yönetilen API (daha güçlü/ucuz)Yönlendirme kararını ve veri sınıfını denetim loguna yaz.
Açık ağırlık güvenlik kontrol promptu:
Kendi barındırdığımız modeli değerlendir:- Lisans, ticari kullanıma ve bizim senaryomuza izin veriyor mu?- Model ağırlıkları güvenilir kaynaktan, bütünlük (hash) doğrulandı mı?- Sunucu yaması, ağ izolasyonu, erişim kontrolü kurulu mu?- İzleme ve loglama yönetilen API kadar olgun mu?Eksik her maddeyi "AÇIK" olarak işaretle.
Zayıf Prompt / Güçlü Prompt
Zayıf yaklaşım
Güçlü yaklaşım
"On-prem daha güvenli, hep onu kullan"
Veri egemenliği + hacim + kapasiteye göre karar
Yalnızca GPU maliyetine bakmak
Tam TCO (enerji, ekip, güncelleme, güvenlik)
Tek bir barındırma modeline kilitlenmek
Hibrit: veri sınıfına göre yönlendirme
Açık ağırlığı indirip doğrulamadan koşmak
Lisans + bütünlük + yama + izleme kontrolü
Üç Mini Vaka
Vaka 1 — On-prem zorunluluğu doğru karardı. Bir savunma yüklenicisi, gizlilik sınıfı yüksek belgeleri işleyecekti; sözleşme veriyi ülke dışına çıkarmayı yasaklıyordu. Yönetilen API baştan elendi. On-prem açık ağırlık model kuruldu; maliyet yüksekti ama tek uyumlu seçenekti.
Vaka 2 — Gizli TCO kararı tersine çevirdi. Bir startup, "API pahalı" diye kendi barındırmaya geçmeyi planladı. TCO hesabında yalnızca GPU'yu değil; 2 tam zamanlı MLOps mühendisini, güncelleme yükünü ve yedekliliği ekleyince 24 aylık toplam, yönetilen API'nin iki katına çıktı. Hacimleri düşük ve düzensiz olduğu için API'de kaldılar.
Vaka 3 — Hibrit en iyisini verdi. Bir bankanın çağrı merkezi asistanı iki tür veri işliyordu: genel ürün soruları ve müşteriye özel hesap verisi. Hesap verisi VPC içindeki modele, genel sorular güçlü yönetilen API'ye yönlendirildi. Hassas veri hiç dışarı çıkmadı, genel sorularda en güçlü modelin kalitesi kullanıldı; maliyet ve uyum birlikte optimize edildi.
İpucu: Karar ikili (ya hep ya hiç) olmak zorunda değil. Hibrit mimari — veriyi sınıfına göre yönlendirmek — çoğu kurumsal senaryoda hem uyumu hem maliyeti aynı anda çözer.
Sık yapılan hatalar
- "Kendi barındırma otomatik daha güvenli" varsaymak; oysa güvenlik yönetim kalitesine bağlıdır.
- TCO'yu yalnızca GPU maliyeti sanmak; ekip, enerji, güncelleme ve güvenliği unutmak.
- Düşük/düzensiz hacimde kendi barındırmaya geçip birim maliyeti yükseltmek.
- Açık ağırlık modeli lisans ve bütünlük (hash) doğrulaması yapmadan kullanmak.
- On-prem sunucuya yönetilen API kadar olgun izleme/loglama kurmamak.
- Hibrit seçeneği hiç değerlendirmeden ikili karar vermek.
Özetle
- Yönetilen API operasyonel olarak en kolayıdır ama veri sağlayıcıya gider; VPC/on-prem veriyi sizin sınırınızda tutar.
- Kararı üç soru yönlendirir: veri egemenliği, hacim/maliyet öngörülebilirliği ve operasyonel kapasite.
- "Kendi barındırma daha güvenli" bir yanılgıdır; güvenlik veriyi nerede tuttuğunuza değil, ne kadar iyi yönettiğinize bağlıdır.
- TCO'yu tam hesaplayın: GPU'nun yanında enerji, ekip, güncelleme, yedeklilik ve güvenlik.
- Hibrit mimari (veriyi sınıfına göre yönlendirme) çoğu kurumsal senaryoda uyum ve maliyeti aynı anda dengeler.
Uygulama görevi
Bir AI kullanımınızı seçin ve işlenecek veriyi gizlilik sınıfına ayırın. Barındırma karar promptuyla bir öneri üretin. Ardından kendi barındırma için TCO kalem listesini doldurup 24 aylık toplamı yönetilen API faturasıyla karşılaştırın. Son olarak bir hibrit yönlendirme kuralı taslağı yazın: hangi veri nereye gider?
Kontrol listesi
- [ ] İşlenecek verinin gizlilik sınıfını ve yasal kısıtını belirledim.
- [ ] Barındırma kararını egemenlik + hacim + kapasiteye göre verdim.
- [ ] TCO'yu tam kalemlerle (GPU dışı dahil) hesapladım.
- [ ] Kendi barındırmada lisans, bütünlük, yama ve izlemeyi kontrol ettim.
- [ ] Hibrit yönlendirme seçeneğini değerlendirdim.
- [ ] Kararı ve gerekçesini belgeledim.