Die Architektur, die das möglich macht, steht in Googles Modellkarte: Gemma 4 26B-A4B ist ein Mixture-of-Experts-Modell mit 25,2 Milliarden Parametern insgesamt und rund 3,8 Milliarden aktiven je Token, verteilt auf 30 Schichten mit je 128 Experten, von denen acht plus ein gemeinsamer Experte pro Token laufen. Kontextfenster 256.000 Token, Lizenz Apache 2.0, Text und Bild. TurboFieldfare nutzt die Text-Variante. (Das Projekt nennt „26B total, about 3.88B active per token“ – die Modellkarte ist mit 25,2 Milliarden genauer; die Differenz erklärt sich aus der gerundeten Namensgebung „26B-A4B“.)
Die Aufteilung: Rund 1,35 Gigabyte bleiben dauerhaft resident – alles, was ein Token in jedem Fall braucht. Die gerouteten Experten selbst, 30 Schichten mal 128 Stück, machen den weitaus größten Teil der 14,3 Gigabyte aus und werden nie vollständig geladen; das Projekt hält je Schicht einen Zwischenspeicher mit 16 Plätzen und füllt Fehltreffer per `pread` direkt von der SSD. Verdrängt wird nach dem am seltensten benutzten Eintrag (LFU) statt nach dem am längsten nicht benutzten – eine Wette darauf, dass manche Experten quer über alle Token häufig gezogen werden und andere fast nie, dass die Nutzungshäufigkeit also mehr über den nächsten Treffer sagt als der Zeitpunkt des letzten.
Warum der Nachschub nicht vorab geplant werden kann, ist der harte Teil des Problems und in der Bauweise von Mixture-of-Experts angelegt: Welche acht Experten eine Schicht braucht, entscheidet der Router erst, nachdem die Attention dieser Schicht gerechnet ist – die Auswahl hängt am aktuellen Token und allen davor. Vorausschauendes Laden scheidet damit aus; 30-mal je Token muss tatsächlich die Platte gelesen werden. Dass das trotzdem trägt, liegt an zwei Umständen. Der gemeinsame Experte läuft ohnehin bei jedem Token, sodass sich der Lesevorgang hinter Arbeit verstecken lässt, die anfällt. Und Apple-Silicon-Macs haben Unified Memory: Prozessor und Grafikeinheit sehen denselben physischen Speicher, ein Metal-Puffer ist einfach Speicher, den beide lesen können. Auf einem PC mit eigener Grafikkarte müssten die Gewichte erst in den Systemspeicher und von dort über PCIe in den VRAM – zwei Kopien, tausendfach pro Sekunde. Deshalb ist das ein Mac-Projekt.
Der Reifegrad: Erste öffentliche Fassung war v0.1 am 20. Juli 2026, seither kamen ein OpenAI-kompatibler lokaler Server (v0.2, 27. Juli), fortsetzbare Downloads (v0.2.1, 28. Juli) und eine deutlich beschleunigte Verarbeitung langer Eingaben dazu (v0.3, 29. Juli: laut Projekt 2,4-fach schnelleres Prefill bei 32.000 Token Eingabe, von 491 auf 204 Sekunden). Vorausgesetzt werden macOS 26 mit Metal 4 sowie Xcode 26 und Swift 6.2; als validiertes Zielgerät nennt das Projekt ausdrücklich das MacBook Air M2 mit acht Gigabyte. Mitgeliefert werden eine Swift-Bibliothek, ein Kommandozeilenwerkzeug und eine native Mac-App.
Beleglage: Architektur, Speicheraufteilung, Lizenz, Versionsverlauf und die Leistungszahlen stammen aus dem Projekt-Repository selbst und sind damit Selbstauskunft des Entwicklers; die Modell-Kennzahlen sind an Googles Modellkarte gegengeprüft. Unabhängig nachgemessen hat bislang, soweit wir sehen, niemand systematisch. Ein erster fremder Durchlauf liegt vor: Der Kanal Better Stack berichtet aus eigenem Test 23,4 Token pro Sekunde bei 2,15 Gigabyte Speicherbedarf auf einem M3 Max und nennt das Ergebnis „completely usable“ – ein Wert, der zwischen den beiden Projekt-Messungen liegt und insofern plausibel ist, aber eine einzelne, nicht reproduzierte Messung bleibt.