Kann ein Mac große Sprachmodelle lokal ohne dedizierte GPU ausführen?

Ja — das ist Apples Stärke. Der Unified Memory wird zwischen CPU und GPU mit hoher Bandbreite geteilt, sodass die GPU den gesamten Speicherpool nutzen kann. Ein Mac mit 64 GB kann ein 70B-Modell bei 4 Bit ausführen, was in eine diskrete GPU mit 24 GB nicht passt, und kleinere Modelle laufen schnell. Eine separate GPU ist nicht erforderlich.

Wie viel Unified Memory brauche ich für ein 7B-, 30B- oder 70B-Modell?

Bei 4-Bit-Quantisierung: etwa 16 GB für ein 7B–8B-Modell, 32 GB für bis zu etwa 30B, und 64 GB für ein 70B (das etwa 40 GB Gewichte belegt, mit engem Kontextspielraum). Mit 128 GB kannst du ein 70B bei höherer Präzision mit Platz für großen Kontext ausführen. Lass immer Platz für den KV-Cache, der mit der Kontextlänge wächst.

Ist MLX schneller als llama.cpp auf Apple Silicon?

Oft, bei kleineren Modellen — MLX ist Apples für Unified Memory entwickeltes Framework und ist unterhalb von etwa 14B merklich schneller, und es glänzt bei Mixture-of-Experts-Modellen. Oberhalb von etwa 27B nähern sich die beiden an, weil beide bandbreitenbegrenzt werden. llama.cpps Vorteil ist die größere GGUF-Modellbibliothek und plattformübergreifende Konsistenz. Nutze MLX für Höchstgeschwindigkeit bei kleineren und MoE-Modellen.

Warum ist mein Mac langsam beim Starten der Antwort auf lange Prompts?

Weil das Prompt-Processing (Time-to-First-Token) Apples schwacher Punkt ist. Das Prefill ist rechengebunden und Apples GPUs fehlen die dedizierten Tensor-Cores, die NVIDIA dafür verwendet, sodass ein langer Prompt eine Weile braucht, bevor der erste Token erscheint — auch wenn die Token-Generierung danach schnell ist. Das ist die wichtigste Apple-spezifische Einschränkung für die Arbeit mit langem Kontext.

Was ist das schnellste Tool zum Ausführen von LLMs auf einem Mac?

Für Höchstleistung MLX-LM (Apples Framework), besonders bei kleineren und MoE-Modellen. Für einfache Bedienung sind Ollama (CLI plus eine OpenAI-kompatible API) oder LM Studio (die beste GUI) die beliebten Optionen, und mehrere nutzen inzwischen MLX-Backends auf Apple Silicon. Die richtige Wahl hängt davon ab, ob du maximale Geschwindigkeit oder maximale Bequemlichkeit möchtest.

Kann ich ein 70B-Modell auf einem MacBook Pro mit 64 GB ausführen?

Ja, bei 4 Bit — ein 70B bei Q4 belegt etwa 40 GB, was in 64 GB mit Platz für die Runtime und ein bescheidenes Kontextfenster passt. Das ist der praktische Einstiegspunkt für 70B auf einem Mac; der Kontextspielraum ist begrenzt, also wärst du für große Kontexte oder höhere Präzision besser mit 128 GB bedient. Erwarte gute Generierungsgeschwindigkeit, aber langsamere Time-to-First-Token bei langen Prompts.

Apple Silicon oder NVIDIA für lokale LLMs?

Apple Silicon ist hervorragend für private Einzelbenutzer-Inferenz — der große Unified Memory erlaubt es einem Mac, Modelle auszuführen, die mehrere diskrete GPUs benötigen würden, bei geringerem Stromverbrauch. NVIDIA gewinnt bei roher Bandbreite (mehrfach höher), Prompt-Processing-Geschwindigkeit, hochnebenläufigem Serving und Ökosystem (CUDA). Wähle Apple für persönliche lokale Nutzung und große Modelle auf einer Maschine; NVIDIA für Durchsatz und langen Kontext beim Serving.

← Resources

By Ren Sugaya — Performance Engineer, GPU & Inference · 2026-05-02 · TUTORIAL

LLMs auf Apple Silicon ausführen: Unified Memory und was passt

Apple Silicon eignet sich besonders gut für den Betrieb von LLMs, weil der Unified Memory geteilt, hochbandbreitig und groß ist — ein Mac mit 64 GB kann ein 70B-Modell ausführen. Dieser Leitfaden erklärt, was in jedes RAM-Level passt, MLX versus llama.cpp, die einzige echte Schwäche (Prompt-Processing) und die verfügbaren Tools.

Warum Unified Memory der entscheidende Vorteil ist

Apple Silicon teilt einen einzigen hochbandbreitigen Speicherpool zwischen CPU, GPU und Neural Engine — es gibt keinen separaten VRAM und keine langsame Kopie über einen PCIe-Bus. Deshalb kann ein Mac mit 64 GB ein Modell laden, das nicht auf eine diskrete GPU mit 24 GB passt: der gesamte Pool steht der GPU zur Verfügung.

Das ist wichtig, weil die Token-Generierung bei LLMs [durch die Speicherbandbreite begrenzt](/articles/running-llms-on-cpu) ist — jeder Token erfordert das Lesen des Modells aus dem Speicher — und Apples Unified-Bandbreite hoch genug ist, um beim Decode wirklich wettbewerbsfähig zu sein. Die Bandbreite, nicht die Rechenleistung, ist die entscheidende Kenngröße für die Generierungsgeschwindigkeit.

Was passt, nach Speicher-Level

Unified Memory ist die maßgebliche Einschränkung, also wähle das Modell passend zu deinem Mac (Werte bei 4-Bit-Quantisierung):

16 GB: 7B–8B-Modelle problemlos.
32 GB: bis zu etwa 30B.
64 GB: ein 70B-Modell wird machbar (ein 70B bei Q4 belegt etwa 40 GB), obwohl der Kontextspielraum eng ist — das ist der praktische Einstiegspunkt für 70B.
128 GB: ein 70B bei höherer Präzision (Q5/Q8) mit Platz für großen Kontext.
Ultra-Level (192 GB+): 70B bei hoher Präzision, sehr große Modelle oder mehrere Modelle gleichzeitig im Speicher.

Faustregel: Rechne mit etwa 0,5–0,6 GB pro Milliarde Parameter für die Gewichte bei Q4, dann lass Platz für den KV-Cache, der mit der Kontextlänge wächst und oft darüber entscheidet, ob 16K oder 32K Kontext möglich ist.

MLX vs. llama.cpp

Zwei Runtimes dominieren auf dem Mac. Das Metal-Backend von llama.cpp übersetzt GPU-Berechnungen in Metal-Shader und nutzt das plattformübergreifende GGUF-Format mit der größten Modellbibliothek. MLX ist Apples eigenes Framework, von Grund auf für Unified Memory entwickelt — im Allgemeinen schneller bei kleineren Modellen (oft merklich so unterhalb von ~14B), wobei sich der Abstand oberhalb von ~27B verringert, wo beide an die Bandbreitengrenze stoßen.

MLX gewinnt an Bedeutung: Apple positionierte es als bevorzugtes Apple-Silicon-Framework, populäre Runtimes fügten MLX-Backends hinzu, und es glänzt bei Mixture-of-Experts-Modellen. Die pragmatische Einschätzung: MLX für Höchstgeschwindigkeit bei kleineren Modellen und MoE-Modellen, llama.cpp/GGUF für die größte Modellauswahl und plattformübergreifende Konsistenz.

Die echte Schwäche: Prompt-Processing

Apples ehrliche Einschränkung liegt nicht bei der Generierung — sondern beim Prompt-Processing (Time-to-First-Token). Das Prefill ist rechengebunden, umfasst große Matrixmultiplikationen, und Apples GPUs fehlen die dedizierten Tensor-Cores, die NVIDIA hier schnell machen. Selbst wenn die Token-Generierung wettbewerbsfähig ist, kann das Modell bei einem langen Prompt merklich langsam mit dem Antworten beginnen, was das reale Gefühl bei der Arbeit mit langem Kontext dominiert.

Die andere Einschränkung ist das Ökosystem: Die meisten Tools zielen auf CUDA ab, es gibt weniger vorquantisierte MLX-Modelle als GGUF, und eine High-End-NVIDIA-GPU hat immer noch ein Vielfaches der rohen Bandbreite. Für interaktive lokale Einzelbenutzernutzung ist Apple Silicon hervorragend; für langen Kontext oder hochdurchsatzbasiertes Serving sind diese Lücken relevant.

Tools und Quantisierung

Die Mac-Tool-Landschaft ist ausgereift: Ollama (CLI plus eine OpenAI-kompatible API, der einfachste Einstieg), LM Studio (die beste GUI), MLX-LM (Höchstleistung und Fine-Tuning, via Python) und datenschutzorientierte Offline-Apps. GGUF ist das dominante Tool-übergreifende Quantisierungsformat; das MLX-Format ist Apple-nativ und schneller, hat aber eine kleinere Bibliothek.

Wie überall ist die [Quantisierung](/articles/llm-quantization-explained-gguf) das, was es möglich macht — auf 4 Bit zu gehen verkleinert ein Modell etwa auf ein Viertel (ein 70B von ~140 GB auf ~40 GB) bei moderatem Qualitätsverlust, und Q4_K_M ist der übliche Sweet Spot. Steige auf Q5 oder Q8 auf, wenn dein Unified Memory es erlaubt.

Apple Silicon in osFoundry

osFoundry führt lokale Inferenz auf Apple Silicon über die Metal- und MLX-Pfade aus, sodass das Modell vollständig auf der GPU deines Macs mit dessen Unified Memory ausgeführt wird — keine Daten verlassen das Gerät und es gibt keine PCIe-Kopierstrafe. Da die Einschränkung schlicht die Menge des verfügbaren Unified Memory ist, hilft dir osFoundry, ein für deinen Mac geeignetes Modell auszuwählen — ein 7B–8B-Modell auf einer 16-GB-Maschine, bis zu einem 70B auf einer 64-GB+-Maschine — und wählt die Quantisierung, um das Modell in den verfügbaren Speicher zu passen und dabei so viel Qualität wie möglich zu erhalten, sodass du nicht manuell über GGUF-Formate oder Q4/Q5/Q8-Kompromisse nachdenken musst. Das Ergebnis ist vollständig private, offline-fähige lokale Inferenz, die auf das Speicher-Level jedes Macs abgestimmt ist — und dasselbe Modell kann auf einen dedizierten GPU-Endpunkt skaliert werden, wenn du schnelleres Prompt-Processing oder höheren Durchsatz benötigst. (Den zugrunde liegenden Bandbreitenhintergrund findest du in unserem [CPU-Inferenzleitfaden](/articles/running-llms-on-cpu).)

Frequently asked questions

Kann ein Mac große Sprachmodelle lokal ohne dedizierte GPU ausführen?: Ja — das ist Apples Stärke. Der Unified Memory wird zwischen CPU und GPU mit hoher Bandbreite geteilt, sodass die GPU den gesamten Speicherpool nutzen kann. Ein Mac mit 64 GB kann ein 70B-Modell bei 4 Bit ausführen, was in eine diskrete GPU mit 24 GB nicht passt, und kleinere Modelle laufen schnell. Eine separate GPU ist nicht erforderlich.
Wie viel Unified Memory brauche ich für ein 7B-, 30B- oder 70B-Modell?: Bei 4-Bit-Quantisierung: etwa 16 GB für ein 7B–8B-Modell, 32 GB für bis zu etwa 30B, und 64 GB für ein 70B (das etwa 40 GB Gewichte belegt, mit engem Kontextspielraum). Mit 128 GB kannst du ein 70B bei höherer Präzision mit Platz für großen Kontext ausführen. Lass immer Platz für den KV-Cache, der mit der Kontextlänge wächst.
Ist MLX schneller als llama.cpp auf Apple Silicon?: Oft, bei kleineren Modellen — MLX ist Apples für Unified Memory entwickeltes Framework und ist unterhalb von etwa 14B merklich schneller, und es glänzt bei Mixture-of-Experts-Modellen. Oberhalb von etwa 27B nähern sich die beiden an, weil beide bandbreitenbegrenzt werden. llama.cpps Vorteil ist die größere GGUF-Modellbibliothek und plattformübergreifende Konsistenz. Nutze MLX für Höchstgeschwindigkeit bei kleineren und MoE-Modellen.
Warum ist mein Mac langsam beim Starten der Antwort auf lange Prompts?: Weil das Prompt-Processing (Time-to-First-Token) Apples schwacher Punkt ist. Das Prefill ist rechengebunden und Apples GPUs fehlen die dedizierten Tensor-Cores, die NVIDIA dafür verwendet, sodass ein langer Prompt eine Weile braucht, bevor der erste Token erscheint — auch wenn die Token-Generierung danach schnell ist. Das ist die wichtigste Apple-spezifische Einschränkung für die Arbeit mit langem Kontext.
Was ist das schnellste Tool zum Ausführen von LLMs auf einem Mac?: Für Höchstleistung MLX-LM (Apples Framework), besonders bei kleineren und MoE-Modellen. Für einfache Bedienung sind Ollama (CLI plus eine OpenAI-kompatible API) oder LM Studio (die beste GUI) die beliebten Optionen, und mehrere nutzen inzwischen MLX-Backends auf Apple Silicon. Die richtige Wahl hängt davon ab, ob du maximale Geschwindigkeit oder maximale Bequemlichkeit möchtest.
Kann ich ein 70B-Modell auf einem MacBook Pro mit 64 GB ausführen?: Ja, bei 4 Bit — ein 70B bei Q4 belegt etwa 40 GB, was in 64 GB mit Platz für die Runtime und ein bescheidenes Kontextfenster passt. Das ist der praktische Einstiegspunkt für 70B auf einem Mac; der Kontextspielraum ist begrenzt, also wärst du für große Kontexte oder höhere Präzision besser mit 128 GB bedient. Erwarte gute Generierungsgeschwindigkeit, aber langsamere Time-to-First-Token bei langen Prompts.
Apple Silicon oder NVIDIA für lokale LLMs?: Apple Silicon ist hervorragend für private Einzelbenutzer-Inferenz — der große Unified Memory erlaubt es einem Mac, Modelle auszuführen, die mehrere diskrete GPUs benötigen würden, bei geringerem Stromverbrauch. NVIDIA gewinnt bei roher Bandbreite (mehrfach höher), Prompt-Processing-Geschwindigkeit, hochnebenläufigem Serving und Ökosystem (CUDA). Wähle Apple für persönliche lokale Nutzung und große Modelle auf einer Maschine; NVIDIA für Durchsatz und langen Kontext beim Serving.