🤖 machine learning

Systematic Exploration of 4-Expert Heterogeneous Mixture-of-Experts via Automated Pipeline Search

Dieses Paper präsentiert eine automatisierte Pipeline zur Untersuchung heterogener 4-Expert Mixture-of-Expert-Architekturen innerhalb des LEMUR-Datensatzes, wobei ein kritischer alphabetischer Enumerations-Bias aufgedeckt wurde, der den Suchraum auf AirNet-zentrierte Kombinationen beschränkte, während gleichzeitig ShuffleNet und MobileNetV3 als optimale Partner für hochgenaue Ensembles identifiziert wurden.

Ursprüngliche Autoren: Yashkumar R Lukhi, Harsh Rameshbhai Moradiya, Radu Timofte, Dmitry Ignatov

Veröffentlicht 2026-06-24

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yashkumar R Lukhi, Harsh Rameshbhai Moradiya, Radu Timofte, Dmitry Ignatov

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Chefkoch, der versucht, die ultimative „Super-Suppe“ zu kreieren. Sie haben einen Vorratsschrank (den LEMUR-Datensatz) gefüllt mit 29 verschiedenen Arten von fertigen Brühen (wie Hühner-, Rinder-, Gemüsebrühe usw.). Ihr Ziel ist es, genau vier dieser Brühen zusammenzumischen, um zu sehen, welche Kombination am besten schmeckt.

Dieses Paper beschreibt einen Roboter-Chef, der versucht hat, dies automatisch zu machen, dabei aber auf einen lustigen Fehler lief, der die Ergebnisse veränderte. Hier ist die Geschichte dessen, was passiert ist, einfach aufgeschlüsselt.

1. Das Ziel: Eine „Super-Suppe“ bauen

In der Welt der KI ist ein Mixture-of-Experts (MoE) wie ein Team von Spezialisten. Anstatt eines riesigen, einzelnen Gehirns, das versucht, ein Problem zu lösen, gibt es vier kleinere, unterschiedliche Gehirne, die zusammenarbeiten.

Die Aufgabe: Der Roboter musste 4 verschiedene KI-„Gehirne“ (Architekturen) aus dem Vorratsschrank von 29 Optionen auswählen und sie zu einem Team mischen.
Die Mathematik: Es gibt 23.751 Möglichkeiten, 4 Gehirne aus 29 auszuwählen. Das sind viele Suppenrezepte zum Testen!

2. Die Küche des Roboter-Chefs

Die Forscher bauten eine automatisierte Küche (eine Pipeline), um diese Arbeit ohne menschliche Hilfe zu erledigen.

Der Generator: Ein Roboter-Skript, das den Code für die neuen Suppenrezepte schreibt. Es rät nicht einfach nur, sondern setzt den Code sorgfältig wie ein Lego-Set zusammen.
Die Sicherheitsprüfung: Bevor gekocht wird, prüft der Roboter das Rezept dreimal:
1. Ergibt die Grammatik Sinn? (Syntaxprüfung)
2. Passt der Topf auf den Herd? (CPU-Test, um zu sehen, ob die Größe passt)
3. Haben wir diese Suppe schon einmal gemacht? (Suche nach Duplikaten)
Das Kochen: Wenn das Rezept besteht, geht es auf einen sehr leistungsstarken Herd (eine NVIDIA RTX 4090 Grafikkarte) und wird für nur einen Tag (einen Trainings-Epoch) gekocht. Das Ziel war nicht, eine perfekte Suppe zu machen, sondern die vielversprechendsten Kombinationen schnell zu finden.

3. Der große Fehler: Die „Alphabetische“ Falle

Der Roboter-Chef sollte eigentlich alle 23.751 Kombinationen ausprobieren. Er beging jedoch einen kritischen Fehler bei der Auswahl der Zutaten.

Dem Roboter wurde gesagt, die Kombinationen in alphabetischer Reihenfolge zu wählen.

Stellen Sie sich vor, Ihr Vorratsschrank ist alphabetisch sortiert. Der allererste Artikel ist „AirNet“.
Der Roboter begann, Rezepte auszuwählen. Er wählte zuerst jede einzelne mögliche Kombination, die „AirNet“ enthielt.
Da es so viele Möglichkeiten gibt, „AirNet“ mit drei anderen Zutaten zu mischen, verbrachte der Roboter seine gesamte Zeit damit, „AirNet“-Suppen zu kochen.
Das Ergebnis: Nach 28 Tagen Kochen hatte der Roboter 1.146 Rezepte ausprobiert. Aber wissen Sie was? Jedes einzelne davon enthielt „AirNet“.
Er hat nie eine Suppe ausprobiert, die kein AirNet enthielt. Er hat nur 4,8 % der gesamten möglichen Rezepte erkundet. Es war wie ein Koch, der immer nur „Hühner-basierte“ Suppen macht und nie eine „Rinder-basierte“ probiert, nur weil „Hühnchen“ in der Liste zuerst kommt.

4. Was sie herausgefunden haben (Innerhalb der „AirNet“-Zone)

Obwohl sie nur „AirNet“-Suppen betrachtet haben, fanden sie dennoch einige interessante Dinge heraus:

Die besten Zutaten: Als „AirNet“ mit ShuffleNet oder MobileNetV3 gemischt wurde, schmeckte die Suppe am besten (höchste Genauigkeit). Dies waren die „Geheimgewürze“, die das Team gut zusammenarbeiten ließen.
Die schlechten Zutaten:
- FractalNet: Diese Zutat war eine Katastrophe. Sie war so komplex, dass sie ständig den Herd kaputt machte (Speicherüberlauf). Es war eine „Sackgasse“.
- MNASNet: Diese Zutat brachte den Herd zwar nicht zum Absturz, aber die Suppe schmeckte schrecklich. Es war eine „gering ertragreiche“ Zutat, die die Leistung des Teams verschlechterte.
Der Champion: Die beste gefundene Suppe war eine Mischung aus AirNet + AlexNet + DPN68 + ResNet. Sie erreichte eine Punktzahl von 68 % bei einem Standardtest (CIFAR-10) in nur einem Tag Kochzeit.

5. Die Lektion

Die Forscher erkannten, dass ihr Roboter voreingenommen war, weil er zu ordentlich war.

Die Lösung: Anstatt die Rezepte alphabetisch auszuwählen, hätten sie die Liste vor dem Start zufällig mischen sollen. Auf diese Weise würde „AirNet“ nur in etwa 14 % der Rezepte vorkommen (was fair ist), und sie würden einen echten Geschmack von allen möglichen Kombinationen bekommen.

Zusammenfassung

Was sie taten: Bauten einen Roboter, der automatisch 4 verschiedene KI-Modelle mischt, um das beste Team zu finden.
Was schiefging: Der Roboter blieb in einer „alphabetischen Schleife“ stecken und testete nur Kombinationen, die ein spezifisches Modell (AirNet) enthielten, wodurch er 95 % der Möglichkeiten verpasste.
Was sie lernten: Selbst mit diesem Fehler fanden sie heraus, dass ShuffleNet und MobileNetV3 großartige Partner für KI-Teams sind, während FractalNet und MNASNet schlechte Partner sind.
Die Erkenntnis: Wenn man nach den besten Kombinationen sucht, geht man nicht einfach der Reihe nach vor; man bringt Abwechslung hinein, um nicht die besten Optionen zu übersehen.

Der Code und die Lösung für diese „alphabetische Falle“ wurden veröffentlicht, damit andere nutzen können, damit zukünftige Roboter-Chefs nicht denselben Fehler machen.

Technische Zusammenfassung: Systematische Exploration von 4-Experten-Heterogenen Mixture-of-Experts via Automatisierter Pipeline-Suche

Problemstellung
Die Arbeit adressiert die Herausforderung, den riesigen kombinatorischen Raum heterogener Mixture-of-Experts (MoE)-Architekturen zu explorieren. Insbesondere zielt sie auf die Konstruktion von 4-Experten-MoE (MoE4)-Ensembles unter Verwendung des LEMUR-Neuronalen-Netzwerk-Datensatzes ab, der 29 unterschiedliche Basis-Architekturfamilien enthält. Der theoretische Suchraum für die Auswahl von 4 einzigartigen Familien aus 29 beträgt $\binom{29}{4} = 23.751$ mögliche Kombinationen. Vorangegangene Arbeiten innerhalb des LEMUR-Ökosystems hatten nur eine geringe Anzahl von Konfigurationen manuell entworfen, wodurch der Großteil dieses Raums unexploriert blieb. Die Autoren streben an, die Entdeckung hochperformanter heterogener Ensembles zu automatisieren, ohne dabei auf Large Language Models (LLMs) für die Generierungsschleife zurückzugreifen, was sich in Szenarien mit 2 Experten zuvor als begrenzt erfolgreich erwiesen hatte.

Methodik
Die Autoren entwickelten eine vollständig automatisierte, 28-tägige Such-Pipeline auf Basis des NNGPT-Frameworks, die aus vier sequenziellen Phasen besteht:

Konstruktion des Experten-Pools: Das System fragt die LEMUR-Datenbank ab, um 29 etablierte Basis-Architekturfamilien abzurufen, die auf CIFAR-10 trainiert wurden. Es filtert LLM-generierte Mutationen, existierende MoE-Modelle und kleingeschriebene generierte Modelle heraus, um einen sauberen Pool an distinkten Architekturfamilien sicherzustellen.
Deterministische Code-Assemblierung: Ein Generator-Skript (AlterHeteroMoE4.py) setzt programmatisch Kandidaten-MoE4-Modelle zusammen. Es ruft den Quellcode für vier ausgewählte Familien ab, benennt Klassen um, um Kollisionen zu vermeiden, führt Imports zusammen und instanziiert ein Wrapper-Template. Die Architektur verwendet ein HeterogeneousGate (ein faltendes Gating-Netzwerk mit Temperaturskalierung), um Eingaben zu routen. Die Ausgabe ist eine gewichtete Summe der Experten-Logits: $y = \sum_{i=1}^{4} g_i(x) \cdot f_i(x)$ . Das Training nutzt AdamW, Mixup-Augmentierung ( $\alpha=0.2$ ), Label Smoothing und kosinus-annealierte Lernraten.
Mehrstufige Validierung: Bevor Kandidaten auf der GPU evaluiert werden, durchlaufen sie drei Filter:
- Syntax-Check: Das Python-Modul compile() überprüft die Korrektheit des Codes.
- CPU-Forward-Pass-Probe: Ein Dummy-Batch (2, 3, 256, 256) wird auf der CPU durchgereicht, um Dimensionsfehler zu erkennen, die Syntax-Checks übersehen könnten.
- Datenbank-Deduplizierung: Ein MD5-Checksum prüft, ob identische Modelle evaluiert werden sollen.
Kampagnen-Automatisierung: Ein fehlertoleranter Orchestrator (CampaignMoE4.py) verwaltet die Generate-Evaluate-Schleife über 197 Batches. Er speichert den Status in JSON-Dateien, was eine SSH-sichere Fortsetzung nach Unterbrechungen ermöglicht, und zielt auf 1.000 erfolgreiche Evaluationen ab.

Wesentliche Beiträge
Die Arbeit präsentiert drei primäre Engineering-Beiträge:

Deterministischer Code-Assemblierungs-Generator: Ein Werkzeug, das Basis-Familien systematisch in syntaktisch valide, durch Forward-Pass verifizierte MoE4-Modelle kombiniert, ohne LLM-Aufrufe zu benötigen, wobei bewährte Gating- und Trainingskonfigurationen wiederverwendet werden.
Mehrstufige Validierungs-Pipeline: Ein Pre-GPU-Filterungssystem, das verschwendete Rechenressourcen signifikant reduziert, indem es Syntaxfehler, dimensionsabhängige Fehler und Duplikate abfängt.
Fehlertolerante Kampagnen-Automatisierung: Ein robustes Orchestrierungssystem, das eine unüberwachte, lang laufende (28-tägige) Ausführung mit persistenter Statusverwaltung ermöglicht.

Ergebnisse
Die Kampagne lief 28 Tage lang auf einer NVIDIA RTX 4090, generierte 4.463 Kandidatenmodelle und evaluierte erfolgreich 1.021 Modelle.

Abdeckung des Suchraums (Coverage Bias): Eine kritische Post-Kampagnen-Analyse ergab einen schweren Abdeckungs-Bias. Aufgrund der Verwendung von itertools.combinations auf einer sortierten Liste enumerierte der Generator Kombinationen in lexikografischer Reihenfolge. Da "AirNet" alphabetisch zuerst steht, erschöpfte der Generator alle $\binom{28}{3} = 3.276$ Kombinationen, die AirNet enthalten, bevor er zur nächsten Familie überging. Die Kampagne stoppte bei 1.146 Kombinationen, was bedeutet, dass 100 % des explorierten Raums an AirNet verankert waren und nur 4,8 % des theoretischen Suchraums abgedeckt wurden.
Leistungsmetriken: Innerhalb des AirNet-verankerten Bereichs erreichte das beste Modell (AirNet + AlexNet + DPN68 + ResNet) eine Top-1 Genauigkeit von 68,0 % auf CIFAR-10 in einer einzigen Trainings-Epoche. Die mittlere Genauigkeit über alle erfolgreichen Modelle hinweg betrug 0,5221.
Analyse auf Familienebene:
- Hochertragreiche Familien: ShuffleNet (mittlere Genauigkeit: 0,632) und MobileNetV3 (mittlere Genauigkeit: 0,621) produzierten konsistent die genauesten Ensembles mit Erfolgsraten von >96 %.
- Geringertragreiche Familien: FractalNet hatte eine Erfolgsrate von nur 0,7 % aufgrund häufiger Out-of-Memory (OOM) Fehler und Form-Fehlern (Shape Mismatches). MNASNet verschlechterte die Ensemble-Qualität konsistent (mittlere Genauigkeit: 0,218).
Fehleranalyse: 99,7 % der Fehler waren auf CUDA OOM-Fehler zurückzuführen, primär verursacht durch den Speicherbedarf der Kombination von vier vollen Netzwerken bei einer Auflösung von 256×256.

Bedeutung und Behauptungen
Die Arbeit behauptet, dass die automatisierte Assemblierung heterogener Experten konkurrenzfähige Kandidaten produzieren kann, ohne manuelles Tuning, wie die erreichte Genauigkeit von 68,0 % in einer einzigen Epoche zeigt. Die Autoren sind jedoch vorsichtig hinsichtlich der Verallgemeinerbarkeit der spezifischen Genauigkeitsrankings und merken an, dass diese durch die Anwesenheit von AirNet bedingt sind.

Der primäre wissenschaftliche Beitrag ist die Identifizierung eines Coverage Blind Spot (Abdeckungs-Blindspot), der inhärent in groß angelegten kombinatorischen Suchen ist, die eine sortierte deterministische Enumeration mit throughput-basierten Abbruchbedingungen verwenden. Die Autoren schlagen eine einfache Lösung vor – das stratifizierte zufällige Shuffeln der Kombinationsliste –, um diesen Bias in zukünftigen Durchläufen zu eliminieren. Sie identifizieren zudem spezifische Architekturfamilien (FractalNet, MNASNet), die aus dem Experten-Pool ausgeschlossen werden sollten, um die Effizienz und Qualität zukünftiger Kampagnen zu verbessern. Die Pipeline, die Analyse-Artefakte und der korrigierte Generator werden als Open Source veröffentlicht.