# Welches Modell passt auf welche GPU? VRAM richtig berechnen

Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.

## "70B läuft doch auf 24 GB"

In einem Workshop letzten Monat sagte ein CTO einen Satz, den wir inzwischen fast jede Woche hören: "Wir haben gelesen, ein 70B-Modell läuft problemlos auf einer 24-GB-Karte, dann kaufen wir halt zwei davon." Der Satz stammte aus einem Forumspost, nicht aus einer eigenen Rechnung, und genau das ist das Problem. **Die Aussage stimmt sogar, aber nur unter Bedingungen, die im Forumspost nicht mehr auftauchen**: aggressive 4-Bit-Quantisierung, ein Kontext von vielleicht 2000 Token, ein einziger Nutzer, kein Puffer für irgendetwas anderes. Sobald einer dieser Punkte wegfällt, bricht die Rechnung zusammen, und die GPU meldet "out of memory", meist mitten in der Produktivdemo.

Wir sehen diesen Fehler so oft, dass wir ihn zum Anlass für diesen Artikel gemacht haben. **Bevor du Hardware kaufst oder mietest, rechnest du den VRAM-Bedarf selbst aus**, nicht anhand eines Blogposts, sondern anhand deines Modells, deiner Kontextlänge und deiner Nutzerzahl. Die Rechnung ist keine Raketenwissenschaft, sie dauert fünf Minuten mit Taschenrechner. Aber sie wird fast nie gemacht, bevor die Bestellung raus ist.

## Die Faustformel für die Modellgewichte

Der erste und grösste Posten sind die reinen Modellgewichte, und dafür gibt es eine simple Faustregel: **Pro Milliarde Parameter brauchst du in fp16 rund 2 GB, in int8 rund 1 GB und in int4 rund 0,5 GB.** Der Grund ist banal: fp16 speichert jeden Parameter mit 16 Bit, also 2 Byte, int8 mit einem Byte, int4 mit einem halben Byte. Ein 8B-Modell wiegt also in fp16 rund 16 GB, in int8 rund 8 GB, in int4 rund 4 GB. Multiplizierst du die Parameterzahl mit dem Bytes-pro-Parameter-Faktor, hast du die Basiszahl, auf der alles Weitere aufbaut.

Wichtig dabei: **Quantisierung ist kein Freibrief ohne Kosten.** int4 halbiert den Speicherbedarf gegenüber int8 nochmal, aber die Modellqualität leidet, besonders bei Reasoning-lastigen Aufgaben und bei sehr grossen Modellen, deren Gewichte ohnehin schon "eng gepackt" sind. Für viele produktive Anwendungsfälle ist int8 der vernünftige Mittelweg zwischen Speicherersparnis und Qualität, int4 lohnt sich vor allem dort, wo Kapazität die harte Grenze ist und du die Qualitätseinbusse getestet und akzeptiert hast, nicht als automatischer erster Griff.

## Der Posten, den fast jeder vergisst: der KV-Cache

Hier liegt der Grund, warum so viele VRAM-Rechnungen in der Praxis scheitern, obwohl die Modellgewichte sauber berechnet waren. Der **KV-Cache** speichert für jedes bereits verarbeitete Token die sogenannten Key- und Value-Vektoren aus jeder Attention-Schicht, damit das Modell sie beim nächsten Token nicht neu berechnen muss. Das ist der Trick, der Inferenz überhaupt schnell macht, aber er hat einen Preis: **Der KV-Cache wächst linear mit Kontextlänge, Batchgrösse, Anzahl der Layer und Hidden-Size des Modells.** Er ist kein fixer Posten wie die Gewichte, er ist ein Posten, der mit jedem zusätzlichen Token und jedem zusätzlichen Nutzer weiterwächst, solange die Session offen bleibt.

Bei kurzen Prompts mit wenigen hundert Token fällt das kaum ins Gewicht, ein paar hundert MB, in der Rechnung fast vernachlässigbar. Bei **langen Kontexten ab 32k Token** sieht das anders aus. Grob gerechnet gilt: **KV-Cache-Grösse ≈ 2 (Key und Value) × Anzahl Layer × Hidden-Size × Bytes pro Wert × Anzahl Token**, multipliziert mit der Zahl paralleler Sequenzen. Bei einem grossen Modell mit vielen Layern und breiter Hidden-Size kann der KV-Cache pro Nutzer schon bei einem einzigen langen Kontext in den Bereich von mehreren GB rutschen, bei Modellen ohne speichersparende Attention-Varianten (Grouped-Query-Attention reduziert das deutlich) auch deutlich mehr. Und dann kommt der Faktor, der in den meisten Milchmädchenrechnungen komplett fehlt: **Concurrency.** Bedienst du nicht einen, sondern zehn gleichzeitige Nutzer mit langen Kontexten, multipliziert sich der KV-Cache-Bedarf entsprechend, und aus ein paar GB werden schnell zweistellige GB, die zusätzlich zu den Modellgewichten im Speicher liegen müssen. Genau das ist die Lücke, in der reale Deployments an die Wand fahren, obwohl "das Modell doch gepasst hat".

Zwei Stellschrauben helfen dagegen, wenn der KV-Cache zum Flaschenhals wird, und beide solltest du kennen, bevor du automatisch zu mehr Hardware greifst. **Grouped-Query-Attention (GQA)**, in praktisch allen aktuellen offenen Modellen wie Llama 3 oder Mistral verbaut, reduziert die Zahl der gespeicherten Key-Value-Köpfe drastisch gegenüber klassischer Multi-Head-Attention, oft um den Faktor 4 bis 8. Und **Quantisierung des KV-Cache selbst**, also int8 statt fp16 für die gespeicherten Key-Value-Vektoren, halbiert den Bedarf nochmal, unabhängig davon, in welcher Präzision die Modellgewichte laufen. Beide Hebel kosten etwas Qualität am Rand, aber deutlich weniger als an den Gewichten selbst zu sparen, weshalb sie in der Praxis oft der bessere erste Griff sind, bevor du eine grössere Karte bestellst.

## Overhead: die letzten 1-2 GB, die trotzdem entscheiden

Nach Gewichten und KV-Cache bleibt noch ein dritter Posten, kleiner, aber real: **Aktivierungen während der Forward-Pass-Berechnung, der CUDA-Kontext selbst und der Speicherbedarf des Inferenz-Frameworks.** Grob gerechnet solltest du hierfür **1 bis 2 GB als Grundrauschen** einplanen, unabhängig von der Modellgrösse, plus einen Puffer, wenn du mit variabler Batchgrösse arbeitest oder mehrere Requests gleichzeitig verarbeitest. Frameworks wie vLLM reservieren zudem bewusst zusätzlichen Speicher für PagedAttention-Blöcke und Zwischenergebnisse, das ist kein Bug, sondern Teil davon, warum sie überhaupt performant sind.

Der Grund, warum wir diesen Posten trotz seiner geringen Grösse ausdrücklich erwähnen: **Er ist der Unterschied zwischen "passt gerade so" und "läuft stabil".** Wer seine GPU bis auf den letzten Gigabyte für Gewichte und KV-Cache ausrechnet und dann live geht, erlebt den ersten Out-of-Memory-Fehler meist innerhalb der ersten Betriebswoche, sobald ein Nutzer zufällig einen längeren Prompt schickt oder zwei Requests gleichzeitig eintreffen. Ein realistischer Sicherheitspuffer ist keine Vorsicht, sondern die Voraussetzung dafür, dass die Rechnung überhaupt in der Praxis hält, was sie auf dem Papier verspricht.

## Die Rechnung durchgespielt: drei Modellgrössen, drei Quantisierungsstufen

Am klarsten wird das Ganze an konkreten Zahlen, deshalb rechnen wir drei typische Modellgrössen jeweils in fp16, int8 und int4 durch, nur für die reinen Gewichte:

- **7B/8B-Modelle** (z. B. Llama 3.1 8B, Mistral 7B): fp16 ≈ 14-16 GB, int8 ≈ 7-8 GB, int4 ≈ 3,5-4 GB.
- **13B-Modelle**: fp16 ≈ 26 GB, int8 ≈ 13 GB, int4 ≈ 6,5 GB.
- **70B-Modelle** (z. B. Llama 3.1/3.3 70B): fp16 ≈ 140 GB, int8 ≈ 70 GB, int4 ≈ 35 GB.

Legst du das gegen reale Hardware, wird die Konsequenz sofort greifbar. Auf einer **24-GB-Karte** passt ein 7B/8B-Modell komfortabel in fp16, ein 13B-Modell braucht schon int8 oder int4, und ein 70B-Modell passt nur in int4, und dann bleibt kaum noch Platz für KV-Cache und Overhead, geschweige denn für mehrere Nutzer mit langem Kontext. Auf **48 GB** hast du für 7B/13B in fp16 komfortabel Luft, für 70B brauchst du weiterhin int4 oder knapp int8 mit sehr kleinem Kontext. Eine **80-GB-H100** trägt ein 70B-Modell in int8 mit spürbarem Puffer für Kontext und moderates Batching, in fp16 wird es eng, weil 140 GB Gewichte allein schon nicht draufpassen, ganz ohne KV-Cache. Und eine **DGX Spark mit 128 GB Unified Memory** trägt ein 70B-Modell sogar in fp16 mit Reserve für ordentlichen Kontext, ohne dass du überhaupt quantisieren musst, was insbesondere für Genauigkeit bei anspruchsvollen Aufgaben relevant sein kann. Das ist genau der Rechenweg, den wir im [Erfahrungsbericht zur DGX Spark](/de/wissen/dgx-spark-erfahrungsbericht) im Praxisbetrieb durchgespielt haben, dort mit echten Ladezeiten und echten Tokens/s, nicht nur auf Papier.

Der Punkt, an dem die meisten Rechnungen kippen, ist selten die Modellgrösse allein, sondern die Kombination aus Modellgrösse und Concurrency. Ein 8B-Modell für einen einzelnen internen Nutzer mit kurzem Kontext läuft auf praktisch jeder Karte ab 16 GB entspannt, Gewichte und KV-Cache zusammen bleiben deutlich unter 20 GB. Derselbe 8B-Endpoint für fünfzig gleichzeitige Nutzer mit 8k-Kontext sieht komplett anders aus, dann dominiert plötzlich der KV-Cache die Rechnung, nicht mehr die Gewichte. **Genau deshalb reicht es nicht, nur "welches Modell" zu fragen, du musst "welches Modell, für wie viele gleichzeitig, mit wie viel Kontext" fragen**, sonst rechnest du nur die halbe Gleichung.

## Erst der Use-Case, dann die Hardware

Aus all dem folgt eine simple, aber oft ignorierte Reihenfolge: **Du definierst zuerst deinen Use-Case, dann wählst du die Hardware, nicht umgekehrt.** Konkret heisst das, drei Fragen zu beantworten, bevor du auch nur eine Preisliste öffnest. Welche Modellgrösse brauchst du wirklich, reicht ein 8B-Modell für deinen Anwendungsfall oder brauchst du die Qualität eines 70B-Modells? Wie lang werden deine typischen Kontexte, reichen 4k Token oder arbeitest du mit ganzen Dokumenten bei 32k und mehr? Und wie viele Nutzer greifen gleichzeitig zu, ist das ein interner Tool für fünf Personen oder ein Endpoint mit hundert parallelen Sessions?

Wer diese Reihenfolge umdreht und zuerst die Hardware kauft, kauft fast immer falsch, entweder zu klein, was zu ständigem Quantisierungs-Downgrade und Kontext-Kürzung führt, oder zu gross, was Kapital bindet, das produktiv nirgends gebraucht wird. **Die günstigste GPU der Welt ist trotzdem zu teuer, wenn sie deinen Use-Case nicht trägt**, und die teuerste ist Verschwendung, wenn ein kleineres Modell für deine Aufgabe längst gereicht hätte. Bei der Modellwahl selbst hilft unser Überblick zur [Auswahl offener Modelle](/de/wissen/offene-modelle-auswahl), bei der Frage Kapazität gegen Bandbreite unser Vergleich [DGX Spark gegen Cloud-GPU](/de/wissen/dgx-spark-vs-cloud-gpu). Als Grobregel gilt: **Brauchst du vor allem Kapazität für grosse Modelle bei stabiler, planbarer Last, ist [DGX Spark](/de/dgx-spark) die richtige Wahl. Brauchst du rohen Durchsatz für Training oder sehr viele parallele Nutzer, ist [Bare-Metal H100](/de/bare-metal) die richtige Liga.** Und was die einzelnen Optionen am Ende tatsächlich kosten, inklusive der Posten, die in Angeboten gerne verschwiegen werden, steht offen in unserer [Kostenrechnung für Self-Hosted LLMs](/de/wissen/llm-selbst-betreiben-kosten).

## Die volle Formel entscheidet, nicht die Gewichte allein

"70B läuft auf 24 GB" ist keine Lüge, aber es ist auch keine Aussage, auf der du eine Kaufentscheidung aufbauen solltest, ohne die Bedingungen dahinter selbst nachzurechnen. **Die vollständige Formel ist immer: Gewichte plus KV-Cache plus Overhead, nicht nur die Gewichte allein.** Wer nur die Gewichte rechnet, hat nur die halbe Rechnung gemacht, und der fehlende Teil meldet sich spätestens beim zweiten gleichzeitigen Nutzer mit langem Kontext, meist zur unpassendsten Zeit.

Wir rechnen diese Zahlen bei Twentyone für jeden Kunden konkret durch, mit echter Modellgrösse, echter Kontextlänge und echter Nutzerzahl, bevor irgendeine Maschine reserviert wird. Wenn du wissen willst, ob dein Modell auf eine [H100 bare metal](/de/bare-metal) passt, oder ob du eigentlich etwas ganz anderes brauchst, rechnen wir es gemeinsam durch, offen und ohne dir vorher etwas verkaufen zu wollen, das du nicht brauchst.