On-premise yapay zekâ sistemleri, yapay zekâ modellerinin, kurumsal verilerin ve bunlara bağlı uygulamaların kurumun kontrolündeki sunucularda çalıştırılmasını sağlar. Özellikle müşteri bilgileri, kaynak kodları, finansal kayıtlar, üretim verileri veya kurum içi belgeler söz konusu olduğunda verinin nerede işlendiği kritik bir karar hâline gelir.
Ancak on-premise yapay zekâ, yalnızca bir sunucuya dil modeli kurmaktan ibaret değildir. Model sunumu, GPU kapasitesi, RAG mimarisi, kimlik doğrulama, erişim kontrolü, izleme, yedekleme ve güvenlik süreçleri birlikte ele alınmalıdır. Bu rehberde kurum içi yapay zekâ altyapısının nasıl çalıştığını, hangi durumlarda mantıklı olduğunu ve planlama sırasında nelere dikkat edilmesi gerektiğini inceleyeceğiz.
Bu rehberde neler bulacaksınız?
- On-premise yapay zekâ ve yerel LLM kavramlarının farklarını,
- Kurum içi yapay zekâ mimarisinin temel bileşenlerini,
- GPU, bellek ve kapasite planlamasında önemli ölçütleri,
- RAG, fine-tuning ve model eğitimi arasındaki farkları,
- Bulut, on-premise ve hibrit sistemlerin avantajlarını,
- Güvenlik ve toplam sahip olma maliyetinde dikkat edilmesi gerekenleri öğreneceksiniz.
On-Premise Yapay Zekâ Nedir?
On-premise yapay zekâ; model, veri ve uygulama bileşenlerinin kurumun kendi veri merkezinde, özel bulutunda veya doğrudan kontrol ettiği altyapıda çalıştırılmasıdır. Türkiye’de “on-premise yapay zekâ”, “kurum içi yapay zekâ”, “yerel LLM” ve “private AI” ifadeleri zaman zaman aynı anlamda kullanılsa da aralarında bazı farklar vardır.
- Yerel model: Bir iş istasyonunda, sunucuda veya kullanıcı cihazında çalışan modeli ifade edebilir.
- On-premise sistem: Modelin yanında veri, uygulama, erişim ve operasyon katmanlarının da kurumun kontrolünde olduğu daha kapsamlı yapıdır.
- Özel bulut: Kaynakların yalnızca belirli bir kuruma ayrıldığı, kurum içinde veya haricî bir veri merkezinde barındırılabilen altyapıdır.
- Air-gapped sistem: Dış ağlarla bağlantısı fiziksel veya mantıksal olarak kesilmiş özel kurulum biçimidir.
Kurumlar Neden On-Premise Yapay Zekâ Kullanır?
On-premise mimarinin tercih edilme nedeni yalnızca güvenlik değildir. Karar; işlenen verinin niteliği, kullanım yoğunluğu, gecikme hedefleri, kurum politikaları ve mevcut teknik ekip birlikte değerlendirilerek verilmelidir.
Veri kontrolü ve veri egemenliği
Müşteri kayıtları, sözleşmeler, sağlık verileri, kaynak kodları ve kurum içi raporlar herkese açık yapay zekâ servislerine gönderilmek için uygun olmayabilir. Kurum içi sistemler verinin nerede saklandığı, hangi servisler tarafından işlendiği ve kimlerin erişebildiği üzerinde daha ayrıntılı kontrol kurulmasını sağlar.
Düşük gecikme ve yerel erişim
Üretim hattı görüntü işleme, çağrı merkezi analizi veya yoğun doküman sorgulama gibi uygulamalarda verinin uzak bir servise gönderilip geri alınması istenmeyen gecikmeler oluşturabilir. Modelin yerel ağda çalışması, uygun kapasite planlaması yapıldığında daha tutarlı yanıt süreleri sağlayabilir.
Model ve altyapı üzerinde kontrol
Kurumlar kullanacakları modeli, model sürümünü, güncelleme zamanını ve erişim politikasını kendileri belirleyebilir. Bu durum belirli bir API sağlayıcısına bağımlılığı azaltabilir; ancak model güncelleme ve sistem yönetimi sorumluluğunu da kuruma taşır.
İnternetten bağımsız çalışma
Saha sistemleri, kapalı ağlar ve kritik üretim ortamları dış bağlantı olmadan çalışmak zorunda olabilir. Böyle bir durumda model dosyaları, bağımlılıklar, güncelleme paketleri ve log yönetimi için özel bir çevrimdışı operasyon planı gerekir.
On-Premise Yapay Zekâ Sistemi Nasıl Çalışır?
Üretim ortamına uygun bir kurum içi LLM sistemi birden fazla katmandan oluşur. NVIDIA’nın kurumsal yapay zekâ platformunda da model servisleri, geliştirme bileşenleri, GPU kaynakları ve altyapı yönetimi birlikte ele alınmaktadır. Teknik bileşenleri incelemek isteyenler NVIDIA AI Enterprise sayfasına bakabilir.
Basitleştirilmiş on-premise yapay zekâ ve kurum içi LLM mimarisi
Her yapay zekâ uygulamasının RAG kullanması gerekmez. RAG gerektirmeyen görevlerde belge arama katmanı atlanarak istek doğrudan model servisine iletilebilir.
Model ve inference sunucusu
Inference sunucusu, kullanıcı isteklerini modele iletir ve üretilen yanıtları uygulamaya döndürür. Burada yalnızca modelin çalışması değil; isteklerin sıraya alınması, GPU kaynaklarının paylaşılması, eşzamanlı kullanıcıların yönetilmesi ve hataların izlenmesi de gerekir.
Tek sunuculu pilotlar ve yerel model denemelerinde Ollama kullanılabilir. Daha yüksek istek hacmi ve üretim odaklı model sunumu için vLLM, NVIDIA GPU tabanlı optimizasyon gereksinimlerinde ise TensorRT-LLM değerlendirilebilecek araçlar arasındadır. Bu araçlar birbirinin birebir karşılığı değildir; seçim model desteği, donanım, eşzamanlı kullanıcı sayısı ve operasyon gereksinimlerine göre yapılmalıdır.
Kullanılan araçtan bağımsız olarak modelin gerçekten yerel bir endpoint üzerinde çalıştığı ve isteklerin haricî bir bulut servisine yönlendirilmediği doğrulanmalıdır.
RAG ve vektör veritabanı
RAG, kullanıcının sorusuyla ilgili kurum belgelerini bulup modele bağlam olarak sağlar. Böylece modelin her doküman değişikliğinde yeniden eğitilmesi gerekmez. Ancak belge parçalama, arama kalitesi, güncelleme sıklığı ve kullanıcı izinleri doğru kurulmazsa sistem ilgisiz veya yetkisiz içerik getirebilir.
Vektör arama katmanında Qdrant ve Milvus gibi özel vektör veritabanları veya mevcut PostgreSQL altyapısına vektör benzerlik araması ekleyen pgvector kullanılabilir. Seçim yalnızca arama hızına göre değil; metadata filtreleme, erişim kontrolleri, yedekleme, yüksek erişilebilirlik, veri miktarı ve kurumun operasyon deneyimine göre yapılmalıdır.
Kimlik ve erişim yönetimi
Kullanıcının bir belgeyi normal sistemlerde görüntüleme yetkisi yoksa yapay zekâ asistanı üzerinden de bu bilgiye ulaşamaması gerekir. Bu nedenle SSO, rol tabanlı erişim, belge izinleri ve denetim kayıtları RAG sisteminin ayrılmaz parçalarıdır.
İzleme ve model operasyonları
CPU ve GPU kullanımı tek başına yeterli değildir. İlk token süresi, token üretim hızı, P95/P99 yanıt süresi, eşzamanlı istek sayısı, hata oranı, kaynak kullanımı ve cevap kalitesi birlikte izlenmelidir.
On-Premise, Bulut ve Hibrit Yapay Zekâ Karşılaştırması
| Kriter | On-Premise | Bulut | Hibrit |
|---|---|---|---|
| Veri kontrolü | Yüksek | Sağlayıcı ve sözleşmeye bağlı | İş yüküne göre değişir |
| İlk yatırım | Genellikle yüksek | Genellikle düşük | Orta |
| Ölçekleme | Donanım kapasitesine bağlı | Daha hızlı | Esnek |
| Operasyon ihtiyacı | Yüksek | Görece düşük | Orta-yüksek |
| İnternet bağımlılığı | Azaltılabilir | Genellikle vardır | İş yüküne bağlıdır |
| Uygun kullanım | Hassas ve sürekli iş yükleri | Hızlı başlangıç ve değişken yük | Karma gereksinimler |
On-premise her zaman daha güvenli veya daha ucuz değildir. Doğru seçim; veri hassasiyeti, kullanım yoğunluğu, ekip yetkinliği, gecikme hedefi ve toplam sahip olma maliyetine göre yapılmalıdır.
On-Premise LLM İçin Donanım Nasıl Seçilir?
Donanım ihtiyacı yalnızca modelin parametre sayısına bakılarak belirlenemez. Modelin sayısal hassasiyeti, sayısal sıkıştırma yöntemi (quantization), bağlam uzunluğu, eşzamanlı kullanıcı sayısı ve beklenen yanıt süresi gerçek kaynak ihtiyacını doğrudan etkiler.
Kapasite planlamasında aşağıdaki sorular cevaplanmalıdır:
- Kaç kullanıcı aynı anda sisteme istek gönderecek?
- Kabul edilebilir ilk token ve toplam yanıt süresi nedir?
- İstekler ve model yanıtları ortalama ne kadar uzun olacak?
- Tek model mi, birden fazla uzman model mi çalışacak?
- RAG, embedding ve yeniden sıralama servisleri aynı altyapıyı mı kullanacak?
- Yüksek erişilebilirlik ve yedekli GPU ihtiyacı var mı?
- Model güncellemeleri ve yeni sürümler için ne kadar depolama ayrılacak?
Donanım satın almadan önce aday modeller gerçek kullanım senaryolarıyla test edilmelidir. Yalnızca tek kullanıcılı token/saniye sonucu değil; eşzamanlı yük altında P95/P99 gecikme, hata oranı, GPU belleği kullanımı ve cevap kalitesi birlikte ölçülmelidir.
Tek Sunucu mu, Kubernetes mi?
Tek sunuculu kurulum
Tek GPU sunucusu, pilot çalışmalar ve sınırlı kullanıcı sayısı için daha hızlı ve basit bir başlangıç sağlayabilir. Ancak arıza durumunda hizmet sürekliliği, kapasite artırımı ve birden fazla modelin yönetimi zamanla zorlaşabilir.
Kubernetes tabanlı kurulum
Kubernetes; birden fazla model servisinin dağıtılması, kaynak limitleri, güncellemeler, geri dönüş, izleme ve yüksek erişilebilirlik için daha güçlü bir temel sunar. Buna karşılık platformun kurulması ve işletilmesi için deneyimli bir teknik ekip gerekir.
Kurum içindeki ekiplerin konteyner orkestrasyonu, kaynak yönetimi ve güvenli dağıtım konularındaki yetkinliğini geliştirmek için Kurumsal Kubernetes Eğitimleri incelenebilir.
RAG, Fine-Tuning ve Baştan Eğitim Arasındaki Fark
| Yöntem | Ne zaman kullanılır? | Temel amaç |
|---|---|---|
| RAG | Güncel kurum belgelerine erişim gerektiğinde | Modele ilgili ve güncel bağlam sağlamak |
| Fine-tuning | Belirli görev veya çıktı biçimine uyarlama gerektiğinde | Model davranışını özelleştirmek |
| Baştan eğitim | Büyük veri, bütçe ve çok özel gereksinimler bulunduğunda | Yeni bir temel model oluşturmak |
Kurumsal belgeleri yapay zekâ sistemine dâhil etmek için ilk seçenek çoğu zaman sıfırdan model eğitmek değildir. Erişim kontrolleri doğru uygulanmış bir RAG sistemi daha güncel, yönetilebilir ve ekonomik olabilir. Model mimarileri ve özelleştirme yöntemleri hakkında daha kapsamlı içerik için Kurumsal Large Language Models (LLM) Eğitimleri incelenebilir.
On-Premise Yapay Zekâ Güvenliği
Verinin kurum içinde tutulması önemli bir kontrol sağlasa da saldırı yüzeyini ortadan kaldırmaz. Model sunucuları, API’ler, vektör veritabanları, kullanıcı arayüzleri ve yönetim panelleri diğer kurumsal sistemler gibi korunmalıdır.
- SSO ve rol tabanlı yetkilendirme uygulanmalıdır.
- Veriler aktarım sırasında ve depolamada şifrelenmelidir.
- RAG sonuçları kullanıcının belge izinlerine göre filtrelenmelidir.
- Prompt injection ve yetkisiz araç kullanımı test edilmelidir.
- API anahtarları ve servis hesapları güvenli biçimde saklanmalıdır.
- Model, konteyner ve bağımlılıkların kaynağı doğrulanmalıdır.
- Telemetri ve dış ağ bağlantıları envantere alınmalıdır.
- Model çıktıları kritik işlemlerde insan denetiminden geçirilmelidir.
- Loglama, yedekleme ve olay müdahale süreçleri hazırlanmalıdır.
LLM uygulamalarında karşılaşılan başlıca güvenlik riskleri için OWASP LLM Top 10, yönetişim ve risk yönetimi için ise NIST AI Risk Management Framework resmî kaynak olarak incelenebilir.
Teknik kontrollerin yanında çalışanların hangi verileri yapay zekâ araçlarıyla paylaşabileceğini bilmesi gerekir. Bu konuda Yapay Zekâ Farkındalık Eğitimi, güvenli ve sorumlu kullanım kültürünün oluşturulmasına yardımcı olabilir.
On-Premise Yapay Zekânın Maliyeti Nasıl Hesaplanır?
On-premise sistemlerde API başına ücret yerine ilk yatırım ve devam eden operasyon maliyetleri öne çıkar. Gerçek değerlendirme yalnızca GPU fiyatına bakılarak yapılamaz.
Toplam sahip olma maliyeti
Donanım + lisans + enerji + soğutma + bakım + yedekleme + operasyon + insan kaynağı
Yoğun ve düzenli kullanımda yerel altyapı maliyet avantajı sağlayabilir. Düşük veya öngörülemeyen kullanımda ise bulut tabanlı servisler daha ekonomik olabilir. Sağlıklı karar için aynı iş yükünün bulut API maliyetiyle on-premise sistemin birkaç yıllık toplam maliyeti karşılaştırılmalıdır.
On-Premise Yapay Zekâ Kurulum Yol Haritası
- İş problemini belirleyin: Sistem hangi süreci iyileştirecek ve başarı nasıl ölçülecek?
- Veriyi sınıflandırın: Kişisel, hassas ve kurum dışına çıkmaması gereken verileri tespit edin.
- Dağıtım modelini seçin: Bulut, on-premise ve hibrit seçenekleri karşılaştırın.
- Aday modelleri test edin: Türkçe başarımı, doğruluk, hız ve lisans koşullarını değerlendirin.
- Gerçek yükle benchmark yapın: Eşzamanlı kullanıcı, uzun bağlam ve RAG sorgularını ölçün.
- Pilot sistem kurun: Sınırlı veri ve kullanıcı grubuyla başlayın.
- Güvenlik testlerini tamamlayın: Yetkilendirme, prompt injection, veri sızıntısı ve kayıtları test edin.
- Üretime geçin: İzleme, yedekleme, güncelleme ve olay müdahale süreçlerini devreye alın.
En Sık Yapılan Hatalar
- Kullanım senaryosu belirlemeden GPU satın almak
- Yalnızca en büyük modeli seçmeye çalışmak
- On-premise kurulumun otomatik olarak güvenli olduğunu düşünmek
- Gerçek eşzamanlı kullanıcı yüküyle benchmark yapmamak
- RAG veri kalitesini ve belge izinlerini ihmal etmek
- Model ve bağımlılık güncellemelerini planlamamak
- Yedekleme ve felaket kurtarma süreci oluşturmamak
- Sistemin operasyonel sahibini belirlememek
On-Premise Yapay Zekâ Kimler İçin Mantıklıdır?
On-premise yapay zekâ özellikle hassas veya düzenlemeye tabi veri işleyen, yoğun AI kullanımına sahip, düşük gecikmeye ihtiyaç duyan ve altyapıyı yönetebilecek teknik ekibi bulunan kurumlar için değerlendirilebilir. Finans, sağlık, kamu, savunma, üretim ve yazılım geliştirme ekipleri bu kullanım modelinden faydalanabilir.
Buna karşılık kullanım hacmi düşükse, teknik ekip sınırlıysa veya hızla değişen modellere erişmek öncelikliyse bulut ya da hibrit yaklaşım daha uygun olabilir. Amaç her şeyi kurum içine taşımak değil; her iş yükünü güvenlik, performans ve maliyet açısından doğru yerde çalıştırmaktır.
On-Premise Yapay Zekâ Hakkında Sık Sorulan Sorular
On-premise yapay zekâ internetsiz çalışabilir mi?
Evet. Model, bağımlılıklar ve gerekli veriler yerel altyapıda bulunuyorsa sistem dış bağlantı olmadan çalışabilir. Ancak güncellemelerin, güvenlik yamalarının ve yeni model dosyalarının kontrollü şekilde sisteme aktarılması gerekir.
On-premise sistemde veriler kesinlikle kurum içinde mi kalır?
Doğru yapılandırılmış bir sistemde veriler kurum içinde tutulabilir. Bunun için telemetri servisleri, haricî API bağlantıları, log hedefleri ve yazılım güncelleme mekanizmaları ayrıca denetlenmelidir.
Yerel LLM çalıştırmak için GPU şart mı?
Küçük ve düşük trafikli modeller CPU üzerinde çalışabilir; ancak üretim ortamında kabul edilebilir yanıt süresi ve eşzamanlı kullanıcı kapasitesi için çoğu senaryoda GPU veya başka bir hızlandırıcı gerekir.
On-premise yapay zekâ buluttan daha mı güvenlidir?
Her zaman değil. On-premise mimari daha fazla kontrol sağlar fakat güvenlik sorumluluğunu da kuruma taşır. Güncelleme, erişim kontrolü, ağ güvenliği ve izleme süreçleri zayıfsa yerel sistem de ciddi riskler barındırabilir.
RAG ile fine-tuning arasındaki fark nedir?
RAG, sorgu sırasında ilgili bilgileri bulup modele bağlam olarak verir. Fine-tuning ise modelin ağırlıklarını belirli örneklerle uyarlayarak davranışını değiştirir. Güncel kurumsal belgelere erişim için genellikle RAG daha uygun bir başlangıçtır.
On-premise yapay zekâ Kubernetes üzerinde çalıştırılabilir mi?
Evet. Kubernetes model servislerinin dağıtılması, kaynakların yönetilmesi, ölçekleme, izleme ve yüksek erişilebilirlik için kullanılabilir. Ancak GPU planlama ve model sunumu konusunda ek uzmanlık gerekir.
On-premise yapay zekâ sisteminin maliyeti ne kadardır?
Maliyet; model büyüklüğü, GPU sayısı, eşzamanlı kullanıcı, yedeklilik, lisans ve operasyon ihtiyacına göre değişir. Bu nedenle sabit bir sunucu fiyatı yerine kullanım senaryosuna dayalı kapasite ve toplam sahip olma maliyeti hesabı yapılmalıdır.
Kurumunuza Uygun Yapay Zekâ Altyapısını Planlayın
On-premise yapay zekâ projelerinde doğru model kadar doğru mimari, güvenlik yaklaşımı ve ekip yetkinliği de önemlidir. Kurumunuzun teknik gereksinimlerini değerlendirmek için Absonet danışmanlık hizmetlerini ve ekiplerin yetkinliklerini geliştirmek için Kurumsal Yapay Zekâ Eğitimleri sayfasını inceleyebilirsiniz.
Kurumunuza özel ihtiyaçlar ve eğitim seçenekleri hakkında bilgi almak için Absonet ile iletişime geçin.
Hazırlayan: Absonet Teknik Ekibi
Son güncelleme: Ağustos 2026