On-Premise ve Egemen AI Altyapısı: Kurulumdan Operasyona

On-premise yapay zeka, bir kurumun dil modellerini ve onları çevreleyen bileşenleri — vektör veritabanı, servis katmanı, izleme — bir bulut sağlayıcının veri merkezinde değil, kendi kontrol ettiği donanımda çalıştırmasıdır. Bu tercihin arkasındaki en güçlü gerekçe veri ikametgahı ve veri egemenliğidir: veri, kurumun fiziksel ve hukuki sınırlarının dışına hiç çıkmaz. Bu rehberde on-premise yapay zeka altyapısının neden gerektiğini, hangi donanım katmanlarından oluştuğunu, model seçimi ve model servis etme kararlarını, ölçeklenme ve eşzamanlılığı, izleme-bakım-güncelleme döngüsünü ve çoğu kurumun hafife aldığı gerçek operasyon yükünü bir danışman titizliğiyle ele alıyoruz.

On-premise yapay zeka, moda bir kavram değil; kritik ve düzenlenen sektörlerde giderek daha somut bir mühendislik ve maliyet kararıdır. Bankacılık, sigorta, sağlık, savunma ve kamu gibi alanlarda "verimiz nerede işleniyor" sorusu artık teknik bir ayrıntı değil, düzenleyici bir zorunluluktur. Bu yazı, "kendi sunucunda LLM çalıştırmak mantıklı mı, mantıklıysa nasıl yapılır ve gerçek maliyeti nedir" sorularına uçtan uca, abartısız ve uygulanabilir bir yanıt vermeyi amaçlar.

Tanım

On-Premise Yapay Zeka

Dil modellerinin ve destekleyici bileşenlerin (vektör veritabanı, servis/inference katmanı, izleme) bulut sağlayıcı yerine kurumun kendi veri merkezinde veya doğrudan kontrol ettiği donanımda çalıştırılması. On-premise yapay zeka; veri ikametgahı ve veri egemenliği sağlar, verinin kurum sınırından çıkmasını engeller ve kullanım öngörülebilir olduğunda birim maliyette avantaj sunar. Karşılığında donanım yatırımı ve süregelen operasyon yükü getirir.

Ayrıca: on-premises AI, şirket içi yapay zeka, egemen AI, kendi sunucunda LLM, self-hosted yapay zeka

On-premise yapay zeka, en yalın haliyle, yapay zeka iş yükünü başkasının bilgisayarında değil, kurumun kendi kontrolündeki bilgisayarlarda çalıştırmaktır. "On-premise" (yerinde, tesis içi) ifadesi, altyapının kurumun veri merkezinde veya en azından tam kontrolündeki bir ortamda bulunduğunu anlatır. Bunun karşıtı, modeli ve veriyi bir bulut sağlayıcının hizmetine gönderip yanıtı geri almaktır. Aradaki fark yalnızca sunucunun fiziksel yeri değil; verinin, model ağırlıklarının ve işletim kararlarının kimin elinde olduğudur.

Bir benzetme yardımcı olur. Bulut yapay zekası, bir dış lokantada yemek yemeye benzer: mutfak, malzeme ve aşçı başkasınındır; siz sipariş verir, sonucu alırsınız — hızlı ve zahmetsizdir ama tarifin, malzemenin ve mutfağın kontrolü sizde değildir. On-premise yapay zeka ise kendi mutfağınızı kurmaktır: fırını, tezgâhı ve malzemeyi siz alırsınız; her şeyi kendiniz kontrol edersiniz ama bulaşığı da, bakımı da, stok yönetimini de siz üstlenirsiniz. Bu benzetme, on-premise'in hem en büyük avantajını (kontrol) hem de en büyük yükünü (operasyon) tek cümlede özetler.

Teknik olarak on-premise yapay zeka bir tek üründen ibaret değildir; birbirine bağlı bir katman yığınıdır. En altta donanım (GPU'lu sunucular, depolama, ağ) bulunur; onun üzerinde modeli çalıştıran bir servis/inference katmanı; onun üzerinde ölçeklenmeyi ve eşzamanlılığı yöneten orkestrasyon; en üstte de izleme, güvenlik ve güncelleme süreçleri yer alır. Bu katmanların her biri ayrı bir karar ve ayrı bir yetkinlik gerektirir. Açık kaynak modellerin bu yığında oynadığı rolü GPU nedir ve kurumsal AI'da neden gerekir yazısıyla birlikte okumak, donanım tarafını netleştirir.

On-premise yapay zeka sorusuna verilecek en ikna edici cevap, "hangi ihtiyacı karşıladığı"nı göstermektir. Bulut hizmetleri çoğu senaryoda hızlı, esnek ve düşük giriş maliyetlidir; buna rağmen bazı kurumların neden kendi altyapısını kurmayı seçtiğini anlamak, kararın stratejik doğasını ortaya koyar. Dört temel gerekçe öne çıkar.

Birincisi ve en belirleyicisi veri ikametgahıdır. Bazı veriler, düzenleyici veya sözleşmesel nedenlerle kurumun — hatta ülkenin — sınırları dışına çıkamaz. Bankacılıkta müşteri verisi, sağlıkta hasta kaydı, savunmada gizli belge, kamuda vatandaş verisi bu kapsamdadır. Bu tür veriyi bir dış modele göndermek, çoğu zaman ya yasak ya da ciddi bir uyum riskidir. On-premise yapay zeka, veriyi hiç dışarı çıkarmadan işleyerek bu sorunu kökten çözer. Veri ikametgahı, "verim fiziksel ve hukuki olarak nerede duruyor" sorusunun net ve savunulabilir bir cevabıdır.

İkincisi veri egemenliği ve stratejik bağımsızlıktır. Egemenlik yalnızca "veri nerede" değil, "kesinti, fiyat değişikliği, politika değişikliği veya erişim kısıtı olduğunda kim karar veriyor" sorusudur. Bir dış sağlayıcı hizmet koşullarını değiştirdiğinde, bir modeli emekliye ayırdığında veya bir bölgeye erişimi kısıtladığında, buluta bağımlı kurum bu kararların pasif alıcısıdır. On-premise altyapı, bu kararları kurumun kendi eline verir. Kritik iş süreçlerini dış bir hizmetin sürekliliğine bağlamak istemeyen kurumlar için bu bağımsızlık başlı başına bir değerdir.

Üçüncüsü öngörülebilir maliyet ve yüksek hacim ekonomisidir. Bulut, kullandıkça öde modeliyle düşük hacimde çok ekonomiktir; ama kullanım hacmi yükseldikçe ve öngörülebilir hale geldikçe, sabit bir donanım yatırımının birim maliyeti bulutun değişken maliyetinin altına inebilir. Sürekli ve yoğun çıkarım (inference) yapan bir kurum için, kendi sunucunda LLM çalıştırmak uzun vadede daha ekonomik olabilir. Bu, maliyet optimizasyonunun daha geniş çerçevesini ele alan LLM maliyet optimizasyonu yazısıyla birlikte değerlendirilmesi gereken bir hesaptır.

Dördüncüsü gecikme ve entegrasyon kontrolüdür. Verinin bir dış merkeze gidip gelmesi gecikme yaratır; ayrıca bazı iç sistemler (eski kurumsal uygulamalar, hava boşluklu ağlar) dışarıya hiç açılamaz. On-premise altyapı, modeli verinin ve sistemlerin yanına getirerek hem gecikmeyi düşürür hem de kapalı ağlarda çalışmayı mümkün kılar. Bu gerekçelerin tamamı aynı kurumda geçerli olmayabilir; ama biri bile yeterince güçlüyse, on-premise yapay zeka masaya gelir.

On-premise yapay zeka altyapısının en somut ve en pahalı katmanı donanımdır. Ve bu katmanın kalbi, sıradan bir sunucudan farklı olarak, grafik işlem birimidir (GPU). Dil modellerinin gerektirdiği devasa paralel matris çarpımlarını verimli yapan bileşen GPU'dur; CPU tek başına bu iş için hem çok yavaş hem çok verimsizdir. Bu yüzden altyapı kurulumu, doğru GPU seçimiyle başlar. GPU'nun kurumsal AI'daki rolünü GPU nedir yazısında derinlemesine ele alıyoruz.

GPU seçiminde en belirleyici parametre işlem gücü değil, bellektir — yani GPU belleği (VRAM). Nedeni şudur: bir dil modelini çalıştırmak için modelin tüm ağırlıklarının belleğe yüklenmesi gerekir; üstelik eşzamanlı her isteğin bağlamı için de (KV cache adı verilen ara bellek) ek yer lazımdır. Model ağırlıkları ve eşzamanlı bağlam belleğe sığmazsa iki kötü sonuçtan biri olur: sistem ya isteği reddeder ya da veriyi daha yavaş belleğe/diske taşıyarak dramatik biçimde yavaşlar. Bu yüzden "kaç GPU" sorusundan önce "ne kadar VRAM" sorusu gelir.

Bellek ihtiyacını üç şey belirler: modelin boyutu (parametre sayısı), sayısal hassasiyet ve hedeflenen eşzamanlılık. Sayısal hassasiyeti düşüren quantization (nicemleme), ağırlıkları daha az bitle temsil ederek bellek ihtiyacını ciddi ölçüde azaltır; böylece daha küçük bir GPU'da daha büyük bir model çalışabilir. Karşılığında kalitede küçük bir düşüş olabilir; bu ödünleşim, hedef göreve göre ölçülerek verilmelidir. Pratik kural: hedef modeli temsili bir yükle test edip gerçek bellek ve gecikme davranışını ölçmeden donanım siparişi vermeyin.

Donanım yalnızca GPU değildir. Model ağırlıklarının ve veri kümelerinin saklandığı hızlı depolama (tercihen NVMe SSD), GPU'lar arası ve sunucular arası düşük gecikmeli ağ, yeterli sistem belleği (RAM) ve — çoğu zaman unutulan — soğutma ve güç altyapısı da kritiktir. Yüksek yoğunluklu GPU sunucuları ciddi ısı ve elektrik tüketir; mevcut veri merkezinin bunu kaldırıp kaldıramayacağı, altyapı kurulumu planının erken bir sorusudur. Aşağıdaki tablo donanım katmanının bileşenlerini ve her birinde dikkat edilecek noktayı özetler.

On-premise yapay zeka donanım bileşenleri ve karar noktaları

Bileşen	Rolü	Dikkat edilecek nokta
GPU	Model çıkarımını (inference) çalıştırır	İşlem gücünden önce VRAM miktarı belirleyici
VRAM (GPU belleği)	Ağırlıkları ve bağlamı tutar	Yetmezse sistem yavaşlar ya da çalışmaz
Depolama	Model ağırlıkları ve veriyi saklar	Hızlı NVMe; model yükleme süresini etkiler
Ağ	Sunucu ve GPU'ları bağlar	Çok GPU'lu kurulumda düşük gecikme şart
Güç ve soğutma	Donanımı ayakta tutar	Mevcut veri merkezi kapasitesi erken kontrol edilmeli

Donanım kararında son bir uyarı: fazla almak da az almak kadar risklidir. İhtiyaçtan fazla GPU almak, yıllarca atıl duran ve amortismanı çıkmayan bir yatırım demektir; az almak ise ilk yoğun kullanımda sistemin çökmesi demektir. Doğru yol, gerçek yükü küçük bir pilotla ölçmek, sonra kanıta dayalı ölçeklemektir. Donanım, on-premise yapay zekanın en görünür maliyeti olsa da, birazdan göreceğimiz gibi, en büyük maliyeti değildir.

Donanım hazır olduğunda sıra, üzerinde ne çalışacağına ve nasıl sunulacağına gelir. Bu, iki ayrı karardır: hangi modeli seçeceğiniz ve o modeli nasıl model servis etme katmanıyla sunacağınız. İkisi de on-premise yapay zeka kalitesini doğrudan belirler ve sık karıştırılır.

Model seçiminde temel gerilim, boyut ile pratiklik arasındadır. Daha büyük modeller genellikle daha yeteneklidir ama daha çok bellek, daha çok elektrik ve daha yüksek gecikme demektir. Çoğu kurumsal görev — belge özetleme, sınıflandırma, bilgi erişimi, form doldurma — en büyük modeli gerektirmez; iyi seçilmiş orta boy bir açık ağırlıklı (open-weight) model, gereksinimin çoğunu karşılar. Doğru yaklaşım, en büyük modelle başlamak değil, göreve yetecek en küçük modelle başlayıp gerekiyorsa büyütmektir. Bu, hem maliyeti hem operasyon yükünü düşürür.

İkinci ve daha teknik karar model servis etme katmanıdır. Bir modeli sadece bir betikle çalıştırmak ile onu üretim kalitesinde sunmak çok farklı şeylerdir. Model servis etme, modeli bir API arkasında, birden çok kullanıcının eşzamanlı erişebileceği, istekleri kuyruğa alıp verimli işleyebilen bir hizmete dönüştürmektir. İyi bir servis katmanı şu yetenekleri sağlar: istekleri gruplayarak GPU'yu doyuran toplu işleme (batching); yanıtı kelime kelime akıtan streaming; bellek yönetimi; ve aşırı yükte isteği zarifçe reddeden veya kuyruğa alan akış kontrolü. Bu katman kötü kurulursa, güçlü bir donanım bile düşük verimle çalışır.

Model servis etme kararının bir boyutu da "tek model mi, çok model mi" sorusudur. Bazı kurumlar tek bir genel model çalıştırır; bazıları görev tipine göre farklı modeller (küçük-hızlı ve büyük-yetenekli) arasında yönlendirme yapar. İkinci yaklaşım maliyet-kalite dengesini iyileştirir ama orkestrasyonu karmaşıklaştırır. Karar, kullanım profiline bağlıdır: çeşitli ve değişken görevler çok modelli kurulumu, tek tip ve yoğun görevler tek modelli sadeliği tercih ettirir.

Model seçimi ve model servis etme kararları

Karar	Seçenekler	Ne zaman hangisi
Model boyutu	Küçük / orta / büyük	Göreve yetecek en küçükle başla, gerekiyorsa büyüt
Sayısal hassasiyet	Tam / quantize edilmiş	Bellek darsa quantize; kaliteyi ölçerek
Servis mimarisi	Tek model / çok model yönlendirme	Değişken görev çok model; tek tip görev tek model
İstek işleme	Tekil / toplu (batching)	Eşzamanlılık yüksekse batching şart

Bir noktanın altını çizelim: model seçimi tek seferlik bir karar değildir. Açık ağırlıklı model ekosistemi hızla gelişir; bugün en iyi olan model altı ay sonra yerini bir başkasına bırakabilir. Bu yüzden servis katmanını, modeli görece kolay değiştirilebilir kılacak biçimde tasarlamak — modeli sabit bir bağımlılık değil, değiştirilebilir bir bileşen olarak görmek — on-premise yapay zeka mimarisinin dayanıklılığını artırır.

Bir modelin tek bir istekle çalışması ile yüzlerce kullanıcının aynı anda ona soru sorması çok farklı mühendislik problemleridir. On-premise yapay zeka altyapısının en çok hafife alınan yönü, eşzamanlılık ve ölçeklenme yönetimidir. Laboratuvarda tek kullanıcıyla mükemmel çalışan bir kurulum, gerçek yük altında kuyruğa girer, yavaşlar veya çöker; çünkü GPU kaynağı sınırlıdır ve paylaşılması gerekir.

Ölçeklenmenin iki yönü vardır. Dikey ölçeklenme, daha güçlü veya daha çok belleğe sahip bir GPU'ya geçmektir — daha büyük bir modeli veya daha uzun bağlamı tek makinede çalıştırmayı sağlar. Yatay ölçeklenme ise birden fazla GPU/sunucu ekleyip yükü aralarında dağıtmaktır — daha çok eşzamanlı isteği karşılamayı sağlar. Kurumsal kullanımda genellikle ihtiyaç yataydır: sorun tek bir isteği hızlandırmak değil, çok sayıda isteği aynı anda makul gecikmeyle karşılamaktır. Bu, önüne bir yük dengeleyici (load balancer) koyup istekleri birden çok servis örneğine dağıtmayı gerektirir.

Eşzamanlılık yönetiminin kalbi kuyruk ve toplu işlemedir. GPU, aynı anda birden çok isteği gruplayarak (batching) işlediğinde çok daha verimli çalışır; tek tek işlemek GPU'yu boş bırakır. İyi bir servis katmanı, gelen istekleri akıllıca gruplar, bir kuyruk tutar ve GPU'yu mümkün olduğunca dolu çalıştırır. Ama bir sınır vardır: kuyruk çok uzarsa kullanıcı bekler; bu yüzden sistemin, kapasitesi dolduğunda isteği zarifçe reddetmesi veya kullanıcıya bekleme süresini bildirmesi gerekir. Sessizce yavaşlayan bir sistem, açıkça "meşgulüm" diyen bir sistemden daha kötü bir deneyimdir.

Kapasite planlama, ölçeklenmenin stratejik tarafıdır ve tahminle değil ölçümle yapılmalıdır. Doğru sorular şunlardır: Zirve saatte kaç eşzamanlı istek geliyor? Kabul edilebilir gecikme nedir? Bir GPU kaç eşzamanlı isteği bu gecikmeyle karşılayabiliyor? Bu üç sayı, kaç GPU gerektiğini belirler. Bu ölçümleri yapmadan kapasite planlamak, ya atıl donanıma ya da yoğun anda çöken bir sisteme yol açar. Ölçeklenmenin altın kuralı şudur: önce ölç, sonra büyüt.

Kurulan bir on-premise yapay zeka sistemi, kurulduğu anda "bitti" sayılamaz; tam tersine, asıl iş burada başlar. Bir sistemi ayakta, sağlıklı ve güvenilir tutmanın ön koşulu onu görebilmektir — yani gözlemlenebilirlik (observability). Ölçülmeyen bir sistem yönetilemez; sessizce bozulur ve genellikle sorun ancak kullanıcı şikâyet ettiğinde fark edilir. Oysa iyi kurulmuş bir izleme katmanı, sorunları kullanıcıdan önce yakalar.

İzlenmesi gereken metrikler üç kümede toplanır. Birincisi altyapı metrikleridir: GPU kullanımı, GPU belleği doluluğu, sıcaklık, güç tüketimi, disk ve ağ. Bir GPU'nun sürekli %100 dolu çalışması kapasitenin tükendiğine, sürekli düşük çalışması ise atıl yatırıma işaret eder. İkincisi hizmet metrikleridir: istek sayısı, gecikme (özellikle uçtaki yavaş yanıtlar), kuyruk uzunluğu, hata oranı ve eşzamanlılık. Üçüncüsü ve en çok ihmal edileni model kalitesi metrikleridir: yanıtların doğruluğu, dayanaklılığı ve kullanıcı memnuniyeti. Altyapı sağlıklı görünürken model kalitesi sessizce düşebilir; bu yüzden kaliteyi de ölçmek gerekir.

Bakım tarafında, on-premise'in buluttan en büyük farkı, tüm sorumluluğun kurumda olmasıdır. Bir donanım arızasında yedek parça temini, bir sürücü uyumsuzluğunda geri alma, bir servis çökmesinde yeniden başlatma — bunların hepsi kurumun süreçleridir. Bu yüzden on-premise yapay zeka, yalnızca bir teknoloji değil, bir operasyon disiplini gerektirir: kimin ne zaman nöbetçi olduğu, bir arızada kimin arandığı, yedeklerin ne sıklıkta alındığı önceden tanımlanmış olmalıdır. Bu operasyonel olgunluk, gelişmiş kurumların AI risk değerlendirme dokümanı gibi araçlarla önceden planladığı bir konudur.

Gözlemlenebilirliğin bir de güvenlik boyutu vardır. On-premise bir sistem, dışarıya kapalı olsa bile iç tehditlere ve yanlış yapılandırmalara açıktır. Kim hangi modele erişti, hangi veriyle sorgu yapıldı, olağandışı bir kullanım deseni var mı — bunları görmek için denetim kaydı (audit log) tutulmalıdır. Erişim kontrolü ve loglama, sonradan eklenen değil, baştan tasarlanan bileşenlerdir. Aşağıda, sürekli izlenmesi gereken temel sinyalleri özetliyoruz.

On-premise yapay zekada izlenmesi gereken temel sinyaller

Sinyal kümesi	Örnek metrik	Ne anlama gelir
Altyapı	GPU kullanımı, VRAM doluluğu, sıcaklık	Kapasite ve donanım sağlığı
Hizmet	Gecikme, kuyruk uzunluğu, hata oranı	Kullanıcı deneyimi ve darboğaz
Model kalitesi	Doğruluk, dayanaklılık, memnuniyet	Yanıtların işe yararlığı
Güvenlik	Erişim logu, olağandışı kullanım	İç tehdit ve uyum

On-premise yapay zekanın en sinsi yükü güncelleme yönetimidir; çünkü sürekli, çok katmanlı ve göz ardı edilmesi tehlikelidir. Bulutta sağlayıcı arka planda bileşenleri güncel tutar; on-premise'de bu sorumluluk tümüyle kuruma geçer. Ve güncellenmesi gereken tek şey model değildir — güncelleme birkaç bağımsız katmanda eş zamanlı yürür.

Birinci katman model güncellemeleridir. Açık ağırlıklı model ekosistemi hızla ilerler; daha yetenekli sürümler çıkar, mevcut modeller iyileşir. Yeni bir modele geçmek cazip olabilir ama körlemesine yapılmamalıdır: yeni model, eski modelin iyi yaptığı bir görevi kötüleştirebilir. Bu yüzden her model güncellemesi, bir değerlendirme kümesiyle regresyon testinden geçmelidir — yani "bu yeni sürüm, önceki sürümün doğru yanıtladığı soruları hâlâ doğru yanıtlıyor mu" sorusu ölçülmelidir. Ölçmeden yapılan model güncellemesi, bir iyileştirme değil, bir kumar olabilir.

İkinci katman yazılım ve bağımlılık güncellemeleridir: servis motoru, orkestrasyon araçları, kütüphaneler. Bu bileşenler birbirine bağımlıdır ve bir katmandaki güncelleme, bir başkasını kırabilir. Özellikle GPU sürücüleri ve alt seviye kütüphaneler kırılgandır; yanlış bir sürüm eşleşmesi, tüm sistemin çalışmamasına yol açabilir. Bu yüzden güncellemeler önce bir test ortamında denenmeli, üretime kademeli geçilmelidir. Üçüncü katman güvenlik yamalarıdır: işletim sistemi, firmware ve bağımlılıklardaki güvenlik açıkları düzenli kapatılmalıdır. Kapalı bir ağda çalışmak, güvenlik yamalarını ihmal etme bahanesi değildir; iç tehditler ve tedarik zinciri açıkları hâlâ geçerlidir.

Güncelleme yönetiminin altın kuralı şudur: her güncelleme geri alınabilir olmalı. Bir model veya yazılım sürümü sorun çıkardığında, hızla bir önceki çalışan sürüme dönebilmek — yani sürüm kontrolü ve geri alma (rollback) yeteneği — üretim güvenilirliğinin temelidir. Bu, ajan tabanlı sistemlerdeki hata yönetimiyle aynı disiplindir; ajan iş akışlarında hata yönetimi ve geri alma yazısında ele aldığımız "geri alınabilir işlem" mantığı, altyapı güncellemeleri için de birebir geçerlidir.

Şimdi on-premise yapay zeka kararının en kritik ama en az konuşulan gerçeğine geliyoruz: operasyon yükü. Kurumlar genellikle kararı donanım fiyatına bakarak verir — "şu kadar GPU şu kadar tutar" der ve hesabı orada kapatır. Oysa donanım, buzdağının yalnızca görünen kısmıdır. Asıl maliyet, o donanımı yıllarca ayakta, güvenli, güncel ve verimli tutan süregelen operasyon yüküdür; ve bu yük çoğu zaman donanım fiyatını gölgede bırakır.

Operasyon yükü neleri kapsar? İşletim sistemi ve sürücü yamaları; GPU firmware güncellemeleri; model sürümlerinin izlenmesi, değerlendirilmesi ve güncellenmesi; kapasite planlama ve ölçeklenme kararları; gözlemlenebilirlik altyapısının kurulması ve bakımı; arıza durumunda nöbet (on-call) ve olay müdahalesi; yedekleme ve felaket kurtarma; güvenlik izleme ve denetim; ve tüm bunları yapacak ekibin işe alınması, eğitilmesi ve elde tutulması. Bulutta bu işlerin çoğunu sağlayıcı üstlenir; on-premise'de hepsi kurumun sırtındadır. İşte bu yüzden karar, satın alma fiyatına değil, üç yıllık toplam sahip olma maliyetine (TCO) ve gereken iç yetkinliğe bakılarak verilmelidir.

En kritik bileşen insandır. Kendi sunucunda LLM çalıştırmak, GPU, sistem yönetimi, ağ, güvenlik ve model operasyonu bilen bir ekip gerektirir. Bu yetkinlikler Türkiye'de kıt ve pahalıdır; bir kurum donanımı kolayca alabilir ama onu işletecek ekibi kuramazsa, en pahalı sistem bile atıl kalır veya güvenilmez çalışır. Bu gerçek, saha deneyimlerinde tekrar tekrar görülür; on-premise kurulumlarda karşılaştığım gerçekler saha notu, tam da bu iç yetkinlik ve tedarik gerçeklerini anlatır.

Operasyon yükünü hafife almanın tipik sonucu şudur: sistem kurulur, ilk aylarda çalışır, sonra yamalar birikir, biri işten ayrılır, model eskir, izleme kurulmadığı için bir sorun sessizce büyür — ve bir gün sistem güvenilmez hale gelir. Bu, teknolojinin değil, operasyonel olgunluğun eksikliğidir. On-premise yapay zekayı sürdürülebilir kılan şey, parlak donanım değil, o donanımın etrafındaki disiplinli süreç ve ekiptir. Karar verirken sorulacak en dürüst soru şudur: "Donanımı alabiliriz, ama onu üç yıl boyunca kim işletecek?"

On-premise yapay zeka kararını netleştirmenin en iyi yolu, onu iki alternatifiyle — bulut ve hibrit — yan yana koymaktır. Üçü de aynı işi yapabilir ama farklı maliyet, risk ve kontrol profilleri sunar. "Hangisi daha iyi" sorusunun cevabı kuruma, veriye ve kullanım profiline göre değişir; bu yüzden ilkeyle değil, kriterlerle karar verilir.

Bulut yaklaşımı, modeli ve altyapıyı bir sağlayıcının hizmeti olarak kullanmaktır. En büyük avantajları düşük giriş maliyeti, hızlı başlangıç, sıfır donanım bakımı ve elastik ölçeklenmedir — yükü artınca anında büyür, azalınca küçülür ve yalnızca kullandığınız kadar ödersiniz. En büyük dezavantajları ise veri egemenliğinden feragat, yüksek hacimde artan değişken maliyet ve sağlayıcıya bağımlılıktır. Deneysel, değişken veya düşük hacimli kullanım için bulut çoğu zaman en akılcı başlangıçtır.

On-premise yaklaşımı, tam kontrol ve veri ikametgahı sunar; yüksek ve öngörülebilir hacimde birim maliyette avantajlıdır. Karşılığında yüksek ön yatırım, uzun kurulum süresi ve süregelen operasyon yükü getirir. Hibrit yaklaşım ise bu ikisinin ortasıdır ve çoğu kurum için en gerçekçi cevaptır: hassas veri ve kritik iş yükleri on-premise işlenirken, hassas olmayan veya değişken yük buluta taşınır. Böylece veri egemenliği korunurken bulutun esnekliğinden de yararlanılır. Örneğin gizli müşteri verisi on-premise bir modelde işlenirken, genel içerik üretimi bulutta yapılabilir.

On-premise, bulut ve hibrit yaklaşımların karşılaştırması

Kriter	On-premise	Bulut	Hibrit
Veri ikametgahı	Tam kontrol	Sağlayıcıya bağlı	Hassas veri yerinde
Giriş maliyeti	Yüksek (donanım)	Düşük (kullandıkça öde)	Orta
Yüksek hacim birim maliyeti	Avantajlı	Artan maliyet	Dengeli
Operasyon yükü	Kurumda (yüksek)	Sağlayıcıda (düşük)	Paylaşılır
En uygun	Düzenlenen, yüksek hacim	Değişken, deneysel	Karışık gizlilik profili

Bu tabloyu okurken şu ilkeyi akılda tutmak gerekir: seçim tek seferlik ve geri dönülmez değildir. Birçok kurum buluta deneyerek başlar, değer ve hacmi kanıtlandıkça hassas iş yüklerini on-premise'e taşır ve zamanla bir hibrit dengeye oturur. Doğru mimari, dogmatik bir "hep on-premise" veya "hep bulut" değil; her iş yükünü kendi gizlilik, hacim ve maliyet profiline göre doğru yere koyan bilinçli bir dağıtımdır.

On-premise altyapının en çok anılan gerekçesi güvenliktir; ama "on-premise, otomatik olarak güvenli demektir" düşüncesi tehlikeli bir yanılgıdır. On-premise, veriyi dış bir sağlayıcıya göndermeme avantajı verir; ama sistemin kendi içindeki güvenliği yine kurumun kurması gerekir. Yanlış yapılandırılmış bir iç sistem, iyi yönetilen bir bulut hizmetinden daha güvensiz olabilir. Bu yüzden güvenlik, on-premise'in bir hediyesi değil, bir sorumluluğudur.

En temel katman erişim kontrolüdür. Bir on-premise yapay zeka sistemine kim erişebilir, hangi modeli çağırabilir, hangi veriyle sorgu yapabilir — bunların tamamı tanımlı ve denetlenebilir olmalıdır. Özellikle RAG gibi kurumsal belgelere erişen sistemlerde, kullanıcının yetkisine göre filtreleme kritiktir: model, kullanıcının görmeye yetkili olmadığı bir belgeyi asla bağlam olarak almamalıdır. İzin kontrolü üretme adımında değil, veri getirme adımında yapılmalıdır. Bu, veri ikametgahının yalnızca "veri nerede" değil, "veriye kim erişiyor" boyutunu da kapsadığını gösterir.

İkinci katman, modelin kendisine yönelik saldırılara karşı savunmadır. Kötü niyetli girdilerle modelin yönlendirilmesi (prompt injection), sistemin sızdırılması veya kötüye kullanılması gibi riskler, on-premise sistemlerde de geçerlidir. Girdi doğrulama, çıktı denetimi ve koruyucu katmanlar (guardrail) baştan kurgulanmalıdır. Üçüncü katman fiziksel ve ağ güvenliğidir: sunuculara fiziksel erişim, ağ segmentasyonu ve şifreleme. Kapalı bir ağda çalışmak yardımcı olur ama tek başına yeterli değildir; iç tehditler ve yanlış yapılandırmalar hâlâ risktir.

Güvenliğin veri boyutu, Türkiye bağlamında KVKK ile doğrudan ilişkilidir. Kişisel veri içeren belgelerin işlenmesi, saklanması ve erişimi, KVKK yükümlülüklerine tabidir; on-premise olması bu yükümlülükleri ortadan kaldırmaz, ama veri ikametgahını sağlayarak uyumu kolaylaştırır. Bu ilişkiyi KVKK ve yapay zeka tartışmaları yazısında ele alıyoruz. Bu bir hukuki tavsiye değildir; kurumun hukuk ve uyum birimiyle birlikte tasarlanmalıdır. Özetle güvenlik, on-premise yapay zekanın hem en güçlü gerekçesi hem de en dikkatli kurulması gereken katmanıdır.

On-premise yapay zeka kararının finansal boyutu, tek bir donanım faturasından çok daha geniştir. Sağlam bir karar için toplam sahip olma maliyetini (TCO) — genellikle üç yıllık bir ufukta — dürüstçe hesaplamak gerekir. Yalnızca GPU fiyatına bakan bir hesap, kararı yanıltıcı biçimde on-premise lehine çevirir; çünkü buzdağının altındaki maliyetleri görmezden gelir.

TCO'nun bileşenlerini ayrıştıralım. Birincisi sermaye harcamasıdır (CapEx): GPU sunucuları, ağ, depolama, güç ve soğutma altyapısı. İkincisi işletme harcamasıdır (OpEx): elektrik (yüksek yoğunluklu GPU'lar ciddi tüketir), veri merkezi alanı, soğutma, bakım sözleşmeleri ve yedek parça. Üçüncüsü ve çoğu zaman en büyüğü personel maliyetidir: sistemi kuran, işleten, izleyen ve güncelleyen ekibin ücreti — ki bu yetkinlikler pahalıdır. Dördüncüsü fırsat ve risk maliyetidir: donanımın eskimesi (amortisman), atıl kapasite ve olası kesintilerin iş etkisi.

Bu bileşenler bir araya geldiğinde, karşılaştırma nettir: bulut, düşük ve değişken hacimde neredeyse her zaman daha ucuzdur çünkü atıl kapasite ve personel maliyeti doğmaz; kullandığınız kadar ödersiniz. On-premise ise ancak yeterince yüksek ve öngörülebilir bir hacimde birim maliyette öne geçer — bir "başabaş noktası" (break-even) vardır ve bu noktanın altında kalan kullanım için on-premise ekonomik değildir. Bu yüzden ilk soru "on-premise mi bulut mu" değil, "kullanım hacmim başabaş noktasını aşıyor mu" olmalıdır. Maliyet optimizasyonu tekniklerini LLM maliyet optimizasyonu yazısında ayrıntılandırıyoruz.

Dürüst bir TCO hesabının en sık atlanan kalemi, yine operasyon yüküdür. Donanım amortisman tablosunu herkes yapar; ama üç yıl boyunca sistemi işletecek ekibin maliyetini, eğitimini ve elde tutulmasını hesaba katmayan bir plan eksiktir. Gerçek karşılaştırma, "bulut faturası" ile "donanım fiyatı" arasında değil; "bulut toplam maliyeti" ile "on-premise toplam sahip olma maliyeti" arasında yapılmalıdır. Ancak bu dürüst hesap yapıldığında karar sağlam bir zemine oturur.

Buraya kadar anlatılanları pratik bir karara dönüştürelim. On-premise yapay zeka her kurum için doğru değildir; ama bazı kurumlar için neredeyse zorunludur. Doğru kararı, dört soruyu dürüstçe yanıtlayarak verebilirsiniz. Bu sorular, teknik değil stratejik bir çerçeve sunar ve kararı ilkeden değil, kurumun gerçek durumundan çıkarır.

Birinci soru düzenleyici ve gizlilik zorunluluğudur: Verileriniz, yasal veya sözleşmesel nedenlerle dışarı çıkamıyor mu? Cevap kesin evetse, on-premise (veya en azından hibrit) bir tercih değil, bir gerekliliktir; veri ikametgahı pazarlık konusu değildir. İkinci soru kullanım hacmidir: Kullanımınız yüksek, sürekli ve öngörülebilir mi? Öyleyse on-premise birim maliyette avantajlı olabilir; düşük veya değişkense bulut daha ekonomiktir. Üçüncü soru iç yetkinliktir: Sistemi üç yıl işletecek GPU, altyapı, güvenlik ve model operasyonu yetkinliğine sahip bir ekibiniz var mı, kurabilir misiniz? Yoksa on-premise sürdürülemez. Dördüncü soru stratejik bağımsızlıktır: Kritik süreçlerinizi dış bir sağlayıcının sürekliliğine bağlamak sizin için kabul edilebilir bir risk mi?

Bu dört sorunun cevapları bir profil çıkarır. Yüksek gizlilik + yüksek hacim + güçlü iç yetkinlik profili, on-premise için en güçlü adaydır — tipik olarak büyük bankalar, sigorta şirketleri, sağlık kuruluşları, savunma ve kamu. Düşük hacim + zayıf iç yetkinlik profili ise buluta işaret eder. Aradaki geniş bölge — karışık gizlilik profili, orta hacim — hibrit için idealdir. Karar rehberinin özü şudur: on-premise'i bir prestij veya moda olarak değil, bu dört ekseni tartan bir maliyet-risk-egemenlik dengesi olarak ele alın.

On-premise yapay zeka altyapısı kurmak teorik olarak anlaşılırdır; zor olan, üretimde ayakta kalan sağlam bir sistem kurmaktır. Deneyimli bir gözle bakıldığında, başarısız on-premise projeleri benzer hatalarla kırılır. En yaygınları şunlardır:

• Kararı yalnızca donanım fiyatına indirgemek: En sık hata, on-premise kararını GPU faturasına bakarak vermek ve operasyon yükünü, personel maliyetini ve TCO'yu görmezden gelmektir. Buzdağının altı hep daha büyüktür.
• Eşzamanlılığı test etmeden canlıya geçmek: Demoda tek kullanıcıyla mükemmel çalışan sistem, gerçek yük altında çöker. Yük testi yapmadan bir sistemi 'hazır' saymak, en pahalı sürprizlerden birine davetiyedir.
• VRAM'i hafife almak: İşlem gücüne odaklanıp bellek ihtiyacını küçümsemek, modelin ya hiç çalışmamasına ya da diske taşarak sürünmesine yol açar. Belleği önce hesaplayın.
• İzleme kurmadan işletmeye başlamak: Gözlemlenebilirlik olmadan sorunlar ancak kullanıcı şikâyet ettiğinde fark edilir. Ölçülmeyen sistem sessizce bozulur.
• Güncelleme ve geri alma planını atlamak: Model ve yazılım güncellemelerini regresyon testi ve geri alma olmadan yapmak, bir iyileştirmeyi bir kesintiye dönüştürebilir.
• Güvenliği 'kapalı ağ' varsayımına yaslamak: 'Dışarı kapalı, o hâlde güvenli' düşüncesi iç tehditleri ve yanlış yapılandırmaları görmezden gelir. Erişim kontrolü baştan kurulmalıdır.
• İç yetkinlik olmadan başlamak: Sistemi işletecek ekip yokken donanım almak, atıl bir yatırım demektir. Önce ekip, sonra donanım.

Bu hatalardan kaçınmanın en pratik yolu, küçük başlamak ve ölçerek büyümektir. Tüm kurumu tek seferde on-premise'e taşımak yerine, dar bir kullanım senaryosuyla (örneğin tek bir departmanın belge sorgulaması) başlamak riski düşürür ve öğrenmeyi hızlandırır. Küçük ama sağlam bir pilot, büyük ama belirsiz bir vaatten her zaman daha ikna edicidir.

On-premise yapay zeka altyapısını fikirden üretime taşımanın sağlam bir sırası vardır. Aşağıdaki adımları sırayla işaretleyebiliyorsanız, "kendi sunucunda LLM çalıştırma" hedefini dayanıklı bir sisteme dönüştürecek temel atılmış demektir. Bu yol haritası, bir kurulum kadar bir operasyon planıdır.

Nasıl Yapılır

On-premise yapay zeka kurulum yol haritası

Bir on-premise yapay zeka sistemini dar bir pilottan güvenilir üretime taşımak için adım adım yol haritası.

1. 1

   Dar bir kullanım senaryosu seç

   Tüm kurum yerine tek, ölçülebilir bir senaryoyla başla; başarı kriterini bir sayıyla tanımla.

2. 2

   Gizlilik ve düzenleme gereksinimini netleştir

   Hangi verinin dışarı çıkamadığını belirle; on-premise, hibrit veya bulut kararını buradan ver.

3. 3

   Model ve bellek ihtiyacını ölç

   Hedef modeli temsili yükle test ederek gerçek VRAM ve gecikme davranışını ölç; donanımı buna göre boyutlandır.

4. 4

   Donanımı ve servis katmanını kur

   GPU, depolama, ağ, güç-soğutma altyapısını hazırla; modeli batching ve kuyrukla model servis etme katmanında sun.

5. 5

   Eşzamanlılık için yük testi yap

   Gerçekçi eşzamanlı yükle test et; gecikme ve kuyruk davranışını gör, kapasiteyi kanıta dayalı planla.

6. 6

   İzleme, güvenlik ve erişim kontrolünü ekle

   Altyapı, hizmet ve model kalitesi metriklerini izle; erişim kontrolü ve denetim kaydını baştan kur.

7. 7

   Güncelleme ve geri alma sürecini tanımla

   Model, yazılım ve güvenlik güncellemelerini regresyon testi ve geri alma yeteneğiyle süreçleştir.

8. 8

   Ölç, iyileştir, ölçekle

   Kaliteyi ve maliyeti sürekli ölç; en zayıf katmanı iyileştir, kapsamı yalnızca kanıtlandıkça büyüt.

Bu yol haritasının kalbindeki ilke, "ölç, iyileştir, sonra büyüt" döngüsüdür. On-premise yapay zeka projelerini kağıt üzerinde iyi görünüp üretimde çöken projelerden ayıran şey, tam da bu disiplindir. Kurumunuza özel bir on-premise mimari ve pilot yol haritası tasarlamak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin gerekli yetkinliği kazanması için kurumsal eğitim seçeneklerini değerlendirebilirsiniz.

On-premise yapay zekanın sürdürülebilirliği, tekrar tekrar vurguladığımız gibi, donanımda değil ekiptedir. O halde bu ekip nasıl kurulur ve hangi yetkinlikleri bir araya getirir? Başarılı bir on-premise operasyonu, tek bir "her şeyi bilen" kişiye değil, birbirini tamamlayan birkaç yetkinliğe dayanır. Bu yetkinlikleri tanımlamak, işe alım ve eğitim planının temelidir.

Tipik bir on-premise yapay zeka ekibinde şu roller öne çıkar. Altyapı/sistem mühendisi: Donanımı, işletim sistemini, sürücüleri, ağı ve GPU ortamını kurar ve sağlıklı tutar. Model/ML operasyon uzmanı: Model servis etme katmanını, ölçeklenmeyi, değerlendirmeyi ve model güncellemelerini yönetir. Güvenlik ve uyum uzmanı: Erişim kontrolü, KVKK yükümlülükleri ve denetim kaydını sahiplenir. Yazılım mühendisi: Sistemi mevcut kurumsal uygulamalarla entegre eder, arayüz ve orkestrasyonu geliştirir. Küçük bir kurumda bu roller tek kişide birleşebilir; büyük bir kurumda ayrı ekipler olabilir. Önemli olan, her sorumluluğun bilinçli biçimde birine verilmesidir.

Bu ekibin en kritik ama en çok atlanan sorumluluğu operasyonel süreklilik ve nöbettir. Bir sistem 7/24 çalışıyorsa, bir arıza gece yarısı da olabilir; o an kimin arandığı, kimin müdahale edeceği önceden tanımlanmış olmalıdır. "Herkesin işi, kimsenin işi" tuzağı on-premise operasyonda özellikle tehlikelidir; çünkü izleme, güncelleme ve olay müdahalesi net bir sahiplik gerektirir. Bu operasyonel olgunluğu kurmak, teknik bir kurulumdan çok bir organizasyon tasarımı meselesidir.

Yetkinlik boşluğunu kapatmanın iki yolu vardır: işe alım ve eğitim. GPU ve model operasyonu yetkinlikleri Türkiye'de kıt olduğundan, çoğu kurum için en gerçekçi yol, mevcut altyapı ekibini yapay zeka operasyonu konusunda geliştirmektir. Bu, sıfırdan bir ekip kurmaktan hem daha hızlı hem daha kalıcıdır; çünkü kurumu zaten tanıyan bir ekip, yeni yetkinliği daha kolay özümser. Ekiplerinizin bu dönüşümü için yapılandırılmış bir program tasarlamak üzere kurumsal eğitim seçeneklerini ve tüm kavramları derinleştirmek için öğrenme merkezini değerlendirebilirsiniz.

On-premise yapay zeka tartışmasının bir üst çerçevesi egemen yapay zekadır (sovereign AI). Egemenlik, bir kurumun — veya daha geniş ölçekte bir ülkenin — yapay zeka yeteneklerini dış bir sağlayıcıya bağımlı olmadan kendi kontrolünde bulundurmasıdır. On-premise altyapı, bu egemenliğin teknik temelidir; ama egemenlik yalnızca teknik değil, stratejik bir kavramdır. "Verim nerede işleniyor" sorusunun ötesinde, "kritik bir yeteneğimi dış bir aktörün kararına ne kadar bağladım" sorusunu sorar.

Türkiye bağlamında bu tartışma özellikle anlamlıdır. Yüksek yapay zeka benimseme oranına sahip, düzenlenen sektörleri güçlü ve veri egemenliğine önem veren bir ekosistemde, on-premise ve egemen AI çözümlerine talep yapısaldır. Bankacılık ve finansta düzenleyici çerçeve, sağlıkta hasta mahremiyeti, kamuda vatandaş verisi, savunmada gizlilik — bunların hepsi veri ikametgahını bir tercih değil, bir zorunluluk haline getirir. Bu, on-premise yapay zekayı Türkiye'de yalnızca teknik bir seçenek değil, stratejik bir yetkinlik yapar.

Ancak egemenlik, izolasyon demek değildir. Egemen bir yapay zeka stratejisi, dünyaya kapanmak değil; kritik yetenekleri kendi kontrolünde tutarken, kritik olmayan alanlarda küresel ekosistemden yararlanmaktır. Açık ağırlıklı modeller bu dengeyi mümkün kılar: dünyanın ürettiği en iyi modelleri kendi altyapınızda, kendi verinizle, kendi kontrolünüzde çalıştırabilirsiniz. Egemenlik, "her şeyi sıfırdan kendimiz yapalım" değil; "kritik olanı kontrol edelim, gerisinden akıllıca yararlanalım" stratejisidir.

Bu stratejik bakış, on-premise kararını daha geniş bir çerçeveye oturtur. Bir kurum on-premise'e yalnızca maliyet veya gizlilik için değil, uzun vadeli bağımsızlık ve dayanıklılık için de yatırım yapabilir. Bir dış sağlayıcının fiyat politikası değiştiğinde, bir model emekliye ayrıldığında veya jeopolitik bir kısıt oluştuğunda, egemen bir altyapıya sahip kurum bu şoklara karşı korunaklıdır. Bu dayanıklılık, kısa vadeli maliyet tablosunda görünmeyen ama uzun vadede belirleyici olan bir değerdir. On-premise yapay zeka, doğru kurulduğunda, yalnızca bugünün bir ihtiyacını değil, yarının belirsizliğine karşı bir sigortayı da karşılar.

On-premise yapay zeka konuşulurken dikkat neredeyse tümüyle GPU'ya odaklanır; ama sağlam bir altyapı kurulumu, GPU'nun etrafındaki fiziksel ve ağ hazırlığı olmadan ayakta duramaz. Yüksek yoğunluklu GPU sunucuları, sıradan bir kurumsal sunucudan çok farklı fiziksel gereksinimler dayatır ve bu gereksinimler çoğu zaman projenin en geç fark edilen darboğazıdır. Donanımı sipariş etmeden önce, onu barındıracak ortamın hazır olup olmadığını sormak, altyapı kurulumu planının ilk adımıdır.

İlk mesele güç ve soğutmadır. Bir GPU sunucusu, klasik bir sunucunun birkaç katı elektrik çeker ve orantılı biçimde ısı üretir. Mevcut veri merkezinin kabin başına güç kapasitesi ve soğutma kabiliyeti bu yükü kaldıramıyorsa, en pahalı GPU bile ya kısık güçte çalışır ya da aşırı ısınıp performansını düşürür (throttling). Bu yüzden altyapı kurulumu, "kaç kW çekiyoruz, bunu nasıl soğutuyoruz" sorusuyla başlamalı; gerekiyorsa elektrik ve soğutma yükseltmesi donanımdan önce planlanmalıdır. Bu, aylar süren bir tedarik kalemi olabilir ve projeyi geciktiren en sinsi faktördür.

İkinci mesele ağdır. Çok GPU'lu ve çok sunuculu bir kurulumda, bileşenler arası veri trafiği çok yoğundur; düşük gecikmeli ve yüksek bant genişlikli bir iç ağ olmadan GPU'lar birbirini bekler ve pahalı donanım atıl kalır. Ayrıca modelin verinin yanında çalışması için, on-premise yapay zeka sistemi kurumun mevcut ağ topolojisine, güvenlik duvarlarına ve segmentasyon politikalarına entegre edilmelidir. Kapalı veya hava boşluklu (air-gapped) ağlarda çalışılıyorsa, model ağırlıklarının ve güncellemelerin bu ağa nasıl güvenli biçimde taşınacağı da baştan tasarlanmalıdır.

Üçüncü mesele depolamadır. Model ağırlıkları büyük dosyalardır ve hızlı yüklenmeleri gerekir; yavaş depolama, model başlatma süresini ve — RAG kullanılıyorsa — belge erişimini yavaşlatır. Tercih genellikle yüksek hızlı NVMe SSD'dir. Ayrıca veri kümeleri, loglar ve yedekler için ayrı bir kapasite planı gerekir. Depolama, GPU kadar göz alıcı olmasa da, ihmal edildiğinde tüm sistemin hızını sınırlayan sessiz bir darboğazdır. Özetle sağlam bir altyapı kurulumu; güç, soğutma, ağ ve depolamayı GPU ile aynı ciddiyetle planlar. Bu dört hazırlık tamamlanmadan sipariş edilen donanım, kutusunda beklemekten başka işe yaramaz.

On-premise yapay zeka çözümlerinin en yaygın kullanım biçimi, salt model çalıştırmak değil; kurumun kendi belgeleriyle konuşan bir bilgi erişim sistemi kurmaktır. Bu da modelin yanına bir vektör veritabanı ve getirme (retrieval) katmanı eklemek demektir — yani RAG (bilgi getirimiyle üretim) mimarisini on-premise kurmak. Bu senaryo, veri ikametgahının en çok değer kazandığı yerdir: hassas kurumsal belgeler hiç dışarı çıkmadan, kurum içinde işlenir ve yanıtlanır.

RAG'i on-premise çalıştırmak, mimariye yeni bileşenler ekler. Belgelerin metne çevrilip parçalara bölünmesi (chunking), her parçanın bir embedding modeliyle vektöre dönüştürülmesi, bu vektörlerin bir vektör veritabanında saklanması ve sorgu anında en ilgili parçaların getirilmesi gerekir. Bu bileşenlerin hepsi de on-premise çalışabilir; ama her biri ek kaynak ve ek operasyon yükü demektir. Özellikle embedding üretmek de GPU kullanır; büyük belge kütlelerinin ilk indekslenmesi ciddi bir hesaplama yüküdür ve kapasite planlamasında hesaba katılmalıdır.

On-premise RAG'in en büyük avantajı, erişim kontrolünü kurumun tam denetiminde tutmasıdır. Hangi kullanıcının hangi belgeye erişebileceği, getirme katmanında kurumun kendi kimlik ve yetki sistemine bağlanarak filtrelenir; hiçbir veri, dış bir hizmete güvenilmek zorunda kalmadan, kurum sınırında yönetilir. Bu, düzenlenen sektörlerde büyük bir uyum avantajıdır. Karşılığında, vektör veritabanının da izlenmesi, yedeklenmesi ve güncellenmesi gereken bir bileşen olarak operasyon yüküne eklendiğini unutmamak gerekir.

Pratik bir öneri: on-premise RAG kurarken, önce küçük ve temsili bir belge kümesiyle başlamak, getirme kalitesini ölçmek ve ancak kanıtlandıkça belge kapsamını genişletmek en sağlam yoldur. "Tüm kurumun belgelerini tek seferde indeksleyelim" hevesi, hem hesaplama maliyetini patlatır hem de kalite sorunlarını gizler. On-premise yapay zeka bağlamında RAG, modelin tek başına yapamayacağı şeyi — güncel, kaynaklı ve kuruma özel yanıt — mümkün kılan katmandır; ama bu katman da aynı ölçüm ve operasyon disiplinini gerektirir.

On-premise yapay zeka bir kez kritik iş süreçlerinin parçası olduğunda, "sistem çökerse ne olur" sorusu teknik bir ayrıntı olmaktan çıkıp bir iş sürekliliği meselesine dönüşür. Bulutta yedeklilik ve felaket kurtarma çoğunlukla sağlayıcının sorumluluğundadır; on-premise'de bu güvence de kuruma geçer. Bu yüzden ciddi bir on-premise kurulum, tek bir sunucuya bağımlı olmayacak biçimde tasarlanmalıdır.

Yüksek erişilebilirlik (high availability), sistemin tek bir bileşenin arızasında hizmeti kesintiye uğratmadan çalışmaya devam etmesidir. Pratikte bu, tek GPU sunucusuna değil, yükü paylaşan birden çok örneğe dayanmak; bir örnek arızalandığında yük dengeleyicinin trafiği sağlıklı örneklere yönlendirmesi demektir. Bu yedeklilik maliyeti artırır ama kritik sistemlerde pazarlık konusu değildir; çünkü tek bir arıza noktasına (single point of failure) bağlı bir sistem, er ya da geç kesinti yaşar.

Felaket kurtarma (disaster recovery), daha büyük bir olayda — bir donanım grubunun, hatta bir veri merkezinin kaybında — sistemin nasıl geri getirileceğinin planıdır. Model ağırlıkları, yapılandırmalar, vektör veritabanı ve önemli veriler düzenli olarak yedeklenmeli; bu yedeklerin gerçekten geri yüklenebildiği periyodik olarak test edilmelidir. Test edilmemiş bir yedek, bir yedek değil, bir varsayımdır. Kurtarma hedefleri — ne kadar sürede geri dönülmeli (RTO) ve ne kadar veri kaybı kabul edilebilir (RPO) — iş biriminin ihtiyacına göre baştan tanımlanmalıdır.

Bu güvencelerin hepsi ek yatırım ve ek operasyon yükü demektir; bu yüzden her sistem için aynı düzeyde yedeklilik gerekmez. Deneysel bir iç araç için basit bir yedek yeterliyken, 7/24 çalışan kritik bir müşteri sistemi tam yüksek erişilebilirlik gerektirir. Doğru yaklaşım, sistemin iş kritikliğine göre yedeklilik düzeyini bilinçli seçmektir. On-premise yapay zeka kararında bu boyutu atlamak, sistemi ilk ciddi arızada iş sürekliliği riskine sokar.

On-premise yapay zeka yolculuğunun en kritik ve en çok tökezlenen anı, çalışan bir pilotu güvenilir bir üretim sistemine dönüştürmektir. Pek çok proje pilotta parlar ama üretime geçişte sıkışır; çünkü pilot ile üretim arasındaki fark yalnızca ölçek değil, güvenilirlik, güvenlik ve operasyon olgunluğu farkıdır. Pilotta "çalışıyor" demek yeterlidir; üretimde "her zaman, herkes için, güvenle çalışıyor" demek gerekir.

Geçişin ilk adımı, pilotta ölçülen gerçek yükü üretim kapasitesine ölçeklemektir. Pilot genellikle birkaç kullanıcıyla çalışır; üretim yüzlerce eşzamanlı kullanıcı demek olabilir. Bu yüzden geçişten önce gerçekçi bir yük testi yapılmalı, kapasite kanıta dayalı planlanmalıdır. İkinci adım, pilotta belki ihmal edilen üretim gereksinimlerini tamamlamaktır: erişim kontrolü, denetim kaydı, izleme, yedekleme ve güncelleme süreçleri. Bunlar pilotta "sonra ekleriz" diye ertelenmiş olabilir; üretimde ertelenemez.

Üçüncü adım, geçişin kendisini kademeli yapmaktır. Tüm kullanıcıları bir gecede yeni sisteme taşımak yerine, önce dar bir grupla başlamak, davranışı izlemek ve sorunları erken yakalamak riski azaltır. Bu kademeli geçiş, bir sorun çıktığında hızla geri dönebilme (rollback) imkânı da sağlar. Geçiş sırasında eski ve yeni sistemi bir süre paralel çalıştırmak, güven oluşana kadar bir güvenlik ağı sunar.

Son olarak, üretime geçiş bir bitiş değil, bir başlangıçtır. Sistem canlıya alındıktan sonra asıl operasyon dönemi başlar: sürekli izleme, düzenli güncelleme, kapasite takibi ve kullanıcı geri bildiriminin sisteme geri beslenmesi. Bu yüzden geçiş planı, "canlıya aldık, bitti" değil; "canlıya aldık, şimdi işletiyoruz" zihniyetiyle yapılmalıdır. Kurumunuza özel bir geçiş ve operasyon planı için yapay zeka danışmanlığı ile başlayabilirsiniz.

Teknik olarak sağlam bir on-premise yapay zeka sistemi kurmak yetmez; o sistemin kuruma gerçek bir değer üretip üretmediğini de gösterebilmek gerekir. Aksi halde yüksek bir donanım ve operasyon yatırımı, bütçe masasında savunulamaz hale gelir. On-premise yatırımının getirisi birkaç kanaldan gelir ve her biri ayrı ayrı ölçülmelidir.

Birinci kanal, doğrudan maliyet karşılaştırmasıdır: aynı iş yükünü bulutta çalıştırmanın toplam maliyeti ile on-premise toplam sahip olma maliyeti arasındaki fark. Bu karşılaştırma yalnızca yeterince yüksek ve öngörülebilir hacimde on-premise lehine döner; bu yüzden hacim, getiri hesabının merkezindedir. İkinci kanal, parayla ölçülmesi zor ama stratejik olarak değerli olan risk azaltımıdır: veri ikametgahı sayesinde önlenen uyum riski, sağlayıcı bağımlılığından kurtulmanın verdiği pazarlık gücü ve iş sürekliliği güvencesi. Bu değerler bilançoda görünmez ama bir uyum ihlali veya bir sağlayıcı kesintisi yaşandığında birden çok somut hale gelir.

Üçüncü kanal, iş sonuçlarıdır: sistemin çalışanlara kazandırdığı zaman, iyileştirdiği hizmet kalitesi ve artırdığı kapasite. Bunları ölçmek için bir başlangıç ölçümü (baseline) şarttır: sistemden önce bir görev ne kadar sürüyordu, hata oranı neydi? Bu sayılar olmadan, sistemden sonraki iyileşme iddiası havada kalır. On-premise yapay zeka projelerinde en sık finansal hata, getiriyi ölçmeden varsaymaktır.

Bir uyarı gerekir: on-premise yatırımının getirisi yalnızca teknolojiden değil, benimsemeden gelir. En iyi kurulmuş sistem bile, çalışanlar kullanmıyorsa değer üretmez. Bu yüzden getiri hesabı, aracın benimsenmesini sağlayan eğitim ve değişim yönetimini de içermelidir. Doğru boyutlandırılmış, ölçülen ve benimsenen bir on-premise sistem, hem veri egemenliğini korur hem de somut ve sürdürülebilir bir getiri üretir; ama bu getiri, bir varsayımla değil, ölçümle kanıtlanmalıdır.

On-premise yapay zeka kararının en çok yanlış tahmin edilen boyutlarından biri süredir. "Modeli indirir, sunucuya kurarız, birkaç günde biter" beklentisi, teknik bir prototip için doğru olsa da üretim kalitesinde bir sistem için gerçekçi değildir. Sağlam bir kurulum, birbirini izleyen ve bazıları paralel yürüyen birkaç evreye yayılır; ve bu evrelerin en uzunu genellikle donanımın kendisi değil, onu çevreleyen hazırlıktır.

En sinsi gecikme kalemi tedariktir. GPU sunucuları, özellikle yüksek talep dönemlerinde, sipariş edildikten sonra teslim edilene kadar haftalar veya aylar bekletebilir; veri merkezinin güç ve soğutma yükseltmesi gerekiyorsa bu süre daha da uzar. Bu yüzden bir on-premise projesinin takvimi, yazılım kurulumuyla değil, donanım ve veri merkezi tedarikiyle başlar. Bunu erken planlamayan projeler, ekip hazır beklerken donanımın gelmesini bekleyen bir kısırdöngüye düşer.

Gerçekçi bir zihinsel çerçeve şudur: teknik bir pilot birkaç günde ayağa kalkabilir; ama erişim kontrolü, izleme, güvenlik, yük testi ve operasyon süreçleriyle üretim kalitesine ulaşmak haftalar, kurumsal ölçekte aylar sürer. Bu süreyi kısaltmaya çalışmak yerine, dar bir pilotla erken değer göstermek ve paralel olarak üretim altyapısını hazırlamak en sağlam yoldur. On-premise yapay zeka bir sprint değil, planlı bir maratondur; ve en sık hata, maratonu sprint sanmaktır.

On-premise yapay zekayı bugün gerçekçi bir seçenek yapan en önemli gelişme, açık ağırlıklı (open-weight) modellerin olgunlaşmasıdır. Bir modeli kendi altyapınızda çalıştırabilmek için, o modelin ağırlıklarına erişebilmeniz gerekir; kapalı, yalnızca API üzerinden sunulan modeller doğaları gereği on-premise çalıştırılamaz. Açık ağırlıklı modeller ise indirilip kurumun kendi donanımında çalıştırılabildiği için, veri ikametgahı ve egemen AI hedeflerinin teknik temelini oluşturur.

Bu ekosistemin son yıllardaki gelişimi, dengeleri değiştirdi. Bir zamanlar yalnızca en büyük kapalı modellerde bulunan yetenekler, artık kurumun kendi sunucusunda çalışabilen açık ağırlıklı modellerde de makul kalitede sunuluyor. Bu, çoğu kurumsal görev için "en iyi kapalı modeli kullanmak zorunda mıyım, yoksa kendi kontrolümdeki bir modelle de yeterli sonucu alır mıyım" sorusunu gerçek bir seçime dönüştürdü. Cevap göreve bağlıdır: standart özetleme, sınıflandırma ve bilgi erişimi görevlerinde iyi seçilmiş bir açık ağırlıklı model çoğu zaman yeterlidir.

Açık ağırlıklı modellerin bir avantajı da bağımlılıktan kurtulmaktır. Kendi altyapınızda çalışan bir model, bir sağlayıcının onu emekliye ayırmasından, fiyatını değiştirmesinden veya erişimi kısıtlamasından etkilenmez; model ağırlıkları sizde olduğu sürece, sistem sizin kontrolünüzdedir. Bu, egemen bir yapay zeka stratejisinin kalbidir. Karşılığında, modeli seçme, değerlendirme, güncelleme ve çalıştırma sorumluluğu tümüyle kuruma geçer — yani açık ağırlıklı model, özgürlükle birlikte operasyon yükünü de getirir.

Pratik bir not: açık ağırlıklı model ekosistemi hızla değişir. Bu yüzden bir modele kalıcı biçimde bağlanmak yerine, model servis etme katmanını modeli görece kolay değiştirilebilir kılacak biçimde tasarlamak akıllıcadır. Bugün en iyi olan model altı ay sonra yerini bir başkasına bırakabilir; dayanıklı olan, belirli bir model değil, modeli değiştirilebilir bir bileşen olarak gören mimaridir. On-premise yapay zeka stratejinizi belirli bir modele değil, sağlam bir altyapı kurulumu ve değerlendirme disiplinine dayandırın.

Bu rehberde anlatılan her şeyi tek bir pratik ana indirmek gerekirse, o an karar anıdır. On-premise yapay zeka size uygun mu, yoksa bulut veya hibrit mi daha doğru? Aşağıdaki öz değerlendirme, kararı duygusal veya moda temelli değil, kurumunuzun gerçek durumu temelinde vermenize yardımcı olur. Her soruyu dürüstçe yanıtlayın; toplam resim, doğru yönü gösterir.

Gizlilik ekseni: Verileriniz düzenleyici veya sözleşmesel nedenlerle kurum sınırından çıkamıyor mu? Cevabınız kesin evetse, on-premise veya hibrit güçlü bir zorunluluktur. Hacim ekseni: Yapay zeka kullanımınız yüksek, sürekli ve öngörülebilir mi, yoksa düşük ve değişken mi? Yüksek ve öngörülebilir hacim on-premise'i, düşük ve değişken hacim bulutu işaret eder. Yetkinlik ekseni: Sistemi üç yıl işletecek altyapı, güvenlik ve model operasyonu ekibiniz var mı, kurabilir misiniz? Yoksa on-premise sürdürülemez ve bulut riski azaltır.

Bu üç eksene bir de zaman ve bütçe boyutu eklenir. On-premise altyapı kurulumu, donanım tedariki ve veri merkezi hazırlığı nedeniyle haftalar hatta aylar sürebilir; bulut ise günler içinde başlar. Aceleniz varsa ve değeri hızla kanıtlamanız gerekiyorsa, buluttan başlayıp değer kanıtlandıkça hassas yükleri on-premise'e taşımak sıklıkla en akılcı yoldur. Bu, kararı ikili bir "ya hep ya hiç" seçiminden çıkarır ve zaman içinde evrilen bir stratejiye dönüştürür.

Öz değerlendirmenin özü şudur: on-premise yapay zeka bir prestij simgesi veya bir moda değil, dört eksende — gizlilik, hacim, yetkinlik, zaman — tartılan bir mühendislik ve maliyet kararıdır. Bu eksenlerin çoğu on-premise'i işaret ediyorsa, sağlam bir altyapı kurulumu planıyla ilerleyin; işaret etmiyorsa, buluttan veya hibritten başlamak daha dürüst bir tercihtir. Doğru karar, en pahalı veya en gösterişli olan değil; kurumunuzun gerçek profiline en iyi oturan seçenektir. Bu değerlendirmeyi kurumunuza özel yapmak için yapay zeka danışmanlığı ile başlayabilirsiniz.

On-premise AI nasıl kurulur?

On-premise yapay zeka kurulumu dört katmanda ilerler. Önce donanım katmanı hazırlanır: yeterli GPU belleğine (VRAM) sahip sunucular, hızlı depolama ve düşük gecikmeli ağ. Ardından model seçilir ve bir servis (inference) katmanıyla model servis etme kurgulanır — modelin bir API arkasında, kuyruk ve toplu işleme ile sunulması. Üçüncü adım orkestrasyon ve ölçeklenmedir: birden fazla eşzamanlı isteği yük dengeleyerek karşılamak. Son adım izleme, bakım ve güncellemedir. Doğru sıra; küçük bir pilotla başlamak, gecikme ve eşzamanlılığı ölçmek, sonra kapasiteyi kanıta dayalı büyütmektir. Kendi sunucunda LLM çalıştırmak teknik olarak birkaç günde ayağa kalkabilir; üretim kalitesine ulaşmak ise haftalar sürer.

On-premise AI için hangi bileşenler gerekir?

Asgari bir on-premise yapay zeka yığını şu bileşenlerden oluşur: GPU'lu sunucu(lar) ve yeterli VRAM; bir inference/servis motoru (model servis etme katmanı); model ağırlıklarının saklandığı hızlı depolama; RAG kullanılıyorsa bir vektör veritabanı; kimlik doğrulama ve erişim kontrolü; yük dengeleme ve kuyruk yönetimi; gözlemlenebilirlik (loglama, metrik, izleme); ve güncelleme/yama süreçleri. Bunların üzerinde bir orkestrasyon katmanı bileşenleri birbirine bağlar. Donanımın kalbi GPU ve belleğidir; yazılımın kalbi ise servis ve izleme katmanıdır.

On-premise AI'ın operasyon yükü nedir?

Operasyon yükü, on-premise yapay zekanın en çok hafife alınan maliyetidir. Donanım satın alındıktan sonra iş bitmez; asıl yük süreğendir: işletim sistemi ve sürücü yamaları, GPU firmware güncellemeleri, model sürümlerinin güncellenmesi ve regresyon testi, kapasite planlama, arıza durumunda nöbet, yedekleme, güvenlik izleme ve maliyet takibi. Bulutta sağlayıcının üstlendiği bu işler on-premise'de kuruma geçer. Bu yüzden karar verirken donanımın satın alma fiyatına değil, üç yıllık toplam sahip olma maliyetine ve gereken iç yetkinliğe bakmak gerekir.

On-premise mi bulut mu daha iyi?

Tek bir doğru cevap yoktur; karar dört eksende verilir. Veri gizliliği ve düzenleyici zorunluluk yüksekse (veri ikametgahı gerekiyorsa) on-premise öne çıkar. Kullanım hacmi yüksek ve öngörülebilirse on-premise birim maliyette avantajlıdır. Kullanım düşük, değişken veya deneysel ise bulut daha ekonomiktir. İç yetkinlik güçlüyse on-premise sürdürülebilir; zayıfsa bulut riski azaltır. Çoğu kurum için en gerçekçi yanıt hibrittir: hassas veri on-premise, hassas olmayan yük bulutta.

Egemen (sovereign) AI ne demektir?

Egemen yapay zeka, bir kurumun veya ülkenin yapay zeka yeteneklerini — veri, model, altyapı ve işletim dahil — dış bir sağlayıcıya bağımlı olmadan kendi kontrolü altında bulundurmasıdır. On-premise altyapı bunun teknik temelidir: veri ikametgahı sağlanır, model ağırlıkları kurumda kalır ve sistem dış bir hizmetin kesintisinden veya politika değişikliğinden etkilenmez. Egemenlik, yalnızca sunucunun yeri değil; kesinti, fiyat değişikliği veya erişim kısıtı durumunda kimin karar verdiği sorusudur.

On-premise LLM için ne kadar GPU belleği gerekir?

Kesin sayı modelin boyutuna, sayısal hassasiyetine (quantization) ve hedeflenen eşzamanlılığa bağlıdır; tek bir evrensel rakam yoktur. Genel ilke: model ağırlıkları belleğe sığmalı, üzerine eşzamanlı isteklerin bağlamı için pay bırakılmalıdır. Ağırlıkları küçülten quantization, daha küçük bellekte daha büyük model çalıştırmayı mümkün kılar ama kaliteyi bir miktar etkileyebilir. Doğru yaklaşım, hedef modeli temsili bir yükle test edip gerçek bellek ve gecikme davranışını ölçmektir. Bellek yetmezse sistem ya isteği reddeder ya da diske taşarak çok yavaşlar; bu yüzden VRAM en belirleyici parametredir.

Kısaca, on-premise yapay zeka; dil modellerini ve destekleyici bileşenleri bir bulut sağlayıcı yerine kurumun kendi kontrolündeki donanımda çalıştıran bir mimaridir. Kurulum dört katmandan oluşur: donanım (özellikle GPU ve VRAM), model seçimi ve model servis etme, orkestrasyon-ölçeklenme, ve izleme-bakım-güncelleme. En büyük değeri veri ikametgahı ve veri egemenliğidir; en büyük maliyeti ise donanım değil, süregelen operasyon yüküdür. On-premise her kurum için doğru değildir; karar, gizlilik, hacim, iç yetkinlik ve stratejik bağımsızlık eksenlerinde verilir ve çoğu kurum için en gerçekçi cevap hibrittir.

En önemli mesaj şudur: on-premise yapay zeka bir donanım projesi değil, bir operasyon projesidir; başarısı, en pahalı GPU'yu almaktan değil, o donanımın etrafında izleme, güncelleme, güvenlik ve ekip disiplinini kurmaktan gelir. Doğru boyutlandırılmış donanım, iyi kurgulanmış bir model servis etme katmanı, kanıta dayalı kapasite planlama, sağlam erişim kontrolü ve sürekli ölçüm bir araya geldiğinde, kurum hem veri egemenliğini korur hem güvenilir bir hizmet sunar. İlgili konuları derinleştirmek için GPU nedir, on-premise kurulum saha notu ve LLM maliyet optimizasyonu yazılarına bakabilir; kurumunuza özel bir on-premise yapay zeka mimarisi ve yol haritası için yapay zeka danışmanlığı ile başlayabilir, ekipleriniz için kurumsal eğitim seçeneklerini ve öğrenme merkezini değerlendirebilirsiniz.