LLM-VRAM-Bedarf: Ein mathematischer Deep Dive

Die Bereitstellung von Large Language Models (LLMs) erfordert eine sorgfältige GPU-Speicherplanung. Dieser Leitfaden rechnet eine beispielhafte Inferenzschätzung für Qwen3-VL-32B-Instruct durch und bilanziert die Modellzustände beim Volltraining getrennt.

Wie viel VRAM braucht ein LLM?

Für Inferenz zählt Modellgewichte + KV-Cache + Laufzeitspeicher. Die reinen Gewichte benötigen ungefähr Parameter × Bits pro Gewicht ÷ 8 Bytes. Ein dichtes 32B-Modell braucht damit etwa 64 GB bei BF16, 32 GB bei 8 Bit oder 16 GB bei 4 Bit allein für Gewichte – vor Quantisierungsskalen, KV-Cache und Laufzeitbedarf. Das sind Schätzungen in dezimalen GB, keine Zusage, dass das Modell auf eine entsprechend große GPU passt.

Kontextlänge und parallele Sequenzen erhöhen den KV-Cache-Bedarf. Dieser Guide berechnet die Komponenten für Qwen3-VL-32B getrennt und unterscheidet Inferenz von Volltraining. Modell, GPU und Kontext kannst du direkt im LLM-VRAM-Rechner erkunden. Format-Overhead erklärt der Quantisierungs-Guide, Cache-Formeln der Artikel KV-Cache erklärt.

Warum die Berechnung des VRAM wichtig ist

Bevor Sie ein LLM bereitstellen, müssen Sie entscheidende Fragen beantworten:

• Wie viel GPU-Speicher wird mein Modell verbrauchen?
• Kann ich dieses Modell auf meiner aktuellen Hardware ausführen?
• Welche Quantisierungsmethode bietet das beste Verhältnis zwischen Speicher und Leistung?
• Wie viele gleichzeitige Nutzer kann ich unterstützen?

Dieser Leitfaden liefert die mathematische Grundlage, um diese Fragen präzise zu beantworten.

Beispielmodell: Qwen3-VL-32B-Instruct

Wir verwenden Qwen3-VL-32B-Instruct als unser Referenzmodell in diesem Leitfaden. Dieses multimodale Modell vereint Bild- und Sprachfähigkeiten mit folgender Architektur:

Konfigurationsquelle: Die Modellkonfiguration wird aus dem Abschnitt text_config der Datei config.json des Modells auf Hugging Face Hub extrahiert.

Zentrale Speicherelemente

Der VRAM-Verbrauch für LLMs besteht aus vier Hauptkomponenten:

1. Model Weights Speicher

Der Basisspeicher, der zum Speichern der Modellparameter benötigt wird.

Model Weights (bytes) = Number of Parameters × Bytes per Parameter

Bytes pro Parameter hängen vom Datentyp (Quantisierungsstufe) ab:

Beispielrechnung für Qwen3-VL-32B:

Number of Parameters: 33,357,390,064 (~33.4B)

float32:  33,357,390,064 × 4.0   = 133,429,560,256 bytes = 133.43 GB
float16:  33,357,390,064 × 2.0   = 66,714,780,128 bytes  = 66.71 GB
int8:     33,357,390,064 × 1.0   = 33,357,390,064 bytes  = 33.36 GB
int4:     33,357,390,064 × 0.5   = 16,678,695,032 bytes  = 16.68 GB

2. KV Cache Speicher

Der Key-Value Cache speichert Zwischenzustände der Attention für eine effiziente autoregressive Generierung. Dies ist die wichtigste dynamische Speichereinheit während der Inferenz.

KV Cache (bytes) = 2 × Batch Size × Sequence Length × Num Layers × Num KV Heads × Head Dimension × KV Data Type Size

Aufschlüsselung der Formel:

• 2×: Getrennter Speicher für Keys und Values
• Batch Size: Anzahl gleichzeitiger Anfragen
• Sequence Length: Maximale Kontextlänge (Eingabe + Ausgabe)
• Num Layers: Anzahl der Transformer-Blöcke
• Num KV Heads: Anzahl der Key-Value-Heads (8 für GQA in Qwen3-VL)
• Head Dimension: Größe jedes Attention-Heads (128)
• KV Data Type Size: Bytes pro Wert (typischerweise 2 für float16)

Beispielrechnung für Qwen3-VL-32B:

Szenario: 1 Nutzer, 8.192 Token-Kontext, float16 KV cache

Batch Size: 1
Sequence Length: 8,192 tokens
Num Layers: 64
Num KV Heads: 8 (Grouped Query Attention)
Head Dimension: 128
KV Data Type: float16 (2 bytes)

KV Cache = 2 × 1 × 8,192 × 64 × 8 × 128 × 2
         = 2 × 1 × 8,192 × 64 × 8 × 256
         = 2 × 1,073,741,824 bytes
         = 2,147,483,648 bytes
         = 2.15 GB (decimal; = 2.00 GiB binary)

Skalierung mit Batch-Größe:

Skalierung mit Sequenzlänge:

3. Aktivierungsspeicher

Speicher für Zwischenberechnungen während der Forward-Passes. Die folgende Formel ist eine Planungsheuristik, keine genaue Allokationsformel von PyTorch oder vLLM; Attention-Implementierung, Prefill-Chunking, Batching und temporäre Puffer verändern den Spitzenbedarf.

Illustrative Activation Reserve = Batch Size × Sequence Length × (18 × Hidden Size + 4 × Intermediate Size)

Beispielrechnung für Qwen3-VL-32B:

Scenario: 1 user, 8,192 token context

Batch Size: 1
Sequence Length: 8,192
Hidden Size: 5,120
Intermediate Size: 25,600

Activation Memory = 1 × 8,192 × (18 × 5,120 + 4 × 25,600)
                  = 8,192 × (92,160 + 102,400)
                  = 8,192 × 194,560
                  = 1,593,835,520 bytes
                  = 1.59 GB (base value)

Multiplikatoren für Datentypen:

Verschiedene Quantisierungsstufen haben unterschiedliche Aktivierungsspeicher-Bedarfe:

4. Nicht-PyTorch Speicher-Overhead

Systembedingter Speicher-Overhead für CUDA-Kontext, cuBLAS und andere Framework-Komponenten.

Illustrative Runtime Reserve ≈ 1.00 GB

Das 1 GB ist eine beispielhafte Reserve, keine feste Framework-Kostenposition. Der interaktive Rechner verwendet stattdessen 1,2 GB, skaliert mit seinem Format-Overhead-Faktor (zum Beispiel ~1,26 GB für int8). Messen Sie den tatsächlichen Runtime-Spitzenbedarf vor der Hardwarewahl.

Vollständige Inferenz-Speicherformel

Durch die Kombination aller Komponenten ergibt sich der gesamte für die Inferenz benötigte VRAM:

Total Inference VRAM = (Model Weights + KV Cache + Non-PyTorch Memory + Activations) / GPU Utilization

Kapazitätsreserve: Die Beispiele teilen durch 0,9, um 10 % VRAM freizuhalten. Das ist eine Planungsentscheidung, keine beobachtete Runtime-Auslastung.

Unterschied zum Rechner: Diese Handbeispiele nutzen rohe Nutzdaten-Bytes und eine explizite 10-%-Kapazitätsreserve. Der interaktive Rechner addiert angenommene Format-Overheads — FP8 ×1,03, INT8 ×1,05, INT4/AWQ ×1,12. Sein NVFP4-Eintrag verwendet 4,5 effektive Bits je Gewicht; die Blockskalen sind bereits enthalten. Er verwendet eine Runtime-Reserve von 1,2 GB multipliziert mit dem Formatfaktor und teilt die Kapazität nicht durch den Durchsatz-Effizienzregler. Keine der beiden Schätzungen garantiert, dass ein Checkpoint passt.

Beispiel: Qwen3-VL-32B Inferenz (int8 Quantisierung)

Konfiguration:

• Quantisierung: int8 (1 Byte pro Parameter)
• Batch-Größe: 1 user
• Sequenzlänge: 8.192 Tokens
• KV Cache Datentyp: float16
• GPU-Auslastung: 0,9

Schritt-für-Schritt-Berechnung:

1. Model Weights:
   33,357,390,064 × 1 byte = 33,357,390,064 bytes = 33.36 GB

2. KV Cache (float16):
   2 × 1 × 8,192 × 64 × 8 × 128 × 2 = 2,147,483,648 bytes = 2.15 GB

3. Activations (int8 uses 1.0× multiplier):
   1 × 8,192 × (18 × 5,120 + 4 × 25,600) × 1.0 = 1,593,835,520 bytes = 1.59 GB

4. Non-PyTorch Memory:
   ≈ 1.00 GB

5. Total (before GPU utilization adjustment):
   33.36 + 2.15 + 1.59 + 1.00 = 38.10 GB

6. Adjusted for GPU Utilization (90%):
   38.10 / 0.9 = 42.33 GB

Ergebnis: Sie benötigen ungefähr 42 GB VRAM, um Qwen3-VL-32B in int8-Quantisierung mit 8k Kontext für einen einzelnen Nutzer auszuführen.

Beispiel: Qwen3-VL-32B Inferenz (int4-Quantisierung)

Konfiguration:

• Quantisierung: int4 (0,5 Byte pro Parameter)
• Batch-Größe: 4 Nutzer
• Sequenzlänge: 8.192 Tokens
• KV Cache Datentyp: float16
• GPU-Auslastung: 0,9

Schritt-für-Schritt-Berechnung:

1. Model Weights:
   33,357,390,064 × 0.5 bytes = 16,678,695,032 bytes = 16.68 GB

2. KV Cache (float16, batch=4):
   2 × 4 × 8,192 × 64 × 8 × 128 × 2 = 8,589,934,592 bytes = 8.59 GB

3. Activations (int4 uses 1.0× multiplier, batch=4):
   4 × 8,192 × (18 × 5,120 + 4 × 25,600) × 1.0 = 6,375,342,080 bytes = 6.38 GB

4. Non-PyTorch Memory:
   ≈ 1.00 GB

5. Total (before GPU utilization adjustment):
   16.68 + 8.59 + 6.38 + 1.00 = 32.65 GB

6. Adjusted for GPU Utilization (90%):
   32.65 / 0.9 = 36.28 GB

Ergebnis: Sie benötigen ungefähr 36 GB VRAM, um Qwen3-VL-32B in int4-Quantisierung mit 8k Kontext für 4 gleichzeitige Nutzer auszuführen.

Speicherbedarf beim Training

Beim Training aller Parameter gilt eine andere Speicherbilanz als bei der Inferenz. Ein dauerhafter Inferenz-KV-Cache gehört nicht dazu: Autograd speichert oder berechnet Forward-Aktivierungen für den Backward-Pass erneut. Der Aktivierungsspeicher hängt von Attention-Kernel, Checkpointing, Microbatch-Größe und Sequenzlänge ab.

Für 33.357.390.064 trainierbare Parameter ergibt eine einfache Bilanz für Adam mit gemischter Präzision:

Das sind Gesamtsummen für Modellzustände über alle Geräte, vor Aktivierungen, temporären Puffern, Runtime-Belegungen und Sicherheitsreserve. Optimizer-Implementierung, Sharding und Auslagerung verändern die Speicherverteilung. Bei quantisiertem LoRA/QLoRA bleiben Basisgewichte eingefroren und nur kleine Adapter werden trainiert; dafür ist eine eigene Rechnung nötig: LoRA-/QLoRA-Speicherrechnung. Die nötige Gerätezahl lässt sich nicht durch einfaches Teilen dieser Summe durch den VRAM einer Karte bestimmen; das Parallelisierungsschema verteilt Gewichte, Optimizer-Zustände und Aktivierungen unterschiedlich.

Vergleichstabelle GPU Speicher

Hier finden Sie einen umfassenden Vergleich für Qwen3-VL-32B über verschiedene Quantisierungsmethoden hinweg:

Konfiguration: Batch-Größe 1, Sequenzlänge 8.192 Tokens, GPU-Auslastung 0,9

Praktische GPU-Empfehlungen

Basierend auf den obigen Berechnungen finden Sie hier geeignete GPU-Konfigurationen für Qwen3-VL-32B:

Inferenzbereitstellung

Vollständiges Training benötigt eine eigene Systemplanung für Optimizer-Zustände, Sharding, Aktivierungen und Checkpointing; der Trainingsabschnitt oben nennt die Zwischensumme für Modellzustände.

Kernpunkte

1. Modellgewichte skalieren linear: Doppelt so viele Parameter bedeuten doppelt so viel Gewichtsspeicher
2. KV-Cache skaliert mit dem Kontext: Der KV-Cache-Speicher wächst linear mit der Kontextlänge
3. Batch-Größe multipliziert den KV-Cache: Jeder gleichzeitige Nutzer erhöht den KV-Cache-Verbrauch
4. Quantisierung reduziert Speicher drastisch: int4 benötigt ~1/8 des Speichers von float32
5. Trainingsspeicher hängt von der Methode ab: Volltraining, LoRA und QLoRA haben unterschiedliche trainierbare Zustände und Aktivierungskosten.
6. Speicherreserve einplanen: Wählen Sie eine Reserve für die tatsächliche Runtime und prüfen Sie den Spitzenverbrauch auf der Hardware.

Erweiterte Überlegungen

Auswirkungen von Grouped Query Attention (GQA)

Qwen3-VL-32B verwendet Grouped Query Attention mit 8 KV Heads anstelle von 64 Query Heads. Dadurch wird der KV-Cache-Speicher im Vergleich zu standardmäßiger Multi-Head Attention um das 8-fache reduziert:

Standard MHA: 64 KV heads → KV Cache = 17.18 GB (8k context, float16)
GQA (Qwen3): 8 KV heads → KV Cache = 2.15 GB (8k context, float16)

Memory Savings: 15.03 GB (87.5% reduction)

Skalierung für langen Kontext

Qwen3-VL-32B unterstützt bis zu 262k Tokens. So skaliert der KV-Cache:

Quantisierung des KV-Caches

Die Verwendung von fp8 für den KV-Cache kann den Speicherverbrauch halbieren:

float16 KV Cache (8k, batch=1): 2.15 GB
fp8 KV Cache (8k, batch=1): 1.07 GB

Savings: 50% memory reduction with minimal quality loss

Fazit

Eine genaue Berechnung des VRAM ist entscheidend für eine effiziente Bereitstellung von LLMs. Durch das Verständnis der mathematischen Grundlagen:

1. Wählen Sie die richtige Quantisierung für Ihren Qualitäts-Speicher-Kompromiss
2. Planen Sie die Skalierung des KV-Cache bei gleichzeitigen Nutzern und Kontextlänge
3. Berücksichtigen Sie Trainings-Overhead bei Feinabstimmung
4. Wählen Sie geeignete GPUs aus basierend auf den tatsächlichen Anforderungen
5. Berücksichtigen Sie immer Sicherheitsmargen, um OOM-Fehler zu vermeiden

Verwenden Sie diese Formeln, um die Speicheranforderungen für jedes Hugging Face Modell abzuschätzen, indem Sie die Konfigurationsparameter extrahieren und die in diesem Leitfaden gezeigten Berechnungen anwenden.

Verwandte Artikel

• LLM-Inferenz-Mathematik: Theorie trifft Hardware — die Compute-Seite derselben Roofline.
• LLM-Inferenzrechner & Break-Even-Analyse — rechnen Sie mit Ihrem Modell und Ihrer Karte.

Referenzen und Werkzeuge

• Modellkonfiguration: Qwen3-VL-32B-Instruct config.json
• Hugging Face Hub: Modell-Metadaten und Parameteranzahl über die API verfügbar
• GPU-Spezifikationen: Prüfen Sie die Herstellerangaben für genaue VRAM-Kapazitäten
• Quantisierungsverfahren: GPTQ, AWQ, GGUF für verschiedene Präzisionsstufen