Wie sich MoE-Modelle beim Deployment unterscheiden: Ein Self-Hosting-Leitfaden
Qwen3.5-9B passt in 5,3 GB VRAM. Sein MoE-Geschwistermodell, Qwen3.5-35B-A3B, braucht 18,5 GB — aktiviert aber nur 3 Milliarden Parameter pro Token. Was steckt dahinter?
Mixture-of-Experts-Modelle verwirren Betreiber, weil die Angabe „aktive Parameter” für die Hardware-Planung irreführend ist. Man sieht „3B aktiv” und greift zur 8-GB-GPU. Dann lässt sich das Modell nicht laden.
Dieser Leitfaden erklärt die VRAM-Berechnung, stellt alle heute selbst hostbaren MoE-Modelle vor und zeigt, wie man sie auf praxistauglicher Hardware zum Laufen bringt. Als durchgängiges Beispiel verwenden wir die Qwen-3.5-Familie, weil sie den klarsten Vergleich bietet: gleiche Generation, gleiche Trainingsdaten, gleiche Fähigkeiten — nur die Architektur unterscheidet sich.
Kurzfassung: Mixture-of-Experts-Modelle wie DeepSeek V3.1 (685B gesamt, 37B aktiv) und Qwen3.5-35B-A3B (36B gesamt, 3B aktiv) leiten jedes Token durch einen Bruchteil ihrer Experten — aber sämtliche Gewichte aller Experten müssen im Speicher verbleiben. Qwen3.5-9B (dense) belegt bei Q4_K_M nur 5,29 GB; sein MoE-Geschwistermodell benötigt bei gleicher Quantisierung 18,49 GB, obwohl es weniger Parameter aktiviert (Unsloth GGUF, 2026). Unter Q4_K_M verschlechtert sich die Routing-Qualität — also nicht tiefer gehen.
Was bedeutet „Mixture of Experts” für das Deployment?
Seit Anfang 2025 setzen nahezu alle führenden Frontier-KI-Modelle auf MoE-Architekturen (NVIDIA Blog, 2025). Bei einem dichten Modell ist jeder Parameter an jedem Token beteiligt. Bei einem MoE-Modell wählt ein Router-Netzwerk pro Token eine Teilmenge von „Experten” aus — allerdings müssen alle Experten im Speicher geladen sein. Diese eine Tatsache erklärt fast jede Überraschung beim Deployment.
Stellen Sie sich das so vor: Ein dichtes Modell ist ein einzelner Koch, der für jedes Gericht jede Zutat in der Küche verwendet. Ein MoE-Modell ist ein Restaurant mit 256 Köchen, jeder ein Spezialist — aber Sie müssen das gesamte Gebäude mieten, obwohl zu jedem Zeitpunkt nur 8 Köche arbeiten.
Qwen 3.5: der perfekte Vergleich
Die Qwen-3.5-Familie bietet uns den saubersten direkten Vergleich. Beide Varianten teilen die gleichen Trainingsdaten, die gleichen Fähigkeiten (Code, Mehrsprachigkeit, Reasoning, Tool Calls, Vision) und das gleiche 262K-Kontextfenster. Der einzige Unterschied ist die Architektur:
- Qwen3.5-9B — dense, 9,65 Milliarden Parameter. Jeder Parameter wird bei jedem Token aktiviert.
- Qwen3.5-35B-A3B — MoE, 35,95 Milliarden Parameter gesamt, 256 Experten, 8 aktive + 1 gemeinsamer pro Token. Etwa 3 Milliarden Parameter werden pro Token aktiviert.
Gleiche Familie. Gleiche Generation. Völlig unterschiedliche Deployment-Profile. Das macht MoE mit Ihrer Infrastruktur.
Beachten Sie das Muster. Je größer MoE-Modelle werden, desto dramatischer wächst die Kluft zwischen Gesamt- und aktiven Parametern. Kimi K2.5 hat über eine Billion Parameter, aktiviert aber nur 32 Milliarden pro Token — 3,1 % der Gesamtzahl. Ihrer GPU ist dieses Verhältnis egal. Sie muss alle halten.
VRAM-Anforderungen — Warum MoE-Modelle mehr brauchen als erwartet
Qwen3.5-35B-A3B benötigt bei Q4_K_M 3,5× mehr VRAM als Qwen3.5-9B, obwohl es weniger Parameter pro Token aktiviert (Unsloth GGUF, Unsloth GGUF, 2026). Der Grund ist einfach: Der VRAM-Bedarf für Modellgewichte skaliert mit der Gesamtzahl der Parameter, nicht mit den aktiven. Nur der KV cache skaliert mit den aktiven Parametern.
Die Formel
Für jedes quantisierte GGUF-Modell teilt sich der VRAM-Bedarf in zwei Teile auf:
- Modellgewichte = Gesamtparameter × Bits_pro_Gewicht / 8. Alle Experten eingeschlossen.
- KV cache = proportional zu aktive_Parameter × Kontextlänge × Batch-Größe.
Bei einem dichten Modell gilt: Gesamtparameter = aktive Parameter — die Unterscheidung spielt keine Rolle. Bei MoE ist sie enorm wichtig. So sieht das mit realen Zahlen aus unseren Modelldaten aus:
| Modell | Architektur | Gesamtparameter | Aktive Parameter | Q4_K_M-Größe |
|---|---|---|---|---|
| Qwen3.5-9B | Dense | 9,65B | 9,65B | 5,29 GB |
| Qwen3.5-35B-A3B | MoE (256 Experten) | 35,95B | ~3B | 18,49 GB |
| DeepSeek V3.1 | MoE (256 Experten) | 684,53B | ~37B | 377,56 GB |
Unsere Erkenntnis: Als wir die Deploy-Seiten von Prositronic erstellt haben, brauchten MoE-Modelle völlig andere VRAM-Berechnungen und Warnhinweise. Ein Modell mit 3B aktiven Parametern könnte vermuten lassen, dass es auf einem Raspberry Pi läuft — bis man bemerkt, dass alle 36 Milliarden Gewichte in den Speicher passen müssen. Wir mussten einen eigenen
MOE_EXPERT_CPU_OFFLOAD-Hinweis auf jeder MoE-Deploy-Seite ergänzen.
Der grüne Streifen im MoE-Balken ist aufschlussreich. Könnte man nur die 3B aktiven Parameter laden, bräuchte man etwa 1,6 GB. Stattdessen benötigt man 18,49 GB, weil alle 256 Experten — 35,95 Milliarden Parameter — resident sein müssen, damit der Router aus ihnen auswählen kann.
Für größere MoE-Modelle werden Multi-GPU-Setups unvermeidlich. DeepSeek V3.1 wiegt bei Q4_K_M 377,56 GB. Kimi K2.5 überschreitet 500 GB. Keine einzelne Consumer-GPU kommt auch nur annähernd heran. Heißt das, man kann sie gar nicht betreiben? Nicht ganz — hier kommt Expert Offloading ins Spiel (dazu mehr in einem späteren Abschnitt).
Ihre MoE-Modelle — ein Deployment-Vergleich
Konfigurationen mit einem einzigen aktiven Experten liefern 50–80 % höheren Durchsatz als Konfigurationen mit 8 aktiven Experten (Chitty-Venkata et al., 2025). Sechs MoE-Modellfamilien stehen heute für selbst gehostetes Deployment zur Verfügung, von 36B bis über eine Billion Gesamtparameter. So schneiden sie im Vergleich ab:
| Modell | Gesamt | Aktiv | Experten (genutzt/gesamt) | Q4-Größe | Min. VRAM |
|---|---|---|---|---|---|
| Qwen3.5-35B-A3B | 35,95B | ~3B | 8+1 / 256 | 18,49 GB | 24 GB |
| Qwen3-235B-A22B | 235B | ~22B | 8 / 64 | ~130 GB | Multi-GPU |
| DeepSeek V3.1 | 684,53B | ~37B | 8+1 / 256 | 377,56 GB | Multi-GPU |
| Kimi K2.5 | 1.016B | ~32B | 8 / 384 | ~550 GB | Multi-GPU |
| Llama 4 Scout | ~109B | ~17B | 1 / 16 | ~60 GB | 2× 48 GB |
| Llama 4 Maverick | ~400B | ~17B | 1 / 128 | ~220 GB | Multi-GPU |
Feingranulares vs. grobgranulares Routing
Beachten Sie den architektonischen Unterschied. DeepSeek V3.1 und Qwen3.5-35B-A3B nutzen 256 kleine Experten (feingranulares Routing) — jeder Experte ist ein schmaler Spezialist. Llama 4 Scout nutzt nur 16 große Experten (grobgranulares Routing) — jeder Experte ist ein Generalist, der ein breiteres Spektrum an Tokens verarbeitet. Was bedeutet das für Sie?
Feingranulare Modelle können Rechenleistung präziser zuweisen. Aber sie erfordern mehr Speicherverwaltung und ihr Routing ist empfindlicher gegenüber Quantisierung. Grobgranulare Modelle sind einfacher zu deployen, aber weniger flexibel. Llama 4 Scout aktiviert nur 1 Experten pro Token (nicht 8), was das Speicherzugriffsmuster berechenbarer macht, aber die Spezialisierung einschränkt.
Auswirkungen der Quantisierung auf MoE-Modelle
FP8 erreicht bei den höchsten Batch-Größen auf H100-GPUs 25–30 % höheren Durchsatz als FP16 (Chitty-Venkata et al., 2025). Lassen Sie sich davon aber nicht zu extremer Quantisierung verleiten. MoE-Modelle sind empfindlicher gegenüber aggressiver Quantisierung als dichte Modelle, weil die Router-Gewichte hochpräzise bleiben müssen, um die richtigen Experten auszuwählen.
Der Router ist das Gehirn eines MoE-Modells. Er untersucht jedes Token und entscheidet, welche Experten es verarbeiten sollen. Wenn man ein dichtes Modell auf Q2 quantisiert, verschlechtert sich jeder Parameter gleichmäßig. Wenn man ein MoE-Modell auf Q2 quantisiert, beginnt der Router, die falschen Experten auszuwählen. Das Ergebnis ist kein allmählicher Qualitätsverlust — sondern ein Absturz.
Modernste MoE-Modelle erleiden bei extremer Quantisierung unter 4 Bit spürbaren Genauigkeitsverlust; Forscher haben Methoden wie MiLo (Mixture of Low-rank compensators) entwickelt, um die Genauigkeit wiederherzustellen, aber diese erhöhen die Komplexität (Huang et al., 2025). Für den praktischen Einsatz ist unsere Empfehlung einfach: Gehen Sie nicht unter Q4_K_M.
MXFP4: die Ausnahme
Es gibt eine Ausnahme. Qwen3.5-35B-A3B bietet eine MXFP4_MOE-Quantisierung mit 20,11 GB, die 4-Bit-MX-Quantisierung gezielt auf die Experten-Layer anwendet und dabei Attention- und Routing-Layer in höherer Präzision belässt. Dieser selektive Ansatz bewahrt die Routing-Qualität und komprimiert dennoch den Großteil des Modells. Wenn Ihre Hardware MXFP4 unterstützt (NVIDIA Blackwell und neuer), ist es eine starke Alternative zu Q4_K_M.
Dynamische Quantisierung: ein klügerer Ansatz
Unsloths Strategie der dynamischen Quantisierung komprimiert MoE-Experten-Layer selektiv auf niedrigere Bit-Breiten, während Attention- und Routing-Layer in höherer Präzision bleiben. Deshalb sehen Sie bei vielen Quant-Dateinamen das Präfix „UD” — es steht für „Unsloth Dynamic”. Der Ansatz nutzt die Tatsache, dass Experten unterschiedlich stark zur Modellqualität beitragen: Gemeinsame Experten und Routing-Layer sind vorrangige Kandidaten für den Erhalt hoher Präzision, während selten aktivierte Experten stärkere Komprimierung vertragen.
Strategien für Expert Offloading
DeepSeek V3.1 läuft in seiner TQ1_0-Quantisierung auf einer einzelnen 24-GB-GPU mit MoE-Offloading und 96–128 GB System-RAM bei etwa 1–2 Tokens pro Sekunde (Community-Benchmarks, 2025). Expert Offloading ist die Schlüsseltechnik, um große MoE-Modelle auf begrenzter Hardware zu betreiben. Dabei werden inaktive Experten-Gewichte im System-RAM oder auf NVMe gespeichert und bei Bedarf auf die GPU geladen.
CPU-Offloading mit llama.cpp
Der praktischste Ansatz für Single-GPU-Setups. In llama.cpp können Sie alle MoE-Experten-Layer auf die CPU auslagern, während Attention- und Routing-Layer auf der GPU bleiben:
llama-server \
--model Qwen3.5-35B-A3B-UD-Q4_K_M.gguf \
-ot ".ffn_.*_exps.=CPU" \
--n-gpu-layers 999 \
--ctx-size 8192 \
--jinjaDas Flag -ot ".ffn_.*_exps.=CPU" weist llama.cpp an, alle
Feed-Forward-Layer der Experten auf der CPU zu platzieren, während alles andere auf der GPU bleibt.
Das ist effektiver als --n-gpu-layers allein, das ganze
Transformer-Blöcke auslagert, anstatt Experten-Layer gezielt aufzuteilen.
Multi-GPU: tensor parallelism gewinnt
Tensor parallelism erzielt Leistungsgewinne von 2×+ beim Skalieren von 1 auf 4 GPUs auf H100 und übertrifft sowohl pipeline parallelism als auch expert parallelism (Chitty-Venkata et al., 2025). Wenn Sie mehrere GPUs über NVLink verbunden haben, verteilt tensor parallelism (TP) jede Schicht über die GPUs. Expert parallelism (EP) weist verschiedene Experten verschiedenen GPUs zu. TP gewinnt, weil die NVLink-Bandbreite hoch genug ist, um die Schichtaufteilung effizient zu machen, während EP unter Lastverteilungs-Overhead leidet — einige Experten erhalten mehr Traffic als andere.
Speculative Decoding verbirgt Offloading-Latenz
Eine neuere Technik namens SpecMoEOff kombiniert Speculative Decoding mit Expert Offloading und erreicht bis zu 2,5× höheren Decode-Durchsatz, indem Entwurfs-Tokens generiert werden, während Experten-Gewichte vom RAM auf die GPU übertragen werden. Das ist noch experimentell, deutet aber auf eine Zukunft hin, in der selbst Billionen-Parameter-MoE-Modelle auf Workstation-Hardware laufen.
Leistungscharakteristiken — Was Sie erwarten können
Die Inter-Token-Latenz variiert um fast 100 % zwischen den besten und schlechtesten MoE-LLM- Performern (Chitty-Venkata et al., 2025). Dichte Modelle haben vorhersagbare Pro-Token-Latenz, weil jedes Token den gleichen Rechenweg nimmt. MoE-Modelle nicht — Routing-Entscheidungen erzeugen Varianz. Wenn Ihre Anwendung konsistente Antwortzeiten benötigt, ist das relevant.
Latenz-Spitzen durch kalte Experten
Wenn ein Token an einen selten genutzten Experten geroutet wird und dessen Gewichte aus dem GPU-Cache verdrängt wurden (oder in einem Offloading-Setup nie geladen waren), entsteht eine Latenz-Spitze. Die GPU wartet, bis die Experten-Gewichte aus dem RAM eintreffen. Diese Spitzen sind unvorhersehbar — sie hängen vom Inhalt des Prompts ab und davon, welche Experten er aktiviert.
Durchsatz variiert je nach Prompt
Manche Prompts treffen wiederholt dieselbe kleine Gruppe von Experten. Andere verteilen die Last auf viele Experten. Das macht den MoE-Durchsatz grundsätzlich weniger vorhersagbar als den Durchsatz dichter Modelle. Kürzere Sequenzen (128 Tokens) erreichen bis zu 30 % höheren Durchsatz als 2048-Token-Sequenzen bei MoE-Modellen (Chitty-Venkata et al., 2025).
Batching ist ebenfalls weniger effizient. In einem dichten Modell folgt jedes Token in einem Batch dem gleichen Rechenweg. In einem MoE-Modell werden verschiedene Tokens im selben Batch an verschiedene Experten geroutet, was Speicherzugriffsmuster erzeugt, die GPUs weniger effizient verarbeiten.
Wann dichte Modelle gewinnen
Vergleichen Sie all das mit Qwen3.5-9B. Es ist dense. Jedes Token nimmt den gleichen Rechenweg. Die Latenz ist vorhersagbar. Der Durchsatz ist konstant. Es gibt keine Spitzen durch kalte Experten. Kein Routing-Overhead. Es wird Qwen3.5-35B-A3B auf Benchmarks nicht schlagen, aber für latenzempfindliche Anwendungen — Echtzeit-Chat, interaktive Coding-Assistenten, Sprachschnittstellen — kann diese Vorhersagbarkeit wichtiger sein als reine Leistungsfähigkeit. Sie können beide auf Prositronic deployen und vergleichen — nutzen Sie dafür unseren Hardware-Kompatibilitätscheck.
Häufig gestellte Fragen
Warum braucht mein MoE-Modell so viel VRAM, wenn nur wenige Experten aktiv sind?
Alle Experten-Gewichte müssen für sofortiges Routing im Speicher liegen. Qwen3.5-35B-A3B lädt 35,95 Milliarden Parameter, aktiviert aber nur etwa 3 Milliarden pro Token. Der Router muss jederzeit jeden Experten auswählen können, daher bleiben alle Experten geladen, auch wenn die meisten bei jedem Forward Pass untätig sind.
Kann ich DeepSeek V3 auf einer einzelnen GPU betreiben?
Ja, mit Expert Offloading. Die TQ1_0-Quantisierung passt auf eine 24-GB-GPU mit 96–128 GB System-RAM, aber erwarten Sie etwa 1–2 Tokens pro Sekunde (Community-Benchmarks, 2025). Für nutzbare Geschwindigkeiten benötigen Sie mindestens zwei 48-GB-GPUs oder vier 24-GB-GPUs mit der Q4_K_M-Quantisierung und tensor parallelism.
Was ist die minimale Quantisierung für MoE-Modelle?
Q4_K_M. Unterhalb dieser Schwelle führt die Verschlechterung der Router-Gewichte dazu, dass Experten falsch ausgewählt werden, was die Ausgabequalität stärker reduziert als die entsprechende Quantisierung bei dichten Modellen. MoE-Modelle erleiden spürbaren Genauigkeitsverlust bei extremer Quantisierung unter 4 Bit (Huang et al., 2025).
Ist ein MoE-Modell immer besser als ein dichtes Modell mit ähnlicher aktiver Größe?
Nicht für latenzempfindliche Anwendungen. Qwen3.5-9B (dense) liefert vorhersagbare Pro-Token-Latenz ohne Routing-Overhead. Qwen3.5-35B-A3B (MoE) schneidet auf Benchmarks besser ab, hat aber aufgrund des Expert-Routings variable Latenz. Wählen Sie dense, wenn Sie konsistente Antwortzeiten brauchen; wählen Sie MoE, wenn Sie maximale Leistung pro Rechen-Euro benötigen.
Was ist der Unterschied zwischen feingranularem und grobgranularem MoE?
DeepSeek V3 und Qwen3.5-35B-A3B nutzen 256 kleine Experten (feingranular). Llama 4 Scout nutzt 16 größere Experten (grobgranular). Feingranulares Routing ermöglicht präzisere Spezialisierung, erfordert aber mehr Speicherverwaltung. Grobgranulare Modelle sind einfacher zu deployen, aber weniger flexibel in der Zuweisung von Rechenleistung.
Nächste Schritte
Das Wichtigste auf einen Blick:
- MoE ≠ weniger VRAM. Alle Experten-Gewichte müssen geladen sein, unabhängig davon, wie viele pro Token aktiv sind.
- Nicht unter Q4_K_M gehen bei MoE-Modellen. Die Router-Qualität verschlechtert sich unterhalb von 4-Bit-Quantisierung stark.
- Expert Offloading ist unverzichtbar für Single-GPU-Setups. Nutzen Sie
-ot ".ffn_.*_exps.=CPU"in llama.cpp. - Dichte Modelle gewinnen bei Latenz-Vorhersagbarkeit. Wählen Sie basierend auf der Varianz-Toleranz Ihrer Anwendung.
- Tensor parallelism schlägt expert parallelism bei Multi-GPU-Deployments, insbesondere mit NVLink.
Deployen Sie sowohl Qwen3.5-9B als auch Qwen3.5-35B-A3B auf Prositronic, um die Unterschiede selbst zu erleben. Beginnen Sie mit der Qwen3.5-9B-Deploy-Seite und der Qwen3.5-35B-A3B-Deploy-Seite, und prüfen Sie dann die Hardware-Kompatibilitätsseite, um die richtige GPU für Ihre Anforderungen zu finden.