Architekturbewusste LLM-Speicher- & Bandbreitenmethodik

VRAMLab modelliert den Inferenzspeicher von LLM-Architekturen direkt aus den fundamentalen Tensordimensionen statt über pauschale Faustfaktoren — zu 100 % clientseitig auf statischen Edge-Assets.

1. Gewichtsquantisierung & effektive Bits pro Gewicht (bpw)

Quantisierte Formate speichern blockweise Skalierungsfaktoren und Nullpunkte neben gepackten Ganzzahlgewichten. Ein 4-Bit-GGUF-Checkpoint in Q4_K_M benötigt im Schnitt 4.85 effektive Bits pro Parameter (nicht 4.00), während Q8_0 bei 8.50 bpw liegt. Bei Mixture-of-Experts-Modellen bleiben sämtliche gerouteten und geteilten Experten im Speicher resident, um Host-Paging bei jedem Token zu verhindern.

1. Gewichtsquantisierung & effektive Bits pro Gewicht (bpw)
Präzision / Format Effektive bpw 32B Weights 70B Weights vLLM / Ollama / GGUF
FP16 / BF16 (16-bit Native) 16.00 bpw 61.09 GB 131.50 GB native · fp16 · F16 / BF16
FP8 E4M3 (Hopper / Ada / Blackwell) 8.50 bpw 32.46 GB 69.86 GB fp8 · fp8 · FP8_E4M3
INT8 SmoothQuant / bitsandbytes 8.50 bpw 32.46 GB 69.86 GB bitsandbytes · q8_0 · INT8
GGUF Q8_0 (8.50 bpw) 8.50 bpw 32.46 GB 69.86 GB gguf · q8_0 · Q8_0
GGUF Q6_K (6.56 bpw) 6.56 bpw 25.05 GB 53.92 GB gguf · q6_K · Q6_K
GGUF Q5_K_M (5.69 bpw) 5.69 bpw 21.73 GB 46.77 GB gguf · q5_K_M · Q5_K_M
GGUF Q4_K_M (4.85 bpw — Recommended) 4.85 bpw 18.52 GB 39.86 GB gguf · q4_K_M · Q4_K_M
AWQ / GPTQ INT4 (4.50 bpw) 4.50 bpw 17.18 GB 36.99 GB awq · q4_K_M · AWQ_4BIT
GGUF IQ4_XS (4.25 bpw Importance Matrix) 4.25 bpw 16.23 GB 34.93 GB gguf · iq4_XS · IQ4_XS
GGUF Q3_K_M (3.91 bpw) 3.91 bpw 14.93 GB 32.14 GB gguf · q3_K_M · Q3_K_M
GGUF Q2_K (3.35 bpw Extreme) 3.35 bpw 12.79 GB 27.53 GB gguf · q2_K · Q2_K

2. Attention-spezifische KV-Cache-Gleichungen (MHA, GQA, MLA & hybride SWA)

Standard-Grouped-Query-Attention reserviert über alle Schichten hinweg 2 × L × H_kv × d_head × S × B × bytes_kv. DeepSeek Multi-head Latent Attention (MLA) komprimiert Keys und Values auf L × (d_kv_lora + d_qk_rope) × S × B × bytes_kv und senkt den Speicherbedarf langer Kontexte um über 90 %. Hybride Sliding-Window-Modelle deckeln lokale Schichten bei min(S, window_size), während globale Schichten linear mit S wachsen.

Multi-Head Attention (MHA) / Grouped-Query Attention (GQA)
2 × L × H_kv × d_head × S × B × bytes_kv
Multi-head Latent Attention (MLA)
L × (kv_lora_rank + qk_rope_dim) × S × B × bytes_kv
Hybride Sliding-Window-Attention (SWA)
(L_global × S + L_local × min(S, W)) × 2 × H_kv × d_head × B × bytes_kv
Mixture-of-Experts-Modell (MoE)
Weights ∝ P_total · Decode tok/s ∝ BW / P_active

3. Apple Silicon Unified Memory & obere Schranke der Decode-Bandbreite

Auf macOS-Systemen mit Apple Silicon endet die standardmäßige verdrahtete GPU-Zuweisung bei rund 75 % des physischen Unified RAM, sofern sie nicht per sysctl iogpu.wired_limit_mb angehoben wird (modelliert bis zu einer stabilen Obergrenze von 88 %). Die autoregressive Decode-Geschwindigkeit wird durch die effektive externe Speicherbandbreite geteilt durch aktive Parameter-Bytes plus pro Schritt gelesene KV-Cache-Bytes begrenzt und alle 12 Stunden durch die automatisierte Verifikationspipeline von VRAMLab geprüft.

3. Apple Silicon Unified Memory & obere Schranke der Decode-Bandbreite
Beschleuniger / System Physischer Speicher Default Usable Tuned Ceiling Speicherbandbreite
NVIDIA GeForce RTX 3090 (24 GB GDDR6X) 24 GB 22.1 GB (92%) 23.0 GB (96%) 936 GB/s
NVIDIA GeForce RTX 4090 (24 GB GDDR6X) 24 GB 22.1 GB (92%) 23.0 GB (96%) 1,008 GB/s
NVIDIA GeForce RTX 5090 (32 GB GDDR7) 32 GB 29.4 GB (92%) 30.7 GB (96%) 1,792 GB/s
Apple Silicon M-Series Max (64 GB Unified Memory) 64 GB 48.0 GB (75%) 56.3 GB (88% sysctl) 546 GB/s
Apple Mac Studio M4 Max (128 GB Unified Memory) 128 GB 96.0 GB (75%) 112.6 GB (88% sysctl) 546 GB/s
Apple Mac Studio M2/M3 Ultra (192 GB Unified Memory) 192 GB 144.0 GB (75%) 169.0 GB (88% sysctl) 800 GB/s
NVIDIA A100 SXM4 (80 GB HBM2e) 80 GB 73.6 GB (92%) 76.8 GB (96%) 2,039 GB/s
NVIDIA H100 SXM5 (80 GB HBM3) 80 GB 73.6 GB (92%) 76.8 GB (96%) 3,350 GB/s

4. Vernetzte Engineering-Workbenches von CodeAP Studio

Kombinieren Sie die Kapazitätsplanung in VRAMLab mit Live-Preisen für über 460 LLM-API-Endpunkte und 429-Rate-Limit-Modellierung auf DevToken, Deprecation-Tracking über 7 Ökosysteme auf LLMEOL sowie PDF/DOCX/HTML-zu-Markdown-Token-Komprimierung auf ToMarkdown.

Häufig gestellte Fragen

Wie reduziert DeepSeek MLA den KV-Cache-VRAM im Vergleich zu Standard-GQA?

Multi-head Latent Attention projiziert Keys und Values in einen gemeinsamen niederdimensionalen Latenzvektor (etwa kv_lora_rank = 512 plus qk_rope_head_dim = 64), anstatt pro Schicht 2 × H_kv × head_dim-Tensoren vorzuhalten. Dadurch sinkt der KV-Cache-Bedarf bei langen Kontexten um über 90 % gegenüber unkomprimierter MHA.

Warum benötigen Mixture-of-Experts-(MoE)-Modelle viel VRAM, dekodieren aber dennoch schnell?

Jeder geroutete Experte muss dauerhaft im GPU- oder Unified-Speicher gehalten werden, um PCIe-/SSD-Nachladen zu vermeiden; der VRAM-Bedarf skaliert daher mit der Gesamtzahl der Parameter (z. B. 235B bei Qwen3-235B-A22B). Die Decode-Rate in tok/s wird hingegen durch die Speicherbandbreite der aktiven Parameter pro Token (22B) bestimmt und erreicht das Tempo eines dichten 32B-Modells.

Warum meldet macOS auf Apple Silicon einen OOM-Fehler, bevor 100 % des Unified RAM belegt sind?

macOS reserviert über iogpu.wired_limit_mb standardmäßig rund 25 % des physischen Arbeitsspeichers für Kernel und Desktop-Compositor (GPU-Limit bei ~75 %). Modelle zwischen 75 % und 88 % RAM-Anteil erfordern vor dem Start von Ollama oder llama.cpp eine Anhebung von iogpu.wired_limit_mb mittels sysctl.

Woher stammen die Architekturdimensionen in VRAMLab?

Unsere automatisierte 12-Stunden-Verifikationspipeline prüft numerische Transformer-Konfigurationsfelder aus offiziellen Open-Weight-Veröffentlichungen und kompiliert sie in statisches HTML — komplett ohne Laufzeit-API-Aufrufe oder Nutzertelemetrie.