Lokale LLMs auf dem Mac: MLX statt der Standard-Engine llama.cpp
Wann Apples MLX auf Apple Silicon schneller ist als llama.cpp – mit Benchmark-Spannen nach Modellgröße, drei Wegen zum Umstieg und den Fallstricken, die Sie vermeiden sollten.
Wenn Sie Ollama auf einem Mac installiert, ein Modell geladen und daraus geschlossen haben, dass Sie jetzt KI lokal betreiben – stimmt. Wahrscheinlich tun Sie es aber auf der falschen Engine und verschenken irgendwo zwischen 15 % und dem Dreifachen der Geschwindigkeit Ihres Rechners, ohne es je zu bemerken.
Der Standardweg
Fast alle gehen denselben Weg. Ollama installieren, ollama run llama3.2 ausführen (oder welches Modell gerade angesagt ist), den Tokens beim Durchlaufen zusehen und annehmen, dass das auf einem Mac das Maximum ist.
Lange Zeit war das eine faire Annahme. Unter der Haube ist Ollama ein Wrapper um llama.cpp, eine Inferenz-Engine in C/C++, die praktisch überall läuft: unter Windows, Linux, auf Intel-Macs, sogar auf einem Raspberry Pi. Das ist hervorragende Ingenieursarbeit. Sie wurde nur nicht darauf ausgelegt, wie Apple Silicon funktioniert.
Apple hat seit Ende 2023 ein eigenes Machine-Learning-Framework, MLX, und es ist um das herum gebaut, was die Chips der M-Serie auszeichnet: Unified Memory. CPU, GPU und Neural Engine greifen alle auf einen gemeinsamen Speicherpool zu. Das Metal-Backend von llama.cpp muss das umschiffen. MLX wurde vom ersten Tag an genau dafür geschrieben. Der Abstand zwischen „läuft auf Apple Silicon“ und „gemacht für Apple Silicon“ ist größer, als die meisten vermutet hätten.
Als Ollama selbst zustimmte
MLX ließ sich leicht als Enthusiastenprojekt abtun, über das man in Foren zu lokalen LLMs sprach. Das änderte sich im März 2026, als Ollama eine optionale MLX-Backend-Option für Apple Silicon auslieferte. Damit räumte das beliebteste Tool für lokale LLMs faktisch ein, dass seine Standard-Engine auf der Hardware, die die meisten seiner Mac-Nutzer besitzen, nicht die schnellste Wahl ist. Grund genug, sich echte Zahlen anzusehen, statt jemandem einfach zu glauben.
Was der Umstieg bringt
Der Abstand schwankt stark je nach Modellgröße, Architektur und genauem Chip, aber unabhängige Tests zeigen in dieselbe Richtung:
- Mittelgroße Mixture-of-Experts-Modelle, etwa der Klasse Qwen3-Coder-30B, auf einem Mac mini mit M4 Pro: rund 130 Tokens pro Sekunde mit MLX gegenüber 43 über das llama.cpp-Backend von Ollama. Das ist das Dreifache, weit jenseits jeder Messungenauigkeit.
- Dichte Modelle unter etwa 14B Parametern: MLX ist 20 bis 87 % schneller als der Metal-Pfad von llama.cpp.
- Ab etwa 27B Parametern: Der Unterschied schrumpft und verschwindet größtenteils. In dieser Größe begrenzt die Speicherbandbreite, nicht die Rechenleistung, sodass die RAM-Geschwindigkeit mehr zählt als die Engine.
- Die Zeit bis zum ersten Token, die lästige Pause vor dem Streaming, verbessert sich mit MLX ebenfalls – besonders auf Chips der M5-Generation mit dedizierten Neural Accelerators.
Die faire Zusammenfassung lautet also nicht, dass MLX immer gewinnt. Es gewinnt deutlich bei den Modellgrößen, die die meisten Leute tatsächlich lokal betreiben, und der Vorsprung schwindet, je riesiger die Modelle werden.
Drei Wege, es auszuprobieren
In Ollama bleiben und das Backend wechseln
Ab Ollama 0.19 können Sie das MLX-Backend aktivieren, ohne Ihr bisheriges Setup zu verlassen. Das ist der geringste Aufwand und erlaubt einen Vergleich auf Ihrer eigenen Hardware, bevor Sie sich festlegen.
Nativ mit mlx-lm
Installieren Sie das Paket und generieren Sie direkt auf der Kommandozeile:
pip install mlx-lm
python -m mlx_lm.generate --model mlx-community/Qwen3.5-35B-A3B-MLX-4bit --prompt "your prompt here"
Modelle der Organisation mlx-community auf Hugging Face sind dafür bereits vorquantisiert. Das ist der Weg zur maximalen Geschwindigkeit, sofern es Sie nicht stört, etwas näher am Terminal zu leben.
LM Studio nutzen
Wenn Python für Sie nicht infrage kommt: LM Studio unterstützt MLX-Modelle inzwischen per Ein-Klick-Schalter im Modellbrowser. Das ist der einfachste Einstieg, wenn Ihnen mlx-lm nach zu viel Einrichtung klingt.
Fallstricke beim Umstieg
- Es ist kein simpler Modelltausch. MLX braucht eigene quantisierte Versionen der Modelle (die
mlx-community-Repos), nicht die GGUF-Dateien, mit denen Sie Ollama gefüttert haben. Zeigen Sie mlx-lm auf eine GGUF-Datei, schlägt es einfach fehl. - RAM-Reserven zählen weiterhin. Unified Memory ist effizient, aber auf einem Rechner, der schon am Limit läuft – etwa einem Mac der M-Serie mit 16 GB –, müssen Sie die Quantisierungsstufe sorgfältig wählen. Bei weniger als 32 GB Unified Memory ist 4 Bit meist der beste Kompromiss.
- Ein 70B-Modell bringt keinen Gewinn. Das passt zur Angleichung oberhalb von etwa 27B: Wenn Sie das größte Modell laden, das Ihr Mac technisch fassen kann, bleibt die Bandbreitengrenze gleich, egal welche Engine es ausführt.
- Behalten Sie Ollama. Für schnelle Einzeltests, Tool-Calling-Workflows und Vision-Modelle sind sein Ökosystem und seine Bibliothek weiterhin bequemer. Sinnvoll ist, es bei allem Performance-Kritischen nicht mehr standardmäßig zu nutzen – nicht, es zu deinstallieren.
Für wen es sich lohnt
- Intel-Macs: lassen Sie es. MLX braucht Apple Silicon ab M1, also bleiben Sie bei llama.cpp und Ollama.
- Basis-M1 oder -M2 mit 8 bis 16 GB RAM: Rechnen Sie mit einer echten, aber kleineren Verbesserung. Die Gewinne wachsen mit der Zahl der GPU-Kerne und der Speicherbandbreite, ein Basis-M1 fühlt sich also nicht wie ein M4 Max an.
- Pro-, Max- und Ultra-Chips mit Modellen von etwa 3B bis 20B: Hier zahlt sich der Umstieg am deutlichsten und sofort aus.
- Alle, die MoE-Modelle ab 30B betreiben: die Kategorie mit dem größten Gewinn in den obigen Benchmarks.
- Alle oberhalb von etwa 27B dichten Parametern: Wechseln Sie wegen der kleinen Verbesserung bei der Zeit bis zum ersten Token, aber erwarten Sie nicht die Schlagzeilenwerte.
Die Engine passend zum Chip wählen
Nichts davon macht MLX in irgendeinem abstrakten Sinn besser. Es geht darum, ein Werkzeug auf der Hardware einzusetzen, für die es entwickelt wurde. llama.cpp ist brillante, portable Software, und genau diese Portabilität ist der Grund, warum sie sich nicht so eng auf eine Chipfamilie abstimmen lässt wie ein Framework des Unternehmens, das den Chip baut.
Wenn Sie lokale Modelle auf dem Mac ernst nehmen – wegen Datenschutz, Kosten oder Kontrolle –, ist die Engine unter Ihrem Prompt genauso wichtig wie das gewählte Modell. Viele verbringen Stunden mit der Wahl des Modells und fragen nie, was es eigentlich ausführt. Prüfen Sie Ihre, denn womöglich liegt dort mehr Leistung brach, als Sie denken.