Bei Sprachmodellen klingt eine Parameterzahl wie eine eindeutige Eigenschaft. Bei Mixture-of-Experts-Modellen (MoE) ist sie es nicht. Ein Modell kann viele Expertengruppen speichern, aber pro Token nur wenige davon verwenden. Wer nur auf eine Zahl schaut, übersieht deshalb die entscheidende Frage: Welche Ressource ist gerade knapp?

Drei Größen statt einer

Gesamtparameter beschreiben, wie viele Gewichte das vollständige Modell enthält. Diese Zahl ist für Speicherung, Download und häufig auch für den Arbeitsspeicher relevant.

Aktive Parameter beschreiben, welcher Teil der Experten bei einem einzelnen Token tatsächlich ausgewählt wird. Sie geben einen Hinweis auf die Rechenarbeit pro Token, sind aber keine direkte Geschwindigkeitsgarantie.

Kontextspeicher entsteht zusätzlich während der Inferenz. Bei langen Eingaben wächst der Key-Value-Cache; Architektur, Präzision und Implementierung beeinflussen, wie stark. Ein Modell mit effizienter Expertenauswahl kann deshalb trotzdem unpraktisch werden, wenn der gewünschte Kontext viel Speicher beansprucht.

Diese Unterscheidung ist wichtiger als eine Rangfolge in einer Ankündigung.

Wie MoE funktioniert

Ein MoE-Block enthält mehrere spezialisierte Teilnetze und eine Routing-Komponente. Für ein Token wählt das Routing eine kleine Anzahl dieser Experten aus. Die Grundidee ist, Rechenkapazität gezielter einzusetzen, statt bei jedem Token jedes Teilnetz auszuführen.

Das Switch-Transformer-Paper beschreibt diesen Ansatz als sparse activation: Die Kapazität des Modells kann wachsen, ohne dass alle Parameter für jede Eingabe aktiv sein müssen.[1] Das macht MoE attraktiv, bringt aber eigene Probleme mit: Routing muss stabil sein, Experten müssen sinnvoll ausgelastet werden, und die Gewichte müssen weiterhin verfügbar bleiben.

Was daraus nicht folgt

„Wenige aktive Parameter“ bedeutet nicht automatisch „läuft auf jeder Maschine schnell“. Die tatsächliche Laufzeit hängt unter anderem von der Quantisierung, dem Speicherzugriff, der Batch-Größe, der Kontextlänge und der verwendeten Inferenzsoftware ab. Ebenso ist eine hohe Gesamtparameterzahl kein Qualitätsbeweis. Architektur und Trainingsdaten bleiben entscheidend.

Auch Kontextangaben verdienen Skepsis. Ein technisch möglicher Maximalwert sagt nicht, ob die Antwortqualität am Ende eines langen Dokuments noch zur Anwendung passt. Für Retrieval, Zusammenfassung oder Agentenabläufe sind gezielte Tests mit realistischen Eingaben aussagekräftiger als ein einzelner Grenzwert.

Eine praktische Leseregel

Vor einem lokalen Einsatz helfen fünf Fragen:

  1. Wie groß ist die Datei in der gewünschten Präzision?
  2. Wie viel Speicher bleibt bei der typischen Kontextlänge übrig?
  3. Welche Laufzeitumgebung unterstützt das Modellformat zuverlässig?
  4. Wie verhält sich die Ausgabe bei den eigenen Aufgaben?
  5. Welche Latenz ist für die Anwendung akzeptabel?

Modellkarten sind dafür der Startpunkt. Die Gemma-2-Modellkarte dokumentiert beispielsweise Varianten, Lizenz und vorgesehene Einsatzgrenzen.[2] Sie ersetzt keine Messung, aber sie verhindert, dass Architekturbegriffe zu Marketingabkürzungen werden.

Fazit

MoE erweitert den Werkzeugkasten für lokale Inferenz, weil Gesamtgröße und Rechenaufwand teilweise auseinanderfallen können. Die richtige Interpretation ist nicht „groß“ gegen „klein“, sondern ein Profil aus Speicher, aktivem Rechenweg, Kontext und Zielaufgabe. Wer dieses Profil misst, trifft bessere Entscheidungen als jemand, der nur Parameterzahlen vergleicht.

Quellen

[1] Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity

[2] Gemma 2 Model Card