Lokales Coding-Modell auf 24 GB Mac: Warum mein NVFP4-Setup leise gescheitert ist

TL;DR

Ich wollte das beste lokal lauffähige Coding-Modell für meinen MacBook M4 Pro mit 24 GB Unified Memory finden und produktiv betreiben. Recherchiert, gepullt, konfiguriert, gestartet -- und bei 0,1 Tokens pro Sekunde stehen geblieben. Das Modell lief laut Ollama auf der GPU, alles sah richtig aus, und trotzdem hat es nicht funktioniert. Dieser Artikel ist die ehrliche Aufarbeitung: was ich versucht habe, woran es lag, fünf Lektionen die ich mitnehme, und was du auf welcher Hardware stattdessen probieren solltest.

Warum ich das überhaupt gemacht habe

Die meisten meiner Coding-Sessions laufen mit Cloud-Modellen. Das funktioniert, ist schnell und robust. Aber es gibt drei Gründe, warum ich regelmäßig den Versuch starte, ein gutes Modell lokal zu bekommen:

• Datenhoheit. Manche Codebases will ich nicht in fremde Inferenz-Pipelines schicken, auch wenn die Anbieter Zero-Retention versprechen.
• Offline-Resilienz. Wenn ich am Flughafen sitze oder in einer Mansarde mit schlechtem Empfang, will ich weiterarbeiten können.
• Kontrolle und Lernen. Lokale Modelle zwingen einen, die Mechanik wirklich zu verstehen: Quantisierung, Kontextlängen, Backends, Speicherlayout. Wer das einmal sauber durchgespielt hat, trifft auch in der Cloud bessere Entscheidungen.

Im April 2026 sah die Lage für 24-GB-Macs auf den ersten Blick gut aus. Qwen veröffentlichte mit Qwen3.6-35B-A3B-Coding ein Modell, das in Coding-Benchmarks 73,4 % auf SWE-Bench Verified erreicht. Als Mixture-of-Experts mit nur 3 Milliarden aktiven Parametern pro Token verspricht es Performance auf Niveau dichter 24-Milliarden-Modelle, bei einer Größe von 22 GB im 4-Bit-Format. Das passt genau in meinen Speicher.

Außerdem brachte Ollama 0.21 das MLX-Backend, Apples nativen Beschleuniger für Apple Silicon. Theoretisch war damit das schnellste lokale Setup für meinen Mac greifbar.

Der Plan

Mehrere Quellen behaupteten, der Trick auf Maschinen unter 32 GB sei ein bestimmter Quantisierungs-Tag: nvfp4. NVFP4 ist ein 4-Bit-Format aus dem Nvidia-Umfeld, das MLX nativ unterstützt. Ollama 0.19+ aktiviert das MLX-Backend automatisch erst ab 32 GB Speicher; mit dem expliziten NVFP4-Tag könne man es laut den Quellen aber auch auf 24 GB triggern.

Mein Plan war einfach:

1. Modell qwen3.6:35b-a3b-coding-nvfp4 per Ollama pullen
2. Custom-Modelfile mit reduziertem Kontext (8K) und den offiziellen Qwen-Sampling-Parametern bauen
3. KV-Cache auf q8_0 quantisieren und Flash-Attention aktivieren
4. Smoke-Test fahren, Tokens pro Sekunde messen
5. Ins agentische Coding-Setup integrieren

Klingt nach 30 Minuten Arbeit. War es nicht.

Was tatsächlich passiert ist

Wand 1: Die unsichtbare Speicher-Decke

Erster Smoke-Test, sofortiger Fehler:

Error: 500 Internal Server Error: model requires 20.4 GiB
but only 17.3 GiB are available (after 512.0 MiB overhead).

Mein erster Reflex: zu wenig RAM frei, andere Apps killen. Codex.app, Chrome-Helper, Notion-Frameworks. Bald hatte ich 16 GB free. Trotzdem dieselbe Fehlermeldung mit derselben Zahl: 17,3 GiB verfügbar.

Was ich erst nach drei Web-Suchen verstanden habe: Das war nicht der freie RAM, sondern das macOS-interne GPU-Wired-Limit. Apple reserviert standardmäßig nur etwa 75 % des Unified Memory für die GPU, hier also rund 18 GB. Der Wert hängt am Kernel-Parameter iogpu.wired_limit_mb. Bei 24 GB Mac mit Default 0 bedeutet das eine harte 18-GB-Decke für GPU-zugewiesene Modelle, völlig unabhängig vom tatsächlichen freien Speicher.

Lösung: sudo sysctl iogpu.wired_limit_mb=21504. Ich habe den Wert auf 21 GB gehoben, was als aggressiv gilt aber bei aufgeräumtem System noch sicher ist. Über 22 GB wird es kritisch und kann das System einfrieren.

Wand 2: Der Bug, den ich nicht kannte

Sysctl gesetzt, verifiziert, Modell neu gestartet -- und Ollama meldet immer noch dieselben 17,3 GiB. Stellt sich heraus: Ollama liest die Kernel-Reserve nur beim Daemon-Start, nicht bei jeder Inferenz. Bekannter offener Bug seit 2024, Issue #1826. Lösung: kompletter Cold-Start des Ollama-Daemons.

Der Moment der Hoffnung

Cold-Start, neuer Versuch. Diesmal lädt das Modell sauber. ollama ps zeigt:

• Modell auf GPU: 100 %
• Memory wired: 21 GB (genau im Cap)
• Runner-Argument: --mlx-engine

Das hieß: Apple Silicon-Beschleunigung war aktiv. Der NVFP4-Tag hatte tatsächlich den MLX-Pfad in Ollama getriggert, obwohl meine Maschine unter der 32-GB-Auto-Schwelle liegt. Ich habe kurz innerlich gejubelt. Das war exakt das Setup, das die Recherche versprochen hatte.

Wand 3: Stille

API-Call abgesetzt. Curl wartet. 30 Sekunden. 60 Sekunden. 90 Sekunden Timeout. Null Bytes Antwort.

Health-Check auf /api/version antwortet sofort. Der Daemon lebt. Aber Generation passiert nicht. Activity Monitor zeigt 100 % GPU-Last, also rechnet das Modell. Nur eben extrem langsam.

Im Server-Log fand sich schließlich die echte Zahl: Prefill mit etwa 0,1 Tokens pro Sekunde. Auf einer M-Series-GPU mit MLX wären 100 bis 200 Tokens pro Sekunde normal. Das war ein Faktor von rund 1.000 zu langsam.

Ich habe es noch zwei Mal probiert mit unterschiedlichen Kontextlängen und Sampling-Parametern. Gleiches Ergebnis. Das Setup hat technisch korrekt geladen, aber die Berechnung selbst ist offenbar in eine Software-Emulation der NVFP4-Kernel gefallen. Apples produktive MLX-Beschleunigung für NVFP4 scheint die Neural Accelerators der M5-Generation zu brauchen, die mein M4 Pro nicht hat.

Diagnose, ehrlich

Das ist eine begründete Hypothese, kein bewiesener Fakt:

• Die Recherche-Quellen behaupteten "NVFP4 läuft auf jeder Hardware mit Kerneln". Formal stimmt das. Praktisch heißt "läuft" nur "Korrektheit", nicht "performant".
• Apples eigene Veröffentlichungen referenzieren explizit die M5 Neural Accelerators für die 4-fach schnellere Prefill-Beschleunigung. Das war das verlässliche Signal, das ich überlesen habe.
• Memory war OK (Peak 19,67 GiB unter dem 21-GB-Cap), GPU-Routing war OK, der Runner lief mit dem richtigen Backend. Der Engpass lag nicht im Setup, sondern in der Hardware-Annahme.

Ausgeschlossen sind hingegen: Memory-Druck, CPU-Fallback, defektes Modell, KV-Cache-Druck oder ein generelles Ollama-Problem. Alle vier wären im Server-Log oder am Aktivitätsmonitor sichtbar gewesen.

Was ich daraus mitnehme

Fünf Lektionen, die ich für übertragbar halte.

1. Ein Quantisierungs-Tag ist kein universeller Beschleuniger

NVFP4 ist auf Hardware ohne Neural Accelerators effektiv ein Anti-Pattern: das Backend wird aktiviert, aber die Kernel emulieren in Software. Die 32-GB-Auto-Aktivierungs-Schwelle in Ollama hat einen Hardware-Grund, nicht nur einen Speicher-Grund. Wer unter dieser Schwelle einen "Trick" findet, sollte misstrauisch werden statt euphorisch.

2. Tech-Blogs überverkaufen Hardware-Portabilität routinemäßig

"Läuft auf jeder Hardware" bedeutet in Tech-Blogs fast immer "ist syntaktisch unterstützt", selten "ist performant". Wenn der Original-Hersteller eine Hardware-Generation als Voraussetzung nennt, ist das das verlässlichere Signal. In meinem Fall hat Apples eigene Veröffentlichung zu MLX und M5 explizit die Neural Accelerators als Quelle der Beschleunigung markiert. Drei Tech-Blogs, die das Gegenteil suggerierten, haben mich zwei Stunden gekostet.

3. "100 % GPU" in ollama ps ist kein Performance-Beweis

Die Spalte zeigt nur, dass das Modell auf der GPU geladen ist. Sie sagt nichts über die Effizienz der Berechnung. Echte Tokens pro Sekunde stehen nur im Server-Log oder in den API-Response-Metriken. Wer nur den Status-Befehl liest, kann ein totes Setup für ein gesundes halten. Ich nehme das jetzt fix in meinen Diagnose-Workflow auf: erst Status, dann immer Server-Log auf die echten Prefill- und Decode-Raten prüfen.

4. Die Speicher-Decke und die Performance sind getrennte Probleme

iogpu.wired_limit_mb löst die Frage "passt das Modell in den Speicher". Es löst nicht die Frage "wie schnell rechnet das Modell". Beide werden in Tutorials oft im selben Atemzug behandelt, sind aber orthogonal. Eine saubere Diagnose-Reihenfolge: erst Loading, dann Backend, dann Prefill-Geschwindigkeit, dann Decode-Geschwindigkeit. Vier separate Fragen, vier separate Beweise.

5. Quantisierung und Hardware-Beschleunigung sind zwei Achsen

Eine Quantisierung wie NVFP4, Q4_K_M oder MXFP8 löst Speicherprobleme. Eine Hardware-Beschleunigung wie MLX-Kernel, CUDA oder Metal löst Geschwindigkeitsprobleme. Dass beide existieren und zusammenpassen heißt nicht, dass die Kombination produktiv läuft. Sie braucht passende Kernel-Implementierungen für die spezifische Hardware-Generation. Diese Trennung war mir intellektuell klar, aber im konkreten Fall habe ich sie übersehen.

Was du stattdessen probieren solltest

Generelle Empfehlungen nach Hardware-Klasse, basierend auf der April-2026-Lage und dem, was zu funktionieren scheint. Keine Versprechen, nur die belastbarsten Pfade aus meiner Recherche.

16 bis 24 GB Mac, agentisches Coding gewünscht

Devstral 2 24B als dichtes Modell mit 14 GB im 4-Bit-Format ist der robuste Daily-Driver. Speziell auf Tool-Calling und agentische Workflows getunt, kein NVFP4-Trick nötig, läuft über den klassischen llama.cpp-Pfad in Ollama. Erwartete Performance auf einem M4 Pro: rund 25 bis 35 Tokens pro Sekunde.

Alternativ Qwen3 14B als dichtes Modell mit etwa 9 GB. Viel Headroom für Kontext, sehr schnell, schwächer in reinen Coding-Benchmarks aber für viele Aufgaben absolut ausreichend.

24 GB Mac, größeres Modell gewünscht

Qwen3.6-35B-A3B im klassischen Q4_K_M-Format (kein NVFP4) über den llama.cpp-Pfad in Ollama. Lädt 22 GB, läuft ohne MLX-Tricks, dafür stabil. Erwartete Performance: rund 25 bis 35 Tokens pro Sekunde. Das ist langsamer als ein hypothetisch funktionierendes MLX-Setup, aber es funktioniert tatsächlich.

Wichtig auch hier: KV-Cache auf q8_0 setzen, Kontext auf 8K bis 16K beschränken, Flash-Attention aktivieren. Sonst kippt das Setup beim ersten längeren Tool-Calling-Lauf in den Swap.

32 GB+ Mac, egal welche M-Generation

Hier wird die NVFP4-Schiene tatsächlich tragfähig. Ollama aktiviert MLX automatisch ab 32 GB, der explizite Tag-Trick ist nicht mehr nötig. Qwen3.6-35B-A3B-Coding-NVFP4 läuft hier so wie es in den Blog-Quellen beschrieben war. Außerdem: LM Studio mit MLX-DWQ-Quantisierungen ist eine separate Toolchain mit aktuell reiferer MLX-Implementierung als Ollama. Wer maximale Qualität bei 4-Bit will, schaut sich das an.

M5-Generation, jede Speicher-Stufe

Mit den Neural Accelerators der M5-GPUs wird NVFP4 nach allem was Apple und die ersten Benchmarks sagen erstmals "der richtige" Pick. Real gemessene Speedups gehen in Richtung 4-fache Prefill-Beschleunigung. Wer auf neuer Hardware sitzt, kann den Pfad nehmen den ich nicht nehmen konnte.

Was ich nicht abdecke

Ich lasse hier bewusst Vergleiche zu meinem persönlichen Upgrade-Plan außen vor. Wer eine Kaufentscheidung trifft, sollte sie auf konkreten Benchmarks aus aktuellen Quellen basieren, nicht auf einem Erfahrungsbericht über ein gescheitertes Setup. Die Modell- und Backend-Lage 2026 verschiebt sich monatlich. Die Halbwertszeit dominanter Modelle liegt aktuell bei rund drei Monaten.

Sauberes Zurücksetzen

Falls du dem Recipe gefolgt bist und auch in die Wand gelaufen bist, drei Schritte zum Aufräumen:

ollama rm qwen36-coder-24gb
ollama rm qwen3.6:35b-a3b-coding-nvfp4
sudo sysctl iogpu.wired_limit_mb=0

Der letzte Befehl setzt die Speicher-Decke auf den macOS-Default zurück. Das aggressive Cap kostet sonst System-Headroom und kann unter Druck zu Stockern führen.

Was bleibt

Zwei Stunden in einer Sackgasse, ein leerer Modell-Cache und eine ehrlich dokumentierte Hypothese. Das ist kein verlorener Abend. Die Diagnose-Reihenfolge, die fünf Lektionen und die Hardware-Empfehlungen werden mir in den nächsten Local-LLM-Versuchen Stunden sparen. Mehr noch: ich werde Recherche-Quellen jetzt anders lesen. Wenn ein Tech-Blog einen Trick verspricht, der die offiziellen Hardware-Voraussetzungen umgeht, ist das ein Warnsignal, nicht ein Geheimtipp.

Wer denselben Pfad probiert hat oder andere Erfahrungen gemacht hat: schreib mir. Local-LLM ist ein Feld, das nur kollektiv vorankommt -- jeder hat ein anderes Stück der Hardware-Realität auf dem Tisch.