GPU und VRAM für LLMs richtig dimensionieren

Wie viel VRAM braucht Ihr Modell, und welche GPU passt dazu?

Den Managed GPU Server gibt es in zwei festen Größen: mit 24 GB VRAM für 699 € netto im Monat und mit 96 GB VRAM für 1.799 € netto im Monat, jeweils zzgl. einmaliger Einrichtung und mit Modell, vLLM, Open WebUI und Betrieb. Für größere Modelle gibt es Server mit zwei, drei oder vier RTX PRO 6000 (192 bis 384 GB) auf Anfrage. Für Teams im eigenen Netz bietet der AI Cube 128 GB Unified Memory.

Managed GPU Server ansehen · Auslegung gemeinsam klären

„Passt dieses Modell auf meine GPU?" ist die praktische Kernfrage beim Aufbau lokaler KI - und sie lässt sich rechnen. Der VRAM-Bedarf eines Sprachmodells setzt sich aus drei Komponenten zusammen, und wer nur die Modellgröße betrachtet, verschätzt sich regelmäßig. Dieser Artikel zeigt die Faustregeln, die Formel für den KV-Cache mit Rechenbeispielen zur Kontextlänge und die Wirkung eines FP8-KV-Cache. Modellangaben Stand Oktober 2026.

Inhaltsverzeichnis

• Drei Speicher-Komponenten
• Modellgewichte: die Faustregel
• Der KV-Cache: oft der Engpass
• KV-Cache und Kontextlänge berechnen
• FP8-KV-Cache: doppelt so viel Kontext
• Overhead und die Gesamtrechnung
• Ein Rechenbeispiel

Drei Speicher-Komponenten

Der VRAM-Bedarf eines Sprachmodells im Betrieb hat drei Teile (Kwon et al., PagedAttention):

1. Modellgewichte - der Speicher für die Parameter des Modells.
2. KV-Cache - Zwischenwerte der Attention während der Generierung.
3. Overhead - Aktivierungen, Framework und CUDA-Kontext.

Nur alle drei zusammen ergeben den realen Bedarf. Der häufigste Fehler ist, allein von den Gewichten auszugehen und den KV-Cache zu unterschätzen.

Modellgewichte: die Faustregel

Der Speicher für die Gewichte folgt aus Parameterzahl und Zahlenpräzision. Die praktische Faustregel:

• FP16 (volle Präzision): rund 2 GB VRAM je Milliarde Parameter.
• 4-Bit-Quantisierung (AWQ, GPTQ): rund 0,5 GB je Milliarde Parameter.

Ein 70-Milliarden-Modell braucht damit bei FP16 etwa 140 GB - mehr, als eine einzelne 80-GB-Karte (H100, A100) fasst. Quantisiert auf 4 Bit sinkt der reale Bedarf auf rund 40 bis 45 GB und passt auf eine 80-GB-GPU. Quantisierung ist deshalb der wichtigste Hebel, um große Modelle auf verfügbare Hardware zu bringen - meist mit nur geringem Qualitätsverlust. Welche Formate (FP8, NVFP4, AWQ, GPTQ, GGUF) zu welcher Hardware passen, vertieft der Artikel LLM-Quantisierung.

Der KV-Cache: oft der Engpass

Der KV-Cache ist der am häufigsten übersehene Posten. Er speichert die Attention-Zwischenwerte während der Generierung, und sein Bedarf wächst linear mit der Sequenzlänge und der Zahl gleichzeitiger Anfragen - nicht mit der Modellgröße.

Das hat eine wichtige Konsequenz: Bei kurzem Kontext dominieren die Gewichte den Speicherbedarf. Bei langem Kontext und vielen parallelen Nutzern wird der KV-Cache zum eigentlichen Engpass und kann mehr Speicher belegen als die quantisierten Gewichte. Das effiziente Speichermanagement von vLLM (PagedAttention) verhindert, dass reservierter, aber ungenutzter Cache verloren geht (Kwon et al.). Den Bedarf selbst senkt es nicht; dafür sorgen kürzere Kontexte, weniger Parallelität oder ein quantisierter KV-Cache.

KV-Cache und Kontextlänge berechnen

Der KV-Cache lässt sich aus der config.json eines Modells exakt berechnen. Für jedes Token speichert jede Attention-Schicht einen Key- und einen Value-Vektor je KV-Head:

KV-Cache je Token = 2 × Attention-Layer × KV-Heads × Head-Dimension × Byte je Wert

KV-Cache gesamt = KV-Cache je Token × Kontextlänge × gleichzeitige Sitzungen

Byte je Wert sind 2 bei FP16/BF16 und 1 bei FP8. Entscheidend ist die Zahl der KV-Heads, nicht die der Attention-Heads: Moderne Modelle nutzen Grouped-Query Attention, bei der sich mehrere Query-Heads ein Key-Value-Paar teilen.

Die Werte gelten je Sitzung. Zehn Nutzer, die gleichzeitig mit 32.768 Token Kontext arbeiten, brauchen bei Qwen3-32B also 80 GiB Cache in FP16. Das ist mehr als die Gewichte des Modells in FP8 (rund 33 GB bei 32,8 Milliarden Parametern, Model Card).

Hybride Modelle verschieben die Rechnung. Qwen3.8-27B wechselt in 16 Blöcken je drei Layer mit linearer Attention (Gated DeltaNet) und einen Layer mit klassischer Attention ab. Nur die 16 klassischen Layer legen einen wachsenden KV-Cache an; die linearen Layer halten einen festen Zustand je Sitzung, der nicht mit der Kontextlänge wächst. Ähnlich arbeitet gpt-oss-120b mit abwechselnd voller Attention und einem gleitenden Fenster von 128 Token. Für solche Modelle zählen in der Formel nur die Layer mit voller Attention.

Ein Beispiel auf 96 GB. vLLM belegt standardmäßig 92 Prozent des GPU-Speichers (Engine-Argumente, --gpu-memory-utilization), auf einer 96-GB-Karte also rund 88 GB. Nach rund 33 GB für Qwen3-32B in FP8 und einigen GB für Aktivierungen und CUDA-Graphen bleiben grob 50 GB für den Cache. Bei 256 KiB je Token sind das rund 200.000 Token, also etwa sechs gleichzeitige Sitzungen mit vollem 32k-Kontext. Mit FP8-KV-Cache verdoppelt sich der Wert. Die tatsächliche Zahl meldet vLLM beim Start im Log als verfügbaren KV-Cache-Speicher und maximale Parallelität.

Ein Beispiel auf 24 GB. Qwen3.8-27B mit 4-Bit-Gewichten belegt grob 14 bis 16 GB. Von rund 22 GB nutzbarem Speicher bleiben damit etwa 5 GB für den Cache, bei 64 KiB je Token rund 80.000 Token. Ein klassisches Modell mit 256 KiB je Token käme auf denselben 5 GB nur auf rund 20.000 Token.

FP8-KV-Cache: doppelt so viel Kontext

Der KV-Cache kann unabhängig von den Gewichten quantisiert werden. vLLM unterstützt dafür FP8 in den Varianten fp8_e4m3 und fp8_e5m2; aktiviert wird es mit --kv-cache-dtype fp8 (vLLM: Quantized KV Cache). Ein Wert belegt dann 1 statt 2 Byte, der Cache je Token halbiert sich.

Zwei Punkte gehören in die Planung:

• Die Genauigkeit ist zu prüfen, nicht anzunehmen. Die vLLM-Dokumentation nennt keine pauschale Qualitätszahl. Vor dem Produktivbetrieb gehört ein Vergleich mit festen Testfragen dazu, wie im Artikel RAG-Qualität messen beschrieben.
• FP8-KV-Cache ist keine Gewichtsquantisierung. Ein Modell in BF16 bleibt in BF16; nur die Zwischenwerte der Attention werden kompakter gespeichert. Gewichtsformate wie FP8, NVFP4 oder AWQ behandelt der Artikel LLM-Quantisierung.

Reicht auch der quantisierte Cache nicht, bleiben kürzere Kontextgrenzen (--max-model-len), weniger gleichzeitige Sitzungen (--max-num-seqs) oder die Verteilung auf mehrere GPUs, wie sie der Artikel Multi-GPU-Inferenz ohne NVLink beschreibt.

Overhead und die Gesamtrechnung

Auf die Summe aus Gewichten und KV-Cache kommt ein Overhead von rund 15 bis 20 Prozent für Aktivierungen, Framework und CUDA-Kontext. Die Gesamtrechnung lautet also:

VRAM ≈ (Gewichte + KV-Cache) × 1,15 bis 1,2

Wer diesen Puffer weglässt, riskiert Out-of-Memory-Abbrüche unter Last - genau dann, wenn viele Nutzer gleichzeitig anfragen.

Ein Rechenbeispiel

Ein mittelgroßes Modell mit 8 Milliarden Parametern, betrieben in FP16 für einige gleichzeitige Nutzer mit moderatem Kontext:

• Gewichte: 8 × 2 GB = 16 GB.
• KV-Cache: je nach Kontext und Parallelität grob 2 bis 6 GB.
• Overhead: rund 15 bis 20 Prozent obendrauf.

Ergebnis: etwa 22 bis 26 GB - passt auf eine 24-GB-Karte, wenn Kontext und Parallelität moderat bleiben, sonst besser eine größere GPU. Dasselbe 8-Milliarden-Modell quantisiert (4 Bit) käme mit rund 4 GB Gewichten aus und ließe deutlich mehr Raum für Cache und Nutzer.

Die Wahl von Modell, Quantisierung und GPU hängt damit unmittelbar zusammen - Welches LLM selbst hosten? ordnet die Modellseite ein, Was ist lokale KI? das Gesamtbild. Welche Hetzner GPU-Server welche VRAM-Größe bieten und was ein GB VRAM dort kostet, zeigt der Hetzner GPU-Server Vergleich. Die Managed GPU-Server von WZ-IT gibt es mit 24 GB (NVIDIA RTX PRO 4000 Blackwell) und 96 GB GPU-Speicher (RTX PRO 6000 Blackwell Max-Q); den Modell-Fit für Kontext und Parallelität prüfen wir vor der Bereitstellung.