Mixture of Experts: Was aktive Parameter wirklich aussagen

Ein Modell mit Mixture of Experts kann pro Token weniger Rechenarbeit leisten und trotzdem enorm viel Platz beim Hosting beanspruchen. Das Sprachmodell Kimi K3.1 Pro von Moonshot AI hat laut offizieller Ankündigung 2.8T Parameter insgesamt, aber nur 104B aktive Parameter pro Token. Die kleinere Zahl hilft, den Rechenaufwand einzuordnen. Für die Speicherung der Modellgewichte bleibt die größere entscheidend.

Parameterzahlen und Quellenangaben wurden am 24. Oktober 2026 geprüft. Die folgenden Berechnungen der aktiven Anteile stammen von uns. Sie sind keine Messwerte für Geschwindigkeitsgewinne, Speicherersparnis oder Qualität.

Was ist Mixture of Experts?

Mixture of Experts, kurz MoE, stellt einem Modell viele interne Verarbeitungsnetze bereit, wählt für eine Eingabe aber nur einige davon aus. Ein Parameter ist ein im Training erlernter Zahlenwert. Die gespeicherten Parameter werden üblicherweise als Modellgewichte bezeichnet. Ein Token ist eine kleine Einheit der Ein- oder Ausgabe, häufig ein Wortfragment.

Man kann sich das wie ein Beratungszentrum mit vielen Räumen vorstellen. Am Empfang wird jeder Besucher in die Räume geschickt, die für seinen Termin benötigt werden. Nur wenige Räume sind mit diesem Besucher beschäftigt, doch das Gebäude enthält weiterhin alle Räume. In einer MoE-Schicht übernimmt der Router die Rolle des Empfangs; die Experten entsprechen den Räumen.

Der Vergleich hat eine Grenze: Gemeint sind erlernte numerische Netze, keine Abteilungen mit menschlichen Berufsbezeichnungen. Man kann also nicht davon ausgehen, dass ein Rechtsexperte, ein Programmierexperte und ein Buchhaltungsexperte auf ihren Einsatz warten.

Wie funktioniert Mixture of Experts?

Der Router wählt Verarbeitungspfade innerhalb des Modells aus; anschließend werden deren Ergebnisse zusammengeführt. Ein Transformer verarbeitet die Zusammenhänge zwischen Tokens im jeweiligen Kontext. In gängigen MoE-Transformern ersetzen mehrere Expertennetze einen Feedforward-Block. Dieser Block wandelt die interne numerische Darstellung eines Tokens um. Attention ist ein davon getrennter Mechanismus, über den das Token seinen umgebenden Kontext einbeziehen kann.

Der Ablauf sieht so aus:

1. Die aktuelle Darstellung eines Tokens erreicht eine MoE-Schicht.
2. Ein im Training erlernter Router, auch Gate genannt, bewertet die Experten.
3. Er wählt eine Teilmenge aus, häufig die Experten mit den höchsten Bewertungen. Das heißt Top-k-Routing, wobei k die Anzahl der ausgewählten Experten angibt.
4. Die ausgewählten Experten verarbeiten diese Darstellung. Ihre Ausgaben werden gewichtet und zusammengeführt, bevor die Verarbeitung weitergeht.

Das geschieht in den MoE-Schichten des Modells. Je nach Token und Schicht können daher andere Experten zum Zug kommen. Die Architekturerklärung von PyTorch beschreibt die gewichtete Zusammenführung; das Modellpaper von Mistral zeigt, wie sich die Auswahl zwischen den Schichten unterscheidet.

Was bedeutet Sparse Mixture of Experts?

Sparse bedeutet, dass für ein bestimmtes Token nur eine Teilmenge der Experten arbeitet. Auf diese Form beziehen sich die Angaben zu gesamten und aktiven Parametern in heutigen Modellbeschreibungen, den sogenannten Model Cards. Die übrigen Experten können andere Tokens verarbeiten, auch solche aus demselben Batch.

Ein dichter Feedforward-Block wendet dagegen sein vollständiges Netz auf jedes Token an. Sparse-Expertenschichten bieten mehr gespeicherte Kapazität, ohne dass jedes Token jeden Experten durchlaufen muss. Gemeinsam genutzte Komponenten, darunter Attention in diesen Beispielen, müssen weiterhin rechnen.

Auch ein MoE-Modell bleibt ein einzelnes Modell

MoE-Routing ist etwas anderes als die Auswahl zwischen API-Modellen oder eine Abstimmung mehrerer Chatbots. Router und Experten werden als Bestandteile eines gemeinsamen Netzes trainiert. Eine Anwendung schickt ihre Anfrage normalerweise an dieses Netz. Sie wählt keinen einzelnen Experten aus wie ein Produkt aus einem Menü.

Für die Anwendungsentwicklung verhindert diese Unterscheidung einen folgenreichen Denkfehler: Mit einem MoE-Modell erhält die Anwendung kein steuerbares Team spezialisierter Agenten.

Mixture of Experts: Gesamte und aktive Parameter gehören zusammen

Die Gesamtzahl beschreibt den Umfang der gespeicherten Modellparameter; die aktive Zahl beschreibt den angegebenen Rechenpfad pro Token. Keine der beiden Zahlen ist eine vollständige Hardwarespezifikation. B steht für Milliarden, T für Billionen.

Die letzte Spalte ergibt sich aus aktiven Parametern geteilt durch Gesamtparameter, jeweils gerundet. Sie ordnet die veröffentlichten Herstellerangaben ein und ist keine modellübergreifende Effizienzrangliste. Architektur und Zählweise können sich unterscheiden.

Kimi K3.1 Pro: Ein kleiner Anteil eines sehr großen Modells

Kimi K3.1 Pro zeigt, weshalb die aktive Parameterzahl nicht als Größe des zu hostenden Modells taugt. In derselben Einheit ausgedrückt beträgt die von Moonshot angegebene Gesamtzahl 2,800B. Daraus folgt gerundet: 104 ÷ 2,800 × 100 = 3.7%.

Die gemeldete aktive Zahl ist also nur ein kleiner Teil der Gesamtzahl. Daraus folgt weder, dass eine Inferenzinstallation die übrigen Gewichte verwerfen kann, noch dass die API nur diesen Bruchteil der Latenz eines dichten Modells benötigt. Mit anderen Tokens und Schichten ändert sich auch der Verarbeitungspfad.

Moonshots Blogbeitrag zur Veröffentlichung beschreibt Pro als K3 mit zusätzlichem Nachtraining und verwendet die gerundete Bezeichnung „3T-class“. Die offizielle Ankündigung nennt das genaue Wertepaar 2.8T / 104B. Für die Einordnung der Modellgröße ist diese konkrete Spezifikation maßgeblich.

Für die Entwicklung über eine API kommt das Modell als Testkandidat infrage. Beim Eigenbetrieb ist die Verfügbarkeit eine zusätzliche Voraussetzung: Zum Prüfdatum hatte Moonshot die vollständigen Gewichte bis zum 4. November 2026 angekündigt. Eine angekündigte Veröffentlichung liefert noch keine einsetzbaren Modelldateien. Der Artikel zu Kimi K3.1 Pro behandelt die Entscheidung rund um diese Veröffentlichung.

Qwen3-235B-A22B: Die aktive Zahl ersetzt nicht die Gesamtzahl

Bei Qwen3-235B-A22B steckt die Unterscheidung bereits im Namen. Qwens ursprüngliche Model Card nennt 235B Parameter insgesamt und 22B aktivierte Parameter, bei 128 Experten und 8 aktivierten Experten.

Für den Parameteranteil ergibt sich gerundet 22 ÷ 235 × 100 = 9.4%. Bei einem internen Dokumentenassistenten gibt das einen Hinweis darauf, wie das Modell den Rechenaufwand pro Token begrenzt. Die Speicherplanung muss trotzdem den vollständigen gewählten Checkpoint und die Zustandsdaten der bearbeiteten Anfragen berücksichtigen.

Aus „22B aktiv“ darf deshalb nicht „braucht so viel Platz wie ein dichtes 22B-Modell“ werden. Ebenso wichtig ist, die Zahlen immer dem konkreten Checkpoint zuzuordnen: Der Name einer Modellfamilie allein reicht für die Auswahl von Gewichtsdateien, Präzision und Inferenzkonfiguration nicht aus.

Mixtral 8x7B: Warum der Modellname keine Rechenaufgabe ist

Mixtral 8x7B enthält gemeinsam genutzte Komponenten. Sein Name ist deshalb keine Aufforderung zum Multiplizieren. Mistrals Blogbeitrag zur Veröffentlichung nennt 46.7B Parameter insgesamt und 12.9B pro Token genutzte Parameter. Wer die Zahlen im Namen multipliziert, zählt die gemeinsam genutzten Komponenten so, als gehörten sie zu eigenständigen vollständigen Modellen.

Mistrals Paper beschreibt Feedforward-Expertennetze neben gemeinsam genutzter Attention. In jeder Schicht wählt der Router 2 von 8 Experten aus. Es handelt sich also nicht um acht unabhängige, vollständige Modelle.

Mit dem veröffentlichten Parameterpaar ergibt sich gerundet 12.9 ÷ 46.7 × 100 = 27.6%. Die Auswahl von 2 aus 8 Experten entspricht dagegen 25% der Experten und hat somit einen anderen Nenner. Die gemeinsam genutzten Komponenten sind ein Grund dafür, dass Expertenanteil und Parameteranteil voneinander abweichen.

Für die Bereitstellungsplanung zählen die Gesamtangabe in der Model Card und die tatsächlichen Checkpoint-Dateien. Weder der Produktname noch die Zahl ausgewählter Experten verrät den vollständigen Speicherbedarf der Gewichte.

Warum weniger Rechenarbeit nicht automatisch kürzere Latenz bedeutet

Sparse Routing verringert die Rechenarbeit der Experten gegenüber einem vergleichbar großen dichten Netz. Es verspricht jedoch nicht die Antwortzeit eines kleineren dichten Modells. So kann MoE die Inferenz großer Modelle pro Token günstiger machen, während Speicher- und Kommunikationsaufwand erheblich bleiben.

Rechenoperationen sind nur ein Teil der Inferenz, also der Ausführung eines trainierten Modells. Der Server liest auch Gewichte, führt gemeinsam genutzte Komponenten aus, leitet Token-Darstellungen weiter und überträgt sie mitunter zwischen Geräten. Eine kleinere aktive Parameterzahl lässt diese Arbeit nicht verschwinden. Shazeer und Kollegen nennen im ursprünglichen Sparse-MoE-Paper kleine Batches pro Experte und die Netzwerkbandbreite als Leistungsgrenzen.

Durchsatz und Latenz beantworten unterschiedliche betriebliche Fragen. Durchsatz beschreibt, wie viel Arbeit ein Dienst pro Zeiteinheit erledigt. Latenz beschreibt, wie lange eine einzelne Anfrage wartet. Eine nächtliche Warteschlange zur Dokumentenverarbeitung kann von einer Konfiguration profitieren, die große Batches effizient abarbeitet. Ein interaktiver Supportassistent muss dagegen schnell eine erste brauchbare Antwort liefern.

Batching, also die gemeinsame Verarbeitung mehrerer Tokens oder Anfragen, kann die Hardware besser auslasten. Verschiedene Tokens können allerdings unterschiedliche Experten auswählen. Deshalb kann ein Batch wesentlich größere Teile des Modells nutzen als ein einzelnes Token. Die aktive Parameterzahl gibt nicht an, auf wie viele Gewichte der Server über einen vollständigen Batch hinweg zugreift.

Auch Prompt-Verarbeitung und Token-Erzeugung beanspruchen das System unterschiedlich. Prefill verarbeitet die Eingabe; Decode erzeugt die nachfolgenden Tokens. vLLM, eine Software für den Betrieb von Sprachmodellen, dokumentiert unterschiedliche Verfahren für die Kommunikation zwischen Experten bei Prefill mit hohem Durchsatz und Decode mit niedriger Latenz. Unser Leitfaden zur LLM-Inferenz erklärt diese Phasen und die Messwerte, die getrennt betrachtet werden sollten.

Bei der API-Auswahl zählt das beobachtete Verhalten mit den eigenen Anfragen. Aus einem Parameterpaar lässt sich weder ablesen, wie stark ein Anbieter Anfragen bündelt, noch wie lang seine Warteschlange ist oder wie gut seine Hardware zum Modell passt.

Welche Folgen die Architektur im Betrieb hat

MoE verlagert einen Teil der Infrastrukturlast: Weniger wiederholte Rechenarbeit steht der Speicherung und Koordination eines größeren Modells gegenüber. Entscheidend ist, ob dieser Tausch zum eigenen Lastprofil passt.

Speicher: Jeder Experte braucht einen Platz

Dass ein Experte für dieses Token inaktiv ist, macht ihn für die Bereitstellung nicht entbehrlich. Im üblichen Betrieb mit dauerhaft geladenen Gewichten bleibt der vollständige Gewichtssatz über das Inferenzsystem verteilt im Speicher, obwohl jedes Token nur einen Teil davon nutzt. Die Erklärung von PyTorch benennt diesen Speicherbedarf ausdrücklich.

Als erste Näherung gilt: Speicherbedarf der Gewichte ≈ Gesamtzahl der Parameter × Bytes pro gespeichertem Parameter. Dabei bleibt es eine Näherung: Die Präzision kann je nach Tensor variieren. Dateimetadaten, Auffüllbereiche, Replikate und Speicherbelegungen zur Laufzeit kommen hinzu.

Die Gewichte machen außerdem nicht das gesamte Speicherbudget aus. Der KV-Cache speichert Attention-Schlüssel und -Werte vorheriger Tokens, damit sie erneut verwendet werden können. Ein Dokumentenassistent mit längeren Gesprächen oder mehr gleichzeitigen Anfragen braucht zusätzlichen Speicher für diese Anfragezustände. Der Artikel zum KV-Cache erläutert diese eigenständige Begrenzung.

Quantisierung, also die Speicherung von Gewichten mit geringerer numerischer Präzision, kann deren Speicherbedarf senken. Sie macht aus Gesamtparametern keine aktiven Parameter und ersetzt nicht die Prüfung der Ausgabequalität. Unser Leitfaden zur LLM-Quantisierung behandelt die Wahl von Format und Präzision. Den Mechanismus beschreibt die Quantisierungsübersicht von Hugging Face.

Durchsatz: Ein geladenes Modell erfüllt noch kein Leistungsziel

Auch ein Modell, das sich erfolgreich laden lässt, kann die Anforderungen an den Dienst verfehlen. Expertenparallelität verteilt Experten auf mehrere Geräte. So lässt sich ein Modell betreiben, das größer als der Speicher eines einzelnen Geräts ist. Dafür müssen die Token-Darstellungen zu den Geräten mit den ausgewählten Experten übertragen und die Ergebnisse anschließend zusammengeführt werden.

Damit werden die Verbindungen zwischen den Geräten, die sogenannten Interconnects, Teil der Inferenzplanung. Dieselbe Speicherkapazität auf schlecht verbundenen Rechnern ist nicht gleichwertig mit der Kapazität in einem gut vernetzten System. Das ergibt sich unmittelbar aus dem Kommunikationsmuster, das PyTorch für seine Implementierung der Expertenparallelität beschreibt.

Bei einem internen Assistenten mit wenigen Anfragen besteht das praktische Problem womöglich darin, dass fest vorgehaltene Kapazität kaum genutzt wird. Bei einem stark ausgelasteten Batch-Dienst geht es eher darum, die Experten kontinuierlich mit Arbeit zu versorgen. Die aktive Parameterzahl allein entscheidet über keines dieser Ergebnisse.

Routing: Häufig gewählte Experten können zum Engpass werden

Ein erlernter Router garantiert keine gleichmäßige Hardwareauslastung. NVIDIAs Analyse des Mixtral-Routings zeigte, dass eine thematisch konzentrierte Anfragelast die Experten ungleichmäßig auslasten kann. Manche Ausführungsprozesse sind früh fertig, während andere noch arbeiten.

Ein breit gemischter Demo-Datensatz reicht deshalb nicht aus, wenn ein Dienst überwiegend Verträge oder Code verarbeitet. Getestet werden muss genau diese thematische Konzentration, einschließlich der langsamen Anfragen. Der Durchschnitt allein genügt nicht.

Inferenzsoftware kann das ausgleichen, doch auch dieser Ausgleich braucht Ressourcen. vLLM dokumentiert den Lastausgleich mithilfe zusätzlicher Expertenkopien und weist darauf hin, dass diese Kopien GPU-Speicher belegen, der sonst für den KV-Cache verfügbar wäre. Passen die Modellgewichte gerade eben in den Speicher, bleibt unter Umständen zu wenig Platz für eine leistungsfähige Betriebskonfiguration.

Ein Mixture-of-Experts-LLM auswählen: API oder Eigenbetrieb?

Bei der API-Nutzung zählt der tatsächlich gelieferte Dienst. Beim Eigenbetrieb muss zusätzlich die vollständige Bereitstellung bewertet werden. Beide Wege brauchen brauchbare Ergebnisse. Nur bei einem davon liegt die Verteilung der Experten jedoch direkt in der eigenen Verantwortung.

Für die Anwendungsentwicklung mit einer API ist die Architektur nützliches Hintergrundwissen, aber noch kein Wechselgrund. Zu prüfen sind repräsentative Aufgaben, die Befolgung von Anweisungen, gegebenenfalls die Tool-Nutzung sowie die Zeit bis zum ersten Token und bis zur vollständigen Antwort bei der erwarteten Zahl gleichzeitiger Anfragen. Fehlversuche und Wiederholungen gehören ebenfalls ins Protokoll. Die Inferenzeffizienz des Anbieters legt weder die Rechnung noch den Aufwand fest, der für ein akzeptables Ergebnis nötig ist.

Beim Eigenbetrieb beginnt die Prüfung mit dem konkret herunterladbaren Checkpoint, seiner Lizenz und einer unterstützten Inferenzimplementierung. Danach folgen Gewichtspräzision, Speicherbedarf des vollständigen Modells, Reserven für den Cache, Geräteverbindungen und Leistung unter Last. Unser Leitfaden zu Open-Weight-Modellen trennt den Zugriff auf die Dateien von den Rechten und Pflichten beim Betrieb.

Wer einen Dienst mit verbindlichen Leistungszusagen einkauft, muss klären, ob der Kandidat auf der vorgesehenen Infrastruktur brauchbare Arbeit innerhalb der geforderten Antwortzeit erledigt. „Billionen insgesamt, Milliarden aktiv“ beschreibt eine Architektur und ist keine Leistungsgarantie.

1. 1

   Vor dem Modellvergleich das Lastprofil festlegen

   Die Testanfragen sollten repräsentativ sein und klare Abnahmekriterien haben. Interaktive Aufgaben und Warteschlangenverarbeitung werden getrennt betrachtet. Lange Eingaben und die thematischen Schwerpunkte der tatsächlichen Anwendung gehören in den Test.

2. 2

   Den vorgesehenen Betriebsweg testen

   Bei einer API werden der vorgesehene Anbieter und Endpunkt geprüft. Beim Eigenbetrieb werden Checkpoint, Präzision, Laufzeitumgebung und Hardware genau festgehalten. Ein anderer Betriebsweg bedeutet ein anderes Betriebsergebnis.

3. 3

   Kapazität und Qualität gemeinsam prüfen

   Die Zahl gleichzeitiger Aufgaben wird erhöht, während Speicherverbrauch, Wartezeit, Ausgabequalität und Fehler beobachtet werden. Eine schnelle Einzelantwort belegt noch keinen brauchbaren Durchsatz. Ein hoher Durchsatz belegt wiederum keine akzeptable Latenz im interaktiven Einsatz.

4. 4

   Nur wechseln, wenn der Einsatz davon profitiert

   Ein Kandidat lohnt sich, wenn sich brauchbare Arbeitsergebnisse und die Erfüllung betrieblicher Anforderungen gemeinsam verbessern. Bleiben diese Vorteile aus, bleibt das bisherige Modell. Der Eigenbetrieb muss warten, solange die benötigten Gewichtsdateien oder ein unterstützter Weg zur Bereitstellung fehlen.

Erfüllt die bisherige API bereits die Anforderungen an Qualität und Antwortzeit, ändert das Architekturetikett daran nichts. Wer dagegen eine eigene Installation anhand der aktiven Parameter dimensioniert hat, sollte diese Planung jetzt korrigieren.

Welche Versprechen rund um MoE gehen zu weit?

Überzogen ist die Behauptung, Sparse MoE vereine sämtliche Vorteile eines riesigen Modells mit sämtlichen Betriebseigenschaften eines kleinen. Die Architektur erlaubt eine nützliche Trennung von Kapazität und Rechenaufwand, allerdings unter bestimmten Bedingungen.

Experten sind nicht automatisch Fachspezialisten. Mistrals Mixtral-Analyse fand Routing-Muster, die sich nicht sauber nach akademischen Fachgebieten trennen lassen. Ein erlernter Experte besitzt keine fachliche Qualifikation. Auch die Auswahl durch den Router erklärt nicht, weshalb eine Antwort richtig ist.

Mehr Gesamtparameter belegen keine besseren Antworten. Ebenso wenig beweist ein kleinerer aktiver Anteil, dass ein Modell besser ist. Training, Architektur und Aufgabe spielen jeweils eine Rolle. Die Tabelle oben erklärt veröffentlichte Größenangaben und ist bewusst keine Qualitätsrangliste.

Ein kleinerer aktiver Anteil bedeutet weder einen entsprechenden Preisnachlass noch einen entsprechenden Geschwindigkeitsgewinn. Für sich genommen sagt er nichts über Anbieterpreise, Warteschlangen, Netzwerkübertragungen oder die Zahl der für eine Aufgabe benötigten Ausgabetokens aus.

Das grundlegende Paper zu Mixture of Experts

Shazeer et al. beschrieben 2017 eine einflussreiche MoE-Schicht mit Sparse Gating, die die Modellkapazität ohne proportional steigenden Rechenaufwand erhöhte. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer ist die maßgebliche Originalquelle für diesen Mechanismus. Die dortige Diskussion über Lastausgleich und verteilte Verarbeitung zeigt zugleich: Die betrieblichen Zielkonflikte gehörten von Anfang an zur Idee.

Häufige Fragen zu MoE in der Anwendungsentwicklung

Was bedeutet Mixture of Experts bei einem LLM?

Dabei wird ein großes Sprachmodell aus mehreren internen Expertennetzen und einem erlernten Router aufgebaut. Bei Sparse MoE nutzt jedes Token in jeder MoE-Schicht nur ausgewählte Experten. Die Anwendung ruft weiterhin ein einzelnes Modell auf.

Ist GPT-4 ein Mixture-of-Experts-Modell?

Der technische Bericht zu GPT-4 hält weitere Architekturdetails zurück, darunter die Modellgröße. Er liefert keine vom Hersteller bestätigte Aufschlüsselung der MoE-Parameter. Gerüchte über solche Zahlen sollten daher nicht als Fakten in die Bereitstellungsplanung eingehen.

Worauf kommt es beim Fine-Tuning von Mixture of Experts an?

Fine-Tuning passt das erlernte Verhalten eines Modells an. Die Hosting-Anforderungen des vollständigen Gewichtssatzes bleiben bestehen. Beim angepassten Modell sollten Aufgabenqualität und Routing-Verhalten unter repräsentativer Anfragelast geprüft werden. Der MoE-Leitfaden von Hugging Face behandelt die unterschiedlichen Herausforderungen bei Überanpassung und Lastausgleich.

Was vor der nächsten Bereitstellungsentscheidung zu tun ist

Am Montag erhält jedes Modell auf der engeren Auswahlliste eine kurze Betriebsnotiz. Darin stehen die vom Hersteller genannten gesamten und aktiven Parameterzahlen, die Quelle und der genaue Checkpoint oder API-Endpunkt. Bei gehostetem Zugriff kommen die Ergebnisse der eigenen Aufgaben und die gemessenen Latenzen hinzu. Beim Eigenbetrieb werden der vollständige Speicherbedarf der Gewichte, die Cache-Reserve und die Leistung unter der erwarteten Anfragelast ergänzt. Diese Notiz hilft mehr als eine Rangliste nach der größten beworbenen Zahl.

Wer die Infrastruktur hinter KI-Produkten praxisnah verstehen möchte, kann den Newsletter abonnieren.