LLM Self-Hosting için VRAM Hesaplayıcı
Kendi barındırılan bir LLM, çıkarımın operatörün kontrol ettiği donanım üzerinde, üçüncü taraf bir API üzerinden değil, çalıştırılması anlamına gelir; bu durum maliyet, veri kontrolü ve gizlilik profilini değiştirir. Bir modelin çalışıp çalışmadığı tamamen belleğe bağlıdır.
LLM Uyumluluk Hesaplayıcı
Hesaplayıcı, modelin, hassasiyetinin, bağlam uzunluğunun ve hedef donanımın temelinde bir modelin yerel olarak çalışması için gereken VRAM veya birleşik belleği tahmin eder. Bir yapılandırmanın uyup uymadığını, ağırlıklar, KV önbelleği ve ek yük arasında belleğin nasıl bölündüğünü ve belirli bir GPU veya Mac'in çalıştırabileceği modelleri döndürür. Niceleme biçimleri ve hassasiyet genişlikleri, Hugging Face Transformers belgelerini takip eder. 1
Bu tahminlerin arkasındaki tam matematiği öğrenmek için kendi barındırılan LLM VRAM hesaplama metodolojimize bakın.
Kendi barındırma için donanım: GPU'lar ve Apple Silicon
İki sayı donanımı belirler. Kapasite uyum eşiğidir ve çözümleme bellek bant genişliğine bağlıdır, bu nedenle saniye başına token sayısı kartın GB/s değeriyle kabaca orantılıdır.
Yukarıdaki satırlar her sınıfı örnekler. Hesaplayıcı toplamda 34 kart taşır; bunlara A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX ve AMD Instinct serisi eklenmiştir. 24 ila 32 GB'de, bir 70B model ağır niceleme artı kısa bağlam veya iki kart gerektirir. Bir 671B model standart minimum olarak 640 GB (8×80 GB) gerektirir. RTX PRO 6000, iş istasyonu sınıfının en üst tek kartıdır ve perakende fiyatı 2026 ortalarına doğru başlangıç MSRP'si olan $8,565'den yaklaşık $13,000'a yükselmiştir.2
Apple Silicon ve birleşik bellek: Apple Silicon'da CPU ve GPU tek bir bellek havuzunu paylaşır ve GPU varsayılan olarak Metal'in recommendedMaxWorkingSetSize aracılığıyla toplam RAM'in yaklaşık 75%'ini adresler, daha küçük Mac'lerde biraz daha düşüktür. Üst sınır sudo sysctl iogpu.wired_limit_mb= ile yükseltilebilir, macOS için 8 ila 16 GB bırakılır. 3 4 Bir 128 GB Mac, GPU'ya yaklaşık 96 GB sunar. M3 Ultra, 512 GB'a kadar, yaklaşık 384 GB sunar; bu, çoklu GPU çoğaltma vergisi olmadan tek bir cihazda KV boşluk payı ile 4-bit'te 400B sınıfı bir model için yeterlidir. 5 Büyük modeller için bu tek cihazlı yol Apple'ın avantajıdır, ancak AMD Strix Halo (128 GB) ve NVIDIA DGX Spark (128 GB) artık uygun fiyatlı büyük birleşik bellek sunmaktadır. 6
LLM sunum motorları
Sunum motoru seçimi, tek bir en iyi araçtan ziyade iş yüküne göre ayrılır. Üretim sunum motorları veri merkezi GPU'larında birçok eşzamanlı kullanıcı için sayfalı dikkat ve sürekli toplu işleme kullanırken, yerel öncelikli çalışma zamanları bir masaüstü, dizüstü bilgisayar veya tek bir GPU üzerinde tek bir kullanıcıyı hedefler. Fark yük altında ortaya çıkar. 64 eşzamanlı istekte, vLLM llama.cpp'den yaklaşık 44 kat daha fazla saniyede token sundu; llama.cpp'nin ilk token süresi 3 dakikayı aştı. Tek bir kullanıcı için ikisi karşılaştırılabilir. 7
Hesaplayıcı, iki kamp arasında sekiz motoru modeller:
Üretim seviyesinde, SGLang'ın RadixAttention'ı çapraz istek öneklerini yeniden kullanır, TensorRT-LLM motor derlendiğinde aktivasyon bütçesini dondurur ve LMDeploy, InternLM, Qwen ve DeepSeek için W4A16 ve MXFP4'ü maliyet etkin şekilde sunar. 8 Yerel tarafta, TabbyAPI'li ExLlamaV2 bir kartı tam olarak doldurmak için kesirli ortalama bit genişliğini ayarlar ve MLX, toplam RAM'i bütçe olarak kullanmak için Apple birleşik belleğini kullanır. Hugging Face TGI tek çıkıştır. Aralık 2025'te bakım moduna geçti ve GitHub deposu 21 Mart 2026'da arşivlendi (salt okunur), kullanıcılar vLLM, SGLang ve llama.cpp'ye yönlendirildi. 9 10
Çoğu kişi bu motorları, onları sarmalayan son kullanıcı uygulamaları aracılığıyla tanır. Ollama, LM Studio ve AnythingLLM'nin tümü llama.cpp üzerinde çalışır (LM Studio ayrıca MLX üzerinde), tek komutla modeller, OpenAI uyumlu localhost API'si ve AnythingLLM için PDF'ler ve kod tabanları üzerinde belge RAG'i ekler. 2026-07-11 itibarıyla kaba bir benimseme göstergesi olarak GitHub yıldızlarına göre Ollama 175,925 ve vLLM 85,979 yıldıza sahiptir, her ikisi de açık kaynaktır, AnythingLLM ise 63,120 yıldıza sahiptir. LM Studio'nun 5,053 yıldızı kapalı kaynak uygulama yerine açık kaynak CLI deposundan (lmstudio-ai/lms) gelir, dolayısıyla gerçek masaüstü benimsemesini olduğundan düşük gösterir. 11 12 13 14
Etkileşimli bir manzara bileşeni bu araçları kullanım durumlarıyla eşleştirir. Entegrasyonlar ve geniş uyumluluk Ollama'ya, geliştiriciler ve yüksek performans vLLM'ye, yerel RAG uygulamaları AnythingLLM'ye ve başlangıç dostu denemeler LM Studio'ya aittir.
Açık kaynaklı büyük dil modelleri
Açık ağırlıklı modeller mimarilerini ve ağırlık dosyalarını yayınlar, böylece herkes bunları genellikle Hugging Face'ten indirebilir, değiştirebilir ve çalıştırabilir. 2026 ortasındaki kendi barındırılabilir sınır, Qwen2.5 ve Llama-3 döneminin çok ötesine geçmiştir:
Toplam ve aktif sütunları yük taşıyan ayrımdır. Toplam parametreler belleği ve GPU sayısını belirler, aktif parametreler ise hesaplamayı belirler. DeepSeek-V4-Flash ve GLM-5.2 2026'da açık ağırlıklar olarak geldi, Gemma 4 aileyi Apache 2.0 altında yeniden lisansladı ve GPT-OSS MoE uzmanlarını doğal MXFP4'te sunar. 15 16 17 18 19
Sahipli amiral gemileri (OpenAI'nin GPT-5.6'sı, Google'ın Gemini 3.1 Pro'su, Anthropic'in Claude Opus 4.8'i, xAI'ın Grok 4.5'i) indirilemez veya kendi barındırılamaz; bunlar API ile sunulur, genellikle OpenAI uyumlu bir uç nokta arkasındadır. Yerel bir dağıtım, bu modellerin belirli bir görevde daha iyi yaptıklarından vazgeçer. 20 21 22
Niceleme ve MoE Boyutlandırma
Niceleme 2026'da ağırlıkları eğitim sonrası yuvarlamaktan çok, niceleme devreye girmeden önce önbelleği azaltan mimari seçimlerin yanı sıra, tasarım gereği düşük bit ile gelen denetim noktalarıyla ilgilidir.
Doğal düşük bit denetim noktaları: Sınırdaki açık modeller giderek niceleme bilinçli olarak dağıtılmaktadır. GPT-OSS, MoE uzmanlarını MXFP4'te (paylaşılan 8 bit ölçekle E2M1, parametre başına 4.25 bit) dağıtır, böylece 120B model yaklaşık 63 GB'a sığar, tek bir 80 GB GPU'da; naif bir BF16 tahmini üç GPU üzerinde yaklaşık 234 GB talep ederdi. DeepSeek-V3 ve R1, parametre başına yaklaşık 1 bayt olarak doğal FP8 dağıtır. Ağırlıklar, parametre sayısına göre değil, denetim noktasının gerçek dtype'ına göre boyutlandırılmalıdır. 23 24
GGUF etkin bit tuzağı: GGUF dosyaları hassasiyeti karıştırır; blok başına FP16 ölçekler ve nicelemesiz gömme ve çıktı tensörleri ile, bu nedenle isim boyuttan ziyade bir tabandır. Q4_K_M yaklaşık 4.9 etkin bittir (parametre başına 0.61 bayt), 4.0 değil. Q8_0 8.5 bittir (parametre başına 1.06 bayt), 8.0 değil. Bit sayısına göre anahtarlanan bir hesaplayıcı, Q4'te ağırlıkları yaklaşık 20%, Q8'de 6% eksik boyutlandırır. IQ4_XS gibi IQ-quant'lar (yaklaşık 4.25 bit) artık daha küçük bir boyutta Q4_K_M kalitesine eşdeğerdir. 25
KV önbellek niceleme: KV dtype'ını düşürmek tüm önbelleği doğrusal olarak ölçeklendirir ve ağırlık hassasiyetinden bağımsızdır. FP8 (e4m3) KV'yi yarıya indirir (Llama-3-8B 128k'de, parti 1, 16.0 GiB BF16'dan 8.0 GiB FP8'e), geniş ölçüde ücretsiz kalitede. INT4 bunu dörde böler ancak bir değerlendirme gerektirir. vLLM'de tek bir bayraktır (--kv-cache-dtype fp8). 26
Bellek tasarrufu olarak dikkat: Çok Başlıklı Gizli Dikkat (MLA, DeepSeek tarafından kullanılır), başlık başına anahtar ve değerler yerine her token başına katman başına tek bir paylaşılan düşük dereceli gizli vektör (yaklaşık 576 öğe) önbelleğe alır; bu, nominal 128 başlıklı okumadan kabaca 30 kat daha küçüktür. Bu, yaklaşık 8.6 GiB KV ile bir 671B modelin 128k bağlam sunmasını sağlayan şeydir. Kayar pencere ve yerel-küresel dikkat (Gemma 2 ve 3, GPT-OSS, Llama 4), çoğu katmanı tam bağlam yerine sabit bir pencereyle sınırlar ve naif bir tüm küresel tahmine karşı uzun bağlam KV'sini 10 ila 40 kat azaltır. Bunlar mimari aile başına sabittir, ayarlanabilir parametreler değildir. 27
Boşaltma ve parçalama: Ağırlıklar GPU belleğini aştığında, boşaltma kullanılmayan MoE uzmanları gibi aktif olmayan parçaları GPU belleği ile daha yavaş sistem RAM'i arasında taşır, çalışabilme yeteneği için saniye başına tokenden ödün verir. 28 Parçalama, bir modeli birkaç cihaz veya bellek katmanı arasında böler; bu, bir 671B modelin 8 GPU'lu bir düğümü kapsamasını sağlar. Her ikisi de sabit donanımın erişimini bir bant genişliği maliyetiyle genişletir.
Kendi barındırmanın faydaları ve ödünleşimler
Kendi barındırmanın gerekçesi veri kontrolü, yüksek hacimde maliyet ve yapılandırma özgürlüğüdür. Karşısındaki gerekçe ise donanım maliyeti, operasyonel yük ve sahipli model farkıdır.
Veri ikameti ve uyumluluk: Sınır ötesi veri aktarımı uyumluluk itici gücüdür. GDPR kapsamında, kişisel verilerin AB dışına gönderilmesi yasal güvenceler, sözleşme yükümlülükleri veya kısıtlamaları tetikleyebilir. AB Yapay Zeka Yasası ikinci bir katman ekler, ancak tam olarak yürürlükte olmaktan ziyade aşamalı olarak devreye girmektedir. 2026 ortası itibarıyla, yasaklar (2 Şubat 2025'ten beri uygulanabilir) ve genel amaçlı yapay zeka (GPAI) model yükümlülükleri (2 Ağustos 2025'ten beri) halihazırda geçerlidir; risk yönetimi, denetlenebilirlik ve yönetişim etrafındaki yüksek risk gereksinimleri ise 2025-26 Dijital Omnibus paketi kapsamında Ek III bağımsız yüksek riskli sistemler için 2 Aralık 2027'ye ve Ek I gömülü sistemler için 2 Ağustos 2028'e ertelenmiştir. 29 30 31 Çıkarımın yargı alanı içinde, kontrollü bir ağda çalıştırılması, hassas verileri üçüncü bir tarafın elinden uzak tutar; bu, finans, sağlık hizmetleri ve kamu sektörü için egemen yapay zeka durumudur.
Maliyet ve kontrol: Kendi barındırma, tüketici GPU'ları veya küçük bir sunucu ile pahalı başlar, ancak yerel çıkarım yüksek istek hacmi oluşturan ekipler için yinelenen API ücretlerinin altına düşebilir. Ayrıca satıcı bağımlılığını ve bağlam penceresi, çıkarım ayarları ve entegrasyon üzerindeki dayatılan sınırları kaldırır ve özel veriler üzerinde ince ayar için ağırlıklara doğrudan erişim sağlar.
Ödünleşimler: GPU belleği bağlayıcı sınırdır ve bazı iş yükleri hala 16 ila 48 GB VRAM gerektirir, bu da daha küçük ekiplerin erişiminin dışındadır. Dağıtım, aksi takdirde bir bulut sağlayıcının ele alacağı bağımlılık yönetimi, CUDA ve çekirdek sorun giderme, izleme ve güncellemeleri ekler. Performans, toplu işleme ve parçalamadan donanım kullanımına kadar operatörün sorumluluğundadır. Ve en güçlü sahipli modeller API ile sunulmaya devam eder, bu nedenle yerel bir dağıtım, onların lider olduğu görevlerde bir yetenek farkını kabul eder.
Kendi barındırılan LLM VRAM hesaplama metodolojisi
Bir modelin bellek ayak izi, parametre sayısından ölçeklendirilen tek bir rakam değil, bağımsız olarak hesaplanan ve toplanan dört terimin toplamıdır:
VRAM_total = Weights + KV cache + Activations + Overhead
En yaygın tahmin hatası, son üç terimi ağırlıklar üzerine sabit bir 20% işaretleme olarak birleştirir. Bu, bir model boyutunda yakındır ve diğerlerinde yanlıştır, çünkü üç terim farklı ölçeklenir. 32
Ağırlıklar: Ağırlık belleği, parametreler çarpı parametre başına bayttır. BF16 ve FP16 parametre başına 2.0 bayt depolar ve FP8 ve INT8 yaklaşık 1.0 depolar. Tuzak 4-bittir, bu parametre başına 0.5 bayt değildir. Gerçek gruplandırılmış INT4 (GPTQ, AWQ) 0.52 ile 0.55 arasında sonuçlanır ve GGUF Q4_K_M parametre başına yaklaşık 0.61 bayttır (4.9 etkin bit, 4.0 değil). GGUF Q8_0 8.5 bittir (parametre başına 1.06 bayt), 8.0 değil. 0.5 varsaymak bir 70B modeli yaklaşık 8 GB eksik sayar, bu da uyum kararını tersine çevirir. 33
Uzmanların karışımı aktif olanları değil, her uzmanı boyutlandırır: Her token başına birkaçı ateşlense de tüm uzman ağırlıkları VRAM'de kalır. Mixtral-8x7B, aktif 13B değil, tam 46.7B parametre için Q4'te yaklaşık 28 GB gerektirir. Toplam parametreler belleği ve GPU sayısını belirler, aktif parametreler hesaplamayı belirler. Aktif parametrelere göre boyutlandıran bir hesaplayıcı, yanlış şekilde büyük MoE modellerine sığdırır.
KV önbelleği: Anahtar-değer önbelleği 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element. Mevcut modellerin çoğu, birçok sorgu başlığının birkaç KV başlığını paylaştığı gruplandırılmış sorgu dikkati (GQA) kullanır, böylece n_kv_heads çiftleri önbelleğe alınır, bu da tam çok başlıklı dikkate karşı önbelleği 4 kat (Llama-3-8B) ile 8 kat (Llama-3-70B) küçültür. Hem head_dim hem de n_kv_heads, her modelin config.json'undan okunur, gizli boyut ve başlık sayısından türetilmez, çünkü Gemma (head_dim 256) ve Qwen3 (128) gibi aileler aksi takdirde yaklaşık 2 kat yanlış boyutlandırılırdı. Önbellek hem bağlam uzunluğu hem de parti boyutuyla doğrusal olarak büyür ve uzun bağlamda ağırlıklarla yarışır veya onları aşar. Llama-3-8B token başına 128 KiB önbelleğe alır, bu nedenle 128k bağlamda ve parti 1'de FP16 KV önbelleği 16.0 GiB olup BF16 ağırlıklarının 16 GB'ına eşittir. Bir FP8 KV önbelleği bunu yarıya indirir. 34
Ek yük bir tabandır, yüzde değil: Framework ek yükü, GPU başına sabit bir taban (CUDA bağlamı ve çekirdekler, GPU başına yaklaşık 1 ila 2 GB) artı küçük sınırlı bir kesirdir, ağırlıkların bir payı değildir. Sabit bir 20%, tek başına bir CUDA bağlamının 6 GB'lık bir modelin 20%'sini aşabildiği küçük modelleri eksik sayar ve 140 GB'lık bir modelin 28 GB bağlama ihtiyaç duymadığı büyük modelleri fazla sayar. Parçalı taban doğru modeldir ve sabit 20% hızlı bir tahmin olarak işe yarar. 35
Aktivasyonlar ve sunum motoru: Aktivasyon terimi geçicidir. Çözümleme sırasında, her seferinde bir token, küçüktür ve ek yük tabanına katlanır, ancak prefill tüm prompt'lar bir kerede işler, bu nedenle aktivasyon zirvesi parti boyutu ve prompt'lar uzunluğuyla ölçeklenir. Tabanın kendisi motora bağlıdır. Sayfalı sunucular (vLLM, SGLang) her kartın belirli bir payını bir bellek kullanım ayarı aracılığıyla rezerve eder, 0.90 varsayılanında yaklaşık 10%, ve ağırlıkları ve KV'yi geri kalanın içine sığdırır. Sayfasız çalışma zamanları (llama.cpp, Ollama) bunun yerine yaklaşık 1 ila 2 GB sabit bir hesaplama arabelleği tutar. Her ikisini de aynı şekilde boyutlandırmak birkaç GB yanıltır.
Birden çok GPU temiz bir şekilde bölünmez: İki 24 GB kart 48 GB kullanılabilir alan değildir. Tensör paralelliği altında ağırlıklar ve KV önbelleği N karta bölünür (W/N ve KV/N), ancak aktivasyonlar, CUDA bağlamı ve NCCL iletişim arabellekleri her kartta çoğaltılır, bu nedenle toplam ayak izi aynı toplamın tek cihazlı bir tahmininden daha büyüktür. Bu çoğaltma vergisi, 70B'nin 43 GB ağırlık gerektirmesi durumunda neden kısa bir bağlamla iki 24 GB karta sığdığı ve güvenli kontrolün toplamı GPU sayısına bölmek yerine GPU başına toplam olduğudur.
Dört terim uyum sınırında etkileşir. Bir yapılandırma, gerekli bellek kullanılabilir belleğin 90%'ının altında veya eşit olduğunda Sığar, üst 10% kapasitede Sınırda ve kullanılabilirin üzerinde Sığmaz olarak okunur. Sayfalı sunucular, kullanım ayarı aracılığıyla bu 10%'u zaten geri tutar. Aşağıdaki örnekler, tüketici kartlarında llama.cpp ile yaygın donanımda Llama-3 kullanır:
128k bağlamda KV önbelleği ağırlıklara eşittir, bu nedenle uyuma bağlam uzunluğu karar verir, parametre sayısı değil. Son satır sığar çünkü Q4 ağırlıkları (~405 GB) 8k bağlamda 640 GB'ın altında kalır. MLA'nın getirisi uzun bağlamdadır, burada bir 671B modelin KV'sini 128k sunacak kadar küçük tutar.
Tercih edilen kaynak olarak ekleDaha fazla okuma
- LLM Niceleme: BF16 vs FP8 vs INT4
- LLM Çıkarım Motorları: vLLM vs LMDeploy vs SGLang
- GPU Eşzamanlılık Kıyaslaması: H100 vs H200 vs B200 vs MI300X
- Çoklu GPU Kıyaslaması: B200 vs H200 vs H100 vs MI300X
- En İyi 60+ Bulut GPU Sağlayıcısı
- Bulut LLM vs Yerel LLM'ler
- LLM Fiyatlandırması: Karşılaştırılmış En İyi 15+ Sağlayıcı
- LLM Kuruluşlar için Fine-Tuning Rehberi
SSS'ler
Kendi barındırılan bir LLM, LLM uygulamaları için kullanılan ve üçüncü taraf bir bulut hizmetine güvenmek yerine tamamen sizin kontrol ettiğiniz donanımda (kişisel bilgisayarınız veya özel sunucunuz gibi) çalışan büyük bir dil modelidir.
Teknikler arasında llama.cpp gibi çerçeveler, Hugging Face transformers gibi kütüphaneler, kullanıcı dostu uygulamalar (Ollama, LM Studio), kaynak ihtiyacını azaltmak için model niceleme (ör. GGUF, GPTQ), büyük modelleri birden çok cihaza dağıtmak için model paralelliği ve optimize edilmiş çıkarım motorları (vLLM gibi) bulunur.
Evet, vLLM, Ollama ve LM Studio gibi araçlar birden çok (genellikle eşzamanlı) isteği işleyebilen yerel sunucular çalıştırabilir. Bu, bulut API'lerinin çalışma şekline benzer, genellikle verimlilik için toplu işleme kullanılır.
Hayır, kendi barındırılan llm için harici erişim iznine veya bir sağlayıcıdan API anahtarlarına ihtiyacınız yoktur. Kendiniz barındırdığınız için doğrudan erişiminiz vardır; gerekirse yerel sunucunuz için isteğe bağlı olarak kendi kimlik doğrulamanızı ayarlayabilirsiniz.
Harici Bağlantılar
Bu araştırmayı kaynak gösterin
Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{LLM Self-Hosting için VRAM Hesaplayıcı}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Erişim tarihi: 12 Temmuz 2026}
}Referans Linkleri
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.