Halbe Experten, volle Leistung? Was gestutzte MoE-Modelle beim Deutschen verlieren

Verfahren wie REAP und Amazons neues HOPE werfen bis zur Hälfte der „Experten“ aus großen KI-Modellen und halbieren so den Speicherbedarf, angeblich ohne Qualitätsverlust. Geprüft wird das aber fast nur mit englischem Code. Wir erklären, wie das Stutzen funktioniert und warum „verlustfrei“ für deutsche Texte nicht automatisch gilt.

Analysen 9. Nov. 2026 10 Min. Lesezeit Eigene Analyse der Redaktion
Symbolbild, KI-generiert

Darum geht es

Große Sprachmodelle nach dem Prinzip Mixture of Experts (MoE) rechnen schnell, brauchen aber viel Speicher. Sie bestehen aus Hunderten spezialisierter Teilnetze, den „Experten“. Pro Wort sind davon nur wenige aktiv, im Speicher liegen müssen trotzdem alle. Ein naheliegender Trick ist das Experten-Pruning: Man entfernt die Experten, die angeblich kaum gebraucht werden, und zwar ohne das Modell danach neu zu trainieren. Auf Hugging Face gibt es inzwischen viele solcher gestutzten Varianten mit dem Kürzel REAP. Amazon hat mit HOPE gerade ein Verfahren vorgestellt, das bei halbierter Expertenzahl in einem Programmier-Benchmark sogar leicht besser abschneiden soll als das Original.

Die These dieses Artikels: „Verlustfrei“ gilt nur für die Aufgaben, mit denen ein Modell gestutzt und geprüft wurde, und das ist fast immer englischer Code. Was beim Stutzen mit Deutsch passiert, hat bislang niemand veröffentlicht gemessen. Die vorhandene Forschung gibt aber Hinweise, wo die Risiken liegen.

Wie ein MoE-Modell seine Experten auswählt

Jede MoE-Schicht hat einen Router, eine Art Weiche. Für jedes Token, also jedes Wort- oder Silbenstück, entscheidet er, welche Experten rechnen sollen, und gewichtet deren Beiträge. Qwen3.5-122B-A10B hat laut HOPE-Paper 48 MoE-Schichten mit je 256 Experten, von denen pro Token 8 aktiv sind. Das Kürzel „A10B“ steht für etwa 10 Milliarden aktive Parameter pro Token.

Der Speicher geht fast vollständig an die Experten. Laut Amazon sind 116 der 122 Milliarden Parameter Experten-Bausteine. Das sind rund 95 Prozent des etwa 250 GB großen Speicherbedarfs in voller Genauigkeit. Halbiert man die Zahl der Experten, sinkt der Bedarf laut Paper auf ungefähr 125 GB. Unser Überschlag für 4-Bit-Quantisierung (die Zahlen werden gröber gespeichert): Statt grob 65 bis 70 GB wären es dann eher 35 GB. Genau diese Rechnung macht das Verfahren für Leute interessant, die bei den aktuellen RAM-Preisen große Modelle auf eigener Hardware betreiben wollen.

REAP: Wer selten Wichtiges beiträgt, fliegt raus

REAP (Router-weighted Expert Activation Pruning) stammt von Cerebras und wurde auf der ICLR 2026 angenommen. Das Verfahren gibt jedem Experten eine Punktzahl. Dafür schickt man Kalibrierdaten durch das Modell, eine Stichprobe typischer Eingaben. Gemessen wird bei jedem Token, für das ein Experte ausgewählt wurde, wie stark der Router ihn gewichtet und wie groß sein Beitrag ausfällt. Der Durchschnitt dieser Werte ist die Punktzahl, und die Experten mit den niedrigsten Werten werden gelöscht. Weil nur über die Tokens gemittelt wird, bei denen der Experte tatsächlich aktiv war, sollen seltene, aber wichtige Spezialisten erhalten bleiben.

Die Ergebnisse sind für Code eindrucksvoll. Bei Qwen3-Coder-480B und Kimi-K2 meldet Cerebras eine nahezu verlustfreie Kompression trotz 50 Prozent Pruning. In der vLLM-Dokumentation schrumpft Qwen3-30B-A3B von 56,93 auf 29,92 GiB und behält im Mathe-Test gsm8k_platinum 99,8 Prozent seiner Leistung.

Dieselben Quellen zeigen aber auch die Grenzen:

  • Im REAP-Paper fällt Qwen3-30B-A3B bei 50 Prozent Pruning im Durchschnitt der Multiple-Choice-Wissenstests von 0,721 auf 0,503. Im Schreibtest WildBench, den das Paper als kreatives Schreiben einordnet, sinkt der Wert von 0,811 auf 0,718.
  • Laut vLLM-Doku behält Moonlight-16B-A3B mit 50 Prozent Pruning nur noch 17 Prozent seiner Mathe-Leistung.
  • Wurde mit allgemeinem Webtext (C4) statt mit Code kalibriert, brach die Code-Leistung laut REAP-Paper zusammen. Mehrere Modelle lieferten dann nur noch unzusammenhängende Ausgaben.

Die vLLM-Doku warnt ausdrücklich: Fehlen in den Kalibrierdaten bestimmte Themen oder Merkmale, können genau die Experten entfernt werden, die dafür zuständig sind.

HOPE: Experten arbeiten im Team

Amazons HOPE (Higher-Order Pruning of Experts, arXiv 2609.18916, Code unter github.com/awslabs/HOPE, Apache-2.0) setzt bei einer Schwäche von REAP an. REAP bewertet jeden Experten für sich, als würden sich die Beiträge einfach addieren. In der Praxis ergänzen sich Experten aber, weil der Router oft dieselben Paare gemeinsam aufruft. HOPE erfasst diese Paarwirkungen in einer Matrix. Ihre Diagonale entspricht ungefähr den REAP-Punktzahlen, die übrigen Einträge beschreiben, wie stark zwei Experten zusammenarbeiten. Welche Experten wegfallen, wird dann als quadratisches Optimierungsproblem gelöst: Gesucht ist die Kombination, deren Entfernung den geschätzten Fehler am wenigsten erhöht. REAP ist dabei ein Sonderfall von HOPE, bei dem die Wechselwirkungen fehlen.

Getestet wurden Qwen3.5-122B, Qwen3.5-35B und GLM-4.5-Air gegen REAP, MAN, EAN und reine Häufigkeitszählung. Bei 50 Prozent Pruning erreicht HOPE einen mittleren Rang von 1,58, REAP folgt mit 2,42. Die viel zitierte Zahl stammt vom 35B-Modell: In SWE-Bench Pro (echte Programmierfehler beheben) kommt die halbierte HOPE-Version auf 42,3 Punkte, das Original auf 41,8, REAP auf 36,2. Beim großen Modell lohnt der Blick in den Anhang:

Qwen3.5-122B, SWE-Bench Pro 25 % entfernt 50 % entfernt
Original (ungestutzt) 50,16 50,16
HOPE, Kalibrierung mit SWE-Bench-Verläufen 51,39 50,63
REAP, Kalibrierung mit SWE-Bench-Verläufen 51,55 46,78
HOPE, Kalibrierung mit Evol-CodeAlpaca 52,29 43,84
REAP, Kalibrierung mit Evol-CodeAlpaca 47,17 39,61

Gleichwertig mit dem Original bleibt das Modell also nur, wenn die Kalibrierdaten genau zur späteren Aufgabe passen. Schon der Wechsel zwischen zwei Arten von Code-Daten macht beim 122B-Modell mit HOPE fast sieben Punkte aus. Bei 10 bis 20 Prozent Pruning sind REAP und MAN laut Amazon „manchmal konkurrenzfähig“.

Bei den allgemeinen Tests (Tulu3-Suite) heißt es in Amazons Blog, Code-Kalibrierung habe andere Fähigkeiten nicht stark beschädigt. Die Tabellen des Papers zeigen ein gemischteres Bild. Beim 35B-Modell fällt der Wissenstest MMLU mit HOPE bei 50 Prozent von 65,15 auf 29,77, mit REAP auf 50,15. Unsere Einschätzung: Einige Werte der Originalmodelle wirken unplausibel. Beim 122B-Modell etwa liegt MMLU bei 26,68, also nahe am Zufallsniveau. Als Maßstab für Allgemeinwissen taugen diese Tests deshalb nur bedingt. Einen Test in einer anderen Sprache als Englisch enthält das Paper nicht.

Der blinde Fleck: Womit kalibriert wird

Modell / Verfahren Kalibrierdaten Sprachen
HOPE (Paper) Evol-CodeAlpaca, SWE-Bench-Verified-Verläufe Englisch / Code
Cerebras-REAP (GLM-4.7-Flash u. a.) evol-codealpaca, xlam-function-calling, SWE-smith-Verläufe, Mixture-of-Thoughts Englisch / Code
0xSero/Qwen3.5-76B, -88B, -99B reap-calibration-data-v1: 23.088 Beispiele, u. a. 21,7 % Funktionsaufrufe, 16,9 % Agenten-Verläufe, 13 % Cybersicherheit als Englisch markiert
OpenMOSE/Qwen3.5-REAP-97B-A10B reap-calib-mix, größtenteils von Qwen3-235B erzeugt in der Vorschau Englisch, Chinesisch, Japanisch
vLLM-Beispiel ultrachat_200k Englisch

Die Model Cards zeigen dasselbe Muster. 0xSero/Qwen3.5-99B entfernt 20 Prozent der Experten (256 auf 205 pro Schicht, 198 GB in BF16) und meldet 97,9 Prozent erhaltene Leistung, gemessen allerdings nur mit englischen Tests wie ARC, HellaSwag und Winogrande. 0xSero/Qwen3.5-76B entfernt 40 Prozent (154 Experten pro Schicht, 152 GB) und nennt keine Benchmarks. Die OpenMOSE-Variante (22 Prozent entfernt) warnt immerhin ausdrücklich: Bei Sprachen, die in den Kalibrierdaten unterrepräsentiert sind, könne die Leistung ungleichmäßig ausfallen.

Cerebras räumte im Januar 2026 auf Reddit selbst ein:

„Wir haben viel Rückmeldung bekommen, dass REAP-Pruning das kreative Schreiben und die mehrsprachigen Fähigkeiten des Modells beeinträchtigt. […] Das ist bei unseren REAPs mit einem für agentisches Programmieren kuratierten Kalibrierset zu erwarten.“

Ein Nutzer nannte den Verlust der Mehrsprachigkeit dort „einen großen Verlust“. Auf der Model Card des Modells stehen dagegen nur zwei Code-Benchmarks, HumanEval und HumanEval+.

Was die Forschung über andere Sprachen weiß

  • Wo Sprache im Modell sitzt: Bandarkar et al. (ICLR 2026) fanden bei vier MoE-Modellen, dass sich das Routing für Nicht-Englisch vor allem in den ersten und letzten Schichten von Englisch unterscheidet. In der Mitte ist es weitgehend sprachunabhängig. In den letzten Schichten übernimmt eine kleine Gruppe von Experten die Erzeugung nicht-englischer Texte. Wurden diese Experten testweise abgeschaltet, sank die Leistung deutlich.
  • Litauisch als Warnsignal: Eine Studie von Hostinger Research vom November 2026 (arXiv 2611.07654) hat vier MoE-Modelle mit REAP gestutzt, darunter Qwen3.6-35B-A3B und GLM-4.7-Flash. Bei 25 Prozent Pruning und englischer Kalibrierung sank das Leseverständnis (Belebele) auf Englisch im Median um 1,7 Punkte, auf Litauisch um 21,4. Der Grund liegt im Routing: Litauisch schickt in den letzten Schichten 55 bis 72 Prozent seiner Expertenaufrufe an nur acht Experten, Englisch 19 bis 39 Prozent, und englische Kalibrierung löscht einige davon. Litauische Kalibrierdaten holten den Großteil des Verlusts zurück, ohne Englisch zu schaden. Bei 50 Prozent verloren aber selbst litauisch kalibrierte Modelle 6 bis 15 Punkte. Typische Fehler: Die Modelle hören nicht auf zu schreiben, wechseln ins Englische, erfinden Wortformen und zerstören Sonderzeichen.
  • Gegenbefunde für große Sprachen: Dieselbe Studie zitiert Arbeiten, nach denen englische Kalibrierung bei weit verbreiteten Sprachen gut übertragbar ist. Salim et al. (ACL 2026) schreiben, Kalibriersets in verschiedenen Sprachen könnten zu sehr ähnlichen Pruning-Ergebnissen führen. Martin, Bandarkar und Peng (arXiv 2605.28042) konnten aus GPT-OSS-20B und Qwen3-30B-A3B Übersetzungsspezialisten herauslösen, unter anderem für Deutsch, und dabei die Hälfte der Experten ohne nennenswerten Verlust entfernen. Kalibriert wurde dort allerdings mit Übersetzungsdaten (FLORES-200), und gemessen wurde nur die Übersetzung. Für Deutsch merken die Autoren an, dass eine gleichmäßige Kürzung über alle Schichten früher zu unbrauchbaren Ausgaben führte.
  • Ältere Pruning-Arten: Kurz et al. (TACL) untersuchten das Ausdünnen einzelner Gewichte in herkömmlichen, nicht nach Experten aufgeteilten Modellen. Bei Llama-3 8B lieferte deutsche statt englischer Kalibrierung bessere deutsche Werte, etwa im Lesetest Belebele (54,3 statt 36,6 Punkte, ungestutzt 66,1). Die Autoren betonen aber, dass Kalibrierung in der Zielsprache gute Ergebnisse beim Schlussfolgern nicht garantiert.

Was das für Deutsch bedeutet und wie man es prüft

Deutsch ist in den Trainingsdaten viel stärker vertreten als Litauisch. Unsere Einschätzung: Ein Einbruch um 20 Punkte ist deshalb unwahrscheinlicher. Belegt ist das für REAP oder HOPE aber nicht. Wir haben keine veröffentlichte Messung gefunden, die ein gestutztes Modell auf Deutsch mit seinem Original vergleicht. Eine eigene belastbare Messung liegt uns für diesen Artikel nicht vor. Die Hinweise aus Cerebras' Eingeständnis, der Litauen-Studie und der Routing-Forschung zeigen aber in dieselbe Richtung: Am ehesten gefährdet ist das, was in den letzten Schichten passiert, also flüssiges, idiomatisches Formulieren. Seltenes Wissen ist ebenfalls gefährdet. Code-Benchmarks bemerken davon nichts.

Ein Praxisbericht von Black Sheep AI (August 2026) zeigt, wie unauffällig so etwas ist. Dort wurde allerdings ein einfacheres, auf Häufigkeit basierendes Verfahren verwendet. Ein gestutztes Qwen3.5-397B übersetzte einen Satz ins Spanische, fügte mitten im Satz ein chinesisches Schriftzeichen ein und wechselte dann ins Englische. Die automatische Prüfung auf Totalausfälle hatte das Modell als einwandfrei bewertet.

Wer ein gestutztes Modell für deutsche Texte nutzen will, sollte es mit derselben Quantisierung neben das Original stellen. Geeignet sind der deutsche Teil von Global-MMLU, MGSM-de, Belebele (deu_Latn) und FLORES für Übersetzungen. Dazu kommen einige eigene Schreibaufgaben, bei denen man auf Sprachwechsel, falsche Wortformen und endlose Wiederholungen achtet. Das Projekt make-localllm-easier plant laut einem GitHub-Issue genau einen solchen Vergleich pro Sprache, Ergebnisse gibt es dort noch nicht.

Einordnung

Experten-Pruning ist eine echte Option, um riesige MoE-Modelle auf bezahlbare Hardware zu bringen. HOPE ist methodisch ein sinnvoller Schritt, weil es berücksichtigt, dass Experten im Team arbeiten. Bei starkem Pruning schneidet es messbar besser ab als REAP. Das Versprechen „genauso gut wie das Original“ gilt aber nur für die Kalibrieraufgabe: Bei SWE-Bench Pro hängt das Ergebnis des 122B-Modells um fast sieben Punkte davon ab, welche Code-Daten man verwendet. Für Deutsch fehlen Daten vollständig. Keines der beiden Paper und keine der untersuchten Community-Model-Cards testet eine andere Sprache als Englisch.

Unser Fazit: Wer Code und Agenten-Aufgaben auf Englisch erledigen lässt, kann mit einer leicht gestutzten Variante (20 bis 25 Prozent) wenig falsch machen. Wer Texte auf Deutsch schreiben lässt, sollte vor dem Wechsel selbst testen. Er sollte auch erwägen, ob eine stärkere Quantisierung des vollständigen Modells der bessere Weg ist, denn dabei bleiben alle Experten erhalten. Black Sheep AI bringt es so auf den Punkt: „Komprimiere die Genauigkeit, nicht die Abdeckung.“ Wünschenswert wären deutsche oder mehrsprachige Kalibriersets. Laut Litauen-Studie schaden sie dem Englischen kaum, und sie sollten bei gestutzten Modellen Standard werden.

Quellen

#moe#pruning#reap#hope#mehrsprachigkeit#qwen3.5

Frag den KI-Assistenten

Fragen zu diesem Artikel, zur Installation oder zu Hintergründen? Unser Assistent kennt diese Seite und läuft auf unserem eigenen Rechner, nicht in einer fremden Cloud.

Verbinde …

Der Assistent ist eine KI (Gemma 4) und kann sich irren – wichtige Angaben bitte in der Quelle prüfen. Fragen werden nur zum Beantworten genutzt und nach einer Stunde gelöscht. Bitte keine persönlichen Daten eingeben.

Kommentare

Was meinst du dazu? Schon ausprobiert? Schreib es hier, ohne Anmeldung.

  1. Kommentare werden geladen …

Kommentare sind öffentlich. Links sind nicht erlaubt, beleidigende Beiträge löschen wir. Deinen eigenen Kommentar kannst du in diesem Browser jederzeit wieder löschen. Mehr dazu in der Datenschutzerklärung.