Kendi sunucunuzda LLM mi, bulut API mi

Kendi sunucunuzda LLM çalıştırmakla bulut API kullanmak arasındaki seçim bir teknoloji tercihi değil, bir risk ve maliyet tercihidir. Bulut API en güçlü modelleri sıfır bakım yüküyle verir; Türkiye’deki donanımda çalışan bir on-prem kurulum ise veriyi yurt dışına hiç çıkarmaz ve böylece KVKK’nın yurt dışına aktarım rejimini baştan devre dışı bırakır. Pratikte kararı belirleyen soru tek: bu veri yurt dışına çıkabilir mi, çıkamaz mı? Gerisi tablo işi.

İki mimari, iki farklı risk profili

On-premise (self-hosted) LLM, model ağırlıklarının sizin kontrolünüzdeki donanımda durması ve çıkarımın (inference) sizin ağınızın içinde yapılması demektir. Prompt da, cevap da ağ sınırınızı hiç geçmez. Donanım kendi veri merkezinizde, bir colocation kabininde ya da kiraladığınız ayrılmış bir GPU sunucuda olabilir — son durumda “on-prem” kelimesi teknik olarak yanlış ama asıl soru aynen yerinde durur: makine fiziksel olarak nerede? Çünkü hukuki tetikleyici verinin kurum ağından çıkması değil, yurt dışına çıkmasıdır. Yurt dışındaki bir kabinde self-host etmek, veri egemenliği açısından size bulut API’den daha az koruma sağlamaz ama KVKK aktarım rejiminden de kurtarmaz.

Bulut API, prompt’un HTTPS üzerinden sağlayıcının veri merkezine gitmesi ve orada işlenmesidir. Model sizde değil, erişim sizde. Ağırlıklar kapalı, sürüm takvimi sağlayıcının, fiyat listesi sağlayıcının.

İkisi de meşru mimarilerdir. Yanlış olan, birini ideolojik gerekçeyle seçip sonuçlarını görmezden gelmektir.

Karşılaştırma tablosu

Boyut	Kendi sunucunuzda (on-prem / self-hosted)	Bulut API (OpenAI, Anthropic vb.)
Veri gizliliği / egemenlik	Veri ağ sınırını geçmez. Sözleşmeye değil, topolojiye güvenirsiniz. Denetimde “veri şu makinede” diyebilirsiniz	Veri sağlayıcıya gider. Koruma sözleşmeseldir: OpenAI API girdilerini kötüye kullanım denetimi için varsayılan olarak 30 güne kadar tutar, Anthropic API girdi/çıktılarını 30 gün içinde siler; uygun kullanım senaryolarında sıfır veri saklama (ZDR) anlaşması yapılabilir
Maliyet modeli	Sabit gider: GPU yatırımı veya aylık sunucu kirası + elektrik + mühendislik. Kullanım artınca birim maliyet düşer, boşta beklerken de ödersiniz	Değişken gider: token başına. Sıfır kullanım = sıfır fatura. Hacim büyüdükçe fatura doğrusal büyür
Gecikme	Ağ turu yok; yurt dışı veri merkezine gidiş-dönüş ortadan kalkar. Ama küçük bir GPU, sağlayıcının optimize edilmiş altyapısından token başına daha yavaş üretebilir	İlk token gecikmesinde coğrafi mesafe bedeli var; buna karşılık üretim hızı çok yüksek ve tutarlı
Ölçeklenme	Eş zamanlı kullanıcı sayısı donanımla sınırlı. Yeni kapasite = yeni kart, tedarik süresi haftalar. Ani yük patlaması sıraya girer	Elastik. Sağlayıcının kota ve rate limit’leri içinde anında ölçeklenir
Bakım yükü	Size ait: sürücü, CUDA, servis katmanı (vLLM/TGI/Ollama), model güncellemesi, izleme, yedeklilik. En az bir kişinin işinin parçası olmalı	Sağlayıcıya ait. Sizin işiniz sürüm sabitleme ve API sözleşmesindeki değişiklikleri takip etmek
Model kalitesi	Açık ağırlıklı modeller son yıllarda hızla kapattı, ama en zor akıl yürütme ve uzun bağlam işlerinde sınır modelleri hâlâ önde. Kendi verinizle ince ayar yapma ve modeli dondurma serbestliği sizde	En güçlü modellere anında erişim. Buna karşılık model sizin altınızdan güncellenebilir; davranış sessizce değişebilir
Uyum (KVKK)	Donanım Türkiye’deyse kişisel veri yurt dışına çıkmaz, dolayısıyla 6698 sayılı Kanun’un 9. maddesi hiç devreye girmez. Veri sorumlusu yükümlülükleriniz elbette sürer	Yurt dışına aktarımdır. 7499 sayılı Kanun’la değişen m.9 üç kademe kurar: yeterlilik kararı → uygun güvenceler → arızi haller. Bu yazının yayım tarihi itibarıyla Kurul herhangi bir yeterlilik kararı yayımlamadığından pratik yol standart sözleşmedir; imzalar tamamlandıktan sonra beş iş günü içinde Kuruma bildirilmesi zorunludur

Donanım: gerçekçi beklenti

Bu alandaki abartıyı kesmenin en kolay yolu, aritmetiği yapmaktır. VRAM ihtiyacının ana bileşeni model ağırlıklarıdır ve hesabı basittir: parametre sayısı × parametre başına bayt.

FP16/BF16 → parametre başına 2 bayt
8-bit → ~1 bayt
4-bit → ~0,5 bayt (kuantizasyon ölçek/sıfır noktası tabloları biraz üstüne biner)

Buradan çıkan tablo:

Model boyutu	FP16 ağırlık	4-bit ağırlık	Pratikte gereken kart
~8B	~16 GB	~4-5 GB	4-bit: 8-12 GB’lık tek tüketici kartı yeter
~70B	~140 GB	~35-40 GB	4-bit: tek 48 GB (ör. L40S) sığdırılabilir; FP16 için 2×80 GB gerekir

Ağırlıklar hikâyenin tamamı değil. Üstüne KV cache, aktivasyonlar ve servis katmanı ek yükü biner; KV cache eş zamanlı istek sayısı ve bağlam uzunluğuyla birlikte büyür. Yani “model kartına sığdı” ile “20 kişi aynı anda uzun belgelerle çalışabiliyor” arasında ciddi mesafe vardır. Kapasite planını parametre sayısına değil, eş zamanlılık × bağlam uzunluğuna göre yapın.

Dürüst olalım: kuantizasyon bedava değildir. 4-bit, ağırlıkları küçültürken çıktı kalitesinde ölçülebilir bir kayba yol açabilir; kaybın büyüklüğü modele ve göreve göre değişir, tahminle değil kendi değerlendirme setinizle ölçülür.

Ne zaman on-prem

Veri kategorisi yurt dışına çıkamıyorsa: sağlık kayıtları, hukuk dosyaları, personel özlük dosyaları, savunma sanayi, henüz açıklanmamış finansal veri
Yurt dışına aktarım için standart sözleşme + bildirim yükünü taşımak istemiyor ya da taşıyamıyorsanız
Kullanım hacminiz yüksek, öngörülebilir ve sürekliyse — sabit gider modeli burada lehinize döner
Modelin davranışını dondurmanız gerekiyorsa: yarın sürüm değişince çıktınız değişmesin
İş yükü dar ve tekrarlı ise: sınıflandırma, bilgi çıkarma, özetleme. Küçük bir açık model, ince ayarla bu işlerde fazlasıyla yeterlidir

Ne zaman bulut API

Henüz doğrulama aşamasındaysanız. Fikir tutmadan GPU almak, en pahalı öğrenme yöntemidir
İşiniz sınır seviyesinde akıl yürütme, çok adımlı ajan davranışı ya da çok uzun bağlam istiyorsa
Hacim düşük veya dalgalıysa
Kurum içinde LLM servisi işletecek mühendislik kapasitesi yoksa — ve bunu dürüstçe kabul etmek erdemdir
Veri zaten kişisel veri değilse: kamuya açık içerik, ürün kataloğu, anonimleştirilmiş metin

Melez kurulum: çoğu kurumun gerçek cevabı

Soru çoğu zaman “hangisi” değil, “hangi veri hangisine” biçiminde sorulmalıdır. Pratikte işleyen desen şudur: hassas iş yükü kurum içindeki açık ağırlıklı modele, hassas olmayan ya da yüksek akıl yürütme isteyen iş yükü bulut API’ye yönlenir. Yönlendirme kararını uygulama katmanında, veri sınıflandırmasına bakan bir kural verir. Kurduğumuz RAG mimarilerinde bu ayrım özellikle temiz kurulur: belge indeksi ve gömme (embedding) üretimi kurum içinde kalır, yalnızca gerektiğinde ve maskelenmiş biçimde dışarı çıkılır.

Karar için üç soru

Bu veri yurt dışına çıkabilir mi? Hayırsa tartışma bitti — Türkiye’deki donanımda on-prem.
Aylık token hacminiz öngörülebilir mi? Hayırsa API ile başlayın, ölçün, sonra karar verin.
Bu sistemi altı ay sonra kim ayakta tutacak? İsim veremiyorsanız on-prem’e girmeyin.

Albatros olarak nasıl yardımcı oluruz

Veri egemenliği bizim için bir pazarlama başlığı değil, hizmet kalemi: açık kaynaklı ya da kapalı modelleri müşterinin kendi sunucusunda çalıştırıyor, gerektiğinde bulut API’lerle melez kurgular tasarlıyoruz. Önce veri sınıflandırmanıza ve gerçek hacminize bakar, donanım kararını ondan sonra veririz — çünkü tersini yapmak pahalıya patlıyor. Konuşmak isterseniz: iletişim ya da [email protected].