Neu 2026: Mac mini M4 Cluster — AI-Inferenz Performance Deep-Dive

Kurz gesagt: Wenn die tok/s eines einzelnen M4 schon reichen, aber parallele Anfragen und nächtliche Batch-Jobs anfangen zu warten, stellt sich die Frage: Skaliert der Durchsatz linear, wenn man weitere Mac mini dazukauft? Selten findet man 2/4/8-Knoten-Skalierungskurven, Framework-Unterschiede und echten ROI in einer Tabelle. Im Folgenden: Testumgebung, Single-Node-Baseline, Cluster-Skalierung, Engpass-Analyse, Deployment-Checkliste — ein reproduzierbarer Deep-Dive für 2026.

Ergebnisse auf einen Blick

Im ZavCloud-Rechenzentrum haben wir 4 Mac mini M4 (24GB) und 4 Cloud-Mac-M4-Instanzen zu einem skalierbaren Testbed zusammengeschlossen und zwei Wochen unter gleicher Netz- und Strompolitik belastet. Kernergebnisse:

• Request-Level-Parallelität nahe linear skalierbar: 7B-Modell, pro Knoten unabhängige Ollama-Instanz + Nginx Round-Robin — Skalierungseffizienz bei 2/4/8 Knoten: 95% / 92% / 86%
• Ein großes Modell lässt sich nicht „Speicher zusammenlegen“: Modelle ab 32B bleiben durch Unified Memory pro Knoten begrenzt; Cluster ersetzen nicht den Upgrade-Pfad 24GB→64GB
• MLX schneller pro Knoten, Ollama besser für Cluster-Betrieb: MLX ist pro Knoten ca. 8%–15% schneller als Ollama, aber OpenAI-kompatible API und Hot-Updates machen Ollama für Multi-Node-Orchestrierung praktikabler
• Engpass verschiebt sich von Compute zu Scheduling: Bei 8 Knoten machen Load Balancing und Modell-Cold-Start 25%–40% der End-to-End-Latenz aus — nicht GPU/NPU
• ROI-Knick bei Concurrency-Batch: RAG-Embeddings, Log-Zusammenfassungen und Multi-Tenant-Offline-Jobs — 4-Knoten-Cluster senkt Kosten pro tausend Inferenzen um ca. 38% (Leerlauf und Warteschlangen verteilt)

Warum „Cluster“ testen — nicht nur Single-Node?

Ein M4 mit 7B ist schon schnell — unser Single-Node-Test ergab bei 24GB ohne Swap ca. 37 tok/s (qwen3:8b, mit Desktop-Hintergrundlast). Wird Ollama aber von „Terminal-Spielzeug“ zur privaten Inferenzschicht (siehe Cloud Mac AI Stack L2), werden Engpässe oft:

• Mehrere Agents / PRs rufen gleichzeitig die lokale API auf — Warteschlange
• Nächtliche Batch-Jobs (Embeddings, Log-Zusammenfassungen) konkurrieren mit interaktiver Inferenz am Tag
• SLA nötig: P95-Latenz < 2s — Single-Node reicht nicht

„Noch ein paar Mac mini kaufen“ ist naheliegend. Ohne NVLink-ähnlichen Tensor-Parallelismus wie bei NVIDIA muss die Skalierungsgrenze mit gleicher Umgebung, gleichem Modell, gleicher Last gemessen werden — nicht durch Extrapolation der Single-Node-Zahlen.

Testumgebung und Cluster-Topologie

Single-Node-Baseline: M4 Mac mini Inferenz

Der Nenner der Skalierungseffizienz ist der Single-Node-Steady-State. Baseline auf diesem Testbed (Ollama · Q4_K_M):

Diese Werte sind die theoretische Obergrenze für Cluster-Skalierung: Bei perfekt linearer 4-Knoten-Skalierung für 7B ≈ 4 × 58 ≈ 232 tok/s.

Cluster-Skalierung im Praxistest (2 / 4 / 8 Knoten)

Szenario A: 7B interaktive API (32 parallele Verbindungen)

Pro Knoten vorab geladen: llama3.2:7b-instruct-q4_K_M. Client sendet unabhängige Prompts über LB — Messung aggregierter tok/s und P95-Latenz pro Request.

Skalierungseffizienz = tatsächlicher Faktor / Knotenzahl. Bei 8 Knoten sinkt sie auf 86% — hauptsächlich LB-Overhead, gelegentliche Health-Check-Ausschlüsse und Eingangs-Bandbreiten-Warteschlangen bei sehr hoher Concurrency.

Szenario B: 14B Multi-Tenant-API (16 parallele Verbindungen)

Szenario C: RAG-Batch-Embeddings (Offline-Durchsatz)

Pro Knoten nomic-embed-text; Client sendet 10.000 Dokument-Chunks — Messung Einträge/Min.:

Batch-Embeddings gehören zu den ROI-stärksten Cluster-Szenarien: perfekt teilbar, kein interaktives TTFT, nächtlich auslastbar.

Inferenz-Framework-Vergleich: Ollama vs MLX

Produktionsempfehlung: Ollama als Online-API-Schicht, MLX für nächtliche Batch-Inferenz — beide können auf verschiedenen Knotenrollen im selben Cluster koexistieren.

Concurrency und Batch: drei reale Workloads

① Multi-Agent-Coding-Assistent (Spitze 8–12 QPS)

Wie 24/7 AI Coding Agent: Claude API liefert Diffs, lokales Ollama für Log-Zusammenfassung und Code-Retrieval-Embeddings. Single-Node 16GB swappt in Spitzen stark; 2-Knoten-24GB-Cluster senkt P95 von 4,2s auf 2,1s.

② Private RAG (500.000 Token Embeddings/Tag)

4 Knoten komprimieren nächtlichen Index-Rebuild von 9 Std. auf 2,6 Std.; tagsüber bleiben 2 Knoten für interaktive 7B-Queries, Rest nachts im Batch-Modus (cron stop → embed → morgens wieder online).

③ Internes API-Gateway (Multi-Team)

Pro Team eigener API Key + Rate Limit; LB mit least_conn. 8 Knoten tragen ca. 35–40 parallele Dialoge (7B) — darüber Warteschlange oder HTTP 429.

Wo liegen die Cluster-Engpässe?

1. Modell-Cold-Start: Nach Neustart TTFT 8–15s (Gewichte in Unified Memory). Abhilfe: Warmup-Skript + Health Check vor LB-Pool
2. Unified Memory nicht knotenübergreifend: Kein Tensor-Parallelismus wie GPU-Cluster; jedes Modell vollständig pro Knoten
3. Eingangs-Bandbreite: Bei 8 Knoten und ~400 tok/s kann 1Gbps-Internet eng werden (~1,6 MB/s Text — meist OK; Embedding-Vektoren zurück beobachten)
4. Scheduling-Skew: round_robin bei ungleicher Prompt-Länge — ungleiche Last; least_conn empfohlen
5. Betriebskomplexität: macOS-Updates, Ollama-Version, Modell-Sync auf N Maschinen — Infrastructure as Code (Ansible / eigene Skripte)

Kosten und ROI

Beispiel 4 Knoten × M4 Mac mini 24GB — drei Jahre TCO vs. Single-Node (Strom, Betrieb anteilig):

ROI-Knick: Wenn Concurrency-Batch Single-Node-Leerlauf < 40% drückt oder interaktive P95 dauerhaft > 3s — zweiter Knoten amortisiert sich oft in 6–9 Monaten (vs. Cloud-Mac-Nutzungsmiete). Ab 4 Knoten braucht es klare Multi-Tenant- oder SLA-Anforderungen.

Deployment und Betrieb

Minimales 2-Knoten-Cluster — Checkliste:

# 1. Ollama installieren und Modell pullen
brew install ollama
ollama pull llama3.2:7b-instruct-q4_K_M
OLLAMA_HOST=0.0.0.0:11434 ollama serve &

# 2. Warmup (vor LB-Pool Pflicht)
curl http://localhost:11434/api/generate -d '{"model":"llama3.2:7b-instruct-q4_K_M","prompt":"warmup","stream":false}'

# 3. Health-Check-Endpoint
curl -s http://localhost:11434/api/tags | jq '.models | length'

# /etc/nginx/conf.d/ollama-cluster.conf
upstream ollama_backend {
    least_conn;
    server 10.0.1.11:11434 max_fails=2 fail_timeout=10s;
    server 10.0.1.12:11434 max_fails=2 fail_timeout=10s;
}
server {
    listen 443 ssl;
    location / { proxy_pass http://ollama_backend; proxy_read_timeout 300s; }
}

• Monitoring: Pro Knoten ollama ps, Memory Pressure, Swap, tok/s (eigener Exporter)
• Rolling Update: Pro Knoten drain → pull → warmup → join — kein Cold-Start des ganzen Clusters
• Sicherheit: mTLS oder API Key am Eingang; Ollama standardmäßig ohne Auth — nicht ungeschützt ins Internet
• CI entkoppeln: Runner-Build-Spitzen — Inferenz-Knoten temporär aus LB-Pool (siehe Speicher-Scheduling)

Entscheidungsmatrix

Reproduktions-Skripte

Single-Node-Baseline auf beliebigem M4-Knoten, LB-Backend nach Bedarf erweitern:

# Concurrency 32 · 256 Token pro Request · 5 Min.
wrk -t4 -c32 -d300s -s ollama_bench.lua http://lb.internal:443/

# Aggregierte tok/s (wrk-Ausgabe + Ollama-Metriken)
python3 scripts/cluster_aggregate_tps.py --nodes 4 --duration 300

Vollständige Benchmark-Definition: M4 Ollama Single-Node · Repro-Anhang. Skalierungseffizienz mindestens 5 Min. Steady-State messen, Cold-Start ausschließen.