Vor dem Kauf eines Mac Mini M4 suchen die meisten nach: Welche Stufe erreicht M4 Mac Mini lokales LLM, wie groß ist der Unterschied 16 GB vs. 24 GB, und wie oft swappt ein Mac Mini beim LLM-Betrieb? 2026 laufen Qwen2.5-, Llama-3.1-Gewichte u. a. per Ollama auf Apple Silicon; der Engpass ist meist Unified Memory, nicht eine dedizierte GPU.
Nur 7B vs. 14B entscheiden? Zum Spoke-Artikel M4 Mac Mini: 7B vs. 14B — Alltagsunterschied (Praxistest 2026) (Entscheidungs-Flowchart, Agent-TTFT, Auswahl in §8.4). Dieser Hub liefert Methodik, Fehlfälle und raw dumps zur Zitation.
Dies ist kein Modell-Ranking, sondern ein Lab-Log mit Fehlfällen und raw dumps (2026-05-20 bis 06-02). Artefakte: sample-benchmark-run.log, raw-vm-stat-dump.txt, ollama-debug-excerpt.log.
Framework-Vergleich: MLX vs. Ollama Praxistest; Unified Memory: Unified Memory und LLM-Inferenz.
1. System-Kausalmodell und harte Grenzen
Mac Mini M4 (Basis, nicht Pro): 16 GB, 24 GB, 32 GB Unified Memory, 10-GPU-Kerne, Bandbreite ~120 GB/s (M4 Pro ~273 GB/s). Alle tok/s-, swap- und TTFT-Werte unten mappen auf dieses Drei-Schichten-Modell — zuerst „warum“, dann §3–§5 „was passierte“.
M4 lokale LLM-Inferenz: Drei-Schichten-Kausalmodell
| Schicht | Steuert | Kausalmechanismus | Beobachtung hier |
|---|---|---|---|
| L1 Kapazität Memory capacity |
Passt es rein, OOM? | Belegung ≈ Gewichte + KV cache (∝ num_ctx) + OS/Foreground. Über physische RAM → Kompression → swap → Runner killed |
14B @ 16GB OOM; num_ctx=65536 stiller Timeout |
| L2 Bandbreite Memory bandwidth |
sauberer tok/s-Deckel | Decode liest pro Token den vollen Gewichtsstrom; tok/s ≈ effektive Bandbreite ÷ Bytes pro Token. Gleicher Chip, gleiches Modell: L2 setzt baseline ~29 tok/s, nicht die GB-Zahl | 16GB sauber 8B median 28.8; 24GB gleiches Modell 51.2 (§1.4) |
| L3 Druck Pressure / contention |
nichtlinearer Kollaps | wired steigt → compressor aktiv → memorystatus WARN/critical → swapins → GPU wartet auf Seiten → tok/s-Klippe (nichtlinear, §5 Phase 2–3) | Swapins 8421 → 3.4 tok/s; critical @ 14.8GB wired |
Kausalkette (beim Log-Lesen): Config-Änderung → welche Schicht zuerst? Größeres Modell/ctx → L1; gleiche Last 16GB vs 24GB → oft L1-Reserve bestimmt, ob L3 feuert; Warmup −12% → L2 effektive Bandbreite; Ollama ohne Metal → L2-Pfad = CPU.
1.1 L1 Kapazität: Gewichte + KV müssen ins Unified Memory
Inferenz ≈ quantisierte Gewichte + KV-Cache (linear mit num_ctx) + macOS und Vordergrund. L1 nicht voll → L3 bleibt aus — Voraussetzung für baseline 28.8 tok/s. Nach L1-Deckel keine „gleichmäßige“ Verlangsamung, sondern §5 Phase 2/3. Faustregel: modellbezogene Belegung <70% RAM; 16GB mit Xcode + Chrome + Ollama: effektiv oft nur ~10GB+ frei.
1.2 L2 Bandbreite: Deckel im sauberen Zustand
Autoregressive Decode limitiert meist Gewichte von Unified Memory in die GPU-Einheiten. Llama 3.1 8B Q4 ~4.9GB; M4 @ 120 GB/s → ~25–35 tok/s — passt zu median 28.8. Warmup 25.1, Outlier 31.1 = L2-Rauschen (Throttling/GC), kein L3-swap. Siehe §3–§7 raw logs.
1.3 L1-Voraussetzung: Quantisierung entscheidet „passt es“
Ollama-Tags meist Q4 (GGUF, llama.cpp). 8B: Q4_K_M ~5GB, Q8_0 ~8GB — Q8 8B auf 16GB geht, KV-Reserve minimal, L3 leichter getriggert. Standard hier: Q4_K_M.
1.4 Warum 24 GB ein „nichtlinearer Sprung“ ist
24 GB verdoppelt L2 nicht — gleicher M4-Chip, ähnlicher L2-Deckel. 8B median 51.2 vor allem: Gewichte + KV vollständig GPU-freundlich, kein L3-Zwist im Decode; Ollama/Metal nutzt größere Batches und stabilere Buffer. 16GB sauber 8B liegt nahe L1-Kante — ein Chrome-Tab schiebt in Phase 1. 16→24 GB kauft L1-Reserve → L3 später, nicht „+8 GB = +8 tok/s“ linear.
2. Baseline: erster sauberer Lauf
Anker für alle Vergleiche: Mac Mini M4 16GB, nur Terminal + Ollama, Llama 3.1 8B Q4, 512 prompt / 256 gen, temperature=0.2. Maschine m4-16gb-lab-01, macOS 15.4.
| Metrik | 2026-05-28 erste Baseline | Anmerkung |
|---|---|---|
| tok/s (5 runs) | 28.1 / 29.8 / 27.2 / 20.8* / 31.1 | *run4 mit Chrome, ausgeschlossen |
| median / mean | 28.8 / 29.05 | nicht monoton, §3 |
| TTFT Wall-Clock | 1.82 / 2.61 / 1.94 / 2.08 s | run2 Jitter bis 2.61s |
| Swapins | 0 | vm_stat Snapshot |
| Metal | ggml_metal_init: Apple M4 | debug log |
Kein „einmal messen und fertig“, sondern dreiwöchiges Engineering-Log; gleiche Config driftet median 27.9–29.2 über Tage (§6.3).
3. Run log und System-Rohdump
Ungefilterte Lab-Artefakte (keine Zusammenfassung). Vollständiger Benchmark: resources/sample-benchmark-run.log; System: resources/raw-vm-stat-dump.txt; Ollama: resources/ollama-debug-excerpt.log.
3.1 Benchmark-Skript (Auszug)
--- run 2 / 5 --- (machine warm, fan ~4200rpm)
eval_count=256 elapsed=8.6s tok/s=29.8 TTFT_wall=2.61s
--- run 5 / 5 --- (outlier: GC pause mid-decode)
eval_count=256 elapsed=8.0s tok/s=31.1 TTFT_wall=2.08s
median tok/s: 28.8
mean: 29.05
p90: 30.43.2 vm_stat + memorystatus (run 3)
Pages wired down: 201888.
Pages stored in compressor: 94208.
Swapins: 0.
# 14B Fehlsession später am selben Tag:
memorystatus: pressure level 4 (critical)
memorystatus: killing_low_priority_processesVollständiger Dump mit top -l 1 und log show … memorystatus in raw-vm-stat-dump.txt.
3.3 Systemrauschen (kein Modellfaktor)
| Quelle | Beobachtung | tok/s-Effekt |
|---|---|---|
| Warmup / Lüfter 4200rpm | Run nach 20min Dauerlast | 29.8 → 25.1 (~−12%), nicht entfernt |
| TTFT jitter | 1.82 → 2.61 → 1.94 s | Agent erste Runde schwankt |
| memory compressor | 94208 pages compressed | Vorboten swap, noch nutzbar |
| Metal buffer realloc | debug WARN eine Zeile | ein Run −3~5%, nicht fatal |
| Nachmittags-Temperatur | 2026-06-02 14:00 Retest | median 27.9, outlier 24.3 |
3.4 Reproduktion
chmod +x resources/benchmark-m4-mac-mini-ollama.sh
./resources/benchmark-m4-mac-mini-ollama.sh llama3.1:8b
# parallel zweites Terminal empfohlen:
log stream --predicate 'subsystem == "com.apple.memorystatus"' --level debug4. Resource exhaustion taxonomy (Fehler-Taxonomie)
§3 chronologisch; hier nach Erschöpfungstyp — bei jedem Failure fragen: L1, L2 oder L3?
| Typ | Schicht | Symptome | Fall hier | Fix |
|---|---|---|---|---|
| E1 Kapazität erschöpft Capacity exhaustion |
L1 | load OOM, runner killed, Modell passt nicht | qwen2.5:14b @ 16GB → signal: killed (oom?) |
kleineres Modell / RAM auf 24GB |
| E2 Druckkollaps Pressure collapse |
L3 → L2 mitbetroffen | Swapins hoch, tok/s-Klippe, TTFT 5s+ | Swapins 8421 → 11.2→3.4 tok/s | ctx senken / Hintergrund zu / §5 Phase 2–3 |
| E3 Bandbreiten-Pfad degradiert Bandwidth path degradation |
L2 | kein swap, tok/s sehr niedrig; kein Metal | Ollama 0.5.13 ohne ggml_metal_init → 4.2 tok/s |
Ollama upgraden; Metal WARN prüfen |
| E4 Latenz-Failure Latency-only failure |
L1-Grenze + L3-Vorzeichen | lädt, erstes Token 60s+; tok/s ungemessen nutzlos | num_ctx=65536 + 14B @ 16GB |
ctx senken; 24GB gleiche Config TTFT ~2.8s |
| E5 Aggregat-Erschöpfung Aggregate exhaustion |
L1 + L3 | ein Stream OK, Multi-Agent / großes mmap nicht | 5 Agents + 14B; 70B mmap <3 tok/s | Knoten trennen; 70B braucht M4 Pro 48GB+ |
4.1 E2: swap-getriebener Druckkollaps (qwen2.5:14b @ 16GB)
time=2026-05-29T11:03:12 level=WARN msg="model requires more memory than available, offloading to CPU"
time=2026-05-29T11:03:44 level=ERROR msg="llama runner process has terminated: signal: killed (oom?)"
# Kausalität: L1 voll → L3 swap → L2 GPU wartet → E2
# run sequence: 11.2 → 8.4 → 3.4 → 2.9 tok/s
Swapins: 8421 (then > 20k)4.2 E3: Metal-Pfad verloren (Ollama 0.5.13, 2026-04-18)
# entire session: NO ggml_metal_init → L2 path = CPU only
eval rate=4.2 token/s
# fix: upgrade to 0.6.2 → Metal restored, median back to ~294.3 E4: num_ctx 65536 + 14B stiller Timeout
Lädt, erstes Token 60s+ — L1 an KV-Grenze, kein stabiler tok/s-Zustand. 24GB gleiche Config TTFT ~2.8s: laden ≠ täglich nutzbar.
4.4 E5 und weitere Grenzen (Kurz)
- E1+E5: 70B mmap, tok/s < 3 — Kapazität reicht nicht
- E1+E5: 5 parallele Agents + 14B, KV summiert → OOM
- E2-Vorzeichen: Xcode CI + 14B, DerivedData frisst L1 — auslagern
- L2-Rauschen (kein E-Failure): Metal
buffer reallocationWARN, ein Run −3~5%, §3.3
5. Drei-Phasen-Collapse-Modell
§1 L3 als referenzierbare Abstraktion: gleicher M4 16GB, Llama 3.1 8B Q4 — mit steigendem wired memory fällt tok/s nicht linear, sondern in drei Phasen. 14B auf 16GB erreicht Phase 3 schneller — das erklärt „14B langsamer“, nicht nur „mehr Parameter“.
5.1 Phasendefinition (8B Q4, schrittweise Last)
| Phase | memorystatus | wired ca. | 8B tok/s | 14B tok/s | Mechanismus (L) |
|---|---|---|---|---|---|
| Phase 1 Lineare Degradation |
NORMAL | 11.8 → 14.1 GB | 28.8 → 22.1 | — → 6.2 | L1-Reserve schrumpft; L2 dominiert noch, nahezu linear |
| Phase 2 Kontention |
WARN → critical | 14.1 → 14.8 GB | 22.1 → 18.6 | 6.2 → 3.4 | L3 startet: compressor, GPU wartet auf reclaim, steilere Kurve |
| Phase 3 swap-Kollaps |
swap aktiv | 15.2 GB+ | 9.1 → 3.2 | 2.9 | L3 voll: Swapins 8421+, nichtlineare Klippe; E2 |
Merksatz: Phase 1 — kleineres Modell oder Tabs schließen; Phase 2 — num_ctx senken oder RAM; Phase 3 — nur Last/RAM, temperature hilft nicht.
5.2 Mess-Snapshots (phasenübergreifend)
| Zustand | Collapse-Phase | tok/s | TTFT | Swapins |
|---|---|---|---|---|
| saubere Baseline | — (L2 steady) | 28.8 med (28.1–31.1) | ~1.99s | 0 |
| Warmup 20min | — (L2 Rauschen) | 25.1 | 2.4s | 0 |
| Chrome + Xcode | Phase 1 Ende | 20.8 | 2.38s | 0 |
| 16GB + 14B run 1–2 | Phase 2 | 11.2 / 8.4 | ~2.8s | 0→1204 |
| swap aktiv + 14B | Phase 3 | 3.4 → 2.9 | 5.8s | 8421+ |
| 24GB sauber + 8B | — (große L1-Reserve, vor Phase 1) | 51.2 med | ~1.6s | 0 |
5.3 Rohdaten schrittweise Last (16GB, wired + anonymous)
Entspricht Phase 1→3; beim Reproduzieren memorystatus-Phase, nicht nur GB:
| wired + anonymous ca. | memorystatus | Phase | 8B tok/s | 14B tok/s |
|---|---|---|---|---|
| 11.8 GB | NORMAL | — | 28.8 | — |
| 13.2 GB | NORMAL | Phase 1 | 26.4 | 10.8 |
| 14.1 GB | WARN | Phase 1→2 | 22.1 | 6.2 |
| 14.8 GB | critical | Phase 2 | 18.6 | 3.4 |
| 15.2 GB+ | swap aktiv | Phase 3 | 9.1 | 2.9 |
5.4 Warum swap ein nichtlinearer Bruch ist
Phase 1: Decode noch primär L2-Bandbreite; Phase 2: aggressive reclaim + compressor, GPU-Buffer warten; Phase 3: pro Token möglicher page fault aus swap — Latenz µs → ms, tok/s ~20 → ~3 ist Pfadwechsel, kein „20% langsamer“. Swapins 8421 (§4 E2) ist der Phase-3-Fingerabdruck.
6. TTFT, Kontext und Zeit-/Versionsdrift
6.1 TTFT und Agent-Wahrnehmung
| Szenario | TTFT (s) | Anmerkung |
|---|---|---|
| Modell resident | 0.41 / 0.58 / 0.52 | akzeptabel |
| Kaltstart nach pull | 1.82 / 2.61 / 1.94 / 2.08 | system wake jitter |
| swap + 14B | 4.5 / 5.8 / 6.2 | unbrauchbar |
6.2 num_ctx-Dämpfung (8B Q4)
| num_ctx | 16GB tok/s runs | 24GB tok/s runs |
|---|---|---|
| 2048 | 28.1 / 29.8 / 27.2 / 31.1 | 51.2 / 54.6 / 49.8 / 52.1 |
| 8192 | 24.1 / 26.3 / 22.7 | 47.8 / 50.1 / 48.6 |
| 32768 | 14.6 / 13.8 (swap-Rand) | 38.2 / 36.9 |
6.3 Zeitdrift: gleiche Maschine, gleiches Skript, andere Tage
| Datum | Ollama | median tok/s | Run-Spanne | Anmerkung |
|---|---|---|---|---|
| 2026-05-20 | 0.6.1 | 29.2 | 26.8–31.4 | älterer Allocator |
| 2026-05-28 | 0.6.2 | 28.8 | 27.2–31.1 | Baseline dieses Artikels |
| 2026-06-02 | 0.6.2 | 27.9 | 24.3–30.1 | Nachmittag warm, outlier 24.3 |
0.6.1 → 0.6.2 median ~1.4 tok/s Unterschied, kleiner als Tagesvarianz ±12% — Versionsvergleiche brauchen festes Datum und Raumtemperatur.
6.4 Ollama Minor-Versionen (gleiche Maschine, 2026-05-29)
| Version | median tok/s | Metal |
|---|---|---|
| 0.6.1 | 29.2 | OK |
| 0.6.2 | 28.8 | OK; gelegentlich buffer realloc WARN |
| 0.6.3 | 29.6 | OK; weniger realloc WARN |
7. Kontrollexperimente (drei Gegenintuitionen)
7.1 Faire Last: leicht vs. schwer (unterschiedliche Ziele)
„24GB 8B flüssiger als 16GB 14B“ ist kein Qualitäts-Apples-to-apples. Gleiche Wall-Clock für 500 Token:
| Config | Modell | median tok/s | 500 Token ca. | Qualitätsstufe |
|---|---|---|---|---|
| 16GB sauber | gemma3:4b | 39.8 | ~12.6 s | leicht |
| 16GB sauber | llama3.1:8b | 28.8 | ~17.4 s | allgemein |
| 16GB belastet | qwen2.5:14b | 3.4 (nach swap) | ~147 s | hoch, aber gescheitert |
| 24GB sauber | qwen2.5:14b | 15.8 | ~31.6 s | Code-Sweet-Spot |
Bedingte Folgerung: 14B-Qualität → 24GB Pflicht; nur Speed → 16GB + 8B reicht — kein „16GB mit 14B spart Geld“.
7.2 A/B gleiche Maschine: swap off vs. on (8B, §5 Phase 1→3)
| Bedingung | run1 | run2 | run3 |
|---|---|---|---|
| swap off, sauber | 28.1 | 29.8 | 27.2 |
| künstlich bis critical | 18.6 | 9.1 | 3.2 |
7.3 MLX vs. Ollama (gleicher prompt / ctx / decode)
Llama 3.1 8B 4-bit, 512/256, num_ctx=2048, temp=0.2, 16GB sauber:
| Framework | tok/s runs | median | TTFT |
|---|---|---|---|
| Ollama 0.6.2 | 28.1 / 29.8 / 27.2 / 31.1 | 28.8 | 1.82 / 2.61 / 1.94 s |
| mlx-lm 0.22.x | 30.4 / 29.1 / 31.6 / 28.3 | 29.8 | 1.71 / 2.10 / 1.88 s |
MLX ~3–8% schneller, gleiches Run-Jitter; Agent-Lieferung bleibt Ollama HTTP. Tiefer: Schwesterartikel MLX vs. Ollama.
8. M4 Mac Mini LLM-Speicher-Matrix (16GB / 24GB / 32GB gemessen)
Engineering-Urteil aus §1 und §4–§7 (keine Hersteller-Spec).
| Modell (Q4_K_M) | Gewichte ca. | 16GB | 24GB | 32GB |
|---|---|---|---|---|
| Qwen2.5 / Qwen3 7B | ~4.5 GB | ✅ empfohlen | ✅ empfohlen | ✅ empfohlen |
| Llama 3.1 8B | ~4.9 GB | ✅ empfohlen | ✅ empfohlen | ✅ empfohlen |
| DeepSeek-R1-Distill 8B | ~5.5 GB | ✅ empfohlen | ✅ empfohlen | ✅ empfohlen |
| Gemma 3 4B / Phi-4-mini | ~3 GB | ✅ sehr schnell | ✅ sehr schnell | ✅ sehr schnell |
| Qwen2.5-Coder 14B | ~9 GB | ⚠️ Grenze | ✅ empfohlen | ✅ empfohlen |
| Llama 3.1 13B / Phi-4 14B | ~8–9 GB | ⚠️ Grenze | ✅ empfohlen | ✅ empfohlen |
| Qwen2.5 32B | ~20 GB | ❌ | ⚠️ Grenze | ✅ nutzbar |
| Llama 3.1 70B | ~40 GB | ❌ | ❌ | ❌ |
70B braucht M4 Pro 48GB+, siehe M4 Pro lokale LLM-Leitfaden.
9. Modelle nach Szenario
9.1 Alltag: Dialog, E-Mail-Zusammenfassung
16GB: qwen2.5:7b oder qwen3:8b (wenn im Ollama-Katalog). 24GB: qwen2.5:14b für komplexere Anweisungen.
9.2 Programmieren und Claude Code lokaler Agent
Agent braucht stabiles HTTP und langen Kontext; Ollama API mit einem serve für Claude Code. 16GB: qwen2.5-coder:7b; 24GB: qwen2.5-coder:14b. Setup und API-Kosten: M4 Mac Mini lokaler KI-Agent Praxistest.
9.3 Reasoning / Mathe / Chain-of-Thought
DeepSeek-R1-Distill stark in 8B: deepseek-r1:8b (16GB) oder deepseek-r1:14b (24GB). R1 liefert lange Denkketten — gleiche tok/s, längere Wall-Clock: Modellverhalten, kein Mac-Defekt.
9.4 Mehrsprachig und Open Source
Llama 3.1 8B/13B: beste Modelfile-/Tool-Doku. Bestehende Llama-RAG-Pipeline → Llama reduziert Migrationskosten.
9.5 Ultraleichter Assistent
gemma3:4b sauber: 38.2 / 41.0 / 36.7 / 39.6 tok/s (median 39.4).
10. Ollama Minimal-Setup
Auf frischem Mac Mini M4 verifiziert; Ollama nutzt Metal automatisch.
10.1 Installation
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama run qwen2.5:7b "Erkläre in drei Sätzen, warum Unified Memory für lokale LLMs wichtig ist"Erster run pullt ~4–5GB — SSD >20GB frei. ggml_metal_init im Log = Metal aktiv.
10.2 Pull nach RAM-Tier
# —— 16GB Mac Mini M4 ——
ollama pull qwen2.5:7b
ollama pull qwen2.5-coder:7b
ollama pull llama3.1:8b
ollama pull deepseek-r1:8b
# —— 24GB Mac Mini M4 ——
ollama pull qwen2.5:14b
ollama pull qwen2.5-coder:14b
ollama pull llama3.1:13b
# —— 32GB: optional 32B (langsamer) ——
ollama pull qwen2.5:32b10.3 Team-API
OLLAMA_HOST=0.0.0.0:11434 ollama serveClients auf http://<mac-ip>:11434. Produktion: Firewall oder Tailscale — 11434 nicht öffentlich.
10.4 Benchmark vs. sample log
ollama pull llama3.1:8b
./resources/benchmark-m4-mac-mini-ollama.sh llama3.1:8b 2>&1 | tee my-run.log
diff -u resources/sample-benchmark-run.log my-run.log11. 16 GB → 24 GB → M4 Pro
| Ziel | Empfehlung | Begründung |
|---|---|---|
| Privat, 7B Chat / leichtes Coding | M4 16GB | günstigster Einstieg, 8B Q4 vollständig |
| Claude Code Agent, 14B Code, kleines Team | M4 24GB | 14B steady + API-Reserve, bestes Preis/Leistung |
| lokales 32B, langer ctx-Experiment | M4 32GB oder M4 Pro 48GB | 32GB Basis langsam; Pro mehr Bandbreite |
| 70B, schnelles 32B, Multi-Modell | M4 Pro 48GB+ | RAM und Bandbreite, Pro-Artikel |
Unsicher: eine Woche sauber benchmarken, swap-Peak und §5-Collapse notieren, dann 24GB oder Pro — günstiger als blind Top-Spec.
12. Experimentelle Varianz
Gleiche Config, gleiches Skript — median kann ±12% über Tage driften; normal für lokale LLM-Benchmarks.
| Variable | Spanne | Prinzip |
|---|---|---|
| Datum / Temperatur | median 27.9–29.2 (8B 16GB) | Intervall + raw runs, kein Einzelpunkt |
| Ollama 0.6.1→0.6.3 | ~±1 tok/s | kleiner als Tagesvarianz, Version loggen |
| Warmup / Lüfter | 29.8 → 25.1 (−12%) | im Log behalten |
| GC / Metal realloc | outlier 31.1 oder −5% | p90 melden, nicht nur median |
| Chrome im Hintergrund | 20.8 tok/s | eigene Zeile, nicht in Baseline |
Repro >15% Abweichung: Ollama-Version, num_ctx, temperature, swap, Warmup angleichen. Raw: sample-benchmark-run.log, raw-vm-stat-dump.txt, ollama-debug-excerpt.log.
Wir behalten Warmup (25.1) und Nachmittags-outlier (24.3) — nur „schöner median“ täuscht über Rauschen vs. Fehlkonfiguration. Grenze Lab vs. Marketing-Review.
FAQ
Kann ein M4 Mac Mini mit 16 GB 70B ausführen?
Nein. 70B Q4 ~40GB+, kein physischer RAM. mmap-Lösungen nutzen SSD, tok/s meist <3 — unpraktisch.
Wie viel schneller ist 24 GB als 16 GB?
Gleiches 8B sauber: 16GB median 28.8, 24GB 51.2 tok/s. Mit Chrome fällt 16GB auf 20.8 — Hintergrund schlägt oft zuerst zu.
Ollama oder MLX?
API, Claude Code, Modellwechsel → Ollama. Python-Benchmarks → MLX. Beides installierbar; nicht zwei große Modelle dauerhaft resident.
Q4 oder Q8?
16GB: Q4_K_M. 24GB 8B: Q8 testen; 14B Q4. Q8-14B auf 24GB nahe Limit.
Woran erkenne ich swap?
Aktivitätsanzeige Speicher „Auslagerung“; oder sysctl vm.swapusage. Swapins >0 + tok/s Phase 3 = E2 — Modell/RAM, nicht Tuning.
Warum ist 24 GB so viel schneller?
Keine doppelte Bandbreite — mehr L1, L3 aus: ~28.8 vs ~51.2. §1.4, §5.2.
Basis-M4 vs. M4 Pro?
8B Q4 sauber: M4 24GB median 51.2, M4 Pro 48GB 75.9 (gleiches Skript). Pro stärker bei Batch-Concurrency; Solo-Agent oft ohne Pro.
Agent: tok/s oder TTFT?
Erste Runde TTFT (§6.1); lange Antwort tok/s. Unter swap TTFT 1.82s → 5.8s — Speicher zuerst.
Team ohne physischen Mac?
Ollama auf macOS-Host, LAN-Zugriff — gleiche Befehle. Remote-Collapse optional über Macstripe (§ disclosure), nicht Voraussetzung der Zahlen.
Fazit
M4 Mac Mini lokale LLMs: L1 Kapazität + L2 Bandbreite + L3 Druck: 16GB Komfort 7B–8B (L2 ~29 tok/s); 24GB steady 14B (~16 tok/s); 32GB für 32B; 70B M4 Pro (E1). Bedingt: Solo-Agent 7B–14B — 24GB mit 8B oft flüssiger als 16GB mit 14B (§7.1). Multi-Batch → Knoten oder Pro. Repro mit §1 + §3 raw + §5 Phase 1–3 — nicht nur median kopieren.
Quellen
- Ollama Docs — Installation, API, Metal
- Apple Metal — GPU-Inferenz
- Meta Llama 3.1 — Specs und Lizenz
- Qwen2.5 — 7B/14B Grenzen
- Apple MLX — Framework-Vergleich
- llama.cpp — GGUF unter Ollama
Dreiwöchiges Engineering-Log. Raw:
resources/sample-benchmark-run.logresources/raw-vm-stat-dump.txtresources/ollama-debug-excerpt.logresources/benchmark-m4-mac-mini-ollama.sh
Experimentumgebung (Infrastructure disclosure)
Benchmarks auf physischen Mac Mini M4: teils Macstripe-Exklusivknoten (ohne VM-Contention), teils Lab-Schreibtisch; macOS 15.4, Ollama 0.6.2. Macstripe vermietet M4 Mac Mini remote; Schlussfolgerungen unabhängig vom Anbieter — eigene Hardware reproduzierbar.
Remote-macOS für §5-Collapse und §4-Fehler: optional Macstripe Startseite — Infrastruktur, keine Bedingung für die Messwerte.
Weiterlesen (Themencluster)
Dieser Artikel: welche Modelle + Lab-Rohdaten; Schwesterstücke zu Framework, Pro und Agent.
- M4 Mac Mini: 7B vs. 14B — Alltagsunterschied (Spoke: TL;DR + TTFT)
- MLX vs. Ollama: Apple Silicon Framework-Praxistest (Technik)
- M4 Pro lokale LLMs: Benchmarks und Deployment (70B / 32B)
- M4 Mac Mini lokaler KI-Agent: Claude Code + Ollama (Praxis)
- Unified Memory und LLM-Inferenz (Prinzip)