Saha Notu: On-Premise Kurulumlarda Karşılaştığım Gerçekler

Bu bir saha notu. On-premise kurulum deneyimi üzerine, farklı ölçeklerdeki kurulumlarda tekrar tekrar karşılaştığım gerçekleri; beklenen ile gerçekleşen kurulum süresi arasındaki farkı, donanım tedariki sürprizlerini, ağ kısıtlarını, güvenlik politikası çatışmalarını ve kurulumdan sonra başlayan güncelleme yükünü olduğu gibi anlatıyorum. Amacım bir ürün övmek değil; on-premise bir yapay zeka çözümü kurmayı düşünen ekiplere, sahada nelerin gerçekten zaman aldığını ve nasıl hazırlanılırsa bu sürprizlerin sürpriz olmaktan çıkacağını göstermek.

Baştan söyleyeyim: on-premise kurulum deneyimi bana öğrettiği tek bir cümleye indirgenebilir — zorluk modelde değil, modelin etrafındaki kurumsal katmanlardadır. Kurulumun teknik adımları çoğu zaman bir günde biter; asıl takvimi belirleyen donanım tedariki, ağ ve güvenlik onayları ile işletme sorumluluğudur. Bu yazı, o katmanları bir bir açıyor.

Tanım

On-premise kurulum (yerinde kurulum)

Bir yapay zeka çözümünü, bulut sağlayıcı yerine kurumun kendi veri merkezinde veya kontrol ettiği donanımda kurup işletme biçimi. Model ağırlıkları, veriler ve çıkarım altyapısı kurumun sınırları içinde tutulur; veri ikametgahı ve erişim kontrolü kuruma aittir. On-premise kurulum deneyimi, bu modelin asıl maliyetinin donanım tedariki, ağ kısıtları, güvenlik politikaları ve kurulumdan sonraki güncelleme yükü gibi işletme kalemlerinde ortaya çıktığını gösterir.

Ayrıca: yerinde kurulum, on-prem, kendi sunucunda LLM, egemen AI altyapısı, veri ikametgahı

Kısa cevabı en başa koyayım: on-premise kurulum deneyimi, bir yapay zeka sistemini kurumun kendi donanımında kurup işletmenin, teknik bir işten çok bir tedarik, ağ, güvenlik ve işletme koordinasyonu işi olduğunu gösterir. Modeli indirip çalıştırmak, tüm sürecin en kısa ve en kolay adımıdır; zamanı yiyen, onun etrafındaki hazırlıktır.

Bu çerçeveyi bir cümleyle özetlersem: on-premise, bir kurulum projesi değil, bir işletme taahhüdüdür. Kararların çoğu kurulumdan önce verilir; kötü verilirse, kurulumun kendisi sorunsuz görünse bile sistem üretimde takılır. Bu yazıda paylaştığım her gözlem, aynı temaya çıkar — planı teknolojiye değil, kurumsal gerçekliğe göre yapın.

On-premise ile bulut arasındaki temel kararı ve egemen AI altyapısının bütününü On-Premise ve Egemen AI Altyapısı yazısında ele alıyorum; bu saha notu, o resmin kurulum ve işletme tarafındaki gerçekleri üzerine. Donanımın neden bu kadar belirleyici olduğunu anlamak için GPU Nedir? Kurumsal AI'da Neden Gerekir? yazısı iyi bir zemin sağlar.

Sahada en çok kırılan beklenti süredir. Ekip, "modeli kurarız, birkaç günde ayakta olur" diye planlar; gerçek, çoğu zaman haftalara yayılır. Ama dikkat: bu gecikme, kurulumun teknik zorluğundan gelmez. Modeli bir sunucuya kurmak, konteyneri ayağa kaldırmak ve ilk yanıtı almak gerçekten de kısa bir iştir. Uzayan, ona giden yoldur.

Takvimi neyin uzattığını yıllar içinde bir desen olarak gördüm. Önce donanım tedariki: sunucu siparişi, teslim, iç satın alma onayı. Sonra veri merkezi hazırlığı: kabin, güç hattı, soğutma, ağ portu. Ardından ağ kısıtları: kapalı ortama paket ve model taşıma. Sonra güvenlik onayı: imaj tarama, erişim yetkisi, politika istisnası. Bu katmanların her biri kendi süresini ekler ve en kötüsü, çoğu seri değil paralel yürütülebilecekken seri yürütülür. Biri bitmeden diğeri başlamaz; oysa büyük kısmı aynı anda ilerleyebilir.

İkinci sık neden, onayların bir "bakım penceresine" veya haftalık toplantıya bağlı olmasıdır. Kurumsal bir veri merkezinde ağ değişikliği veya güvenlik istisnası çoğu zaman anında yapılmaz; belirli pencerelerde toplu yapılır. Bir belge eksikse veya bir onay o pencereyi kaçırırsa, süreç bir hafta daha bekler. Saha gözlemi net: gecikmenin nedeni neredeyse her zaman eksik hazırlık ve seri işleyen onaylardır, teknik bir duvar değil.

Pratik bir öneri: takvimi yaparken her katman için "kim onaylıyor, hangi belgeyi istiyor, ne zaman toplanıyor" sorularını önden yanıtlayın. Bu üç soru, sürpriz gecikmelerin büyük kısmını görünür kılar. On-premise kurulum deneyimi boyunca, bu üç soruyu baştan soran ekipler ile sormayanlar arasındaki fark, neredeyse her zaman haftalarla ölçüldü.

Donanım tedariki, planın en kırılgan halkasıdır ve en sık hafife alınan kalemidir. GPU sunucuları hazır rafta bekleyen ürünler değildir; sipariş, teslim, gümrük ve iç satın alma onayı zinciri kolayca haftalara yayılır. Sahada gördüğüm en yaygın hata, projeyi donanım elde varmış gibi planlamaktır; oysa donanımın gelmesi çoğu zaman tüm takvimin en uzun tek kalemidir.

Donanım geldiğinde de iş bitmez. Sunucu fiziksel olarak veri merkezine yerleşmeli, uygun bir kabine takılmalı, yeterli güç hattı çekilmeli ve — en çok atlanan kalem — soğutma kapasitesi yetmelidir. GPU sunucuları yüksek güç çeker ve çok ısı üretir; mevcut bir veri merkezi, ek bir yoğun sunucuyu güç veya soğutma açısından kaldıramayabilir. Bu, satın almadan bağımsız, tesis tarafında ayrı bir hazırlık gerektirir. Donanım tedariki bu yüzden bir satın alma kalemi değil, güç, soğutma, kabin ve ağı da içeren bütünsel bir kapasite planlama işidir.

Kapasite planlamasının kalbinde ise sık yapılan bir hesap hatası yatar: kapasiteyi tek kullanıcıya göre planlamak. Modeli kurup tek başınıza denediğinizde her şey hızlı ve akıcıdır; ama on kişi aynı anda uzun bir belge sorduğunda tablo değişir. Eşzamanlı istekler GPU belleğini (VRAM) hızla doldurur, kuyruk oluşur ve yanıt süreleri uzar. Doğru kapasite planlaması, "kaç kullanıcı aynı anda, ne uzunlukta istek gönderecek" sorusundan başlar; tek kullanıcı testi yanıltıcıdır.

Donanım tedariki ve kapasite planlamada beklenti ile saha gerçeği

Konu	Yaygın beklenti	Saha gerçeği
GPU teslimi	Kısa sürede gelir	Sipariş-teslim-onay zinciri haftalara yayılır
Kapasite ölçütü	Tek kullanıcı testi yeter	Eşzamanlı yük belirleyicidir
VRAM	Model sığıyorsa yeter	Eşzamanlılık + uzun bağlam VRAM'i doldurur
Güç ve soğutma	Mevcut veri merkezi kaldırır	Ek yoğun sunucu güç/soğutma limitine takılır
Satın alma	Teknik karar	Bütçe ve onay süreci ayrı takvim ister

VRAM'in neden bu kadar belirleyici olduğunu ve GPU'nun kurumsal AI'daki rolünü GPU Nedir? yazısında ayrıntılandırıyorum. Buradaki saha dersi şu: donanım tedariki takvimi başlatan kalemdir, o yüzden projede en erken netleşmesi gereken karardır. Donanımı beklerken ağ, güvenlik ve veri hazırlığını paralel yürütmek, kaybedilen haftaların büyük kısmını geri kazandırır.

Kapasite konusunu ayrı bir başlıkta derinleştirmeye değer, çünkü sahada en çok yanılan hesap budur. Bir dil modelinin bir sunucuda çalışması iki ayrı soruyu içerir: model belleğe sığıyor mu, ve kaç eşzamanlı isteği makul sürede yanıtlayabiliyor. Birincisi statik, ikincisi dinamik bir sorudur ve ikisi çok farklı kapasite gerektirir.

Model belleğe sığma sorusu görece basittir: modelin boyutu ve seçilen nicemleme (quantization) düzeyi, gereken VRAM'i büyük ölçüde belirler. Ama asıl sürpriz eşzamanlılıkta çıkar. Her aktif istek, modelin ağırlıklarına ek olarak kendi bağlamı için bellek tüketir; uzun belgelerle çalışan kullanıcılar bu tüketimi katlar. Tek kullanıcıyla rahat çalışan bir kurulum, on eşzamanlı kullanıcıda belleği doldurup istekleri kuyruğa alabilir. Yanıt "yavaşladı" diye şikayet gelir; oysa sorun modelde değil, kapasite planının eşzamanlılığı hesaba katmamasındadır.

Bu yüzden saha gözlemim, kapasiteyi her zaman "tepe eşzamanlı kullanıcı" üzerinden planlamaktır. Kaç kişi aynı anda kullanacak, tipik ve en uzun istek ne kadar, kabul edilebilir yanıt süresi ne — bu üç sayı olmadan doğru donanım seçilemez. Ayrıca eşzamanlılık arttıkça tek büyük sunucu yerine yükü dağıtmak (birden çok GPU veya sunucu) gerekebilir; bu da ağ, yük dengeleme ve işletme karmaşıklığı ekler. Çıkarım maliyetini ve model seçimini optimize etmenin yollarını LLM Maliyet Optimizasyonu yazısında ele alıyorum; on-premise'de bu optimizasyonlar doğrudan gereken donanım miktarını, dolayısıyla bütçeyi düşürür.

On-premise ile bulut arasındaki en büyük operasyonel fark, çoğu zaman ağdadır. Bulutta bir bağımlılığı, konteyner imajını veya model ağırlığını indirmek bir dakika sürer; kapalı veya air-gap (internetten fiziksel olarak ayrılmış) bir kurumsal ağda aynı iş, kontrollü bir aktarım süreci gerektirir ve günlere yayılabilir. Ağ kısıtları, on-premise kurulum deneyimimde en çok küçümsenen ve en çok zaman kaybettiren başlıklardan biridir.

Sorunun kaynağı basittir: modern yazılım kurulumu, sessizce internete bağlanmayı varsayar. Bir konteyner ayağa kalkarken onlarca bağımlılığı dış kayıtlardan çeker; bir model çerçevesi, ağırlıkları bir depodan indirir. Kapalı ağda bu adımların hiçbiri çalışmaz. Çözüm, her paketin, imajın ve model ağırlığının önce dış ortamda toplanıp, güvenli bir aktarım yöntemiyle (onaylı bir aktarım istasyonu veya iç ayna kayıt) içeri taşınmasıdır. Bu, kurulumdan önce planlanması gereken ayrı bir lojistik iştir.

İç ayna kayıt (mirror registry) kurmak, tekrar eden kurulumlar için en sağlıklı yatırımdır: bağımlılıklar ve imajlar bir kez içeri alınır, sonra tüm kurulumlar oradan beslenir. Ama bu aynanın da güncellenmesi gerekir; yeni bir bağımlılık veya model sürümü, aynı kontrollü aktarım sürecinden geçer. Ağ kısıtları bu yüzden bir kez çözülüp unutulan değil, süreklilik gerektiren bir başlıktır. Veri ikametgahı ve verinin kurum sınırında kalması gerekçesiyle kapalı ağ tercih ediliyorsa, bu tercih genellikle bilinçlidir; ama bedeli, kurulum ve güncellemenin bu ekstra adımı içermesidir.

Bir başka sık ağ sorunu, iç servisler arası iletişimin kurumsal güvenlik duvarı ve segmentasyon kurallarıyla çatışmasıdır. Model servisi, vektör veritabanı, arayüz ve kimlik doğrulama farklı ağ bölgelerinde olabilir; aralarındaki portların açılması ayrı bir onay ister. Bu portların hangi bölgeler arasında, hangi protokolle açılacağını kurulumdan önce belgelemek, sonradan yaşanan "servis birbirini göremiyor" sorunlarının çoğunu önler.

Ağ kısıtlarının hemen yanında, onunla iç içe geçmiş bir başlık durur: güvenlik politikası çatışmaları. Kurumsal bir veri merkezinde her kurulum adımı, güvenlik ekibinin politikalarıyla uyumlu olmak zorundadır ve bu politikalar, standart kurulum yönergelerinin varsaydığı özgürlüğü çoğu zaman kısıtlar. Saha gözlemim net: on-premise projelerinde en çok zaman, güvenlik ekibiyle geç kurulan diyalogda kaybedilir.

En sık karşılaştığım çatışmalar şunlar: dış registry yasağı (imajların yalnızca onaylı iç kaynaktan çekilebilmesi), zorunlu imaj tarama (her konteyner imajının güvenlik taramasından geçmeden çalıştırılamaması), port kısıtları (yalnızca açıkça onaylı portların açık olması), ayrıcalıklı erişim onayı (kök/yönetici yetkisi gerektiren adımların ayrı onay istemesi) ve gizli bilgi yönetimi (parola, anahtar ve sertifikaların politika gereği belirli bir kasada tutulması). Standart bir kurulum kılavuzu bu adımların hiçbirini varsaymaz; sonuç, her adımda "bu bizde yasak" cevabıyla duran bir kurulumdur.

Bu çatışmaların çözümü teknik değil, sıralamayla ilgilidir: güvenlik ekibini kurulumun ortağı yapın, sonradan gelen denetçisi değil. Mimariyi, veri akışını, gereken portları ve erişim yetkilerini kurulumdan önce güvenlik ekibiyle birlikte belgeleyip onaylatmak, sonradan yaşanan tıkanmaların büyük kısmını ortadan kaldırır. Bu belge aynı zamanda risk değerlendirmesinin de temelini oluşturur; bir AI sistemi için risk dokümanının nasıl hazırlandığını AI Risk Değerlendirme Dokümanı Nasıl Hazırlanır? yazısında adım adım anlatıyorum.

Regüle sektörlerde bu tablo daha da katmanlıdır; bilgi güvenliği, uyum ve hukuk gözden geçirmeleri sırayla gelir. O ortamlardaki onay katmanlarını ve nasıl hızlandırıldığını Regüle Sektörde AI Onay Süreçleri saha notunda ayrı ele alıyorum; on-premise ve regüle sektör bir araya geldiğinde hazırlık disiplini daha da belirleyici olur.

Kapalı bir ağda çözülmesi gereken özel bir alt başlık, model ağırlıklarının kendisidir. Bir açık ağırlıklı modeli on-premise çalıştırmak için o modelin ağırlık dosyalarını içeri taşımanız gerekir; bu dosyalar çoğu zaman onlarca gigabayttır ve kapalı ağda internetten çekilemez. Ağ kısıtları başlığında anlattığım aktarım süreci burada da geçerlidir, ama ek bir boyutu vardır: lisans ve sürüm yönetimi.

Her açık ağırlıklı modelin bir lisansı vardır ve bu lisansın kurumsal kullanıma, ticari kullanıma ve türev üretimine izin verip vermediği önceden okunmalıdır. Sahada gördüğüm bir hata, modeli teknik olarak seçip lisans uygunluğunu sonradan kontrol etmektir; oysa lisans, hukuk ekibinin de dahil olması gereken bir karardır. Açık kaynak ve açık ağırlıklı modellerin kurumsal kullanımındaki nüansları On-Premise ve Egemen AI Altyapısı yazısında da ele alıyorum.

İkinci konu sürüm yönetimidir. Bir modeli içeri aldıktan sonra iş bitmez; model geliştikçe yeni sürümler çıkar ve her yeni sürüm aynı aktarım ve doğrulama sürecinden geçmelidir. Ayrıca hangi sürümün üretimde olduğunu, hangi dosya bütünlük değerine (checksum) sahip olduğunu ve nereden geldiğini izlemek gerekir; kapalı ortamda bu izlenebilirlik, hem güvenlik hem de tekrarlanabilirlik açısından kritiktir. Model ağırlığı tedariki, donanım tedariki kadar planlanması gereken ayrı bir kalemdir.

Şimdi çoğu ekibin en çok şaşırdığı gerçeğe geliyorum: on-premise, kurulunca biten bir proje değildir; asıl iş kurulumdan sonra başlar. Güncelleme yükü, bulutta sağlayıcının sessizce üstlendiği ama on-premise ortamda tamamen sizin ekibinize düşen sürekli bir bakım işidir. Bu yükü baştan hesaba katmayan projeler, kurulumu başarıyla tamamlayıp birkaç ay sonra bakım altında ezilir.

Güncelleme yükü birkaç koldan gelir ve her biri süreklidir. Model sürümleri yenilenir ve yeni sürüm test edilip devreye alınmalıdır. GPU sürücüsü, CUDA sürümü ve model çerçevesi arasındaki uyum korunmalıdır; birini güncellerken diğerini kırmamak, sahada sıkça yaşanan bir baş ağrısıdır. İşletim sistemi ve konteyner imajları güvenlik yamalarını almalıdır; bir güvenlik açığı çıktığında yama, kapalı ağda yine o kontrollü aktarım sürecinden geçer. Sertifikalar yenilenmeli, yedekler alınmalı ve düzenli olarak geri yükleme denenerek doğrulanmalıdır.

Bu kalemlerin hiçbiri tek başına dramatik değildir; ama toplamı, sürekli bir işletme yüküdür ve bir sahibi olmalıdır. Saha gözlemim şu: güncelleme yükünün sahibi belirsizse, sistem yavaşça güncelliğini yitirir — sürücüler eskir, yamalar birikir, model sürümü geride kalır — ve bir gün beklenmedik bir uyumsuzluk üretimi durdurur. On-premise'i bir işletme taahhüdü olarak görmek, tam da bu yükü baştan sahiplendirmek demektir.

Bulut ve on-premise: kurulumdan sonraki güncelleme yükü kimde?

Bakım kalemi	Bulut (yönetilen)	On-premise
Model sürüm yenileme	Sağlayıcı üstlenir	Sizin ekibiniz test edip alır
Sürücü/CUDA uyumu	Görünmez	Sizin sorumluluğunuz
Güvenlik yaması	Otomatik	Kapalı ağda kontrollü aktarım
Sertifika/yedek	Büyük ölçüde yönetilir	Sizin süreciniz
Kapasite büyütme	Tıklamayla ölçek	Yeni donanım tedariki gerekir

Bu tablo, on-premise kararının neden yalnızca kurulum maliyetiyle değerlendirilemeyeceğini gösterir. Kurulum bir kerelik bir maliyettir; güncelleme yükü ise sistemin ömrü boyunca süren bir işletme kalemidir. Üretim ortamında bir LLM sistemini izlemenin ve operasyonel disiplinin çerçevesini LLM Maliyet Optimizasyonu ve genel işletme prensipleri açısından değerlendirmek, bu yükü yönetilebilir kılar.

On-premise kararının en çok gizlenen maliyeti, iç yetkinliktir. Bir modeli kurup çalıştırmak, biraz teknik bilgiyle görece kolaydır; onu üretimde 7/24 ayakta tutmak, izlemek, bir sorun çıktığında teşhis edip müdahale etmek ise apayrı bir uzmanlıktır. Saha gözlemim, bu iki işi aynı kişiye ya da hiç kimseye bırakan projelerin, kurulum başarısına rağmen üretimde zorlandığıdır.

Somutlaştırayım. Kuruluma emek veren kişi, çoğu zaman bir denemeyi ayağa kaldırmayı bilen bir mühendistir; ama gece yarısı GPU sürücüsü bir güncellemeyle bozulduğunda, ya da yanıt süreleri açıklanamayan biçimde uzadığında, ya da bir güvenlik yaması sistemi durdurduğunda müdahale etmek, altyapı ve operasyon deneyimi ister. Bu, bir "kurulum becerisi" değil, bir "işletme becerisi"dir. İkisini karıştırmak, on-premise projelerinde en pahalı yanılgılardan biridir.

İç yetkinlik gerçeğini baştan dürüstçe değerlendirmek gerekir: bu sistemi kim izleyecek, kim yedekleyecek, kim güncelleyecek, bir olay olduğunda kim nöbette olacak? Eğer bu sorulara net bir cevap yoksa, kurulum teknik olarak başarılı olsa bile sistem kırılgandır. Bu yüzden on-premise kararı, bir donanım ve yazılım kararı olduğu kadar bir ekip ve yetkinlik kararıdır. Ekiplerin bu yetkinliği kazanması için gereken eğitim yaklaşımını kurumsal eğitim tarafında ele alıyorum; iç yetkinliği kurulumun bir parçası olarak planlamak, sonradan dışarıdan kapatmaya çalışmaktan her zaman ucuzdur.

Bir de kullanıcı tarafı vardır: en iyi kurulmuş sistem bile, çalışanlar benimsemezse değer üretmez. Aracın iş akışına oturması, güvenilir bulunması ve düzenli kullanılması ayrı bir başarı boyutudur. Kullanıcı benimsemesini belirleyen faktörleri ve neden ilk hafta zirvesinden sonra kullanımın düşebildiğini Kullanıcı Benimsemesi saha notunda ayrı ele alıyorum; on-premise bir sistemi ayakta tutmak, hem teknik işletmeyi hem de bu benimseme çalışmasını içerir.

İşletme yükünün somut karşılığı, izleme ve olay müdahalesi altyapısıdır. Bulutta çoğu izleme sağlayıcının panosunda hazır gelir; on-premise ortamda bu katmanı da siz kurarsınız. Ve bu, çoğu ekibin kurulum telaşında en son düşündüğü, ama üretimde en çok ihtiyaç duyduğu şeydir.

Minimum bir izleme kurulumu şu soruları anlık yanıtlayabilmelidir: sistem ayakta mı, yanıt süreleri normal mi, GPU ve VRAM kullanımı hangi seviyede, kuyrukta bekleyen istek var mı, hata oranı arttı mı? Bu göstergeler olmadan, bir kullanıcı "sistem yavaş" dediğinde nereye bakacağınızı bilemezsiniz. Ayrıca kayıt (log) tutmak, hem sorun teşhisi hem de güvenlik denetimi için gereklidir; kimin ne zaman hangi isteği gönderdiği, kapalı bir kurumsal ortamda çoğu zaman politika gereğidir.

Olay müdahalesi ise bir adım ötesidir: bir şey bozulduğunda ne olacak? Kimin haberi olacak, kim müdahale edecek, sistem tamamen durursa geri dönüş planı ne? Bu soruları kurulumdan önce yanıtlamak, üretimde bir kriz anında panik yaşamamayı sağlar. Saha gözlemim, izleme ve olay müdahalesini "sonra ekleriz" diyen ekiplerin, ilk ciddi olayda bu katmanı aceleyle ve eksik kurduğudur. Bu katmanı kurulumun bir parçası olarak planlamak, sonradan telafi etmekten çok daha ucuz ve sağlıklıdır.

On-premise kararının ardında genellikle güçlü bir gerekçe vardır ve bu gerekçe, kurulumun tüm zorluklarına değmesini sağlar: veri ikametgahı. Bazı kurumlar, verilerinin kurum sınırının veya ülke sınırının dışına çıkmasını istemez ya da hukuken çıkaramaz; bu durumda modeli veriye getirmek, veriyi buluta göndermekten daha doğru bir tercihtir. On-premise, veri ikametgahını en güçlü biçimde garanti eden mimaridir çünkü veri hiç kurumun dışına çıkmaz.

Bu gerekçe, özellikle kişisel veri ve regüle sektör bağlamında belirleyicidir. KVKK ve yapay zeka etrafındaki güncel tartışmaların çoğu, verinin nerede işlendiği ve kimin eriştiği sorusuyla ilgilidir; bu tartışmaların ana eksenlerini KVKK ve Yapay Zeka yazısında ele alıyorum. Verinin kurum sınırında kalması, bu tartışmaların bir kısmını baştan çözer; ama unutmamak gerekir ki on-premise, veri ikametgahını çözerken erişim kontrolü, denetim kaydı ve güvenlik yükümlülüklerini ortadan kaldırmaz — onları kuruma taşır.

Saha gözlemim, on-premise kararının gerçekten veri ikametgahı gerekçesiyle verildiği projelerin, kurulum zorluklarına daha sabırlı ve hazırlıklı yaklaştığıdır; çünkü neden orada olduklarını bilirler. Buna karşılık, on-premise'i yalnızca "daha güvenli hissettiriyor" diye seçen projeler, ilk donanım tedariki veya güncelleme yükü sürprizinde bulut alternatifini yeniden sorgular. Bu yüzden kararın gerekçesini netleştirmek, kurulumdan önceki en önemli adımlardan biridir: veri ikametgahı gerçek bir kısıt mı, yoksa bir tercih mi? Cevap, tüm projenin tonunu belirler.

Şimdi tüm bu gözlemleri tek bir tabloda toplayayım. Aşağıdaki tablo, on-premise kurulum deneyimi boyunca en sık karşılaştığım engelleri, sahada nasıl belirti verdiklerini ve her birini kurulumdan önce nasıl önleyebileceğinizi özetliyor. Bu tablo, bu yazının en alıntılanabilir çıktısıdır; bir on-premise projesine başlarken kontrol listesi gibi okuyabilirsiniz.

On-premise engelleri: belirti ve önleyici hazırlık (saha gözlemi)

Engel	Sahadaki belirti	Önleyici hazırlık
Donanım tedariki gecikmesi	Proje donanım beklerken durur	GPU siparişini en erken ver; teslim süresini takvimin başına koy
Kapasite yetersizliği (VRAM)	Eşzamanlı kullanımda yanıt yavaşlar, kuyruk oluşur	Tepe eşzamanlı kullanıcıya göre planla; yük testi yap
Güç ve soğutma limiti	Sunucu takılamıyor veya ısınıyor	Tesis güç/soğutma bütçesini önden doğrula
Ağ kısıtları / air-gap	Bağımlılık ve model indirilemiyor	İç ayna kayıt ve onaylı aktarım sürecini kur
Güvenlik politikası çatışması	İmaj tarama, port, erişim adımları durduruyor	Güvenlik ekibini ilk toplantıda ortak yap
Güncelleme ve yama yükü	Sürücü/CUDA uyumsuzluğu üretimi durduruyor	Güncelleme sahibini ve bakım penceresini baştan ata
İç yetkinlik eksiği	Olay anında müdahale eden yok	İşletme ekibini ve nöbet planını kurulumdan önce belirle
Veri ikametgahı belirsizliği	Karar ortasında bulut sorgulanıyor	On-premise gerekçesini yazılı netleştir

Bu tablonun altını çizen bir gerçek var: engellerin neredeyse hiçbiri modelle ilgili değil. Hepsi tedarik, tesis, ağ, güvenlik ve işletme başlıklarında. On-premise kurulum deneyimi tam da bunu söylüyor — bir on-premise projesini yönetmek, bir yapay zeka projesini yönetmekten çok, bir altyapı ve koordinasyon projesini yönetmeye benzer.

Bu saha notunun en pratik çıktısı, kurulumdan önce doldurulması gereken bir hazırlık listesidir. Aşağıdaki adımlar, yukarıdaki engellerin her birini takvimin başına çeker; sırayla yanıtladığınızda, kurulum günü geldiğinde sürprizlerin büyük kısmı çoktan çözülmüş olur.

Nasıl Yapılır

On-premise kurulum hazırlık listesi

Bir on-premise yapay zeka kurulumunu sürprizsiz yürütmek için kurulumdan önce netleştirilmesi gereken adımlar.

1. 1

   Gerekçeyi ve veri ikametgahını yaz

   On-premise neden seçiliyor: veri ikametgahı gerçek bir kısıt mı, tercih mi? Bunu yazılı netleştir; tüm kararların çıpası budur.

2. 2

   Kapasiteyi eşzamanlı yüke göre planla

   Tepe eşzamanlı kullanıcı sayısı, tipik ve en uzun istek boyu ve kabul edilebilir yanıt süresini belirle; gereken GPU ve VRAM'i bu üç sayıdan çıkar.

3. 3

   Donanım tedarikini en erken başlat

   GPU siparişini, teslim süresini ve satın alma onayını projenin ilk gününde başlat; donanımı beklerken diğer katmanları paralel yürüt.

4. 4

   Tesis güç ve soğutmayı doğrula

   Kabin yeri, güç hattı ve soğutma kapasitesinin yeni yoğun sunucuyu kaldırdığını tesis ekibiyle önden teyit et.

5. 5

   Ağ ve aktarım yöntemini kur

   Kapalı ağa paket, imaj ve model ağırlığı taşımak için iç ayna kayıt ve onaylı aktarım sürecini kurulumdan önce hazırla.

6. 6

   Güvenlik ekibini ortak yap

   Mimari, veri akışı, port ve erişim matrisini güvenlik ekibiyle birlikte belgele ve onaylat; imaj tarama ve gizli bilgi yönetimini baştan planla.

7. 7

   İşletme sahipliğini ve izlemeyi ata

   Güncelleme yükünün sahibini, bakım penceresini, izleme panosunu ve olay müdahale planını kurulumdan önce belirle.

8. 8

   Pilotu gerçek yük altında test et

   Küçük ama temsili bir kapsamla başla; beklenen eşzamanlı yükün bir bölümüyle test edip VRAM ve kuyruk süresini ölç, sonra ölçeklendir.

Bu listeyi bir pilotta uygulamak, koca bir dönüşüm vaadinden çok daha değerlidir; çünkü küçük ama ölçülmüş bir başarı, büyük ama belirsiz bir plandan her zaman daha ikna edicidir. On-premise kurulum deneyimi boyunca gördüğüm en sağlıklı projeler, bu listeyi bir kontrol noktası olarak kullanıp kararları kurulumdan önce yazılı hale getirenlerdi.

Bir on-premise projesine başlarken en sık yapılan hata, kapsamı en baştan geniş tutmaktır: "tüm kurumun kullanacağı bir sistem kuralım." Bu, riski en yüksek yoldur çünkü her engel — donanım tedariki, ağ kısıtları, güvenlik, güncelleme yükü — en büyük ölçekte aynı anda üstünüze gelir. Saha gözlemim, dar bir pilotla başlayan projelerin hem daha hızlı öğrendiğini hem de daha az yara aldığını gösteriyor.

İyi bir pilotun üç özelliği vardır. Birincisi darlıktır: tek bir ekip, tek bir kullanım senaryosu, sınırlı bir kullanıcı grubu. İkincisi ölçülebilirliktir: başarının bir sayıyla tanımlanabilmesi — kaç kullanıcı, hangi yanıt süresi, hangi kullanım oranı. Üçüncüsü gerçek bir değerdir: pilot başarılı olursa somut bir sıkıntıyı çözmesi. Bu üç özelliğe sahip bir pilot, on-premise'in tüm zorluklarını küçük ölçekte, telafi edilebilir biçimde yaşamanızı sağlar.

Pilotun bir başka değeri, kapasite ve işletme varsayımlarını gerçek veriyle sınamaktır. Pilotta gördüğünüz eşzamanlı yük, VRAM doluluğu ve güncelleme ritmi, üretim ölçeğini planlamak için gerçek girdiler verir. Tek kullanıcı testinin yanıltıcılığını daha önce vurgulamıştım; pilot, o yanılgıyı düzelten en ucuz araçtır. Dar başla, ölç, iyileştir, sonra ölçeklendir — bu sıra, kağıt üzerinde iyi görünüp üretimde çöken projelerle sahada ayakta kalan projeleri birbirinden ayırır.

On-premise kararı sık sık bir maliyet karşılaştırmasına indirgenir: "bulut abonelik ister, on-premise bir kere donanım alıp biter." Bu karşılaştırma yanıltıcıdır çünkü on-premise'in maliyeti kurulumla bitmez. Doğru bir maliyet resmi, iki ayrı kalemi ayırır: bir kerelik kurulum maliyeti ve sistemin ömrü boyunca süren işletme maliyeti.

Bir kerelik kalemler görünürdür: donanım tedariki, kurulum emeği, ağ ve tesis hazırlığı. Ama asıl belirleyici, sürekli kalemlerdir: işletme ekibinin zamanı, güncelleme ve yama yükü, izleme altyapısı, elektrik ve soğutma, ve donanımın zamanla yenilenmesi. Bu sürekli kalemleri hesaba katmayan bir karşılaştırma, on-premise'i olduğundan ucuz gösterir. Saha gözlemim, on-premise projelerinde en sık yanılan hesabın, işletme maliyetini "sıfır" varsaymak olduğudur; oysa iç yetkinlik gerçeği tam da burada bir maliyet olarak karşımıza çıkar.

Bu, on-premise'in yanlış olduğu anlamına gelmez. Yüksek ve öngörülebilir bir kullanım hacminde, güçlü bir veri ikametgahı gerekçesiyle, on-premise toplam maliyet açısından bulutu geçebilir. Ama bu kararı dürüstçe vermek için işletme maliyetini baştan masaya koymak gerekir. Model seçimi, nicemleme ve çıkarım optimizasyonuyla gereken donanımı — dolayısıyla hem kurulum hem işletme maliyetini — düşürmenin yollarını LLM Maliyet Optimizasyonu yazısında ele alıyorum; on-premise'de bu optimizasyonlar doğrudan bütçeye yansır.

On-premise kurulum deneyimi biriktikçe, başarısız veya sancılı projelerin benzer hatalarla takıldığını görüyorum. Bunları bir arada listelemek, kendi projenizde erken uyarı işareti olarak işe yarar:

• Takvimi kuruluma göre yapmak: Zamanın çoğunu kuruluma ayırıp donanım tedariki, ağ ve onay katmanlarını hafife almak. Oysa kurulum en kısa adımdır; gecikme hazırlıktadır.
• Kapasiteyi tek kullanıcıya göre planlamak: Modeli tek başına deneyip "hızlı" demek. Eşzamanlı yük hesaba katılmazsa üretimde VRAM dolar ve yanıt yavaşlar.
• Ağ kısıtlarını sona bırakmak: Kapalı ağa paket ve model taşıma sürecini kurulum günü keşfetmek. Bu süreç önden kurulmazsa kurulum durur.
• Güvenliği sonradan eklemek: Güvenlik ekibini kurulumun ortağı değil, sonradan gelen denetçisi yapmak. Her adım onaya takılır ve proje geriye döner.
• Güncelleme yükünü yok saymak: On-premise'i kurulunca biten bir proje sanmak. Güncelleme yükü ve bakım, kurulumdan sonra süreklidir ve bir sahibi olmalıdır.
• İç yetkinliği fazla varsaymak: Kurulumu yapan kişinin işletmeyi de yürüteceğini varsaymak. Kurulum becerisi ile işletme becerisi farklıdır.
• Kapsamı geniş başlatmak: Tüm kurumu tek seferde dönüştürmeye çalışmak. Dar bir pilotla başlamak riski düşürür ve öğrenmeyi hızlandırır.
• Gerekçeyi netleştirmemek: On-premise'i bilinçli bir veri ikametgahı gerekçesi olmadan seçmek. İlk sürprizde bulut alternatifi yeniden sorgulanır ve proje sarsılır.

Tüm bu saha gözlemlerini tek bir derse indirgeyeyim: on-premise, bir yapay zeka projesi kadar bir altyapı ve koordinasyon projesidir. Modeli kurmak, tüm işin en küçük ve en kolay parçasıdır; asıl iş, donanım tedariki, ağ kısıtları, güvenlik politikaları, güncelleme yükü ve iç yetkinlik gibi kurumsal katmanları önceden hizalamaktır. On-premise kurulum deneyimi boyunca bu ders her projede tekrarlandı ve hiç değişmedi.

İkinci ders, hazırlığın gücüdür. Sahada gördüğüm sürprizlerin neredeyse tamamı, kurulumdan önce verilebilecek bir kararın verilmemesinden doğuyordu. Bu yüzden bu yazının en değerli çıktısı, tek tek gözlemler değil, onları önleyen hazırlık listesidir. Kararları kurulumdan önce yazılı hale getiren ekipler, kurulum gününe sürprizsiz gelir; getirmeyenler ise aynı sürprizleri üretimde, en pahalı anda yaşar.

Üçüncü ders, on-premise'in bir tercih değil, gerekçeli bir karar olması gerektiğidir. Güçlü bir veri ikametgahı gerekçesi, yüksek ve öngörülebilir bir kullanım hacmi ve işletmeyi üstlenecek bir iç yetkinlik varsa, on-premise doğru ve güçlü bir seçimdir. Bu üçü yoksa, kararı yeniden düşünmek gerekir. On-premise kurulum deneyimi bana, doğru gerekçeyle girilen projelerin tüm zorluklara değdiğini; yanlış gerekçeyle girilenlerin ise ilk sürprizde sarsıldığını defalarca gösterdi.

Dördüncü ve belki en pratik ders şudur: on-premise'de sürpriz, bilgi eksikliğinden doğar. Sahada yaşadığım her gecikmenin arkasında, kurulumdan önce sorulmayan bir soru vardı — donanım tedariki ne kadar sürer, kapasite eşzamanlı yükte yeter mi, ağ kısıtları bağımlılıkları nasıl etkiler, güvenlik ekibi hangi belgeyi ister, güncelleme yükünün sahibi kim? Bu soruları erken sormak, sürprizleri karara dönüştürür; sormamak, onları üretimin en pahalı anına erteler. On-premise kurulum deneyimi boyunca bu desen hiç değişmedi: iyi sorular soran ekipler sakin ilerledi, sormayanlar sürekli yangın söndürdü.

Eğer kurumunuz on-premise bir yapay zeka altyapısı kurmayı değerlendiriyorsa, en değerli adım, bu kararı ve hazırlığı bir uzmanla birlikte gözden geçirmektir. Kurulumdan önce gerekçeyi, kapasiteyi, ağ ve güvenlik gereksinimlerini ve işletme sahipliğini netleştiren bir danışmanlık görüşmesi, sahada haftalarca sürecek sürprizlerin çoğunu takvimin başına çeker. Ekiplerinizin bu sistemi ayakta tutacak yetkinliği kazanması için kurumsal eğitim seçeneklerini, konunun teknik temellerini derinleştirmek için ise On-Premise ve Egemen AI Altyapısı yazısını ve öğrenme merkezini inceleyebilirsiniz. Sorularınız için iletişim sayfasından bana ulaşabilirsiniz.

Sahada erken verilmesi gereken ama sık ertelenen bir karar, kurulum topolojisidir: sistem tek bir sunucuda mı, yoksa birden çok sunucuya yayılmış bir kümede mi çalışacak? Bu karar kulağa teknik gelir ama aslında kapasite, bütçe, işletme yükü ve dayanıklılık arasındaki bir dengedir ve donanım tedariki daha başlamadan netleşmelidir. Yanlış topoloji, ya gereğinden fazla donanım almanıza ya da üretimde tek bir sunucunun çökmesiyle tüm sistemin durmasına yol açar.

Tek sunucu, en basit ve en ucuz başlangıçtır: tüm bileşenler — model servisi, vektör veritabanı, arayüz — aynı makinede çalışır. Pilot ve düşük eşzamanlı yük için genellikle yeterlidir. Ama tek bir kırılma noktası (single point of failure) taşır: o sunucu bakım için kapandığında veya arızalandığında sistem tamamen durur. Saha gözlemim, tek sunucuyla başlayıp veri ikametgahı gerekçesiyle kurulan çoğu pilotun, üretime geçerken en az yedeklilik gerektiren bir yapıya evrildiğidir.

Küme (cluster) topolojisi ise yükü ve riski dağıtır: birden çok GPU sunucusu isteği paylaşır, biri arızalandığında diğerleri devam eder. Ama bedeli vardır: yük dengeleme, servis keşfi, ağ karmaşıklığı ve daha fazla donanım tedariki. Doğru karar, tek doğru cevap değildir; eşzamanlı yük, kabul edilebilir kesinti süresi ve bütçe üçlüsünden çıkar. Pratik yaklaşımım, pilotu tek sunucuda kurup ölçmek, sonra üretim için gereken yedekliliği gerçek yük verisiyle planlamaktır. Bu kararın bulut ile karşılaştırmalı çerçevesini On-Premise ve Egemen AI Altyapısı yazısında ele alıyorum.

Donanım tedariki denince akla önce GPU gelir; ama sahada sık atlanan bir kalem depolamadır. Model ağırlıkları, vektör veritabanı, belge deposu ve loglar ciddi bir disk alanı ister ve bu alan yalnızca kapasite değil, hız ve dayanıklılık meselesidir. Yavaş bir disk, model yükleme sürelerini uzatır; dayanıksız bir depolama, tek bir donanım arızasında veri kaybı riski taşır. Depolama planı, kapasite planlamasının çoğu zaman unutulan yarısıdır.

Yedekleme ise on-premise'de tamamen sizin sorumluluğunuzdadır. Bulutta çoğu zaman otomatik olan yedekleme, kapalı bir ortamda kurulması ve düzenli test edilmesi gereken bir süreçtir. Saha gözlemim şu: yedek almak kolay, yedeği geri yüklemek zordur; ve çoğu ekip geri yükleme senaryosunu hiç denemez. Bir felaket anında, hiç test edilmemiş bir yedeğin işe yaramadığını keşfetmek, olabilecek en pahalı derstir. Bu yüzden yedekleme kadar, düzenli geri yükleme tatbikatı da hazırlık listesinin parçası olmalıdır.

Felaket kurtarma (disaster recovery) bir adım ötesidir: sunucu tamamen kaybedilirse, sistem ne kadar sürede yeniden ayağa kalkar? Bu sorunun cevabı, işin kritikliğine bağlıdır ve kurulumdan önce netleşmelidir. Kritik bir kurumsal asistan için saatlerce kesinti kabul edilemezken, iç bir deneme aracı için bir gün tolere edilebilir. Bu tolerans, hem yedekleme sıklığını hem de gereken yedek donanımı belirler. On-premise kurulum deneyimi bana, depolama ve kurtarmayı sonraya bırakan ekiplerin, ilk ciddi arızada en çok pişman olan ekipler olduğunu öğretti.

On-premise bir yapay zeka sistemi, kurumun mevcut kimlik altyapısına bağlanmadan gerçek anlamda üretime giremez. Kullanıcıların ayrı bir parola ile giriş yaptığı, erişimin elle yönetildiği bir sistem, hem güvenlik hem de kullanılabilirlik açısından kısa ömürlüdür. Sahada gördüğüm en sağlıklı kurulumlar, ilk günden kurumsal kimlik sağlayıcısına (SSO, dizin servisi) entegre olanlardır; ama bu entegrasyon, çoğu ekibin kurulum telaşında hafife aldığı bir iştir.

Kimlik entegrasyonunun asıl değeri, erişim kontrolünü sistemin kalbine yerleştirmesidir. Kim hangi belgeye, hangi modele, hangi işleve erişebilir sorusunun cevabı, kurumun mevcut rol ve grup yapısından gelmelidir; her sistemin kendi ayrı yetki listesini tutması, hem hataya hem de güvenlik açığına davetiyedir. Bir kullanıcı işten ayrıldığında erişiminin merkezi olarak kesilmesi, ancak bu entegrasyonla mümkün olur. Erişim kontrolünün neden getirme katmanında yapılması gerektiğini ve KVKK ile ilişkisini KVKK ve Yapay Zeka yazısında ele alıyorum.

Saha gözlemim, kimlik ve erişim entegrasyonunun güvenlik politikası çatışmalarının da bir parçası olduğudur: güvenlik ekibi, sistemin kendi ayrı kullanıcı deposunu tutmasına genellikle izin vermez ve kurumsal kimlik altyapısına bağlanmayı şart koşar. Bu şartı bir kısıt değil, doğru tasarım girdisi olarak almak gerekir. Bu entegrasyonu kurulumdan önce planlamak, sonradan yaşanan "kullanıcılar giremiyor" ve "yetkiler karışık" sorunlarının büyük kısmını önler.

Modeli çalıştırmak ile modeli servis etmek farklı şeylerdir. Bir modeli bir kez çalıştırıp yanıt almak kolaydır; onu çok sayıda eşzamanlı kullanıcıya, kararlı gecikme ve yüksek verimle sunmak ise ayrı bir katman ister: çıkarım sunucusu (inference server). Bu katman, istekleri kuyruğa alır, toplu işler (batching), GPU belleğini yönetir ve modeli verimli biçimde besler. Sahada, doğru çıkarım sunucusunu seçmenin gereken donanımı belirgin biçimde azalttığını defalarca gördüm.

Çıkarım sunucusu seçiminde birkaç kriter öne çıkar: eşzamanlı istekleri ne kadar verimli toplu işleyebiliyor, uzun bağlamları nasıl yönetiyor, hangi model formatlarını ve nicemleme düzeylerini destekliyor, ve izleme ile ölçeklenmeye ne kadar uygun. Bu kararlar doğrudan kapasite planlamasını etkiler; aynı donanım, iyi seçilmiş bir çıkarım katmanıyla çok daha fazla eşzamanlı kullanıcıya hizmet eder. Model seçimi ve nicemlemenin çıkarım verimine etkisini LLM Maliyet Optimizasyonu yazısında ayrıntılandırıyorum.

Bu katmanın bir başka gerçeği, güncelleme yüküne katkısıdır: çıkarım sunucusu da bir yazılımdır ve sürümlenir, yamalanır, model formatı değiştiğinde uyum ister. Yani model, sürücü ve çıkarım sunucusu üçlüsü arasındaki uyumu korumak, on-premise bakımının sürekli bir parçasıdır. Sahada bu üçlünün uyumunu belgeleyip izlemeyen ekipler, bir güncelleme sonrası "dün çalışan bugün çalışmıyor" durumuyla en çok karşılaşan ekiplerdir.

Bir on-premise sistemi pilotta çalıştırmak ile üretime almak arasında net bir eşik vardır ve bu eşiği belirsiz bırakmak, sahada en çok sancı yaratan durumlardan biridir. "Pilot iyi gitti, açalım" demek, çoğu zaman erken bir karardır; çünkü pilotta tolere edilen birçok eksik — yedekleme, izleme, erişim kontrolü, kapasite — üretimde kritik hale gelir. Bu yüzden pilottan üretime geçişi bir karar değil, bir kontrol listesi olarak ele almak gerekir.

Geçiş kontrol noktalarım şunlardır: kapasite gerçek eşzamanlı yük altında test edildi mi, erişim kontrolü kurumsal kimlikle entegre mi, yedekleme kuruldu ve geri yükleme denendi mi, izleme panosu ve olay müdahale planı hazır mı, güvenlik onayı tamamlandı mı, ve güncelleme yükünün bir sahibi atandı mı? Bu soruların hepsine "evet" denemeden üretime geçmek, sistemi ilk ciddi olayda kırılgan bırakır. Saha gözlemim, bu kontrol noktalarını atlayan ekiplerin, üretimin ilk haftasında pilotta hiç yaşamadıkları sorunlarla boğuştuğudur.

Bu eşiği net tutmanın bir faydası da beklenti yönetimidir. İş birimi, pilotun başarısını görüp "hemen herkese açalım" baskısı yapabilir; kontrol noktaları, bu baskıya karşı somut ve savunulabilir bir gerekçe sunar. "Şu üç madde tamamlanmadan üretime almak riskli" demek, teknik bir bahane değil, sorumlu bir işletme kararıdır. Pilotun dar ve ölçülebilir olmasının değerini daha önce vurgulamıştım; bu kontrol noktaları, o dar pilotu güvenli bir üretime bağlayan köprüdür.

On-premise kurulumların sessiz ama ciddi bir riski, tüm bilginin tek bir kişinin kafasında birikmesidir. Kurulumu yapan mühendis, sistemin nasıl kurulduğunu, hangi kararların neden verildiğini ve bir sorun çıktığında nereye bakılacağını bilir; ama bu bilgi yazılı değilse, o kişi izne çıktığında veya işten ayrıldığında sistem bir anda sahipsiz kalır. Saha gözlemim, belgeleme eksikliğinin on-premise projelerinde en geç fark edilen ama en pahalı risklerden biri olduğudur.

İyi bir belgeleme, en az şunları içermeli: mimari ve veri akışı, donanım envanteri ve kapasite varsayımları, ağ ve port haritası, güvenlik kararları ve istisnalar, kurulum adımları, güncelleme prosedürü ve olay müdahale rehberi. Bu belge süslü olmak zorunda değil; bir sonraki kişinin sistemi anlayıp sürdürebilmesine yetecek kadar net olması yeterli. Belgeyi kurulum sırasında yazmak, sonradan hatırlayarak yazmaktan hem daha kolay hem daha doğrudur.

Devir (handover), belgelemenin pratik sınavıdır. Sistemi kuran kişi ile onu işletecek kişi çoğu zaman farklıdır; iç yetkinlik gerçeği başlığında değindiğim gibi, kurulum becerisi ile işletme becerisi ayrıdır. Bu devrin sağlıklı olması, yazılı belgeye ve bilinçli bir bilgi aktarımına bağlıdır. On-premise kurulum deneyimi bana, belgelemeye ve devre yatırım yapan ekiplerin, bir kişinin ayrılmasıyla sarsılmayan; yapmayanların ise tek bir istifayla kriz yaşayan ekipler olduğunu gösterdi. Ekiplerin bu sürekliliği kazanması için gereken yapıyı kurumsal eğitim tarafında da ele alıyorum.

On-premise kurulumların çoğu, tamamen kurum içi kaynaklarla değil, donanım, yazılım ve entegrasyon için dış tedarikçilerle birlikte yürür. Bu ilişki, kurulum başarısı kadar üretim sürekliliği için de kritiktir; çünkü bir şey bozulduğunda "kimi arayacağız" sorusunun net bir cevabı olmalıdır. Saha gözlemim, tedarikçi ve destek ilişkisini kurulum öncesinde netleştirmeyen ekiplerin, ilk ciddi arızada değerli saatleri "bu kimin sorumluluğunda" tartışmasıyla kaybettiğidir.

Netleşmesi gereken sorular şunlar: donanım arızasında garanti ve yerinde servis süresi ne, yazılım desteği hangi kapsamda ve hangi yanıt süresiyle, model veya çıkarım katmanı için kime danışılacak, ve bir sorun birden çok tedarikçiyi ilgilendiriyorsa koordinasyonu kim yapacak? Bu soruların cevabı, sözleşme aşamasında konuşulmazsa, kriz anında konuşulmaya çalışılır ki bu en kötü zamandır. Destek kapsamı, on-premise toplam maliyetinin de bir parçasıdır ve maliyet gerçeği başlığında değindiğim sürekli kalemlere dahildir.

Bu ilişkinin bir başka boyutu, bağımlılık dengesidir. Tek bir tedarikçiye tam bağımlı olmak, esnekliği azaltır ve pazarlık gücünü zayıflatır; ama her katmanı ayrı tedarikçiden almak da koordinasyon yükü yaratır. Doğru denge, kritik katmanlarda içeride yeterli yetkinlik tutup, uzmanlık gerektiren noktalarda güvenilir destek almaktır. On-premise'i bir işletme taahhüdü olarak görmek, bu destek ağını da baştan kurmayı içerir; çünkü sistem sizin sınırlarınızda çalışıyor olsa da, onu ayakta tutmak çoğu zaman bir ekosistem işidir.

Sahada en pahalı hatalardan biri, üretim sistemine doğrudan dokunmaktır: bir güncellemeyi, bir ayar değişikliğini veya yeni bir model sürümünü önce test etmeden canlıya uygulamak. Bulutta bu ayrım çoğu zaman hazır gelir; on-premise'de test (staging) ortamını da siz kurarsınız ve bu ortam, sınırlı donanım yüzünden en sık feda edilen kalemdir. Oysa test ortamı olmadan yapılan her güncelleme, kullanıcıların önünde denenen bir kumardır.

Test ortamının üretimin birebir kopyası olması gerekmez; ama kritik uyumları — model, sürücü, çıkarım sunucusu ve bağımlılık sürümleri — yansıtacak kadar temsili olmalıdır. Bir güncelleme yükü geldiğinde, onu önce test ortamında denemek, güncelleme ve yama yükünün yarattığı riski büyük ölçüde düşürür. Saha gözlemim, test ortamı olmayan ekiplerin, ilk ciddi güncellemede üretimi bozup saatlerce geri dönmeye çalıştığıdır; test ortamı olanlar ise aynı sorunu kullanıcıya hiç yansıtmadan yakalar.

Bu ayrım, sınırlı donanımda bile küçük ölçekli bir test ortamıyla sağlanabilir; amaç kapasiteyi değil, uyumu doğrulamaktır. On-premise kurulum deneyimi bana, test-üretim ayrımını baştan kuran ekiplerin güncellemeleri güvenle yaptığını; kurmayanların ise her güncellemede nefeslerini tuttuğunu öğretti. Doğrudan canlıya dokunmamak, on-premise işletmesinin en ucuz ve en değerli disiplinlerinden biridir.

Donanım tedariki ve kapasite planlaması konuşulurken en az akla gelen ama sahada en somut sınırlardan biri fiziksel ortamdır: elektrik, kesintisiz güç ve soğutma. GPU sunucuları yüksek güç çeker; bu, yalnızca bir prizin yetip yetmemesi değil, veri merkezinin toplam güç bütçesinin bu ek yükü kaldırıp kaldıramaması meselesidir. Sahada, kapasite planını donanım üzerinden yapıp elektrik altyapısını unutan ekiplerin, sunucu geldikten sonra "takacak yer yok" gerçeğiyle karşılaştığını gördüm.

Kesintisiz güç kaynağı (UPS) ve jeneratör, kritik bir sistem için lüks değil, zorunluluktur. Bir elektrik kesintisinin sistemi aniden durdurması, hem hizmeti keser hem de veri bütünlüğü riski yaratır; yarım kalan bir yazma işlemi, vektör veritabanını veya depolamayı bozabilir. Bu yüzden kritik bir on-premise kurulumda, güç sürekliliği planı kurulumdan önce netleşmeli ve gereken UPS kapasitesi donanımın güç ihtiyacına göre boyutlandırılmalıdır. Bu, tesis ekibiyle birlikte verilecek bir karardır ve donanım tedariki takvimiyle paralel yürümelidir.

Fiziksel ortamın bir de erişim ve güvenlik boyutu vardır: sunucular nerede duruyor, kimlerin fiziksel erişimi var, ortam sıcaklığı ve nem izleniyor mu? Bunlar, siber güvenlik kadar konuşulmasa da kurumsal bir veri merkezinin standart gereksinimleridir ve güvenlik ekibinin denetim kapsamına girer. On-premise kurulum deneyimi bana, fiziksel ortamı "nasılsa var" diye geçen ekiplerin, ilk yaz sıcağında soğutma yetmediğinde veya bir güç dalgalanmasında en pahalı dersi aldığını öğretti. Fiziksel altyapı, yazılımın altındaki sessiz zemindir; sağlam değilse üstüne kurulan her şey kırılgandır.

Büyük başlıkların yanında, on-premise kurulum deneyimi boyunca biriken ve tek başına küçük görünen ama toplamda çok zaman kazandıran birkaç saha dersi var. Bunları bir arada paylaşmak, kendi projenizde erken hatırlatıcı olarak işe yarayabilir:

• Her şeyi bir kez daha, temiz bir ortamda kur. Kurulumu yalnızca kendi makinenizde denemek yanıltıcıdır; temiz bir ortamda tekrarlanabilir bir kurulum, gerçek bağımlılık ve ağ kısıtlarını ortaya çıkarır.
• Zaman ve saat dilimini baştan sabitle. Kapalı ortamlarda sunucu saatinin kayması, sertifika ve log sorunlarına yol açar; küçük görünür, büyük baş ağrıtır.
• İlk günden log topla. Bir sorun çıktığında geriye dönük log olmadan teşhis çok zordur; loglamayı kurulumun parçası yapın, sonraya bırakmayın.
• Bir geri dönüş planı hazır tut. Bir güncelleme sistemi bozarsa, hızlıca eski sürüme dönebilmek, saatlerce süren bir krizi dakikalara indirir.
• Kapasiteyi gerçek belgelerle test et. Kısa örnek metinlerle yapılan test, uzun kurumsal belgelerin yarattığı gerçek yükü göstermez; testte gerçek uzunlukta veri kullanın.
• Güvenlik ekibinin dilini öğren. Onların istediği belgeleri onların beklediği biçimde sunmak, ağ kısıtları ve onay katmanlarında haftalar kazandırır.

Bu küçük derslerin ortak noktası, hepsinin ucuz bir hazırlıkla pahalı bir sürprizi önlemesidir. Saha gözlemim şu: on-premise'de zaman kazandıran şey, tek bir büyük doğru karar değil, bu küçük disiplinlerin toplamıdır. Bir on-premise projesini sürprizsiz yürütmek isteyen ekipler için bu notlar, hazırlık listesinin gayrı resmî ama değerli bir uzantısıdır.

On-premise'de donanım sınırlı olduğu için, bulutta çoğu zaman düşünülmeyen bir karar öne çıkar: nicemleme (quantization). Nicemleme, modelin ağırlıklarını daha az bit ile temsil ederek bellek ihtiyacını ve çıkarım maliyetini düşüren bir tekniktir; sahada, aynı GPU üzerinde daha büyük bir modeli çalıştırmanın veya daha fazla eşzamanlı kullanıcıya hizmet etmenin en pratik yoludur. Ama bedelsiz değildir: agresif nicemleme, modelin doğruluğunda küçük ama bazen belirleyici bir düşüşe yol açabilir.

Sahada gördüğüm doğru yaklaşım, nicemleme düzeyini bir varsayım değil, ölçülen bir karar haline getirmektir. Kurumun kendi test kümesiyle, farklı nicemleme düzeylerinin hem yanıt kalitesini hem de VRAM tüketimini karşılaştırmak, "ne kadar sıkıştırma kabul edilebilir" sorusunu kanıta dayandırır. Bir görevde fark edilmeyen kalite kaybı, başka bir görevde kritik olabilir; bu yüzden karar, kullanım senaryosuna göre verilir. Nicemlemenin çıkarım verimine ve gereken donanıma etkisini LLM Maliyet Optimizasyonu yazısında ele alıyorum.

Bu kararın donanım tedariki ile doğrudan bir bağı vardır: doğru nicemleme, daha az veya daha ucuz GPU ile aynı işi görmenizi sağlayabilir ve böylece hem kurulum hem işletme maliyetini düşürür. On-premise kurulum deneyimi bana, nicemlemeyi kapasite planlamasının bir parçası olarak ele alan ekiplerin, donanımı çok daha verimli kullandığını öğretti. Nicemlemeyi hiç düşünmeyen ekipler ise çoğu zaman gereğinden fazla donanım tedarik eder ya da kapasiteye takılır.

Güvenlik politikası çatışmalarının somut bir alt başlığı, gizli bilgi (secret) yönetimidir. Bir on-premise sistem; veritabanı parolaları, API anahtarları, sertifikalar ve model erişim bilgileri gibi çok sayıda gizli veriyi kullanır. Bu bilgilerin nerede ve nasıl saklandığı, kurumsal güvenlik ekibinin en hassas olduğu konulardandır. Sahada en sık gördüğüm hata, bu gizli bilgileri yapılandırma dosyalarına düz metin olarak yazmaktır; bu, hemen her güvenlik denetiminde takılan bir uygulamadır.

Doğru yaklaşım, gizli bilgileri kurumsal bir kasada (secret manager) tutmak ve uygulamaya yalnızca çalışma anında, kontrollü biçimde vermektir. Bu, kurulumu bir adım karmaşıklaştırır ama güvenlik onayını da kolaylaştırır; çünkü güvenlik ekibinin tam olarak beklediği uygulamadır. Gizli bilgi yönetimini kurulumdan önce planlamak, sonradan "bu parolalar neden dosyada" tartışmasıyla projeyi geri döndürmekten çok daha ucuzdur.

Anahtar yönetiminin bir de yaşam döngüsü boyutu vardır: sertifikalar ve anahtarlar süreli olabilir ve yenilenmeleri gerekir. Güncelleme yükü başlığında değindiğim sertifika yenileme, tam da buraya bağlanır; bir sertifika sessizce süresi dolduğunda sistem beklenmedik biçimde durabilir. Bu yüzden gizli bilgilerin ne zaman yenileneceğini izlemek, işletme rutininin bir parçası olmalıdır. Saha gözlemim, gizli bilgi ve anahtar yönetimini baştan kuran ekiplerin hem güvenlik onayını daha hızlı geçtiğini hem de üretimde daha az sürprizle karşılaştığını gösteriyor.

On-premise'in bulutla en keskin ayrıştığı noktalardan biri, kapasite büyütmedir. Bulutta talep arttığında birkaç tıklamayla daha fazla kaynak eklersiniz; on-premise'de aynı ihtiyaç, yeni bir donanım tedariki döngüsü anlamına gelir — yani yine sipariş, teslim, onay ve kurulum. Bu fark, on-premise kapasite planlamasını neden bu kadar önemli kıldığını açıklar: yanlış planlarsanız, düzeltmesi bir tık değil, haftalar sürer.

Bu gerçek, kapasiteyi baştan biraz esneklik payıyla planlamayı gerektirir. Tam sınırda bir donanımla başlamak, talep beklenenden hızlı artarsa sizi hazırlıksız yakalar. Ama aşırı büyük bir donanımla başlamak da atıl kapasite ve gereksiz maliyet demektir. Doğru denge, gerçekçi bir büyüme tahmini ve makul bir esneklik payıdır; ve bu tahmin, pilottan ve ilk 90 günden gelen gerçek kullanım verisiyle sürekli güncellenmelidir.

Büyütme kararının bir de topoloji boyutu vardır: kapasiteyi tek bir sunucuyu büyüterek mi (dikey), yoksa yeni sunucular ekleyerek mi (yatay) artıracaksınız? Dikey büyütme basittir ama bir tavana çarpar; yatay büyütme esnektir ama yük dengeleme ve işletme karmaşıklığı ekler. Bu kararı kurulum topolojisi başlığında ele aldığım tercihlerle birlikte düşünmek gerekir. Saha gözlemim, kapasite büyütmeyi kurulumdan önce bir senaryo olarak düşünen ekiplerin, talep patladığında panik yaşamadığıdır; hiç düşünmeyenler ise en kötü anda, sistem zaten zorlanırken donanım tedariki telaşına düşer.

Bu saha notu on-premise gerçeklerine odaklansa da, dürüst bir çerçeve şunu söylemeyi gerektirir: on-premise her zaman doğru cevap değildir ve bazen en iyi karar hibrit bir yapıdır. Bazı kurumlar, hassas verileri on-premise tutarken, hassas olmayan iş yüklerini bulutta çalıştırır; bu, veri ikametgahı gereksinimini karşılarken bulutun esnekliğinden de yararlanmayı sağlar. Kararı "ya hep ya hiç" olarak kurgulamak, çoğu zaman gereksiz bir kısıtlamadır.

Doğru kararı vermek için birkaç soru belirleyicidir: verinin kurum sınırında kalması gerçek bir hukuki/kurumsal zorunluluk mu, yoksa bir tercih mi? Kullanım hacmi yüksek ve öngörülebilir mi, yoksa değişken mi? İşletmeyi üstlenecek iç yetkinlik var mı? Bu soruların cevabı, on-premise, bulut ve hibrit arasındaki dengeyi belirler. Yüksek ve sabit yük, güçlü bir veri ikametgahı gerekçesi ve mevcut iç yetkinlik on-premise'i güçlendirirken; değişken yük ve sınırlı ekip bulutu ya da hibriti öne çıkarır.

Saha gözlemim, en sağlıklı kararların ideolojik değil, gerekçeli olanlar olduğudur. "Bulut her zaman daha iyidir" ya da "on-premise her zaman daha güvenlidir" gibi genellemeler, her iki yönde de hataya yol açar. Doğru soru, "bu iş yükü, bu veri ve bu ekip için hangisi daha uygun" sorusudur ve cevabı iş yüküne göre değişir. Bu kararı kurumunuza özel olarak değerlendirmek için bir danışmanlık görüşmesi, on-premise ile bulut arasındaki dengeyi net bir gerekçeye oturtmanın en hızlı yoludur. Kararın teknik çerçevesini On-Premise ve Egemen AI Altyapısı yazısında derinleştiriyorum.

Bir on-premise sistem üretime alındıktan sonraki ilk üç ay, sistemin gerçek karakterinin ortaya çıktığı dönemdir ve sahada gözlemlediğim bir desen izler. İlk günlerde her şey yenidir ve dikkat yüksektir; ama asıl sınav, ilk heyecan geçtikten sonra sistemin sessizce nasıl davrandığıdır. Bu dönemi bilinçli izlemek, sonraki yılların işletme yükünü büyük ölçüde belirler.

İlk haftalarda tipik olarak kapasite ve kullanım varsayımları test edilir. Gerçek kullanıcılar, pilotta öngörülmeyen biçimlerde sistemi zorlar: beklenmedik uzunlukta belgeler, tahmin edilmeyen eşzamanlılık dalgaları, öngörülmeyen soru tipleri. Bu dönemde izleme panosu paha biçilmezdir; hangi saatlerde yük arttığını, VRAM'in ne zaman dolduğunu ve yanıt sürelerinin nerede bozulduğunu ancak ölçerek görürsünüz. Saha gözlemim, ilk 90 günde en çok öğrenilen şeyin kapasite planının ne kadar doğru olduğu olduğudur.

İkinci ay genellikle ilk güncelleme ve bakım gerçeğini getirir. Bir güvenlik yaması çıkar, bir model sürümü yenilenir veya bir sürücü uyumsuzluğu baş gösterir; işte güncelleme yükünün gerçek ritmi bu dönemde belli olur. Bu ilk bakım döngüsünü sağlıklı geçmek, güncelleme sahibinin ve prosedürünün baştan atanmış olmasına bağlıdır. Üçüncü ay ise benimseme tarafında bir gerçeği ortaya çıkarır: ilk hafta yoğun kullanılan sistem, iş akışına gerçekten oturmadıysa kullanımı düşmeye başlar. Bu düşüşün nedenlerini ve müdahalesini Kullanıcı Benimsemesi saha notunda ele alıyorum. İlk 90 günü bilinçli yöneten ekipler, sistemin hem teknik hem benimseme tarafını sağlam bir zemine oturtur; yönetmeyenler ise aynı sorunları daha büyük ölçekte, daha geç fark eder.

On-premise kurulumda pratikte ne çıkıyor?

Sahada çıkan şeyler neredeyse hiç modelle ilgili olmuyor. En sık karşılaştıklarım: donanım tedariki gecikmesi, veri merkezinin güç ve soğutma sınırları, kapalı ağa bağımlılık ve model indirme sorunu, güvenlik ekibinin imaj tarama ve port politikalarının kurulum adımlarıyla çatışması, ve kurulumdan sonra ortaya çıkan güncelleme yükü. On-premise kurulum deneyimi bana şunu öğretti: teknik adımlar bir günde biter, kurumsal engeller haftalara yayılır.

On-premise kurulum süresi neden beklenenden uzun sürüyor?

Çünkü takvimi uzatan şey kurulumun kendisi değil, ona giden hazırlıktır. Donanım tedariki tek başına haftalar alabilir; sunucu geldikten sonra kabin, güç, soğutma ve ağ hazırlığı ister; kapalı ağ ortamında paket ve model ağırlıklarını içeri taşımak ayrı bir süreçtir; güvenlik onayı ve ağ kısıtları sırayla beklenir. Saha gözlemi net: gecikmenin nedeni neredeyse her zaman eksik hazırlık, teknik zorluk değil.

On-premise kuruluma nasıl hazırlanılır?

En etkili yöntem, kurulumdan önce yazılı bir hazırlık listesi oluşturmaktır: eşzamanlı kullanıcı sayısına göre GPU ve VRAM kapasitesi, donanım tedariki için teslim süresi ve satın alma onayı, veri merkezinin güç ve soğutma bütçesi, kapalı ağa model taşıma yöntemi, güvenlik ekibinin gereksinimleri, veri ikametgahı politikası ve kurulumdan sonraki güncelleme sorumluluğu. Bu kararları önden vermek, sürprizlerin büyük kısmını takvimin başına çeker.

Donanım tedariki neden bu kadar zaman alıyor?

GPU sunucuları hazır rafta bekleyen ürünler değildir; sipariş, teslim ve iç satın alma onayı zinciri haftalara yayılır. Üstelik donanım geldiğinde iş bitmez: kabin yeri, güç hattı, soğutma kapasitesi ve ağ bağlantısı da hazır olmalıdır. Donanım tedariki bu yüzden bir satın alma değil, güç, soğutma ve ağı da içeren bir kapasite planlama işidir.

On-premise ortamda ağ ve güvenlik kısıtları hangi sorunları çıkarıyor?

En belirgin çatışma, kapalı veya air-gap ağlarda internet erişiminin olmamasıdır: bulutta bir dakikada inen bağımlılıklar ve model ağırlıkları, on-premise ortamda kontrollü bir aktarım süreci gerektirir. Buna güvenlik politikaları eklenir: dış registry yasakları, imaj tarama, port kısıtları ve ayrıcalıklı erişim onayları. Ağ kısıtları ve güvenlik politikası çatışmaları, saha gözlemine göre en çok zaman kaybettiren iki başlıktır.

Kurulumdan sonra hangi bakım ve güncelleme yükü geliyor?

On-premise, kurulunca biten bir proje değil, sürekli bir işletme taahhüdüdür. Güncelleme yükü birkaç koldan gelir: model sürümlerinin yenilenmesi, GPU sürücüsü ve CUDA uyumunun korunması, işletim sistemi ve konteyner güvenlik yamaları, sertifika yenileme ve yedeklerin doğrulanması. Bunların her biri, bulutta sağlayıcının üstlendiği, on-premise ortamda ise sizin ekibinize düşen işlerdir.

Kısaca özetlersem: on-premise kurulum deneyimi, zorluğun modelde değil, modelin etrafındaki kurumsal katmanlarda olduğunu gösterir. Kurulum süresi beklenenden uzar çünkü donanım tedariki, ağ kısıtları, güvenlik onayları ve işletme hazırlığı seri değil paralel yürütülmeli ama çoğu zaman öyle yürütülmez. Donanım tedariki en kırılgan halkadır; kapasite eşzamanlı yüke göre planlanmalıdır. Ağ kısıtları ve güvenlik politikası çatışmaları en çok zaman kaybettiren yerdir. Asıl yük olan güncelleme yükü kurulumdan sonra başlar ve bir sahibi olmalıdır. İç yetkinlik gerçeği ise çoğu projede eksik hesaplanır.

En önemli mesaj şu: on-premise, bir kurulum projesi değil, bir işletme taahhüdüdür ve başarısı, saha gözlemiyle oluşturulmuş bir hazırlık listesinden gelir. Kararları kurulumdan önce yazılı hale getiren ekipler sürprizsiz ilerler. Konunun bütününü On-Premise ve Egemen AI Altyapısı yazısında, donanım temelini GPU Nedir? yazısında ele alıyorum; kurumunuza özel bir on-premise hazırlık ve kurulum planı için danışmanlık görüşmesi ile başlayabilir, ekipleriniz için kurumsal eğitim seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.