Şirket içi LLM, büyük dil modelinin bulut API’si yerine kurumun kendi sunucularında ya da özel veri merkezinde çalıştırılmasıdır. Bu yazıda, verisini yurt dışındaki bir servise gönderemeyen kurumların Ollama ve vLLM ile nasıl bir altyapı kurabileceğini, ne kadar donanım gerektiğini ve Kubernetes üzerinde nasıl ölçekleneceğini anlatıyoruz. Hedef okur; banka, sigorta, sağlık ve kamu projelerinde çalışan BT yöneticileri, DevOps ekipleri ve yazılım mimarlarıdır.
Kurumlar neden modeli kendi sunucusunda çalıştırmak istiyor?
Asıl sebep veridir. Çalışanların sözleşme, müşteri kaydı ya da kaynak kod içeren bir soruyu herkese açık bir yapay zeka servisine yapıştırması, verinin kurum dışına çıkması anlamına gelir. Bu davranışın kurumlarda ne kadar yaygın olduğunu shadow AI yazımızda ayrıntılı olarak ele almıştık.
KVKK tarafında da tablo nettir. Haziran 2024’te yürürlüğe giren değişiklikle yurt dışına veri aktarımı; yeterlilik kararı, standart sözleşme veya bağlayıcı şirket kuralları gibi uygun güvencelere bağlandı. Standart sözleşmenin imzadan sonra beş iş günü içinde Kurula bildirilmesi gerekiyor. Her yapay zeka kullanımı için bu süreci işletmek, özellikle çok sayıda departmanı olan kurumlarda pratik değil. Hangi kurumların bu yükümlülüklerle doğrudan muhatap olduğunu merak ediyorsanız KVKK kimler için zorunludur yazısına göz atabilirsiniz.
Bankacılık gibi düzenlenmiş sektörlerde ek kurallar da devreye giriyor. Bankaların birincil ve ikincil bilgi sistemlerini yurt içinde tutma yükümlülüğü, bulut tabanlı dil modellerinin kullanımını ciddi biçimde sınırlıyor. Model kurum içinde çalıştığında veri, mevcut güvenlik ve denetim sınırlarının içinde kalır.
Ollama mı vLLM mi: hangi araç hangi iş için?
İki araç aynı işi yapıyor gibi görünse de farklı ihtiyaçlara göre tasarlanmıştır. Ollama, bir modeli tek komutla indirip çalıştırmayı kolaylaştırır ve dizüstü bilgisayardan tek GPU’lu sunucuya kadar geniş bir yelpazede sorunsuz çalışır. vLLM ise aynı anda çok sayıda kullanıcıya hizmet vermek için geliştirilmiş bir çıkarım (inference) motorudur.
| Kriter | Ollama | vLLM |
|---|---|---|
| Kurulum kolaylığı | Çok kolay, tek komut | Orta, Python ve GPU sürücü bilgisi gerekir |
| Eş zamanlı kullanıcı | Düşük ve orta yük | Yüksek yük, sürekli toplu işleme (continuous batching) |
| Bellek yönetimi | Standart | PagedAttention ile verimli KV önbellek |
| API | OpenAI uyumlu uç nokta | OpenAI uyumlu uç nokta |
| Uygun senaryo | Pilot, departman içi asistan, geliştirici makinesi | Kurum geneli servis, yüzlerce kullanıcı |
Pratikte birçok ekip pilot aşamasına Ollama ile başlıyor, kullanım büyüdüğünde vLLM’e geçiyor. İkisi de OpenAI uyumlu API sunduğu için uygulama kodunu değiştirmeden sadece uç nokta adresini güncellemek çoğu zaman yeterli oluyor.
Donanım ve GPU planlaması nasıl yapılır?
Doğru boyutlandırma, projenin bütçesini belirleyen ilk karardır. Kaba bir hesapla 7 ile 8 milyar parametreli bir model 16 bit hassasiyette yaklaşık 16 GB GPU belleği ister. Aynı model 4 bitlik nicemleme (quantization) ile 5 ile 6 GB’a iner. 70 milyar parametreli modeller 4 bit ile bile 40 GB’ın üzerinde bellek gerektirir.
Model ağırlıkları hesabın yalnızca bir kısmıdır. Her eş zamanlı istek, bağlam uzunluğuna göre büyüyen bir KV önbelleği tutar. 50 kişinin aynı anda uzun belgelerle çalıştığı bir senaryoda önbellek, model ağırlığından daha fazla yer kaplayabilir. Bu yüzden kapasite planında şu üç soruya net cevap verin:
- Aynı anda kaç kullanıcı modeli kullanacak?
- Ortalama ve en uzun bağlam penceresi ne olacak?
- Kabul edilebilir yanıt süresi kaç saniye?
Küçük bir modelle başlamak genellikle doğru tercihtir. İyi yazılmış istemler ve kurum verisiyle desteklenen 8 milyar parametreli bir model, belge özetleme ve iç yazışma taslağı gibi işlerin önemli bir kısmında yeterli sonuç verir. İstem tasarımının model boyutu kadar sonucu etkilediğini kurumsal promptlarda halüsinasyon nasıl azaltılır yazımızda örneklerle gösterdik.
Kubernetes üzerinde LLM nasıl ölçeklenir?
Tek sunucuda çalışan bir model, kullanıcı sayısı arttığında darboğaza dönüşür. Kubernetes, GPU’lu düğümleri tek bir havuz gibi yönetmenizi ve yükü birden fazla model kopyasına dağıtmanızı sağlar. Bu mimariyi kurmak ve işletmek için ekibin Kubernetes eğitimi seviyesinde bilgiye sahip olması gerekir.
Temel yapı taşları şunlardır:
- GPU erişimi: NVIDIA GPU Operator, sürücüleri ve cihaz eklentisini düğümlere kurar. Pod tanımında nvidia.com/gpu kaynağı istenerek model kopyası GPU’ya atanır.
- Model ağırlıklarının saklanması: Ağırlıkları her pod başlangıcında internetten indirmek yerine kalıcı bir birimde (PersistentVolume) veya kurum içi bir nesne deposunda tutun. Bu hem açılış süresini kısaltır hem de dış bağlantı ihtiyacını ortadan kaldırır.
- Otomatik ölçekleme: CPU kullanımı LLM iş yükleri için yanıltıcı bir ölçüttür. Kuyruktaki istek sayısı veya GPU kullanım oranı gibi özel metriklere göre ölçekleme yapın.
- Hazırlık kontrolleri: Büyük bir modelin belleğe yüklenmesi dakikalar sürebilir. Readiness probe tanımlanmazsa trafik, henüz hazır olmayan pod’lara yönlenir.
Ekibiniz konteyner dünyasına yeni giriyorsa Kubernetes atölye çalışması uygulamalı bir başlangıç sunar. Dağıtım süreçlerini CI/CD hattına bağlamak için DevOps Practitioner eğitimi iyi bir tamamlayıcıdır. OpenShift kullanan kurumlar için konteyner, Kubernetes ve Red Hat OpenShift eğitimi daha uygun bir yol olacaktır.
Güvenlik ve yönetişim katmanı neden atlanmamalı?
Modelin şirket içinde çalışması, otomatik olarak güvenli olduğu anlamına gelmez. En sık yapılan hata, model API’sini kimlik doğrulaması olmadan iç ağa açmaktır. Böyle bir uç noktaya ağdaki herkes, hatta ele geçirilmiş bir iş istasyonu da istek gönderebilir.
Sağlam bir kurulumda modelin önünde bir API geçidi (gateway) bulunur. Bu katman kullanıcıyı kurumsal kimlik sistemiyle doğrular, departman bazında kota uygular ve istekleri kayıt altına alır. Kayıtlarda TC kimlik numarası, IBAN gibi kişisel verilerin maskelenmesi, KVKK açısından ayrıca önemlidir. Kişisel verinin yapay zeka süreçlerinde nasıl ele alınacağını veri yönetişimi farkındalığı: GDPR ve KVKK uyumunda yol haritası eğitimi kapsamlı biçimde ele alıyor.
Modeli kurum içi araçlara bağlayacaksanız, yani modelin veritabanına sorgu atmasına ya da e-posta göndermesine izin verecekseniz, istem enjeksiyonu (prompt injection) riski de gündeme gelir. Bu riskleri MCP güvenliği yazımızda somut senaryolarla anlattık.
Şirket içi LLM için 30 günlük pilot planı
Büyük bir yatırım kararından önce kısa ve ölçülebilir bir pilot yapmak riski azaltır. Aşağıdaki plan, tek GPU’lu bir sunucuyla başlayan ekipler için gerçekçi bir çerçeve sunar.
- 1. hafta: Tek bir kullanım senaryosu seçin. İç yönetmeliklerde soru cevap veya sözleşme özetleme iyi başlangıç noktalarıdır.
- 2. hafta: Ollama ile iki ya da üç açık modeli aynı test setiyle karşılaştırın. Doğruluğu ve yanıt süresini kayıt altına alın.
- 3. hafta: Kazanan modeli API geçidinin arkasına alın, kimlik doğrulamasını ve kayıt maskelemesini devreye sokun.
- 4. hafta: 20 ile 30 kişilik bir kullanıcı grubuyla gerçek iş akışında deneyin. Eş zamanlı kullanım verisine bakarak vLLM’e ve Kubernetes’e geçiş ihtiyacını değerlendirin.
Pilotun sonunda elinizde üç somut veri olmalı: kullanıcı başına ortalama maliyet, ortalama yanıt süresi ve kullanıcıların sonuçtan memnuniyet oranı. Yatırım kararının maliyet boyutunu ele almak için CAPEX ve OPEX farkları yazımız karar vericilere pratik bir çerçeve sunar.
Sonuç
Şirket içi LLM, veri egemenliğini korumak isteyen kurumlar için artık ulaşılabilir bir seçenek. Ollama hızlı bir pilot için, vLLM ise kurum geneline yayılan bir servis için doğru araçtır. Başarıyı belirleyen unsur çoğu zaman model seçimi değil; GPU kapasitesinin doğru hesaplanması, Kubernetes üzerinde düzgün işletilmesi ve güvenlik katmanının baştan tasarlanmasıdır.
Ekibinizin bu altyapıyı kurup işletebilmesi için Kubernetes, DevOps ve derin öğrenme yetkinliklerini birlikte geliştirmesi gerekir. Modelin iç işleyişini anlamak isteyen yazılımcılar için derin öğrenme ve Python ile uygulamaları eğitimi sağlam bir temel oluşturur.
Sıkça sorulan sorular
Şirket içi LLM, ChatGPT kadar iyi sonuç verir mi?
Genel kültür ve karmaşık akıl yürütme gerektiren işlerde büyük bulut modelleri hâlâ öndedir. Ancak özetleme, sınıflandırma ve kurum belgelerinden bilgi bulma gibi dar tanımlı işlerde, iyi yapılandırılmış açık modeller çoğu kurumun ihtiyacını karşılar. Belirleyici olan, modelin hangi iş için kullanılacağıdır.
Ollama kurumsal ortamda kullanılabilir mi?
Kullanılabilir, ancak tek başına yeterli değildir. Ollama’nın önüne kimlik doğrulama, kota ve kayıt işlevleri sağlayan bir API geçidi konulmalıdır. Yüzlerce eş zamanlı kullanıcı beklenen senaryolarda ise vLLM gibi yüksek verimli bir motor daha uygundur.
Şirket içi LLM için en az kaç GPU gerekir?
Pilot için 24 GB belleğe sahip tek bir GPU, 4 bitlik nicemlenmiş 8 milyar parametreli bir modeli rahatça çalıştırır. Kurum geneli kullanımda gereken GPU sayısı; eş zamanlı kullanıcı sayısına, bağlam uzunluğuna ve hedeflenen yanıt süresine göre hesaplanmalıdır.
Model şirket içinde çalışınca KVKK yükümlülükleri ortadan kalkar mı?
Hayır. Yurt dışı aktarım sorunu büyük ölçüde çözülür, ancak aydınlatma, veri minimizasyonu, erişim yetkisi ve kayıt güvenliği gibi yükümlülükler devam eder. Modelin işlediği kişisel veriler, diğer bilgi sistemlerindeki verilerle aynı özenle korunmalıdır.