2026'da büyük bir dil modelinin kendi sunucunuzda barındırılması artık bir laboratuvar merakı değil. Çerçevelediğimiz projelerin artan bir kısmı için olgun, performanslı ve ekonomik olarak savunulabilir bir seçenek haline geldi. Mistral Large 2, Llama 3.3 70B, Qwen 2.5 72B veya DeepSeek V3 gibi açık modeller artık standart vakaların çoğunluğunda GPT-4 Turbo veya Claude 3.7 Sonnet performansının %90 ila %95'ine ulaşıyor: çıkarım, sınıflandırma, özet, yardımlı üretim, RAG. 2023'te yıkıcı olan bu kalite farkı, soru artık "yeterince iyi mi?" değil, "sektörümüz için doğru hakemlik nedir?" haline gelene kadar daraldı.

Bu makale, kendi sunucunuzda barındırılan LLM seçeneğini ciddi olarak değerlendiren CTO'lar, BT yöneticileri ve lead engineerlara hitap ediyor. Altı yapılandırıcı kararı detaylandırıyoruz: egemenlik kriterleri, model seçimi, GPU boyutlandırma, serving yığını, güvenlik ve gözlemlenebilirlik, FinOps. Mevcut pazarlama söylemine teslim olmadan, projelerimizde somut olarak gördüklerimize dayanıyoruz. Egemenlik "her ne pahasına olursa olsun her şey self-host" anlamına gelmez: soru, sınırın nereye yerleştirileceği ve hangi mühendislik şartlarıyla.

Bu soru 2026'da neden güçlü bir şekilde geri dönüyor

Üç güç bir araya geliyor. Öncelikle düzenlemeler sertleşiyor: tüm kişisel veriler için KVKK, sağlık sektörü için HDS, temel operatörler için NIS2, riskli sistemler için AI Act, büyük müşterilerin artık tedarikçilerine dayattığı özel sözleşmesel gereksinimleri saymadan. Bu maddelerin çoğu, Avrupa dışı bir AI API'sine transferi açıkça yasaklar veya üçüncü taraf bir API üzerinde garanti edilmesi imkansız tam izlenebilirlik gerektirir.

Ardından, open-weight ekosistemi geride kalmışlığını telafi etti. Mistral Large 2 (123B parametre), Llama 3.3 70B, Qwen 2.5 72B ve DeepSeek V3 (MoE'de 671B, ~37B aktif) bugün endüstriyel modellerdir. vLLM veya TensorRT-LLM gibi sunucular ve NVIDIA H100, A100 veya L40S, hatta AMD MI300X donanımı ile eşleştirildiğinde, istek başına saniyede 30 ila 80 token gerçek hız sağlarlar ve dinamik batching ile doğru boyutlandırılmış tek bir sunucuda yüzlerce eşzamanlı kullanıcıyı emerler.

1. Her şeyden önce egemenlik kriterlerini tanımlayın

En sık yapılan hata bir model seçmek ve sonra projeyi bir egemenlik söylemiyle giydirmektir. Titiz yaklaşım terstir: önce verilerin hassasiyetini, düzenleyici yükümlülükleri ve sözleşmesel taahhütleri nitelendirmek, sonra teknik sonuçları çıkarmak. Kimliklendirilebilir bir sağlık verisi HDS barındırma dayatır ve tüm AB dışı API'leri engeller. Savunma müşterisi tarafından sınıflandırılmış bir belge tam ağ bölümlendirmesi dayatır. Bir Ar-Ge ticari sırrı en azından aktarımda ve istirahatte şifreleme dayatır ve ideal olarak LLM operatörünün el atmadığı bir altyapı.

Denetimlerimizde sistematik olarak üç seviye ayırırız: kamuya açık veya banal veriler (tescilli API kabul edilebilir), iç gizli veriler (sıkı DPA ile Avrupa API'si veya egemen bulut self-host), hassas veya düzenlenmiş veriler (zorunlu self-host, ideal olarak on-prem veya SecNumCloud / HDS bulut). Bu ızgara ihtiyacı objektifleştirmeyi ve çoğu AI komitesini baltalayan "hep ya da hiç"ten kaçınmayı sağlar.

2. Uygun open-weight modeli seçin

Model seçimi dört kritere bağlıdır: vakalarınızdaki kalite, dile özgü kalite, boyut (dolayısıyla altyapı maliyeti) ve lisans. Mistral Large 2 zorlu Fransızca/Türkçe vakaları için referansımız olmaya devam ediyor: muhakeme kalitesi, talimat-takip, doğal üretim. Llama 3.3 70B mükemmel bir kalite/boyut oranı sunar ancak lisansı (Acceptable Use Policy) belirli kullanımlar için kısıtlayıcı kalır ve çok büyük platformları hariç tutar. Qwen 2.5 72B kod ve matematikte şaşırtıcı derecede güçlüdür. MoE'de DeepSeek V3, 37B aktif parametre sayesinde paradoksal olarak ılımlı bir serving maliyetiyle GPT-4'e yakın bir kalite sunar.

Yöntemimiz: MMLU veya Chatbot Arena gibi genel sıralamalara asla inanmıyoruz. Müşteri sektörünü temsil eden 50 ila 200 istemden oluşan bir iç benchmark inşa ediyoruz ve her aday modelde faithfulness, format, ton, gecikme ve maliyeti ölçüyoruz. Dürüstçe karar vermenin tek yolu budur.

  • Mistral Large 2 (123B): mükemmel Fransızca, net MRL lisansı, 2-4×H100 devreye alma
  • Llama 3.3 70B: en iyi kalite/boyut oranı, AUP'ye dikkat
  • Qwen 2.5 72B: kod ve muhakemede güçlü, kısmi Apache 2.0 lisansı
  • DeepSeek V3 (671B MoE): üst düzey kalite, boyuta rağmen makul serving maliyeti

3. GPU altyapısını boyutlandırın

Boyutlandırma sezgisel değildir. Üç değişken önemlidir: mevcut VRAM, hedef gecikme (kullanıcı başına ilk token süresi ve saniyede token) ve eşzamanlılık (eşzamanlı kullanıcılar). INT4'te kuantize edilmiş bir Llama 3.3 70B için POC'de tek bir H100 80GB yeterlidir ancak 5-10 eşzamanlı kullanıcının ötesinde hızla doyar. FP8'de iki H100 gereklidir. Üretimde Mistral Large 2 için yük profiline göre tipik olarak 2 ila 4×H100 veya bir 8×L40S düğümünden başlarız.

Altyapı tarafında iki seçenek hakim: doğrudan satın alma (1×H100 80GB KDV hariç 30 ila 40 bin €, 24-36 ay amortize edilebilir) veya Scaleway, OVHcloud, Lambda Labs veya RunPod'da bulut GPU kiralaması, sağlayıcı ve taahhüde göre saatte 2,5 ila 4 €. Avrupa bulut GPU'su, egemenlik ve esnekliği uzlaştırmaya çalışırken alakalı kalır, sağlayıcının gerçek yetki alanını ve gerektiğinde SecNumCloud durumunu doğrulamak koşuluyla.

4. Serving yığınını seçin

Dört seçenek pazarı yapılandırır. vLLM açık kaynak referansı haline geldi: PagedAttention, continuous batching, OpenAI uyumlu destek, devasa topluluk. Varsayılan seçimimiz. TGI (Hugging Face text-generation-inference) çok sağlam kalır, özellikle HF ekosistemine entegre, vLLM'den biraz daha az performanslı ancak üretimde çok olgun. NVIDIA'nın TensorRT-LLM'si NVIDIA donanımında en iyi ham performansı sunar, çok daha yüksek derleme ve bakım karmaşıklığı pahasına — yalnızca büyük ölçekte alakalıdır. NVIDIA NIM, kullanıma hazır konteynerize mikro hizmetlerle yönetilen on-prem bir yaklaşım sunar: iç ekibin kıdemli MLOps profili olmadığında ilginç, daha az esnek ve uzun vadede daha pahalı.

Birkaç yüz eşzamanlı kullanıcıya kadar projeler için, OpenAI uyumlu bir istemciyle uygulama tarafında bir reverse proxy (Traefik, NGINX) arkasındaki vLLM en basit, en performanslı ve en bakımı yapılabilir kombinasyondur. Kendi sunucumuzda barındırma projelerimizin çoğunluğunda devreye aldığımız budur.

5. Üretimde LLM'yi güvence altına alın ve gözlemleyin

Kendi sunucunuzda barındırılan bir LLM asla maruz bırakılacak basit bir API değildir. Potansiyel olarak hassas verileri manipüle eden ve yeni bir saldırı yüzeyi oluşturan kritik bir bileşendir. Sistematik olarak dört savunma hattı dayatıyoruz: sıkı ağ izolasyonu (özel VPC, doğrudan internet erişimi yok), güçlü uygulama kimlik doğrulaması (imzalı JWT'ler, rotasyon), istemlerin ve yanıtların kontrollü saklama ile tam loglaması ve iş koruma bariyerleri (giriş filtreleri, çıkış doğrulaması, prompt injection tespiti).

Teknik gözlemlenebilirlik de aynı derecede önemlidir: GPU izleme (kullanım, bellek, sıcaklık), serving metrikleri (TTFT, tokens/sec, kuyruk boyutu), uygulama izlenebilirliği (Langfuse, OpenLLMetry veya yerel çözüm). Bu telemetri olmadan, altyapınızın ne zaman doyacağını, bir modelin ne zaman saptığını veya bir kalite gerilemesinin nereden geldiğini bilemezsiniz.

6. FinOps: TCO'yu dürüstçe modelleyin

Finansal soru GPU fiyatına indirgenmez. Kendi sunucunuzda barındırılan bir LLM'nin gerçek TCO'su donanım amortismanını veya kiralamayı, on-prem ise elektrik ve soğutmayı, iç veya dış MLOps becerilerini, modellerin bakımını (open-weight'te 3-6 ayda bir güncelleme), gözlemlenebilirliği, güvenliği ve yükseltme aşamalarını entegre eder. Projelerimizde her zaman üç senaryo arasında 24 aylık karşılaştırma yaparız: saf tescilli API, hibrit (pik için API, tekrarlayan için self-host), tam self-host.

Göstergesel olarak: optimize edilmiş vLLM serving'de 1×H100 80GB üzerinde Mistral Large 2 istek başına yaklaşık 50 token/saniye ve batching'e göre toplu hızda 1500 ila 2500 token/saniye sunar. 30 tam günde, bu teorik olarak milyarlarca token'ın hacmini temsil eder, aynı hacimlerde ayda on binlerce avro ile sayılan eşdeğer bir API faturasıyla karşılaştırılır.

Kendi sunucunuzda barındırma projelerini başarısızlığa uğratan tuzaklar

Telafi denetimlerimizde dört tuzak geri dönüyor. Birincisi, gözlemlenebilirliği hafife almak: telemetri olmadan ekip körlemesine pilotlar ve her arıza bir felakete dönüşür. İkincisi, ağ güvenliğini ihmal etmek: çok fazla POC, vLLM endpoint'i açıkça maruz bırakılmış olarak üretime geçer. Üçüncüsü, modellerin güncellenmesinin tekrarlayan maliyetini unutmak: 2026 open-weight LLM'si 2027'de eskimiş olacak, yükseltme kadansı çerçevelemeden itibaren öngörülmelidir. Dördüncüsü, ekibi eğitmemek: self-host bir LLM klasik bir mikro hizmet gibi yönetilmez, MLOps ve ML engineering becerileri vazgeçilmezdir.

Bu teknik tuzaklara stratejik bir tuzak eklenir: egemenliği ve performansı karıştırmak. Kendi sunucunuzda barındırmak kötü bir kullanım senaryosunu iyi yapmaz. İş ihtiyacı kötü çerçevelenmişse, RAG ihmal edilmişse, değerlendirme yoksa, proje egemenlikle veya egemenliksiz başarısız olacaktır. Kendi sunucunuzda barındırma bir araçtır, amaç değildir.

Şimdi ne yapmalı?

Bir LLM'yi kendi sunucunuzda barındırmayı ciddi olarak değerlendiriyorsanız, ilk adım egemenlik ihtiyacınızı, hedef hacminizi ve kullanım senaryosunun kritikliğini dürüstçe nitelendirmektir. DevHighWay'de çerçevelemelerimizde tam olarak yaptığımız şey budur: sloganlarla değil, rakamlarla API, hibrit ve self-host arasında karar vermek.

  • Egemenlik proje çerçevelemesi için iletişime geçin (2 günlük atölye, karar verici çıktı)
  • Denetimimiz AI platformunuzun görünürlük boyutunu da kapsar
  • LLM yönetimini içeren paketler için tarifelerimize bakın

Bir LLM'yi kendi sunucunuzda barındırma bugün güvenilir bir seçenektir, bazen verilerinin kontrolünü elinde tutması gereken kuruluşlar için tek seçenektir. Ancak bu, böyle ele alınan ciddi bir mühendislik projesidir: net hedefler, benchmark edilmiş model, boyutlandırılmış altyapı, ipliği güvenlik ve gözlemlenebilirlik, belgelenmiş FinOps. Projelerimizde benimsediğimiz duruş tam olarak budur ve uzun ömürlü devreye almaları ilk üretim olayında ölen POC'lerden kalıcı olarak ayıran şey budur.