On-Prem LLM Kurulumu: Donanım Gereksinimleri ve Maliyet Hesabı

On-prem LLM kurulumu nasıl yapılır? On-prem LLM kurulumu, açık kaynak bir büyük dil modelini üçüncü taraf bir bulut API'sine göndermek yerine kurumun kendi veri merkezinde veya özel altyapısında, kendi GPU sunucularında barındırıp çalıştırma sürecidir; ve dört kararın birlikte tasarlandığı bir sistem mühendisliği işidir: model boyutuna göre donanım gereksinimleri (GPU, VRAM, bellek, depolama), modeli sığdırıp maliyeti düşüren kuantizasyon, isteği güvenilir bir servise çeviren sunum yığını (çıkarım sunucusu ve orkestrasyon) ve kararı belirleyen maliyet modeli (CAPEX, OPEX ve toplam sahip olma maliyeti). Bu rehber, bu dört katmanı bir yapay zeka mühendisi ve danışman titizliğiyle uçtan uca ele alıyor.

On-prem LLM kurulumu son iki yılda niş bir tercihten kurumsal gündemin merkezine taştı. Bunun iki itici gücü var: açık kaynak modellerin kalitesinin kapalı modellere gözle görülür biçimde yaklaşması ve veri egemenliği ile KVKK kaygılarının kurumsal karar süreçlerinde ağırlık kazanması. Ama on-prem LLM kurulumu, "bir GPU alıp bir model indirmek" kadar basit değildir; yanlış boyutlandırılmış donanım, hesaba katılmayan işletme yükü ve ölçülmemiş bir maliyet modeli, iyi niyetli projeleri hızla hayal kırıklığına çevirir. Dil modelinin ne olduğu konusunda temele ihtiyacınız varsa önce LLM nedir yazısını, kurulumda kullanacağınız açık modeller için açık kaynak LLM nedir rehberini okumanız faydalı olur.

Tanım

On-Prem LLM Kurulumu (Kurum İçi Büyük Dil Modeli Kurulumu)

Açık kaynak bir büyük dil modelini (LLM) üçüncü taraf bir bulut API'sine göndermek yerine kurumun kendi veri merkezinde, kolokasyonda veya özel altyapısında GPU sunucuları üzerinde barındırıp çalıştırma sürecidir. On-prem LLM kurulumu; donanım gereksinimleri (GPU, VRAM, bellek, depolama), model ve kuantizasyon seçimi, sunum yığını (çıkarım sunucusu, orkestrasyon, gözlemlenebilirlik) ve maliyet modeli (CAPEX, OPEX, toplam sahip olma maliyeti) kararlarının birlikte tasarlandığı bir sistem mühendisliği işidir. Temel gerekçeleri veri egemenliği/KVKK, öngörülebilir gecikme ve yeterli hacimde birim maliyet avantajıdır.

Ayrıca: self-hosted llm, kurum içi llm, on-premises dil modeli, özel llm altyapısı, yerel llm barındırma

On-prem LLM kurulumu, bir dil modelini "hizmet olarak" satın almak yerine, o modeli çalıştıran altyapının sahipliğini ve kontrolünü kuruma almaktır. Bir API kullandığınızda modeli sağlayıcının veri merkezinde çalıştırırsınız; verinizi oraya gönderir, yanıtı geri alırsınız. On-prem kurulumda ise model, ağırlıkları ve çalıştığı GPU'lar sizin denetiminizdedir; veri kurum sınırlarının dışına hiç çıkmaz. Bu temel fark, hem gerekçeleri hem de sorumlulukları belirler.

Birinci ve çoğu zaman en belirleyici gerekçe veri egemenliğidir. Kişisel veri, ticari sır, hukuki belge veya sağlık verisi gibi hassas içerikle çalışan kurumlar için istemlerin ve belgelerin üçüncü bir tarafa gönderilmemesi bir tercih değil, çoğu zaman bir zorunluluktur. On-prem LLM kurulumu, veriyi fiziksel ve mantıksal olarak kurum içinde tuttuğu için bu gereksinimi doğrudan karşılar. KVKK ve veri egemenliği boyutunu KVKK nedir ve KVKK uyumlu yapay zeka nedir yazılarında derinlemesine ele alıyoruz.

İkinci gerekçe maliyet ekonomisidir — ama koşullu biçimde. Yüksek, öngörülebilir ve sürekli bir kullanım hacminde, kendi donanımınızda token başına maliyeti sabitlemek, API'nin değişken kullanım maliyetine göre belli bir eşiğin üstünde avantajlı olabilir. Bu avantaj otomatik değildir; ancak GPU'lar yüksek doluluk oranıyla çalıştığında ortaya çıkar. Üçüncü gerekçe öngörülebilirlik ve bağımsızlıktır: gecikme dış bir sağlayıcının yüküne bağlı olmaz, sağlayıcının fiyat veya model kullanımdan kaldırma kararlarına tabi kalmazsınız ve modeli tümüyle kendi ihtiyacınıza göre ayarlayabilirsiniz.

Bu gerekçelerin karşısında, on-prem'in getirdiği sorumluluklar durur: donanım yatırımı, işletme yükü, güvenlik ve en yeni modellere erişimde olası gecikme. On-prem LLM kurulumu bu ödünleşimi bilinçli tartmaktır; ideolojik bir "bulut kötü" veya "on-prem kötü" tutumu değil, kurumun verisine, hacmine ve kapasitesine bakan mühendislik kararı.

Bu dört gerekçenin ağırlığı sektöre ve kuruma göre değişir. Bir yazılım girişimi için hız ve esneklik her şeydir; bu kurum büyük olasılıkla API ile başlar ve ölçek geldiğinde on-prem'i değerlendirir. Bir kamu kurumu veya bir banka için ise veri egemenliği çoğu zaman en baştan belirleyicidir; bu kurum, maliyet hesabı API'yi işaret etse bile hassas iş yüklerini on-prem'de tutmayı tercih edebilir. Bu yüzden "on-prem mi API mi" sorusunun evrensel bir doğru cevabı yoktur; doğru cevap, kurumun risk profili, veri hassasiyeti ve stratejik önceliklerine göre değişir. Bu rehberin amacı, size tek bir cevap dayatmak değil, kararı sağlam biçimde verebilmeniz için gereken çerçeveyi ve ölçütleri sunmaktır.

Veri Egemenliği, KVKK ve Uyum Bağlamı

Türkiye'de ve Avrupa'da faaliyet gösteren kurumlar için veri egemenliği giderek daha somut bir kısıt haline geliyor. Kişisel verinin nerede işlendiği, yurt dışına aktarılıp aktarılmadığı ve hangi sağlayıcının hangi sıfatla veriye eriştiği, hem KVKK hem de sektörel düzenlemeler açısından denetlenen başlıklardır. On-prem LLM kurulumu, veriyi kurum sınırında tutarak bu başlıkların çoğunu sadeleştirir; ama tek başına uyumu sağlamaz. Erişim kontrolü, loglama, saklama süresi, anonimleştirme ve aydınlatma gibi yükümlülükler, model nerede çalışırsa çalışsın tasarlanmalıdır. Düzenleyici çerçevenin geniş resmi için EU AI Act nedir yazısına bakabilirsiniz. Bu bölüm bilgilendirme amaçlıdır ve hukuki tavsiye değildir; kurumunuzun özel durumunu hukuk ve uyum birimleriyle değerlendirmelisiniz.

On-Prem, Bulut ve Hibrit Arasındaki Fark

Kararı ikili bir "on-prem mi bulut mu" seçimine indirgemek yanıltıcıdır; gerçekte bir yelpaze vardır. Bir uçta tam yönetilen API (model tümüyle sağlayıcıda), diğer uçta tam on-prem (donanım kurumun veri merkezinde) yer alır. Aralarında özel bulut (VPC içinde ayrılmış GPU), kolokasyon (kurumun sahip olduğu donanım üçüncü taraf veri merkezinde) ve hibrit (hassas iş yükleri on-prem, gerisi API'de) gibi ara modeller bulunur. Çoğu kurum için en gerçekçi başlangıç, saf bir uç değil, hassas veriyi on-prem'de tutan ve gerisini esnek biçimde yöneten bir hibrit modeldir. Bulut ve on-prem'in KVKK açısından karşılaştırmasını ayrı bir rehberde ele alıyoruz.

On-prem LLM kurulumunun ilk somut kararı, hangi açık kaynak modelin çalıştırılacağıdır; ve bu karar diğer her şeyden önce gelir, çünkü seçtiğiniz model hem donanım gereksinimlerini hem de nihai kaliteyi doğrudan belirler. Kapalı API modellerinin aksine, on-prem senaryoda ağırlıkları indirilebilen açık modelleri kullanırsınız; bu yüzden seçim, bir sağlayıcının kısıtlı menüsünden değil, giderek genişleyen ve kalitesi hızla artan bir açık model ekosisteminden yapılır. Açık modellerin genel çerçevesi için açık kaynak LLM nedir yazısı iyi bir başlangıçtır.

Model Ailesi ve Boyut

Açık model ekosisteminde çeşitli aileler ve her ailede farklı parametre boyutları bulunur; küçük (birkaç milyar parametre), orta (7-13 milyar), büyük (30-70 milyar) ve çok büyük (yüz milyar ve üzeri) kademeler tipiktir. Boyut arttıkça kalite genellikle yükselir ama donanım maliyeti daha hızlı artar; bu yüzden seçim bir "en büyüğü al" kararı değil, göreve yetecek en küçük modeli bulma disiplinidir. Ayrıca modeller taban (base) ve talimat-ayarlı (instruct) sürümlerle gelir; kurumsal asistan senaryolarının çoğunda, talimatları takip etmek üzere ayarlanmış instruct sürümler tercih edilir. Bir model ailesinin boyut ve sürüm çeşitliliğine örnek olarak Llama nedir yazısına bakabilirsiniz; benzer mantık diğer açık ailelerde de geçerlidir.

Lisans ve Ticari Kullanım

On-prem model seçiminde sık atlanan ama kritik bir boyut lisanstır. Açık ağırlıklı modeller aynı özgürlükte gelmez: bazıları izin verici (permissive) lisanslarla geniş ticari kullanıma açıktır, bazıları belirli kısıtlar (kullanıcı ölçeği, kullanım alanı, yeniden dağıtım koşulları) taşır. Bir modeli kurumsal üretime almadan önce, lisansının ticari kullanımınıza ve dağıtım biçiminize uygun olduğunu doğrulamak gerekir; aksi halde teknik olarak mükemmel bir kurulum, hukuki bir risk taşıyabilir. Bu değerlendirme hukuki tavsiye değildir; model lisanslarını kurumunuzun hukuk birimiyle birlikte gözden geçirin.

Türkçe Yeterliliği ve Göreve Uygunluk

Türkçe ağırlıklı bir kullanım senaryosunda, modelin Türkçe yeterliliği doğrudan kaliteyi belirler. Bazı açık modeller çok dilli olarak eğitilir ve Türkçeyi güçlü temsil ederken, bazıları ağırlıklı İngilizce veriyle eğitildiği için Türkçede zayıf kalır. Buradaki tek sağlam yöntem, aday modelleri kendi göreviniz ve kendi Türkçe verinizle bir değerlendirme kümesinde karşılaştırmaktır; genel sıralamalar yol gösterici olabilir ama sizin göreviniz için kesin cevap değildir. Doğal dil işleme temeli için doğal dil işleme nedir yazısı bağlam sağlar. Pratik kural şudur: birkaç aday modeli aynı görevde ölçün, kaliteyi ve donanım maliyetini birlikte tartın ve göreve yetecek en verimli modeli seçin; on-prem LLM kurulumunda model seçimi de tıpkı donanım gibi ölçümle verilen bir karardır.

On-prem LLM kurulumunun kalbi donanım gereksinimleridir ve bu gereksinimlerin merkezinde tek bir bileşen durur: GPU. Dil modeli çıkarımı, milyarlarca parametrenin (ağırlığın) her token üretiminde okunmasını gerektiren, bellek bant genişliğine aç bir iştir; ve bu ağırlıkların hızlıca erişilebilir olması için GPU belleğinde (VRAM) tutulması gerekir. Bu yüzden on-prem LLM kurulumunda donanım gereksinimlerini boyutlandırmanın ilk kuralı şudur: önce modeli seç, sonra o modelin VRAM ihtiyacına göre donanımı boyutlandır.

Donanımı dört kaynak ekseninde düşünmek faydalıdır: hesaplama (GPU), bellek (VRAM ve sistem RAM'i), depolama ve ağ. Bu eksenlerden hangisinin darboğaz olacağı, iş yükünün doğasına bağlıdır; ama çıkarım senaryolarının ezici çoğunluğunda kısıtlayıcı kaynak VRAM'dir. GPU kavramının temeli için GPU nedir yazısı iyi bir zemin sunar.

GPU ve VRAM Gereksinimleri

GPU, on-prem LLM kurulumunun en pahalı ve en belirleyici bileşenidir. GPU seçiminde iki özellik öne çıkar: VRAM miktarı (modelin sığıp sığmayacağını belirler) ve bellek bant genişliği (üretim hızını, yani token/saniye verimini büyük ölçüde belirler). Hesaplama gücü (FLOPS) de önemlidir ama çıkarımda çoğu zaman bant genişliği kadar belirleyici değildir; çünkü çıkarım, hesaplamadan çok bellekten veri okumakla sınırlıdır.

VRAM ihtiyacını kaba ama işe yarar bir kuralla tahmin edebilirsiniz: yarı hassasiyette (FP16/BF16) çalışan bir modelin ağırlıkları, parametre sayısının yaklaşık iki katı gigabayt yer kaplar. Yani 7-8 milyar parametreli bir model ağırlıkları için ~14-16 GB, 13 milyarlık ~26 GB, 70 milyarlık ~140 GB VRAM ister. Bu yalnızca ağırlıklardır; gerçek ihtiyaç, bağlam penceresi ve eşzamanlı istekler için tutulan KV önbelleği (anahtar-değer önbelleği) ile büyür. Uzun bağlam ve yüksek eşzamanlılıkta bu ek, ağırlıkların yanında ciddi bir pay tutabilir. Token ve bağlam kavramları için token nedir ve context window nedir yazıları yol gösterir.

Pratik sonuç şudur: tek bir modern veri merkezi GPU'su küçük ve orta boy modelleri (kabaca 7B-13B) rahatça barındırır; büyük modeller (70B ve üzeri) için ya çok GPU'lu bir sunucu ya da agresif kuantizasyon gerekir. Birden fazla GPU kullanıldığında, model katmanları GPU'lara bölünür (tensor/pipeline paralelliği) ve bu GPU'lar arasında yüksek hızlı bir ara bağlantı (örneğin GPU'lar arası doğrudan bağlantı) verimi doğrudan etkiler; yavaş bir ara bağlantı, çok GPU'lu bir sunucuyu tek GPU hızına düşürebilir.

Sistem Belleği, Depolama ve Ağ

GPU tek başına yeterli değildir. Sistem belleği (RAM), modeli diskten okuyup GPU'ya yüklerken ve işletim sistemi ile çıkarım sunucusu çalışırken kullanılır; genel bir başlangıç kuralı, sistem RAM'ini toplam VRAM'in en az birkaç katı tutmaktır. Yetersiz RAM, model yükleme ve takas (swap) sırasında sinsi yavaşlamalara yol açar.

Depolama tarafında iki ihtiyaç vardır: model ağırlıklarını hızlı yükleyecek hızlı disk ve verinizi/loglarınızı tutacak kapasite. Model dosyaları on gigabaytlar mertebesinde olabilir; bunları saniyeler içinde belleğe almak için NVMe SSD tercih edilir, çünkü mekanik disk hem yavaş yükleme hem de uzun soğuk başlatma süreleri anlamına gelir. Ağ tarafında, tek sunuculu bir kurulumda ağ nadiren darboğazdır; ama çok düğümlü (multi-node) bir ölçekleme, dağıtık bir depolama veya yoğun bir kullanıcı trafiği söz konusuysa, ağ bant genişliği ve gecikmesi tasarımın parçası olur.

Depolama planlamasında sık atlanan bir nokta, birden çok model ve sürümü aynı anda tutma ihtiyacıdır. Üretimde çoğu zaman tek bir model dosyası değil; farklı boyutlarda modeller, aynı modelin farklı kuantizasyon sürümleri, yedekler ve deneme sürümleri bir arada bulunur. Bu, beklenenden hızlı büyüyen bir depolama ihtiyacı yaratır. Ayrıca soğuk başlatma süresi — bir modeli diskten belleğe yükleme süresi — kullanıcı deneyimini etkiler; nadiren çağrılan bir modeli her seferinde yeniden yüklemek gecikme ekler. Bu yüzden depolamayı yalnızca kapasite olarak değil, hız ve model yaşam döngüsü yönetimi olarak da planlamak gerekir; bu, on-prem LLM kurulumunun görünmeyen ama işletmede hissedilen bir ayrıntısıdır.

CPU, Güç, Soğutma ve Fiziksel Altyapı

CPU, çıkarım senaryolarının çoğunda darboğaz değildir; ana görevi veriyi hazırlayıp GPU'yu beslemektir. Yine de yeterli çekirdek ve bellek bant genişliği, GPU'ların aç kalmamasını sağlar. Sık atlanan ama on-prem'de belirleyici olan iki kalem güç ve soğutmadır. Modern veri merkezi GPU'ları yüksek güç çeker ve ciddi ısı üretir; bu, hem elektrik faturasını hem de soğutma altyapısını (havalandırma, gerekiyorsa sıvı soğutma) doğrudan etkiler. Bir sunucu odasının güç ve soğutma kapasitesi, kaç GPU'yu güvenle çalıştırabileceğinizin fiziksel sınırıdır; bu sınır çoğu zaman GPU bütçesinden önce devreye girer.

On-prem LLM kurulumunda donanım kaynakları ve rolleri

Kaynak	Rolü	Darboğaz olursa belirtisi
GPU / VRAM	Modeli barındırır, üretim hızını belirler	Model sığmaz veya token/saniye düşük
Bellek bant genişliği	Token üretim hızının asıl belirleyicisi	Güçlü GPU'da bile yavaş üretim
Sistem RAM'i	Model yükleme ve OS/servis	Yavaş yükleme, takas kaynaklı duraklama
NVMe depolama	Ağırlıkları hızlı yükler	Uzun soğuk başlatma süreleri
GPU'lar arası ara bağlantı	Çok GPU'lu verimi belirler	Çok GPU tek GPU hızına düşer
Güç ve soğutma	Fiziksel çalışma sınırı	Termal kısılma, kararsızlık, arıza

On-prem LLM kurulumunda donanım gereksinimlerini boyutlandırmanın en pratik yolu, model boyutunu bir başlangıç noktası olarak almaktır. Model ne kadar büyükse, o kadar çok VRAM, o kadar çok GPU ve o kadar çok güç gerekir; ama bu ilişki doğrusal olmaktan çok basamaklıdır, çünkü GPU'lar belirli VRAM kademeleriyle gelir ve bir modeli tek GPU'ya sığdırmak ile birden çok GPU'ya bölmek arasında keskin bir karmaşıklık farkı vardır.

Aşağıdaki tablo, yaygın model boyutları için yaklaşık VRAM ihtiyacını hem yarı hassasiyette (FP16) hem de 4 bit kuantizasyonda özetler. Bu sayılar illüstratiftir ve yalnızca ağırlıkları kabaca gösterir; gerçek ihtiyaç bağlam uzunluğu, eşzamanlı istek sayısı ve çalışma zamanına göre değişir. Kendi senaryonuzda kesin rakamı, seçtiğiniz modeli hedef donanımda ölçerek bulmalısınız.

Model boyutuna göre yaklaşık VRAM ihtiyacı (illüstratif; yalnızca ağırlıklar, kendi verinizle ölçün)

Model boyutu	FP16 ağırlık VRAM (~)	4-bit ağırlık VRAM (~)	Tipik on-prem kurulum
7-8 milyar	~14-16 GB	~5-6 GB	Tek orta-üst GPU
13 milyar	~26 GB	~9-10 GB	Tek üst düzey GPU
30-34 milyar	~60-70 GB	~18-22 GB	Tek büyük GPU veya çift GPU
70 milyar	~140 GB	~40-48 GB	Çok GPU'lu sunucu
Çok büyük (100B+)	Yüzlerce GB	On-larca-yüz GB	Çok GPU / çok düğüm

Tablodan çıkan üç pratik ders var. Birincisi, kuantizasyonun oyunu değiştirdiğidir: 4 bitte 70 milyarlık bir model, yarı hassasiyette olduğunun yaklaşık dörtte biri VRAM ile çalışabilir ve bu, "çok GPU'lu sunucu" ihtiyacını bazen "tek büyük GPU"ya indirebilir. İkincisi, ağırlıkların hikâyenin tamamı olmadığıdır; bağlam ve eşzamanlılık için KV önbelleği eklendiğinde gerçek ihtiyaç bu rakamların üstüne çıkar, bu yüzden VRAM'i her zaman bir emniyet payıyla boyutlandırmak gerekir. Üçüncüsü, "en büyük model her zaman en iyisi değildir": iyi kuantize edilmiş orta boy bir model, çoğu kurumsal görevde belirgin biçimde daha ucuz bir donanımla kabul edilebilir kalite verebilir; hangi boyutun gerçekten gerektiğini görevinizde ölçerek kararlaştırın. Model aileleri ve boyut seçenekleri için Llama nedir yazısı bir örnek çerçeve sunar.

On-prem LLM kurulumunda en çok tartışılan donanım kararı, hangi tür GPU'nun alınacağıdır. Kabaca iki dünya vardır: tüketici sınıfı GPU'lar (masaüstü/oyun kartları) ve veri merkezi sınıfı GPU'lar (sunuculara özel, yüksek VRAM'li kartlar). İkisi arasındaki seçim, yalnızca fiyat değil; VRAM kapasitesi, çok GPU ölçekleme, dayanıklılık, garanti ve lisans gibi boyutları da kapsar.

Tüketici GPU'ları görece ucuzdur ve küçük ölçekli deneyler, tek kullanıcılı senaryolar veya bir pilot için cazip bir başlangıç sağlar. Sınırları ise nettir: VRAM kapasiteleri veri merkezi kartlarına göre düşüktür, çok GPU'lu ölçeklemede gereken yüksek hızlı ara bağlantıdan yoksundurlar, 7/24 kesintisiz üretim yükü için tasarlanmamışlardır ve bazı üreticilerin lisans koşulları veri merkezinde kullanımı kısıtlayabilir. Bu yüzden tüketici kartları çoğu zaman "öğrenme ve prototip" için mantıklıdır, ciddi üretim için değil.

Veri merkezi GPU'ları ise pahalıdır ama on-prem üretim için tasarlanmıştır: yüksek VRAM (büyük modelleri tek kartta veya az sayıda kartta barındırır), GPU'lar arası yüksek hızlı bağlantı (çok GPU verimini korur), sürekli yük için dayanıklılık ve kurumsal garanti/destek sunar. Yüksek ve sürekli bir iş yükü hedefliyorsanız, veri merkezi GPU'larının daha yüksek ön maliyeti, güvenilirlik ve ölçeklenebilirlikle geri döner. Karar yine kullanım profiline bağlıdır: bir öğrenme pilotu için tüketici kartı yeterliyken, çok kullanıcılı bir kurumsal servis için veri merkezi sınıfı GPU neredeyse zorunludur.

Üçüncü bir yol, GPU'yu hiç satın almadan bulutta veya kolokasyonda kiralamaktır; bu, ön yatırımı ortadan kaldırır ve pilot aşamasında gerçek iş yükünü ölçmenizi sağlar. Pratik ve maliyet-akılcı bir strateji şudur: pilotu kiralık GPU üzerinde ölçün, gerçek verim ve hacmi görün, ancak yüksek ve sürekli kullanım kanıtlandığında satın almaya geçin. GPU'nun mimari temeli ve neden bu iş için uygun olduğu konusunda GPU nedir yazısı iyi bir zemin sunar.

Soyut kuralları somuta indirmek için, on-prem LLM kurulumunda sık karşılaşılan üç boyutlandırma senaryosunu ele alalım. Bu senaryolar illüstratiftir ve kesin donanım seçimini değil, düşünme çerçevesini gösterir; kendi kalite eşiğiniz ve hacminizle doğrulamalısınız.

Senaryo 1: Küçük Ekip, Dar Kapsamlı İç Asistan

Bir ekibin, sınırlı sayıda kullanıcıya iç dokümantasyon üzerinde soru-cevap sunan dar kapsamlı bir asistan kurduğunu düşünün. Burada orta boy (7-13 milyar) iyi kuantize edilmiş bir model çoğu zaman yeterlidir; bu model tek bir üst düzey GPU'ya rahatça sığar. Eşzamanlılık düşük olduğundan verim baskısı azdır; asıl odak, kurulumu tekrarlanabilir ve işletilebilir kılmaktır. Bu senaryoda on-prem'in gerekçesi genellikle veri hassasiyetidir, saf ölçek ekonomisi değil.

Senaryo 2: Orta Ölçekli Çok Kullanıcılı Servis

Onlarca-yüzlerce eşzamanlı kullanıcıya hizmet veren bir müşteri destek veya bilgi asistanı, farklı bir tablo çizer. Burada verim ve gecikme kritik olur; sürekli toplu işlem yapan üretim sınıfı bir çıkarım sunucusu, yatay ölçekleme için birden çok kopya ve dikkatli KV önbellek yönetimi gerekir. Model boyutu göreve göre orta-büyük olabilir; kuantizasyon, aynı donanımdan daha çok kullanıcı çıkarmanın anahtarıdır. Bu senaryoda donanım genellikle bir veya birkaç veri merkezi GPU'lu sunucudur ve gözlemlenebilirlik olmazsa olmazdır.

Senaryo 3: Büyük Model, Yüksek Kalite İhtiyacı

En zorlu kaliteyi gerektiren senaryolarda (karmaşık muhakeme, uzun bağlam) büyük bir model (70 milyar ve üzeri) gerekebilir. Bu, çok GPU'lu bir sunucu ve GPU'lar arası yüksek hızlı bağlantı demektir; agresif kuantizasyon, bu maliyeti bir miktar dizginleyebilir ama fiziksel altyapı (güç, soğutma) ciddi biçimde devreye girer. Bu senaryoda karar, "gerçekten bu kaliteye ihtiyacım var mı" sorusuyla başlamalı; çünkü büyük modelin TCO'su, orta modelin katları olabilir. Sık sık, iyi kuantize edilmiş bir orta model + güçlü bir RAG katmanı, çok daha ucuz bir donanımla büyük modele yakın iş çıkarır.

Kuantizasyon, on-prem LLM kurulumunun ekonomisini en çok değiştiren tek tekniktir. Kuantizasyon, model ağırlıklarını daha az bit ile temsil etme işlemidir: tipik olarak 16 bitlik kayan noktalı sayılar yerine 8 bit veya 4 bitlik tamsayılara indirgenir. Ağırlıklar daha az yer kapladığından, model daha küçük bir VRAM'e sığar; bu da ya daha ucuz bir GPU kullanmayı ya da aynı GPU'da daha büyük bir modeli çalıştırmayı mümkün kılar. Böylece kuantizasyon, donanım gereksinimlerini ve dolayısıyla hem CAPEX hem OPEX'i doğrudan aşağı çeker.

Kuantizasyonun neden bu kadar etkili olduğunu anlamak için çıkarımın doğasına bakmak gerekir: çıkarım büyük ölçüde bellekten ağırlık okumakla sınırlıdır. Ağırlıkları yarıya (8 bit) veya dörtte bire (4 bit) indirmek, hem gereken VRAM'i hem de okunacak veri miktarını azaltır; bu yalnızca modeli sığdırmakla kalmaz, bazı durumlarda üretim hızını da artırır. Bu yüzden kuantizasyon, on-prem senaryolarında neredeyse varsayılan bir uygulama haline gelmiştir.

Kuantizasyon Seviyeleri ve Formatları

Kuantizasyon bir "aç-kapa" düğmesi değil, bir yelpazedir. Yaygın kademeler şunlardır: 8 bit (kaliteyi neredeyse tam korurken belleği yaklaşık yarıya indirir), 4 bit (belleği yaklaşık dörtte bire indirir, modern yöntemlerle çoğu görevde kabul edilebilir kalite kaybı) ve daha agresif alt kademeler (daha çok tasarruf ama artan kalite riski). Ayrıca yalnızca ağırlıkları mı yoksa hem ağırlıkları hem aktivasyonları mı kuantize ettiğiniz de önemlidir; ağırlık-yalnız kuantizasyon çıkarımda en yaygın ve en pratik olanıdır.

Pratik ekosistemde çeşitli kuantizasyon yöntem ve formatları vardır; bunlar kalibrasyon verisi kullanıp kullanmaması, hangi çalışma zamanıyla uyumlu olduğu ve hız-kalite dengesi bakımından farklılaşır. Buradaki teknik ayrıntıya girmeden önemli olan ilke şudur: seçtiğiniz format, kullanacağınız çıkarım sunucusuyla ve GPU'nuzla uyumlu olmalıdır. Kavramsal temel için token nedir ve daha geniş çerçeve için açık kaynak LLM nedir yazıları bağlam sağlar. Masaüstü veya küçük ölçekli denemelerde kuantize modelleri kolayca çalıştırmak için Ollama nedir yazısında ele aldığımız gibi hafif yerel çalışma zamanları iyi bir başlangıçtır.

Kuantizasyonun Ödünleşimleri ve Doğru Kullanımı

Kuantizasyon bedava bir öğle yemeği değildir; ölçülü bir kalite ödünleşimi taşır. Daha agresif kuantizasyon daha çok tasarruf sağlar ama muhakeme gerektiren, çok adımlı veya nüanslı görevlerde küçük kalite düşüşleri görülebilir. Kritik kural şudur: kuantizasyon düzeyini soyut bir "ne kadar çok o kadar iyi" mantığıyla değil, kendi görevinizde doğruluğu ölçerek seçin. Aynı görev için birkaç kuantizasyon düzeyini bir değerlendirme kümesiyle karşılaştırmak, kalite ile maliyet arasındaki doğru noktayı gösterir.

Deneyimli bir yaklaşım şöyledir: taban çizgisini yarı hassasiyette (veya 8 bitte) kurun ve kaliteyi ölçün; sonra 4 bite inip aynı görevde kaliteyi yeniden ölçün. Kayıp kabul edilebilirse, sağladığınız donanım tasarrufu net kazançtır; kayıp göreviniz için fazlaysa, bir üst kademeye dönün. Bu ölçüm disiplini, kuantizasyonu bir tahmin olmaktan çıkarıp bilinçli bir mühendislik kararına dönüştürür.

Kuantizasyonun bir de ekonomik çarpan etkisi vardır. Modeli 4 bite indirmek yalnızca "sığdırmakla" kalmaz; çoğu zaman daha küçük ve ucuz bir GPU sınıfına geçmeyi, daha az GPU kullanmayı veya aynı GPU'da daha çok eşzamanlı kullanıcıyı barındırmayı mümkün kılar. Bu üç etki de doğrudan TCO'yu aşağı çeker. Bir başka deyişle, kuantizasyon on-prem LLM kurulumunda yalnızca teknik bir sığdırma hilesi değil, maliyet modelinin merkezî bir kaldıracıdır. Bu yüzden donanımı boyutlandırmadan önce kuantizasyon kararını vermek gerekir: önce hangi hassasiyette çalışacağınıza karar verin, VRAM ihtiyacını ona göre hesaplayın, sonra donanımı seçin. Sırayı tersine çevirmek — önce donanım alıp sonra kuantizasyonu düşünmek — çoğu zaman gereğinden pahalı bir kuruluma yol açar.

Kuantizasyon seviyeleri: yaklaşık bellek tasarrufu ve ödünleşim (illüstratif)

Seviye	Bellek ayak izi	Kalite etkisi	Tipik kullanım
FP16/BF16 (taban)	Tam	Referans kalite	Bol VRAM, kalite önceliği
8-bit	~%50	Çok küçük kayıp	Dengeli üretim tercihi
4-bit	~%25	Çoğu görevde kabul edilebilir	On-prem varsayılan başlangıcı
4-bit altı (agresif)	En düşük	Artan risk, göreve bağlı	Sıkı VRAM kısıtı, dikkatli test

Donanım gereksinimlerini boyutlandırırken en çok yanlış hesaplanan kalem, bağlam ve eşzamanlılık için gereken bellektir. Model ağırlıkları VRAM'in yalnızca bir bölümüdür; üretim sırasında her aktif istek, o ana kadarki bağlamı temsil eden bir KV önbelleği (anahtar-değer önbelleği) tutar ve bu önbellek, uzun bağlamda ve yüksek eşzamanlılıkta hızla büyür. On-prem LLM kurulumunda gerçek VRAM ihtiyacını doğru tahmin etmek, bu önbelleği hesaba katmayı gerektirir; yoksa üretimde beklenmedik bellek taşmaları ve düşen eşzamanlılık sınırlarıyla karşılaşırsınız.

KV önbelleğinin büyüklüğü üç şeye bağlıdır: bağlam uzunluğu (daha uzun istem ve yanıt daha çok önbellek), eşzamanlı istek sayısı (her istek kendi önbelleğini tutar) ve modelin iç boyutları. Pratik sonuç şudur: 100 eşzamanlı kullanıcıya uzun bağlamla hizmet vermek, tek kullanıcıya kısa bağlamla hizmet vermekten kat kat fazla VRAM ister; ve bu ek, çoğu zaman ağırlıkların yanında hafife alınır. Bu yüzden donanımı yalnızca "model sığıyor mu" diye değil, "hedeflediğim eşzamanlılık ve bağlam uzunluğunda önbellekle birlikte sığıyor mu" diye boyutlandırmak gerekir.

Bu bellek baskısını yönetmenin birkaç kaldıracı vardır. Birincisi, olgun çıkarım sunucularının verimli önbellek yönetimi (örneğin önbelleği sayfalara bölerek parçalanmayı azaltan teknikler) sayesinde aynı VRAM'den çok daha fazla eşzamanlı istek çıkarmasıdır. İkincisi, gereksiz uzun bağlamdan kaçınmaktır; bağlam bütçesini disiplinli yönetmek hem belleği hem maliyeti düşürür. Üçüncüsü, kuantizasyonun yalnızca ağırlıkları değil, bazı durumlarda önbelleği de küçültebilmesidir. Bağlam penceresinin ne olduğunu ve neden sınırlı olduğunu context window nedir yazısında ele alıyoruz; bu sınır, on-prem bellek planlamasının doğrudan girdisidir.

Bir GPU'ya bir model yüklemek, on-prem LLM kurulumunun yalnızca başlangıcıdır. Ham GPU'yu çok kullanıcılı, güvenilir ve gözlemlenebilir bir servise dönüştüren şey sunum yığınıdır (serving stack). Sunum yığını üç ana katmandan oluşur ve verimin, gecikmenin ve işletilebilirliğin büyük kısmını bu katmanlar belirler; model seçimi kadar, hatta bazen ondan çok bu yığın kararları başarıyı belirler.

Çıkarım Sunucusu (Inference Server)

Sunum yığınının merkezi, çıkarım sunucusudur (inference server): gelen istekleri karşılayan, bellek ve eşzamanlılığı yöneten ve GPU'dan mümkün olan en yüksek verimi çıkaran katman. Naif bir yaklaşımda her isteği tek tek işlerseniz GPU'yu çok verimsiz kullanırsınız. Olgun çıkarım sunucuları, sürekli toplu işlem (continuous batching) gibi tekniklerle birden çok isteği aynı anda işler ve KV önbelleğini verimli yöneterek tek bir GPU'dan kat kat daha yüksek verim elde eder. Bu, on-prem ekonomisini doğrudan etkiler: daha yüksek verim, aynı donanımda daha düşük token başına maliyet demektir.

Çıkarım sunucusu seçiminde ürün adından çok yeteneklere bakılır: desteklenen modeller ve kuantizasyon formatları, verim ve gecikme profili, çok GPU ve çok düğüm ölçekleme desteği, gözlemlenebilirlik ve standart (örneğin OpenAI-uyumlu) bir API sunması. Basit, tek kullanıcılı veya masaüstü senaryolarda hafif yerel çalışma zamanları yeterlidir; kurumsal, çok kullanıcılı ve düşük gecikme hedefli üretim senaryolarında üretim sınıfı bir çıkarım sunucusu tercih edilir. Doğru seçim, kendi iş yükünüzle yaptığınız ölçümden çıkar.

OpenAI-uyumlu bir API sunmanın pratik değeri özellikle büyüktür. Çoğu kurumsal uygulama ve kütüphane, yaygın bir API sözleşmesine göre yazılmıştır; çıkarım sunucunuz aynı sözleşmeyi konuşuyorsa, uygulama kodunu değiştirmeden API sağlayıcısı ile on-prem arasında geçiş yapabilirsiniz. Bu, hem hibrit mimarileri (bazı iş yükleri API'de, bazıları on-prem) kolaylaştırır hem de sağlayıcı bağımlılığını azaltır: yarın modeli veya barındırma yerini değiştirmek isterseniz, arayüz sabit kaldığı için geçiş ucuzlar. Bu tür bir soyutlama, on-prem LLM kurulumunu geleceğe daha dayanıklı kılan basit ama güçlü bir tasarım kararıdır.

Orkestrasyon ve Ölçekleme Katmanı

Tek bir çıkarım sunucusu bir başlangıçtır; kurumsal kullanım genellikle birden çok kopya (replika), yük dengeleme, otomatik ölçekleme ve dayanıklılık ister. Bu ihtiyaçları orkestrasyon katmanı karşılar: konteynerleştirme ve bir orkestratör (örneğin container orkestrasyonu), model kopyalarını çalıştırır, trafiği dağıtır, arızalı kopyayı değiştirir ve talep arttığında ölçeği büyütür. Orkestrasyon, on-prem LLM kurulumunu bir "tek sunucu deneyi"nden dayanıklı bir servise taşıyan katmandır.

Ölçekleme kararlarında iki desen öne çıkar: dikey ölçekleme (daha güçlü/daha çok GPU'lu tek sunucu) ve yatay ölçekleme (daha çok sunucu/kopya). Büyük tek model için dikey, yüksek eşzamanlılık için yatay ölçekleme uygundur; çoğu üretim sistemi ikisini birlikte kullanır. Model yönetiminin işletme boyutu — sürümleme, dağıtım, geri alma — bir MLOps nedir ve dil modeline özel olarak LLMOps nedir disiplini gerektirir; bu disiplin, on-prem'i sürdürülebilir kılan görünmez omurgadır.

Gözlemlenebilirlik, API Ağ Geçidi ve Güvenlik Katmanı

Üçüncü katman, servisi işletilebilir ve güvenli kılan çevre bileşenlerdir. Gözlemlenebilirlik, gecikme, verim (token/saniye), hata oranı, GPU kullanımı ve bellek doluluğu gibi metrikleri sürekli izler; bu olmadan sistemin ne zaman ve neden yavaşladığını göremezsiniz. Bir API ağ geçidi, kimlik doğrulama, oran sınırlama (rate limiting), kotalar ve yönlendirme sağlar; farklı ekiplere aynı altyapıdan güvenli erişim verir. Güvenlik katmanı ise ağ yalıtımı, erişim kontrolü ve istem/yanıt denetimi ile modeli ve veriyi korur. Bu katmanları baştan kurmak, sonradan eklemekten hem daha kolay hem daha güvenlidir.

Nasıl Yapılır

On-prem LLM sunum yığınını kurma adımları

Ham GPU'dan güvenilir bir çıkarım servisine giden temel katmanları kurma sırası.

1. 1

   Modeli ve kuantizasyonu belirle

   Görevi çözecek en küçük modeli ve uygun kuantizasyon düzeyini ölçümle seç.

2. 2

   Çıkarım sunucusunu kur

   Sürekli toplu işlem ve verimli KV önbellek yönetimi sunan bir inference server ayağa kaldır.

3. 3

   Container ve altyapı-kod ile paketle

   Kurulumu tekrarlanabilir kılmak için container ve IaC kullan.

4. 4

   Orkestrasyon ve ölçeklemeyi ekle

   Kopyalar, yük dengeleme ve otomatik ölçekleme ile dayanıklılık kur.

5. 5

   API ağ geçidi ve erişim kontrolü koy

   Kimlik doğrulama, oran sınırlama ve kota ile güvenli erişim sağla.

6. 6

   Gözlemlenebilirliği kur

   Gecikme, verim, hata oranı ve GPU kullanımını sürekli izle.

7. 7

   Yük testi yap ve boyutlandır

   Gerçek iş yüküyle verim ve gecikmeyi ölçüp donanımı doğrula.

8. 8

   Yükseltme ve yedekleme prosedürü yaz

   Model/sürücü güncellemeleri ve arıza kurtarma için net bir işletme rehberi hazırla.

On-prem LLM kurulumunun maliyet hesabı, tek bir sayıya değil üç kaleme dayanır: CAPEX, OPEX ve bunları birleştiren toplam sahip olma maliyeti (TCO). En yaygın hata, maliyeti yalnızca GPU fiyatına indirgemektir; oysa GPU, toplam sahip olma maliyetinin çoğu zaman yarısından azını oluşturur. Doğru bir hesap, tüm gizli kalemleri görünür kılar ve kararı sağlam bir zemine oturtur.

CAPEX: Sermaye Harcaması

CAPEX, bir kereye mahsus yatırımlardır: GPU sunucuları (GPU'lar, anakart, CPU, RAM), depolama, ağ ekipmanı, rack ve kurulum. Bu kalemin en büyük bileşeni GPU'lardır ve model boyutu ile kuantizasyon düzeyi bu maliyeti doğrudan belirler. CAPEX'i değerlendirirken donanımın faydalı ömrünü (tipik olarak birkaç yıl) ve teknoloji eskimesi riskini de hesaba katmak gerekir; hızla gelişen bu alanda bugün alınan bir GPU, birkaç yıl içinde görece geride kalabilir.

OPEX: İşletme Harcaması

OPEX, sistemi çalışır tutmanın sürekli maliyetidir ve çoğu kurumda hafife alınır. Başlıca kalemler: elektrik (GPU'lar önemli güç çeker), soğutma, veri merkezi veya kolokasyon alanı, bakım ve destek sözleşmeleri, ve en kritik olanı insan gücü. On-prem bir yığını kuran, izleyen, güncelleyen, güvenliğini sağlayan ve arıza durumunda müdahale eden uzman ekip, çoğu zaman OPEX'in en büyük ve en çok atlanan kalemidir. Bu insan maliyeti hesaba katılmadan yapılan bir on-prem TCO'su gerçekçi değildir.

Elektrik kalemi özellikle Türkiye gibi enerji maliyetlerinin dalgalanabildiği bağlamlarda dikkatle modellenmelidir. Bir GPU sunucusu yalnızca GPU'ların çektiği gücü değil, onları soğutan sistemin gücünü de tüketir; veri merkezlerinde bu ek, tüketilen her birim enerjiye bir soğutma katsayısı olarak eklenir. Yüksek doluluk oranıyla 7/24 çalışan bir sunucunun yıllık elektrik maliyeti, donanımın CAPEX'inin göz ardı edilemez bir oranına ulaşabilir. Bu yüzden OPEX hesabında elektriği "küçük bir kalem" olarak görmemek; güç çekişini, çalışma saatlerini ve soğutma yükünü birlikte modellemek gerekir. Bu kalem, on-prem ile API arasındaki başabaş noktasını doğrudan etkileyen değişkenlerden biridir.

TCO: Toplam Sahip Olma Maliyeti

Toplam sahip olma maliyeti, CAPEX'i faydalı ömre yayıp OPEX'i ekleyerek elde edilen ve tipik olarak üç yıllık bir ufukta bakılan toplam maliyettir. TCO'yu birim maliyete (örneğin milyon token başına maliyet) çevirmek, on-prem ile API'yi adil biçimde karşılaştırmanın tek yoludur. Bu çeviride belirleyici değişken kullanım oranıdır: aynı donanımın TCO'su sabittir, ama bu maliyeti kaç token'a böldüğünüz kullanım oranına bağlıdır. GPU'lar günün büyük kısmında boşta duruyorsa birim maliyet fırlar; yüksek doluluk oranında ise düşer. Kurumsal yapay zeka bütçesini planlarken bu TCO mantığını kurumsal AI bütçesi planlama ve genel getiri çerçevesini yapay zeka ROI nasıl hesaplanır yazılarıyla birlikte ele almak faydalı olur.

On-prem ile API arasındaki seçim, en çok yanlış çerçevelenen kurumsal kararlardan biridir. Doğru çerçeve "hangisi ucuz" değil, "hangi kullanım profili ve hangi kısıtlar altında hangisi doğru" sorusudur. İki modelin ekonomisi köklü biçimde farklıdır: API bir OPEX modelidir (kullandıkça öde, sıfır ön yatırım), on-prem ise büyük bir CAPEX ve sürekli OPEX modelidir (yüksek ön yatırım, sonra sabit işletme).

Bu farkın pratik sonucu bir başabaş (break-even) mantığıdır. Düşük veya değişken hacimde API neredeyse her zaman daha ucuzdur, çünkü boşta duran donanım maliyeti taşımazsınız ve yalnızca kullandığınız kadar ödersiniz. Kullanım hacmi arttıkça API'nin toplam maliyeti doğrusal büyürken, on-prem'in maliyeti büyük ölçüde sabit kalır; belli bir eşiğin üzerinde on-prem'in birim maliyeti API'nin altına iner. Ama bu eşik kuruma özgüdür ve elektrik, insan gücü ve kullanım oranı gibi değişkenlere çok duyarlıdır; genel bir "şu token'dan sonra on-prem ucuzdur" rakamı vermek yanıltıcı olur. Bunu kendi rakamlarınızla modellemelisiniz.

On-prem ve API karşılaştırması: toplam sahip olma maliyeti ve ötesi

Boyut	On-prem (self-hosted)	API (yönetilen)
Maliyet modeli	Yüksek CAPEX + sabit OPEX	Kullandıkça öde (OPEX)
Düşük/değişken hacim	Birim maliyet yüksek (boşta GPU)	Genellikle daha ucuz
Yüksek/sürekli hacim	Eşik üstünde avantajlı	Toplam maliyet doğrusal büyür
Veri egemenliği / KVKK	Veri kurum içinde kalır	Veri sağlayıcıya gider
İşletme yükü	Kurumda (yüksek)	Sağlayıcıda (düşük)
En yeni modellere erişim	Gecikmeli, kurulum gerekir	Hızlı, hazır sunulur
Gecikme öngörülebilirliği	Yüksek (kendi kontrolünüz)	Sağlayıcı yüküne bağlı

Bunu somutlaştırmak için tümüyle illüstratif ve varsayımsal bir başabaş örneği düşünelim (kendi rakamlarınızla hesaplayın). Diyelim bir on-prem sunucunun üç yıllık TCO'su sabit bir X tutarıdır (üç yıla yayılan CAPEX artı elektrik, kolokasyon ve bir mühendisin zamanının bir kısmı için OPEX). Bu sunucu, iyi ayarlanmış halde ve yüksek doluluk oranıyla ayda N milyon token sunuyorsa, on-prem birim maliyeti X'in üç yıllık toplam token'a bölümüdür. Aynı N milyon token'ı API'nin milyon token başına ücretiyle fiyatlandırıp karşılaştırın. Düşük N'de API toplamı küçüktür ve on-prem'i yener; N büyüdükçe API toplamı doğrusal artarken X sabit kalır ve belli bir N'den sonra on-prem birim maliyeti API'nin altına iner. Kesin geçiş noktası tümüyle sizin kullanım oranınıza, elektrik tarifenize ve insan maliyetinize bağlıdır; bu yüzden ödünç alınmış bir kural değil, kendi sayılarınızla modellenmiş bir hesap gerekir. Ders sayısal değil yapısaldır: on-prem yüksek ve sürekli kullanımı ödüllendirir, boşta kapasiteyi cezalandırır.

Tablonun gösterdiği kilit nokta şudur: maliyet çoğu zaman tek kriter değildir. Veri egemenliği ve KVKK gereksinimi bir kurumu, saf ekonomiden bağımsız olarak on-prem'e zorlayabilir; tersine, küçük bir ekibin sınırlı işletme kapasitesi, ekonomik olarak cazip görünse bile on-prem'i pratikte sürdürülemez kılabilir. Bu yüzden karar, tek boyutlu bir maliyet karşılaştırması değil, maliyet + uyum + kapasite + esneklik boyutlarını birlikte tartan bir çerçevedir. Bu çerçeveyi kurumsal stratejiye oturtmak için kurumsal yapay zeka stratejisi nasıl oluşturulur yazısı yol gösterir.

Bir self-hosted LLM'i tek kullanıcıyla bir sunucuda çalıştırmak kolaydır; onu yüzlerce eşzamanlı kullanıcıya, öngörülebilir gecikmeyle ve makul maliyetle sunmak bambaşka bir mühendislik problemidir. Ölçekleme, self-hosted altyapının demoyu üretime taşıyan boyutudur ve üç eksende yönetilir: verim, gecikme ve dayanıklılık.

Verim ekseninde asıl kaldıraç, çıkarım sunucusunun toplu işlem (batching) verimidir. Sürekli toplu işlem sayesinde tek bir GPU çok sayıda eşzamanlı isteği işleyebilir; doğru ayarlanmış bir yığın, aynı donanımdan kat kat daha yüksek toplam verim çıkarır. Verim yeterli değilse iki seçenek vardır: dikey ölçekleme (daha güçlü GPU veya aynı sunucuya daha çok GPU) veya yatay ölçekleme (daha çok kopya ve yük dengeleme). Yüksek eşzamanlılık için yatay ölçekleme genellikle daha esnektir.

Gecikme ekseninde, bir self-hosted yığında kullanıcının algıladığı bekleme süresi birkaç adımın toplamıdır: kuyruk süresi, ilk token'a kadar geçen süre ve token üretim hızı. Yanıtı akış (streaming) halinde vermek algılanan gecikmeyi belirgin biçimde düşürür; ayrıca sık sorulan istekler için önbellekleme ve iş yüküne göre model yönlendirme (basit istekleri küçük modele, karmaşıkları büyük modele) hem gecikmeyi hem maliyeti optimize eder. Dayanıklılık ekseninde ise kopya yedekliliği, sağlık kontrolleri, otomatik yeniden başlatma ve arıza devri, self-hosted altyapının üretim güvenilirliğini sağlar.

Ölçeklemede sık gözden kaçan bir konu, talep dalgalanmasıdır. Kurumsal bir asistanın yükü gün içinde ve haftalar boyunca dalgalanır; mesai saatlerinde zirve yaparken gece neredeyse sıfıra iner. Sabit bir on-prem kapasite, zirveyi karşılamak için boyutlandırıldığında düşük yük saatlerinde boşta durur ve birim maliyeti yükseltir. Bu gerilimi yönetmenin yolları vardır: düşük yük saatlerinde GPU'ları toplu (batch) işlere ayırmak, hibrit bir modelle zirve taşmasını API'ye yönlendirmek (burst) veya kopya sayısını talebe göre otomatik ayarlamak. Self-hosted bir altyapıyı verimli kılan, yalnızca zirve kapasitesini değil, ortalama doluluk oranını da yüksek tutan bu tür kararlardır; çünkü on-prem ekonomisi, boşta kalan her GPU-saatiyle zayıflar.

On-prem LLM kurulumu, veriyi kurum içinde tutarak bazı güvenlik risklerini azaltır; ama yeni sorumluluklar da getirir. Verinin dışarı çıkmaması güçlü bir avantajdır, fakat modelin, altyapının ve erişimin güvenliği artık tümüyle kurumun sorumluluğundadır. Güvenlik, sonradan eklenen bir katman değil, tasarımın parçası olmalıdır.

Birinci sütun erişim kontrolüdür. Kimin hangi modele, hangi veriyle ve hangi kotayla eriştiği net biçimde tanımlanmalı; API ağ geçidi kimlik doğrulama, oran sınırlama ve loglama sağlamalıdır. İkinci sütun ağ yalıtımıdır: on-prem yığının hangi ağ segmentinde durduğu, dışarıya hangi kapıların açık olduğu ve iç trafiğin nasıl şifrelendiği tasarlanmalıdır. Üçüncü sütun istem/yanıt güvenliğidir; dil modeli tabanlı sistemler, kötü niyetli girdilere karşı korunmalıdır. Saldırı yüzeyini anlamak için prompt injection nedir ve koruma katmanları için guardrail nedir yazıları yol gösterir.

Loglama, güvenliğin hem dostu hem de gizli bir riskidir. Denetlenebilirlik ve hata ayıklama için istem ve yanıtları loglamak değerlidir; ama bu loglar kişisel veya gizli veri içerebileceği için, logların kendisi de bir veri işleme faaliyetidir ve KVKK kapsamında değerlendirilmelidir. Doğru yaklaşım, ne loglanacağını bilinçli seçmek, hassas alanları maskelemek, loglara erişimi kısıtlamak ve saklama sürelerini tanımlamaktır. On-prem senaryoda logların da kurum içinde kalması bir avantajdır; ama "her şeyi sonsuza kadar logla" refleksi, on-prem'in sağladığı gizlilik avantajını sessizce eritebilir. Loglamanın uyum boyutunu ayrı bir rehberde ele alıyoruz; buradaki ilke, güvenliğin bir denge işi olduğudur: yeterince izlemek ama gereğinden fazla veri biriktirmemek.

Uyum tarafında, on-prem uyumu kolaylaştırır ama tek başına sağlamaz. KVKK açısından veri işleme envanteri, hukuki dayanak, aydınlatma, saklama süreleri ve gerektiğinde anonimleştirme/maskeleme hâlâ tasarlanmalıdır; verinin kurum içinde olması bu yükümlülükleri ortadan kaldırmaz, yalnızca yurt dışına aktarım gibi bazı başlıkları sadeleştirir. Yönetişim çerçevesi için ISO/IEC 42001 (yapay zeka yönetim sistemi) gibi standartlar referans alınabilir. Bu bölüm bilgilendirme amaçlıdır; hukuki tavsiye değildir.

On-prem LLM kurulumunun Türkiye'deki önemi, yapay zeka kullanımının ülkedeki olağanüstü hızıyla birlikte artıyor. We Are Social "Digital 2026" verilerine göre Türkiye, ChatGPT trafiğinde yüzde 94,49'luk oranla dünya birincisi konumundadır (Euronews Türkçe, Ocak 2026). Bu tablo iki şeyi birden gösterir: bir yandan Türk kullanıcıların ve kurumların üretken yapay zekayı benimseme iştahı çok yüksektir, diğer yandan bu yoğun kullanım, kişisel ve kurumsal verinin nereye gittiği sorusunu her zamankinden kritik hale getirir. İşte on-prem LLM kurulumu tam bu kesişimde anlam kazanır: yüksek benimseme ile yüksek veri hassasiyetinin buluştuğu yerde, veriyi kurum sınırında tutan bir çözüm arayışı doğaldır.

Türkiye'de faaliyet gösteren kurumlar için düzenleyici çerçevenin merkezinde KVKK bulunur; kişisel verinin işlenmesi, aktarımı ve saklanması bu kapsamda denetlenir. Bir dil modeline gönderilen istem, çoğu zaman içinde müşteri adı, çalışan bilgisi, sözleşme detayı veya sağlık verisi taşıyabilir; bu veriyi üçüncü taraf bir buluta göndermek, KVKK açısından aktarım, işleyen sıfatı ve alt-işleyen zinciri gibi başlıkları gündeme getirir. On-prem LLM kurulumu, veriyi hiç dışarı çıkarmayarak bu karmaşıklığın önemli bir bölümünü sadeleştirir. KVKK'nın temel kavramları için KVKK nedir ve kişisel verinin tanımı için kişisel veri nedir yazıları yol gösterir.

Ancak Türkiye bağlamında on-prem'i yalnızca bir uyum aracı olarak görmek eksik olur; aynı zamanda bir yetkinlik ve egemenlik yatırımıdır. Kendi altyapısında dil modeli çalıştırabilen bir kurum, dış sağlayıcıların fiyat, erişim ve model kullanımdan kaldırma kararlarına daha az bağımlı olur; Türkçe verisiyle modeli kendi ihtiyacına uyarlama esnekliği kazanır. Bu, özellikle kamu, finans, sağlık ve savunma gibi veri egemenliğinin stratejik olduğu sektörlerde belirleyicidir. Yine de karar duygusal değil ölçülü verilmelidir: her kurumun her iş yükü on-prem gerektirmez, ama hassas veriyle çalışan iş yükleri için on-prem, Türkiye'nin bu hızlı benimseme ortamında giderek daha çok gündeme gelen bir seçenektir. Bu bölüm bilgilendirme amaçlıdır ve hukuki tavsiye değildir.

On-prem kararının en çok hafife alınan boyutu işletme yüküdür. Bir self-hosted LLM'i kurmak bir defalık bir iştir; onu aylar ve yıllar boyunca güvenilir, güvenli ve güncel tutmak süreklidir. Bu görünmez emek, on-prem TCO'sunun en büyük ve en çok atlanan kalemidir ve genellikle donanımdan çok daha belirleyicidir.

İşletme yükünün başlıca kalemleri şunlardır: sürücü ve kütüphane uyumluluğunun (örneğin GPU sürücüsü ve hesaplama kütüphaneleri) yönetimi, model ve çıkarım sunucusu güncellemeleri, güvenlik yamaları, kapasite ve maliyet izleme, donanım arızalarına müdahale ve olası kesintiler için nöbet. Bunlar sürekli dikkat ve uzmanlık gerektirir; ve küçük bir ekipte, asıl işten çalınan bu zaman çoğu zaman fark edilmez ama toplamda büyüktür.

Pratik sonuç şudur: on-prem'e geçmeden önce, bu yığını kim işletecek sorusuna net bir yanıtınız olmalı. Ekip kapasitesi sınırlıysa üç seçenek vardır: kapsamı dar tutmak (tek model, tek kuantizasyon, tekrarlanabilir kurulum), işletmeyi bir iş ortağına devretmek (yönetilen on-prem/kolokasyon) veya hibrit bir modele geçmek. İç ekip mi danışmanlık mı sorusunu tartarken, işletme sürekliliğini kararın merkezine koymak gerekir; bu tartışma için AI danışmanlığı mı iç ekip mi yazısı faydalı bir çerçeve sunar.

İşletme yükünün bir başka boyutu, model ve ekosistemin hızlı değişmesidir. Açık model dünyası aylar içinde yenilenir: daha iyi modeller çıkar, çıkarım sunucuları yeni özellikler kazanır, kuantizasyon yöntemleri gelişir. On-prem bir kurulumu güncel tutmak, bu değişimi izleyip düzenli olarak değerlendirme yapmayı gerektirir; aksi halde birkaç ay içinde, aynı donanımdan çok daha iyi sonuç alabilecekken eski bir kurulumla çalışmaya devam edersiniz. Bu, işletmenin yalnızca "çalışır tutmak" değil, aynı zamanda "rekabetçi tutmak" boyutudur ve genellikle bir MLOps / LLMOps disiplininin parçası olarak sürdürülür. Bu güncelleme disiplinini kurmayan ekipler, on-prem'in ilk gününde aldıkları değeri zamanla kaybeder.

Aşağıdaki kontrol listesi, on-prem LLM kurulumunu bir fikirden üretim kalitesine taşımak için pratik bir yol haritasıdır. Her adımı bilinçle geçmek, sonraki adımların sağlam bir zemine oturmasını sağlar; bir adımı atlamak, sorunu zincirin ilerisine erteler.

Nasıl Yapılır

On-prem LLM kurulumu kontrol listesi

Bir on-prem LLM kurulumunu pilottan üretime taşımak için adım adım kontrol listesi.

1. 1

   Kullanım senaryosunu ve gereksinimi netleştir

   Hangi görev, hangi kalite eşiği, hangi veri hassasiyeti ve hangi hacim? On-prem gerçekten gerekli mi?

2. 2

   Modeli ve kalite eşiğini belirle

   Görevi çözecek en küçük modeli göreve özel bir değerlendirme kümesiyle seç.

3. 3

   Kuantizasyon düzeyini ölçerek seç

   Bellek tasarrufu ile kalite arasındaki doğru noktayı kendi görevinde test et.

4. 4

   Donanımı boyutlandır

   VRAM (ağırlık + KV önbelleği), sistem RAM'i, NVMe, ağ, güç ve soğutmayı emniyet payıyla planla.

5. 5

   Sunum yığınını kur

   Çıkarım sunucusu, orkestrasyon, API ağ geçidi ve gözlemlenebilirliği ayağa kaldır.

6. 6

   Güvenlik ve erişim kontrolünü tasarla

   Kimlik doğrulama, ağ yalıtımı, loglama ve istem/yanıt korumasını baştan ekle.

7. 7

   Yük testiyle verim ve gecikmeyi ölç

   Gerçek iş yükünle token/saniye, gecikme ve eşzamanlılık sınırını doğrula.

8. 8

   TCO'yu modelle ve API ile karşılaştır

   CAPEX + OPEX'i üç yıla yayıp birim maliyeti hesapla; kararı sayılarla ver.

9. 9

   İşletme prosedürlerini yaz

   Yükseltme, yedekleme, izleme ve arıza kurtarma rehberini hazırla.

10. 10

    Dar pilotla başla, ölçerek büyüt

    Tüm kurumu değil, dar ve yüksek değerli bir senaryoyu üretime al ve genişlet.

Bu listeyi dar bir pilotta uygulamak, tüm kurumu bir anda dönüştürmeye çalışmaktan çok daha akıllıcadır. Küçük ama ölçülen bir on-prem LLM kurulumu, hem gerçek maliyeti ve verimi görünür kılar hem de ileride ölçekleme için sağlam bir temel bırakır. Kurumunuza özel bir mimariyi uçtan uca kurmak için yapay zeka danışmanlığı ile başlayabilir, ekibinizin yetkinliğini büyütmek için kurumsal eğitim seçeneklerine bakabilir ve kavramları derinleştirmek için öğrenme merkezini kullanabilirsiniz.

On-prem LLM kurulumu her kurum için doğru karar değildir; doğru olduğu senaryolar bellidir ve bu senaryoların dışında API veya hibrit daha akılcıdır. Kararı ideolojiyle değil, dört soruyla vermek gerekir: veri ne kadar hassas, hacim ne kadar yüksek ve öngörülebilir, ekip kapasitesi ne kadar ve iş yükü ne kadar kararlı?

On-prem en güçlü olduğu yer, veri hassasiyetinin API'yi dışladığı senaryolardır: kişisel veri, sağlık, hukuk, savunma veya sıkı düzenlemeye tabi sektörler. Burada veri egemenliği çoğu zaman maliyetten önce gelir ve on-prem bir tercih değil bir gerekliliktir. İkinci güçlü senaryo, yüksek ve sürekli hacimdir: GPU'lar yüksek doluluk oranıyla çalışacaksa, sabit TCO belli bir eşiğin üstünde API'ye göre avantajlı olur. Üçüncü senaryo, öngörülebilir ve kararlı bir iş yüküyle güçlü bir işletme kapasitesinin bir araya geldiği durumdur.

Tersine, on-prem'in zayıf olduğu senaryolar da nettir: düşük veya değişken hacim (boşta GPU maliyeti), sık değişen iş yükü (bugün bir model, yarın başka), küçük ve kapasitesi sınırlı ekip, ve en yeni-en büyük modellere hızlı erişim ihtiyacı. Bu durumlarda API ile başlamak, gerçek ihtiyacı ölçmek ve ancak veri egemenliği veya ölçek ekonomisi net biçimde gerektirdiğinde on-prem'e geçmek en akılcı yoldur.

Bu çerçeveyi kullanırken unutulmaması gereken şudur: karar ikili ve nihai değildir. Çoğu olgun kurum, zaman içinde bir yelpaze üzerinde hareket eder — API ile başlar, hacim ve hassasiyet arttıkça belirli iş yüklerini hibrit veya on-prem'e taşır ve teknoloji değiştikçe dengeyi yeniden gözden geçirir. On-prem LLM kurulumu bir kez verilip unutulacak bir karar değil, kurumun verisi, hacmi ve yetkinliği büyüdükçe periyodik olarak yeniden değerlendirilecek yaşayan bir tercihtir.

On-prem, hibrit ve API için karar çerçevesi

Durum	Önerilen yön	Neden
Yüksek veri hassasiyeti (KVKK)	On-prem veya özel bulut	Veri egemenliği zorunluluğu
Yüksek, sürekli hacim	On-prem (yüksek doluluk)	Sabit TCO eşik üstünde avantajlı
Düşük/değişken hacim	API	Boşta donanım maliyeti taşımaz
Karışık: bir kısmı hassas	Hibrit	Hassas iş yükü on-prem, gerisi API
Küçük ekip, sınırlı kapasite	API veya yönetilen	İşletme yükü sürdürülemez
En yeni modele hızlı ihtiyaç	API	Sağlayıcı çok daha hızlı sunar

Deneyimli bir gözle bakıldığında, başarısız olan on-prem LLM kurulumu projeleri benzer hatalarla kırılır. Bu hataların çoğu, kararı tek bir boyuta (genellikle donanım fiyatına veya model boyutuna) indirgemekten ve sistemin diğer katmanlarını ihmal etmekten kaynaklanır. En yaygınları şunlardır:

• Sadece GPU fiyatına bakıp TCO'yu ihmal etmek: Elektrik, soğutma, veri merkezi ve özellikle işletme insan gücü hesaba katılmadığında on-prem yanıltıcı biçimde ucuz görünür; gerçek maliyet üretimde ortaya çıkar.
• İhtiyaçtan büyük model seçmek: Her ek parametre kademesi daha çok VRAM, daha çok GPU ve daha yüksek maliyet demektir. Görevi çözen en küçük modeli ölçmeden büyük modele atlamak israftır.
• VRAM'i yalnızca ağırlıklara göre boyutlandırmak: Bağlam ve eşzamanlılık için KV önbelleğini unutmak, üretimde bellek taşmalarına ve beklenmedik yavaşlamalara yol açar; her zaman emniyet payı bırakın.
• Kuantizasyonu ölçmeden uygulamak (ya da hiç kullanmamak): Kuantizasyonu körlemesine agresif seçmek kaliteyi düşürür; hiç kullanmamak ise gereksiz donanım maliyeti getirir. Doğru düzey, göreve özel ölçümle bulunur.
• Çıkarım sunucusunu naif kurmak: Sürekli toplu işlem ve verimli bellek yönetimi olmadan, güçlü bir GPU bile verimsiz kalır; token başına maliyet gereksiz yükselir.
• İşletme yükünü hafife almak: Kim yükseltecek, kim izleyecek, arızada kim müdahale edecek sorularına net yanıt olmadan başlayan on-prem, zamanla ekibi tüketir.
• Güvenliği sona bırakmak: Erişim kontrolü, ağ yalıtımı ve istem güvenliği sonradan eklendiğinde hem zor hem eksik olur; baştan tasarlanmalıdır.
• Ölçmeden büyük yatırım yapmak: Gerçek iş yüküyle verim ve gecikmeyi ölçmeden büyük donanım almak, en pahalı hatadır; önce dar pilot, sonra ölçekli yatırım.

On-prem LLM kurulumu tek başına bir "ham motor" sağlar; o motoru kurumsal olarak değerli kılan, çoğu zaman üzerine eklenen iki katmandır: RAG ve fine-tuning. Bu üçünü doğru konumlandırmak, on-prem yatırımından alınan değeri belirgin biçimde artırır. Basit bir ayrım işe yarar: on-prem model motoru sağlar, RAG bilgiyi getirir, fine-tuning davranışı biçimlendirir.

RAG (getirmeyle zenginleştirilmiş üretim), on-prem modeli kurumun güncel ve özel bilgisiyle besler. Modelin ağırlıklarına gömülü olmayan — sürekli değişen politikalar, belgeler, ürün bilgileri — her şey, RAG ile çıkarım anında modele bağlam olarak verilir. On-prem senaryoda bu özellikle güçlüdür, çünkü hem model hem bilgi tabanı kurum sınırında kalır; hassas belgeler hiç dışarı çıkmadan modele zemin oluşturur. RAG'in ne olduğu ve nasıl kurulduğu için RAG nedir ve uçtan uca RAG mimarisi nasıl kurulur yazılarına bakabilirsiniz; bir on-prem model, bu mimarinin üretim (generation) katmanını kurum içinde çalıştırmanın doğal yoludur.

Fine-tuning ise modelin davranışını, tonunu ve çıktı biçimini kalıcı olarak uyarlar. On-prem senaryoda hafif ayar teknikleri (örneğin düşük-ranklı uyarlama), tam modeli yeniden eğitmeden, görece mütevazı donanımla modeli kurumun diline ve formatına yaklaştırabilir. Ama önemli bir kural vardır: bilgi problemini fine-tuning ile çözmeye çalışmak pahalı ve kırılgandır; bilgi değiştikçe yeniden eğitim gerekir. Bu yüzden pratik sıra şudur: önce RAG ile bilgiyi doğru getirin, biçim ve ton hâlâ sorunsa fine-tuning ekleyin. Fine-tuning'in ne olduğu için fine-tuning nedir ve hafif uyarlama için LoRA nedir yazıları yol gösterir. Çoğu olgun kurumsal sistemde bu üçü birlikte çalışır: on-prem motor veri egemenliğini, RAG güncelliği ve doğrulanabilirliği, hafif fine-tuning ise tutarlı biçimi sağlar.

On-prem bir yığının performansını "hızlı görünüyor" gibi öznel izlenimlerle değil, birkaç net metrikle ölçmek gerekir. Bu metrikler hem donanımı doğru boyutlandırmayı hem de maliyeti gerçekçi hesaplamayı mümkün kılar. Aşağıdaki değerler ve yaklaşımlar illüstratiftir; kesin sayıları kendi modeliniz, donanımınız ve iş yükünüzle ölçmelisiniz.

Başlıca performans metrikleri şunlardır: verim (throughput — saniyede üretilen toplam token, eşzamanlılık altında), ilk token'a kadar geçen süre (kullanıcının ilk yanıtı algılama hızı), token üretim hızı (token/saniye, akış deneyimini belirler), eşzamanlılık sınırı (kaç eşzamanlı isteği hedef gecikmede karşılayabildiğiniz) ve GPU kullanım oranı (donanımın ne kadar verimli kullanıldığı). Bu metrikler birlikte okunur: yüksek verim ama kötü gecikme, ya da düşük GPU kullanımı, ayarların veya boyutlandırmanın gözden geçirilmesi gerektiğini gösterir.

Ölçüm disiplini şöyle işler: gerçekçi bir iş yükü profili hazırlayın (tipik istem uzunlukları, yanıt uzunlukları ve eşzamanlılık deseni), bu profille yük testi yapın ve metrikleri farklı ayarlar (toplu işlem boyutu, kuantizasyon düzeyi, kopya sayısı) altında karşılaştırın. Bir maliyet metriği olarak, ölçülen verimi TCO'ya bölerek birim maliyeti (örneğin milyon token başına maliyet) hesaplayın; API'nin ilan edilen birim maliyetiyle karşılaştırmanın tek adil yolu budur. Performans ölçümünü, dil modeli kalitesini ölçen değerlendirmeyle karıştırmayın; ikisi farklı disiplinlerdir ve kalite tarafı için LLM değerlendirme nedir yazısına bakabilirsiniz.

Ölçümü sentetik değil gerçekçi tutmak kritiktir. Yapay bir "en iyi durum" testi (kısa istemler, tek istek) size donanımın teorik tavanını gösterir ama üretimdeki deneyimi yansıtmaz. Gerçek kullanıcılar uzun istemler yazar, eşzamanlı gelir ve değişken yanıt uzunlukları ister; bu koşullar altında verim ve gecikme, sentetik testtekinden belirgin biçimde farklı olabilir. Bu yüzden yük testini mümkün olduğunca gerçek trafik desenine yaklaştırmak gerekir. İyi bir uygulama, pilot dönemde gerçek kullanım loglarından bir profil çıkarmak ve donanım kararını bu profil üzerinde ölçülen sayılara dayandırmaktır; ilan edilen "laboratuvar" rakamlarına değil, kendi iş yükünüzdeki gerçek performansa güvenin.

Özetle, on-prem LLM kurulumu nasıl yapılır sorusunun cevabı dört katmanı birlikte doğru kurmaktır. Önce donanım gereksinimleri model boyutuna göre boyutlandırılır; en kısıtlayıcı kaynak GPU belleğidir (VRAM) ve doğru sıra "önce modeli seç, sonra donanımı ona göre boyutlandır"dır. Sonra kuantizasyon ile aynı GPU'da daha büyük model çalıştırılır ve donanım maliyeti düşürülür; düzey, göreve özel ölçümle seçilir. Ardından bir sunum yığını (çıkarım sunucusu, orkestrasyon, gözlemlenebilirlik, güvenlik) kurulur ve ham GPU güvenilir bir servise dönüştürülür. En sonda karar, GPU fiyatıyla değil CAPEX, OPEX ve toplam sahip olma maliyeti üzerinden on-prem ile API karşılaştırılarak verilir.

En önemli mesaj şudur: on-prem LLM kurulumu bir tek satın alma değil, bir sistem tasarımı ve işletme taahhüdüdür. On-prem'in asıl gerekçesi çoğu zaman saf maliyet değil, veri egemenliği ve KVKK uyumudur; ve on-prem ancak yeterli, sürekli kullanımda ve güçlü bir işletme kapasitesiyle sürdürülebilir. Doğru yol, büyük yatırımdan önce dar bir pilotu kendi iş yükünüzle ölçmek ve kararı sayılarla vermektir. Temel kavramlar için LLM nedir, GPU nedir ve açık kaynak LLM nedir yazılarına; kurumunuza özel bir on-prem mimarisini kurmak için yapay zeka danışmanlığı hizmetine, ekip yetkinliği için kurumsal eğitim seçeneklerine ve derinleşmek için öğrenme merkezine bakabilirsiniz. On-prem ile API arasındaki kararı bir RAG veya ajan sistemiyle birleştirecekseniz, RAG mimarisi nasıl kurulur yazısı tamamlayıcı bir çerçeve sunar.