LLM VRAM hesaplayıcı — model ağırlıkları, KV cache ve GPU uyumu
Bir model gerçekte ne kadar GPU belleği ister? Ağırlıklar ve KV cache, context penceresi ve eşzamanlı kullanıcı ile birlikte ölçeklenir. Bir model seç, yükü ayarla ve hangi GPU'ların yettiğini gör.
Model seç
Hassasiyet & yük
Kapalıyken her kullanıcı context penceresinin tamamını tutar; vLLM'in “Maximum concurrency” diye bildirdiği en kötü durum budur. Açıkken bir istek ortalama prompt'unu ve cevabının yarısını tutar; tüm prompt'ların paylaştığı prefix bir kez cache'lenir.
VRAM kırılımını görmek için bir model seç.
Ağırlıklar, KV cache ve ek yük modelin kendi config'inden, tarayıcının içinde hesaplanır — yukarıdan Hugging Face'te ara ya da hazır bir modelle başla.
Sayılar nasıl hesaplanıyor ▸▾
Ağırlıklar = parametre × byte/parametre (FP16/BF16 = 2, FP8/INT8 = 1, INT4 = 0.5). Mixture-of-Experts modellerde tüm uzmanlar yüklenir, dolayısıyla aktif alt küme değil toplam parametre kullanılır.
KV cache = 2 × katman × kv_head × head_dim × byte × context × eşzamanlılık. Grouped-Query Attention (kv_head < attn_head) bunu ciddi ölçüde küçültür — her modelin config'inden okunur. Multi-head latent attention (DeepSeek) ise token başına katman × (kv_lora_rank + qk_rope_head_dim) × byte saklar. vLLM'in ayırdığı gibi hesaplanır: kayan pencereli bir katman penceresine ek olarak işlenmekte olan tüm token'ları (iki --max-num-batched-tokens batch'i), Mamba ya da linear-attention katmanı ise iki durum bloğu tutar.
Ek yük vLLM 0.31'in her GPU'da ağırlıklar ve cache dışında tuttuğu bellektir: runtime tamponları (batch'e alabileceği her dizi için sözlükteki her giriş başına 4 byte), profil geçişinin tepe noktası (batch'lenmiş token'lar üzerindeki feed-forward bloğu ile çıkış katmanından büyük olanı) ve CUDA graph'ları. Tensor parallelism'de her GPU kendininkini tutar. On bir vLLM açılışıyla doğrulandı; vLLM'in kendi rakamlarından en fazla 0,13 GiB sapar. Her kart için bellek bütçesi vLLM'in --gpu-memory-utilization değeriyle belirlenir; bu değer varsayılan olarak 0,92'dir.
Tahminler planlama içindir, garanti değildir. Gerçek kullanım; servis motoruna (vLLM, TGI, llama.cpp) ve onun paged-attention verimliliğine göre değişir.
Bu hesaplayıcının varsayımları
LLMScale her modelin mimarisini Hugging Face Hub'daki config.json dosyasından okur — katman sayısı, attention ve key-value head sayısı, head boyutu — ve GPU belleğini yalnızca parametre sayısından değil, bunlardan hesaplar. Tarayıcının config'ini okuyamadığı Llama, Gemma ve Mistral gibi erişimi kısıtlı modeller yerleşik bir veritabanından gelir; kendi config'i olmayan depolar, örneğin GGUF kopyaları, base_model üzerinden çözülür.
Her kart için bellek bütçesi vLLM'in varsayılan payıyla belirlenir: belleğin %92'si; kalanı CUDA context'ine ayrılır. Ağırlıklara ve KV cache'e ek olarak her GPU vLLM'in kendi ek yükünü taşır: runtime tamponları, profil geçişinin tepe noktası ve CUDA graph'ları; bu hesap gerçek vLLM başlangıçlarıyla karşılaştırılarak doğrulanmıştır. Unified bellekli cihazlarda havuzun tamamı yerine gerçekçi bir pay kullanılır: Apple Mac'lerde belleğin %75'i (36 GB'ın altındakilerde üçte ikisi); Strix Halo ve DGX Spark'ta GPU'nun bildirdiği belleğin vLLM'in kullandığı %92'si — Strix Halo'nun GPU'ya verdiği 96 GB'ın 88'i, DGX Spark'ın 121,6 GB'ının 112'si (Spark'ta vLLM çoğunlukla %80 ile çalıştırılır). Her kartın bütçesi çalışma zamanının bildirdiği bellekten başlar; bu, nominal boyutun biraz altındadır, ECC açık GDDR veri merkezi kartlarında (L40S, L4, T4) ayrıca on altıda bir azdır. Decode hızını, üreticinin tepe değerinin %80'i olarak alınan bellek bant genişliğinin ve yoğun tensor işlem gücünün getirdiği sınırlardan daha düşük olanı belirler. İlk token süresi, kuyruksuz tek bir istek için prompt'un FLOP'larından hesaplanır. Tensor işlem gücü GeForce kartlarda nominal tepe değerin %90'ı olarak alınır; bu oran, vLLM ile bir RTX 4070 Ti üzerinde yapılan ölçüme dayanır (test edilen kart, nominal değerin hesaplanmasında kullanılan saat hızının üzerinde çalışmıştır). Diğer kartlarda ise tahmini bir değer olarak %60 alınır. Sayılar kapasite planlaması içindir — servis motoru ve paged-attention verimliliği gerçek değerleri yine değiştirir.
Sık sorulanlar
- 70B bir model kaç GB VRAM ister?
- Llama 3.3 70B'de yalnızca ağırlıklar BF16'da yaklaşık 131 GiB, FP8'de 68 GiB, INT4'te 38 GiB tutar: 70,6 milyar parametre × 2 byte; FP8 ve INT4'te transformer katmanları 1 byte ya da yaklaşık 4,25 bit, embedding ve çıkış katmanı ise quantize checkpoint'lerin yaptığı gibi 16 bit. KV cache ve ek yük bunun üstüne gelir; ikisi de context penceresine ve kullanıcı sayısına bağlıdır — hesaplayıcının bulduğu da budur.
- Context penceresi sonucu neden bu kadar değiştiriyor?
- KV cache, context uzunluğu ve eşzamanlı kullanıcı sayısıyla doğrusal büyür. Llama 3.1 8B, FP16'da token başına 131.072 byte saklar: tek kullanıcı için 8k token'da 1 GiB, 128k'da 16 GiB — 8k'da 16 kullanıcıyla da yine 16 GiB.
- Mixture-of-Experts modeller daha az bellek mi ister?
- Bellek açısından hayır. Tüm uzmanların yüklenmesi gerekir, bu yüzden bellek toplam parametre sayısından hesaplanır. Her token için uzmanların yalnızca bir kısmı çalışır; MoE modellerin boyutlarına göre hızlı üretmesinin nedeni budur.
- DeepSeek'in KV cache'i nasıl hesaplanıyor?
- DeepSeek-V2 ve V3, multi-head latent attention (MLA) kullanır: her head için key ve value yerine katman başına tek bir sıkıştırılmış latent saklar. Hesaplayıcı config'den kv_lora_rank ve qk_rope_head_dim değerlerini okur ve token başına katman × (kv_lora_rank + qk_rope_head_dim) × byte kullanır. DeepSeek-V3 için 8k context'te bu 0,54 GiB eder; alışılmış formül 13,34 GiB verirdi.