LLM-VRAM-Bedarf: Die große Tabelle 2026 (jedes Modell, jede Quantisierung)

LLM-VRAM-Bedarf: Die große Tabelle 2026 (jedes Modell, jede Quantisierung)

Hier ist die Zahl, die jeden überrascht: DeepSeek-V3.2 hat 671 Milliarden Parameter, aber nur 37 Milliarden davon feuern pro Token. Wie viel VRAM braucht das Modell also wirklich? Alle 671 Milliarden, ungefähr 382 GB bei Q4. LLM-VRAM-Bedarf folgt selten der Intuition, und genau in der Lücke zwischen „aktiven Parametern" und „dem, was tatsächlich geladen werden muss", sprengen Hardware-Budgets. Dieser Leitfaden liefert die große Tabelle (jedes wichtige offene Modell, jede Quantisierungsstufe, die GB-Zahl und die passende GPU) plus die Formel, mit der Sie jedes Modell in etwa zehn Sekunden selbst berechnen.

Wichtigste Erkenntnisse

• VRAM für die Gewichte ≈ Parameter × Bytes pro Parameter: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Dazu kommen KV-Cache und ca. 15-20 % Overhead.
• Mixture-of-Experts-Modelle (DeepSeek, GLM-5.2, Qwen3-235B) müssen jeden Experten in den VRAM laden. „Aktive Parameter" bringen Geschwindigkeit, aber keinen Speicherplatz.
• Der KV-Cache ist die versteckte Kostenstelle. Llama 3.3 70B braucht bei 8K Kontext rund 2.6 GB Cache und bei 128K etwa 41 GB, zusätzlich zu den Gewichten.
• Q4_K_M ist der sinnvolle Standard: nahezu volle Qualität bei etwa einem Viertel des FP16-Speicherbedarfs.
• Ein 12B-Modell wie Gemma 4 passt bei Q4 auf eine 8-GB-Karte. Ein dichtes 70B-Modell braucht etwa 40 GB. Ein 671B-Frontier-MoE-Modell braucht einen kleinen Server.

LLM-VRAM-Bedarf nach Modell: Die große Tabelle

Kurz gesagt: Bei Q4_K_M passen kleine Modelle (unter 14B) auf Consumer-Karten mit 8-12 GB, mittelgroße Modelle (24-32B) wollen 16-24 GB, ein dichtes 70B-Modell braucht etwa 40 GB, und die Frontier-MoE-Modelle springen in den dreistelligen Gigabyte-Bereich, weil jeder Experte im Speicher liegen muss. Hier die vollständige Übersicht an einem Ort. Alle Angaben beziehen sich ausschließlich auf den Speicherbedarf der Gewichte, berechnet aus der Parameterzahl jedes Modells und abgeglichen mit den offiziellen Model Cards von Meta AI, Qwen und Hugging Face.

Zwei Dinge lassen sich aus dieser Tabelle ablesen. Erstens: Quantisierung ist der größte Hebel, den Sie haben. Der Sprung von FP16 zu Q4 senkt den Speicherbedarf um etwa das Vierfache, bei kaum spürbarem Qualitätsverlust. Zweitens: Die MoE-Zeilen wirken brutal, weil sie es sind. Qwen3-30B-A3B aktiviert nur 3B Parameter pro Token und läuft deshalb so schnell wie ein winziges Modell, trotzdem müssen alle 30B im Speicher liegen, damit jeder Experte bereitsteht. Wollen Sie die Details hinter diesen Zahlen Modell für Modell nachvollziehen? Unser Gemma 4 12B Deep Dive und der Überblick über die besten Open-Source-LLMs 2026 behandeln Benchmarks und Lizenzen.

Die VRAM-Formel: Jedes Modell selbst berechnen

Um ein beliebiges Modell zu dimensionieren, multiplizieren Sie die Parameterzahl mit den Bytes pro Parameter Ihrer Quantisierungsstufe und addieren dann noch etwas für KV-Cache und Laufzeit-Overhead. Das ist alles. Die Gewichte sind der dominante Term, und die Rechnung ist einfach genug für die Rückseite eines Bierdeckels.

Die Kerngleichung für die Gewichte:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Die Bits-pro-Gewicht-Werte, die Sie brauchen (das sind die effektiven Raten für GGUF-k-Quant-Dateien, die zusätzlich zur nominellen Bit-Tiefe noch etwas Block-Metadaten mitführen):

Ein Rechenbeispiel: Gemma 4 12B bei Q4_K_M: 11.95 × 4.5 ÷ 8 = etwa 6.7 GB für die Gewichte. Das passt zu den rund 6.6 GB, die die offizielle Model Card angibt, und erklärt, warum das Modell auf eine 8-GB-Karte passt und noch Platz für einen bescheidenen Kontext lässt. Rechnen Sie dieselbe Formel für ein 70B-Modell bei Q4, kommen Sie auf 70 × 4.5 ÷ 8 = 39.4 GB. Deshalb hört man überall die Faustregel: „zwei 24-GB-Karten oder eine 48-GB-Karte für ein 70B-Modell".

Das vollständige Bild ergänzt zwei weitere Terme: Gesamt-VRAM ≈ Gewichte + KV-Cache + ~15-20 % Overhead. Der Overhead deckt Aktivierungspuffer, den CUDA-Kontext und Speicherfragmentierung ab, und Ihre GPU reserviert außerdem ein halbes Gigabyte oder so für den Treiber. Planen Sie also nie mit 100 % des aufgedruckten VRAM-Werts.

Warum der KV-Cache Sie kalt erwischt

Der KV-Cache speichert die Attention-Keys und -Values für jeden Token, der bereits im Kontext steht, und wächst linear mit der Kontextlänge. Bei kurzen Prompts ist er ein Rundungsfehler. Bei einem langen Kontext kann er die Gewichte selbst einholen oder sogar übertreffen. Das ist mit Abstand der häufigste Grund, warum ein Modell, das „eigentlich passen sollte", mitten in der Generierung einen Out-of-Memory-Fehler wirft.

Die Formel, pro Token:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Nehmen Sie Llama 3.3 70B: 80 Layer, 8 KV-Heads, Head-Dimension 128, also kv_dim = 1024. Bei FP16 ergibt das 80 × 2 × 1024 × 2 = 327,680 Bytes pro Token, etwa 0.31 MB. Multiplizieren Sie das mit der Kontextlänge, und die Geschichte schreibt sich von selbst: Bei 8K Tokens liegt der Cache bei rund 2.6 GB, bei 32K bei etwa 10 GB, und bei 128K wächst er auf rund 41 GB an. Diese letzte Zahl kommt zusätzlich zu den 40 GB Gewichten hinzu, sodass aus einem „40-GB-Modell" in dem Moment, in dem Sie das Fenster füllen, still und leise ein 80-GB-Problem wird.

Zwei praktische Auswege. Grouped-Query-Attention (die inzwischen jedes aktuelle Modell nutzt) reduziert kv_dim bereits gegenüber dem alten Multi-Head-Design deutlich, moderne Modelle sind hier also weit gnädiger als Llama 2 es war. Und die meisten Inference-Engines können den KV-Cache auf 8-Bit oder 4-Bit quantisieren, was die Größe halbiert oder viertelt, bei geringem Qualitätsverlust. Wenn Sie in Produktion lange Kontexte bedienen, zeigt der Vergleich vLLM vs. SGLang, welches Backend diesen Speicher mit Paged Attention am effizientesten verwaltet.

MoE-Modelle: Warum „aktive Parameter" keinen VRAM sparen

Das ist die Falle, die die meisten Leute am meisten Geld kostet. Ein Mixture-of-Experts-Modell wie DeepSeek-V3.2 (671B gesamt, 37B aktiv, mit der V3-Architektur) oder GLM-5.2 (744B gesamt, 40B aktiv) leitet jeden Token durch eine kleine Teilmenge seiner Experten. Das Marketing stützt sich auf die aktive Zahl, weil sie die Geschwindigkeit beschreibt: Sie zahlen pro Token nur die Rechenleistung von 37B Parametern, die Inferenz ist also schnell für die Modellgröße. Aber jeder Experte muss im Speicher liegen, bereit, ausgewählt zu werden, und deshalb bestimmt die Gesamtparameterzahl Ihr VRAM-Budget, nicht die aktive.

Die ehrliche Lesart der Tabelle oben: GLM-5.2 läuft mit der Geschwindigkeit eines 40B-Modells, belegt aber den Speicher eines 744B-Modells. Deshalb brauchen diese Frontier-Open-Modelle einen 8-GPU-Server oder eine große Unified-Memory-Maschine, obwohl ein einzelner Forward-Pass günstig ist. Qwen3-235B-A22B hat dieselbe Form in kleinerem Maßstab: schnell pro Token, teuer zu hosten.

Der Vorteil von MoE zeigt sich bei Unified-Memory-Hardware. Ein Mac Studio mit 512 GB Unified Memory kann ein 671B-Modell bei Q4 laden und trotzdem mit brauchbarer Geschwindigkeit betreiben, genau weil nur 37B aktivieren und der Speicherbandbreitenbedarf pro Token dadurch überschaubar bleibt. Wenn Sie neu darin sind, solche Modelle lokal zu betreiben, starten Sie mit unserem Leitfaden zum lokalen LLM-Setup, bevor Sie in Hardware investieren.

Welche Quantisierung sollten Sie wählen?

Für fast alle ist Q4_K_M der richtige Standard: nahezu volle Qualität bei etwa einem Viertel des FP16-Speicherbedarfs. Steigen Sie nur auf Q5_K_M oder Q8 um, wenn Sie VRAM übrig haben und die Aufgabe qualitätssensibel ist, und greifen Sie nur zu FP16, wenn Sie fine-tunen oder gegen eine Referenz benchmarken. Unterhalb von Q4 wird der Qualitätsverlust schnell spürbar, Q3 und darunter sind daher nur ein letzter Ausweg, um ein Modell auf eine Karte zu quetschen, die wirklich zu klein ist.

Eine Einschränkung: Die Quantisierungsqualität ist nicht bei jedem Modell gleich. Sehr kleine Modelle (unter 4B) spüren Q4 stärker als große, weil ihnen weniger Redundanz übrig bleibt. Bei einem 70B-Modell lassen sich Q4 und Q8 bei den meisten Aufgaben kaum unterscheiden. Bei einem 1.7B-Modell ist die Lücke real.

Welche GPU brauchen Sie wirklich?

Gleichen Sie die Q4-Spalte der großen Tabelle mit einer Karte ab, die noch etwas Spielraum für den KV-Cache bietet. Hier die praktische Zuordnung von günstiger Consumer-Hardware bis zum Rechenzentrum, mit der Modellklasse, die jede Stufe bei Q4 komfortabel läuft.

Apple Silicon verdient eine besondere Erwähnung, weil Unified Memory die Rechnung verändert. Ein Mac trennt VRAM nicht vom System-RAM, sodass eine 128-GB-M-Serie-Maschine Modelle laden kann, für die sonst mehrere diskrete GPUs nötig wären. Der Tausch: weniger Spitzendurchsatz gegen die Fähigkeit, riesige Gewichte auf einem einzigen Desktop unterzubringen. Für die Backends, die das Meiste aus jeder dieser Karten herausholen, benchmarkt unser Überblick über die besten Tools zum lokalen Betrieb von LLMs die realen Geschwindigkeitsunterschiede.

Wie wir VRAM für Kundenprojekte dimensionieren

Bei Techsy setzen wir für Kunden oft genug offene Modelle ein, dass die VRAM-Dimensionierung das erste Gespräch ist, noch vor der Modellwahl, noch vor den Prompts, noch vor allem anderen. Unsere Methode ist absichtlich langweilig, denn der Fehlerfall (ein OOM in Produktion unter echter Kontextlast) ist teuer. Hier der Prozess, den wir tatsächlich fahren.

Wir starten mit der Tabellen-Rechnung und messen dann nach. Nach dem Laden eines Modells prüfen wir den tatsächlichen residenten Speicherbedarf, statt der Schätzung zu vertrauen:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

Die Lektion, die sich ständig wiederholt: Teams dimensionieren für die Gewichte und vergessen den KV-Cache, und wundern sich dann, warum ein Modell, das problemlos geladen hat, mitten in einer Demo nach drei langen Requests abstürzt. Wir dimensionieren für die Gewichte plus den KV-Cache beim maximalen Kontext, den die App wirklich nutzen wird, plus Puffer, und wir deckeln --ctx-size, damit ein außer Kontrolle geratener Request die Box nicht in ein OOM treibt. Für alles, was Kunden direkt sehen, betreiben wir lieber ein quantisiertes 32B-Modell, das nie umkippt, als ein FP16-70B-Modell, das unter Last in ein OOM läuft.

Wenn Sie abwägen, ob Sie ein offenes Modell selbst hosten oder bei einer gehosteten API bleiben, ist genau dieser Trade-off (Hardware-Kosten und Ops-Aufwand gegenüber Pro-Token-Preisen und Kontrolle) das, was unser Team bei einem KI-Integrationsprojekt durchrechnet. Wenn es hilft, dass jemand die Zahlen konkret für Ihre Workload durchrechnet, holen Sie sich eine kostenlose Beratung, und wir dimensionieren es gemeinsam mit Ihnen.

Häufig gestellte Fragen

Wie viel VRAM brauche ich, um ein 70B-Modell zu betreiben?

Ein dichtes 70B-Modell wie Llama 3.3 70B braucht bei Q4_K_M etwa 40 GB VRAM für die Gewichte, planen Sie also mit einer 48-GB-Karte (RTX 6000 Ada) oder zwei 24-GB-Karten. Bei langem Kontext kommen noch mehrere Gigabyte für den KV-Cache hinzu, was den praktischen Bedarf Richtung 48 GB oder mehr treibt.

Wie viel VRAM brauchen Llama, Qwen oder DeepSeek?

Das hängt ganz von der Variante ab. Llama 4 Scout braucht bei Q4 etwa 62 GB, Qwen3-32B etwa 18 GB, und Qwen3-8B unter 5 GB. DeepSeek-V3.2, ein 671B-MoE-Modell, braucht rund 382 GB, weil jeder Experte geladen werden muss. Prüfen Sie bei MoE-Modellen immer die Gesamtparameterzahl, nicht die aktive.

Kann ich ein LLM auf einer 8-GB-GPU betreiben?

Ja, problemlos. Eine 8-GB-Karte wie die RTX 4060 betreibt Modelle bis etwa 12B Parameter bei Q4_K_M. Gemma 4 12B passt in rund 6.8 GB und lässt noch Platz für einen bescheidenen Kontext. Für alles Größere quantisieren Sie stärker, halten den Kontext kurz oder greifen zu einer größeren Karte.

Was kann eine 24-GB-GPU wie die RTX 4090 betreiben?

Eine 24-GB-Karte bewältigt dichte Modelle bis etwa 32B bei Q4_K_M, mit Spielraum für einen angemessenen Kontext, Qwen3-32B und Mistral Small 3.2 24B laufen also komfortabel. Sie betreibt außerdem das Qwen3-30B-A3B-MoE-Modell, das 30B an Gewichten lädt, aber dank spärlicher Aktivierung mit der Geschwindigkeit eines 3B-Modells generiert.

Verschlechtert Quantisierung die Modellqualität?

Bei Q4_K_M und darüber ist der Qualitätsverlust gering und bei echten Aufgaben oft kaum spürbar, besonders bei Modellen über 13B. Die Lücke wird größer, je niedriger Sie gehen und je kleiner das Modell ist, Q4 bei einem 70B ist also fast kostenlos, während Q4 bei einem 1.7B spürbar ist. Q8 ist praktisch verlustfrei, wenn Sie den Speicher dafür haben.

Brauchen MoE-Modelle weniger VRAM als dichte Modelle?

Nein, und das ist der häufigste Irrtum. Ein Mixture-of-Experts-Modell muss jeden Experten im VRAM halten, sein Speicherbedarf richtet sich also nach der Gesamtparameterzahl. Die aktive Parameterzahl beschreibt nur die Inferenzgeschwindigkeit. GLM-5.2 läuft mit der Geschwindigkeit eines 40B-Modells, braucht aber den Speicher eines 744B-Modells.

Ist Unified Memory dasselbe wie VRAM?

Funktional, für das Laden von Modellen, ja. Apple Silicon und einige andere Systeme teilen sich einen gemeinsamen Speicherpool zwischen CPU und GPU, sodass ein 128-GB-Mac Modelle laden kann, für die sonst mehrere diskrete GPUs nötig wären. Der Tausch betrifft die Bandbreite: Unified Memory liefert meist einen geringeren Spitzendurchsatz als eine High-End-Rechenzentrums-GPU, die Tokens pro Sekunde sind also niedriger.

Kann ich einen Teil eines Modells auf System-RAM oder CPU auslagern?

Ja. Engines wie llama.cpp und Ollama lassen Sie mit einem Flag wie --n-gpu-layers einige Layer auf der GPU behalten und den Rest im System-RAM. Damit können Sie ein Modell betreiben, das eigentlich zu groß für Ihren VRAM ist, aber jeder Layer auf der CPU verlangsamt die Generierung deutlich. Nutzen Sie es, um ein Modell möglich zu machen, nicht schnell.

Wie berechne ich VRAM für ein Modell, das nicht in der Tabelle steht?

Multiplizieren Sie die Parameterzahl in Milliarden mit den Bits pro Gewicht Ihrer Quantisierungsstufe und teilen Sie dann durch 8. Für Q4_K_M rechnen Sie mit etwa 4.5 Bits, ein 40B-Modell braucht also 40 × 4.5 ÷ 8 = etwa 22.5 GB für die Gewichte. Für den realen Bedarf addieren Sie noch rund 15-20 % Overhead plus Ihren KV-Cache.