Aktive Parameter, Gesamtparameter und was davon wirklich in den Grafikspeicher muss

TL;DR

Der Titel ist eine Zuspitzung, und sie stimmt nur halb. Ein 30B-MoE braucht keine 30 GB — im Q4-Format sind es rund 19 GB. Aber es braucht auch keine 3 GB: Die Gesamtparameter treiben den Speicherbedarf, alle Experten müssen geladen sein, weil der Router pro Token neu auswählt. Die aktiven Parameter treiben nur die Rechenlast. MoE spart Zeit, nicht Speicher.

Der Denkfehler, der gerade reihenweise Hardware-Fehlkäufe produziert

Der Modellname Qwen3-30B-A3B liest sich für viele wie ein Versprechen: 30 Milliarden Parameter Qualität zum Preis von 3 Milliarden. Also müsste eine 8-GB-Karte reichen, oder? Wir hören diese Rechnung inzwischen in fast jedem zweiten Sizing-Gespräch.

Sie ist falsch, und zwar an genau einer Stelle. Das A3B sagt aus, wie viele Parameter pro Token gerechnet werden. Es sagt nichts darüber, wie viele Parameter verfügbar sein müssen. Der Router entscheidet für jedes einzelne Token neu, welche acht der 128 Experten er anspricht. Welche das sein werden, weiß vorher niemand — also müssen alle 128 im Speicher liegen.

Die Analogie, die am schnellsten zündet: eine Bibliothek mit 128 Regalen. Sie lesen pro Frage acht Bücher. Trotzdem brauchen Sie das ganze Gebäude, weil Sie nicht wissen, wo die Antwort auf die nächste Frage steht.

Was der Router tatsächlich tut

In einem klassischen dichten Modell läuft jedes Token durch jede Schicht und jedes Gewicht. Ein 32B-Modell liest für jedes einzelne erzeugte Token 32 Milliarden Parameter durch. Das ist der Grund, warum Token-Generierung speicherbandbreiten- und nicht rechenlimitiert ist.

MoE greift genau dort ein. Der Feed-Forward-Block jeder Schicht — der Teil, der den Großteil der Gewichte hält — wird in viele kleine parallele Blöcke aufgeteilt, die Experten. Davor sitzt ein winziges Netz, der Router. Es schaut sich den Zustand des aktuellen Tokens an und wählt eine feste Anzahl Experten aus, deren Ausgaben dann gewichtet zusammengerechnet werden.

Drei Zahlen beschreiben so ein Modell vollständig:

• Gesamtparameter — alles, was auf der Platte liegt und in den Speicher muss.
• Aktive Parameter — was pro Token durchgelesen wird. Bestimmt die Geschwindigkeit.
• Experten insgesamt / Experten pro Token — bei Qwen3-30B-A3B sind das 128 und 8, bei DeepSeek-V3 256 und 8, bei Mixtral 8x7B 8 und 2.

Was dabei gern übersehen wird: Die Attention-Schichten sind nicht sparse. Sie laufen bei jedem Token vollständig. Auch Embeddings und Normalisierungen sind dicht. Die aktiven Parameter setzen sich also aus dem dichten Rest plus den ausgewählten Experten zusammen — nicht nur aus den Experten.

Die Speicherrechnung, Posten für Posten

Rechnen wir ein reales Beispiel offen durch: Qwen3-30B-A3B im Format Q4_K_M auf einer RTX 4090 mit 24 GB, 32.768 Token Kontext.

Posten 1: Gewichte. Die Q4_K_M-Datei von Qwen3-30B-A3B misst laut Hugging-Face-Dateiliste exakt 18.556.686.912 Byte, also 18,6 GB (unsloth/Qwen3-30B-A3B-GGUF); Ollama gibt für dasselbe Modell gerundet 19 GB an. Das ist kein Schätzwert, das ist die Dateigröße, und sie landet praktisch eins zu eins im VRAM. Die verbreitete Faustformel Parameter × 0,5 Byte ergibt 30,5 × 0,5 = 15,25 GB und liegt damit 3,3 GB oder 18 Prozent unter dem echten Wert — Q4_K_M quantisiert nicht alle Tensoren gleich hart, und Embeddings bleiben oft in höherer Präzision. Wer mit der Faustformel plant, plant zu knapp.

Posten 2: KV-Cache. Hier wird es interessant, weil MoE ausgerechnet an dieser Stelle einen echten Vorteil hat. Die Formel:

KV pro Token = 2 × Layer × KV-Heads × Head-Dim × Bytes

Qwen3-30B-A3B hat laut seiner config.json 48 Layer, 4 KV-Heads und eine Head-Dimension von 128. In FP16 ergibt das 2 × 48 × 4 × 128 × 2 Byte = 98.304 Byte, also 96 KiB pro Token. Bei 32.768 Token sind das exakt 3 GiB.

Posten 3: Aktivierungen, CUDA-Context, Fragmentierung. Der CUDA-Kontext allein kostet je nach Treiber 300 bis 600 MB. Dazu Zwischenergebnisse, Puffer für Prefill-Batches und Speicherfragmentierung. Kalkulieren Sie 1 bis 1,5 GB.

Summe: rund 23 GB von 24 GB. Es passt — ohne jede Reserve. Erhöhen Sie den Kontext auf 128k, brauchen Sie allein für den KV-Cache 12 GiB, und die Karte reicht nicht mehr.

Jetzt der Gegencheck mit dem dichten Nachbarn. Qwen3-32B hat laut config.json 64 Layer, 8 KV-Heads, Head-Dim 128 — macht 2 × 64 × 8 × 128 × 2 Byte = 256 KiB pro Token, also 8 GiB bei 32k Kontext. Plus 20 GB Gewichte (Ollama-Tag qwen3:32b) plus Overhead: rund 30 GB. Auf einer 24-GB-Karte läuft dieses Modell bei vollem Kontext schlicht nicht.

Hier kippt das Bild an einer Stelle, und wir sagen das offen, auch wenn es der eigenen Überschrift widerspricht: Bei gleicher nomineller Größe ist das MoE-Modell in der Gesamtbilanz oft das genügsamere — nicht wegen der Gewichte, sondern weil moderne MoE-Architekturen schlanke Attention-Konfigurationen mitbringen. Der Unterschied zwischen 19 GB und 20 GB Gewichten ist irrelevant. Der zwischen 3 und 8 GiB KV-Cache ist es nicht.

Wer diese Rechnung für die eigene Nutzerzahl aufstellen will, findet die Systematik im Sizing-Leitfaden für KI-Server. Denn bei acht parallelen Sessions à 8.000 Token multipliziert sich der KV-Cache — und genau daran scheitern die meisten Erstinstallationen, nicht an den Gewichten.

Gängige MoE-Modelle nach Gesamt- und aktiven Parametern

Spalte "Gewichte im VRAM" sind die Download-Größen der jeweiligen Ollama-Tags (qwen3:30b-a3b, mixtral:8x7b, gpt-oss:20b, gpt-oss:120b, qwen3:235b-a22b, deepseek-v3:671b-q4_K_M), Stand August 2026; Expertenzahlen aus den config.json der jeweiligen Hugging-Face-Repositories. KV-Cache und Overhead sind nicht enthalten. Bei Llama 4 Scout schwanken die Community-Quantisierungen erheblich, deshalb eine Spanne statt einer Punktzahl.

Lesen Sie die Tabelle einmal von unten nach oben. DeepSeek-V3 aktiviert pro Token nur 37 von 671 Milliarden Parametern — trotzdem müssen 404 GB Gewichte im Speicher liegen, also mindestens sechs 80-GB-Karten, in der Praxis eher acht, sobald KV-Cache und Overhead dazukommen. Wie das in einem deutschen Rechenzentrum aussieht, steht in der DeepSeek-V3-On-Premise-Analyse. Der Sparsamkeitsfaktor von 18 (671 geteilt durch 37) findet vollständig auf der Rechenseite statt und spart keine einzige Gigabyte-Zeile auf der Speicherseite.

Was MoE dann wirklich bringt

Geschwindigkeit. Und zwar in einer Größenordnung, die Sie nachrechnen können, statt sie aus einem Forenpost zu übernehmen.

Bei der Token-Generierung limitiert die Speicherbandbreite, nicht die Rechenleistung — die GPU muss für jedes Token die relevanten Gewichte einmal komplett durch den Speicherbus ziehen. Eine RTX 4090 liefert 1.008 GB/s. Daraus folgt die theoretische Obergrenze:

• Dichtes 32B in Q4: 20 GB pro Token → 1.008 / 20 = rund 50 Token/s.
• Qwen3-30B-A3B in Q4: 3,3 Mrd. aktive Parameter bei effektiv 0,61 Byte pro Parameter (18,6 GB geteilt durch 30,5 Mrd.) ergeben etwa 2 GB pro Token → 1.008 / 2 = rund 500 Token/s.

Diese Obergrenzen erreicht keine Runtime. Kernel-Overhead, die dichte Attention und die Router-Logik kosten, und beim MoE kosten sie relativ mehr, weil der dichte Anteil dort einen größeren Teil der verbleibenden Arbeit ausmacht. Der reale Abstand ist deshalb deutlich kleiner als der rechnerische Faktor 10 — aber er bleibt ein Vielfaches, bei praktisch identischem Speicherbedarf.

Konkrete Token/s-Zahlen aus fremden Benchmarks sind für Ihre Kaufentscheidung wertlos: Sie hängen an Runtime, Batchgröße, Kontextlänge, Quantisierung und Treiberversion. Messen Sie auf Ihrer eigenen Karte, das dauert zwei Minuten:

llama-bench -m Qwen3-30B-A3B-Q4_K_M.gguf -p 512 -n 128 -ngl 99

Und das ist der eigentliche Punkt. MoE ist keine Kompressionstechnik. Es ist ein Tauschgeschäft: Sie geben Speicher, den Sie ohnehin belegen müssten, und bekommen dafür Geschwindigkeit — oder, aus der anderen Richtung gelesen, mehr Modellqualität bei gleichem Rechenbudget. Für einen internen Chat-Assistenten mit zwölf gleichzeitigen Nutzern ist das der Unterschied zwischen "fühlt sich flüssig an" und "die Leute machen währenddessen etwas anderes".

Zwei Nebeneffekte, die selten erwähnt werden: MoE-Modelle sind beim Fine-Tuning aufwendiger, weil die Router-Balance kippen kann. Und die Antwortlatenz schwankt stärker als bei dichten Modellen. Für Chat ist das egal, für getaktete Prozessschritte in der Fertigung nicht.

Wann ein dichtes Modell die bessere Wahl ist

Klare Ansage, weil die Frage in Sizing-Gesprächen ständig fällt: Wenn Ihr VRAM knapp ist, nehmen Sie das dichte Modell.

Konkret. Sie haben eine RTX 4070 Ti Super oder eine A4000 mit 16 GB. Die Wahl steht zwischen einem dichten 14B in Q4 (9,3 GB) und einem 30B-MoE in Q4 (18,6 GB). Das MoE passt nicht — Punkt. Es gibt keinen Trick, der daraus 12 GB macht, außer einer Quantisierung so aggressiv, dass die Qualität unter die des dichten 14B fällt. Sie nehmen das 14B, behalten nach Abzug des Overheads gut 5 GB Luft für KV-Cache und parallele Sessions und fahren damit besser als mit jedem Offloading-Konstrukt.

Dasselbe eine Klasse tiefer: 8 GB VRAM. Ein dichtes 8B in Q4 belegt 5,2 GB und läuft sauber. Das kleinste ernstzunehmende MoE, gpt-oss-20b, will 14 GB. Die Antwort ist trivial.

Unsere Empfehlung als Regel: MoE lohnt erst ab der Speicherklasse, in der das Modell vollständig hineinpasst — inklusive KV-Cache für die geplante Nutzerzahl. Darunter ist es keine günstigere Variante eines großen Modells, sondern ein großes Modell mit Zusatzproblemen. Welche Karte welche Klasse abdeckt, steht im GPU-Vergleich für LLM-Inferenz.

Ein zweiter Fall spricht für dicht: Ihre Installation läuft, die Anforderungen sind stabil, der Durchsatz reicht. Dann ist der Wechsel auf MoE Arbeit ohne Gegenwert.

Offloading: was passiert, wenn es doch nicht passt

Sowohl llama.cpp als auch Ollama können Teile eines Modells im System-RAM lassen. Für MoE gibt es dafür in llama.cpp den Schalter --n-cpu-moe, der gezielt die Expertengewichte einer wählbaren Anzahl Schichten im RAM belässt und Attention plus KV-Cache auf der GPU behält.

Ein Punkt vorweg, weil er fast überall falsch erklärt wird: Diese Gewichte werden nicht bei jedem Token über PCIe zur GPU geschoben. Sie bleiben im Hauptspeicher, und die zugehörige Rechnung erledigt die CPU. Über den Bus gehen nur die kleinen Aktivierungen an der Nahtstelle. Der Flaschenhals ist damit nicht PCIe, sondern die Bandbreite des Hauptspeichers — bei Dual-Channel-DDR5 grob 70 bis 90 GB/s gegenüber 1.008 GB/s auf der 4090. Das ist Faktor 12 bis 14, nicht Faktor 39.

Ob es Sie betrifft, sehen Sie in zwei Zeilen:

# Was die Karte gerade belegt und wie ausgelastet sie ist
nvidia-smi --query-gpu=name,memory.used,memory.total,utilization.gpu --format=csv

# Welche Modelle laufen, und ob sie ganz auf der GPU liegen
ollama ps

Steht in der Spalte PROCESSOR von ollama ps etwas wie "35%/65% CPU/GPU", läuft ein Teil im RAM.

Rechnen wir es durch, mit 70 GB/s Hauptspeicherbandbreite als konservativer Annahme:

• Dichtes 32B, 30 Prozent ausgelagert: 30 Prozent von 20 GB sind 6 GB, die pro Token aus dem RAM gelesen werden müssen. 6 / 70 = 86 Millisekunden, also höchstens rund 11 Token/s — und das ist die reine Bandbreiten-Obergrenze, die CPU-Rechenzeit kommt obendrauf. Unbenutzbar.
• MoE mit denselben 30 Prozent: Pro Token fallen im ausgelagerten Anteil nur rund 0,6 GB an, weil eben nicht alle Experten gebraucht werden. 0,6 / 70 = 9 Millisekunden. Der GPU-Anteil bleibt der Flaschenhals, das Offloading kostet kaum etwas.

Das ist der Grund, warum MoE die einzige Klasse ist, bei der Teil-Offloading erträglich bleibt. Wer ein 120B-MoE auf einer 24-GB-Karte mit viel System-RAM betreiben will, kann das tun.

Nur verschweigt diese Rechnung einen Bruch: den Prefill. Wenn das Modell einen langen Prompt einliest — bei RAG sind 8.000 Token Kontext normal — routet jedes dieser Token zu anderen Experten. Über einige hundert Token gesehen werden praktisch alle Experten gebraucht, die Sparsamkeit verschwindet. Dazu kommt der eigentliche Killer: Prefill ist rechen- und nicht bandbreitenlimitiert. Genau in dieser Disziplin verliert eine CPU gegen eine 4090 um Größenordnungen — anders als bei der Token-Generierung, wo sie nur um Faktor 12 bis 14 zurückliegt. In der Praxis heißt das: Die Antwort tröpfelt danach passabel, aber Sie warten spürbar lange auf das erste Wort. Wie lange genau, hängt an CPU, RAM-Takt und Prompt-Länge — messen Sie das, bevor Sie ein Produkt darauf bauen.

Deshalb bleibt unsere Position: Offloading ist eine Notlösung für Testbetrieb und Einzelnutzer. Für einen produktiven RAG-Dienst mit mehreren Nutzern kaufen Sie die passende Karte oder verteilen auf mehrere GPUs — die Systematik dafür steht im vLLM-Guide für Multi-GPU-Cluster.

FAQ

Was bedeutet die Bezeichnung 30B-A3B bei einem Modellnamen?

30B ist die Gesamtzahl der Parameter, hier 30,5 Milliarden — sie bestimmt den Speicherbedarf. A3B steht für "3 Milliarden aktive Parameter" und beschreibt, wie viele Gewichte pro erzeugtem Token tatsächlich gerechnet werden; das bestimmt die Geschwindigkeit. Beide Zahlen sind voneinander unabhängig: Das Modell belegt im Speicher die vollen 30B, arbeitet aber im Tempo eines 3B-Modells.

Braucht ein MoE-Modell weniger VRAM als ein dichtes Modell gleicher Größe?

Für die Gewichte nein — ein 30B-MoE und ein 32B-Dense liegen in Q4 beide bei 19 bis 20 GB. In der Gesamtbilanz kann das MoE trotzdem günstiger sein, weil moderne MoE-Architekturen weniger Layer und KV-Heads mitbringen: Qwen3-30B-A3B braucht bei 32.000 Token Kontext 3 GiB KV-Cache, das dichte Qwen3-32B dagegen 8 GiB. Der Unterschied liegt also nicht bei den Experten, sondern bei der Attention.

Wie viel VRAM braucht Qwen3-30B-A3B bei mehreren gleichzeitigen Nutzern?

Rechnen Sie 18,6 GB Gewichte plus 96 KiB KV-Cache je Token und Session plus rund 1,5 GB Overhead. Bei acht parallelen Sessions à 8.000 Token macht der KV-Cache 6,3 GB aus, macht in Summe gut 26 GB — eine 24-GB-Karte reicht dann nicht mehr, eine 48-GB-Karte schon. Die Gewichte sind fix, mitwachsen tut nur der KV-Cache; er bestimmt deshalb Ihre Kartenwahl, nicht die Modellgröße. Konkrete Konfigurationen und Preise stehen im KI-Server-Hardware-Guide.

Kann ich ein MoE-Modell teilweise in den System-RAM auslagern?

Ja, llama.cpp und Ollama unterstützen das, bei llama.cpp gezielt über --n-cpu-moe für die Expertengewichte. MoE verträgt Offloading deutlich besser als dichte Modelle, weil pro Token nur ein Bruchteil der ausgelagerten Gewichte gelesen werden muss — und zwar von der CPU aus dem Hauptspeicher, nicht über PCIe zur GPU. Die Token-Generierung bleibt dadurch erträglich, aber die Prompt-Verarbeitung bricht ein: Dabei werden nahezu alle Experten angesprochen, und Prefill ist rechenlimitiert, nicht bandbreitenlimitiert. Bei langem RAG-Kontext warten Sie spürbar auf das erste Wort.

Warum kann man nicht einfach nur die benötigten Experten laden?

Weil der Router erst während der Berechnung entscheidet, welche Experten er für das nächste Token braucht — und das ändert sich von Token zu Token. Ein Nachladen einzelner Experten über den Bus liefe bei PCIe 4.0 x16 auf rund 26 GB/s hinaus (theoretisch 32 GB/s) gegenüber 1.008 GB/s im Grafikspeicher der RTX 4090 — Faktor 39, und das pro Token. Es gibt experimentelle Caching-Verfahren für häufig genutzte Experten, aber keines davon ist in Ollama oder vLLM produktionsreif verfügbar.

Der nächste Schritt

Bevor Sie eine Karte bestellen, stellen Sie die Rechnung aus diesem Artikel für Ihren Fall auf: Gewichte laut Modelldatei, KV-Cache aus Layer-Zahl und geplantem Kontext mal Nutzerzahl, plus 1,5 GB Overhead. Landen Sie über 90 Prozent der Kartenkapazität, ist die Karte zu klein. Welche Konfiguration zu welchem Ergebnis passt, steht im Sizing-Leitfaden für KI-Server — und wenn Sie die Rechnung lieber gegenlesen lassen, sprechen Sie uns an.