GPU-VRAM-Rechner für lokale LLMs
Ein 7B-Modell bei 4 Bit braucht etwa 3,3 GiB für die Gewichte, und ein Modell der Klasse Llama 3.1 8B fügt je 8.192 Token Kontext rund 1 GiB KV-Cache hinzu.
So funktioniert’s
- Wähle ein Modell, um Parameter, Schichten, KV-Köpfe und Kopfdimension zu füllen, oder wähle Eigene Werte und trage die Zahlen aus der config.json des Modells ein.
- Stelle die Quantisierungs-Bits der Gewichte ein (4 für Q4, 16 für FP16) und die Genauigkeit des KV-Caches.
- Gib die Kontextlänge in Token und die Batchgröße an, also wie viele Sequenzen gleichzeitig laufen.
- Lies die Summe und die Aufteilung in Gewichte, KV-Cache und Overhead ab. Die Tabelle zeigt, auf welche gängigen GPU-Größen es passt.
Berechnung
Speicher der Gewichte = Parameter × Bits ÷ 8 Byte. Ein Modell mit 7 Milliarden Parametern bei 4 Bit belegt 7.000.000.000 × 0,5 = 3,5 GB, also 3,26 GiB. Bei 16 Bit sind es 14 GB, passend zur Faustregel von 2 GB pro Milliarde Parameter in bfloat16 aus dem Hugging-Face-Leitfaden "Optimizing LLMs for Speed and Memory".
KV-Cache = 2 × Schichten × KV-Köpfe × Kopfdimension × Kontextlänge × Batchgröße × Byte pro Wert. Die 2 steht für Keys und Values. Hugging Face nennt die Form pro Token, 2 × 2 × Schichten × KV-Köpfe × Kopfdimension für 16-Bit-Werte, im Blogbeitrag "Unlocking Longer Generation with Key-Value Cache Quantization".
Der Overhead wird als Prozentsatz von Gewichten plus KV-Cache eingegeben. Er steht für den CUDA-Kontext, Aktivierungspuffer und Speicherfragmentierung. Die voreingestellten 10 Prozent sind eine Annahme, kein Messwert.
Alle Ergebnisse sind in GiB (1 GiB = 1.073.741.824 Byte). GPU-Hersteller schreiben "24 GB" für eine Karte mit 24 GiB, daher vergleicht die Tabelle die Summe direkt mit 8, 12, 16, 24, 48 und 80. Das ist eine Schätzung. Der reale Verbrauch hängt vom Framework (llama.cpp, vLLM, Ollama, Transformers), von den Kernels und von der Cache-Zuweisung ab.
Was den VRAM füllt
Zwei Dinge dominieren. Die Gewichte stehen fest, sobald Modell und Quantisierung gewählt sind. Der KV-Cache wächst mit jedem Token im Kontext und mit jeder Sequenz im Batch. Deshalb passt ein Modell, das eben noch passte, bei langem Kontext oder vielen parallelen Nutzern plötzlich nicht mehr.
Modelle mit Grouped Query Attention (GQA) haben weniger KV-Köpfe als Attention-Köpfe, was den Cache um ein Vielfaches verkleinert. Darum zählt das Feld KV-Köpfe mehr als die Zahl der Attention-Köpfe. Den Wert num_key_value_heads findest du in der config.json des Modells.
Gewichtsgröße pro Milliarde Parameter
| Bits pro Gewicht | GiB pro 1 Mrd. Parameter | Beispiel: 8B-Modell |
|---|---|---|
| 16 (FP16 / BF16) | 1,86 | 14,90 GiB |
| 8 (INT8 / Q8) | 0,93 | 7,45 GiB |
| 6 (Q6) | 0,70 | 5,59 GiB |
| 5 (Q5) | 0,58 | 4,66 GiB |
| 4 (Q4) | 0,47 | 3,73 GiB |
| 3 (Q3) | 0,35 | 2,79 GiB |
| 2 (Q2) | 0,23 | 1,86 GiB |
Herkunft der Modellvorgaben
- config.json des jeweiligen Repositorys: huggingface.co/Qwen/Qwen2.5-{7B,14B,32B,72B}, huggingface.co/Qwen/Qwen3-{8B,32B}, huggingface.co/mistralai/Mistral-7B-v0.3, huggingface.co/mistralai/Mistral-Nemo-Base-2407, huggingface.co/microsoft/phi-4.
- Llama 3.1 8B und 70B: Die config.json von Meta ist auf Hugging Face zugangsbeschränkt, die Werte stammen daher aus Tabelle 3 des Meta-Papers "The Llama 3 Herd of Models" (arXiv 2407.21783). Gemma 2 9B und 27B: Tabelle 1 des Google-Berichts "Gemma 2" (arXiv 2408.00118).
- Die Parameterzahlen sind die safetensors-Summen, die die Hugging-Face-API für jedes Repository anzeigt. Fehlt in der config.json head_dim, wird hidden_size ÷ Attention-Köpfe verwendet.
Häufige Fragen
Wie viel VRAM braucht ein 7B-Modell bei 4 Bit?
Etwa 3,3 GiB allein für die Gewichte. Bei 8.192 Token Kontext kommt bei einem Modell der Klasse Llama 3.1 8B rund 1 GiB KV-Cache dazu, mit Overhead also etwa 5 GiB. Eine 8-GB-Karte schafft das und hat noch Luft für mehr Kontext.
Kann eine 24-GB-Karte ein 32B-Modell ausführen?
Bei 4 Bit ja. Qwen2.5 32B hat rund 32,76 Milliarden Parameter, die Gewichte belegen also etwa 15,3 GiB. Bei 8.192 Token Kontext ist der KV-Cache 2 GiB groß, mit 10 Prozent Overhead liegt die Summe bei etwa 19 GiB.
Warum weicht mein tatsächlicher Verbrauch von der Schätzung ab?
Frameworks haben unterschiedlichen Overhead. vLLM reserviert den Großteil der GPU vorab für den KV-Cache und verdrängt Anfragen, wenn der Platz knapp wird, llama.cpp legt den Cache für den vollen Kontext gleich zu Beginn an, und GGUF-K-Quants speichern zusätzliche Skalenwerte, ihre effektiven Bits liegen also über der Nennzahl. Erhöhe die Bits oder den Overhead, wenn Speicherfehler auftreten.
Funktioniert das auch für Mixture-of-Experts-Modelle?
Die Gewichte müssen trotzdem komplett im Speicher liegen, trage also die Gesamtzahl der Parameter ein, nicht die aktiven. Der KV-Cache hängt nur von den Attention-Schichten ab, nimm also Schichten und KV-Köpfe aus der config. Die Vorgaben hier sind dichte Modelle.
Gemma 2 nutzt ein Sliding Window. Ist die Schätzung dann niedriger?
Gemma 2 wechselt lokale Schichten mit 4.096 Token Fenster und globale Schichten ab. Das Tool zählt in allen Schichten den vollen Kontext, liefert für Gemma 2 also eine Obergrenze, wenn der Kontext länger als das Fenster ist.