Wie viel VRAM braucht dein LLM wirklich? Eine Berechnungsanleitung

Wenn jemand fragt wie viel VRAM er für ein bestimmtes Modell braucht, ist die ehrliche Antwort: Es kommt drauf an. Das klingt unbefriedigend, aber es stimmt. Denn der VRAM-Bedarf setzt sich aus zwei sehr unterschiedlichen Komponenten zusammen, die unterschiedlich skalieren. Die erste ist fest und vorhersagbar. Die zweite wächst mit jedem Nutzer und jedem Token den ihr verarbeitet.

Wer beide Komponenten versteht, kann seinen Bedarf auf wenige Gigabyte genau abschätzen, ohne raten zu müssen.

Die zwei Komponenten des VRAM-Bedarfs

Der Gesamtbedarf ergibt sich aus Modellgewichten plus KV-Cache plus einem kleinen Puffer für Framework-Overhead.

Modellgewichte sind die gelernten Parameter des Modells. Sie werden einmal in den VRAM geladen und bleiben dort für die gesamte Laufzeit. Diese Komponente ist statisch.

KV-Cache ist das Arbeitsgedächtnis des Modells während einer Konversation. Für jeden Token den das Modell bereits verarbeitet hat, speichert es Zwischenergebnisse, damit es sie nicht neu berechnen muss. Dieser Cache wächst mit der Länge des Gesprächs und mit der Anzahl gleichzeitiger Nutzer.

Framework-Overhead ist der Speicher den die Inference-Engine selbst braucht. CUDA-Kontext, Aktivierungen, interne Puffer. Grob 10 bis 20 Prozent der Modellgewichte als Faustformel.

Total: Modellgewichte + KV-Cache + 10-20% Overhead

Modellgewichte berechnen

Die Formel ist einfach. Man nimmt die Anzahl der Parameter in Milliarden und multipliziert mit den Bytes pro Parameter je nach Quantisierungsstufe.

Format	Bytes pro Parameter	Beispiel 70B Modell
BF16 / FP16	2,0 Bytes	ca. 140 GB
Q8	ca. 1,0 Byte	ca. 70 GB
Q4_K_M	ca. 0,5 Bytes	ca. 35 GB

Der Faktor bei Q4_K_M liegt in der Praxis eher bei 0,55 bis 0,60 weil die Komprimierung nicht gleichmäßig über alle Schichten läuft — manche Layer werden etwas weniger aggressiv quantisiert als andere. Für eine Planungsrechnung ist 0,5 Bytes pro Parameter trotzdem der richtige Ausgangspunkt.

Konkret auf unseren Modellen: MiniMax-M2.5 hat 230 Milliarden Parameter, die Q4-Datei wiegt 140 GB. Das passt zur Rechnung: 230B × 0,5 Bytes × 1,2 Overhead ≈ 138 GB. Kimi K2.5 mit 1 Billion Parametern kommt auf 621 GB in Q4, was ebenfalls stimmig ist.

Einen wichtigen Punkt dazu: Bei MoE-Modellen müssen alle Expertenschichten im VRAM liegen, auch wenn pro Token nur ein Bruchteil davon aktiv ist. Das ist ein häufiges Missverständnis. Wer denkt, dass ein MoE-Modell mit 230 Milliarden Gesamtparametern und 10 Milliarden aktiven Parametern auch nur 10 Milliarden Parameter im Speicher braucht, irrt. Nur der Rechenaufwand ist kleiner, nicht der Speicherbedarf.

KV-Cache berechnen

Das ist die Stelle wo viele Planungen schiefgehen. Der KV-Cache ist dynamisch und wächst in drei Dimensionen gleichzeitig: Kontextlänge, Anzahl der Nutzer, und Modellarchitektur.

Die Formel lautet:

KV-Cache = 2 × Layers × KV-Heads × Head-Dim × Kontextlänge × Nutzer × Bytes pro Element

Die "2" steht für Key und Value, die zwei Matrizen die das Modell für jeden Token speichert. Die Architekturwerte (Layers, KV-Heads, Head-Dim) stehen in der config.json jedes Modells und auf unserer Modellseite.

Damit man ein Gefühl für die Größenordnung bekommt, haben wir die Werte bereits als "KV/Token" vorkalkulated — das ist der Speicher pro Token und pro Nutzer in Kilobyte. Hier ein Vergleich der Modelle die wir deployen:

Modell	KV pro Token	10 Nutzer, 8K Kontext	20 Nutzer, 32K Kontext
gpt-oss-120b	72 KB	ca. 5,5 GB	ca. 44 GB
Qwen3.5-122B	96 KB	ca. 7,5 GB	ca. 59 GB
MiniMax-M2.5	248 KB	ca. 19 GB	ca. 155 GB
DeepSeek V3.2	31 KB	ca. 2,4 GB	ca. 19 GB
Kimi K2.5	31 KB	ca. 2,4 GB	ca. 19 GB
GLM-5	1.248 KB	ca. 96 GB	ca. 767 GB

Der Unterschied zwischen diesen Modellen ist enorm und erklärt sich durch die Attention-Architektur. Kimi K2.5 und DeepSeek V3.2 nutzen Multi-Head Latent Attention (MLA), eine Technik die den KV-Cache auf etwa ein Zehntel des normalen Umfangs komprimiert. Deshalb haben diese Modelle trotz enormer Gesamtparameterzahl einen sehr effizienten VRAM-Fußabdruck im Betrieb. GLM-5 hingegen hat 64 KV-Heads mit einem Head-Dim von 64, was bei 78 Layern zu einem sehr großen KV-Cache pro Token führt.

Das hat praktische Konsequenzen: Mit einem 8-GPU-System und 768 GB VRAM kann man Kimi K2.5 (621 GB Modellgewichte) laden und hat noch rund 140 GB für den KV-Cache. Das erlaubt bei 8K Kontext rund 500 gleichzeitige Nutzer. Bei GLM-5 mit demselben System wäre der KV-Cache bei 20 Nutzern und 32K Kontext bereits größer als der verfügbare Restplatz.

Ein konkretes Rechenbeispiel

Nehmen wir ein mittleres Unternehmen das MiniMax-M2.5 auf 2 bis 3 RTX PRO 6000 Blackwell einsetzen will. Die Konfiguration hat 192 bis 288 GB VRAM.

MiniMax-M2.5 in Q4 braucht 140 GB für die Modellgewichte. Für Framework-Overhead rechnen wir 20 GB. Bleiben 32 bis 128 GB für den KV-Cache.

KV pro Token: 248 KB. Bei 8K Kontext und 10 gleichzeitigen Nutzern:

248 KB × 8.000 × 10 = ca. 19 GB

Das passt problemlos. Sogar bei 20 Nutzern und 16K Kontext (ca. 38 GB KV) bleiben wir mit 3 Karten im Rahmen. Das Modell erreicht dabei über 100 Token pro Sekunde bei Single-Inference auf dieser Hardware — schneller als jede Cloud-API unter realen Bedingungen.

Was dieses Beispiel auch zeigt: Wenn man den Kontext von 8K auf 32K erhöht, vervierfacht sich der KV-Cache. Das ist der häufigste Grund warum ein Setup das bei kurzen Gesprächen funktioniert plötzlich unter Last zusammenbricht. Wer lange Dokumente analysieren will oder mehrstündige Konversationen speichert, muss den KV-Cache im Voraus einkalkulieren, nicht erst wenn der Server die erste Out-of-Memory-Meldung wirft.

Was GQA und MLA bedeuten

Ältere Modelle verwenden Multi-Head Attention (MHA), bei der jeder Query-Head seinen eigenen Key- und Value-Head hat. Das ist speicherhungrig. Neuere Modelle nutzen Grouped Query Attention (GQA), bei der sich mehrere Query-Heads einen gemeinsamen KV-Head teilen. Llama 3 zum Beispiel hat 64 Query-Heads aber nur 8 KV-Heads — der Cache schrumpft auf ein Achtel.

MLA geht noch weiter und komprimiert die KV-Matrizen in einen latenten Raum bevor sie gespeichert werden. Kimi K2.5 hat dadurch trotz 61 Layers nur 31 KB pro Token. Das macht diese Modelle besonders attraktiv für Deployments mit vielen gleichzeitigen Nutzern oder langen Kontexten.

Als Faustregel gilt: Modelle mit MLA-Architektur (aktuell DeepSeek und Kimi) sind für KV-Cache-intensive Workloads deutlich effizienter als Modelle mit klassischer GQA. Wer zum Beispiel einen Kundensupport-Bot mit langen Gesprächsverläufen betreiben will, fährt mit Kimi K2.5 oder DeepSeek V3.2 wesentlich entspannter als mit MiniMax-M2.5, selbst wenn letzteres in anderen Benchmarks ähnliche Qualität zeigt.

Wie vLLM und SGLang den Bedarf verändern

Die Wahl der Inference-Engine beeinflusst den effektiven VRAM-Bedarf, weil sie bestimmt wie effizient der KV-Cache verwaltet wird.

llama.cpp reserviert für jede Anfrage einen vordefinierten Speicherblock, auch wenn der Nutzer am Ende nur einen kurzen Satz schreibt. Ist die maximale Kontextlänge auf 32K eingestellt, wird für jeden aktiven Slot 32K × KV/Token reserviert, unabhängig von der tatsächlichen Nutzung. Das verschwendet 60 bis 80 Prozent des reservierten KV-Cache-Speichers.

vLLM und SGLang lösen das mit PagedAttention und RadixAttention. Der KV-Cache wird in kleine Seiten aufgeteilt, die dynamisch zugeteilt und nach Abschluss einer Anfrage sofort freigegeben werden. vLLM erreicht damit unter 4 Prozent Speicherverschwendung. Das bedeutet in der Praxis: Mit demselben VRAM können mehrfach so viele gleichzeitige Nutzer bedient werden wie mit llama.cpp bei gleichen Kontextlängen.

SGLang geht noch einen Schritt weiter und cached gemeinsame Prefixe automatisch. Wenn 50 Nutzer denselben System-Prompt schicken, wird der KV-Cache für diesen Prefix einmal berechnet und für alle geteilt. Bei einem internen Unternehmensassistenten mit konstantem System-Prompt kann das den effektiven KV-Cache-Bedarf deutlich reduzieren.

Für die Planung bedeutet das: Die Zahlen in der Tabelle oben gelten für naiven Betrieb ohne PagedAttention. Mit vLLM oder SGLang kann man in der Praxis mit 30 bis 50 Prozent weniger VRAM pro Nutzer kalkulieren.

Die Formel zusammengefasst

Für eine erste Abschätzung ohne tiefe Modellkenntnisse:

Schritt 1: Modellgröße in GB schätzen. Für Q4: Parameteranzahl in Milliarden × 0,5. Für Q8: × 1,0.

Schritt 2: 15 bis 20 Prozent Overhead addieren.

Schritt 3: KV-Cache addieren. Wert aus der Modellseite (KB/Token) × Kontextlänge in Tokens × Anzahl gleichzeitiger Nutzer, dann durch 1.024 × 1.024 für GB.

Schritt 4: Mit vLLM oder SGLang kann man 30 bis 40 Prozent des KV-Cache-Bedarfs abziehen.

Das Ergebnis ist der Mindestwert. In der Praxis empfehlen wir 10 bis 20 Prozent Puffer obendrauf, weil Modelle bei knappen VRAM-Budgets unter Last instabil werden können. lieber eine Karte mehr als einen nächtlichen Absturz.

Für konkrete Konfigurationsempfehlungen zu euren Modellen und Nutzerzahlen nutzt unseren Konfigurator oder schreibt uns unter office@inhausi.at. Wir rechnen das für euren Use Case kostenlos durch.