2026'da LLM'i şirket içinde dağıtma: mimari, yığın, maliyet

Bir LLM'i 2026'da şirket içinde dağıtmak için açık ağırlıklı bir modeli NVIDIA GPU sunucularında çalıştırın, vLLM, TensorRT-LLM veya NVIDIA NIM ile sunun ve uygulamalara yalnızca SSO, kotalar ve denetim kaydını (audit logging) zorunlu kılan OpenAI uyumlu bir ağ geçidi üzerinden erişim verin. Şirket bilgisi için bir vektör veritabanıyla bir RAG katmanı ekleyin ve güvenlik sınırlarını (guardrails), değerlendirmeyi ve gözlemlenebilirliği ilk sürüme dahil edin. Platformu, 3 ila 5 yıla yayılan GPU yatırım maliyeti (capex) artı güç, destek ve personel işletim maliyeti (opex) olarak bütçeleyin ve GPU'ları yalnızca ağırlıklara göre değil, ağırlıklar artı KV önbelleğine göre boyutlandırın.

Şirket içinin buluta üstün geldiği durumlar

Bulut API'leri, düşük, dalgalı veya keşif amaçlı kullanım için doğru varsayılan olmayı sürdürür. Aşağıdaki dört koşuldan en az biri geçerliyse şirket içi kazanır.

Veri egemenliği. İstemler, alınan belgeler ve model çıktıları ağınızdan asla çıkmaz, dolayısıyla müzakere edilecek bir tedarikçi veri işleme sözleşmesi ve savunulacak bir sınır ötesi aktarım analizi yoktur.

İstikrarlı yüksek hacim. Sahip olunan GPU'lar sabit bir aylık maliyettir, dolayısıyla kullanım arttıkça token başına maliyet düşer; sürekli yük genellikle fiyatta ölçülü (metered) API'leri geride bırakır, boşta duran bir platform bırakmaz. Hesaplama kendi GPU'larınız vs bulut API'si token başına maliyet yazısındadır.

Gecikme. İnternet gidiş-dönüşünü kaldırmak ve modeli çağırdığı sistemlerin yanına yerleştirmek, öngörülebilir p99 gecikmesi sağlar; bu, görev başına birçok ardışık çağrı yapan ajanlar için en çok önem taşır.

Düzenleme. AB Yapay Zeka Yasası, GDPR, KVKK ve bankacılık, sağlık ve savunma için sektörel kurallar, denetçilerinizin uçtan uca inceleyebileceği bir altyapıda, belirli bir yargı alanında işleme gerektirebilir. Bkz. AB Yapay Zeka Yasası, GDPR ve KVKK kontrol listesi.

Önemli çıkarım: veri, hacim, gecikme veya düzenleme gerektirdiğinde şirket içini seçin; aksi halde buluttan başlayın ve ilk günden itibaren OpenAI uyumlu bir API üzerine inşa ederek seçeneği açık tutun. Birçok kurum hibrit bir yapıda karar kılar: düzenlemeye tabi iş yükleri şirket içinde, patlama trafiği ise bulutta.

Referans mimari

2026 itibarıyla üretim düzeyinde bir şirket içi LLM platformunun altı katmanı vardır; her biri değiştirilebilir, ancak katmanlama atlanmamalıdır.

• GPU sunucuları. 4 veya 8 NVIDIA GPU'lu düğümler: H100 (80 GB HBM3, 3.35 TB/s, 700 W), H200 (141 GB HBM3e, 4.8 TB/s), B200 (~180 GB HBM3e, ~8 TB/s, ~1000 W) veya daha küçük modeller için RTX PRO 6000 (96 GB GDDR7). Bir düğüm içinde NVLink; yalnızca bir model düğümler arasına yayıldığında InfiniBand veya RoCE.
• Platform. Linux, NVIDIA sürücüsü, CUDA, konteyner araç seti ve NVIDIA GPU Operator ile Kubernetes; model önbelleği için yerel NVMe, kayıt defteri ve RAG derlemi için paylaşımlı depolama.
• Sunum katmanı. Tensor paralelliği, sürekli gruplama (continuous batching) ve sayfalanmış KV önbelleğine sahip, model başına bir tane olacak şekilde vLLM, TensorRT-LLM veya NIM konteynerleri. Hopper ve Blackwell üzerinde FP8, FP16'ya kıyasla belleği kabaca yarıya indirir ve az kalite kaybına yol açar.
• OpenAI uyumlu ağ geçidi. Uygulamaların çağırabileceği tek uç nokta. SSO'yu (OIDC) sonlandırır, servis anahtarları çıkarır, takım başına kotaları zorunlu kılar, modeller arasında yönlendirir, kişisel verileri (PII) maskeler ve her istek ile yanıtı denetim deposuna yazar.
• RAG ve vektör veritabanı. İçe aktarma, parçalama (chunking), bir gömme (embedding) modeli, bir vektör veritabanı ve bir yeniden sıralayıcı (reranker); belge izinleri kaynak sistemden kopyalanır ve sorgu anında zorunlu kılınır.
• Uygulamalar ve ajanlar. Modeli SAP, Salesforce, Microsoft 365 veya Snowflake'e bağlayan sohbet arayüzleri, kopilotlar, iş akışı otomasyonları ve MCP sunucuları.

Yığının yanında SSO ve RBAC, SIEM'inize gönderilen değişmez denetim kayıtları, girdi ve çıktı güvenlik sınırları ve GPU sağlığı, saniyedeki token sayısı, ilk token'a kadar geçen süre ve kuyruk derinliği için gözlemlenebilirlik bulunur. Önemli çıkarım: uygulamalar asla doğrudan sunum katmanıyla konuşmaz; güvenlik, maliyet atfı ve denetlenebilirlik ağ geçidinde yaşar.

Katmana göre yazılım yığını

Önemli çıkarım: katman başına bir seçenek belirleyin, sürümünü sabitleyin ve nedenini yazın; 2026'da disiplin, yenilikten daha önemlidir. Ayrıntılı bir sunum karşılaştırması vLLM vs TensorRT-LLM vs Ollama vs SGLang yazısındadır.

Adım adım dağıtım planı

1. İş yükünü tanımlayın. Kullanım senaryoları, eşzamanlı kullanıcılar, dakika başına zirve istek sayısı, bağlam uzunluğu ve gecikme hedefleri. İki veya üç modeli kısa listeye alın ve lisans koşullarını kaydedin.
2. GPU'ları boyutlandırın. Bellek ihtiyacı ağırlıklar artı KV önbelleği artı çalışma zamanı ek yüküdür: 70B bir model FP16'da yaklaşık 140 GB, FP8'de 70 GB ve INT4'te ~38 GB'tır, artı KV önbelleği için yüzde 20 ila 50. Nanobase AI'ın boyutlandırma incelemelerinde en sık atlanan kalem KV önbelleğidir. Boyutlandırma tabloları 70B, 405B ve DeepSeek R1 için kaç GPU yazısındadır.
3. Tesisi tedarik edin ve hazırlayın. Sipariş vermeden önce rack alanını, gücü (yük altında 8 GPU'lu bir H100 sunucusu yaklaşık 10 kW çeker), soğutmayı ve ağı doğrulayın. Sunucu teslim süreleri genellikle plandaki en uzun kalemdir.
4. Platformu kurun. İşletim sistemi, sürücüler, konteyner araç seti, Kubernetes ve GPU Operator; ardından herhangi bir model donanıma dokunmadan önce yanma testi (burn-in) ve DCGM tanılamaları.
5. Sunum katmanını devreye alın. Bir modeli dağıtın, desteklendiği yerde FP8'i etkinleştirin ve 1. adımın hedeflerine göre kıyaslayın. Minimal bir tek düğümlü vLLM başlangıcı:

   docker run --gpus all --ipc=host -p 8000:8000 \
     -v /models:/models \
     vllm/vllm-openai:latest \
     --model /models/your-70b-instruct \
     --tensor-parallel-size 4 \
     --quantization fp8 \
     --max-model-len 32768 \
     --served-model-name llm-70b

1. Ağ geçidini devreye alın. SSO'ya bağlayın, uygulama başına servis anahtarları oluşturun, kotalar belirleyin ve istek günlüklemesini etkinleştirin. Bu noktadan sonra hiçbir uygulama doğrudan sunum katmanını çağırmaz.
2. RAG'ı inşa edin. Yüksek değerli tek bir derlemle başlayın ve kaynak eklemeden önce etiketli bir soru setinde erişim kalitesini ölçün.
3. Güvenliği sağlamlaştırın. GPU düğümleri için ağ bölümlemesi, bir kasada (vault) saklanan sırlar, güvenlik sınırları, PII maskeleme, SIEM'e denetim kayıtları ve yazılı bir saklama politikası.
4. Değerlendirin. Altın veri seti, zirve eşzamanlılıkta yük testi ve bir kırmızı takım (red-team) turu; canlıya geçmeden önce her bulguyu düzeltin veya resmi olarak kabul edin.
5. Canlıya geçin ve işletin. Önce pilot grup, önceki model sürümüne dönüş yolu ve yama uygulama, model güncellemeleri, kapasite incelemesi ve olaylar için çalışma kılavuzlarına sahip belirlenmiş bir sahip.

Önemli çıkarım: sunum katmanı en kolay kısımdır; dağıtımların başarılı olduğu veya tıkandığı yer ağ geçidi, RAG kalitesi ve operasyonlardır.

Maliyet yapısı: capex, opex ve amortisman

Tablo, tedarikçi teklifleri değiştiği için toplamlar yerine maliyet bileşenlerini listeler; bölgeniz ve yapılandırmanız için güncel fiyatlandırmayı doğrulayın.

Hızla bir sonraki GPU neslini bekliyorsanız capex'i 3 yıla, iş yükü yalnızca çıkarım ve istikrarlıysa 5 yıla yayarak amortisman uygulayın. Aylık platform maliyeti, capex'in amortisman ayına bölünmüş hali artı aylık opex'tir; aylık token sayısına bölmek token başına maliyeti verir.

Kullanım oranı en büyük kaldıraçtır: aylık maliyet neredeyse sabit olduğundan, aynı donanım yüzde 20 kullanım oranında, yüzde 60'a göre token başına yaklaşık üç kat daha fazlaya mal olur. Önemli çıkarım: platformu sabit bir aylık maliyet olarak modelleyin ve kullanım oranını değişken olarak ele alın; zirve için değil sürekli yük için satın alın ve boşta kapasiteyi düşük yoğunluklu dönem toplu işleriyle doldurun.

İzole ağ (air-gapped) dağıtımlar

İzole ağ siteleri (savunma, kritik altyapı, bazı bankalar) internete hiçbir yolu olmayan aynı mimariyi çalıştırır. Farklar prosedüreldir.

• Çevrimdışı paketler. Ağırlıklar, konteyner görüntüleri ve Helm şemaları, bağlı bir hazırlık ağında indirilir, özetlenir (hash), imzalanır ve onaylı bir ortam aracılığıyla özel kayıt defterine taşınır.
• Özel kayıt defteri ve aynalar. Konteynerler için Harbor, yerel bir model deposu ve işletim sistemi ile Python paketlerinin bir aynası; NIM konteynerleri önceden doldurulmuş yerel bir model önbelleğinden çalışabilir.
• Lisanslama ve telemetri. Satın almadan önce NVIDIA AI Enterprise için çevrimdışı etkinleştirmeyi doğrulayın; her bileşende kullanım raporlamasını devre dışı bırakın ve çıkış (egress) izlemesiyle doğrulayın.
• Değişiklik kontrolü. Güncellemeler, hızlı bir yama yolu olmadığından tam bir değerlendirme çalıştırmasıyla planlı bir ritmi izler.
• Dahili PKI ve zaman. Dahili bir CA ve dahili NTP; ikisi de başarısız çevrimdışı kurulumların yaygın nedenleridir.

Önemli çıkarım: önce tam yığını bağlı bir hazırlık kopyası üzerinde inşa edin ve test edin, ardından imzalı eserleri (artifact) aktarın; izole ağın içinde asla ilk kez hata ayıklama yapmayın.

Yaygın hatalar

1. Yalnızca ağırlıklara göre boyutlandırma. KV önbelleği ve eşzamanlılık, 70B bir FP16 modelini iki H100'ün ötesine iter; pay bırakarak bütçeleyin.
2. Kıyaslamadan önce satın almak. Aday modeli önce kiralık GPU'larda çalıştırın, ardından sipariş verin.
3. Uygulamaların doğrudan vLLM'i çağırması. Kimlik doğrulama yok, denetim izi yok, her uygulamaya dokunmadan model değiştirme yolu yok.
4. RAG'ı bir haftalık bir görev olarak ele almak. Parçalama, izinler ve erişim değerlendirmesi, model dağıtımından daha uzun sürer.
5. Yüksek erişilebilirlik olmaması. Tek modelli tek bir düğüm bir demodur; üretim için en az iki kopya planlayın.
6. Model lisanslarını görmezden gelmek. Açık ağırlıkların tümü Apache 2.0 değildir; model başına ticari kullanım ve atıf koşullarını kontrol edin.
7. Canlıya geçtikten sonra sahip olmaması. Pilot bitmeden önce bir ekip, bir nöbet rotasyonu ve model güncellemeleri için bir bütçe atayın.

Önemli çıkarım: çoğu başarısız şirket içi proje modelde değil, boyutlandırma, güvenlik veya sahiplikte başarısız olur.

Sıkça sorulan sorular

70B bir modeli şirket içinde çalıştırmak için kaç GPU'ya ihtiyacım var?

Bellekten başlayın: 70B bir model FP16'da yaklaşık 140 GB, FP8'de 70 GB veya INT4'te ~38 GB gerektirir, artı KV önbelleği için yüzde 20 ila 50. FP8'de bu, bağlam için yer bırakarak iki H100 80 GB GPU'ya veya bir H200 141 GB'a sığar. Uzun bağlamlı ve çok sayıda eşzamanlı kullanıcılı FP16 için, kopya başına dört H100 pratik asgaridir.

vLLM, TensorRT-LLM veya NVIDIA NIM mi kullanmalıyım?

Geniş model kapsamı, yeni mimarilerin hızlı benimsenmesi ve tamamen açık kaynaklı bir yığın için vLLM kullanın. Sabit modeller için, NVIDIA GPU'larında GPU başına en yüksek verimi istediğinizde TensorRT-LLM kullanın. NVIDIA AI Enterprise altında NVIDIA tarafından paketlenmiş, desteklenen konteynerler için NIM kullanın. Üçü de OpenAI uyumlu API'ler sunar, dolayısıyla ağ geçidi tasarımı aynı kalır.

Kubernetes olmadan şirket içi bir LLM dağıtabilir miyim?

Evet. vLLM, bir ağ geçidi, bir vektör veritabanı ve izleme çalıştıran Docker Compose'lu tek bir GPU sunucusu, mütevazı trafikli bir veya iki model için geçerli bir üretim kurulumudur. GPU Operator'lı Kubernetes, birkaç model çalıştırdığınızda, düğümler arasında kesintisiz güncellemeler ve otomatik ölçeklendirmeye ihtiyaç duyduğunuzda veya zaten başka bir yerde Kubernetes işlettiğinizde değerli hale gelir.

Şirket içi LLM dağıtımı bulut API'lerinden daha mı ucuz?

Neredeyse tamamen sürekli kullanım oranına bağlıdır. Sahip olunan GPU'lar sabit bir aylık maliyettir, dolayısıyla kullanım arttıkça token başına maliyet düşer, ölçülü API'ler ise doğrusal olarak ölçeklenir. Yüksek, istikrarlı günlük hacim şirket içini, düşük veya dalgalı kullanım ise bulutu destekler. Karar vermeden önce her ikisini de kendi token hacimlerinizle hesaplayın ve güncel donanım ile API fiyatlandırmasını doğrulayın.

NVIDIA AI Enterprise lisanslarına ihtiyacım var mı?

Yalnızca NVIDIA NIM kullanıyorsanız veya NVIDIA destekli konteynerler, sürücüler ve destek SLA'ları istiyorsanız. vLLM, TensorRT-LLM, GPU Operator ve DCGM açık kaynaktır veya ücretsiz kullanılabilir ve lisanssız çalışır. Birçok kurum bir entegrasyon ortağının desteğiyle açık kaynaklı sunum işletir; diğerleri denetim nedenleriyle NVIDIA destekli yolu tercih eder. Güncel koşulları NVIDIA ile doğrulayın.

İzole ağ ortamında modelleri nasıl güncellerim?

Yeni modeli bağlı bir hazırlık kopyası üzerinde indirin ve değerlendirin, özetini (hash) ve lisansını kaydedin, paketi imzalayın ve onaylı bir ortam aracılığıyla özel kayıt defterine aktarın. Aynı değerlendirme paketini izole ağın içinde çalıştırın, yeni sürümü ağ geçidi üzerinden eskisinin yanına dağıtın, trafiği kademeli olarak kaydırın ve geri dönüş için önceki sürümü saklayın.

Nanobase AI nasıl yardımcı olabilir

Nanobase AI, şirket içi LLM platformlarını uçtan uca tasarlar, kurar ve işletir: H100, H200, B200 ve RTX PRO sistemleri için GPU boyutlandırma ve tedarik desteği; Kubernetes, GPU Operator, MIG ve InfiniBand ile kurulum; vLLM, TensorRT-LLM veya NIM ile sunum; SSO ve denetim kaydına sahip OpenAI uyumlu bir ağ geçidi; RAG ve ince ayar; güvenlik sınırları, gözlemlenebilirlik ve AB Yapay Zeka Yasası, GDPR ve KVKK için uyumluluk eşlemesi; ve gerektiğinde izole ağ (air-gapped) teslimatı. Silikon Vadisi merkezliyiz ve NVIDIA Inception Programı'nın bir üyesiyiz. Bir referans dağıtımın çalıştığını görmek için çözümlerimize göz atın veya bir canlı demo rezervasyonu yapın.

Projenizi görüşmeye hazır mısınız? Nanobase AI ile iletişime geçin veya hello@bumu.tech adresine e-posta gönderin.