Wie viel VRAM du für ein LLM brauchst, lässt sich mit einer Rechnung bestimmen: Parameter × Byte pro Gewicht plus Speicher für KV-Cache und Laufzeit-Overhead. Das ergibt etwa 2 GB pro Milliarde Parameter bei 16 Bit, 1 GB bei 8 Bit und 0,5–0,6 GB bei 4 Bit, zuzüglich 10–30 %. Ein 70B-Modell mit 4 Bit braucht damit ungefähr 42–50 GB.
Die VRAM-Formel: Gewichte, KV-Cache und Overhead
Der GPU-Speicherbedarf eines LLM setzt sich aus drei Teilen zusammen, wobei der erste den größten Anteil ausmacht. Diesen LLM-VRAM-Rechner kannst du im Kopf anwenden:
- Gewichte: Parameter × Byte pro Gewicht. Ein 16-Bit-Format (FP16 oder BF16) belegt 2 Byte, ein 8-Bit-Format (INT8 oder FP8) 1 Byte. Bei 4-Bit-Formaten sind es einschließlich der gespeicherten Skalierungsfaktoren etwa 0,5–0,6 Byte.
- KV-Cache: der Attention-Zustand für jedes bereits verarbeitete Token. Er wächst mit der Kontextlänge und der Anzahl gleichzeitiger Anfragen, wie der Abschnitt zum KV-Cache weiter unten zeigt.
- Overhead: CUDA-Kontext, Aktivierungspuffer und Fragmentierung des Speicher-Allokators. Plane als Faustregel zusätzlich 10–30 % des Gewichtspeichers ein. Das ist kein garantierter Wert.
VRAM (GB) ≈ Parameter (Milliarden) × Byte pro Gewicht + KV-Cache (GB) + Overhead
Schnelle Schätzung: Gesamtbedarf ≈ Gewichte × 1,1 bis 1,3
Rechenbeispiel: Ein 70B-Modell mit 4 Bit hat 70 × 0,55 = 38,5 GB an Gewichten. Multipliziert mit 1,1–1,3 ergibt das etwa 42–50 GB. Auf einer einzelnen Karte mit 48 GB passt es bei kurzem Kontext nur knapp, auf eine Karte mit 24 GB gar nicht. Berechne den VRAM-Bedarf eines LLM auf dieselbe Weise, bevor du eine GPU mietest oder kaufst.
Hinweis zu den Einheiten: GB steht hier für 10^9 Byte, während nvidia-smi MiB (2^20 Byte) ausgibt. Rechne deshalb mit Abweichungen von bis zu etwa 7 %.
LLM-VRAM-Bedarf nach Modellgröße und Quantisierung
Die Tabelle wendet die Formel auf gängige Parameterzahlen an. Wähle die Modellgröße und Präzision aus, um den ungefähren Speicherbedarf der Gewichte abzulesen. Die Werte berücksichtigen nur die Gewichte; KV-Cache und Overhead kommen hinzu.
| Modellgröße | FP16 / BF16 | INT8 / FP8 | 4 Bit (≈ 0,55 Byte) |
| 7B | ≈ 14 GB | ≈ 7 GB | ≈ 3,9 GB |
| 8B | ≈ 16 GB | ≈ 8 GB | ≈ 4,4 GB |
| 14B | ≈ 28 GB | ≈ 14 GB | ≈ 7,7 GB |
| 32B | ≈ 64 GB | ≈ 32 GB | ≈ 18 GB |
| 70B | ≈ 140 GB | ≈ 70 GB | ≈ 38 GB |
| 120B | ≈ 240 GB | ≈ 120 GB | ≈ 66 GB |
Die Quantisierung hat den größten Einfluss. Wenn jedes Gewicht mit 8 statt 16 Bit gespeichert wird, halbiert sich der Gewichtspeicher. Mit 4 Bit sinkt er auf ungefähr ein Viertel. Dafür kann die Genauigkeit abnehmen: Bei 8 Bit ist der Verlust meist gering, bei 4 Bit und darunter eher bemerkbar. Teste ein quantisiertes Modell deshalb mit deinen eigenen Prompts. Gängige 4-Bit-Formate sind GGUF für llama.cpp, AWQ und GPTQ. Mit LLM-Quantisierung passt ein größeres Modell am günstigsten auf dieselbe Karte.
Wie die Kontextlänge den VRAM-Bedarf verändert
Der KV-Cache speichert in jeder Schicht die Key- und Value-Vektoren aller Tokens, die das Modell bereits gelesen hat. Dadurch muss es sie nicht für jedes neue Token erneut berechnen. Der Cache wächst linear mit der Kontextlänge und der Anzahl gleichzeitiger Sequenzen; seine Größe hängt außerdem von der Architektur ab. Dafür gilt folgende Formel:
KV-Cache in Byte = 2 × Schichten × kv_heads × head_dim × context_tokens × bytes_per_value
(die 2 steht für einen Key und einen Value)
Als Rechenbeispiel dient Qwen3-32B. Laut offizieller Konfiguration hat das Modell 64 Schichten, 8 KV-Heads und eine Head-Dimension von 128. Mit BF16 ergibt das 2 × 64 × 8 × 128 × 2 Byte = 262.144 Byte oder 256 KiB pro Token.
| Kontextlänge | KV-Cache (BF16) | Entspricht in GiB | Mit 8-Bit-KV-Cache |
| 4k (4.096) | ≈ 1,1 GB | 1 GiB | ≈ 0,5 GB |
| 32k (32.768) | ≈ 8,6 GB | 8 GiB | ≈ 4,3 GB |
| 128k (131.072) | ≈ 34,4 GB | 32 GiB | ≈ 17,2 GB |
Die Konfiguration von Qwen3-32B nennt nativ 40.960 Positionen. Die Zeile mit 128k zeigt daher die Skalierung des Caches und keinen unterstützten Standardwert. Der Cache ist keine vernachlässigbare Größe: Bei 128k belegt allein der BF16-Cache etwa 34 GB und damit ungefähr die Hälfte der 65,5 GB großen BF16-Gewichte.
Zwei Techniken halten den Cache in Grenzen. Bei Grouped-Query Attention (GQA) teilen sich viele Query-Heads wenige KV-Heads. Qwen3-32B hat 64 Attention-Heads, aber nur 8 KV-Heads. Sein Cache ist daher achtmal kleiner als bei vollständiger Multi-Head Attention. Außerdem kannst du den Cache selbst mit geringerer Präzision speichern: llama.cpp bietet Optionen für den Cache-Typ des K- und V-Caches, darunter q8_0. vLLM dokumentiert einen FP8-KV-Cache mit der Option –kv-cache-dtype fp8. Ein 8-Bit-Cache ist halb so groß wie ein 16-Bit-Cache.
Mixture-of-Experts-Modelle: Warum aktive Parameter nicht den VRAM bestimmen
Ein Mixture-of-Experts-Modell (MoE) leitet jedes Token nur durch wenige Experten-Subnetze. Da ein Token aber an jeden Experten weitergeleitet werden kann, müssen alle Experten im Speicher liegen. Die aktiven Parameter bestimmen den Rechenaufwand pro Token; die Gesamtzahl der Parameter bestimmt den Speicherbedarf.
gpt-oss-120b zeigt das besonders deutlich. Die Model Card nennt 117B Parameter, von denen pro Token 5,1B aktiv sind. Laut Konfiguration gibt es 128 Experten, von denen pro Token 4 verwendet werden. Die MoE-Gewichte wurden nach dem Training mit MXFP4 quantisiert. Laut Model Card passt das Modell auf eine einzelne GPU mit 80 GB. Die Checkpoint-Shards belegen zusammen etwa 65 GB und liegen damit nahe am Formelwert für ein Modell mit ungefähr 4 Bit. Mit FP16 würden 117B Parameter etwa 234 GB belegen.
Qwen3-30B-A3B-Instruct-2507 zeigt dasselbe Muster in kleinerem Maßstab: 30,5B Parameter insgesamt, davon 3,3B aktiviert, sowie 128 Experten mit 8 aktiven Experten. Das Modell braucht so viel Speicher wie ein dichtes 30B-Modell, also etwa 61 GB mit BF16 oder 17 GB mit 4 Bit. Der Rechenaufwand pro Token entspricht dagegen eher einem 3B-Modell. gpt-oss-120b hat für seine Größe ebenfalls einen kleinen KV-Cache: Die Konfiguration nennt 36 Schichten, 8 KV-Heads und eine Head-Dimension von 64. Jede zweite Schicht ist außerdem auf ein Sliding Window mit 128 Tokens begrenzt. Wie groß die Einsparung ausfällt, hängt von der Runtime ab.
Welche Modelle passen in 24, 48 und 96 GB VRAM?
Wenn du nach dem VRAM-Bedarf für LLMs gesucht hast, brauchst du in der Praxis eine passende Größenklasse. Die folgende Tabelle enthält Modelle, deren Größen aus offiziellen Model Cards oder Repositorys stammen, jeweils mit einer Präzision, bei der sie in den Speicher passen.
| GPU-Speicher | Modell und Präzision | Ungefährer Gewichtspeicher | Frei für KV-Cache und Overhead |
| 24 GB | gpt-oss-20b, MXFP4 wie veröffentlicht | Model Card: läuft mit höchstens 16 GB | ≈ 8 GB, mit Reserve |
| 24 GB | Qwen3-30B-A3B-Instruct-2507, 4 Bit | ≈ 17 GB | ≈ 7 GB, mittlere Kontextlänge |
| 24 GB | Qwen3-32B, 4 Bit | ≈ 18 GB | ≈ 6 GB, nur kurzer Kontext |
| 48 GB | Qwen3-32B, 8 Bit | ≈ 33 GB | ≈ 15 GB, 32k-Kontext passt |
| 48 GB | Qwen3-30B-A3B-Instruct-2507, 8 Bit | ≈ 31 GB | ≈ 17 GB, 32k-Kontext passt |
| 48 GB | Dichtes Modell der 70B-Klasse, 4 Bit (laut Formel) | ≈ 39 GB | ≈ 9 GB, nur kurzer Kontext |
| 96 GB | Qwen3-32B, BF16 | 65,5 GB (Repository-Größe) | ≈ 30 GB, langer Kontext oder Batching |
| 96 GB | gpt-oss-120b, MXFP4 wie veröffentlicht | ≈ 65 GB (Checkpoint-Shards) | ≈ 30 GB, langer Kontext oder Batching |
| 96 GB | Dichtes Modell der 70B-Klasse, 8 Bit (laut Formel) | ≈ 70 GB | ≈ 26 GB, 32k-Kontext passt |
Drei Muster fallen auf. Bei Modellen mit etwa 30B Parametern brauchst du auf einer 24-GB-Karte eine 4-Bit-Quantisierung; gpt-oss-20b ist die Ausnahme mit mehr Reserve. Eine 48-GB-Karte führt ein 32B-Modell mit 8 Bit und brauchbarer Kontextlänge aus. Erst mit 96 GB kannst du ein 32B-Modell in BF16 halten oder gpt-oss-120b mit zusätzlichem Speicher laden.
GPU VPS auswählen: Was in 96 GB VRAM passt
Der GPU VPS bei Contabo enthält eine dedizierte NVIDIA RTX PRO 6000 Blackwell Server Edition mit 96 GB GDDR7 sowie 18 vCPUs, 96 GB Arbeitsspeicher und 900 GB NVMe-Speicher. Laut dem Contabo Launch-Beitrag kostet er 999 € pro Monat ohne Mehrwertsteuer. Im Launch-Beitrag zum GPU VPS findest du alle technischen Daten. Der Vergleich der GPU-VPS-Preise stellt die Kosten denen anderer Anbieter gegenüber. Aus den Tabellen oben ergeben sich drei sinnvolle Konfigurationen für diese Karte:
- Ein großes Modell mit höherer Präzision: Qwen3-32B in BF16 (65,5 GB) oder gpt-oss-120b (etwa 65 GB) lässt ungefähr 30 GB für KV-Cache und Overhead frei.
- Ein mittelgroßes Modell mit langem Kontext: Qwen3-32B mit 8 Bit (etwa 33 GB) und ein 128k-BF16-KV-Cache (etwa 34 GB) belegen zusammen ungefähr 67 GB. Rund 29 GB bleiben frei. Beachte dabei die native Kontextgrenze des Modells.
- Mehrere kleine Modelle nebeneinander: Vier Modelle der 16-GB-Klasse wie gpt-oss-20b belegen etwa 64 GB. Für ihre Caches bleiben ungefähr 30 GB.
Bei einem GPU-Server für KI-Anwendungen sind die dedizierten 96 GB wichtiger als die Anzahl der vCPUs: Passen alle Gewichte in den GPU-Speicher, vermeidest du das weiter unten beschriebene langsame CPU-Offloading.
Wenn der VRAM nicht reicht: Offloading, Quantisierung und mehrere GPUs
Wenn das Modell nicht in den Speicher passt, arbeite diese Liste der Reihe nach ab:
- Reduziere die Präzision. Der Wechsel von 16 auf 8 Bit oder von 8 auf 4 Bit spart am meisten Speicher. Hier bringt die LLM-Quantisierung den größten direkten Vorteil.
- Verkürze den Kontext und quantisiere den KV-Cache. Ein kleineres Kontextfenster oder ein mit 8 Bit gespeicherter Cache gibt Speicher frei, ohne die Gewichte zu verändern.
- Lagere Schichten auf CPU und Arbeitsspeicher aus. Mit der Option -ngl kannst du in llama.cpp festlegen, wie viele Schichten auf der GPU liegen; den Rest verarbeitet die CPU. Das funktioniert, kostet aber viel Geschwindigkeit, weil der Arbeitsspeicher deutlich langsamer als GPU-Speicher ist. Für CPU-taugliche Runtimes findest du weitere Informationen in unserem Llamafile-Leitfaden und im KoboldCpp-Leitfaden.
- Verteile das Modell per Tensorparallelität auf mehrere GPUs. Dadurch steht mehr Speicher zur Verfügung, aber für eine gute Skalierung brauchst du eine schnelle Verbindung zwischen den Karten.
VRAM-Nutzung auf deinem Server prüfen
Schätzwerte sind nur der Ausgangspunkt. Miss den tatsächlichen Bedarf deshalb mit nvidia-smi. Beobachte, wie memory.used beim Laden der Gewichte und anschließend beim Reservieren des KV-Caches steigt:
nvidia-smi
nvidia-smi –query-gpu=memory.used,memory.total –format=csv -l 1
nvidia-smi –query-compute-apps=pid,process_name,used_memory –format=csv
Der erste Befehl liefert eine Momentaufnahme, der zweite protokolliert während des Ladens jede Sekunde den Speicher und der dritte listet den Speicherbedarf pro Prozess auf. Einige Inference-Server reservieren vorab einen großen Teil des GPU-Speichers. Deshalb kann memory.used auch auf einem inaktiven Server hoch erscheinen; vergleiche den Wert mit deiner Berechnung, statt ihn als Mindestbedarf anzusehen. Wenn du Container nutzt, richte zuerst die GPU ein und überwache danach die Auslastung über längere Zeit. Den vollständigen Ablauf beschreibt unser Leitfaden zur LLM-Inferenz auf einem GPU VPS.
FAQ: VRAM-Bedarf von LLMs
Wie viel VRAM brauche ich für ein 7B-Modell?
Ein 7B-Modell braucht für die Gewichte etwa 14 GB mit 16 Bit, 7 GB mit 8 Bit und rund 4 GB mit 4 Bit. Rechne für KV-Cache und Overhead 10–30 % hinzu. Ein 7B-Modell mit 4 Bit läuft daher bei moderater Kontextlänge auf einer GPU mit 8 GB.
Wie viel VRAM braucht ein 70B-Modell?
Ein 70B-Modell braucht für die Gewichte etwa 140 GB mit 16 Bit, 70 GB mit 8 Bit und rund 38,5 GB mit 4 Bit. Mit 10–30 % Overhead sind für ein 70B-Modell mit 4 Bit etwa 42–50 GB nötig. Plane daher bei kurzem Kontext eine GPU mit 48 GB oder für mehr Reserve 96 GB ein.
Reduziert Quantisierung den VRAM-Bedarf?
Ja. Bei der Quantisierung wird jedes Gewicht mit weniger Bits gespeichert. Dadurch halbiert 8 Bit den Gewichtspeicher gegenüber 16 Bit, während 4 Bit ihn auf etwa ein Viertel reduziert. Dafür kann die Genauigkeit abnehmen, meist nur geringfügig bei 8 Bit. Teste das quantisierte Modell deshalb mit deinen eigenen Aufgaben.
Kann ich ein LLM statt auf einer GPU auf der CPU ausführen?
Ja. Runtimes wie llama.cpp führen Modelle mit dem Arbeitsspeicher auf der CPU aus; für den RAM gilt dieselbe Berechnung der Gewichte. Die Geschwindigkeit ist deutlich geringer als auf einer GPU. CPU-Inferenz eignet sich daher eher für kleine Modelle, Tests und Anwendungen mit wenig Traffic als für den Produktivbetrieb.
Wie viel zusätzlichen VRAM verbraucht ein längeres Kontextfenster durch den KV-Cache?
Das hängt von der Architektur ab. Bei Qwen3-32B mit BF16 belegt der KV-Cache 256 KiB pro Token: pro Sequenz etwa 1 GB bei 4k Tokens, 8,6 GB bei 32k und 34 GB bei 128k. Ein 8-Bit-Cache halbiert diese Werte.
Hinweis: Die in diesem Artikel genannten Produktspezifikationen, Funktionen und Preise können sich ändern und je nach Region, Abrechnungszeitraum und laufender Aktion abweichen. Aktuelle Angaben, Preise und lokale Wechselkurse findest du auf der offiziellen Website des jeweiligen Anbieters oder der jeweiligen Marke.