VRAM-Guide: Wie viel GPU-Speicher braucht Ihr KI-Modell?
Wie viel VRAM ein KI-Modell braucht, hängt vor allem von drei Größen ab: Anzahl der Parameter, Genauigkeit der Gewichte und Länge des Kontexts. Als Richtwert für Inference gilt: rund 2 GB GPU-Speicher pro Milliarde Parameter in FP16, rund 1 GB in 8-Bit und etwa 0,5 bis 0,6 GB in 4-Bit – plus Reserve für KV-Cache und Laufzeit.
VRAM-Bedarf berechnen: die Faustregel
Der Speicherbedarf der Modellgewichte lässt sich einfach abschätzen:
VRAM für Gewichte ≈ Parameter (in Milliarden) × Bytes pro Parameter
| Genauigkeit | Bytes pro Parameter | Beispiel 8B-Modell |
|---|---|---|
| FP16 / BF16 | 2 | ca. 16 GB |
| FP8 / INT8 | 1 | ca. 8 GB |
| 4-Bit (AWQ, GPTQ, GGUF Q4) | ca. 0,5–0,6 | ca. 4–5 GB |
Dazu kommen drei Posten, die in der Praxis oft unterschätzt werden:
- KV-Cache: Zwischenspeicher für den bisherigen Kontext jeder laufenden Anfrage. Er wächst linear mit Kontextlänge und Anzahl paralleler Anfragen.
- Aktivierungen und Laufzeit: CUDA-Kontext, Framework-Overhead, temporäre Puffer – grob 1 bis 3 GB.
- Reserve: Planen Sie 10 bis 20 Prozent Luft ein. Ein Modell, das „gerade so“ passt, läuft im Betrieb selten stabil.
Der KV-Cache: warum Kontextlänge teuer ist
Bei Modellen mit Grouped-Query-Attention lässt sich der KV-Cache pro Token so abschätzen:
2 × Anzahl Layer × Anzahl KV-Heads × Head-Dimension × Bytes pro Wert
Für ein Modell der 8B-Klasse (z. B. Llama 3.1 8B mit 32 Layern, 8 KV-Heads, Head-Dimension 128) ergibt das in FP16 rund 128 KB pro Token. Ein Kontext von 8.000 Token belegt damit etwa 1 GB – pro gleichzeitiger Anfrage. Bei einem Modell der 70B-Klasse sind es rund 320 KB pro Token; 32.000 Token Kontext bedeuten dann etwa 10 GB zusätzlich.
Die Konsequenz: Ein Modell für einen Nutzer mit kurzem Kontext braucht deutlich weniger Speicher als derselbe Dienst für 20 Mitarbeitende mit langen Dokumenten im RAG-Betrieb. Inference-Server wie vLLM verwalten den KV-Cache effizient und nutzen freien VRAM gezielt für mehr parallele Anfragen – mehr dazu im Beitrag KI-Inference optimieren: Latenz und Throughput.
Richtwerte für verbreitete Modellgrößen
Die folgenden Werte beziehen sich nur auf die Gewichte und sind Richtwerte. Kontext und Parallelität kommen hinzu.
| Modellgröße (Beispiele) | 4-Bit | 8-Bit | FP16 |
|---|---|---|---|
| 7–8B (z. B. Llama 3.1 8B, Mistral 7B, Qwen-Modelle dieser Klasse) | ca. 4–5 GB | ca. 8 GB | ca. 16 GB |
| 12–14B | ca. 7–9 GB | ca. 14 GB | ca. 28 GB |
| 24–32B | ca. 14–19 GB | ca. 26–34 GB | ca. 50–65 GB |
| Mixture-of-Experts ~47B gesamt (z. B. Mixtral 8x7B) | ca. 24–28 GB | ca. 47 GB | ca. 94 GB |
| 70B (z. B. Llama 3.3 70B) | ca. 40–43 GB | ca. 70 GB | ca. 140 GB |
Wichtig bei Mixture-of-Experts-Modellen: Pro Token ist nur ein Teil der Parameter aktiv, im Speicher liegen müssen aber alle. Für die VRAM-Planung zählt daher die Gesamtparameterzahl.
Welche GPU für welches Modell?
Übertragen auf unsere beiden Konfigurationen ergibt sich folgendes Bild:
- Verda GPU S (NVIDIA RTX 4000 SFF Ada, 20 GB): Modelle der 7–8B-Klasse in 8-Bit oder 4-Bit mit komfortablem Kontext, Modelle bis etwa 14B in 4-Bit. Ein 8B-Modell in FP16 passt rechnerisch, lässt aber kaum Platz für KV-Cache und parallele Nutzer. Außerdem gut geeignet für Embedding-Modelle, Reranker und Vision-Workloads.
- Verda GPU L (NVIDIA RTX PRO 6000 Blackwell, 96 GB): Modelle der 70B-Klasse in 4-Bit mit viel Raum für KV-Cache und parallele Anfragen, 70B in 8-Bit mit knapperem Kontext, mittlere Modelle in voller Genauigkeit sowie Fine-Tuning mit LoRA/QLoRA.
Was die beiden Klassen kosten und wovon der Preis abhängt, zeigt die Übersicht KI-Server Preise und Kosten. Einen ausführlichen Vergleich der beiden Karten finden Sie unter NVIDIA RTX 4000 vs. RTX PRO 6000. Welche Modelle sich für den Unternehmenseinsatz eignen, beleuchtet der Open-Source-LLM-Vergleich.
Training und Fine-Tuning: der VRAM-Multiplikator
Beim Training liegen neben den Gewichten auch Gradienten, Optimizer-Zustände und Aktivierungen im Speicher. Als grobe Orientierung:
- Full Fine-Tuning: mit gängigen Optimizern ein Vielfaches des Inference-Bedarfs – für mittelgroße und große Modelle meist nur mit mehreren GPUs realistisch.
- LoRA: Basismodell eingefroren, nur kleine Adapter werden trainiert. Bedarf liegt etwas über dem Inference-Bedarf in derselben Genauigkeit.
- QLoRA: Basismodell in 4-Bit, Adapter in höherer Genauigkeit. Damit lassen sich Modelle der 70B-Klasse auf einer einzelnen 96-GB-GPU feinjustieren.
Praktische Details beschreibt der Beitrag Fine-Tuning auf dem eigenen GPU-Server.
VRAM sparen: bewährte Techniken
- Quantisierung: 4-Bit-Verfahren wie AWQ oder GPTQ reduzieren den Speicherbedarf der Gewichte gegenüber FP16 um rund drei Viertel, bei meist moderatem Qualitätsverlust. Testen Sie die Qualität mit Ihren eigenen Aufgaben.
- FP8 und FP4: Neuere GPU-Generationen beschleunigen niedrige Genauigkeiten in Hardware – die Ada-Generation unterstützt FP8, Blackwell zusätzlich FP4.
- KV-Cache-Quantisierung: Speichert den Kontext in 8-Bit und verdoppelt so annähernd die nutzbare Kontextmenge.
- Flash Attention: Senkt den Speicherbedarf der Attention-Berechnung bei langen Kontexten deutlich.
- Gradient Checkpointing: Tauscht beim Training Speicher gegen Rechenzeit.
- Kontext begrenzen: Wer die maximale Kontextlänge an den tatsächlichen Bedarf anpasst, gewinnt oft mehr als durch jede andere Maßnahme.
Häufige Planungsfehler
- Nur die Gewichte rechnen und KV-Cache sowie parallele Nutzer vergessen
- Die maximal mögliche Kontextlänge des Modells einstellen, obwohl 8.000 oder 16.000 Token genügen
- Quantisierung pauschal ablehnen, statt die Qualität am eigenen Anwendungsfall zu prüfen
- Keine Reserve für Embedding-Modell oder Reranker einplanen, die im RAG-Betrieb auf derselben GPU laufen
Häufige Fragen
Wie viel VRAM braucht ein 70B-Modell?
Reichen 20 GB VRAM für ein lokales LLM?
Verschlechtert Quantisierung die Antwortqualität?
Kann ich VRAM mehrerer GPUs zusammenlegen?
Verwandte Artikel
vLLM vs. Ollama vs. TGI: Inference-Frameworks für GPU-Server in der Praxis
vLLM, Ollama oder TGI? Stärken, Grenzen und Projektstatus der Inference-Frameworks – plus eine Methodik für aussagekräftige eigene GPU-Benchmarks.
Monitoring und Observability für KI-Workloads
Monitoring für KI-Workloads: welche GPU- und LLM-Metriken zählen, wie DCGM, Prometheus und Grafana zusammenspielen und welche Alerts sinnvoll sind.
On-Premise vs. Cloud GPU: Was ist die richtige Wahl für Ihr Unternehmen?
On-Premise, Cloud GPU oder Managed Dedicated Server? Kosten, Datenschutz, Betrieb und Flexibilität im Vergleich – Entscheidungshilfe für den Mittelstand.