VRAM für LLM: so rechnen Sie vor dem Kauf richtig

Wie viel VRAM braucht ein Sprachmodell?

Der Bedarf ergibt sich aus vier Grössen: der Parameterzahl, der Quantisierung, der Kontextlänge und der Zahl gleichzeitiger Anfragen. Ein Modell mit 27 Milliarden Parametern in 4 Bit belegt rund 19 GB an Gewichten. Dazu kommen der KV-Cache für die laufenden Gespräche und der Aufschlag der Engine für Puffer und CUDA-Graphen, der bei einem 27-Milliarden-Modell allein rund 15 GB beträgt.

Das Wichtigste in Kürze

• Rechnen Sie den Aufschlag der Engine mit ein. Er wächst mit dem Modell, bei der 30er-Klasse auf zwei Karten sind es 13 bis 15 GB. Was er bei Ihnen beträgt, schreibt vLLM bei jedem Start ins Log.
• Die Kontextlänge ist Ihr grösster Hebel. Wer sie grosszügig setzt, macht aus einer Mehrbenutzermaschine einen Einzelplatz.
• Schalten Sie den KV-Cache?KV-CacheDer Zwischenspeicher, in dem ein Modell den bisherigen Gesprächsverlauf hält. Er wächst mit der Textlänge und mit jedem gleichzeitigen Nutzer und belegt oft mehr Grafikspeicher als das Modell selbst. auf FP8. Ein Flag, und je nach Aufbau passen 37 bis 100 Prozent mehr Gespräche hinein.
• Prüfen Sie die Bauart, bevor Sie Grössen vergleichen. Zwei ähnlich grosse Modelle können beim Platz je Gespräch um Faktor drei auseinanderliegen.
• Lagern Sie ganz aus oder gar nicht. Ein bisschen auslagern kostet am meisten Tempo je gespartem Gigabyte.

Wer eine Maschine für lokale Inferenz bestellt, legt sich für drei Jahre fest. Fällt die Rechnung zu klein aus, startet der Server im schlimmsten Fall gar nicht. Fällt sie zu grosszügig aus, stehen ein paar tausend Franken Grafikspeicher ungenutzt unter dem Schreibtisch. Die Frage «passt das Modell auf die Karte» klingt nach einer Ja-Nein-Frage und ist der teuerste Punkt der ganzen Planung.

Beantwortet wird sie meist mit einer Multiplikation: Parameter mal Bits. Diese Zahl ist ein Anfang, und sie liegt für die Planung deutlich zu tief.

Dies ist der zweite Teil unserer Serie über lokale Inferenz. Der erste hat erzählt, was unsere Maschine kann; dieser hier zeigt, wie Sie eine eigene auslegen.

Warum die Rechnung schwerer ist, als sie aussieht

Vier Grössen bestimmen den Bedarf, und keine davon lässt sich einzeln festlegen:

1. die Modellgrösse, also wie viele Parameter überhaupt geladen werden
2. die Quantisierung, also mit wie vielen Bits je Parameter
3. die Kontextlänge, also wie lang eine einzelne Anfrage werden darf
4. die gleichzeitigen Anfragen, also wie viele Gespräche parallel laufen

Die Hardware setzt die Grenze, in die diese vier passen müssen. Verändern Sie eine, verschieben sich die anderen. Wer die Kontextlänge vervierfacht, drittelt die Zahl gleichzeitiger Nutzer. Wer von FP8 auf 4 Bit geht, gewinnt ein Drittel des Platzes; die Antwortqualität blieb in unserer Messung dabei unverändert. Wer eine zweite Karte einbaut, gewinnt Nutzer und wird beim einzelnen Nutzer minim langsamer.

Ein Beispiel mit zwei Karten

Wir haben ein Modell mit 27.8 Milliarden Parametern in 4 Bit auf zwei RTX 4090 geladen und danach abgelesen, wie viel Platz für die Gespräche der Nutzer übrigblieb. Die Aufstellung sieht so aus:

	GB
Auf beiden Karten vorhanden	48.0
Davon belegt das Modell	19.4
Erwartet für die Gespräche	28.6
Tatsächlich für die Gespräche verfügbar	10.3

Zwischen der dritten und der vierten Zeile liegen 18.3 GB. Die hat sich die Software genommen, bevor das erste Gespräch begonnen hat. Wer also Parameter mal Bits rechnet und den Rest für seine Nutzer einplant, plant mit einem Speicher, den er nicht bekommt.

Wohin der Speicher geht

Vier Posten teilen sich die Karte, und nur der erste steht im Modellnamen: die Gewichte, der KV-Cache, der Aufschlag der Engine und die Reserve.

Erstens die Gewichte. Ihr Platzbedarf hängt allein an der Parameterzahl und an der Quantisierung?QuantisierungKompression eines Modells über geringere Zahlenpräzision der Gewichte (z.B. FP8 oder 4-Bit). Der Betrieb wird deutlich günstiger; ab einem gewissen Grad sinkt die Antwortqualität messbar.. Aus unseren Läufen ergeben sich diese Werte:

Format	GB je Milliarde Parameter
4-Bit (AWQ, GGUF Q4)	0.68
FP8	1.02
BF16, unquantisiert	2.05

Für unser Beispiel: 27.8 Milliarden mal 0.68 ergibt 18.9 GB. Gemessen waren es 19.4. Die Formel trifft auf drei Prozent genau, das reicht für eine Planung.

Zweitens der KV-Cache, also der Platz für die laufenden Gespräche. Dass er mit der Textlänge und mit jeder gleichzeitigen Anfrage wächst, stand im ersten Teil. Was dort nicht stand: wie stark sich sein Preis zwischen zwei Modellen unterscheidet.

Unser 27-Milliarden-Modell hat 64 Schichten, aber nur jede vierte davon führt einen KV-Cache. Die übrigen 48 sind rekurrente Schichten: Sie führen einen Zustand fester Grösse mit und kosten deshalb nichts zusätzlich, wenn das Gespräch länger wird. Beim MoE?MoEMixture of Experts: ein Modell, das viele Teilmodelle («Experten») speichert, pro Token aber nur wenige davon rechnet. Gespeichert werden alle Parameter, gerechnet wird mit einem Bruchteil.-Modell derselben Familie fällt das Verhältnis noch günstiger aus:

Modell	Schichten mit KV-Cache	KV je 1’000 Tokens
Qwen3.6-27B	16 von 64	32 MB
Qwen3.6-35B-A3B	10 von 40	10 MB

Faktor drei zwischen zwei Modellen derselben Familie. Acht Nutzer mit je 10’000 Tokens Kontext brauchen beim einen 2.6 GB, beim anderen 0.8 GB. Dieser Unterschied kann darüber entscheiden, ob eine Karte reicht.

Drittens der Aufschlag der Engine. Er besteht aus zwei Teilen. Die CUDA-Graphen, bei unserem Lauf 6.9 GB über beide Karten: vLLM zeichnet für einige Dutzend Batch-Grössen je eine eingefrorene Abfolge der Rechenschritte auf, und dafür müssen die Zwischenergebnisse jeder Schicht an festen Adressen liegen. Dazu die Puffer für Aktivierungen, den Zustand der 48 rekurrenten Schichten und den CUDA-Kontext, zusammen 7.6 GB. Macht 14.5 GB, die belegt sind, bevor das erste Gespräch beginnt.

Viertens die Reserve. Wir liefen mit --gpu-memory-utilization 0.92, die restlichen 8 Prozent (3.8 GB) rührt vLLM nicht an. Diese Zahl wählen Sie selbst; wo ihre Obergrenze liegt, steht bei den Fallen am Ende.

Zusammen ergeben Aufschlag und Reserve die 18.3 GB aus dem Beispiel oben.

Der Aufschlag wächst mit dem Modell. Wir haben zum Vergleich das kleinste Modell der Vorgängergeneration gestartet:

Modell	Aufbau	Aufschlag der Engine
Qwen3.5-0.8B	eine Karte	2.3 GB
Qwen3.6-27B	zwei Karten	14.5 GB
Qwen3.6-35B-A3B	zwei Karten	13.3 GB

Der Platz für die Zwischenergebnisse wächst mit der Breite und der Tiefe des Modells, langsamer als die Parameterzahl: Das 27-Milliarden-Modell ist fünfmal breiter (Hidden-Dimension 5’120 gegen 1’024) und fast dreimal tiefer (64 gegen 24 Schichten) als das kleine, hat 35-mal mehr Parameter, aber nur rund achtmal mehr Graphenspeicher (3.4 gegen 0.4 GB je Karte). Bei zwei Karten fallen die Puffer je Karte an. Für die Modellklasse dieser Serie rechnen Sie mit 13 bis 15 GB Aufschlag insgesamt.

Raten müssen Sie dabei nicht: vLLM, die Engine hinter allen Messungen dieser Serie, schreibt die Aufteilung bei jedem Start ins Log, in der Zeile Actual usage is ... for peak activation, and ... for CUDAGraph memory. Dieses Protokoll ist verlässlicher als jede Faustzahl, auch als unsere.

Rechnen Sie Ihren Fall durch

Aus den vier Posten und den gemessenen Konstanten wird eine Rechnung, die Sie für Ihre eigene Hardware anstellen können.

Zwei Beispiele zum Mitrechnen, die auch ohne den Rechner funktionieren. Beide mit demselben 27-Milliarden-Modell in 4 Bit.

Eine einzelne RTX 4090 mit 24 GB. Gewichte 19.4, dazu Aufschlag und Reserve: Die Summe liegt weit über 24. Mit Standardeinstellungen startet das nicht. In unseren Messungen lief dieses Modell auf einer Karte nur mit abgeschalteten CUDA-Graphen und verkleinerten Puffern, und selbst dann blieben ganze 15’473 Tokens für Gespräche.

Zwei RTX 4090 mit zusammen 48 GB. Gewichte 19.4, Reserve 3.8, Aufschlag 14.5: Für Gespräche bleiben 10.3 GB, was bei 10’000 Tokens je Anfrage 33 gleichzeitige Anfragen trägt. Dass die Rechnung hier exakt aufgeht, ist keine Kunst, denn die Konstanten stammen aus diesem Lauf. Die Probe ist das MoE-Modell: Dort sagt dieselbe Rechnung 7.8 GB voraus, und aus der gemessenen Token-Kapazität folgen 8.2. Fünf Prozent daneben, in die vorsichtige Richtung.

Kontextlänge frisst gleichzeitige Nutzer

«Wir nehmen die volle Kontextlänge, dann sind wir für alles gerüstet» klingt vernünftig und kostet den ganzen Mehrbenutzerbetrieb.

Dieselbe Maschine, dasselbe Modell, nur die eingestellte Kontextlänge verändert:

Eingestellter Kontext	Platz für Gespräche	Gleichzeitige volle Anfragen
8’192	265’784 Tokens	32.4
32’768	398’677 Tokens	12.2
131’072	438’413 Tokens	3.3
262’144	447’637 Tokens	1.7

Der Platz für Gespräche wächst dabei sogar, um zwei Drittel. Was fällt, ist die Zahl voller Anfragen, die gleichzeitig hineinpassen: von gut 32 auf 1.7, weil jede einzelne Anfrage 32-mal länger sein darf. Wer die volle Kontextlänge freischaltet, bekommt für den Preis einer Mehrbenutzermaschine einen Einzelplatz.

Der KV-Cache lässt sich zudem in halber Genauigkeit führen, in FP8 statt FP16. Auf einer einzelnen Karte verdoppelte das die Kapazität exakt, von 3’920 auf 7’840 Tokens. Über den Kontext-Sweep auf zwei Karten fiel der Gewinn kleiner aus, zwischen Faktor 1.37 und 1.73; ein Grund dürfte der Zustand der rekurrenten Schichten sein, der bei der Umstellung nicht schrumpft, ganz erklären es unsere Logs aber nicht. Bei voller Kontextlänge wird das Flag ohnehin zur Bedingung, denn mit FP16-KV startete der Server dort gar nicht.

Eine Karte, zwei Karten

Der Sprung von einer auf zwei Karten wirkt in unseren Messungen dramatischer, als es die verdoppelte Speichermenge vermuten lässt.

Zum Aufbau: Beide Spalten liefen mit identischen Flags, allerdings mit einer anderen Kontexteinstellung als die Tabellen weiter oben. Deshalb steht hier 411’420 Tokens und in Anhang B 337’042 für dasselbe Modell auf denselben Karten. Vergleichen lässt sich nur, was in derselben Zeile steht; auch die Tempowerte stammen aus diesem Lauf und liegen deshalb unter denen aus dem ersten Teil. Der Platz ist in Tokens angegeben, weil das die Zahl ist, die der Server beim Start ins Log schreibt.

	Eine RTX 4090	Zwei RTX 4090
Platz für Gespräche	15’473 Tokens	411’420 Tokens
Tempo bei einem Nutzer	27.3 Tok/s	23.2 Tok/s
Tempo bei vier Nutzern	50.0 Tok/s	82.0 Tok/s
Wartezeit bei vier Nutzern	42.0 s	3.0 s

Faktor 26.6 beim Platz für Gespräche, obwohl sich der Speicher nur verdoppelt. Das liegt daran, dass auf einer Karte nach Gewichten, Aufschlag und Reserve fast nichts mehr übrig bleibt. Der freie Rest ist die Differenz zweier grosser Zahlen, und eine solche Differenz wächst überproportional, sobald die zweite Karte dazukommt.

Bemerkenswert ist die zweite Zeile. Bei einem einzelnen Nutzer ist die zweite Karte langsamer, weil die Aufteilung eines Modells über zwei Karten Kommunikation kostet, auf einem Consumer-Mainboard zudem über eine halbierte Anbindung. Wir haben unter Last nachgesehen: Die Karten liefen mit acht statt sechzehn PCIe-Lanes, weil sich zwei Steckplätze die Lanes der CPU teilen.

Wenn es nicht passt: die Regel für das Auslagern

Passt das Modell nicht in den Grafikspeicher, lässt sich ein Teil davon in den Arbeitsspeicher legen. Wie teuer das wird, hängt vollständig an der Bauart.

Bei einem Dense-Modell ist es ein Absturz. Wir haben 8 GB ausgelagert und der Durchsatz fiel von 168.7 auf rund 7.4 Tokens pro Sekunde, also um Faktor 22. Der Grund ist die Rechenweise aus dem ersten Teil: Ein Dense-Modell braucht für jedes einzelne Token sämtliche Parameter, also wandert jeder ausgelagerte Wert bei jedem Token über die Leitung.

Bei einem MoE-Modell lohnt es sich. Dort fragt jedes Token nur wenige Experten an, und die selten gebrauchten dürfen liegen bleiben, wo sie sind:

Ausgelagerte Schichten	Grafikspeicher	Durchsatz	Wartezeit
0	23’012 MB	236.5 Tok/s	1.8 s
8	19’472 MB	96.7 Tok/s	10.4 s
16	15’760 MB	64.1 Tok/s	16.8 s
24	12’046 MB	49.1 Tok/s	23.3 s
48 (alle Experten)	4’502 MB	17.7 Tok/s	47.4 s

Ein Modell mit 35 Milliarden Parametern läuft in 4.5 GB Grafikspeicher, also in dem, was eine Einsteigerkarte mitbringt.

Die praktisch wichtigste Zeile ist aber die zweite. Die ersten acht ausgelagerten Schichten kosten 59 Prozent des Durchsatzes und sparen 3.5 GB. Wer alles auslagert, zahlt für die letzten Gigabyte deutlich weniger:

Ausgelagert	Kosten je gespartem GB
8 Schichten	40.4 Tok/s
48 Schichten	12.1 Tok/s

Daraus folgt eine Regel, die dem Bauchgefühl widerspricht. Passt das Modell, lagern Sie nichts aus, weil jede ausgelagerte Schicht reiner Verlust ist. Passt es nicht, lagern Sie richtig aus und akzeptieren den neuen Arbeitspunkt. Am teuersten kommt Sie das «ich schiebe schnell ein paar Schichten raus, damit es gerade noch passt» zu stehen: rund 140 Tokens pro Sekunde für 3.5 GB gesparten Speicher.

Vier Fallen, die uns je einen Anlauf gekostet haben

Die Speicherrechnung ist die eine Hälfte. Die andere sind Einstellungen, die still danebengreifen.

Der Bildschirm kostet ein Gigabyte. Mit --gpu-memory-utilization 0.96 startet vLLM auf einem Arbeitsplatzrechner nicht, weil die grafische Oberfläche bereits rund ein Gigabyte belegt. Auf unserer Maschine war 0.94 die Obergrenze.

CUDA-Graphen lassen sich abschalten. --enforce-eager gibt die rund 7 GB aus dem Aufschlag zurück und bezahlt mit Durchsatz. Ein Handel für Maschinen, auf denen der Platz knapper ist als das Tempo.

FP8-Gewichte brauchen eine Begrenzung der Anfragen. Die offiziellen FP8-Fassungen unseres Modells brachen mit einer Meldung über fehlende Mamba-Cache-Blöcke ab, bis wir die Zahl gleichzeitiger Sequenzen auf 32 begrenzten. Die 4-Bit-Fassung brauchte das nicht.

Der FP8-KV-Cache braucht einen Compiler. Fehlt ninja im Container, startet der Server sauber und beantwortet jede Anfrage mit einem Serverfehler, weil der passende Kernel erst beim ersten Aufruf gebaut wird. Wer dann im Netzwerk sucht, sucht lange.

Was das für Ihren Einkauf heisst

Stellen Sie die Rechnung als Summe auf: Gewichte plus KV-Cache plus der Aufschlag der Engine plus die Reserve. Passt die Summe nicht auf die Karte, hilft kein Optimismus beim KV-Cache.

Wählen Sie die Kontextlänge nach dem, was Ihre längsten echten Dokumente brauchen. Von 8’192 auf 262’144 Tokens fällt die Zahl gleichzeitiger Anfragen von 32 auf 1.7, und das ist der grösste Hebel im ganzen Aufbau.

Nehmen Sie den FP8-KV-Cache, sofern Ihre Karten ihn können. Bei voller Kontextlänge startet der Server sonst gar nicht.

Und wenn der Platz eng wird, hilft eine zweite Karte mehr als ein kleineres Modell: Sie kauft Gleichzeitigkeit, also genau das, wofür eine solche Maschine meist angeschafft wird.

1. 01

   Die Rechnung als Summe aufstellen

   Gewichte plus KV-Cache plus der Aufschlag der Engine plus die Reserve. Den Aufschlag für Ihr Modell verrät die Log-Zeile beim ersten Start.

2. 02

   Die Kontextlänge begrenzen

   Auf das, was Ihre längsten echten Dokumente brauchen, plus Reserve. Jede Verdopplung darüber hinaus kostet gleichzeitige Nutzer.

3. 03

   Den Startversuch protokollieren

   Halten Sie fest, mit wie viel freiem KV-Cache der Server startet. vLLM schreibt die Zahl ins Log, und sie ist Ihre echte Obergrenze für gleichzeitige Anfragen.

4. 04

   Die Konfiguration festhalten

   Engine-Version, Speicherauslastung, Kontextlänge, KV-Präzision. Ohne diese vier Angaben ist eine Messung nicht wiederholbar, auch nicht die eigene.

Damit steht die Speicherrechnung. Wie stark Sie quantisieren dürfen, ohne dass die Antworten leiden, misst der dritte Teil der Serie; die Wahl der Engine und die Kostenrechnung folgen danach.

Sie planen eine Maschine für lokale KI. Wie viel Grafikspeicher brauchen Sie wirklich?

Die übliche Antwort lautet: Parameter mal Bits. Für ein Modell mit 27 Milliarden Parametern in 4 Bit sind das 19.4 GB, und auf zwei Karten mit zusammen 48 GB klingt das nach reichlich Luft.

Gemessen mit vLLM 0.27 sieht die Aufteilung anders aus: 19.4 GB Gewichte, 14.5 GB Aufschlag der Engine für Puffer und CUDA-Graphen, 3.8 GB Reserve. Für alle laufenden Gespräche zusammen bleiben 10.3 GB. Der Aufschlag wächst mit dem Modell, von 2.3 GB bei 0.8 Milliarden Parametern auf 14.5 GB bei 27 Milliarden, und er steht in keinem Datenblatt. vLLM schreibt ihn bei jedem Start ins Log.

Unser Schluss: Wer souverän hosten will, dimensioniert selbst. Rechnen Sie mit vier Posten statt mit einem, sonst kaufen Sie eine Maschine, auf der zwar das Modell liegt, aber kaum jemand damit arbeiten kann.

Im Beitrag stehen ein Rechner zum Selbernachrechnen, der Effekt der Kontextlänge und die Messung dazu, warum halbes Auslagern in den Arbeitsspeicher selten lohnt. Link in den Kommentaren.

#KI #LLM #Hardware #Schweiz