LLM VRAM Calculator: Bemessen Sie die GPU, bevor Sie das Modell herunterladen.

Drei Teile addieren. Die Gewichte sind die Parameterzahl mal Bits pro Gewicht der gewählten Quantisierung, geteilt durch 8 für Bytes und durch 2^30 für GiB — ein 8B-Modell braucht etwa 15 GiB in FP16, 8 GiB in Q8_0 und 4,6 GiB in Q4_K_M. Der KV-Cache wächst mit der Kontextlänge (nächste Frage), und die Laufzeit legt einen festen Puffer obendrauf, den dieser Rechner mit 1,5 GiB ansetzt. Die Summe muss mit etwas Luft in den Speicher der Karte passen; wenn nicht, wählen Sie zuerst eine kleinere Quantisierung oder einen kürzeren Kontext, bevor Sie zu einer größeren GPU greifen.

Quantisierung speichert jedes Gewicht in weniger Bits als den 16, mit denen es trainiert wurde. FP16 behält 16 Bit pro Gewicht (bpw); Q8_0 nutzt etwa 8,5 bpw und ist praktisch verlustfrei; Q4_K_M nutzt etwa 4,89 bpw — rund ein Drittel der FP16-Größe — mit einem kleinen Qualitätsverlust, den die meisten im Chat nicht bemerken. Die Bruchwerte stammen aus den gemischten Layouts von llama.cpp, die einige empfindliche Tensoren in höherer Präzision halten und pro Block einen Skalierungsfaktor ablegen — deshalb ist eine „4-Bit“-Datei nicht exakt halb so groß wie eine 8-Bit-Datei.

Jedes Token im Kontext hält in jeder Schicht einen Key- und einen Value-Vektor, der KV-Cache beträgt also 2 × Schichten × KV-Heads × Head-Dimension × Tokens × 2 Bytes in FP16. Für Llama 3.1 8B (32 Schichten, 8 KV-Heads, Head-Dimension 128) sind das 128 KiB pro Token: 1 GiB bei 8.192 Tokens und 16 GiB bei den vollen 131.072 — mehr als die Q4_K_M-Gewichte selbst. Grouped-Query-Attention (8 statt 32 KV-Heads) viertelt den Cache, weshalb Llama 3 lange Kontexte schafft, an denen Llama 2 scheiterte. Der Kontext-Schieberegler zeichnet den Cache als eigenes Balkensegment, damit Sie sehen, wohin der Speicher geht.

GPU-Speicher wird in binären Gigabyte verkauft: Eine „24 GB“-RTX 4090 hat 24 GiB, also 25,77 GB. Ein GB sind 10^9 Bytes, ein GiB sind 2^30 = 1.073.741.824 Bytes und damit 7,37 % mehr; durch 10^9 zu teilen ließe jedes Modell um 7,4 % größer erscheinen, als es ist, und würde knappe Fälle falsch bewerten. Der Rechner teilt überall durch 2^30, damit ein Urteil Gleiches mit Gleichem vergleicht.

Gewichte und KV-Cache sind nicht das ganze Bild: Die Laufzeit (llama.cpp, Ollama, vLLM) reserviert Rechenpuffer für Aktivierungen, der CUDA- oder Metal-Kontext belegt einige hundert MiB, und der Treiber hält eigenen Speicher vor. 1,5 GiB ist eine runde Schätzung, die das für die meisten Modelle auf einer einzelnen Karte abdeckt; der echte Wert hängt von Laufzeit, Batch-Größe und GPU ab. Betrachten Sie ihn als Reserve, nicht als Messwert — landet ein Urteil weniger als ein halbes GiB unter einer Stufe, rechnen Sie mit Problemen.

Nicht vollständig auf der GPU. Llama 3.1 70B in Q4_K_M braucht allein für die Gewichte etwa 40 GiB, noch vor KV-Cache und Laufzeit-Overhead, also kann eine einzelne 24-GiB-Karte es nicht halten. Es passt auf eine 48-GiB-Karte (RTX 6000 Ada, A6000) oder mit Schichtaufteilung auf zwei 24-GiB-Karten; Q2_K mit etwa 3,16 bpw drückt die Gewichte auf rund 26 GiB — immer noch zu viel für eine Karte und mit sichtbarem Qualitätsverlust. Laufzeiten können die restlichen Schichten in den Arbeitsspeicher auslagern, doch dann fällt die Token-Geschwindigkeit auf das, was die Speicherbandbreite der CPU hergibt, typischerweise wenige Tokens pro Sekunde.

Apple Silicon teilt einen Speicherpool zwischen CPU und GPU, sodass ein Mac mit 64 GB Modelle laden kann, die auf keine 24-GiB-Karte passen. Standardmäßig lässt macOS die GPU rund 75 % des Unified Memory nutzen (etwa 48 GiB bei einer 64-GB-Maschine) und behält den Rest für das System; das sysctl iogpu.wired_limit_mb kann die Grenze auf eigenes Risiko anheben. Tragen Sie etwa drei Viertel des Mac-Speichers als Budget ein, und bedenken Sie, dass die Bandbreite, nicht die Kapazität, die Token-Geschwindigkeit bestimmt: Ein M-Series Max schafft rund 400 GB/s, eine RTX 4090 etwa 1 TB/s.

Nein. Der Rechner läuft zu 100 % clientseitig: Die Architektur-Presets und die Arithmetik werden mit der Seite ausgeliefert, und jede Zahl wird in Ihrem Browser-Tab berechnet. Nichts wird auf einen Server hochgeladen, es gibt kein Konto und keine Anmeldung, und der Teilen-Link kodiert Ihre Auswahl im URL-Fragment, das Browser nie an einen Server senden.

Allein für die Gewichte: Ein 8B-Modell braucht etwa 4,6 GiB in Q4_K_M, 7,9 GiB in Q8_0 und 14,9 GiB in FP16 (ein 7B etwa 4,0, 6,9 und 13,0 GiB); ein 14B etwa 8,0, 13,9 und 26,1 GiB; ein 70B etwa 39,9, 69,3 und 130,4 GiB. Dazu kommt der KV-Cache für Ihren Kontext — bei 8.192 Tokens 1 GiB für Llama 3.1 8B und 2,5 GiB für Llama 3.1 70B — plus 1,5 GiB Laufzeit-Overhead, sodass ein 8B in Q4_K_M mit 8k Kontext bei insgesamt etwa 7,1 GiB landet. Jedes verbreitete Modell hat eine eigene Seite mit seiner echten Schichtzahl und seinen KV-Heads, dort lesen Sie das Urteil für genau dieses Modell ab.

Die Gewichte haben eine feste Größe, der KV-Cache wächst dagegen mit jedem Token: Er kostet 2 × Schichten × KV-Heads × Head-Dimension × 2 Bytes pro Token in FP16. Für Llama 3.1 8B sind das 2 × 32 × 8 × 128 × 2 = 128 KiB pro Token, der volle Kontext von 131.072 Tokens braucht also 16 GiB Cache gegenüber etwa 4,6 GiB Q4_K_M-Gewichten. Grouped-Query-Attention hält ihn so klein — 8 statt 32 KV-Heads vierteln den Cache —, während ältere Modelle mit Multi-Head-Attention und einem KV-Head pro Query-Head schon bei viel kürzeren Kontexten den Speicher sprengen.