TurboFieldfare – Open-Source-Engine, der Gemma 4 26B auf allen Macs der M-Serie mit 2 GB RAM ausführt

 (github.com/drumih)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • TurboFieldfare führt Gemma 4 26B-A4B mit rund 2 GB Speicher aus, ohne das komplette 14,3-GB-Modell in den Arbeitsspeicher zu laden, und ermöglicht damit lokale Inferenz auch auf Apple-Silicon-Macs mit 8 GB RAM
  • Es hält nur einen 1,35-GB-Shared-Core und den FP16-KV-Cache resident und streamt pro Token die benötigten MoE-Expert-Gewichte von der SSD; ein LFU-Cache mit 16 Slots und paralleles pread begrenzen die I/O-Last
  • Gemma 4 26B-A4B aktiviert pro Token etwa 3,88 Mrd. Parameter; die gemessene Decoding-Geschwindigkeit liegt bei 5,1–6,3 tok/s auf einem M2 MacBook Air mit 8 GB und bei 31–35 tok/s auf einem M5 Pro mit 24 GB
  • Es handelt sich um eine dedizierte Runtime in Swift 6.2 und Metal 4, die eine native Mac-App, CLI, Installationswerkzeuge und einen experimentellen OpenAI-kompatiblen Server auf Basis desselben .gturbo-Modellverzeichnisses bereitstellt
  • Der aktuelle Umfang ist auf rein textbasierte Inferenz auf Apple-Silicon-Macs mit macOS 26 oder neuer und mindestens 8 GB RAM beschränkt; Bilder, Sprache, Video sowie Remote-Server-Authentifizierung und TLS werden nicht unterstützt

Ausführungsarchitektur zur Speicherreduktion

  • TurboFieldfare lädt das instruction-tuned Gemma 4 26B-A4B nicht vollständig in den Arbeitsspeicher
    • Der 1,35-GB-Shared-Core und der FP16-KV-Cache bleiben im Speicher
    • Nur die pro Token benötigten routed Experts werden von der SSD in für Metal sichtbare Buffer gelesen
    • Das installierte reine Textmodell ist etwa 14,3 GB groß, aber Gewichte und 4K-KV-Cache belegen nur rund 2 GB Speicher
  • Das Modell aktiviert von insgesamt 26 Mrd. Parametern pro Token etwa 3,88 Mrd. Parameter
  • Die Gewichte verwenden MLX affine 4 Bit auf Basis von Gruppen mit 64 Elementen; der Router ist 8 Bit, Shared und routed Experts sind 4 Bit
  • Es ist kein Wrapper um MLX oder llama.cpp, sondern eine speziell für Gemma 4 26B-A4B entwickelte Swift-/Metal-Runtime

Ablauf der Token-Erzeugung

  • In jedem Transformer-Layer berechnet Metal Attention und Router mit residenten Gewichten
  • Die CPU gleicht die vom Router ausgewählten Top-8-Expert-IDs mit einem LFU-Cache mit 16 Slots pro Layer ab
    • Cache Misses werden über eine begrenzte Anzahl paralleler pread-Aufrufe gefüllt
    • Während der SSD-Lesevorgang läuft, berechnet Metal den residenten shared-expert-Zweig
    • Nach Abschluss des Lesens werden shared output und routed output kombiniert
  • Das Prompt-Prefill nutzt Chunks von bis zu 128 Token, sodass einmal geladene Experts mehrere Zeilen verarbeiten können
  • In der Generierungsphase wird die routed-layer-Schleife tokenweise wiederholt
  • Der KV-Cache nutzt für 25 Sliding-Window-Layer einen begrenzten Ringspeicher und für 5 Full-Attention-Layer linearen Speicher
  • Decoding-Attention verwendet ein exaktes Split-K/V-Verfahren mit getrennten Pfaden für normalisiertes K und V

Installation und Modellformat

  • Wird beim ersten Start Download gewählt, werden etwa 15 GB per Range Requests von einer festen Hugging-Face-Revision heruntergeladen
  • Der Installer erzeugt den ursprünglichen Checkpoint nicht vollständig als temporäre Datei oder im Speicher
    • Die benötigten Byte-Bereiche werden abgerufen und direkt in das .gturbo-Layout umgepackt
    • Da keine vollständigen Shards oder Tensoren separat vorbereitet werden, bleibt die temporäre Speichernutzung begrenzt
    • Eine fertige Installation kann erst verwendet werden, nachdem Manifest- und Datei-Hash-Prüfung bestanden wurden
  • Nach Abschluss der Installation belegt das Modell etwa 14,3 GB Speicherplatz; der Installationsvorgang selbst lädt das Modell nicht in den Arbeitsspeicher
  • Die Runtime akzeptiert nur ein vollständiges .gturbo-Verzeichnis mit finaler manifest.json
  • Unterstützt werden das Fortsetzen unterbrochener Downloads, das Löschen teilweiser Downloadzustände und eine Installationsprüfung ohne Laden des Modells

Laufzeitumgebung und Performance

  • Erforderlich sind ein Apple-Silicon-Mac, macOS 26, Metal 4, Xcode 26 und Swift 6.2 oder neuer
  • Das Paket ist nur für arm64; ältere macOS- und Metal-Versionen werden nicht unterstützt
  • Verifiziert wurde auf einem M2 MacBook Air mit 8 GB; für die Modellinstallation sind freier Speicherplatz und für den Erst-Download eine Internetverbindung erforderlich
  • Die gemessene Decoding-Performance beträgt:
    • M2 MacBook Air mit 8 GB: 5,1–6,3 tok/s
    • M5 Pro mit 24 GB: 31–35 tok/s
  • Der Durchsatz hängt von Prompt-Länge, Generierungslänge, Zustand des Page Cache und Hardware ab; die Messwerte sind daher Referenzpunkte, keine Performance-Obergrenzen
  • Vor dem Ausführen des Modells sollten speicherintensive Apps geschlossen und der freie Speicher mit memory_pressure -Q geprüft werden
  • App, Decode Service, CLI, Server, Tests oder andere lokale Modellprozesse sollten jeweils nur einzeln laufen

Bereitgestellte Produkte und Nutzung

  • Das Swift-Paket stellt sechs Produkte bereit
    • TurboFieldfare: Swift-Bibliothek mit Runtime und Metal-Kernels
    • TurboFieldfareMac: native Mac-App für Installation und Generierung
    • TurboFieldfareDecodeService: einmaliger lokaler Modell- und Metal-Besitzerprozess, den die Mac-App verwendet
    • TurboFieldfareCLI: instruction chat und raw completion über die Kommandozeile
    • TurboFieldfareServer: OpenAI-kompatibler Chat-Completions-Server auf Loopback
    • TurboFieldfareRepack: Werkzeug für Streaming-Installation und Installationsprüfung
  • In der Mac-App lädt man das Modell herunter, wählt anschließend Load Model und gibt einen Prompt ein, um zu generieren
    • In der Statusleiste lassen sich Fortschritt, Decoding-Geschwindigkeit und Speichernutzung prüfen
    • Sampling, Context Length, Expert-Cache-Slots und Runtime-Optionen können angepasst werden
  • Der instruction chat der CLI nimmt ein JSON-Array von Nachrichten entgegen und wandelt es in dasselbe Format wie die Mac-App um
    • Der Standardwert für das Antwortlimit --max-new beträgt 1.024 Token
    • Die Mac-App kann generieren, bis das ausgewählte Context Window gefüllt ist
  • --prompt wird für raw completion ohne Anwendung des Chat-Formats und für reproduzierbare Vergleiche verwendet
  • Generierter Text wird an die Standardausgabe, Zeitstatistiken an die Standardfehlerausgabe gesendet; mit --quiet lässt sich die Statistik-Ausgabe deaktivieren

Prompts und unterstützter Umfang

  • Die Mac-App behandelt Eingaben als Instruction und wendet automatisch Gemmas Chat-Format an
  • Die Standard-Sampling-Einstellungen sind temperature 0.2, Top-K 64 und Top-P 0.95
    • Wird temperature auf 0 gesetzt, wird deterministischer greedy output verwendet
    • Das Modell kann sich wiederholen oder falsche Antworten geben; wichtige Ergebnisse sollten daher überprüft werden
  • App und CLI unterstützen Nutzer- und Modellnachrichten sowie optional system guidance, exponieren oder führen jedoch keine Tools aus
  • Die aktuellen Ein- und Ausgaben des Modells sind rein textbasiert; Bilder, Audio und Video werden nicht unterstützt
  • Die CLI bietet --max-context, --temperature, --top-k, --top-p, --repetition-penalty, --seed und wiederholbare --stop-Strings

OpenAI-kompatibler lokaler Server

  • Der experimentelle Server läuft unter 127.0.0.1:8080/v1 und unterstützt Chat Completions, Streaming, Deklarationen von Function Tools und die Wiederverwendung eines einzelnen Prefix-Prompts
  • Der Server gibt vom Modell erzeugte tool calls zurück, aber Freigabe und Ausführung aller Tool-Aufrufe liegen beim Client
  • Da Remote-Authentifizierung und TLS fehlen, sollte der Server ausschließlich auf Loopback bleiben
  • Mac-App, CLI und Server verwenden dasselbe .gturbo-Verzeichnis, aber jeweils nur ein produktseitiger Modelleigner sollte gleichzeitig laufen

Implementierungsumfang und Experimentprotokoll

  • Custom-Metal-Kernels übernehmen quantisiertes GEMV, Attention, MoE, Normalization, RoPE, Sampling und Production Fusion
  • Die Runtime implementiert SSD-basiertes Streaming routed Experts, einen begrenzten Expert-Cache, chunkweises Prefill für einzelne Prompts und tokenweise Generierung
  • 103 Messergebnisse zu Kernels, Caching, I/O, Prefill und Decode werden als Experimentprotokoll geführt
  • Die Experimentdokumentation enthält Optimierungen mit großer Wirkung, gescheiterte Ideen und frühe Ergebnisse, die nach stärkerer Validierung revidiert wurden
  • Geplante Arbeiten sind die Entwicklung von iPhone- und iPad-Apps, Messungen zu mobiler Inferenzgeschwindigkeit und Speichernutzung sowie Benchmarks auf einem M4 Mac mini mit 16 GB und weiteren Apple-Silicon-Macs mit 8 GB

Lizenz und Modellbedingungen

  • Quellcode und Dokumentation werden unter der Apache License 2.0 veröffentlicht
  • Die Modellgewichte sind nicht im Repository enthalten; der Installer lädt sie separat von einem festen Hugging-Face-Checkpoint herunter
  • Für die Gewichte gelten weiterhin die ursprünglichen Distributionsbedingungen
  • TurboFieldfare ist ein unabhängiges Forschungsprojekt und weder mit Google verbunden noch von Google gesponsert oder genehmigt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Ich habe mich immer gefragt, warum man jedes Mal, nur weil auch Wissen darüber nötig sein könnte, wer König Charles ist, das gesamte Modell in den Speicher schiebt. Techniken, große Dateien in kleine Teile zu zerlegen und mit wenig Speicher effizient zu lesen, sind meiner Ansicht nach längst etabliert.
    In der KI-Branche an der Spitze scheint es eine Tendenz zu geben, beim Bau von Modellen stark zu sein, Skalierbarkeit und Praxistauglichkeit aber den Infrastrukturleuten zu überlassen. Wenn tatsächlich weniger als 10 % des Wissens genutzt werden, ließen sich die Kosten vermutlich schon durch Fine-Tuning und Optimierung deutlich senken.

    • Das gesamte Modell im Speicher zu halten ist deutlich schneller, als mit der Festplatte zu tauschen.
    • Im Grunde beschreibst du damit eine Mixture-of-Experts-(MoE)-Architektur. Wenn die Expertenschichten klein genug und die SSD schnell ist, kann man sie nur bei Bedarf laden.
      Dichte LLMs liefern normalerweise bessere Leistung, werden aber viel stärker ausgebremst als MoE, wenn man Schichten in externen Speicher auslagert.

  • Heutzutage muss man solche Security Reviews selbst laufen lassen, wenn man Projekte unbekannter Herkunft herunterlädt. Ich habe es angewiesen, die Agent-Anweisungen und Markdown-Dateien im Repository zu ignorieren und Swift-/Metal-Quellcode, Build-Skripte, CI-Konfigurationen und Abhängigkeiten zu prüfen. Es fand keinen Schadcode, keine Backdoors, keinen Diebstahl von Zugangsdaten und keine versteckten Netzwerk-Endpunkte, kam aber zu dem Ergebnis, dass weiterhin Risiken bei Kompilierung, Supply Chain und Runtime bestehen.
    Wenn jemand einen besseren Prompt hat, gern teilen; die Ausführung mit Cursor Composer 2.5 kostete unter 0,20 US-Dollar.

  • Wenn man macOS 15 auf einem M1 MacBook Air nutzt, kompiliert es, wenn man die folgenden zwei Zeilen löscht oder mit if #available(macOS 26.0, *) umschließt: opts.languageVersion = .version4_0
    Laut Kommentar verpasst man damit zwar den Effekt, dass Attention um den Faktor 11,24 schneller wird und Prefill um den Faktor 2,4 beschleunigt, aber auf einem M1 Air mit 8-Core-GPU kommen trotzdem 5–6 Token pro Sekunde heraus.

    • Nützliche Info. Vielleicht kann man die Mindestversion später absenken.
      Die 2,4-fache Prefill-Verbesserung funktioniert nur auf der apple10-GPU-Familie; der M1 ist meiner Erinnerung nach apple7.

  • Mich interessiert, wie dieses Projekt im Vergleich zu gewöhnlichem mmap abschneidet. Auch llama.cpp kann mit aktiviertem mmap und deaktiviertem Repacking ein 26B-Modell bei Bedarf mit 2 GB RAM ausführen.
    Der wesentliche Unterschied scheint zu sein, dass SSD-Lesevorgänge mit der Inferenzarbeit synchronisiert werden, um Latenzen zu minimieren; das Betriebssystem berücksichtigt diesen Ausführungskontext nicht.

    • Die erste Version nutzte mmap. Auf einem 8-GB-M2 dauerte das Lesen eines kalten 3,36-MB-Experten mit mmap 10 ms, mit pread 2,8 ms, und die Gesamtsimulation kam auf 0,50 bzw. 4 Token pro Sekunde.
      Bei mmap liest das Betriebssystem reaktiv nach, wenn das Modell eine Seite berührt, und weiß daher nicht, welcher Experte ausgewählt wurde oder wann sich GPU-Arbeit und Lesevorgänge überlappen lassen. Gemeinsame Gewichte verwenden der Einfachheit halber weiterhin mmap; llama.cpp kann vermutlich ebenfalls unter 2 GB laufen, dürfte aber langsamer sein.
    • Um die tatsächliche Geschwindigkeit zu prüfen, würde ich gern direkt mit dem SSD-Offloading von llama.cpp vergleichen.

  • Der Satz „Messwerte sind eine Basislinie, keine Leistungsobergrenze“ wirkt wie eine typische Claude-Formulierung.

    • Solche Formulierungen sind inzwischen so verbreitet, dass ich befürchte, mir dieselben Gewohnheiten anzueignen, wenn ich weiter Claude-artigen Stil lese.
    • Auch „Ich habe über 100 Experimente gemacht, die meisten sind gescheitert, aber einige haben hierher geführt“ wirkt nach derselben Spur.
    • Ursprünglich war es wahrscheinlich eher eine ChatGPT-Formulierung, aber deshalb werde ich nicht gleich unterstellen, dass ein westliches Unternehmen destilliert wurde. Rezeptblogs von nach 2022 könnten um 4.6–4.8 herum in die Trainingsdaten gelangt sein.
    • Ich denke, es ist Zeit, mit solchen Zuschreibungen aufzuhören. Das ist kaum mehr als eine neue Form von Grammatikpolizei und bringt keinen echten Mehrwert.
      Wenn der Autor mit einem LLM nur die Formulierungen geglättet hat und kein unnötiger Inhalt hinzugefügt wurde, ist das in Ordnung. Wenn der Text selbst ein nutzloses Generat ist, gibt man ihm einfach eine niedrige Bewertung.

  • Beeindruckend ist, dass auf einem M1 Max Mac Studio mit schnellerer SSD 12 Token pro Sekunde und fast sofortige Antworten herauskommen. Das zeigt die Möglichkeit, große Modelle nicht aus dem Speicher, sondern direkt von der SSD zu betreiben.

    • Leider ist hier die SSD-Lesegeschwindigkeit der größte Flaschenhals.

  • Es gibt inzwischen viele SSD-Streaming-Engines, aber nur wenige versuchen sich an den schwierigen Features. Da die wichtigsten Modelle MTP-Heads für Speculative Decoding haben, könnte man diese nutzen, um Expertengewichte von der SSD vorab zu lesen.
    Wenn die Gewichte bereitstehen, bevor die GPU sie braucht, lassen sich die Kosten von VRAM-Cache-Misses stark reduzieren; wenn sich das bewährt, könnten künftige Modelle eigene Heads zum Vorabladen von Experten haben und schon beim Training darauf ausgelegt werden.

    • Beim SSD-Streaming wartet man fast immer auf die SSD, bis die GPU den richtigen Experten erhält, daher gibt es auf SSD-Seite praktisch keinen Spielraum zum Vorablesen. Einen falsch vorhergesagten Experten zu lesen schadet eher, und deshalb hilft auch bestehendes MTP in typischen Nicht-Large-Batch-Umgebungen kaum.
    • In der Praxis ist es schwieriger, als es klingt. Jede Schicht hat eine andere Expertengruppe, und ein kleiner Router entscheidet anhand des Ausgabezustands der Experten der darunterliegenden Schicht, welche Experten genutzt werden.
      Mit den von MTP erzeugten Draft-Tokens kann man zwar die Experten der ersten Schicht vorhersagen, aber um die 10. Schicht zu kennen, muss man die Schichten 1 bis 9 ausführen und diese Experten zuerst lesen. Daher braucht man statt eines Next-Token-Generators eine Vorrichtung, die darauf trainiert ist, die Expertenaktivierung aller Schichten auf einmal vorherzusagen.

  • Ein Projekt zum Ausführen von DiffusionGemma ist ebenfalls fast fertig, und die beiden Projekte könnten gut zusammenpassen. Auf einem M3 mit 36 GB kommen etwa 20 Token pro Sekunde heraus, und die Wahrscheinlichkeit ist groß, dass sie gegenseitig schnellere Kernel übernehmen können.
    Der aktuelle Code liegt unter https://github.com/mmastrac/diffgemma, ist aber noch nicht releasefähig.

    • Ich habe es mir kürzlich angesehen, kam aber zu dem Schluss, dass es wenig praktischen Nutzen hat, Diffusionsmodelle lokal auszuführen: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...
      Mich würde deine Einschätzung dazu interessieren.
    • Diffusion Gemma erschien mitten im Projekt, und ich habe ernsthaft über einen Wechsel nachgedacht, mich aber entschieden, die bestehende Richtung abzuschließen. Die beiden Projekte dürften sehr gut zusammenpassen; der benötigte Code kann gern frei verwendet werden, oder man kann mich über LinkedIn am Ende der README kontaktieren.

  • Ich frage mich, warum der Unterschied zwischen 5–6 Token pro Sekunde auf einem 8GB M2 MacBook Air und 31–35 Token auf einem M5 MacBook Pro so groß ist. Ich glaube nicht, dass der Unterschied bei der SSD-Leistung so groß ist, hätte aber erwartet, dass bei diesem Ansatz die SSD der dominierende Flaschenhals ist

    • Die Leistungssteigerung der M5-SSD ist auch im Vergleich zur vorherigen Generation beträchtlich. Im Blackmagic Disk Speed Test erreichte das M5 MacBook Pro bis zu 6.323MB/s, das M4 MacBook Pro 2.031MB/s – also mehr als das Dreifache
      https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
    • Wahrscheinlich liegt es daran, dass der M5 mehr Arbeitsspeicher hat und das Betriebssystem den Großteil der Dateien bereits gecacht hat. Beim M2 ist der Speicherdruck höher, sodass Ergebnisse von SSD-Lesezugriffen weniger gecacht werden dürften
      Wenn inklusive Betriebssystem-Cache insgesamt nur 2GB genutzt werden können, könnte die Inferenzgeschwindigkeit noch niedriger ausfallen
    • Es hängt stark vom System-Cache und pread ab. Auch wenn der Prozess unter 2GB bleibt, kann der M5 Mac einen Teil cachen, und die Hardware selbst ist ebenfalls deutlich schneller
      Die Lesezeit pro Token lag beim M2 bei 83ms und beim M5 Pro bei 12ms; die Gesamtzeit betrug jeweils 163ms bzw. 30ms. Das ist das Ergebnis schnellerer Lesezugriffe und schnellerer GPU-Verarbeitung
    • Da die Generation älter ist, ist die SSD selbst im Vergleich zwischen Pro-Modellen deutlich langsamer, und innerhalb derselben Generation dürften SSD und Speicherbandbreite des Air niedriger sein als beim Pro
    • Das M5 MacBook Pro hat 24GB RAM, sodass es möglicherweise auch mehr Kontext im Speicher halten kann

  • Ich hoffe, dass Systeme mit 30–60GB Arbeitsspeicher und sehr schnellen SSDs künftig mit solchen Techniken auch extrem große Modelle ausführen können