Mixture of Experts VRAM: Gesamtparameter und aktive Parameter, Experten-Parallelismus und CPU-Offload der Experten

Mixture of Experts VRAM: die Gesamtparameter bestimmen den Speicher

Ein Mixture-of-Experts-Modell (MoE) braucht GPU-Speicher für alle seine Parameter, weil jedes Token an jeden Experten geleitet werden kann. Für ein bestimmtes Token rechnen nur die ausgewählten Experten; die aktiven Parameter bestimmen daher die Rechenlast je Token und, zusammen mit der Speicherbandbreite der Karte, das Tempo, das ein Nutzer sieht. Metas Llama-4-Beitrag vom 5. April 2025 hält fest, hier übersetzt: „Während alle Parameter im Speicher abgelegt sind, wird beim Serving dieser Modelle nur eine Teilmenge der gesamten Parameter aktiviert“.

Für den Hardwarekauf heißt das, den Speicher nach der Gesamtzahl der Parameter und der Größe des Checkpoints auszulegen und dann den KV-Cache je Gespräch hinzuzurechnen, genau wie bei einem dichten Modell. Die Zahl der aktiven Parameter verringert den Speicherbedarf nicht. Sie verändert, wie schnell das Modell auf einer bestimmten Karte erzeugt und wie viel die Karten austauschen, wenn das Modell aufgeteilt ist. Unsere LLM-Hardware-Anforderungen je Modell enthalten die Dimensionierung je Modell; dieser Artikel erklärt den Mechanismus hinter diesen Zahlen.

Wie aktuelle MoE-Modelle jedes Token weiterleiten

Jede MoE-Schicht ersetzt den dichten Feed-Forward-Block durch viele kleinere Expertenblöcke und einen Router, der je Token einige davon auswählt. Attention, Embeddings und der Router bleiben dicht und laufen für jedes Token. Die Modelle auf unseren Seiten zur Dimensionierung unterscheiden sich vor allem darin, wie viele Experten sie haben und wie viele sie auswählen.

gpt-oss-120b hat 36 Schichten mit je 128 Experten und leitet jedes Token an 4 davon weiter, wie seine config.json aufführt, und OpenAIs Card nennt „117B Parameter mit 5,1B aktiven Parametern“. Llama 4 Maverick hat „128 geroutete Experten und einen Shared Expert“, und in Metas Worten: „Jedes Token wird an den Shared Expert und außerdem an einen der 128 gerouteten Experten gesendet.“ Die Card von Moonshot AI zu Kimi-K2.6 nennt 384 Experten, von denen je Token 8 ausgewählt werden, und einen Shared Expert, bei 1T Parametern und 32B aktiven. Qwen3.8-Flash-Next aktiviert „10 Routed + 1 Shared“ von 512 Experten, und die config.json von GLM-5.3 nennt 256 geroutete Experten, von denen je Token 8 aktiv sind, und einen Shared Expert.

Die Experten halten den größten Teil der Gewichte. OpenAIs Model Card zu gpt-oss vom 5. August 2025 hält fest: „Die MoE-Gewichte machen 90+ % der gesamten Parameterzahl aus“. Deshalb quantisieren diese Veröffentlichungen zuerst die Experten: gpt-oss und DeepSeek-V4-Flash liefern FP4-Experten, Kimi-K2.6 INT4-Experten, während die Attention in BF16 oder FP8 bleibt. Die RTX PRO 6000 und der DGX Spark rechnen FP4 direkt, und die H200 NVL hält 4-Bit-Gewichte, rechnet sie aber mit höherer Präzision, wie unser Leitfaden zu FP8, NVFP4 und MXFP4 erklärt.

Gesamt- und aktive Parameter aktueller MoE-Modelle

Parameter aus den Model Cards der Hersteller und, für DeepSeek-V4-Flash, aus DeepSeeks Release Note und NVIDIAs NVFP4-Card; Checkpoints und Konfigurationen von unseren Modellseiten (gelesen am 9. und 10. Oktober 2026). „Eine Karte“ bedeutet eine RTX PRO 6000 oder eine H200 NVL. Die Zuordnungen sind unsere Schätzungen für ein Gespräch mit 32K, siehe unseren Überblicksartikel und die Seiten zu DeepSeek, Kimi K2, Qwen, Llama 4 und GLM; kein Dokument von Moonshot AI oder vLLM betreibt Kimi K2 auf der RTX PRO 6000.

Für DeepSeek-V4-Flash weichen die veröffentlichten Gesamtzahlen voneinander ab. DeepSeeks Release Note vom 24. April 2026 nennt „284B insgesamt / 13B aktive Parameter“, und sein Changelog vom 31. Juli 2026 hält fest, dass das Release -0731 „dieselbe Modellarchitektur und Größe wie DeepSeek-V4-Flash-Preview beibehält“. NVIDIAs Card zu seiner NVFP4-Version von -0731, veröffentlicht am 31. August 2026, nennt „304B insgesamt und 13B aktiviert“. Unsere Dimensionierung geht vom Checkpoint mit 167 GB aus, der von keiner der beiden Zahlen abhängt.

Gesamt- und aktive Parameter können weit auseinanderliegen. Kimi-K2.6 rechnet je Token mit 32B Parametern, weniger als ein dichtes 70B-Modell, doch seine 595,2 GB INT4-Gewichte brauchen acht H200 NVL oder, nach dem Speicher gerechnet, acht RTX PRO 6000, wie unsere Kimi-K2-Hardware-Anforderungen darlegen. gpt-oss-120b liegt am anderen Ende: 5,1B aktive Parameter und ein Checkpoint mit 65,3 GB, der auf eine Karte passt.

Wir bauen Inferenz-Server mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Nennen Sie uns das MoE-Modell, das Sie betreiben wollen, mit Präzision und Zahl der Gespräche in der Spitze, und wir antworten mit Konfiguration und Angebot.

Was aktive Parameter ändern: Tempo je Nutzer und Cache

Wenn ein Nutzer Text erzeugt, erfordert jedes neue Token, die Gewichte, die es nutzt, aus dem GPU-Speicher zu lesen. Bei einem MoE-Modell sind das die Attention-Gewichte, alle dichten Schichten und Shared-Expert-Schichten sowie die gerouteten Experten. Llama 4 Maverick hat 17B aktive Parameter und liest in FP8 daher nach unserer Rechnung mindestens 17 GB Gewichte je Token, während es etwa 417 GB vorhält. Ein Token liest mehr als das, weil manche Gewichte in 16 Bit bleiben: Metas FP8-Veröffentlichung ist mit 416,8 GB etwa 15 GB größer als die Hälfte ihrer BF16-Veröffentlichung mit 803,2 GB.

NVIDIAs FP8-Checkpoint des dichten Llama 3.3 70B hat 72,7 GB, passt auf eine H200 NVL, und jedes Token liest fast alles davon. Maverick braucht daher viermal so viele H200 NVL wie das 70B-Modell und liest nach unserer Rechnung weniger als halb so viele Bytes je Token.

Dieser Vorteil ist bei einer einzigen Anfrage am größten. Sind viele Anfragen in Bearbeitung, gehen die Token eines Decode-Schritts an verschiedene Experten, und ein Schritt liest weit mehr als den Anteil der Experten, der auf ein Token entfällt. NVIDIAs Blog zu Mixture of Experts macht dieselbe Beobachtung für das Training: „Da Token im Training gebündelt verarbeitet werden, werden die meisten, wenn nicht alle Experten genutzt.“ Nach unserer Lesart fällt das Tempo je Nutzer bei einem MoE-Modell mit steigender Last schneller, als die Zahl der aktiven Parameter vermuten lässt. NVIDIAs TensorRT-LLM-Blog zu Experten-Parallelismus, zuletzt aktualisiert am 26. September 2026, schreibt, dass großskaliger EP die MoE-Berechnung verkürzt, „indem er den Druck beim Laden der Expertengewichte verringert“.

Der KV-Cache hängt überhaupt nicht von den Experten ab. Er folgt dem Attention-Layout: Unsere Seiten nennen 1,125 GiB 16-Bit-Cache je Gespräch mit 32K bei gpt-oss-120b, das den vollen Kontext in der Hälfte seiner Schichten hält, 2,14 GiB 16-Bit-Cache bei Kimi K2 mit Latent Attention und etwa 0,12 GiB FP8-Cache bei DeepSeek-V4-Flash mit komprimierter Attention. Wie viele Nutzer eine Karte bedient, hängt daher ebenso vom Attention-Design ab wie von den Gewichten.

Die 128 GB Unified Memory eines DGX Spark fassen gpt-oss-120b, und seine Speicherbandbreite von 273 GB/s, niedriger als die der RTX PRO 6000 oder der H200 NVL, passt zu Modellen, die je Token wenige Gewichte lesen. Nach unserer Lesart sind MoE-Modelle mit wenigen aktiven Parametern diejenigen, die auf einem Spark sinnvoll sind, und unser Überblicksartikel hält fest, dass dort das Tempo ein Team früher begrenzt als der Speicher.

Dichte Modelle und MoE-Modelle: was sich bei der GPU-Auslegung ändert

Metas Llama-4-Beitrag (5. April 2025), NVIDIAs Blog zu Mixture of Experts (14. März 2024), die vLLM-Dokumentation zum Expert Parallel Deployment (2. Oktober 2026) und die Server-Dokumentation von llama.cpp, gelesen am 10. Oktober 2026; Zeilen mit „nach unserer Lesart“ sind unsere Interpretation.

Experten-Parallelismus auf RTX PRO 6000 und H200 NVL

Die Dokumentation von vLLM beschreibt Experten-Parallelismus (EP) als Anordnung, die es „erlaubt, die Experten in Mixture-of-Experts-Modellen (MoE) auf getrennten GPUs bereitzustellen“. Eingeschaltet wird er mit --enable-expert-parallel, und die Dokumentation gibt „EP_SIZE = TP_SIZE × DP_SIZE“ an. Bei einer Tensor-Parallel-Größe von 1 werden die Attention-Gewichte über die Datenparallel-Ranks repliziert; oberhalb von 1 werden sie innerhalb jeder Datenparallelgruppe aufgeteilt. Jede MoE-Schicht schickt dann die Token an die Karten, die ihre Experten halten, und sammelt die Ergebnisse ein, das Dispatch und Combine, das unser Artikel zu Tensor-, Pipeline- und Experten-Parallelismus über PCIe und NVLink beschreibt.

Auf der RTX PRO 6000, die in keiner Edition NVLink hat, laufen diese All-to-All-Austausche über PCIe Gen5. NVIDIAs H200-Seite führt für die H200 NVL eine Zweifach- oder Vierfach-NVLink-Brücke mit „900 GB/s je GPU“ neben 128 GB/s für PCIe Gen5, und in einem Server mit acht Karten bilden die Brücken nach unserer Lesart zwei Domänen aus je vier Karten, die über PCIe verbunden sind. Die vLLM-Seite führt ihre All-to-All-Backends auf Basis von DeepEP für Prefill und Decode über mehrere Knoten und die von FlashInfer für NVLink-Systeme mit mehreren Knoten. Die README von DeepEP selbst verlangt „NVLink für die Kommunikation innerhalb eines Knotens“ und bietet PCIe-Kernel nur in einem experimentellen Branch an; auf Servern mit RTX PRO 6000 würden wir daher mit dem Standard-Backend allgather_reducescatter von vLLM planen.

Die Rezepte auf unseren Modellseiten zeigen EP auf beiden Plattformen. Das vLLM-Rezept für DeepSeek-V4-Flash setzt --enable-expert-parallel auf acht RTX PRO 6000 und hält für den Checkpoint -0731 fest: „Serving ohne spekulatives Decoding wurde auf 8× RTX PRO 6000 (PCIe, kein NVLink) verifiziert“, wie unsere DeepSeek-Hardware-Anforderungen zitieren. Sein Rezept für DeepSeek-V3.2 bevorzugt -dp 8 --enable-expert-parallel, was jeder Karte ihren eigenen KV-Cache gibt, die Gewichte außerhalb der Experten aber auf jeder Karte wiederholt.

Experten werden nicht gleichmäßig genutzt. NVIDIAs TensorRT-LLM-Blog berichtet, dass „ein Ungleichgewicht der Arbeitslast auf EP-Ebene bei großskaliger EP-Inferenz häufig ist“, verursacht dadurch, dass stark genutzte Experten auf demselben Rank liegen. Der Expert Parallel Load Balancer von vLLM, --enable-eplb, „sammelt bei jedem Forward-Pass Lastdaten und verteilt die Experten regelmäßig neu“.

Wir bauen Server mit vier oder acht H200 NVL und ihren NVLink-Brücken oder mit Karten der RTX PRO 6000 Server Edition und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Beschreiben Sie das Modell, seine Präzision und Ihren Rack-Standort im Formular unten.

MoE-Experten in den CPU-Speicher auslagern: llama.cpp und vLLM

Passen die Experten nicht auf die Karten, können beide verbreiteten Engines Gewichte im Systemspeicher halten. Die Server-Dokumentation von llama.cpp führt --cpu-moe, um „alle Mixture-of-Experts-Gewichte (MoE) auf der CPU zu halten“, und --n-cpu-moe N für die Experten der ersten N Schichten. Das allgemeinere --override-tensor weist Tensoren nach Namensmuster einem Puffertyp zu. Liegen alle Schichten auf der GPU (-ngl all), bleiben Attention und die gemeinsam genutzten Schichten dort, und die Experten liegen im Systemspeicher.

vLLM bietet --cpu-offload-gb, „Der Speicher in GiB, der je GPU auf die CPU ausgelagert wird“, und --cpu-offload-params, dessen Dokumentation zeigt, dass das Namenssegment „experts“ auf ein Expertengewicht passt. Die Dokumentation warnt, dass Offloading „eine schnelle CPU-GPU-Verbindung erfordert, da ein Teil des Modells in jedem Forward-Pass des Modells im laufenden Betrieb aus dem CPU-Speicher in den GPU-Speicher geladen wird“.

Mit Offload wird die Erzeugung langsamer. Gewichte auf der Karte werden nach NVIDIAs Angaben mit 1.597 GB/s auf der RTX PRO 6000 Server Edition und mit 4,8 TB/s auf der H200 NVL gelesen. Ausgelagerte Gewichte kommen in vLLM über eine Verbindung mit PCIe 5.0 x16, für die NVIDIA 64 GB/s je Richtung angibt. In llama.cpp verarbeitet die CPU sie mit der Geschwindigkeit des Systemspeichers, oder llama.cpp kann mit --op-offload, das standardmäßig eingeschaltet ist, „Tensoroperationen des Hosts auf das Device auslagern“, was die Gewichte wiederum über PCIe bewegt. Nach unserer Lesart eignet sich Offload daher für Tests und einzelne Nutzer. Die Offloads in den vLLM-Rezepten hinter unseren Modellseiten verschieben große Lookup-Tabellen statt Experten: die N-Gram-Tabelle von Qwen3.8-Flash-Next und die Engram-Tabellen von DeepSeek-V4.1-Flash.

Was wir liefern

Wir liefern die RTX PRO 6000 als Workstation, Max-Q und Server Edition, die H200 NVL mit ihren Zweifach- und Vierfach-NVLink-Brücken und die DGX Spark Founders Edition, als Karten oder in nach Auftrag gebauten KI-Servern. Für ein MoE-Modell legen wir die Karten nach dem Checkpoint und dem Cache je Gespräch aus und wählen zwischen Replikaten, einer Aufteilung über PCIe oder einer NVLink-Domäne. Alles kommt unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie, und unser Sortiment professioneller GPUs führt jede Karte. Das Modell mit vLLM bereitzustellen, mit RAG und MLOps darauf, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ