Gemma 4 26B MoE: Fallstricke und wann es wirklich gewinnt

🧩 Was ist MoE und warum 26B besser klingt als es ist

"26B-Qualität zum Preis von 4B" – das stimmt. Aber nur zur Hälfte. Die andere Hälfte betrifft den Speicher – und genau das verschweigen alle.

Mixture of Experts (MoE) ist eine Architektur, bei der ein Modell aus vielen spezialisierten "Experten" besteht, aber für jeden Token wird nur eine Teilmenge davon aktiviert. Gemma 4 26B hat 128 Experten, und für jeden Token werden nur 2 davon aktiviert – daher ~3,8 Milliarden aktive Parameter während der Inferenz.

Das ist ein echter Vorteil: Das Modell berechnet wie ein 4B-Modell, "weiß" aber wie ein 26B-Modell. Die Geschwindigkeit der Token-Generierung ist vergleichbar mit E4B, und die Qualität der Antworten ist deutlich höher. Auf dem Papier – die ideale Lösung für diejenigen, die die Qualität eines großen Modells ohne die Langsamkeit eines großen Modells benötigen.

Aber es gibt ein kritisches Detail, das die meisten Überprüfungen nicht erwähnen oder nur beiläufig erwähnen: Obwohl nur 3,8 Milliarden Parameter aktiviert werden – müssen alle 26 Milliarden in den Speicher geladen werden. Der Grund ist einfach: Der Router weiß nicht im Voraus, welche Experten für den nächsten Token benötigt werden. Daher müssen alle 128 Experten gleichzeitig im Speicher verfügbar sein.

Wie SudoAll in seiner detaillierten Überprüfung es genau beschreibt: "MoE saves compute, not memory" – MoE spart Berechnungen, aber nicht Speicher. Das ist eine grundlegende Einschränkung der Architektur, kein Fehler der spezifischen Implementierung.

⚠️ Das Hauptmissverständnis: MoE spart Berechnungen, nicht Speicher

Wenn Sie 16 GB RAM haben – 26B MoE passt nicht hinein. Wenn Sie 24 GB haben – es passt, aber es wird geswappt. Das ist keine Meinung, das ist Mathematik.

Die meisten Überprüfungen von Gemma 4 26B betonen, dass "nur 3,8 Milliarden Parameter aktiviert werden" – und der Leser denkt natürlich, dass das Modell so viel Speicher benötigt wie ein 4B-Modell. Das ist ein Fehler, der Stunden der Frustration kostet. Lassen Sie uns das im Detail aufschlüsseln.

Warum alle 26B geladen werden müssen, wenn nur 3,8B aktiviert werden

Stellen Sie sich eine Bibliothek mit 128 Spezialisten (Experten) vor. Wenn eine Frage an Sie gestellt wird – entscheidet der Router, welche 2 Spezialisten er rufen soll. Aber um diese Entscheidung sofort treffen zu können, müssen alle 128 Spezialisten im Raum anwesend sein – Sie können nicht warten, bis sie von zu Hause kommen.

So funktioniert MoE: Der Router weiß nicht im Voraus, welche Experten für den nächsten Token benötigt werden. Daher müssen alle 128 Experten gleichzeitig in den Speicher geladen werden. 3,8 Milliarden werden aktiviert – aber alle 26 Milliarden werden gespeichert.

Das ist eine grundlegende Einschränkung der Architektur, kein Implementierungsfehler. MoE spart Berechnungen (und damit Geschwindigkeit und Energie), aber nicht Speicher.

Reale Speicherberechnung

Gemma 4 26B in 4-Bit-Quantisierung (Q4_K_M) wiegt ~17-18 GB. Aber das ist nur das Gewicht des Modells. Dazu muss alles andere addiert werden:

Zusammenfassung für verschiedene Szenarien:

Was ist Swapping und warum es die Leistung zerstört

Wenn dem Modell der RAM ausgeht – beginnt das Betriebssystem, die SSD als "langsamen Arbeitsspeicher" zu verwenden. Das ist Swapping. Auf einer SSD ist die Lese-/Schreibgeschwindigkeit 10-100 Mal langsamer als RAM – daher bricht die Leistung katastrophal ein.

In der Praxis sieht das so aus: Anstelle normaler 20-50 Tokens/Sek. erhalten Sie 1-2 Tokens/Sek. Eine Antwort dauert mehrere Minuten. Wenn mehrere Anfragen gleichzeitig eingehen – kann das System vollständig einfrieren oder den Ollama-Prozess beenden.

Genau das ist dem Entwickler auf dem erwähnten Mac mini mit 24 GB passiert: 26B ließ nur ~7 GB für macOS übrig – und bei der ersten Belastung ging das System in den Swap.

Vergleich: 26B MoE vs. E4B im Speicher

Um den Unterschied besser zu verstehen – hier ist ein Vergleich zweier Modelle auf einem Mac mit 16 GB Unified Memory:

Sonderfall: Großer Kontext und KV-Cache

26B unterstützt 256K Kontext – das ist einer der Hauptgründe, warum es für RAG beworben wird. Aber es gibt einen Haken: Der KV-Cache wächst linear mit der Kontextgröße.

Bei 256K Tokens kann der KV-Cache 25-30 GB beanspruchen – genauso viel wie das Modell selbst. Das bedeutet, dass Sie für die vollständige Nutzung von 256K Kontext nicht 24 GB, sondern 50-60 GB RAM benötigen.

Fazit: Wenn Sie 26B speziell für großen Kontext verwenden möchten – planen Sie mindestens 48 GB RAM in Ihrem Hardware-Budget ein. Andernfalls ist E4B mit 128K Kontext die praktischere Lösung.

🔴 Проблеми: що повідомляє спільнота

Ich habe 26B persönlich nicht getestet – auf einem M1 mit 16 GB passt es einfach nicht. Aber ich habe echte Berichte von Leuten gesammelt, die es ausprobiert haben. Das Bild ist eindeutig.

Mac mini 24 GB — der aufschlussreichste Fall:

Ein Entwickler, der Ollama auf einem Mac mini mit 24 GB eingerichtet hat, beschrieb seine Erfahrungen in einem detaillierten GitHub gist: 26B belegte ~17 GB und ließ nur ~7 GB für macOS und Systemprozesse übrig. Unter Last (mehrere parallele Anfragen) begann das System stark zu swappen, wurde nicht mehr reaktionsfähig und beendete manchmal Prozesse. Fazit: Zurück zu E4B als Standard, da es ~14 GB für das System übrig lässt und stabil läuft.

MacBook Pro M4 Pro 24 GB — konkrete Zahlen:

Ein Entwickler, der alle vier Varianten von Gemma 4 auf einem M4 Pro mit 24 GB getestet hat, veröffentlichte die Ergebnisse auf DEV Community. Ergebnisse über Ollama: E2B — 95 Tokens/Sek., E4B — 57 Tokens/Sek., 26B — ~2 Tokens/Sek. (Swap), 31B — passte nicht. Fazit: "For 24GB MacBook: ollama run gemma4:e4b is the answer."

16 GB Systeme — versuchen Sie es gar nicht erst:

Laut einem detaillierten Leitfaden auf DEV Community: "The 16GB models won't cut it — even with aggressive quantization, you'll be swapping constantly." Auf 16 GB Unified Memory kann 26B technisch geladen werden, wird aber bei jeder Anfrage swappen — was die Arbeit praktisch unmöglich macht.

Geschwindigkeit ohne Swapping — ein anderes Bild:

Wenn 26B auf einer Maschine mit ausreichend Speicher (32+ GB) läuft, ändert sich das Bild. Ein Entwickler in den HuggingFace discussions berichtet von 50 Tokens/Sek. auf einer RTX 5070Ti mit 16 GB VRAM über llama.cpp mit dem Parameter --n-cpu-moe — aber das ist eine spezifische Konfiguration, kein Standard-Ollama.

🐛 Bugs auf Apple Silicon: Flash Attention und mehr

Neben Speicherproblemen gibt es technische Bugs, die spezifisch für Apple Silicon sind und 26B auf dem Mac noch unattraktiver machen.

Ein detaillierter Bericht aus den GitHub issues von Ollama (Test auf M5 Max 128 GB) deckte drei separate Bugs auf:

Bug 1 — Flash Attention Hänger: Wenn OLLAMA_FLASH_ATTENTION=1 aktiviert ist und der Prompt länger als ~500 Tokens ist, hängt das Modell unendlich. CPU/GPU-Auslastung fällt auf 0%. Ohne Flash Attention — das Modell funktioniert, ist aber deutlich langsamer (~15 Tokens/Sek. auf M5 Max statt erwarteter 75+).

Bug 2 — Streaming über den /v1 Endpoint: Bei Verwendung der OpenAI-kompatiblen API landet die Antwort im Feld reasoning anstelle von content. Das bricht alle Clients, die Standard-OpenAI-SDK-Wrapper verwenden. Workaround: Verwenden Sie den nativen Ollama /api/chat Endpoint anstelle von /v1/chat/completions.

Bug 3 — MLX wird nicht unterstützt: Ollama auf Apple Silicon verwendet normalerweise MLX zur Beschleunigung. Für Gemma 4 ist die MLX-Unterstützung noch nicht implementiert — das Modell wird über llama.cpp gestartet, was langsamer ist.

Außerdem wurde in den GitHub llama.cpp issues eine Geschwindigkeitsregression von ~3,8x auf einem M4 Mac mini mit 16 GB beim Starten von 26B dokumentiert: Einige Versionen von llama.cpp zeigen eine starke Leistungsverschlechterung speziell bei MoE-Modellen mit Apple Silicon.

Fazit: Stand April 2026 hat Gemma 4 26B auf Apple Silicon aktiv zu behebende Bugs. Wenn Sie den Einsatz in der Produktion oder für Agentenaufgaben planen — überprüfen Sie den Status der Issues vor dem Deployment.

✅ Wann 26B MoE wirklich gewinnt

Mit der richtigen Hardware ist 26B MoE ein wirklich beeindruckendes Modell. Das Problem ist nicht die Architektur, sondern dass sie für Hardware empfohlen wird, auf der sie sich nicht entfalten kann.

Nach all den Fallstricken ist es fair zu sagen, wann 26B MoE wirklich die richtige Wahl ist. Es gibt vier Szenarien, in denen sie eindeutig gewinnt.

🎯 Szenario 1: RTX 3090 / RTX 4090 mit 24 GB VRAM

Dies ist das beste Szenario für 26B MoE. Das Modell (17-18 GB in Q4_K_M) passt vollständig in den VRAM, ohne zu swappen. Der GPU-Speicher ist deutlich schneller als der System-RAM – daher profitiert die Inferenz maximal von der MoE-Architektur.

Was Sie auf einer RTX 4090 erhalten:

• Generierungsgeschwindigkeit: 40-60 Token/Sek. (im Vergleich zu ~20 bei 31B Dense)
• Antwortqualität: Praktisch identisch mit 31B bei den meisten Aufgaben
• VRAM-Rest für Kontext: ~6 GB – ausreichend für 32-64K Token

Für Windows-Entwickler mit einer RTX-Karte ist dies der praktischste Weg zu großer Modellqualität ohne Kompromisse bei der Geschwindigkeit. 31B Dense passt auch auf eine RTX 4090, ist aber aufgrund der Dense-Architektur, bei der alle Parameter aktiviert werden, merklich langsamer.

🎯 Szenario 2: Mac M2/M3 Pro oder Max mit 32+ GB Unified Memory

Auf Macs mit 32 GB wird das Modell komfortabel geladen: ~18 GB für das Modell + ~14 GB bleiben für macOS und den KV-Cache. Kein Swapping, keine Hänger. Die Unified Memory-Architektur von Apple Silicon bietet einen zusätzlichen Vorteil – GPU und CPU teilen sich einen einzigen Speicherpool, sodass es keine Einschränkungen durch separaten VRAM gibt.

Praktisches Beispiel: Ein Entwickler auf DEV Community hat 26B auf einem Mac mini mit 32 GB und Q4_K_M-Quantisierung mit einem Kontext von 8192 Token getestet – alles funktionierte stabil den ganzen Arbeitstag über. Empfehlung: Schließen Sie unnötige Browser-Tabs, bevor Sie das Modell laden – Chrome allein kann 3-5 GB verbrauchen.

Auf Mac M2/M3 Max mit 64 GB+ können Sie sowohl 26B MoE als auch 31B Dense komfortabel ausführen und sie sogar für spezifische Aufgaben vergleichen.

🎯 Szenario 3: Produktions-API mit mehreren gleichzeitigen Benutzern

Die MoE-Architektur hat einen einzigartigen Vorteil bei der parallelen Verarbeitung von Anfragen. Verschiedene Token von verschiedenen Benutzern können unterschiedliche Expertensätze aktivieren – dies wird auf der GPU natürlich parallelisiert.

Für die Serverbereitstellung, bei der der Durchsatz wichtiger ist als nur die Latenz einer einzelnen Anfrage, kann 26B MoE mehr gleichzeitige Benutzer bedienen als 31B Dense bei gleicher GPU-Anzahl. Dies ist besonders relevant für:

• Unternehmens-RAG-Systeme, bei denen mehrere Mitarbeiter gleichzeitig Fragen stellen
• API-Dienste, die einen hohen Durchsatz erfordern
• Batch-Dokumentenverarbeitung, bei der die Geschwindigkeit wichtiger ist als die Qualität jeder einzelnen Antwort

Die Unsloth-Dokumentation bestätigt den Vorteil von MoE für dieses Szenario: Das Modell aktiviert nur ~4B Parameter pro Token, was die Belastung des Speicherbandbreite reduziert und die parallele Verarbeitung von mehr Anfragen ermöglicht.

🎯 Szenario 4: Vergleich der Qualität von 26B vs. 31B bei ausreichend Speicher

Wenn Sie 32+ GB haben und zwischen 26B MoE und 31B Dense wählen – der Qualitätsunterschied ist geringer als der Name vermuten lässt. Auf Benchmarks:

Der Qualitätsunterschied ist minimal – 1-3%. Aber der Geschwindigkeitsunterschied ist erheblich: MoE aktiviert ~4B Parameter anstelle von 31B und generiert daher Token deutlich schneller. Für die meisten praktischen Aufgaben – Codierung, Textanalyse, Beantwortung von Fragen – ist 26B MoE die bessere Wahl als 31B Dense, wenn Sie 32 GB haben.

31B Dense gewinnt in Nischenszenarien: komplexe Mathematik, bei der jeder Prozentpunkt Genauigkeit entscheidend ist, Fine-Tuning, bei dem die Stochastik des MoE-Routers das Training erschwert, und Aufgaben, bei denen maximale Deterministik der Antworten wichtig ist.

Allgemeine Auswahlregel

💻 Welche Hardware wird wirklich für 26B benötigt

Eine ehrliche Tabelle ohne Marketing. Basiert auf realen Berichten der Community, nicht auf offiziellen Mindestanforderungen.

✅ Fazit: Kaufen oder nicht

26B MoE ist ein ausgezeichnetes Modell für die richtige Hardware. Das Problem ist, dass die meisten Leute, die es ausprobieren möchten, Hardware haben, auf der es sich nicht entfaltet.

Wenn Sie 32+ GB RAM oder eine RTX 3090/4090 haben, ist 26B MoE eine ausgezeichnete Wahl. Schneller als 31B Dense bei fast gleicher Qualität. Besonders geeignet für Produktionsszenarien, bei denen die Antwortgeschwindigkeit wichtig ist.

Wenn Sie 24 GB oder weniger haben, lautet mein Fazit basierend auf der Erfahrung der Community: Es lohnt sich nicht. Technisch wird es laufen, aber die Erfahrung wird enttäuschend sein. E4B auf 8-16 GB liefert ein besseres praktisches Ergebnis als 26B, das swappt.

Die allgemeine Regel von der Unsloth-Dokumentation: "Als Faustregel sollte Ihr insgesamt verfügbarer Speicher die Größe des heruntergeladenen quantisierten Modells mindestens überschreiten." Für 26B bedeutet dies mindestens 20+ GB freien Speicher nach dem Laden des Betriebssystems.

📚 Lesen Sie auch

• Gemma 4: Vollständiger Überblick – Größe, Lizenz, Vergleich mit Gemma 3
• Gemma 4 auf M1 16 GB – reale Tests: Code, Text, Geschwindigkeit
• Reasoning Mode in Gemma 4 – wie man ihn aktiviert und wann er benötigt wird