Wie viel VRAM ein LLM braucht: Formeln und Tabellen

Das VRAM-Budget: Gewichte, KV-Cache und Overhead

Ein LLM braucht VRAM für seine Gewichte, für den KV-Cache jeder gleichzeitigen Session und für 1 bis 5 GB CUDA-Graphs: Ein 70B-Modell belegt in FP8 schon ohne Cache 70 GB, und ein Gespräch mit 128K-Kontext auf Llama 3.1 70B braucht weitere 40 GiB. NVIDIAs NIM-Engine reserviert einen Anteil der Karte, den gpu_memory_utilization festlegt, laut der Speicherdokumentation von NIM 2.0 vom April 2026 standardmäßig 0,9 (vLLM selbst nutzt seit seinem Release 0.20.0 aus demselben Monat standardmäßig 0,92). In diesem Anteil liegen die Gewichte, der Overhead, die Aktivierungsspitzen und der KV-Cache. Der Cache wird gierig alloziert: „er dehnt sich in den gesamten verbleibenden Platz aus“. Die Zahl gleichzeitiger Nutzer hängt deshalb davon ab, wie viel Speicher nach den Gewichten und dem Overhead übrig bleibt. Wir liefern die NVIDIA-Karten, die dieser Leitfaden durchrechnet, und bauen KI-Server mit ihnen auf Bestellung. Nennen Sie uns Modell und Nutzerzahl, unser Team hilft Ihnen weiter.

Gewichtsspeicher: Parameter × Bytes pro Parameter

Die Formel in NVIDIAs NIM-Dokumentation lautet Gewichtsspeicher pro Karte = Parameter × Bytes pro Parameter / TP, wobei TP die Zahl der Karten im Tensor-Parallelismus ist. Ein Parameter belegt 2 Bytes in BF16/FP16, 1 in FP8 und in 4-Bit-Formaten ein halbes Byte plus seine Skalierungen, also 0,5625 Bytes pro NVFP4-Gewicht einschließlich der Block-Skalierungen. Ganze Checkpoints liegen höher, weil Embeddings und Ausgabeschicht in 16 Bit bleiben: NVIDIAs NVFP4-Checkpoint von Llama 3.3 70B hat 42,7 GB, etwa 0,61 Bytes pro Parameter, und ein INT4-AWQ-Checkpoint von Llama 3.1 70B etwa 39,8 GB. NVIDIAs FP8-Checkpoint desselben 70B-Modells hat aus demselben Grund 72,7 GB.

Bei einem Mixture-of-Experts-Modell zählen alle Parameter, nicht nur die aktiven: Jeder Experte bleibt im GPU-Speicher. gpt-oss-120b hat 117 Milliarden Parameter, davon 5,1 Milliarden je Token aktiv, und sein Checkpoint mit den Experten in MXFP4 hat 65,3 GB. Die aktiven Parameter bestimmen, wie viele Bytes jedes Token liest, und damit die Geschwindigkeit, wie unser Artikel zu Gesamt- und aktiven Parametern bei MoE erklärt.

KV-Cache pro Token für 7B-, 8B- und 70B-Modelle

Der zweite Teil des Speicherbudgets ist der KV-Cache, in dem das Modell Keys und Values für jedes gelesene Token speichert. Pro Token belegt er 2 × Layer × KV-Heads × Head-Dimension × Bytes pro Wert. Die Formel rechnet mit KV-Heads und nicht mit Attention-Heads: Llama 3 70B hat 64 Attention-Heads, aber nur 8 KV-Heads. Der Cache wächst linear mit der Sequenzlänge und mit der Zahl paralleler Anfragen.

Llama 2 7B unterstützt 4.096 Token, seine Werte für 32K und 128K sind also reine Rechnung.

Das 7B-Modell mit der älteren Multi-Head-Attention braucht 512 KiB Cache pro Token, das 70B-Modell mit Grouped-Query-Attention 320 KiB. Das 70B-Modell ist zehnmal so groß und braucht 38 Prozent weniger Cache; wie viel Kontext passt, lässt sich also nicht an der Parameterzahl ablesen. Beide Tabellen zusammengenommen braucht ein 70B-Modell in FP16 mit 128K-Kontext 131 GiB für die Gewichte plus 40 GiB Cache, etwa 171 GiB für einen Nutzer.

Overhead: CUDA-Graphs und FP8-Profile, die BF16-Gewichte laden

CUDA-Graph-Capture belegt nach NVIDIAs Schätzung in der Speicherdokumentation von NIM 2.0 „1 bis 5 GB je nach GPU-Architektur und Modellgröße“. Manche Profile brauchen außerdem beim Start mehr Speicher als im Betrieb. In einem vLLM-FP8-Profil von NVIDIAs Vision-Language-NIM etwa „erfolgt die FP8-Quantisierung zur Laufzeit, was bedeutet, dass die BF16-Gewichte zuerst in den Speicher geladen werden müssen“. Ein solches Profil spart bei der Inferenz Speicher, braucht beim Start aber Platz für BF16-Gewichte; prüfen Sie deshalb das konkrete Profil vor dem Kauf.

Gleichzeitige Nutzer pro Karte für 8B- und 70B-Modelle

Die Tabellen verwenden unsere Regel für Nutzer je Karte, wie auch unser Leitfaden dazu, wie viele Nutzer eine RTX PRO 6000 bedient. Sie nehmen 90 Prozent des Kartenspeichers, ziehen die Gewichte und etwa 3 GiB pro Karte für CUDA-Graphs und Aktivierungen ab und teilen den Rest durch den Cache einer Session. Als Kartenspeicher zählt, was der Treiber meldet, 95,6 GiB bei einer 96-GB-Karte und 140,4 GiB bei der H200 NVL, bei den übrigen Karten die Nennkapazität, als GiB gerechnet und damit etwas mehr, als ihre Treiber melden; die Gewichte sind die veröffentlichten Checkpoints. NVIDIAs CUDA Best Practices Guide nennt für GDDR-Speicher mit aktiviertem ECC 6,25 Prozent weniger nutzbare Kapazität; für die GDDR7-Karten der RTX PRO Blackwell veröffentlicht NVIDIA keinen Wert. Wir rechnen, wo wir ihn kennen, mit dem Speicher, den der Treiber meldet (nvidia-smi, FB Memory Total); prüfen Sie ihn auf Ihrer Karte in dem ECC-Modus, den Sie betreiben. Das sind Speicher-Obergrenzen; die Latenz senkt sie weiter, und wenn die Plätze virtuelle Desktops statt einer API sind, zählen MIG und vGPU anders.

8B-Klasse, FP8-Gewichte mit 8,5 GiB (NVIDIAs Checkpoint mit 9,1 GB), FP16-KV-Cache mit 128 KiB pro Token (ein FP8-Cache halbiert ihn und verdoppelt jede Zahl), parallele Sessions:

70B-Klasse mit GQA, Cache 320 KiB pro Token; Gewichte aus NVIDIAs Checkpoints von Llama 3.3 70B, 39,8 GiB (42,7 GB) in NVFP4 und 67,7 GiB (72,7 GB) in FP8:

Auf der RTX PRO 5000 mit 48 GB lässt ein 70B-Modell keinen Platz für auch nur eine Session. NVIDIAs Vier-Bit-Checkpoint hat 42,7 GB, also 39,8 GiB, und passt gerade noch in die 43,2 GiB, die ein Anteil von 0,9 der Karte zulässt. Nach etwa 3 GiB für CUDA-Graphs und Aktivierungen bleiben 0,4 GiB, weniger als die 2,5 GiB einer 8K-Session.

Mit mehreren Karten im Tensor-Parallelismus verteilen sich die Gewichte auf die Karten, und der Cache addiert sich, weil Llama 3.3 70B acht KV-Heads hat. Nach derselben Regel halten zwei RTX PRO 6000 eine FP8-Kopie des 70B-Modells und lassen 98,4 GiB für den Cache frei, 39 Sessions mit 8K bei 16-Bit-Cache. Der Inferenzknoten mit vier Karten unter unseren KI-Server-Konfigurationen hält zwei solche Paare, 78 Sessions, oder eine Kopie auf vier Karten mit 264,5 GiB freiem Speicher, 105 Sessions (26 mit 32K); ein FP8-Cache verdoppelt jede Zahl ungefähr. Die Karten haben kein NVLink, eine aufgeteilte Kopie tauscht also in jedem Layer Daten über PCIe aus, und vLLM schaltet seinen Custom All-Reduce bei mehr als zwei GPUs ohne NVLink ab, was zwei TP=2-Paare gegenüber einer TP=4-Kopie begünstigt. Der Durchsatz bei Spitzenlast ist für diese Aufteilungen nicht gemessen; fragen Sie deshalb nach einem Lasttest mit Ihrem Modell.

Wenn Ihr Modell oder Ihre Nutzerzahl oben nicht abgedeckt ist, schicken Sie uns die Angaben, und wir machen dieselbe Rechnung für Ihren Fall, bevor Sie bestellen.

Gemessene Latenz: NIM-Benchmarks für Llama 3.1 8B

Die Rechnung zeigt, was in den Speicher passt; die Antwortzeit ist eine eigene Grenze. NVIDIA hat diese NIM-Benchmark-Zahlen für Llama 3.1 8B auf einer H100 80 GB veröffentlicht, gemessen mit NIM for LLMs 1.8.0, einem älteren Release (aktuell ist im Oktober 2026 Version 2.0.13); sie zeigen, wie Eingabelänge, Präzision und die Zahl laufender Anfragen die Latenz auf einer Karte verändern:

Treffen 250 Anfragen mit je 20.000 Token gleichzeitig ein, dauert das erste Token deutlich über vier Minuten, weil jede Anfrage auf die Prefills vor ihr wartet; einen Wert für einen einzelnen Nutzer nennt die Tabelle nicht. Lange Eingaben kosten also doppelt Zeit, im Prefill selbst und in der Warteschlange dahinter. Die Speicherwarnung von NIM zeigt, was ein kürzerer maximaler Kontext spart: Im dokumentierten Beispiel von NVIDIA senkt eine Grenze von 4.096 Token den geschätzten Speicherbedarf von 45,2 auf 30,1 GB.

KV-Cache-Quantisierung: FP8 und NVFP4

NVIDIAs NVFP4-KV-Cache in TensorRT-LLM senkt den Cache-Speicher gegenüber FP8 um bis zur Hälfte. In NVIDIAs Szenarien mit langem Kontext und Cache-Wiederverwendung verbessert er außerdem die Zeit bis zum ersten Token um bis zu 3×, bei kleinem Genauigkeitsverlust: MMLU-Pro auf Qwen3-Coder-480B-A35B liegt mit FP8-Cache bei 78,1 Prozent und mit NVFP4 bei 77,4 Prozent. NVIDIA hat ihn für Blackwell-GPUs eingeführt; auch SGLang bietet einen NVFP4-Cache an, und vLLM 0.32.0 vom 18. Oktober 2026 meldet, sein NVFP4-KV-Cache laufe jetzt auf SM8x und SM12x, also auch auf den Blackwell-Karten der RTX PRO und dem DGX Spark. Prüfen Sie die Unterstützung für Ihre Karte und Ihre Engine. Ein quantisierter KV-Cache spart Speicher, aber seine Geschwindigkeit hängt von den Kerneln Ihrer Engine für dieses Format auf Ihrer GPU ab; messen Sie sie deshalb, bevor Sie damit rechnen.

Was wir liefern

Wir liefern jede Karte aus den Dimensionierungstabellen EU-weit, unter einem Vertrag und auf einer Rechnung, mit Herstellergarantie: die RTX PRO 4500 (32 GB) für Modelle bis 13B, die RTX PRO 5000 (48 oder 72 GB) für 8B- bis 13B-Modelle mit langem Kontext, die RTX PRO 6000 (96 GB; Workstation, Max-Q oder Server Edition) für ein 70B-Modell in FP8 auf einer Karte und die H200 NVL (141 GB HBM3e) für ein 70B-Modell mit mehr Nutzern oder längeren Kontexten pro Karte. Sie bekommen sie als Karten oder eingebaut in KI-Server, die wir auf Bestellung bauen.

FAQ