MoE gegen Dense: Warum das grössere Modell viermal schneller war
Ein lokaler Dokumenten-Benchmark auf einem Mac mini mit M4 Pro zeigt, warum aktive Parameter für den Durchsatz wichtiger sind als die Gesamtgrösse.
Nach einem Modellwechsel brauchte meine automatisierte Dokumentenpipeline plötzlich fünf bis zwölf Minuten pro Dokument. Drei parallele Läufe reichten teilweise aus, um den Ollama-Runner aus dem Tritt zu bringen. Zurück auf dem vorher verwendeten Mixture-of-Experts-Modell war das Problem verschwunden.
Der erste Verdacht fiel auf die Architektur. Das dichte 27B-Modell muss bei jedem Token alle 27 Milliarden Parameter durchlaufen. Das grössere MoE-Modell besitzt zwar rund 36 Milliarden Parameter, aktiviert davon aber nur ungefähr drei Milliarden.
Plausibel war das. Gemessen hatte ich es nicht.
Also habe ich die komplette Pipeline aus meiner automatisierten Paperless-Verarbeitung in einen reproduzierbaren Benchmark überführt. Nicht mit MMLU, Multiple-Choice-Fragen oder einem einzelnen Prompt, sondern mit genau der Arbeit, die das Modell produktiv erledigt: OCR prüfen, handschriftliche Seiten lesen, Dokumente klassifizieren und Metadaten erzeugen.
Der vollständige Benchmark mit Korpus, Prompts und Rohresultaten liegt auf GitHub.
Das grössere Modell rechnet mit weniger Parametern
Im Zentrum des Vergleichs stehen zwei Modelle derselben Qwen-Generation:
| Modell | Architektur | Parameter gesamt | Pro Token aktiv |
|---|---|---|---|
qwen3.6:35b-a3b | Mixture of Experts | 36,0 B | rund 3 B |
qwen3.6:27b | Dense | 27,8 B | 27,8 B |
Beim MoE entscheidet ein Router für jeden Token, welche Experten gebraucht werden. Qwen3.6-35B-A3B besitzt 256 Experten. Pro Token werden acht geroutete Experten und ein gemeinsam genutzter Experte aktiviert.1 Die übrigen Gewichte bleiben für diesen Rechenschritt unbenutzt.
Das reduziert die Rechenarbeit, nicht den Speicherbedarf. In einem normalen Ollama- oder llama.cpp-Setup müssen weiterhin alle Experten im Speicher liegen. Das Modell verhält sich deshalb vereinfacht wie ein grosses Modell beim RAM-Verbrauch und wie ein kleines Modell beim Decoding.
Auf Apple Silicon ist das eine ziemlich praktische Kombination. Gemessen wurde auf einem Mac mini mit M4 Pro und 48 GB Unified Memory. Alle vier Modelle passten als Q4_K_M-Quantisierung vollständig in den gemeinsamen Speicher.
Gemessen wurde die reale Pipeline
Die produktive Pipeline besteht aus vier Stufen. Zuerst entscheidet das Modell, ob der bereits vorhandene OCR-Text brauchbar ist. Falls nicht, liest ein Vision-Modell das Seitenbild. Danach folgen Klassifikation und Metadatenextraktion.
| Stufe | Aufgabe | Auswertung |
|---|---|---|
| OCR-Check | Ist der vorhandene Text brauchbar? | richtige Ja/Nein-Entscheidung |
| Vision-OCR | Seitenbild lesen | Zeichen- und Wortfehlerrate |
| Klassifikation | Korrespondent, Dokumenttyp und Tags | exakter Treffer, F1 bei Tags |
| Metadaten | Titel und inhaltliches Datum | Token-F1, exakter Treffer |
Die Prompts stammen unverändert aus dem produktiven Windmill-Script. Gemessen habe ich direkt über Ollamas /api/generate, weil die API mit eval_count und eval_duration Generierung, Prompt-Verarbeitung und Ladezeit getrennt ausweist. Produktiv sitzt LlamaIndex dazwischen. Über den Wrapper wäre die gemessene Zeit eine Mischung aus Modelllaufzeit und Framework-Overhead geworden.
Der Korpus enthält acht erfundene Dokumente: vier gedruckte Seiten, zwei tatsächlich von Hand geschriebene und eingescannte Seiten sowie zwei mit einem Handschrift-Font gerenderte Dokumente. Die Inhalte sind synthetisch, weil sich nur mit einem exakt bekannten Referenztext eine Zeichenfehlerrate berechnen lässt und weil private Dokumente nichts in einem öffentlichen Repository zu suchen haben.
Vor jedem Modell wurde Ollama neu gestartet. Pro Modell gab es drei vollständige Durchläufe, jeweils mit nur einem Dokument gleichzeitig. Der Testplan umfasste 96 Modell-Dokument-Kombinationen. Das 8B-Modell übersprang mangels Vision zwölf Handschriftläufe; 84 Kombinationen wurden tatsächlich verarbeitet, ohne einen einzigen Fehlschlag. Speicher, Swap und thermische Drosselung wurden parallel aufgezeichnet.
Zusätzlich zu den beiden Qwen3.6-Modellen liefen qwen3.8:27b als neueres dichtes Modell und qwen3:8b als kleine Textvariante mit. Das 8B-Modell besitzt keine Vision-Fähigkeit und bearbeitete deshalb nur die gedruckten Dokumente.
Das MoE-Modell rechnet 4,6-mal schneller
Der Unterschied ist nicht subtil.
| Modell | Generierungsrate über die Stufen | Sekunden je Dokument |
|---|---|---|
qwen3.6:35b-a3b | 67,1 bis 68,0 Tokens/s | 85 s |
qwen3.6:27b | 14,5 bis 14,8 Tokens/s | 367 s |
qwen3.8:27b | 15,0 bis 20,6 Tokens/s | 96 s |
qwen3:8b | 45,8 bis 46,4 Tokens/s | 37 s* |
* Nur gedruckte Dokumente, ohne Vision-OCR. Die Wanduhrzeit ist deshalb nicht direkt mit den anderen Modellen vergleichbar.
Für den Architekturvergleich sind vor allem qwen3.6:35b-a3b und qwen3.6:27b relevant. Beide stammen aus derselben Generation, verwenden dieselbe Quantisierung und bekamen dieselben Eingaben. Der MoE erreichte ungefähr 68 Tokens pro Sekunde, das dichte Modell knapp 15. Das entspricht Faktor 4,6 beim Durchsatz.
Bei der Wanduhrzeit sieht es ähnlich aus. Der MoE brauchte durchschnittlich 85 Sekunden pro Dokument, der dichte Zwilling 367 Sekunden. Ein Dokument war damit in weniger als einem Viertel der Zeit fertig.
Der Abstand blieb über alle vier Stufen erhalten:
| Stufe | MoE 35B-A3B | Dense 27B |
|---|---|---|
| OCR-Check | 68,0 Tokens/s | 14,8 Tokens/s |
| Vision-OCR | 67,1 Tokens/s | 14,5 Tokens/s |
| Klassifikation | 67,7 Tokens/s | 14,7 Tokens/s |
| Metadaten | 68,0 Tokens/s | 14,7 Tokens/s |
Auch die Wiederholungen waren stabil. Das dichte Modell kam in den drei Läufen auf 359, 367 und 375 Sekunden je Dokument. Beim MoE waren es 99, 76 und 80 Sekunden. Die Spannweite ist sichtbar, aber weit davon entfernt, den Architekturunterschied zu erklären.
Noch auffälliger war der Vergleich mit dem kleinen 8B-Modell. Der MoE generierte mit 68 Tokens pro Sekunde rund 1,5-mal schneller als das dichte 8B mit ungefähr 46 Tokens pro Sekunde. Das Modell mit 36 Milliarden Parametern war beim Decoding also schneller als eines mit 8,2 Milliarden. Die Gesamtzahl der Parameter sagt hier wenig über die Decoding-Geschwindigkeit aus. Wichtiger ist, wie viele davon pro Token tatsächlich aktiv sind.
Thinking macht Geschwindigkeit nicht kostenlos
Tokens pro Sekunde sind nur die halbe Wahrheit. Ein Modell kann sehr schnell rechnen und trotzdem lange brauchen, wenn es wesentlich mehr Tokens erzeugt.
Beim MoE war genau das der Fall. Über die gesamte Pipeline erzeugte er im Mittel 5.549 Tokens pro Dokument. qwen3.8:27b kam auf 1.685. Trotzdem war der MoE mit 85 Sekunden noch etwas schneller als das neuere dichte Modell mit 96 Sekunden.
Auf dem handschriftlichen Dokument d05 wird der Effekt besonders deutlich. Allein im Vision-OCR-Schritt erzeugte der MoE 5.262 Tokens und brauchte 84 Sekunden. qwen3.8:27b erzeugte 408 Tokens und war nach 30 Sekunden fertig. Ein grosser Teil der zusätzlichen Ausgabe entfiel auf Reasoning.
Der hohe Durchsatz kompensiert also einen Teil der zusätzlichen Reasoning-Tokens.
Beim Vergleich mit dem dichten Qwen3.6-Zwilling fällt dieser Einwand weg. Beide erzeugten über ein Dokument fast dieselbe Tokenmenge: 5.549 beim MoE und 5.222 beim dichten Modell. Trotzdem standen am Ende 85 gegen 367 Sekunden. Hier lässt sich der Unterschied nicht mit kürzeren Antworten oder weniger Reasoning erklären.
Für einen produktiven Workflow sind deshalb beide Messgrössen nötig. Die Tokenrate zeigt, wie schnell die Architektur rechnet. Die Wanduhrzeit zeigt, wie lange der Nutzer tatsächlich wartet.
Bei der Genauigkeit gibt es keinen Gesamtsieger
Die Geschwindigkeit trennt die Modelle klar. Die Genauigkeit tut das nicht.
| Metrik | MoE 35B-A3B | Dense 27B, Qwen3.6 | Dense 27B, Qwen3.8 |
|---|---|---|---|
| Zeichenfehlerrate, echte Handschrift | 23,5 % | 34,0 % | 22,4 % |
| Wortfehlerrate, echte Handschrift | 41,1 % | 56,5 % | 41,1 % |
| Korrespondent richtig | 88 % | 88 % | 88 % |
| Dokumenttyp richtig | 79 % | 75 % | 88 % |
| Tags F1 | 0,88 | 0,83 | 0,87 |
| Datum richtig | 100 % | 100 % | 100 % |
| Titel F1 | 0,53 | 0,38 | 0,43 |
Der MoE las die beiden echten Handschriften im Mittel deutlich besser als sein dichter Qwen3.6-Zwilling. Dieser Unterschied hängt allerdings fast vollständig an einem einzigen schwierigen Dokument. Auf dem besser lesbaren Blatt lagen alle drei Vision-Modelle bei ungefähr elf Prozent Zeichenfehlern. Auf dem schwierigen Blatt erreichte der MoE 35,9 Prozent, qwen3.8:27b 34,7 Prozent und das dichte Qwen3.6-Modell 57,1 Prozent.
In diesem Korpus war der MoE damit besser als sein dichter Zwilling. Für eine allgemeine Aussage über MoE und Handschrift reicht das nicht. Es gibt nur zwei echte handschriftliche Seiten, und nur eine davon trennt die Modelle deutlich.
Auf den gedruckten Dokumenten wurde die Modellgrösse erstaunlich unwichtig. Alle vier Modelle erkannten den Korrespondenten zu 100 Prozent, das Datum zu 100 Prozent und den Dokumenttyp zu 75 Prozent. Selbst das 8B-Modell erledigte diese strukturierte Textaufgabe zuverlässig. Grössere Modelle verbesserten vor allem Tags und Titel, nicht die grundlegende Zuordnung.
Interessant war auch ein identischer Fehler beim Dokumenttyp. Eine Policenänderung war im Referenzdatensatz als Vertrag markiert. Alle vier Modelle nannten sie in jedem Durchlauf Bestätigung. Der Brief bestätigt tatsächlich eine Änderung. Wenn vier Modelle denselben angeblichen Fehler zwölfmal reproduzieren, sollte man nicht nur die Modelle, sondern auch die Ground Truth prüfen.
Ein Handschrift-Font testet keine Handschrift
Die beiden mit einem Handschrift-Font gerenderten Dokumente sahen auf den ersten Blick nach einem brauchbaren Ersatz für echte Scans aus. Im Ergebnis waren sie wertlos.
Alle drei Vision-Modelle lasen beide Seiten in jedem Durchlauf mit null Prozent Zeichen- und Wortfehlerrate. Auf den echten handschriftlichen Seiten lag die Zeichenfehlerrate dagegen zwischen 22,4 und 34,0 Prozent.
Ein Handschrift-Font ist eine saubere Vektorschrift mit ungewöhnlichen Buchstabenformen. Er besitzt keine schwankende Linienführung, keine übermalten Zeichen, keinen ungleichmässigen Druck und keine schiefen Zeilen. Wer OCR mit gerendertem Text testet, misst deshalb vor allem, ob das Modell eine Schriftart lesen kann.
Flüssiger falscher Text ist gefährlicher als Zeichensalat
Das schwierigste Blatt war eine handschriftliche Mahnung einer Bibliothek. Bei allen Modellen blieben Datum, Beträge und die grobe Dokumentstruktur erstaunlich stabil. Aus inhaltstragenden Begriffen entstanden jedoch plausible Alternativen.
| Auf dem Blatt | MoE 35B-A3B | Dense Qwen3.8 | Dense Qwen3.6 |
|---|---|---|---|
Ausweisnummer 4471 | Kassennummer 4971 | Kundennummer 4471 | Kunstenzwaams 49 t.t |
Mahngebühr 6.00 CHF | Mahngebühr 6 CHF | Mahnschreiben 6 CHF | Makroplastiekken 6 CHF |
Bitte innert zehn Tagen zurückbringen | Bitte sofort an Tiger Journal Premier | Bitte umsofort 10 Tage vor dem 2. Mahnung | Bilte simost 1e Tegen landd kremer |
Das dichte Qwen3.6-Modell hatte die höchste Fehlerrate, produzierte dabei aber sichtbar kaputten, teilweise niederländisch anmutenden Text. Das war zumindest leicht als Fehler zu erkennen.
Plausibler OCR-Text ist gefährlicher. Kundennummer 4471 sieht auf einem Formular völlig normal aus, obwohl auf dem Blatt Ausweisnummer 4471 steht. Solche Fehler wandern unauffällig in die nächste Stufe. Bei diesem Dokument fand kein Modell den richtigen Korrespondenten; in mehreren Läufen wählte qwen3.8:27b sogar einen plausiblen, aber falschen Eintrag aus der vorgegebenen Liste.
Eine reine Zeichenfehlerrate erfasst dieses Risiko nur unvollständig. Für Dokumentenpipelines braucht es zusätzlich Plausibilitätsprüfungen auf bekannte Absender, Beträge, Datumsangaben und Dokumenttypen. Ein Modell, das Unsinn sichtbar als Unsinn ausgibt, kann betrieblich ungefährlicher sein als eines, das denselben Fehler sauber formuliert.
Der erste Benchmarklauf mass teilweise den Rechner
Die Messung hatte selbst einige Fehlversuche. In einem frühen Lauf fiel qwen3.8:27b bei einzelnen Aufrufen von ungefähr 24 bis 26 auf ein bis zwei Tokens pro Sekunde. Prompt und erzeugte Tokenmenge waren vergleichbar, die Dauer stieg trotzdem um ungefähr Faktor 20.
Es wäre verlockend gewesen, das als Beleg gegen das dichte Modell zu verwenden. Der neue Lauf auf dem Mac mini reproduzierte den Effekt nicht. Ollama wurde vor jedem Modell neu gestartet, die Tokenraten blieben stabil, der Swap unter einem Gigabyte und die thermische Drosselung aus. Selbst das langsame dichte Qwen3.6-Modell lief zweieinhalb Stunden ohne Einbruch.
Damit bleibt der frühere Einbruch real, aber seine Ursache offen. Server, Betriebssystem, Ollama-Version, Parallelität oder ein anderer Zustand der Runtime kommen ebenso infrage wie das Modell. Der Benchmark misst ausserdem nur ein Dokument gleichzeitig, während das ursprüngliche Produktionsproblem bei drei parallelen Läufen auftrat.
Eine zweite Korrektur war banaler. In einer frühen Auswertung stand eine Kombination aus Tokenzahl und Laufzeit, die bei der gemessenen Tokenrate mathematisch unmöglich war. Die Zahl war von Hand aus dem JSON übernommen worden und stützte ausgerechnet die gewünschte Aussage besonders schön.
Seitdem erzeugt bench/report.py alle Tabellen direkt aus dem Ergebnis-JSON. Das hätte ich von Anfang an so machen sollen; die manuell übernommene Zahl war schlicht falsch.
Andere Messungen zeigen dasselbe Muster
Die Grössenordnung passt zu zwei anderen Apple-Silicon-Benchmarks, die ich gefunden habe.
Ein reproduzierbarer llama.cpp-Vergleich auf einem MacBook Pro mit M1 Pro und 32 GB mass 5,3 Tokens pro Sekunde für das dichte 27B-Modell und 25,4 für das MoE. Das entspricht Faktor 4,8. Gleichzeitig benötigte der MoE mehr Speicher und erreichte im dort verwendeten Qualitätsaggregat 66 statt 73 Punkte.2
mlx-coding-bench mass auf einem M4 Pro mit 64 GB und 4-Bit-MLX-Quantisierung 16 Tokens pro Sekunde für das dichte Modell und 86 für das MoE, also Faktor 5,4. Beim dortigen Mix aus Coding, Reasoning, Tool Use, Mathematik und Schreiben lag das dichte Modell mit 90,1 gegenüber 86,2 Prozent vorn.3
Die absoluten Zahlen sind nicht direkt mit meinem Ollama-Lauf vergleichbar. Hardware, Runtime, Quantisierung, Kontext, Prompt und Tokenbudget unterscheiden sich. Die Verhältnisse liegen trotzdem erstaunlich nahe beieinander: In allen drei Tests ist der MoE beim Decoding mehrere Male schneller, während die dichten Modelle in den externen Qualitätsbenchmarks etwas besser abschneiden und weniger Speicher brauchen.
Ein aktuelles Paper zeigt denselben Effekt auf einer anderen MoE-Architektur. DECO aktiviert nur 20 Prozent seiner Experten, erreicht laut Paper die Leistung eines dichten Modells mit gleichem Parameterbudget und kommt mit einem spezialisierten Kernel auf realer Hardware auf eine dreifache Beschleunigung.4 Mit Qwen ist das nicht direkt vergleichbar, der Grundmechanismus ist aber derselbe.
Für das Decoding ist die Zahl der aktiven Parameter also ein guter erster Indikator, aber keine vollständige Erklärung. Expert-Routing, Speicherbandbreite, Kernel, Quantisierung, Kontextlänge und Modellgeneration entscheiden darüber, ob aus dem theoretischen Vorteil Faktor zwei oder Faktor fünf wird.
Für die Pipeline zählt nicht ein einziges bestes Modell
Für meine Dokumentenpipeline würde ich in diesem Setup weiterhin qwen3.6:35b-a3b nehmen, wenn ein Modell alle vier Stufen übernehmen soll. Gegen seinen dichten Zwilling ist es mehr als viermal schneller, ohne in dieser Aufgabe einen allgemeinen Qualitätsnachteil zu zeigen.
Daneben fiel mir noch etwas auf: Für den reinen Textteil braucht es oft kein grosses Modell. Auf gedruckten Dokumenten erledigte das 8B-Modell Korrespondent, Dokumenttyp und Datum genauso zuverlässig wie die Varianten mit 27 oder 36 Milliarden Parametern.
Für den reinen Textteil braucht es offenbar nicht immer ein grosses Modell. Das bedeutet aber nicht automatisch, dass zwei Modelle in der produktiven Pipeline sinnvoller wären. Bei lokalem Betrieb kann der Wechsel zwischen Modellen zusätzliche Ladezeit verursachen, während zwei gleichzeitig geladene Modelle den verfügbaren Speicher stärker belasten. Für meine Pipeline dürfte deshalb ein einzelnes Vision-fähiges MoE die praktischere Lösung bleiben. Interessant ist das 8B-Ergebnis trotzdem: Es zeigt, dass ein grosser Teil der strukturierten Textverarbeitung deutlich weniger Modellkapazität benötigt als die schwierigen OCR-Fälle.
Die Grenzen des Tests sind ziemlich klar: ein Rechner, acht Dokumente, zwei echte handschriftliche Seiten, drei Wiederholungen, eine Quantisierung, nur Qwen-Modelle und keine Parallelität. Der Benchmark belegt einen deutlichen Geschwindigkeitsunterschied auf dieser Hardware. Er ist keine allgemeine Rangliste für dichte und sparse Modelle.
Für diesen Rechner bestätigt der Test meinen ursprünglichen Verdacht. Die Zahl der aktiven Parameter erklärt den Decoding-Durchsatz deutlich besser als die Gesamtgrösse des Modells. Die Gesamtgrösse bleibt trotzdem wichtig, weil alle Gewichte in den Speicher passen müssen.
Für die Praxis heisst das: Ein 36B-MoE kann auf derselben Hardware deutlich schneller sein als ein 27B-Dense, solange das grössere Modell in den Speicher passt.