Vom Mac Apple das Maximum herausholen Silicon

#Ein LLM auf Apple Silicon optimieren: die vier Stellschrauben

Um das Maximum aus einem Mac mit Apple Silicon herauszuholen, sind vier Stellschrauben entscheidend, in dieser Reihenfolge: die Speichergrenze, die macOS der GPU setzt, die Größe und Quantisierung des Modells, der KV-Cache und Flash Attention für lange Kontexte sowie die Wahl der Engine (Ollama, llama.cpp, MLX oder LM Studio). Ausgangspunkt ist eine Tatsache: CPU und GPU teilen sich den vereinheitlichten Speicher, sodass der gesamte RAM als VRAM dient. macOS begrenzt jedoch den Anteil, den die GPU fest im Speicher reservieren kann. Wird diese Grenze angehoben, lassen sich größere Modelle nutzen; die anderen Stellschrauben verhindern, dass der Speicher voll wird oder die Generierung langsamer läuft. Keine davon macht den Rechner schneller, als es seine Speicherbandbreite erlaubt.

Unified Memory

CPU und GPU lesen dieselben Daten, ohne sie zu kopieren. MLX fasst es so zusammen: Die Arrays liegen in einem gemeinsamen Speicher. Ein Mac mit 64 GB kann daher ein Modell laden, das auf keine Consumer-Grafikkarte mit 24 oder 32 GB passt.

Effizienz

Ein Mac verbraucht deutlich weniger Energie als ein PC mit einer High-End-Grafikkarte, deren Leistungsaufnahme bei NVIDIAs RTX 5090 über 500 W liegt: Bei leichter Nutzung bleibt der Mac leise und sparsam.

Ökosystem

Das llama.cpp-Repository beschreibt Apple Silicon als eine Plattform mit erstklassiger Unterstützung, optimiert durch ARM NEON, Accelerate und Metal. Ollama, LM Studio und MLX nutzen ebenfalls Metal.

Grenzen

Kein CUDA, daher laufen Bibliotheken, die es voraussetzen, nicht; die Bandbreite eines Macs (bis zu 546 GB/s bei einem M4 Max) bleibt unter der einer High-End-Grafikkarte; Fine-Tuning ist möglich, aber langsamer.

#VRAM eines Macs: das GPU-Speicherlimit und iogpu.wired_limit_mb

Auf einem Mac gibt es keinen separaten VRAM: Der „VRAM“ ist ein Teil des vereinheitlichten Speichers, den macOS für die GPU als nicht auslagerbaren Speicher reservieren lässt. Dieser Anteil ist kleiner als der gesamte RAM. Die öffentlichen Quellen sind sich über den standardmäßigen Anteil nicht einig; je nach Fall liegt er zwischen zwei Dritteln und drei Vierteln. Gehen Sie nicht von einem bestimmten Anteil aus, sondern lesen Sie ihn auf Ihrem Rechner aus. MLX stellt den vom System festgelegten Wert über device_info() im Feld max_recommended_working_set_size bereit, und laut MLX-Dokumentation lässt sich diese Systemgrenze mit sudo sysctl iogpu.wired_limit_mb gefolgt von der Größe in Megabyte erhöhen.

Das Repository mlx-lm nennt folgende Vorsichtsregel: Der Wert muss größer als die Modellgröße in Megabyte sein, aber unter der Speicherkapazität des Rechners bleiben. Apple dokumentiert diese Einstellung nicht als Parameter für gewöhnliche Nutzer: Behandeln Sie sie als riskante Systemänderung.

Die Formel ist einfach: Wert in MB = gewünschte Speichergröße in GB × 1.024. Die Reserve ist eine Vorsichtsmaßnahme dieses Leitfadens, keine Angabe von Apple: Sie hängt von den Anwendungen ab, die Sie geöffnet lassen. Wenn der Rechner langsamer wird, auf den Datenträger schreibt oder instabil wird, reduzieren Sie den Wert.

Um die von macOS tatsächlich angesetzte Grenze auszulesen, genügt eine Zeile Python, sofern das Paket mlx installiert ist. Die Ausgabe enthält das Feld max_recommended_working_set_size, angegeben in Bytes: Teilen Sie den Wert durch 1.073.741.824, um Gigabytes zu erhalten. Vergleichen Sie diese Zahl mit der Größe Ihres Modells, bevor Sie irgendeine Einstellung ändern: Wenn das Modell bereits unter diese Grenze passt, bringt eine Erhöhung nichts.

python3 -c "import mlx.core as mx; print(mx.device_info())"

1. 01
   Den aktuellen Wert auslesen

   Im Terminal zeigt der Befehl sysctl iogpu.wired_limit_mb den Wert an. Eine Null bedeutet in der Regel, dass macOS seine standardmäßige Obergrenze anwendet.
2. 02
   Den neuen Wert berechnen

   Addieren Sie die Größe des Modells und seines KV-Caches, planen Sie zusätzlichen Spielraum ein und lassen Sie dem System anschließend eine Reserve von mindestens 5 GB. Rechnen Sie den Wert in Megabyte um.
3. 03
   Einstellung anwenden

   Führen Sie sudo sysctl iogpu.wired_limit_mb mit dem gewünschten Wert aus. Laut den veröffentlichten Anleitungen wird die Einstellung ohne Neustart wirksam.
4. 04
   Prüfen

   Starten Sie das Modell erneut: Die Protokolle von Ollama oder llama.cpp zeigen den empfohlenen Arbeitsspeicher an; lesen Sie bei MLX device_info() erneut aus. Überwachen Sie den Speicherdruck in der Aktivitätsanzeige.
5. 05
   Die Änderung rückgängig machen

   Setzen Sie den Wert wieder auf 0, um dem System wieder die Kontrolle zu überlassen, oder starten Sie neu: Die Einstellung bleibt bei einem Neustart nicht unbedingt erhalten; überprüfen Sie sie mit sysctl.

# Lire la valeur actuelle (0 = plafond par défaut du système)
sysctl iogpu.wired_limit_mb

# Exemple : 24 Go au GPU sur un Mac de 32 Go (24 x 1024)
sudo sysctl iogpu.wired_limit_mb=24576

# Retour au comportement par défaut
sudo sysctl iogpu.wired_limit_mb=0

#Welche Modelle eignen sich je nach Arbeitsspeicher des Macs?

Der Speicherbedarf der Modellgewichte in Q4 folgt den Richtwerten dieser Website: 3B etwa 2 GB, 7–8B etwa 5 GB, 14B etwa 9 GB, 32B etwa 19 bis 20 GB und 70B etwa 40 GB. Dazu kommen der KV-Cache und eine Speicherreserve für das System. Die Tabelle setzt diese Richtwerte zur Speicherkapazität des Macs in Beziehung, vor und nach der Anhebung des GPU-Speicherlimits.

Die maximale Geschwindigkeit lässt sich anhand der Bandbreite des Chips berechnen: Bandbreite geteilt durch die Größe der Modellgewichte in Gigabyte. Die Bandbreite ist im Datenblatt jedes Geräts angegeben: siehe die Leitfäden zu MacBook Air, MacBook Pro, Mac mini und Mac Studio, die jeweils die Werte für den betreffenden Chip enthalten.

Konkretes Beispiel: Auf einem Mac mit 32 GB belegt ein Modell mit 32 Milliarden Parametern in Q4 etwa 19 bis 20 GB. Mit einem Kontext von 8.000 Token und einem KV-Cache in f16 müssen Sie einige zusätzliche Gigabyte einplanen, also insgesamt etwa 23 bis 24 GB. Wenn die standardmäßige GPU-Speichergrenze niedriger liegt, wird ein Teil des Modells auf die CPU ausgelagert und die Geschwindigkeit fällt ab: Eine Erhöhung der Grenze auf 24 oder 26 GB behebt das Problem, sofern dem System genügend Speicherreserve bleibt. Wenn die Speicherbelastung in den roten Bereich steigt, wählen Sie stattdessen ein Modell mit 24 Milliarden Parametern.

#Quantisierung: Warum Q4 auf dem Mac weiterhin eine gute Standardeinstellung ist

Auf einem Mac wird die Generierung durch die Speicherbandbreite begrenzt: Ein kleineres Modell lässt sich schneller auslesen. Q4_K_M bleibt daher die Standardwahl mit dem besten Verhältnis zwischen Größe, Geschwindigkeit und Qualität. Q5_K_M und Q6_K kosten einige Prozent Geschwindigkeit für einen bescheidenen Qualitätsgewinn; Q8_0 verdoppelt die Größe gegenüber Q4 fast und halbiert damit ungefähr die maximal mögliche Geschwindigkeit. Die 4-Bit-Formate von MLX erfüllen im MLX-Ökosystem dieselbe Rolle. Der Leitfaden zur Quantisierung erläutert diesen Kompromiss im Detail, ohne dass die Zahlen hier wiederholt werden müssen.

#Metal und Flash-Attention

Die gängigen Engines nutzen die GPU des Macs über Metal, ohne dass Einstellungen nötig sind. Bei Ollama zeigt der Befehl ollama ps an, ob das Modell auf der GPU geladen ist. Flash Attention reduziert den Speicherbedarf langer Kontexte: Ollama aktiviert diese Funktion automatisch, wenn Engine und Hardware sie unterstützen, und die Variable OLLAMA_FLASH_ATTENTION=1 erzwingt ihre Aktivierung. In llama.cpp akzeptiert die Option -fa die Werte on, off oder auto, wobei auto der Standardwert ist; die Option -ngl legt die Anzahl der auf der GPU platzierten Schichten fest.

# Ollama : forcer l'attention flash
export OLLAMA_FLASH_ATTENTION=1
ollama serve

# llama.cpp : toutes les couches sur le GPU, attention flash active
llama-server -m modele.gguf -ngl all -fa on -c 16384

#KV-Cache: der Speicheranteil, den man vergisst

Der KV-Cache speichert für jedes Token des Kontexts Vektoren jeder Schicht. Seine Größe ergibt sich aus dem Produkt aus 2, der Anzahl der Schichten, der Anzahl der KV-Köpfe, deren Dimension, der Kontextlänge und den Bytes pro Wert. Rein arithmetisches Beispiel mit einer typischen Architektur mit 32 Schichten, 8 KV-Köpfen mit einer Dimension von 128 und einem Kontext von 32 000 Tokens in f16: 2 × 32 × 8 × 128 × 32 000 × 2 Bytes, also etwa 4,2 GB zusätzlich zu den Gewichten. In q8_0 schrumpft dieser Cache auf ungefähr die Hälfte, in q4_0 auf ungefähr ein Viertel, mit einem leichten Präzisionsverlust.

Ollama quantisiert den Cache über die Variable OLLAMA_KV_CACHE_TYPE (standardmäßig f16); llama.cpp nutzt dafür die Option -ctk für die Schlüssel und -ctv für die Werte. Auf einem Mac mit 32 GB, der der GPU 24 GB zuweist, machen einige beim Cache eingesparte Gigabyte den Unterschied zwischen einem Kontext, der nicht in den Speicher passt, und einem Kontext mit komfortabler Speicherreserve. Ollama wählt auch den Standardkontext anhand des Speichers: 4.000 Tokens bei weniger als 24 GiB.

# Ollama
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve

# llama.cpp
llama-server -m modele.gguf -ngl all -fa on -ctk q8_0 -ctv q8_0 -c 32768

#Ollama, LM Studio, llama.cpp oder MLX

Das Repository mlx-lm stellt das Paket als Werkzeug zur Textgenerierung und zum Fine-Tuning von Modellen auf Apple Silicon vor, mit Unterstützung für quantisierte Modelle. Für den Geschwindigkeitsvergleich zwischen MLX und llama.cpp ist der entsprechende Leitfaden die Referenz; diese Seite beschränkt sich auf die gemeinsamen Einstellungen.

#Akku und Stromsparmodus

Auf einem MacBook beansprucht eine kontinuierliche Generierung die GPU dauerhaft: Die Akkulaufzeit fällt deutlich kürzer aus als die von Apple für das Surfen im Web angegebene Laufzeit. Diese Seite nennt mangels einer Quelle keine genaue Dauer; sie hängt vom Modell und der Auslastung ab. Der Stromsparmodus von macOS reduziert die Leistung: Verwenden Sie ihn auf Reisen, wenn die Akkulaufzeit wichtiger ist als die Geschwindigkeit, und schließen Sie das Gerät für jede längere Sitzung ans Stromnetz an.

• MLX gegenüber llama.cpp: Vergleich der Geschwindigkeiten
• MacBook Pro M4 Pro und Max
• Mac Studio: bis zu 512 GB
• llama.cpp mit Metal kompilieren
• KV-Cache quantisieren
• VRAM-Rechner der Website

• Quelle: mlx-lm-Repository (Limit für Wired Memory)
• Quelle: MLX-Dokumentation, set_wired_limit
• Quelle: Ollama-FAQ, Flash Attention und KV-Cache
• Quelle: llama.cpp-Repository

#Häufig gestellte Fragen