Wie viel Unified Memory braucht dein lokales LLM auf dem Mac?

Direkte Antwort: Für ein brauchbares lokales LLM auf einem Apple-Silicon-Mac sind 16 GB Unified Memory das Minimum, 24 bis 32 GB der vernünftige Einstieg, 48 bis 64 GB der Bereich für größere Modelle und anspruchsvollere Workflows und 96 bis 128 GB oder mehr sinnvoll, wenn 70B-Modelle, sehr lange Kontexte, multimodale Modelle oder mehrere parallele Prozesse geplant sind. 8 GB reichen nur für kleine, stark quantisierte Modelle und kurze Kontexte.

Wenn du speziell ein Notebook kaufst, vergleicht der Guide MacBook für KI-Entwicklung 2026 die verfügbaren M1- bis M5-Konfigurationen und zeigt, wann Air, Pro oder Max die sinnvollere RAM-Stufe bietet.

Entscheidend ist nicht allein die Parameterzahl. Der tatsächliche Speicherbedarf besteht aus Modellgewichten, KV-Cache, Runtime-Overhead, temporären Tensoren, macOS, anderen Anwendungen und einer Sicherheitsreserve. Ein Modell, das gerade noch startet, kann trotzdem langsam, swap-lastig oder instabil sein.

Auf Apple Silicon teilen sich CPU und GPU denselben physischen Speicherpool. Apple bezeichnet das als Unified Memory. Dadurch muss ein Modell nicht wie auf einem klassischen PC zwischen separatem Arbeitsspeicher und Grafikspeicher kopiert werden. Der Speicher bleibt aber endlich und wird zugleich von macOS, Browser, IDE, Datenbank, RAG-Index und anderen Prozessen genutzt.

Unified-Memory-Stufen und passende Modellgrößen

• 8 GB: 1B- bis 3B-Modelle in 4 Bit; nur zum Ausprobieren.
• 16 GB: 7B- bis 8B-Modelle in 4 oder 5 Bit; 12B bis 14B nur knapp.
• 24 GB: 12B- bis 14B-Modelle komfortabel; 20B bis 24B in 4 Bit mit begrenztem Kontext.
• 32 bis 36 GB: 20B bis 32B in 4 Bit; brauchbar für Entwicklung und RAG.
• 48 GB: 32B höher quantisiert; mehr Reserve für Tools und lange Prompts.
• 64 GB: 70B in einer guten 4-Bit-Quantisierung mit moderatem Kontext.
• 96 bis 128 GB: 70B in 5 bis 8 Bit oder Modelle um 100B bis 120B in 4 Bit.
• 192 bis 256 GB: sehr große Modelle, mehrere Instanzen oder hohe Präzision.
• 512 GB: 405B-Klasse in 4 Bit mit realer Reserve; nur in aktuellen Ultra-Konfigurationen.

Diese Werte sind Planungsbereiche, keine Garantien. Architektur, Quantisierungsformat, Kontext, Batch-Größe und Runtime können den Bedarf deutlich verändern.

Für dein konkretes Modell: Der Mac-KI-Matchmaker berechnet Modellgewichte, KV-Cache, macOS-Reserve und passende Macs.

RAM, VRAM und Unified Memory auf dem Mac

Klassischer RAM

RAM ist der schnelle Arbeitsspeicher, in dem das Betriebssystem, Programme und aktive Daten liegen. Auf einem PC mit diskreter Grafikkarte liegen CPU-Daten meist im System-RAM, während die GPU einen eigenen VRAM besitzt. Ein Modell kann deshalb in den System-RAM passen, aber trotzdem nicht vollständig in den VRAM.

Dedizierter VRAM

VRAM ist Speicher direkt an einer diskreten GPU. Für LLM-Inferenz ist er häufig der harte Engpass, weil Modellgewichte, KV-Cache und Arbeitsbereiche möglichst nah an der GPU liegen sollen. Reicht der VRAM nicht, müssen Teile über PCIe aus dem System-RAM übertragen oder auf der CPU berechnet werden.

Unified Memory bei Apple Silicon

Apple-Silicon-Macs nutzen einen gemeinsamen Speicherpool für CPU und GPU. Apple dokumentiert ausdrücklich, dass beide auf denselben physischen Speicher zugreifen. Das reduziert Kopien und ermöglicht, dass eine integrierte GPU auf deutlich mehr Speicher zugreifen kann als viele diskrete Consumer-GPUs.

Das bedeutet jedoch nicht:

• dass der gesamte Unified Memory dem Modell gehört;
• dass die Neural Engine automatisch jede LLM-Runtime beschleunigt;
• dass 64 GB auf jedem Mac gleich schnell sind;
• dass ein Modell, das in 64 GB passt, automatisch interaktiv schnell läuft.

*Abbildung 1: CPU und GPU greifen bei Apple Silicon auf denselben physischen Unified-Memory-Pool zu, statt getrennten System-RAM und VRAM zu verwenden. *

Fünf unterschiedliche Zustände

1. Passt in den Speicher: Gewichte und Laufzeitdaten können allokiert werden.
2. Läuft vollständig GPU-beschleunigt: Die gewählte Runtime hält die relevanten Tensoren auf dem Metal-Backend.
3. Teilweises Offloading: Einige Layer oder Operationen laufen auf CPU oder einem anderen Backend.
4. Kompression und Swap: macOS komprimiert Speicher und lagert inaktive Seiten auf die SSD aus.
5. Technisch startbar, praktisch ungeeignet: Sehr lange Ladezeiten, hohe Time to First Token, niedrige Tokens pro Sekunde oder ständiges Nachladen.

Woraus setzt sich der Speicherbedarf zusammen?

1. Modellgewichte

Die Gewichte sind der größte feste Block. Ihre Idealgröße hängt von Parameterzahl und Bitbreite ab.

2. Quantisierungsdaten

Eine „4-Bit-Datei“ enthält nicht zwangsläufig exakt vier Bit pro Parameter. Blockskalierungen, Nullpunkte, Metadaten, unquantisierte Tensoren und gemischte Präzision erhöhen die reale Bits-per-Weight-Zahl. Das llama.cpp-Projekt dokumentiert beispielsweise für Q4_K_M reale Dateien von 4,9 GB bei 8B, 43,1 GB bei 70B und 249,1 GB bei 405B – jeweils größer als die ideale 4-Bit-Rechnung.

3. KV-Cache

Der Key-Value-Cache speichert für bereits verarbeitete Tokens Zwischenergebnisse der Attention-Layer. In der Näherung wächst er linear mit Tokenzahl, Layerzahl, KV-Head-Zahl, Head-Dimension, Batch-Größe und Datentyp.

4. Runtime-Overhead

Dazu gehören Graphen, Buffer, Tokenizer, Sampler, Metal-Kernels, Threadpools und Verwaltungsdaten. Der Wert ist runtime- und architekturabhängig.

5. Temporäre Tensoren

Prefill, Attention und Matrixmultiplikationen benötigen Arbeitsbereiche. Flash Attention oder optimierte Kernel können diesen Bedarf verändern.

6. macOS und Anwendungen

Finder, WindowServer, Browser, Terminal, IDE, Docker, Datenbanken und RAG-Komponenten nutzen denselben Speicherpool. Apple zeigt in der Aktivitätsanzeige getrennt App-Speicher, verdrahteten Speicher, komprimierten Speicher und Swap an.

7. Mehrere Modelle und parallele Anfragen

Zwei gleichzeitig geladene Modelle benötigen ungefähr die Summe ihrer Gewichte plus getrennte Caches und Arbeitsbereiche. Mehrere parallele Sequenzen vervielfachen den KV-Cache weitgehend mit der Batch- beziehungsweise Sequenzzahl.

8. Multimodale Komponenten

Vision Encoder, Audio Encoder, Projektoren und zusätzliche Tokenrepräsentationen kommen zum Sprachmodell hinzu. Bei GGUF-Modellen kann beispielsweise eine separate Multimodal-Projektordatei geladen werden.

9. Mixture of Experts

Bei MoE-Modellen werden pro Token nur einige Experten berechnet, aber oft müssen deutlich mehr oder alle Expertengewichte im Speicher liegen. Aktive Parameter sind daher nicht dasselbe wie gespeicherte Gesamtparameter.

Abbildung 2: Beispielhafte Speicherbestandteile. Annahmen stehen direkt in der Grafik; kein Benchmark.

Modellparameter und Datentypen

Die vereinfachte Grundformel lautet:

Gewichtsspeicher in Byte ≈ Parameterzahl × Bits pro Parameter ÷ 8

Für eine Modellgröße in Milliarden Parametern ergibt sich die dezimale Größe besonders einfach:

Gewichtsspeicher in GB ≈ Parameterzahl in Milliarden × Bits ÷ 8

Beispiel für ein 8B-Modell in idealen 4 Bit:

8 Milliarden × 4 Bit ÷ 8 = 4 Milliarden Byte = 4,0 GB
4,0 GB ÷ 1,073741824 = 3,73 GiB

GB und GiB

• 1 GB = 1.000.000.000 Byte
• 1 GiB = 1.073.741.824 Byte

Hersteller und Downloadseiten verwenden häufig GB. Betriebssysteme und technische Tools können GiB anzeigen oder die Begriffe uneinheitlich verwenden. Deshalb werden beide Einheiten angegeben.

Theoretische Gewichtsgrößen

Modellklasse	FP16	8 Bit	6 Bit	5 Bit	4 Bit
1B	2.0 GB / 1.9 GiB	1.0 GB / 0.9 GiB	0.8 GB / 0.7 GiB	0.6 GB / 0.6 GiB	0.5 GB / 0.5 GiB
3B	6.0 GB / 5.6 GiB	3.0 GB / 2.8 GiB	2.2 GB / 2.1 GiB	1.9 GB / 1.7 GiB	1.5 GB / 1.4 GiB
8B	16.0 GB / 14.9 GiB	8.0 GB / 7.5 GiB	6.0 GB / 5.6 GiB	5.0 GB / 4.7 GiB	4.0 GB / 3.7 GiB
14B	28.0 GB / 26.1 GiB	14.0 GB / 13.0 GiB	10.5 GB / 9.8 GiB	8.8 GB / 8.1 GiB	7.0 GB / 6.5 GiB
22B	44.0 GB / 41.0 GiB	22.0 GB / 20.5 GiB	16.5 GB / 15.4 GiB	13.8 GB / 12.8 GiB	11.0 GB / 10.2 GiB
32B	64.0 GB / 59.6 GiB	32.0 GB / 29.8 GiB	24.0 GB / 22.4 GiB	20.0 GB / 18.6 GiB	16.0 GB / 14.9 GiB
70B	140.0 GB / 130.4 GiB	70.0 GB / 65.2 GiB	52.5 GB / 48.9 GiB	43.8 GB / 40.7 GiB	35.0 GB / 32.6 GiB
120B	240.0 GB / 223.5 GiB	120.0 GB / 111.8 GiB	90.0 GB / 83.8 GiB	75.0 GB / 69.8 GiB	60.0 GB / 55.9 GiB
405B	810.0 GB / 754.4 GiB	405.0 GB / 377.2 GiB	303.8 GB / 282.9 GiB	253.1 GB / 235.7 GiB	202.5 GB / 188.6 GiB

Wichtig: Diese Tabelle enthält mathematische Idealwerte. Eine konkrete GGUF- oder MLX-Datei kann durch Blockmetadaten, Skalierungswerte und gemischte Quantisierung größer sein. Die Inferenz benötigt zusätzlich KV-Cache und Runtime-Speicher.

Abbildung 3: Idealwerte nach Parameterzahl und Bitbreite; reale Quantisierungen sind meist größer.

Konkrete Beispielrechnungen

1B-Klasse

• FP16: 1 × 16 / 8 = 2,0 GB = 1,86 GiB
• 8 Bit: 1,0 GB = 0,93 GiB
• 4 Bit: 0,5 GB = 0,47 GiB

Mit Runtime, kleinem KV-Cache und Systemanteil ist ein 1B-Modell auf 8 GB gut machbar. Die Modellqualität und nicht der Speicher ist hier meist die größere Grenze.

3B-Klasse

• FP16: 6,0 GB = 5,59 GiB
• 6 Bit: 2,25 GB = 2,10 GiB
• 4 Bit: 1,5 GB = 1,40 GiB

3B in 4 bis 6 Bit ist die realistische Oberklasse für einen 8-GB-Mac, sofern der Kontext kurz bleibt und keine schweren Anwendungen parallel laufen.

7B- bis 8B-Klasse

Für 8B:

• FP16: 16,0 GB = 14,90 GiB
• 8 Bit: 8,0 GB = 7,45 GiB
• 6 Bit: 6,0 GB = 5,59 GiB
• 5 Bit: 5,0 GB = 4,66 GiB
• 4 Bit ideal: 4,0 GB = 3,73 GiB
• Q4_K_M-Beispiel aus llama.cpp: 4,9 GB reale Datei

Auf 16 GB ist ein 8B-Q4/Q5-Modell mit 4k bis 8k Kontext meist sinnvoll. FP16 lässt praktisch zu wenig Platz für macOS und Cache.

12B- bis 14B-Klasse

Für 14B:

• FP16: 28,0 GB = 26,08 GiB
• 8 Bit: 14,0 GB = 13,04 GiB
• 6 Bit: 10,5 GB = 9,78 GiB
• 5 Bit: 8,75 GB = 8,15 GiB
• 4 Bit ideal: 7,0 GB = 6,52 GiB

16 GB können ein 14B-Q4-Modell laden, aber lange Kontexte, Browser und Entwicklungsumgebung machen die Konfiguration schnell eng. 24 GB sind die deutlich robustere Wahl.

20B- bis 24B-Klasse

Für 22B:

• FP16: 44,0 GB = 40,98 GiB
• 8 Bit: 22,0 GB = 20,49 GiB
• 6 Bit: 16,5 GB = 15,37 GiB
• 5 Bit: 13,75 GB = 12,81 GiB
• 4 Bit ideal: 11,0 GB = 10,24 GiB

24 GB reichen für Q4 mit begrenztem Kontext. 32 GB erlauben mehr Cache und parallele Anwendungen.

27B- bis 32B-Klasse

Für 32B:

• FP16: 64,0 GB = 59,60 GiB
• 8 Bit: 32,0 GB = 29,80 GiB
• 6 Bit: 24,0 GB = 22,35 GiB
• 5 Bit: 20,0 GB = 18,63 GiB
• 4 Bit ideal: 16,0 GB = 14,90 GiB

Ein 32B-Q4-Modell ist auf 32 GB möglich, aber die reale Datei, ein großer KV-Cache und eine IDE können den Speicher aufbrauchen. 36 oder 48 GB sind komfortabler.

70B- bis 72B-Klasse

Für 70B:

• FP16: 140,0 GB = 130,39 GiB
• 8 Bit: 70,0 GB = 65,19 GiB
• 6 Bit: 52,5 GB = 48,89 GiB
• 5 Bit: 43,75 GB = 40,75 GiB
• 4 Bit ideal: 35,0 GB = 32,60 GiB
• Q4_K_M-Beispiel aus llama.cpp: 43,1 GB reale Datei

Diese Differenz zeigt, warum die Idealformel allein keine Kaufentscheidung tragen darf. Auf 64 GB ist 70B Q4 mit moderatem Kontext realistisch. 48 GB ist in vielen Fällen zu knapp, weil für Cache, Runtime und macOS kaum Reserve bleibt.

Oberhalb von 100B

Für 120B:

• FP16: 240,0 GB = 223,52 GiB
• 8 Bit: 120,0 GB = 111,76 GiB
• 6 Bit: 90,0 GB = 83,82 GiB
• 5 Bit: 75,0 GB = 69,85 GiB
• 4 Bit ideal: 60,0 GB = 55,88 GiB

Auf 96 GB ist 120B Q4 denkbar, sofern die reale Quantisierung nicht deutlich größer ist und der Kontext moderat bleibt. 128 GB ist für produktive Nutzung wesentlich plausibler.

Für 405B ergibt die ideale 4-Bit-Rechnung 202,5 GB beziehungsweise 188,6 GiB. Das dokumentierte Q4_K_M-Beispiel ist jedoch 249,1 GB groß. Ein 256-GB-System hätte damit praktisch keine Reserve; 512 GB sind die realistische Klasse.

Der Einfluss des Kontextfensters

Was ist das Kontextfenster?

Das Kontextfenster ist die maximale Zahl von Tokens, die das Modell in einer Anfrage und im bisherigen Dialog berücksichtigen kann. Tokens sind Wortteile, Satzzeichen oder kurze Wörter. Ein beworbenes 128k-Fenster bedeutet nicht, dass 128.000 Tokens auf jeder Hardware schnell oder sinnvoll sind.

KV-Cache-Formel

Für eine klassische Transformer-Architektur mit getrennten Key- und Value-Tensoren kann man näherungsweise rechnen:

KV-Cache-Byte =
Batch × Tokens × Layer × 2 × KV-Heads × Head-Dimension × Byte pro Element

Der Faktor 2 steht für Key und Value.

Beispiel A: mittelgroßes GQA-Modell

Annahmen:

• 32 Layer
• 8 KV-Heads
• Head-Dimension 128
• FP16-KV-Cache: 2 Byte
• Batch 1

pro Token = 32 × 2 × 8 × 128 × 2 Byte
          = 131.072 Byte
          = 128 KiB

Daraus folgen:

• 4k Tokens: 0,5 GiB
• 8k Tokens: 1,0 GiB
• 32k Tokens: 4,0 GiB
• 64k Tokens: 8,0 GiB
• 128k Tokens: 16,0 GiB

Beispiel B: großes GQA-Modell

Annahmen:

• 80 Layer
• 8 KV-Heads
• Head-Dimension 128
• FP16-KV-Cache
• Batch 1

pro Token = 80 × 2 × 8 × 128 × 2 Byte
          = 327.680 Byte
          = 320 KiB

• 4k Tokens: 1,25 GiB
• 8k Tokens: 2,5 GiB
• 32k Tokens: 10 GiB
• 64k Tokens: 20 GiB
• 128k Tokens: 40 GiB

Kontext	Beispiel A: 32 Layer, 8 KV-Heads	Beispiel B: 80 Layer, 8 KV-Heads	Praktische Bedeutung
4k	0,5 GiB	1,25 GiB	Kurzer Chat / kleine Dokumente
8k	1,0 GiB	2,5 GiB	Normaler Chat und Coding
32k	4,0 GiB	10,0 GiB	Große Dokumente / RAG
64k	8,0 GiB	20,0 GiB	Agenten- und Repository-Workflows
128k	16,0 GiB	40,0 GiB	Nur mit viel Speicher

Die Werte sind berechnete Architekturbeispiele, keine Messwerte eines bestimmten Produkts. Ein 8-Bit-KV-Cache halbiert den Rohspeicher gegenüber FP16 ungefähr. 4 Bit reduziert ihn weiter, kann aber zusätzliche Metadaten und Qualitäts- oder Geschwindigkeitsfolgen haben. Ollama weist darauf hin, dass größere Kontexte mehr Speicher benötigen und unterstützt bei kompatiblen Backends Flash Attention sowie quantisierte K/V-Caches.

Abbildung 4: Berechnetes KV-Cache-Wachstum bei FP16, Batch 1 und acht KV-Heads.

GQA und MQA

Bei Multi-Head Attention hat jeder Query-Head eigene Key- und Value-Heads. GQA teilt Key/Value-Heads zwischen Gruppen von Query-Heads; MQA nutzt einen gemeinsamen Key- und Value-Head. Dadurch sinkt der KV-Cache deutlich.

Batch-Größe und parallele Nutzer

Batch 2 verdoppelt den Cache in einer einfachen Näherung. Ein lokaler Server mit vier parallelen langen Chats kann daher viel mehr Speicher benötigen als ein einzelner Chat mit demselben Modell.

Empfohlene Modellgrößen nach Unified Memory

Unified Memory	Realistische Modellklasse	Typischer Kontext	Einordnung	Freie Reserve
8 GB	1–3B, meist 4 Bit	2k–4k	Nur Experimente; Browser/IDE schließen	3–4 GiB
16 GB	7–8B Q4/Q5; 12–14B Q4 nur knapp	4k–8k	Chat, Zusammenfassen, leichte Codehilfe	5–7 GiB
18 GB	8B Q5/Q6; 12–14B Q4	4k–8k	Etwas mehr Reserve als 16 GB	6–7 GiB
24 GB	12–14B Q4/Q5; 20–24B Q4 knapp	8k–16k	Guter Einstieg für lokale KI	7–9 GiB
32 GB	20–24B Q4/Q5; 27–32B Q4	8k–32k	Entwicklung, RAG, mittlere Modelle	8–10 GiB
36 GB	27–32B Q4 komfortabler	8k–32k	Pro/Max-Konfigurationen mit Reserve	9–11 GiB
48 GB	32B Q5/Q6; 70B nur sehr niedrig quantisiert/knapp	16k–32k	Code, RAG, mehrere Tools	10–13 GiB
64 GB	70B Q4 mit moderatem Kontext; 32B höherpräzise	8k–32k	Große Einzelmodelle, ernsthafte Entwicklung	12–16 GiB
96 GB	70B Q5/Q6; ~100–120B Q4	16k–64k	Lange Kontexte, multimodal, Forschung	14–20 GiB
128 GB	70B Q8 oder 120B Q4/Q5	32k–128k modellabhängig	Professionelle lokale Workflows	16–24 GiB
192 GB	120B Q8; ~200B Q4; mehrere große Modelle	32k–128k	Mac Pro/ältere Ultra-Klasse	20–30 GiB
256 GB	200–300B Q4; 405B nur niedrigere Bits/knapp	32k–128k	Sehr große Modelle und Parallelbetrieb	24–40 GiB
512 GB	405B Q4 mit Reserve; große MoE- und Mehrmodell-Setups	64k+	Extrem große lokale Inferenz	32–64 GiB

Die Reservewerte sind Planungsannahmen, keine technischen Limits. Bei einem reinen Headless-Server kann die Reserve geringer sein; bei Xcode, Docker, Browser und RAG-Datenbank sollte sie höher ausfallen.

Abbildung 5: Planungsbereiche, keine harten Kompatibilitätsgrenzen.

Empfehlungen nach Anwendungsfall

Anwendungsfall	Sinnvolle Speicherausstattung	Typische Modellklasse	Warum
Gelegentliches Chatten	16–24 GB	7B–14B Q4/Q5	Kurzer Kontext, eine Instanz
Zusammenfassungen	24–32 GB	14B–24B Q4	Dokumente erhöhen Kontextbedarf
Programmierassistent	32–64 GB	14B–32B, ggf. 70B Q4	Repository-Kontext und IDE laufen parallel
RAG	32–64 GB	14B–32B	Modell, Embeddings, Vektordatenbank und Dokumente
Lange Dokumente	64–128 GB	32B–70B	KV-Cache wird zum Hauptfaktor
Lokale Agenten	48–128 GB	24B–70B	Lange Historie, Tools, mehrere Prozesse
Multimodal/Bildverständnis	32–96 GB	12B–32B plus Vision-Komponenten	Encoder und Bildtokens benötigen Zusatzspeicher
Mehrere Modelle	96 GB aufwärts	Zwei oder mehr 14B–70B	Gewichte und Caches addieren sich
Forschung/Entwicklung	128–512 GB	70B bis mehrere hundert B	Hohe Präzision, lange Kontexte, Parallelität

Reale Mac-Klassen im Jahr 2026

MacBook Air

Apples MacBook-Air-Spezifikationen listen für die aktuelle M5-Generation 16 GB Unified Memory als Standard, konfigurierbar auf 24 GB oder 32 GB; die Speicherbandbreite gibt Apple mit 153 GB/s an. Der Air ist lüfterlos. Für 7B bis 14B ist er gut geeignet; 20B bis 24B in 4 Bit ist auf 24 oder 32 GB möglich, aber längere Dauerlast kann wegen passiver Kühlung weniger konstant sein als auf aktiv gekühlten Macs.

MacBook Pro

Die MacBook-Pro-Spezifikationsseite führt das aktuelle 14- und 16-Zoll-Lineup mit M5, M5 Pro und M5 Max auf. Apple nennt 307 GB/s Speicherbandbreite für M5 Pro und bis zu 614 GB/s für M5 Max; 128 GB Unified Memory werden für das M5-Max-40-Core-GPU-Topmodell als Konfigurationsoption gelistet. Damit können zwei MacBook-Pro-Modelle mit gleicher Speichermenge bei LLMs deutlich unterschiedliche Tokenraten erreichen.

Mac mini

Apples Mac-mini-Spezifikationsseite beschreibt das aktuelle Lineup mit M4 oder M4 Pro. Apple gibt 120 GB/s Speicherbandbreite für den M4 und 273 GB/s für den M4 Pro an; 48 GB Unified Memory werden als Konfigurationsoption gelistet. Der M4 Pro ist für 32B-Klassen deutlich interessanter als ein Basismodell mit derselben oder ähnlicher Speichermenge.

Mac Studio

Apples Mac-Studio-Spezifikationsseite führt die aktuelle Generation mit M4 Max und M3 Ultra. Apple gibt 410 GB/s Speicherbandbreite für den M4 Max mit 14-Core-CPU und 546 GB/s für den M4 Max mit 16-Core-CPU an; der M3 Ultra mit 32-Core-CPU, 80-Core-GPU und 32-Core-Neural-Engine erreicht 819 GB/s. Apple listet für die M4-Max-Konfigurationen 36 GB und 96 GB Unified Memory, mit 64 GB als zusätzliche Konfiguration für die M4-Max-Variante mit 16-Core-CPU und 40-Core-GPU. Für die M3-Ultra-Konfiguration bewirbt Apple im Mac-Studio-Newsroom bis zu 512 GB Unified Memory.

Mac Pro

Der aktuelle Apple-Silicon-Mac-Pro nutzt laut Apple-Support-Dokument 111343 den M2 Ultra mit 800 GB/s Speicherbandbreite und bis zu 192 GB Unified Memory. Für reine lokale LLM-Inferenz ist der Mac Studio mit neuerem Ultra-Chip und höherer Maximalkapazität häufig die logischere Klasse; der Mac Pro richtet sich zusätzlich an Workflows, die PCIe-Erweiterung benötigen.

Warum gleiche Speichermenge nicht gleiche Leistung bedeutet

Die Geschwindigkeit hängt ab von:

• Speicherbandbreite;
• GPU-Kernzahl und GPU-Architektur;
• thermischer Kühlung;
• Runtime und Kernelqualität;
• Quantisierungsformat;
• Modellarchitektur;
• Promptlänge;
• Ausgabelänge;
• Cache-Datentyp;
• parallelen Prozessen.

Ein 64-GB-Mac mit Max-Chip kann ein speicherbandbreitenlimitiertes Modell deutlich schneller dekodieren als ein 64-GB-System mit niedrigerer Bandbreite, sofern beide Konfigurationen existieren beziehungsweise verglichen werden.

Welche Modelle passen ungefähr auf welchen Mac?

Arbeitsbudget für das Modell	Modellklasse	Quantisierung	Kontext	Realistische Bewertung
2–4 GiB	1B–3B	Q4–Q8	2k–8k	Komfortabel auf 8 GB
5–9 GiB	7B–8B	Q4–Q6	4k–16k	Gut auf 16 GB
8–15 GiB	12B–14B	Q4–Q6	8k–32k	Gut auf 24 GB
14–24 GiB	20B–32B	Q4–Q5	8k–32k	32–48 GB
40–52 GiB	70B	Q4–Q5	8k–32k	64 GB knapp bis gut; 96 GB komfortabler
60–90 GiB	100B–120B	Q4–Q6	16k–64k	96–128 GB
120–220 GiB	200B–400B	niedrige bis mittlere Bits	modellabhängig	192–512 GB
ca. 232 GiB reale Datei	405B Q4_K_M-Beispiel	Q4_K_M	Zusatzspeicher nötig	512 GB empfohlen

Ollama, LM Studio, MLX und llama.cpp

Runtime	Typisches Format	Mac-Beschleunigung	Speichersteuerung	Geeignet für
Ollama	meist GGUF-basierte Modelle im eigenen Modellmanagement	Metal über Backend	Kontext, Flash Attention, KV-Cache-Quantisierung je nach Support	Einfache CLI/API und lokale Dienste
LM Studio	GGUF und eigene Engines/Modelle	GPU-Offload auf Apple Silicon	Kontextlänge, Offload, Lade-/Entladeverwaltung	GUI, Modellvergleich, lokaler API-Server
MLX-LM	MLX/Safetensors-Modelle	nativ für Apple Silicon und Unified Memory	Quantisierung, rotierender KV-Cache, Prompt-Cache	Python, Forschung, Apple-spezifische Optimierung
llama.cpp	GGUF	Metal standardmäßig verfügbar beim passenden Build	GPU-Layer, Kontext, Cache-Typen, mmap/mlock	maximale Kontrolle, CLI und Server

GGUF

GGUF ist ein Container für Tensoren und Metadaten. Die Dateigröße ist ein guter Ausgangspunkt für die Gewichte, aber nicht der gesamte Laufzeitspeicher.

MLX-Modelle

MLX ist um das Unified-Memory-Modell von Apple Silicon gebaut. MLX-LM bietet Quantisierung, Prompt-Caching und einen rotierenden KV-Cache. Ein kleiner max-kv-size spart Speicher, kann aber Qualität kosten, weil ältere Cache-Einträge verworfen werden.

Metal und GPU-Offloading

llama.cpp aktiviert Metal auf macOS beim entsprechenden Build standardmäßig; GPU-Inferenz kann auch deaktiviert oder über Layersteuerung beeinflusst werden. LM Studio bietet beim Laden eine GPU-Offload-Konfiguration und nennt als Systemanforderung aktuell 16 GB Unified Memory oder mehr unter macOS, während 8-GB-Macs auf kleine Modelle und bescheidene Kontexte verwiesen werden.

Memory Mapping

llama.cpp kann GGUF-Dateien per mmap abbilden. Das verbessert typischerweise Ladeverhalten und überlässt Seitenverwaltung dem Betriebssystem. Es verwandelt die SSD jedoch nicht in schnellen Unified Memory: Werden Modellseiten ständig ein- und ausgelagert, leidet die interaktive Leistung.

Keine pauschale Rangliste

Keine Runtime ist für jedes Modell, jede Version und jeden Mac stets schneller oder sparsamer. Ein fairer Vergleich benötigt:

• exakt dieselbe Modellversion;
• dasselbe Quantisierungsformat;
• gleiche Kontextlänge;
• gleiche Prompt- und Ausgabetokens;
• gleiche Cache-Präzision;
• dokumentierte Runtime-Version;
• mehrere Wiederholungen nach Warm-up.

Swap und Speicherkomprimierung

macOS komprimiert inaktive Speicherseiten, wenn der Druck steigt. Reicht der physische Speicher nicht, werden Seiten auf das Startvolume ausgelagert. Die Aktivitätsanzeige zeigt Speicherbelastung, komprimierten Speicher und Swap-Nutzung.

Swap kann helfen, dass ein Modell lädt. Er ist aber kein gleichwertiger Ersatz für Unified Memory:

• SSD-Latenz und Bandbreite sind für wiederholte LLM-Zugriffe schlechter;
• Time to First Token kann stark steigen;
• Tokenrate kann einbrechen, wenn aktive Gewichte oder Cache-Seiten wechseln;
• parallele Anwendungen reagieren träger;
• der nutzbare Kontext wird unberechenbarer.

Permanenter Swap verursacht zusätzliche SSD-Schreibvorgänge. Daraus folgt nicht automatisch ein kurzfristiger SSD-Ausfall; alarmistische Lebensdauerprognosen ohne Messdaten sind nicht seriös. Praktisch entscheidend ist die schlechte und schwankende Leistung.

Geschwindigkeit ist nicht nur eine RAM-Frage

Time to First Token

Zeit vom Absenden bis zum ersten Ausgabetoken. Sie enthält Modellladen, Promptverarbeitung und Initialisierung.

Prefill oder Prompt Processing

Das Modell verarbeitet den vollständigen Prompt. Lange Dokumente belasten Rechenleistung und Speicher stärker als ein kurzer Chat.

Decode oder Tokens pro Sekunde

Nach dem ersten Token wird autoregressiv generiert. Bei großen quantisierten Modellen auf Apple Silicon ist Decode häufig stark von Speicherbandbreite abhängig.

Thermik

Ein MacBook Air hat keinen Lüfter. Bei langen Läufen kann die nachhaltige Leistung anders ausfallen als bei MacBook Pro, Mac mini oder Mac Studio.

Ein Modell kann passen und trotzdem langsam sein

Ein 70B-Q4-Modell kann in 64 GB passen. Auf einem Chip mit geringerer Speicherbandbreite kann es dennoch nur eine niedrige Tokenrate liefern. Mehr Speicher entscheidet über Machbarkeit; Chip und Bandbreite entscheiden wesentlich über Tempo.

Abbildung 6: Ein Modellstart ist nicht gleichbedeutend mit guter Nutzbarkeit.

Kaufberatung

Reichen 16 GB für lokale LLMs?

Ja, für 7B bis 8B in Q4/Q5 und kurze bis mittlere Kontexte. Für 14B, lange Dokumente, RAG oder eine schwere IDE ist 16 GB knapp. Wer einen Mac neu kauft und lokale KI ernsthaft nutzen will, sollte 24 oder 32 GB wählen.

24 GB oder 32 GB?

24 GB sind ein guter Einstieg für 12B bis 14B. 32 GB erweitern den sinnvollen Bereich auf 20B bis 32B in niedriger Quantisierung und geben deutlich mehr Reserve für Kontext, Browser und Entwicklungswerkzeuge. Bei nicht aufrüstbarem Speicher ist 32 GB die langlebigere Wahl.

Wann lohnen sich 48 oder 64 GB?

48 GB lohnen sich für 32B-Modelle, RAG, lokale Agenten und parallele Tools. 64 GB sind die Schwelle, ab der 70B Q4 realistisch wird. Für 70B mit längerem Kontext sind 96 GB angenehmer.

Braucht man 96 oder 128 GB?

Nicht für normales Chatten. Sie sind sinnvoll für:

• 70B mit höherer Präzision;
• 100B- bis 120B-Klasse;
• 32k bis 128k Kontext;
• mehrere Modelle;
• multimodale Systeme;
• Forschung und lokale Server.

Mehr Speicher oder stärkerer Chip?

Zuerst muss das Modell passen. Ein schnellerer Chip mit zu wenig Speicher kann das gewünschte Modell gar nicht sinnvoll ausführen. Wenn beide Konfigurationen das Modell mit Reserve tragen, bringt der stärkere Chip beziehungsweise die höhere Speicherbandbreite den größeren Geschwindigkeitsgewinn.

Praktische Reihenfolge:

1. gewünschte Modellklasse und Kontext bestimmen;
2. erforderlichen Unified Memory mit Reserve wählen;
3. innerhalb dieser Speicherklasse den stärksten sinnvollen Chip kaufen.

Empfehlungen nach Nutzergruppe

• Studierende und Einsteiger: 24 GB; 32 GB bei Programmierung und längerer Nutzung.
• Entwickler: 32 bis 64 GB, abhängig von Docker, IDE, RAG und Modellgröße.
• Professionelle lokale KI: 64 bis 128 GB.
• Forschung, große Modelle, Server: 128 bis 512 GB.

Unified Memory ist bei den meisten aktuellen Macs nach dem Kauf nicht aufrüstbar. Eine kleine Reserve ist deshalb wertvoller als eine Konfiguration, die heute bereits am Limit liegt.

Häufige Fehler und Missverständnisse

„Ein 7B-Modell braucht exakt 7 GB.“

Falsch. 7B bezeichnet Parameter, nicht Byte. In FP16 wären es theoretisch 14 GB; in idealen 4 Bit 3,5 GB, zuzüglich Overhead.

„4 Bit ist exakt halb so groß wie 8 Bit.“

Nur in der Idealformel. Reale Formate enthalten Skalierungen, Metadaten und gemischte Tensoren.

„Eine 10-GB-Datei braucht 10 GB Unified Memory.“

Die Datei deckt vor allem Gewichte ab. KV-Cache, Runtime, temporäre Buffer und System fehlen.

„Der gesamte Unified Memory steht dem Modell zur Verfügung.“

Nein. macOS und andere Anwendungen nutzen denselben Pool.

„Mehr Kontext ist immer besser.“

Mehr Kontext kostet Speicher und Prefill-Zeit. Außerdem kann die Qualität bei extrem langen Prompts trotz beworbener Maximalgröße sinken.

„Swap ersetzt fehlenden RAM.“

Swap kann das Starten ermöglichen, aber nicht dieselbe Leistung liefern.

„Mehr Parameter bedeutet automatisch besser.“

Architektur, Training, Daten, Post-Training, Quantisierung und Aufgabe sind ebenso wichtig.

„Alle 4-Bit-Quantisierungen sind gleich.“

Sie unterscheiden sich in Bits pro Weight, Skalierung, Mischpräzision, Qualität und Kernelunterstützung.

„Wenn es startet, läuft es gut.“

Startfähigkeit sagt wenig über TTFT, Tokenrate und Stabilität aus.

„RAM bestimmt allein die Geschwindigkeit.“

Speicherbandbreite, GPU, Runtime, Promptlänge und Thermik sind ebenfalls zentral.

Praktische Checkliste

• Parameterzahl und Architektur prüfen.
• Quantisierungsformat und reale Dateigröße prüfen.
• Gewünschte Kontextlänge festlegen.
• KV-Cache mit Layern, KV-Heads und Datentyp abschätzen.
• Runtime-Overhead einplanen.
• Speicher für macOS und andere Programme reservieren.
• Reale Benchmarks für exakt den eigenen Mac und dieselbe Runtime suchen.
• Zunächst kleinere Quantisierung und kürzeren Kontext testen.
• Aktivitätsanzeige: Speicherbelastung, Kompression und Swap beobachten.
• Time to First Token, Prompt-Tokens/s und Decode-Tokens/s getrennt messen.

Key Takeaways

1. Die reale Modelldatei ist wichtiger als die reine 4-Bit-Idealrechnung.
2. Der KV-Cache kann bei 32k bis 128k Kontext viele oder sogar mehrere Dutzend GiB beanspruchen.
3. 24 bis 32 GB sind der beste allgemeine Einstieg; 64 GB ist die realistische 70B-Q4-Schwelle.
4. Speicher entscheidet, ob ein Modell sinnvoll passt; Bandbreite und Chip bestimmen wesentlich das Tempo.
5. Für einen Neukauf sollte mindestens 20 bis 30 Prozent Arbeitsreserve gegenüber dem geplanten Normalfall eingeplant werden.

Fazit: 24 oder 32 GB als sinnvolle Basis

Für die meisten Mac-Nutzer, die lokale KI ernsthaft ausprobieren möchten, sind 24 oder 32 GB Unified Memory die sinnvollste Basiskonfiguration. 16 GB funktionieren für kleine Modelle, begrenzen aber Modellgröße, Kontext und parallele Anwendungen. 48 GB sind stark für 32B-Modelle und Entwicklerworkflows. 64 GB sind der Einstieg in brauchbare 70B-Q4-Nutzung, während 96 oder 128 GB lange Kontexte und höhere Präzision ermöglichen.

Wer sehr große Modelle lokal betreiben will, sollte nicht nur auf Kapazität achten: Ein Mac Studio mit Ultra-Chip kombiniert hunderte Gigabyte Unified Memory mit sehr hoher Speicherbandbreite. Ein Modell, das in 256 GB theoretisch hineinpasst, benötigt in der Praxis häufig 512 GB, sobald reale Quantisierung, KV-Cache und Systemreserve berücksichtigt werden.

Weiterlesen

• Mac AI Matchmaker: Speicherbedarf und passende Hardware berechnen
• Die besten Open-Weight-LLMs für deinen Mac
• Ollama auf dem Mac mini M4 einrichten
• LM Studio vs. Ollama auf dem Mac
• Alle Mac-Hardwareprofile vergleichen

Quellen