llama.cpp experimentiert mit Laufzeit-Erweiterung von MoE-Experten ohne Nachtraining

Am 6. September 2026 erschien in einem Community-Fork von llama.cpp eine neue experimentelle Funktion, die es Sparse-Mixture-of-Experts-(MoE)-Modellen erlaubt, während der Inferenz mehr Experten zu aktivieren, ohne dass ein Nachtraining oder Änderungen an den Gewichten erforderlich sind. Diese von dem Mitwirkenden vagrillo entwickelte und am Modell Qwen 3.6 35B A4B+ getestete Modifikation verwandelt die feste Routing-Grenze in einen einstellbaren Laufzeit-Budgetwert und bietet lokalen KI-Ingenieuren eine neue Möglichkeit, die Rechenkosten gegen die Ausgabequalität abzuwägen.

Was passiert ist

Die Kerninnovation besteht in einer Umstellung vom statischen Top-K-Routing auf die dynamische Expertenerweiterung. In Standard-MoE-Architekturen wählt ein Router eine feste Anzahl von Experten aus, beispielsweise acht von zweiunddreißig, um jedes Token zu verarbeiten. Dieses Experiment erlaubt es dem System, zusätzliche Kandidaten über diese native Grenze hinaus auszuwählen, wodurch das Netz der für jeden Schritt der Generierung konsultierten neuronalen Pfade effektiv erweitert wird. Die Implementierung verändert nicht die in GGUF-Dateien gespeicherten Modellgewichte, sondern ändert, wie diese Gewichte während des Forward-Passes zugegriffen und aggregiert werden.

Dieser Ansatz ist derzeit auf einen Community-Zweig beschränkt und wurde noch nicht in das Haupt-Repository ggml-org/llama.cpp integriert. Er unterstützt verschiedene Compute-Backends und zielt auf breite Kompatibilität ab, statt nur für CUDA-GPUs optimiert zu sein. Obwohl die Validierung an spezifischen Qwen-Modellen durchgeführt wurde, befindet sich die Funktion noch in einem frühen experimentellen Stadium, was bedeutet, dass Parameter und Verhaltensweisen sich ändern können, wenn Entwickler die Logik für Schwellenwerte und schichtspezifische Steuerung verfeinern.

Wie es funktioniert

Die Standard-MoE-Inferenz basiert auf einem Router, der allen verfügbaren Experten Scores zuweist und die besten K auswählt. Dieses Experiment behält diese primäre Auswahl bei, fügt jedoch eine sekundäre Phase hinzu, in der auch Experten mit niedrigeren Scores zur Mitarbeit eingeladen werden. Um zu verhindern, dass diese weniger vertrauenswürdigen Experten die Ausgabe dominieren, werden ihre Beiträge durch eine Dämpfungsstrategie reduziert. Der Einfluss dieser hinzugefügten Experten kann je nach ihren ursprünglichen Scores und der konfigurierten Abfallkurve von nahezu vollem Gewicht bis hin zu fünfzig Prozent reichen.

Entscheidend ist, dass das System eine Konfiguration pro Ebene (Layer) unterstützt. Nicht alle Transformer-Ebenen profitieren gleichermaßen von erweitertem Experten-Zugriff; einige haben scharfe Routing-Verteilungen, bei denen die Top-Auswahl klar ist, während andere flachere Score-Profile aufweisen, bei denen zusätzlicher Kontext hilfreich ist. Indem Benutzer festlegen können, welche Ebenen ihre aktive Expertenanzahl erweitern sollen, ermöglicht das Werkzeug eine granularere Zuteilung der Rechenressourcen. Dies bedeutet, dass Sie gezielt die „Engpass“-Ebenen ansteuern können, wo die Mehrdeutigkeit am höchsten ist, ohne die Leistungseinbußen im gesamten Netzwerk in Kauf nehmen zu müssen.

Wichtige Details

• Kein Nachtraining erforderlich: Die Methode funktioniert vollständig zur Inferenzzeit und lässt Modellgewichte und Architektur unberührt.
• Gedämpfte Beiträge: Zusätzliche Experten werden mit reduziertem Gewicht einbezogen, um Stabilität zu wahren und hochvertrauensvolle Pfade zu priorisieren.
• Schichtspezifische Steuerung: Benutzer können unterschiedliche Erweiterungsstrategien für verschiedene Transformer-Ebenen definieren, um einheitliche Kostensteigerungen zu vermeiden.
• Backend-unabhängig: Die Implementierung zielt darauf ab, alle llama.cpp-Backends zu unterstützen, nicht nur GPU-beschleunigte Umgebungen.
• Getestet an Qwen 3.6: Die erste Validierung erfolgte am Modell Qwen 3.6 35B A4B+, obwohl die Ergebnisse bei anderen MoE-Architekturen variieren können.
• Experimenteller Status: Die Funktion ist noch nicht im Mainline-Zweig von llama.cpp enthalten, daher unterliegen API-Stabilität und Parameternamen Änderungen.

Warum es wichtig ist

Für Entwickler, die lokale KI-Anwendungen erstellen, entkoppelt dieses Experiment die Modellkapazität vom Inferenz-Budget. Traditionell akzeptierten Sie entweder die feste Sparsity eines trainierten MoE-Modells oder wechselten zu einer dichteren, langsameren Alternative. Dieser Ansatz führt ein kontinuierliches Spektrum ein, in dem Sie Latenz gegen Abdeckung eintauschen können. Wenn eine bestimmte Aufgabe, wie komplexe Codegenerierung oder Multi-Hop-Reasoning, breiteres Wissensabruf erfordert, können Sie die aktive Expertenanzahl vorübergehend erhöhen, um die Robustheit zu verbessern, ohne ein völlig anderes Modell bereitzustellen.

Diese Flexibilität bringt jedoch erhebliche Engineering-Trade-offs mit sich. Das Aktivieren weiterer Experten erhöht den Druck auf die Speicherbandbreite und die Matrixmultiplikationsoperationen, was die Tokens-pro-Sekunde-Raten und die First-Token-Latenz erheblich beeinträchtigen kann. Für Echtzeit-interaktive Anwendungen könnte die Verzögerung inakzeptabel sein. Doch für Offline-Batch-Verarbeitung, Evaluations-Pipelines oder Szenarien, in denen Genauigkeit Vorrang vor Geschwindigkeit hat, bietet dieser einstellbare Regler einen leistungsstarken Hebel, um marginale Gewinne aus bestehenden Modellen herauszuholen.

Was Sie tun können

• Klonen Sie den experimentellen Zweig aus vagrillos Repository und kompilieren Sie ihn mit Ihren bevorzugten Backend-Flags.
• Überprüfen Sie die Hilfe-Ausgabe der Befehlszeile, um aktuelle Parameternamen für die Expertenerweiterung zu identifizieren, da diese noch nicht standardisiert sind.
• Beginnen Sie mit konservativen Einstellungen, indem Sie die aktive Expertenanzahl nur um fünfundzwanzig bis fünfzig Prozent über das native Top-K erhöhen.
• Wenden Sie die Erweiterung selektiv auf mittlere Transformer-Ebenen an, statt auf das gesamte Netzwerk, um den Leistungsaufwand zu minimieren.
• Führen Sie kontrollierte Benchmarks durch, die native und erweiterte Konfigurationen bei Aufgaben wie Codegenerierung, mathematischem Reasoning und Langkontext-Zusammenfassung vergleichen.
• Überwachen Sie sowohl Qualitätsmetriken als auch Systemressourcen, insbesondere die Nutzung der Speicherbandbreite und die Generierungsgeschwindigkeit neben der Ausgabepräzision.