LLM-VRAM-Rechner

Gesamt ≈ Gewichte + KV-Cache + Laufzeit-Overhead. Gewichte = Parameter × Bits pro Gewicht ÷ 8; ein Modell mit 8 Milliarden Parametern braucht z. B. etwa 15 GiB in FP16 (16 Bit) und etwa 4,6 GiB in Q4_K_M (rund 4,9 Bit). Der KV-Cache wächst mit der Kontextlänge und der Zahl gleichzeitiger Sequenzen, stellen Sie also beides ein.

Für jedes verarbeitete Token speichert das Modell Key und Value jeder Schicht, damit sie beim Generieren nicht neu berechnet werden müssen. Größe = 2 × Schichten × KV-Köpfe × Kopfdimension × Bytes pro Element × Kontextlänge × Sequenzen, also proportional zur Kontextlänge. Modelle mit Grouped-Query-Attention (weniger KV-Köpfe) oder Sliding Window brauchen deutlich weniger.

Weniger Bits machen die Gewichte kleiner und meist schneller, kosten aber Qualität. Q8_0 liegt nahe am Original, Q5_K_M und Q6_K sind gängige Kompromisse, Q4_K_M ist bei knappem Speicher der übliche Startpunkt, unterhalb von Q3 wird der Qualitätsverlust deutlich. Die Tabelle zeigt, ob jede Stufe mit Ihren Einstellungen passt.

Alle Experten müssen geladen werden, daher zählen die Gewichte mit den GESAMT-Parametern und nicht mit den pro Token aktiven. Die Generierungsgeschwindigkeit hängt dagegen von den AKTIVEN Parametern ab; deshalb brauchen MoE-Modelle oft viel Speicher, sind aber nicht besonders langsam.

In der Regel nicht. Standardmäßig darf die GPU nur einen Teil des Unified Memory nutzen (grob zwei Drittel bis drei Viertel); bei „Apple Unified Memory“ gelten daher 75 % als nutzbar. Mit „Eigener nutzbarer Anteil“ passen Sie das an Ihre tatsächliche Einstellung an.

Gewichte und KV-Cache werden gleichmäßig auf die Karten verteilt angenommen, und jede Karte trägt ihren eigenen festen Laufzeit-Overhead; die Summe liegt daher etwas über der bei einer Karte. Die tatsächliche Aufteilung (Tensor- oder Pipeline-Parallelität) und der Kommunikations-Overhead hängen von der Engine ab, planen Sie also zusätzliche Reserve ein.

Es ist eine Planungsschätzung nur für die INFERENZ: Gewichte, KV-Cache und ein einstellbarer Overhead. Der reale Bedarf hängt von Engine (vLLM, llama.cpp u. a.), Batching, CUDA-Version und Paged-KV-Einstellungen ab. Training und Fine-Tuning brauchen viel mehr Speicher (Gradienten, Optimizer-Zustand, Aktivierungen) und liegen außerhalb dieses Tools.

Jedes erzeugte Token liest die aktiven Gewichte einmal; bei Batch 1 liegt die Obergrenze daher bei etwa „Speicherbandbreite ÷ pro Token gelesene Gewichts-Bytes“. Das ist ein theoretisches Limit ohne Rechenengpässe, KV-Cache-Lesezugriffe und Software-Overhead, die reale Geschwindigkeit ist meist niedriger. Sie erscheint erst, wenn Sie die Bandbreite Ihres Geräts eintragen.