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.

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 × (Heads × Head-Dimension) × Bytes pro Token; 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 (8 GB Gewichte), Cache 128 KB/Token — 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 Zahlen für Llama 3.1 8B auf einer H100:

Bei 20.000 Token Eingabe dauert das erste Token fast fünf 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

NVFP4-Cache braucht rund die Hälfte des FP8-Speichers bei bis zu 3× niedrigerer Latenz und kleinem Genauigkeitsverlust (MMLU-PRO: 78,2% BF16 → 77,4% NVFP4). Aber das Format allein garantiert nichts: Dieselbe Idee in llama.cpp (q4_0) auf Unified Memory wurde 6% größer als f16 und ließ das Prompt-Tempo von 282,7 auf 21,3 Tok/s einbrechen. 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