Im Juli 2026 sorgte ein Open-Source-Projekt namens TurboFieldfare auf Hacker News für Aufsehen, sammelte 608 Punkte und löste über 200 Diskussionen aus. Der Grund war verblüffend simpel: Es ermöglichte das Ausführen eines Large Language Models mit 26 Milliarden Parametern auf einem Mac-Notebook mit nur 8 GB Arbeitsspeicher – bei einem RAM-Verbrauch von lediglich etwa 2 GB.
26 Milliarden Parameter. 2 GB Arbeitsspeicher. Diese beiden Zahlen nebeneinander klingen zunächst widersprüchlich.
Große KI-Modelle erfordern nicht zwangsläufig riesige Grafikkarten. Das ist die Kernbotschaft dieses Artikels.
Eine scheinbar unmögliche Aufgabe
Zunächst zum Hintergrund. Gemma 4 ist eine Familie von Open-Source-Modellen, die Google DeepMind Anfang 2026 veröffentlichte. Eine Variante namens „Gemma 4 26B-A4B“ nutzt eine Mixture-of-Experts-Architektur (MoE, weiter unten erklärt). Selbst nach vierfacher Komprimierung benötigt dieses Modell immer noch 14 GB Festplattenspeicher.
Die meisten handelsüblichen Mac-Notebooks verfügen jedoch nur über 8 GB RAM – wovon das Betriebssystem selbst bereits 3 bis 4 GB beansprucht. Der verbleibende Speicherplatz für große Sprachmodelle ist somit stark begrenzt.
Herkömmliche Inferenz-Werkzeuge (wie llama.cpp oder MLX) laden das gesamte Modell vollständig in den Arbeitsspeicher, bevor sie es ausführen. Ein 14-GB-Modell kann unmöglich auf einem 8-GB-System geladen werden – das Betriebssystem würde einer einzelnen Anwendung niemals erlauben, den gesamten Arbeitsspeicher zu beschlagnahmen. Dieser Weg war von Beginn an eine Sackgasse.
So entstand die entscheidende Frage: Gibt es eine Möglichkeit, das Modell auszuführen, ohne es vollständig in den RAM zu laden?
Andrey Mikhaylov, Entwickler von TurboFieldfare sowie iOS- und Metal-Ingenieur, lieferte eine klare Antwort. Er investierte mehrere Wochen, führte 103 Experimente durch und schrieb eine Inferenz-Engine von Grund auf neu – unter Verwendung von Swift und Apples Metal-Grafik-Framework. Das Ergebnis: 5 bis 6 Tokens pro Sekunde auf einem M2 MacBook Air und bis zu 31 bis 35 Tokens pro Sekunde auf dem neuesten M5 Pro.
Das System funktioniert nicht nur, sondern erreicht absolut praxistaugliche Geschwindigkeiten. Dies ist kein theoretisches Konzept, sondern ein betriebsbereites Engineering-Projekt zum Herunterladen.
Der verborgene Vorteil von MoE-Modellen: Perfekt für Streaming geeignet
Um diese Lösung zu verstehen, muss man die Besonderheit der Mixture-of-Experts-Architektur (MoE) betrachten.
Ein herkömmliches Sprachmodell fungiert als „Generalist“ – bei der Generierung jedes einzelnen Wortes müssen sämtliche Parameter des gesamten Modells berechnet werden. Das gleicht einem Großunternehmen, in dem jeder Mitarbeiter an jedem einzelnen Projekt mitarbeiten muss – extrem uneffizient.
MoE-Modelle arbeiten völlig anders. Sie ähneln einem Unternehmen mit 128 spezialisierten Abteilungen. Trifft eine neue Aufgabe ein, analysiert ein sogenannter „Router“ den Inhalt und aktiviert exakt die 8 am besten geeigneten Abteilungen. Die übrigen 120 Abteilungen bleiben inaktiv.
Von den insgesamt 26 Milliarden Parametern des Modells sind bei jedem einzelnen Berechnungsschritt nur etwa 3,8 Milliarden tatsächlich beteiligt. Das bedeutet das „A4B“ in „26B-A4B“: Active 4 Billion (ca. 4 Milliarden aktive Parameter).
Diese Architektureigenschaft bestimmte die strategische Ausrichtung von TurboFieldfare: Wenn jedes Mal weniger als ein Zehntel der Experten benötigt wird, warum sollten dann die restlichen 90 % der Gewichte dauerhaft im RAM liegen?
Drei Kernoptimierungen, um ein 14-GB-Modell in 2 GB RAM einzupassen
Herkömmliche Inferenz-Frameworks laden alle 128 Experten-Gewichte komplett in den Arbeitsspeicher, um jederzeit bereit zu sein. Das entspricht einer Firma, die für alle 120 inaktiven Mitarbeiter permanente Arbeitsplätze bereithält und damit ein ganzes Gebäude belegt.
TurboFieldfare nutzt einen direkten Ansatz: Nur wer arbeitet, bekommt einen Platz.
1. 4-fache Komprimierung: Datenverschlankung
Die Gewichtsdaten von Modellen weisen erhebliche mathematische Redundanz auf. Vergleichebar mit einem 4K-Ultra-HD-Foto, das auf 1080p komprimiert im Alltag kaum vom Original zu unterscheiden ist.
TurboFieldfare setzt auf 4-Bit-Quantisierung – die Präzision der Modellparameter wird von 16 Bit auf 4 Bit reduziert, was die Dateigröße auf ein Viertel schrumpft. So entstanden die 14 GB komprimierten Gewichtsdaten. Die Router-Schichten nutzen 8-Bit-Quantisierung zur Wahrung der Routing-Genauigkeit, während die Hauptgewichte in 4-Bit vorliegen, was eine akzeptable Antwortqualität gewährleistet.
2. SSD-Streaming: Der RAM speichert nur den gemeinsamen Zustand
Dies ist das zentrale technische Design des gesamten Projekts.
TurboFieldfare behält nur den 1,35 GB großen gemeinsamen Teil (gemeinsame Berechnungsschichten und KV-Cache) im Arbeitsspeicher. Die Gewichte aller 128 Experten verbleiben auf der SSD. Bei jedem einzelnen Token-Generierungsschritt werden nur die aktuell benötigten 8 Experten von der SSD gelesen.
Hier existiert jedoch eine physikalische Grenze: SSD-Zugriffszeiten liegen im Millisekundenbereich, während RAM-Zugriffszeiten im Nanosekundenbereich liegen – ein Geschwindigkeitsunterschied vom Zehntausendfachen. Würde man bei jedem Lesevorgang starr auf die SSD warten, wäre die Generierungsgeschwindigkeit unbrauchbar langsam.
3. Intelligenter Cache + Zeitliche Überlappung
Der Entwickler entwarf drei Optimierungsebenen, um dieses Geschwindigkeitsgefälle zu überbrücken:
Experten-Cache. Obwohl pro Schritt 8 Experten benötigt werden, überschneiden sich die geforderten Experten bei aufeinanderfolgenden Tokens häufig. TurboFieldfare hält für jede Schicht 16 Cache-Plätze bereit und nutzt einen LFU-Algorithmus (Least Frequently Used), um zu entscheiden, welche Experten im Speicher verbleiben. Bei einem Cache-Treffer entfällt das erneute Lesen von der SSD. Experimentelle Daten zeigen, dass dieser Cache die Lesezeit pro Token von 166 ms auf 88 ms senkte.
Paralleles Vorlesen (pread). Sich auf On-Demand-Paging (mmap) zu verlassen, um das Betriebssystem das Laden der Seiten verwalten zu lassen, wirkt zwar elegant, führte in Praxistests jedoch zu katastrophalen Ergebnissen – beim Kaltstart sank die Geschwindigkeit auf 0,5 tok/s. Der Entwickler wechselte zu expliziten parallelen pread-Systemaufrufen, um Leseanfragen aktiv nebenläufig zu starten, was die Geschwindigkeit auf 3,97 tok/s steigerte. Diese Entscheidung basierte auf empirischen Messungen statt auf theoretischen Annahmen.
Zeitliche Überlappung. Während die SSD die Expertendaten liest, bleibt die GPU nicht untätig – sie berechnet die gemeinsamen Schichten des Modells. Wenn die Berechnung der gemeinsamen Schichten abgeschlossen ist, sind die Daten von der SSD punktgenau eingetroffen. Durch diese präzise Ablaufsteuerung wird die Wartezeit nahezu vollständig verborgen. Ein grobkörniges Überlappen (erst gesammelt lesen, dann berechnen) erwies sich als stabiler und effizienter als eine feingliedrige Einzelverarbeitung.
103 Experimente, der Großteil davon Fehlschläge
Ingenieurarbeit unterscheidet sich von wissenschaftlichen Publikationen. Arbeiten zeigen oft nur den erfolgreichen Pfad; echtes Engineering erfordert es, alle Sackgassen selbst zu beschreiten.
Die Dokumentation von TurboFieldfare verzeichnet die detaillierten Ergebnisse von 103 Experimenten. Der Autor teilt dabei offen jene Versuche, die auf dem Papier vielversprechend aussahen, sich in der Praxis jedoch als wirkungslos erwiesen:
Speicher-Mapping (mmap) schien elegant. Es lässt das Betriebssystem das Laden verwalten und erfordert minimalen Code. Testergebnis: 0,5 tok/s beim Kaltstart, praktisch unbrauchbar.
SIMD-Kooperations-Kernel. Mehrere Threads arbeiteten zusammen an einem Experten, um sauberen Code zu erzielen. Ergebnis: Die GPU-Rechenzeit verdoppelte sich von 230 ms auf 527 ms. Die Idee wurde verworfen.
Schichtübergreifendes Vorlesen. Wenn in Schicht N Experten A und B gewählt wurden, kann man dann die Experten für Schicht N+1 vorab laden? Analysen zeigten, dass die Expertenauswahl benachbarter Schichten nahezu unkorreliert war – die Vorhersagegenauigkeit lag bei mageren 7 %.
Feingliedrige Asynchronität. Die Berechnung sofort zu starten, sobald ein einzelner Experte gelesen wurde, erzeugte Synchronisations-Overhead, der die Gesamtgeschwindigkeit bremste und die Ergebnisse veränderte. Schließlich setzte sich die einfachere, grobkörnige Variante durch.
Der Wert dieser Fehlschläge steht dem Erfolg in nichts nach. Sie unterstreichen eine einfache, aber oft verdrängte Wahrheit: Die einzige nützliche Optimierung ist diejenige, die in der Praxis verifiziert wurde.
Warum das wichtig ist
Die Bedeutung von TurboFieldfare liegt im Beweis einer grundlegenden Erkenntnis:
Die Inferenz großer Sprachmodelle erfordert nicht zwingend teure High-End-GPUs.
Durch kompromisslose Software-Optimierung – SSD-Streaming, intelligentes Caching und hardwarenahes Kernel-Design – können ganz normale Alltags-Laptops zu leistungsfähigen KI-Inferenz-Knoten werden.
Derzeit werden High-End-GPUs von wenigen Konzernen monopolisiert, sind extrem teuer und schwer verfügbar. Projekte wie TurboFieldfare zeigen einen alternativen Weg auf: Anstatt von noch teurerer Hardware abhängig zu sein, werden physische Grenzen durch bessere Software neu definiert.
Dies erinnert an die PC-Spieleindustrie der 1990er Jahre. Damals liefen 3D-Spiele nur auf professionellen Grafik-Workstations, bis Grafikkarten für Endverbraucher erschienen und normale PCs 3D-fähig machten. TurboFieldfare befindet sich in einer frühen Phase dieses historischen Prozesses und zeigt der Branche: KI-Inferenz muss nicht an Hardware-Monopole gebunden sein.
Aktuell verzeichnet das Projekt auf GitHub über 900 Sterne, und die Community steuert weitere Benchmark-Daten bei. Der Entwickler plant zudem Versionen für iPhone und iPad, um lokale LLMs auch auf mobilen Geräten nutzbar zu machen.
Vielleicht wird in naher Zukunft auf Ihrem Smartphone oder sogar in Ihren Kopfhörern ein KI-Assistent mit tens of billions von Parametern laufen, der im Arbeitsspeicher nur wenige Dutzend Megabyte belegt. TurboFieldfare ist ein wichtiger Meilenstein auf diesem Weg – und weist klar die Richtung nach vorne.
Referenz-Links:
- GitHub: TurboFieldfare Repository
- HN-Diskussion (item?id=49098510)
- Gemma 4 Technischer Bericht
- Maarten Grootendorsts visueller Leitfaden zu Gemma 4
- TurboFieldfare Systemarchitektur-Dokumentation
- TurboFieldfare Optimierungs-Experimente (103 Experimente)
