Lokale LLM-Inferenz auf einem Cloud Mac mini: Speicherplanung und Quantisierung

Letzte Woche fragte mich ein Leser, der mit On-Device-KI experimentiert: Er wolle Llama 3 8B und ein 13B-Codemodell laufen lassen, sein Laptop-Speicher reiche nicht, ein Mac Studio zu kaufen sei ihm aber zu riskiert, weil er die Kapazität vielleicht gar nicht ausnutzt – ob man das nicht erst mal in der Cloud im passenden Format testen könne. Das ist tatsächlich ein ziemlich typisches Szenario – dieser Artikel geht deshalb Schritt für Schritt durch, wie man auf einem Cloud Mac mini lokale LLM-Inferenz betreibt: Speicherplanung, Umgebungsaufbau und Auswahl der Quantisierung.

Warum die Unified-Memory-Bandbreite die Modellgröße vorgibt

Bei Apple Silicon teilen sich CPU, GPU und Neural Engine denselben Unified-Memory-Pool – es gibt keinen Overhead durch das Hin- und Herkopieren zwischen VRAM und RAM, was für Inferenz ein natürlicher Vorteil ist. Das bedeutet aber auch: Die Speicherkapazität setzt eine harte Obergrenze für die maximal lauffähige Modellgröße. Grobe Umrechnungsregel: Ein ursprünglich in FP16 trainiertes Modell belegt nach 4-Bit-Quantisierung etwa das 0,55- bis 0,6-fache der Parameterzahl in GB, hinzu kommen KV-Cache und Systemoverhead.

Diese Tabelle ist nur ein Startpunkt – wie groß es real werden kann, hängt davon ab, ob parallel Xcode, Browser & Co. Speicher belegen. Prüfe mit top, wie viel freier Speicher übrig ist, bevor der Inferenzprozess abstürzt – nicht erst debuggen, wenn schon ein OOM aufgetreten ist.

Umgebungsaufbau: llama.cpp oder MLX

Beide Wege schließen sich nicht aus – man kann beide auf derselben Maschine installieren und je nach Aufgabe wechseln.

llama.cpp: Fokus auf Universalität

brew install cmake
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_METAL=ON
cmake --build build --config Release -j
./build/bin/llama-cli -m models/llama-3-8b-q4_k_m.gguf \
  -p "Schreibe ein Codebeispiel, das Rekursion erklärt" -n 256 --ctx-size 4096

-DGGML_METAL=ON ist entscheidend – erst mit aktiviertem Metal-Backend wird die GPU-Leistung voll ausgenutzt. Ohne diesen Parameter fällt alles auf reine CPU-Inferenz zurück, was mehrfach langsamer ist.

MLX: Apples natives Framework

python3 -m venv mlx-env
source mlx-env/bin/activate
pip install mlx-lm
mlx_lm.generate --model mlx-community/Llama-3-8B-Instruct-4bit \
  --prompt "Erkläre, welche Aufgabe der KV-Cache hat" --max-tokens 256

MLX-Modelle werden direkt unter dem Namespace mlx-community mit quantisierten Gewichten gehostet – ein eigenes Format-Konvertieren entfällt, und der Einstieg ist schneller als bei llama.cpp. Allerdings ist das Ökosystem und die Community-Dokumentation bei llama.cpp aktuell noch reifer.

Welches Quantisierungsformat wählen

Niedriger ist nicht automatisch besser – die Wahl richtet sich nach dem Anwendungsfall:

• Q4_K_M: Reicht für alltägliche Q&A und Code-Vervollständigung, spart am meisten Speicher und ist in den meisten Fällen die Standardwahl.
• Q5_K_M: Bei langen Reasoning-Ketten und mehrstufiger Logik empfiehlt sich diese Stufe – die Ausgabestabilität ist merklich besser.
• Q8_0: Kommt der Originalpräzision sehr nahe, geeignet für Evaluationsszenarien mit hohen Genauigkeitsanforderungen. Der Speicherbedarf verdoppelt sich jedoch, deshalb nur bei ausreichend Speicher (ab 24GB) in Betracht ziehen.

Die Faustregel ist einfach: Zunächst mit Q4 eine Reihe realistischer Fragen testen und die Antwortqualität manuell prüfen. Erst wenn deutliche Logiksprünge oder Rechenfehler auftreten, stufenweise höher gehen – man muss nicht von vornherein die höchste Präzision fahren und den Speicher komplett belegen.

Speicherplatz und Snapshot-Verwaltung

Modelldateien reichen von einigen GB bis zu mehreren Dutzend GB – vor Ablauf der Mietdauer sollte man die Bereinigung vorab planen:

1. Heruntergeladene Modelle einheitlich unter ~/models/ ablegen, damit sich Verzeichnisse gesammelt bereinigen oder migrieren lassen.
2. Mit du -sh ~/models/* regelmäßig den Speicherverbrauch prüfen und alte, bereits quantisierte Modellversionen zeitnah löschen, damit die Systemplatte nicht überläuft und die Inferenzgeschwindigkeit leidet.
3. Wer die Experimentumgebung (virtuelle Umgebung, Liste heruntergeladener Gewichte) behalten möchte, sollte sie als Tarball packen und lokal herunterladen – noch vor Ablauf der Mietdauer, denn nach Vertragsende bleiben keine Daten auf der Systemplatte erhalten.

du -sh ~/models/* | sort -rh | head -5
tar czf mlx-env-backup.tar.gz mlx-env models/*.json

Testablauf und Monitoring

Während der Inferenz nebenbei ein Terminalfenster mit der Ressourcenauslastung offen halten – so lässt sich Speicherdruck frühzeitig erkennen:

sudo powermetrics --samplers gpu_power -i 1000 -n 5

Beobachte GPU-Auslastung und Leistungskurve: Bleibt die Auslastung dauerhaft hoch, während die Antwortzeit trotzdem lang ist, liegt meist die Speicherbandbreite durch den Kontext-Cache am Limit. In diesem Fall entweder --ctx-size verkleinern oder auf eine kleinere Quantisierungsstufe wechseln – statt blind die Batch-Größe zu erhöhen.

Häufig gestellte Fragen