Wie viel VRAM ein LLM braucht: Formeln und Tabellen

Woraus das Speicherbudget besteht

NVIDIAs NIM-Engine beansprucht einen gpu_memory_utilization-Anteil der Karte (Standard 0,9) und verteilt darin: Gewichte, Overhead, Aktivierungsspitzen und den KV-Cache. Der Cache wird gierig alloziert – „er dehnt sich in den gesamten verbleibenden Platz aus“. Die Zahl paralleler Nutzer ist also keine Einstellung. Sie ist ein Rest.

Gewichte: eine einzige Multiplikation

Offizielle Formel: Gewichtsspeicher pro Karte = Parameter × Bytes pro Parameter / TP (Tensor-Parallel-Kartenzahl). Bytes pro Parameter: 2 für BF16/FP16, 1 für FP8, 0,5 für INT4 und NVFP4 (reale NVFP4-Checkpoints landen eher bei 0,56, sobald die Block-Skalierungen und die unquantisierten Embeddings mitzählen: NVIDIAs FP4-Datei von Llama 3.3 70B hat 42,7 GB).

KV-Cache – und warum ein 7B mehr frisst als ein 70B

Die zweite Hälfte der Rechnung: Das Modell speichert Keys und Values für jedes gelesene Token. Formel: 2 × Layer × KV-Heads × Head-Dimension × Bytes pro Wert, pro Token (KV-Heads, nicht Attention-Heads: Llama 3 70B hat 64 Attention-Heads, aber nur 8 KV-Heads); das Volumen wächst linear mit Sequenzlänge und parallelen Anfragen.

Der kontraintuitive Teil: Das 7B mit alter Multi-Head-Attention verbraucht 512 KB pro Token, das 70B mit Grouped-Query-Attention 320 KB. Zehnfaches Modell, 38% weniger Cache. „Wie viel Kontext passt“ folgt nicht aus der Parameterzahl. Beide Tabellen addiert: Ein 70B in FP16 mit 128K-Kontext sind 140 GB Gewichte + 40 GB Cache – 180 GB für eine Person.

Der Overhead, den man nur in Logs sieht

CUDA-Graph-Capture nimmt nach NVIDIAs eigener Schätzung „1 bis 5 GB je nach GPU-Architektur und Modellgröße“. Und eine Falle, die es nie auf eine Folie schafft: Bei manchen Profilen „passiert die FP8-Quantisierung on the fly, d. h. die BF16-Gewichte müssen zuerst in den Speicher“ – acht Bit sparen Speicher bei der Inferenz, aber der Start verlangt BF16-großen Platz. Prüfen Sie das konkrete Profil vor dem Kauf.

Karte × Modell × Kontext × Nutzer

Methode: Kartenkapazität × 0,9, minus Gewichte, minus ~2 GB für Graphs und Aktivierungen; den Rest durch den Cache einer Session teilen. Das sind Speicher-Obergrenzen – und wenn die Plätze virtuelle Desktops statt einer API sind, zählen MIG und vGPU anders. Die Latenz kürzt sie weiter.

8B-Klasse, FP8-Gewichte (8 GB), FP16-KV-Cache mit 128 KB/Token (ein FP8-Cache halbiert ihn und verdoppelt jede Zahl) – parallele Sessions:

70B-Klasse mit GQA, Cache 320 KB/Token:

Sehen Sie sich die 48-GB-Zeile an: Die Karte „hält“ ein 70B in vier Bit technisch, aber nur 6,2 GB überleben die Gewichte – zwei Sessions mit 8K Token, und ein einziger 32K-Kontext passt gar nicht.

Was echte Messungen hinzufügen

Die Arithmetik liefert die Speicher-Obergrenze; die Latenz bestimmt das Erlebnis. NVIDIAs eigene NIM-Benchmark-Zahlen (NIM 1.8.0) für Llama 3.1 8B auf einer H100 80 GB:

Bei 20.000 Token Eingabe dauert das erste Token deutlich über vier Minuten: Der Dienst lebt technisch – und niemand wird ihn benutzen. Der direkteste Hebel ist die Promptlänge: NIMs eigenes Log liefert die Zahl – Kontext auf 4.096 gekürzt machte im dokumentierten Beispiel 15,1 GB frei.

Cache-Quantisierung: Behauptung vs. Messung

NVIDIAs NVFP4-KV-Cache in TensorRT-LLM senkt den Cache-Speicher gegenüber FP8 um bis zur Hälfte und verbessert in NVIDIAs Szenarien mit langem Kontext und Cache-Wiederverwendung die Zeit bis zum ersten Token um bis zu 3× – bei kleinem Genauigkeitsverlust (MMLU-Pro auf Qwen3-480B: 78,2% BF16 → 77,4% NVFP4); er kam zuerst auf der B200-Klasse, prüfen Sie also den Support für Ihre Karte. Das Format allein garantiert nichts: Dieselbe Idee in llama.cpp (ein q4_0-KV-Cache) auf Unified Memory ließ im Test eines Besitzers das Prompt-Tempo von 282,7 auf 21,3 Tok/s einbrechen, weil dieser Pfad keine fusionierten Kernel hatte. Hardware-beschleunigtes NVFP4 in TensorRT-LLM gewinnt; Software-Entpacken verliert. Engine und Silizium liefern den Nutzen, nicht das Format.

Was wir liefern

Eurokommerz liefert die gesamte Reihe EU-weit auf Bestellung: RTX PRO 4500 (32 GB) für Modelle bis 13B, RTX PRO 5000 (48 / 72 GB) für 8–13B mit langem Kontext, RTX PRO 6000 (96 GB) für ein 70B in FP8 auf einer Karte, und H200 NVL (141 GB HBM3e) für 70B-Serving mit langem Kontext im großen Maßstab.

FAQ