Werkstattbericht · Lokale KI
NVIDIA-Format auf Apple-Hardware:
Wie mein 48-GB-Mac Qwen3.6-35B in 262k Kontext stemmt
Wie Open-Source-Backports die jüngsten Quantisierungs-Verfahren aus dem Datacenter auf Apple Silicon bringen — und was das messbar verändert.
Tokens Kontext auf einem 48-GB-Mac
Das ist die Spitze dessen, was Qwen3.6-35B technisch zulässt — bisher dachte ich, dafür braucht es ein Rechenzentrum.
Schneller als der bisherige Standard
Im direkten Vergleich gegen meine bisherige Konfiguration auf llama.cpp: gleicher Mac, gleiches Modell, gleiche Aufgaben, doppelte Geschwindigkeit.
Tests bei identischer Antwortqualität
Schneller heißt hier nicht "schlechter". In der Apples-to-Apples-Prüfung gegen die alte Konfiguration ist die Qualität dieselbe.
Der Ausgangspunkt
Lokale Sprachmodelle hatten eine Obergrenze — und sie ist gerade verschwunden
Seit Anfang 2026 betreibe ich einen Teil meiner KI-Arbeit lokal auf einem MacBook. Das hat zwei Gründe, die nichts mit Geld zu tun haben: Vertraulichkeit (Kunden-Code verlässt das Haus nicht) und Unabhängigkeit (keine Cloud-Quota, keine Token-Rechnung am Monatsende). Was lange dagegen sprach, war eine sehr nüchterne Obergrenze: Modelle in seriöser Größe — die wirklich gute Antworten geben — passten entweder nicht in den RAM, oder sie waren so langsam, dass der Arbeitsfluss bricht.
Im April habe ich für wulffit.de einen Benchmark veröffentlicht: gleicher Mac, gleiches Modell, einmal mit dem Standard-Werkzeug llama.cpp, einmal mit Apples eigenem Framework MLX. Das Ergebnis war ein bisschen unbefriedigend: kleiner Geschwindigkeitsvorteil für MLX, sonst kein Unterschied, der die Umstellung gerechtfertigt hätte. Beide Stacks taten dasselbe in ähnlicher Qualität.
Im Mai habe ich dann meinen Stack komplett ausgetauscht. Nicht weil mir langweilig war, sondern weil zwei Verfahren aus dem Datacenter-Umfeld plötzlich auf Apple Silicon ankamen: NVIDIAs neues 4-Bit-Format NVFP4 und ein Komprimierungs-Trick aus der Google-Forschung namens TurboQuant. Beides hatte ich vorher nur aus Papern und Datacenter-Blogs gekannt. Jetzt laufen sie auf meinem MacBook.
Dieser Bericht erklärt, was die zwei Verfahren wirklich tun, wie sie auf den Mac kommen, was sich messbar ändert — und wo die Erzählung „Mac jetzt so gut wie Datacenter" übertrieben wäre. Ich habe in den letzten drei Wochen den Stack produktiv gefahren und konkrete Zahlen mitgeschrieben.
Test-Setup
- Hardware: MacBook Pro M4 Pro, 48 GB Hauptspeicher
- Werkzeug: omlx, ein Open-Source-Server für lokale Modelle
- Modell: Qwen3.6-35B-A3B (chinesisch, Apache 2.0)
- Quantisierung: NVFP4 + TurboQuant
- Vergleich: llama.cpp Q5_K_M als bisheriger Standard
- Testzeitraum: Mai 2026, drei Wochen produktiv
Die zwei Datacenter-Verfahren
NVFP4 und TurboQuant — was die beiden tun, in einfachen Worten
Beide Verfahren lösen dasselbe Grundproblem: Sprachmodelle bestehen aus Milliarden von Zahlen, und jede dieser Zahlen muss irgendwo abgelegt und beim Rechnen bewegt werden. Wenn ein Modell in 4 statt 16 Bit pro Zahl gespeichert wird, braucht es ein Viertel des Platzes — und es lässt sich entsprechend schneller bewegen. Das ist Quantisierung. Die offene Frage ist immer: bricht die Qualität ein, wenn man so radikal komprimiert?
NVFP4 — von NVIDIA
Ein 4-Bit-Zahlenformat für die neuen Datacenter-Chips
NVIDIA hat NVFP4 für seine 2025 vorgestellten Blackwell-Beschleuniger entwickelt — die Generation, die zum Beispiel in der RTX-50er-Reihe und in den B200-Datacenter-Karten steckt. Das Format ist clever konstruiert: nicht jede Zahl wird einzeln komprimiert, sondern in Gruppen von sechzehn, jede Gruppe mit einer eigenen Skalierung. Das macht das Format genauer als bisherige 4-Bit-Verfahren — bei gleichem Speicherbedarf. NVIDIA hat das im Datacenter-Kontext eingeführt; dass es auch auf Apple Silicon ankommt, hat NVIDIA nicht geplant.
TurboQuant — von Google
Ein Komprimierungs-Verfahren für das laufende Gedächtnis
TurboQuant ist eine Forschungsarbeit aus Google (publiziert bei ICLR 2026, Autoren Zandieh, Daliri, Hadian und Mirrokni). Es komprimiert nicht das Modell selbst, sondern das laufende Gedächtnis, das beim Lesen eines langen Textes entsteht — den sogenannten KV-Cache. Bei langen Kontexten wächst dieser Zwischenspeicher schnell auf zweistellige Gigabyte-Beträge. Mit TurboQuant lässt sich derselbe Inhalt auf etwa ein Viertel komprimieren — bei messbar gleicher Qualität. Erst dadurch werden lange Kontexte auf Consumer-Hardware überhaupt machbar.
Was beide gemeinsam haben: Sie kommen aus dem Datacenter-Kontext. NVIDIA hat NVFP4 entwickelt, um teure GPU-Zeit besser auszunutzen. Google hat TurboQuant entwickelt, um sehr lange Kontexte in der Cloud bezahlbar zu machen. Keiner der beiden Anbieter hatte ein Mac-Notebook im Kopf — und doch profitiert das Mac-Notebook am Ende vielleicht am meisten davon. Weil dort der Speicher knapper ist.
Der Migrationsweg
Wie die zwei Verfahren auf Apple Silicon kommen
Apple hat ein eigenes Framework für maschinelles Lernen auf seinen Chips: MLX. Es ist die technische Grundlage, auf der die meisten lokalen Sprachmodelle auf dem Mac heute laufen. MLX ist Open Source, von Apple selbst gepflegt, und es entwickelt sich rasant. Vor ein paar Monaten wurde NVFP4 als unterstütztes Zahlenformat hinzugefügt — nicht von Apple, sondern von einem einzelnen Community-Entwickler, der den Pull-Request beigesteuert hat. Apple hat das integriert, ohne es als großes Feature anzukündigen. Die Datacenter-Erfindung kam still und leise auf den Mac.
TurboQuant hat einen ähnlich pragmatischen Weg genommen. Eine erste Umsetzung gab es als experimentellen Zweig eines anderen Werkzeugs (mlx-lm), wo ein Beitragender die Idee aus der Google-Forschung in MLX-Code übersetzt hat. Diese erste Fassung hatte einen Konstruktions-Fehler, der ihre praktische Nutzbarkeit eingeschränkt hat. Damit hätte die Geschichte enden können.
Sie endete nicht, weil omlx dazwischen kam — ein noch junges Open-Source-Werkzeug, das auf MLX aufsetzt und sich als Server-Layer für lokale Modelle versteht. omlx hat die fehlerhafte Implementierung aufgegriffen, den Konstruktions-Fehler behoben und beide Verfahren in einem benutzbaren Werkzeug zusammengeführt. Das macht es im Moment zur einfachsten Möglichkeit, NVFP4 und TurboQuant gemeinsam auf Apple Silicon zu nutzen.
Wer den Verlauf nachverfolgt, sieht ein wiederkehrendes Muster: Konzern macht das Format, Open-Source-Community baut es nach, ein kleines Werkzeug packt es benutzbar zusammen. Apple hatte am Ergebnis aktiven Anteil (das Framework selbst), aber die spannenden Schritte kamen aus der Community.
Eigene Messungen
Was sich auf meinem Mac messbar verändert hat
Vor der Umstellung hatte ich einen sauberen Vergleichsmaßstab: meine Benchmark-Suite aus dem April-Artikel, 27 Aufgaben aus verschiedenen Bereichen — Zusammenfassen, Logik, Code, deutscher Volltext. Drei Wochen nach der Umstellung habe ich die gleichen 27 Aufgaben erneut laufen lassen, einmal mit dem alten Werkzeug, einmal mit dem neuen. Gleiches Modell, gleicher Mac, gleiche Aufgaben — direkt nebeneinander.
Direktvergleich — alter vs. neuer Stack
| Messwert | llama.cpp (Standard) | omlx + NVFP4 + TurboQuant | Differenz |
|---|---|---|---|
| Decode-Geschwindigkeit | ~30–40 Tokens/Sekunde | ~70 Tokens/Sekunde | ≈ 2× schneller |
| Bestandene Tests | 23–24 von 27 | 23–24 von 27 | unverändert |
| Antwortqualität (Score) | 102–104 / 108 | 102–104 / 108 | unverändert |
| Maximaler Kontext | ~64.000 Tokens | ~262.000 Tokens | 4× mehr |
| Modell-Belegung im RAM | ~20 GB | ~19 GB | –5 % |
Die Zahlen sind nüchtern, aber sie verändern den Arbeitsablauf spürbar. Doppelte Geschwindigkeit bei gleicher Qualität ist die Sorte Verbesserung, die man auf dem Schreibtisch direkt merkt. Eine Anfrage, die vorher zwanzig Sekunden gedauert hat, dauert jetzt zehn. Bei mehreren Anfragen pro Stunde summiert sich das auf eine halbe Stunde gewonnene Arbeitszeit am Tag.
Die spannendere Zahl ist die letzte Zeile in der Tabelle: maximal 262.000 Tokens Kontext. Das sind ungefähr eine Million Wörter, die ich am Stück füttern kann — ein komplettes Buch, eine ganze Codebasis, die gesamte Dokumentation eines kleinen Projekts. Vorher war hier bei rund 64.000 Tokens Schluss, weil das laufende Gedächtnis nicht in den RAM passte. TurboQuant ist der Hebel, der die Obergrenze nach oben gezogen hat. Vier mal mehr Kontext auf derselben Hardware — durch ein Komprimierungs-Verfahren, das vor sechs Wochen noch in einem Paper stand.
Damit verschiebt sich, was lokal überhaupt machbar ist. Eine längere Recherche, in der ich dem Modell zwanzig Quellen mit jeweils mehreren tausend Wörtern zu lesen gebe, war auf meinem MacBook bisher unrealistisch. Jetzt ist es Alltag.
Wo die Erzählung übertrieben wäre
Fünf Einschränkungen, die in die Geschichte gehören
Damit das Bild ehrlich bleibt: hier sind die fünf Punkte, die mir wichtig sind. Wer den Stack einsetzt, sollte sie kennen.
Einschränkung
Mein Mac hat keine FP4-Tensor-Cores
NVIDIAs Format ist für eigene Chips gebaut. Auf meinem Mac wird es in Software nachgerechnet. Der Geschwindigkeitsvorteil entsteht aus weniger Speicher-Verkehr, nicht aus Hardware-Beschleunigung. „Mac so schnell wie Blackwell" wäre falsch.
Einschränkung
Das Format auf MLX ist nicht bitidentisch
Die MLX-Umsetzung von NVFP4 weicht in einem Detail von NVIDIAs Original ab (eine technische Differenz bei der Skalierung). Empirisch hat das in meinen Tests keinen Qualitätsverlust gezeigt — aber strikt bitidentisch ist es nicht.
Einschränkung
TurboQuant ist von Google, nicht NVIDIA
Die beiden Innovationen kommen aus unterschiedlichen Häusern. NVFP4 ist eine NVIDIA-Erfindung für Blackwell-Chips, TurboQuant stammt aus der Google-Forschung (ICLR 2026). Beide kommen aus dem Datacenter, beide landen jetzt auf Apple Silicon — über verschiedene Wege.
Einschränkung
In langen Werkzeug-Dialogen kann es kippen
Bei Multi-Turn-Programmier-Sessions mit kleinen Modellen (4 Milliarden aktive Parameter) habe ich nach vielen Iterationen Qualitätsverlust beobachtet. Für ernsthafte Programmier-Assistenten nutze ich das größere Qwen3.6-35B. Single-Shot-Anfragen und Lese-Aufgaben bleiben stabil.
Einschränkung
omlx ist noch nicht ausgereift
In den letzten Wochen kamen drei Notfall-Releases innerhalb von vier Tagen, die alle Speicher-Probleme adressiert haben. Eine Pinning-Falle habe ich selbst getroffen — ein Modell ließ sich nicht laden, obwohl genug RAM frei war. Für mehrtägige unbeaufsichtigte Workloads würde ich es noch nicht einsetzen.
Was die Erzählung NICHT behauptet: dass mein Mac jetzt einen Datacenter ersetzt. Eine NVIDIA-Karte rechnet das gleiche Format auf eigener Hardware ein Vielfaches schneller. Was sich verändert hat: die Obergrenze, an die ich auf meinem Notebook stoße, liegt deutlich höher als vorher. Modelle, die ich bisher nur in der Cloud hätte ernsthaft betreiben können, laufen jetzt lokal. Das ist ein Unterschied in der Größenordnung — nicht in der Beschaffenheit.
Wann lohnt es sich
Für wen die Umstellung Sinn ergibt — und für wen nicht
Die Umstellung kostet einen halben Vormittag Konfiguration. Wer das nicht erübrigen will oder kann, ist mit einer Klick-App wie LM Studio weiterhin gut bedient — die nutzt im Hintergrund dasselbe Framework, ohne die letzten Quantisierungs-Verfahren. Der Unterschied liegt nicht in „Apple Silicon ja oder nein", sondern in „wie nah am Stand der Forschung will ich sein".
Mein Eindruck nach drei Wochen produktivem Einsatz: für ernsthafte lokale Arbeit mit größeren Modellen ist das Setup die Mühe wert. Für gelegentliche Chat-Nutzung ist es überdimensioniert. Und für Kundenarbeit, in der ich heute Cloud-Modelle aus Vertraulichkeits-Gründen vermeiden würde, ist es die erste Konfiguration, die wirklich produktiv mithält.
Lohnt sich — lohnt sich nicht
JA, die Umstellung lohnt sich
- Mac mit mindestens 32 GB, idealerweise 48 GB oder mehr
- Lokale LLM-Nutzung als ernsthafter Teil der Arbeit
- Lange Dokumente, große Codebasen, mehrstufige Recherche
- Bereitschaft, einen Server-Prozess statt einer Klick-App zu betreiben
NEIN, Klick-App reicht
- Mac mit 16 GB — die spannenden Modelle passen nicht rein
- Gelegentliche Chat-Nutzung — eine Klick-App wie LM Studio reicht
- "Plug-and-Play ohne Anpassen" — etwas Konfiguration ist Pflicht
- Mehrtägige Produktiv-Workloads ohne Aufsicht — Reife-Stand abwarten
Fazit
Eine Obergrenze ist gefallen — leise, aus dem Datacenter heraus
Wenn ich versuche, die letzten Wochen in einem Satz zusammenzufassen: meine Obergrenze für lokale Sprachmodelle liegt seit Mai deutlich höher, und zwar weil zwei Datacenter-Innovationen — eine von NVIDIA, eine von Google — fast lautlos auf Apple Silicon angekommen sind. Apple hat das Framework gepflegt, aber die Umsetzung kam aus der Community. Ein Werkzeug, das die Stücke produktiv zusammenpackt, gibt es seit ein paar Wochen: omlx. Es ist noch jung, es bricht hier und da, aber es macht Dinge möglich, die ich vor sechs Wochen nicht für realistisch gehalten hätte.
Das interessanteste an dieser Geschichte ist nicht die Geschwindigkeit, sondern die Verschiebung dessen, was lokal überhaupt machbar ist. Vier mal mehr Kontext heißt: ich kann lokal eine Recherche fahren, für die ich vorher in die Cloud musste. Es heißt auch: für Kunden mit harten Vertraulichkeits-Anforderungen — Mittelständler mit eigenem Know-how, Kanzleien, kleine Engineering-Büros — gibt es eine reale Option, ohne Cloud zu arbeiten und trotzdem ernsthaft produktiv zu sein.
Ob omlx in einem halben Jahr noch das Werkzeug der Wahl ist, kann ich nicht versprechen. Die Open-Source-Szene um lokale Sprachmodelle bewegt sich schnell. Was ich versprechen kann: die Verfahren NVFP4 und TurboQuant werden bleiben. Sie sind in den letzten Wochen breit genug adoptiert worden, dass andere Werkzeuge nachziehen werden. omlx ist heute der bequemste Weg dorthin — nicht zwingend der einzige in Zukunft.
Es gibt Momente, in denen sich das lokale Setup auf einem Notebook anfühlt wie ein anderer Computer. Drei Wochen mit dem neuen Stack waren einer dieser Momente. Nicht weil etwas Spektakuläres passiert, sondern weil eine Obergrenze verschwindet, an die man sich gewöhnt hatte.
Quellen
Referenzen und weiterführende Links
Werkzeug und Framework
Lokale KI im eigenen Haus
Vertrauliche Daten und KI — geht beides?
Ich helfe mittelständischen Unternehmen, lokale KI-Stacks ohne Cloud-Bindung aufzubauen — von der Hardware-Wahl bis zum produktiven Betrieb.