On-Premise LLM Kurulumu: Donanım Boyutlandırma Rehberi

On-premise LLM kurulumunda llm donanım gereksinimi üç değişkenle belirlenir: çalıştıracağınız modelin boyutu (parametre sayısı), uyguladığınız kuantizasyon düzeyi ve aynı anda hizmet vereceğiniz eşzamanlı kullanıcı sayısı. Bu üç girdi, ihtiyacınız olan GPU belleğini (VRAM), GPU sayısını ve nihai sunucu boyutlandırma kararını doğrudan şekillendirir.

Bu rehber, on-prem LLM konusunun dar ve teknik bir kesitine — donanım boyutlandırmaya — odaklanır. Kurulumun uçtan uca mimarisini, ağ, depolama, güvenlik ve işletim tarafını ele alan kapsamlı rehber ayrı bir yazıdır; burada amacımız, bir model seçtiğinizde "kaç GPU, ne kadar VRAM, hangi sunucu" sorularını kaba ama güvenilir bir yaklaşık hesapla yanıtlayabilmenizdir. Temel kavramlar için LLM nedir ve GPU nedir yazıları iyi bir başlangıçtır. Buradaki tüm sayısal örnekler illustratiftir; kesin değerler modele, çalışma zamanına ve donanıma göre değişir.

Tanım

LLM donanım gereksinimi

Bir dil modelini yerel (on-premise) altyapıda çalıştırmak için gereken GPU belleğinin (VRAM), GPU sayısının ve sunucu kapasitesinin; modelin boyutu, kuantizasyon düzeyi ve eşzamanlı kullanıcı yüküne göre hesaplanmasıdır. Temel formül: gereken VRAM ≈ ağırlık belleği + KV cache + işletim payı.

Ayrıca: LLM donanım boyutlandırma, on-prem LLM donanımı, GPU boyutlandırma, VRAM hesabı

Donanım boyutlandırma tek bir sayıya değil, birbiriyle çarpışan üç değişkene bağlıdır. Bunları ayrı ayrı anlamak, llm donanım gereksinimini bir tahminden çıkarıp yaklaşık bir hesaba dönüştürür. Aşağıdaki tablo, her girdinin donanıma etkisini ve nasıl hesaba katıldığını özetler; boyutlandırmaya buradan başlamak en sağlıklısıdır.

Boyutlandırma girdisi, donanıma etkisi ve hesap yaklaşımı

Girdi	Donanıma etkisi	Hesap yaklaşımı
Model boyutu (parametre)	Ağırlıkların kapladığı taban VRAM	parametre sayısı × parametre başına bayt
Kuantizasyon düzeyi	Parametre başına baytı düşürür	FP16≈2, INT8≈1, INT4≈0,5 bayt
Eşzamanlı kullanıcı	KV cache ve verim yükünü artırır	kullanıcı sayısı × bağlam × katman maliyeti
Bağlam uzunluğu	KV cache'i doğrusal büyütür	token sayısıyla orantılı artış
İşletim payı	Aktivasyon ve parçalanma tamponu	toplamın yaklaşık %15-25'i

Tablodaki mantık nettir: ilk iki satır ağırlıkların ne kadar yer kaplayacağını, sonraki ikisi çalışma sırasında ne kadar ek bellek isteneceğini, sonuncusu ise güvenli bir tampon payını belirler. Bu beş kalemin toplamı, aradığınız gpu bellek hesabının çekirdeğidir.

Boyutlandırmanın başlangıç noktası, ağırlıkların belleğidir. Buradaki model boyutu vram ilişkisi doğrusaldır: bir modelin ağırlıkları için gereken bellek, parametre sayısını parametre başına bayt ile çarparak bulunur. FP16 (16 bit) gösterimde her parametre 2 bayt tutar; yani her milyar parametre yaklaşık 2 GB yer kaplar. Buna göre 7 milyar parametreli bir model FP16'da yaklaşık 14 GB, 70 milyar parametreli bir model ise yaklaşık 140 GB ağırlık belleği ister (illustratif değerler).

Bu taban rakam neden önemlidir? Çünkü model boyutu vram ihtiyacının en büyük ve en öngörülebilir bileşenidir; geri kalan her şey bunun üzerine eklenir. Tek bir modern veri merkezi GPU'su genellikle 24-80 GB arası VRAM taşır. Dolayısıyla 7-8 milyar parametreli bir model tek karta rahat sığarken, 70 milyar parametreli bir model kuantize edilmeden tek karta sığmaz. Modelin metni nasıl parçalara ayırdığını anlamak için token nedir yazısına bakabilirsiniz; parametre sayısıyla token işleme kapasitesi farklı şeylerdir.

Burada iki uyarı önemlidir. Birincisi, çıkarım (inference) ile eğitim (training) bambaşka bütçelerdir: eğitimde ağırlıkların yanında gradyanlar ve optimizer durumları da tutulduğu için bellek ihtiyacı çıkarımın birkaç katına çıkar; bu yazıdaki hesaplar üretimde model çalıştırma, yani çıkarım içindir. İkincisi, VRAM tek darboğaz değildir: modeli diskten belleğe yüklemek için ağırlık boyutunun en az bir katı kadar hızlı depolama ve rahat bir sistem belleği (RAM) gerekir. Boyutlandırmayı yalnızca GPU'nun VRAM'ine indirgemek, kurulumda diski ve RAM'i unutup ilk yüklemede tıkanmaya yol açar.

Kuantizasyon, model ağırlıklarını daha az bit kullanan sayılarla temsil ederek model boyutunu ve VRAM ihtiyacını düşüren tekniktir. "Kuantizasyon ne kazandırır?" sorusunun net cevabı: parametre başına bayt sayısını azaltır. FP16'da 2 bayt olan gösterim, INT8'de 1 bayta, INT4'te yaklaşık 0,5 bayta iner. Bu da ağırlık belleğini 2-4 kata kadar küçültür — 70 milyar parametreli modelin yaklaşık 140 GB'lık FP16 tabanı, INT4'te yaklaşık 35 GB'a düşer.

Kazanç yalnızca bellek değildir. Daha küçük ağırlıklar daha az bellek bant genişliği tükettiği için verim de genellikle artar ve model daha ucuz kartlarda çalışabilir hale gelir. Karşılığında küçük bir doğruluk kaybı olur; ancak modern kuantizasyon yöntemleriyle bu kayıp çoğu kurumsal senaryoda kabul edilebilir düzeydedir. Açık ağırlıklı modelleri kendi altyapınızda çalıştırma seçeneklerini açık kaynak LLM nedir ve yerel çalıştırma araçlarını Ollama nedir yazılarında değerlendiriyoruz.

Pratik bir ayrım: her kuantizasyon düzeyi her işe uygun değildir. INT8, doğruluğu neredeyse hiç bozmadan belleği yarıya indirdiği için çoğu üretim yükünün güvenli varsayılanıdır. INT4 ise en agresif tasarrufu sağlar ama karmaşık akıl yürütme veya hassas görevlerde kaliteyi belirgin biçimde etkileyebilir; bu yüzden INT4'e geçmeden önce kendi görevinizde bir kalite testi yapmak şarttır. Doğruluğun kritik olduğu, belleğin ise sorun olmadığı senaryolarda FP16 hâlâ yerinde bir tercihtir. Özetle kuantizasyon, on-prem boyutlandırmanın en güçlü kaldıracıdır: aynı modeli çoğu zaman yarı donanımla çalıştırır, ama düzeyi bilinçli seçilmelidir.

Ağırlıklar denklemin yalnızca yarısıdır. Model çalışırken, her aktif isteğin ürettiği ara durumları tutan bir KV cache belleği oluşur ve bu bellek eşzamanlı kullanıcı sayısıyla doğru orantılı büyür. Tek kullanıcıya hizmet veren bir kurulumda KV cache küçüktür; ama yüzlerce eşzamanlı kullanıcıya hizmet veriyorsanız, bu cache toplam VRAM ihtiyacında ağırlıklarla yarışacak boyuta ulaşabilir.

Burada iki kavramı ayırmak gerekir: kapasite ve verim (throughput). Kapasite, aynı anda kaç isteği bellekte tutabildiğinizdir; verim ise saniyede kaç token üretebildiğinizdir. Yüksek eşzamanlı kullanıcı yükü her ikisini de zorlar. Pratikte modern çalışma zamanları, istekleri toplu işleyerek (batching) verimi artırır; ama bu da daha fazla KV cache belleği ister. Bu yüzden sunucu boyutlandırma yalnızca "model sığıyor mu" değil, "hedef yükte kaç kullanıcıya kabul edilebilir gecikmeyle hizmet verebiliyorum" sorusuna göre yapılmalıdır. Maliyet tarafını dengelemek için LLM maliyet optimizasyonu yazısı tamamlayıcıdır.

Yük birden fazla GPU'ya yayıldığında yeni bir değişken devreye girer: kartlar arası bağlantı. Model tek karta sığmadığında ağırlıklar birden çok GPU'ya bölünür (tensor paralelliği) ve kartlar her adımda birbiriyle veri alışverişi yapar; bu iletişim yavaşsa, kartları eklemek beklediğiniz hızlanmayı vermez. Bu yüzden çok GPU'lu bir sunucuda yalnızca toplam VRAM değil, GPU'ları birbirine bağlayan ara bağlantının (yüksek hızlı bir köprü mü, standart veri yolu mu) hızı da verimi doğrudan belirler.

KV cache'i büyüten ikinci etken bağlam uzunluğudur (context window). Bağlam, modelin aynı anda işlediği token sayısıdır ve KV cache belleği bu sayıyla doğrusal artar. Bağlamı iki katına çıkarmak, kullanıcı başına ayrılan cache belleğini de yaklaşık iki katına çıkarır; bunu eşzamanlı kullanıcı sayısıyla çarptığınızda, uzun bağlam tek başına toplam VRAM ihtiyacını ağırlıkların önüne geçirebilir.

Bunun pratik sonucu şudur: 8 bin token bağlamla boyutlandırılmış bir sunucu, aynı modeli 128 bin token bağlamla çalıştırmaya kalktığında bellek duvarına toslar. Bağlam uzunluğunun neden bir kaynak kararı olduğunu context window nedir yazısında ele alıyoruz. Boyutlandırmada altın kural, gerçekten ihtiyaç duyduğunuz en kısa bağlamı seçmek ve uzun bağlamı yalnızca gereken senaryolar için ayrı planlamaktır; "her ihtimale karşı maksimum bağlam" kararı, donanım bütçesini sessizce katlar.

Şimdi bu değişkenleri tek bir hesaba bağlayalım. Aşağıdaki adımlar, bir modelden yola çıkıp llm donanım gereksinimini kaba ama savunulabilir bir rakama dönüştürmenin pratik yoludur; kesin planlama öncesi hızlı bir ön eleme sağlar.

Nasıl Yapılır

On-premise LLM donanımını kaba boyutlandırma

Model ve yükten yola çıkarak gereken VRAM'i, GPU sayısını ve sunucu kapasitesini yaklaşık hesaplama adımları.

1. 1

   İş yükünü tanımla

   Hangi model, hedef eşzamanlı kullanıcı sayısı ve tipik bağlam uzunluğu — bu üç girdiyi netleştir.

2. 2

   Ağırlık belleğini hesapla

   Parametre sayısını parametre başına bayt ile çarp: FP16 için 2, INT8 için 1, INT4 için yaklaşık 0,5 bayt.

3. 3

   KV cache payını ekle

   Eşzamanlı kullanıcı sayısı ile bağlam uzunluğunu dikkate alarak çalışma zamanı bellek payını topla.

4. 4

   İşletim payını ekle

   Aktivasyon ve bellek parçalanması için toplamın yaklaşık %15-25'i kadar tampon bırak.

5. 5

   GPU sayısına böl

   Toplam VRAM'i seçtiğin GPU'nun VRAM'ine böl ve yukarı yuvarla; sonucu güç ve soğutmayla birlikte sunucuya çevir.

Bu gpu bellek hesabı bilinçli olarak kabadır; amacı hassas bir tahmin değil, doğru büyüklük sınıfını bulmaktır. Örnek: INT4'e kuantize 70 milyar parametreli bir model, ağırlıklar için ~35 GB, orta düzey eşzamanlı kullanıcı için KV cache ve %20 işletim payıyla toplam ~50-60 GB isteyebilir; bu da 80 GB'lık tek bir kartla ya da 40 GB'lık iki kartla karşılanabilir (illustratif). Gerçek değerleri, seçtiğiniz çalışma zamanıyla küçük bir yük testinde doğrulamak şarttır.

Boyutlandırma hatalarının çoğu aynı birkaç yanılgıdan doğar. Deneyimli bir gözle en sık görülenler:

• Yalnızca ağırlıkları hesaplamak: Modelin FP16 boyutuna bakıp kartı seçmek, KV cache'i unutmak demektir; yüksek eşzamanlı kullanıcı ve uzun bağlamda sistem beklenmedik biçimde belleğe sığmaz.
• Bağlamı abartmak: "Her ihtimale karşı" maksimum bağlam seçmek, donanım maliyetini gereksiz yere katlar; gerçekte ihtiyaç duyulan bağlam çoğu senaryoda çok daha kısadır.
• Kuantizasyonu göz ardı etmek: FP16'da boyutlandırıp bütçeyi şişirmek yaygındır; oysa uygun kuantizasyon çoğu zaman aynı modeli yarı donanımda çalıştırır.
• Verimi kapasiteyle karıştırmak: Model belleğe sığıyor diye sistemin hedef yükte yeterince hızlı olacağını varsaymak; gecikme ve verim ayrı ölçülmelidir.
• Güç ve soğutmayı unutmak: Sunucu boyutlandırma yalnızca VRAM değildir; GPU'ların güç çekişi ve ısı yükü, veri merkezi kapasitesiyle birlikte planlanmazsa kurulum sahada tıkanır.

Bu hataların ortak kökü, donanımı iş yükünden önce seçmektir. Doğru sıra tersidir: önce modeli ve gerçek yükü ölç, sonra hesapla, en son kartı ve sunucuyu seç. Yerelde model çalıştırma ekosistemine daha geniş bakmak için açık kaynak LLM karşılaştırma yazısı da yardımcı olur.

LLM için hangi donanım gerekir?

On-premise bir LLM'in temel donanımı bir veya daha fazla veri merkezi sınıfı GPU, bunları besleyecek yeterli sistem belleği ve hızlı depolamadır. Belirleyici bileşen GPU'nun VRAM'idir; çünkü modelin ağırlıkları ve çalışma sırasındaki KV cache belleği burada tutulur. llm donanım gereksinimi tek bir reçete değildir: 7-8 milyar parametreli bir model tek bir modern GPU ile çalışabilirken, 70 milyar parametreli bir model kuantize edilse bile genellikle birden fazla GPU ister. Doğru yaklaşım, önce çalıştıracağınız modeli ve yükü belirleyip gpu bellek hesabı yapmak, sonra sunucuyu buna göre boyutlandırmaktır.

Kaç GPU lazım?

GPU sayısı, modelin kuantizasyon sonrası toplam bellek ihtiyacının tek bir GPU'nun VRAM'ine sığıp sığmadığıyla belirlenir. Kaba hesap: gereken toplam VRAM'i seçtiğiniz GPU'nun VRAM'ine bölün ve yukarı yuvarlayın; ağırlıklar tek karta sığsa bile yüksek eşzamanlı kullanıcı ve uzun bağlam, KV cache'i büyüterek ek karta ihtiyaç doğurabilir. Örneğin INT4'e kuantize 70 milyar parametreli bir model, ağırlıkları için yaklaşık 35 GB isterken KV cache ve işletim payıyla birlikte pratikte iki GPU'ya yayılabilir. Verim (throughput) hedefiniz yüksekse, tek büyük karttan çok, yükü paylaştıran çoklu GPU daha mantıklı olabilir.

Kuantizasyon ne kazandırır?

Kuantizasyon, model ağırlıklarını daha az bit kullanan sayılarla temsil ederek model boyutunu ve VRAM ihtiyacını düşürür. FP16 gösterimde parametre başına 2 bayt gerekirken, INT8'de 1 bayta, INT4'te yaklaşık 0,5 bayta iner; bu da taban bellek ihtiyacını 2-4 kat azaltır. Kazanç yalnızca bellek değildir: daha küçük ağırlıklar daha az bellek bant genişliği tükettiği için verim de genellikle artar. Karşılığında küçük bir doğruluk kaybı olur; ancak modern kuantizasyon yöntemleriyle bu kayıp çoğu kurumsal senaryoda kabul edilebilir düzeydedir. Kısaca kuantizasyon, aynı modeli daha ucuz donanımda çalıştırmanın en pratik yoludur.

Bağlam uzunluğu donanımı nasıl etkiler?

Bağlam uzunluğu (context window), modelin aynı anda işlediği token sayısıdır ve KV cache belleğini doğrusal olarak büyütür. Bağlamı iki katına çıkarmak, kullanıcı başına ayrılan cache belleğini de yaklaşık iki katına çıkarır; bu yük, eşzamanlı kullanıcı sayısıyla çarpıldığında toplam VRAM ihtiyacında ağırlıkların bile önüne geçebilir. Bu yüzden boyutlandırmada yalnızca modelin boyutunu değil, hedeflediğiniz bağlam uzunluğunu da hesaba katmalısınız.

GPU belleği yetmezse ne olur?

Model kuantize edilerek küçültülebilir, bağlam uzunluğu veya eşzamanlı kullanıcı sayısı sınırlanabilir, ya da yük birden fazla GPU'ya bölünebilir. Yetersiz VRAM durumunda bir kısmı sistem belleğine taşıma (offloading) mümkündür ama verimi ciddi biçimde düşürür ve üretim için nadiren uygundur. Sağlıklı çözüm, gpu bellek hesabını baştan doğru yapıp sunucu boyutlandırmayı gerçek yüke göre planlamaktır.

Özetle, on-premise bir kurulumda llm donanım gereksinimi üç değişkenin çarpımıdır: model boyutu ağırlıkların taban belleğini, kuantizasyon parametre başına baytı, eşzamanlı kullanıcı ve bağlam uzunluğu ise KV cache'i belirler. Bu kalemlerin toplamına bir işletim payı ekleyip seçtiğiniz GPU'nun VRAM'ine bölerek GPU sayısına, oradan da sunucu boyutlandırmaya ulaşırsınız. Kuantizasyon bu denklemin en güçlü kaldıracıdır; model boyutu vram ihtiyacını 2-4 kat düşürerek donanımı erişilebilir kılar.

Kurumunuz için hangi modelin, hangi kuantizasyonla, hangi donanımda çalışacağına dair somut bir boyutlandırma planı ve kurulum yol haritası çıkarmak isterseniz, bir danışmanlık görüşmesi ile iş yükünüze özel bir gpu bellek hesabı ve sunucu boyutlandırma çalışmasıyla başlayabiliriz. Uçtan uca mimari için kapsamlı rehber yazısını, veri egemenliği tarafını değerlendirmek için ise on-premises yapay zeka vs bulut karşılaştırmasını inceleyebilirsiniz.