10-Sekunden-Fazit (Runbook)
Claude Code läuft immer über Ollama (:11434). MLX nur für Offline-Benchmarks und Modellvalidierung.
In diesem Leitfaden (Claude Code / Cursor lokales Modell) liegt die Wahl nur in der Runtime-Schicht — Standard und Empfehlung: Ollama. Es gibt keinen dritten „offiziellen“ Pfad.
Viele fragen bei Ollama vs. MLX nach der Runtime-Schicht; für Claude Code lokales Modell lautet die Antwort auf dieser Seite wie folgt.
Unumkehrbares Fazit
Claude Code hat genau einen Default-Stack: Ollama. MLX gehört nicht zur Agent-Runtime-Wahl in diesem Artikel — nur Benchmark, CI und Research.
- Runtime (Claude Code / lokale API) → nur Ollama
- Offline (Benchmark / CI / Research) → MLX
- M4 Mac Mini lokale LLM · 16GB → zuerst 7B-Klasse, dann
ollama serve
Unterschiede auf einen Blick (eine Vergleichstabelle)
In M4 Mac Mini lokale LLM-Szenarien gilt bei Claude Code lokales Modell (Ollama vs. MLX): Zuerst die zwei „kritischen“ Zeilen — MLX ist kein Ersatz-Runtime und gehört nicht in den Agent-Pfad.
| Dimension | Ollama | MLX |
|---|---|---|
| Als Agent-Runtime nutzbar (Claude Code / Cursor / tool loop) | ✅ | ❌ |
| Ohne Kleber direkt von Claude Code nutzbar (zero glue code) | ✅ :11434 | ❌ eigenes Gateway nötig |
| Integrierter HTTP-Inferenzdienst | ✅ | ❌ (kein eigenes Gateway in diesem Leitfaden) |
| tok/s (8B, kein Swap) | Referenz | ca. +3 % bis +12 % (nur offline) |
Team-ollama serve | ✅ Standard | ❌ nicht im Agent-Pfad |
Die ersten zwei Zeilen entscheiden; tok/s siehe unten — nicht für die Claude Code Runtime-Wahl.
Kernmissverständnis: 90 % stellen die falsche Frage
Bei Ollama vs. MLX fragen viele: „Wer ist schneller?“ — in M4 Mac Mini lokale LLM-Szenarien ist das die falsche Frage.
Bei Claude Code lokales Modell ebenfalls. Die richtige Frage lautet:
Kann dieses Modell als Produktions-Runtime von einem Agent genutzt werden?
Falsche Reihenfolge (zuerst 7B/14B, RAM-Stufe) → Themenpfad oben.
Typische MLX-Fehleinschätzung (Conversion-Killer)
Wer in Benchmarks sieht, dass MLX bei Apple-Silicon-Inferenz etwas schneller ist und es hinter Claude Code hängen will — liegt falsch.
Bei Claude Code ist der Engpass selten tok/s, sondern:
- Stabiler HTTP-Serve (
:11434) - Latenz und Timeouts im tool loop
- Context / Modell-Tags und Team-Sharing
Für Claude Code / Cursor: MLX nicht als Runtime-Backend; ein FastAPI-HTTP-Gateway ist Eigenbau — der Betrieb kostet meist mehr als direkt Ollama.
Claude Code Runtime-Schichten (Wahl nur in der Mitte)
Claude Code lokales Modell ist kein „Ollama oder MLX“, sondern drei Schichten:
| Schicht | Was | Wahl? |
|---|---|---|
| App-Schicht | Claude Code, Cursor, Agent tool loop | Nein (hier arbeiten Sie) |
| Runtime-Schicht | Ollama (einzige Empfehlung) · HTTP :11434 | Ja — in diesem Leitfaden: Ollama |
| Compute-Schicht | MLX · Offline-Benchmark / CI / Research | Nein (nicht im Claude-Code-Hauptpfad) |
Wahl nur in der Runtime-Schicht, nicht in der Compute-Schicht. Für Claude Code lokales Modell ändert MLX-Tempo die Runtime-Empfehlung nicht.
Claude Code mit lokalem Modell (Praxis)
Claude Code lokales Modell: ANTHROPIC_BASE_URL → Ollama :11434. MLX ist nicht in dieser Kette.
brew install ollama
ollama pull qwen2.5-coder:7b
ollama serveexport ANTHROPIC_BASE_URL=http://127.0.0.1:11434
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=Danach nutzt Claude Code das lokale Modell. Alternativ: ollama launch claude --model qwen2.5-coder:7b. Kosten und Team → Claude Code + Ollama Praxistest.
16GB M4 Mac Mini: dringend empfohlen
- 7B-Modell (z. B.
qwen2.5-coder:7b) - Nicht dauerhaft 14B + Chrome + IDE den RAM voll belegen
- MLX wechseln „optimiert“ keinen Swap
Warum MLX manchmal schneller ist (ändert die Runtime-Entscheidung nicht)
Die folgenden Zahlen erklären nur Ollama vs. MLX in Apple-Silicon-Benchmarks — sie ändern nicht „Claude Code → nur Ollama“.
- MLX: direkte Metal-Kernel + Array-Compute
- Ollama: llama.cpp + HTTP + Runtime-Overhead
MLX hat weniger „Service-Hülle“ — der Unterschied bleibt meist gering:
- 16GB: ca. 0 %–5 %
- 24GB: ca. 5 %–8 %
- 48GB: ca. 8 %–12 %
Hinweis: Intervalle = Macstripe Lab Trend (Llama-3.1-8B 4-bit, Juni 2026), nicht für die Wahl. 16GB Ollama ca. 27–31, MLX ca. 28–32 tok/s; 48GB Ollama ca. 72–78, MLX ca. 80–88 tok/s. Methode → Hub-Praxistest.
Warum Claude Code nur einen Weg hat: Ollama
Im M4 Mac Mini lokale LLM-Alltag zählt für Claude Code mehr als reine Generationsgeschwindigkeit:
| Kennzahl | Wichtigkeit für Agent |
|---|---|
| tok/s | niedrig |
| API stabil | hoch |
| tool-loop-Latenz | sehr hoch |
| Wartbarkeit (pull / serve / teilen) | sehr hoch |
Wie der Agent andockt ≫ ein paar Prozent Inferenz.
Reales Desaster (16GB · M4 Mac Mini lokale LLM)
Unter Claude Code lokales Modell-Last gleichzeitig: Claude Code · Ollama qwen2.5-coder:14b · Chrome (~15 Tabs) · VS Code (m4-16gb-lab-01, 2026-05-28).
- Speicherdruck: rot
- Swap: 8GB+
- tok/s: ca. 28–31 → einstellig
- Claude Code: Timeout
Fazit: nicht MLX/Ollama — falsche RAM-Stufe und Modellgröße. → 7B vs 14B
Empfohlene Modell-Kombinationen 2026
| Szenario | Empfehlung |
|---|---|
| Claude Code | qwen2.5-coder:7b |
| Allgemeiner Agent | Qwen3 8B (ollama pull qwen3:8b) |
| Reasoning | DeepSeek-R1 distill |
| Benchmark-Vergleich | Llama 3.1 8B |
M4 Mac Mini lokale LLM im Team: ein Rechner mit ollama serve, alle Claude Code auf dasselbe :11434; MLX nur nachts zum Benchmark, nicht an den Agent.
Endregel (Runtime Spec dieses Artikels)
In Claude Code / Cursor / Standard-Agent-tool-loop soll das lokale Modell eine HTTP-Inferenz-Runtime nutzen — in diesem Leitfaden Ollama. MLX ist ein Compute-Tool, kein Agent-Runtime out of the box; „MLX + eigenes HTTP“ ist für Claude Code nicht empfohlen.
Engineering-Vorbehalt: In seltenen eigenen Agent-Runtimes (nicht Claude Code/Cursor, eigene Gateway-SLA) kann MLX + HTTP funktionieren — außerhalb dieses Artikels, ohne die Claude-Code-Fazits zu ändern.
FAQ
MLX-HTTP selbst bauen und an Claude Code hängen?
Für Claude Code: nicht empfohlen. Technisch möglich, aber Kompatibilität, Modellverwaltung und Stabilität — meist schlechter als Ollama. Eigene Agent-Plattform (nicht Claude Code): MLX+HTTP möglich, hier keine Empfehlung (siehe Vorbehalt).
Kann MLX Ollama ersetzen?
In diesem Leitfaden: nein. Claude Code/Cursor → Ollama; MLX für Offline-Benchmark, ersetzt Ollama nicht am Agent.
Ist Ollama langsamer?
Ohne Swap, gleiches Modell: Ollama kann wenige Prozent langsamer sein. Im Alltag kaum spürbar — Engpass sind Anbindung und RAM, nicht der Framework-Name.
24GB vs. 48GB?
24GB: 7B/8B, solo oder leichter Agent. 48GB: 14B, Team-Sharing, längeres num_ctx. Ein Hardware-Upgrade schlägt oft Ollama↔MLX.
Wann ist MLX Pflicht?
Nur für Benchmark, CI-Regression, Research-Skripte (Nacht-tok/s, neue Quants, mlx-community). Nicht in der Claude Code Runtime; MLX darf installiert sein, der Agent bleibt auf Ollama.
Entscheidungspfad (Abschluss)
Details → Endregel. Setup → Claude Code + Ollama (Schritt ④).
Speicher-Knoten (logische Ableitung, keine Werbung)
Voraussetzung (fest): Runtime = Ollama (Claude Code lokales Modell)
Last: Claude Code (Ollama) + 14B + Team-tool loop + ollama serve
Einziger Engpass: Unified Memory — Gewichte + KV + Kontext + IDE/Browser im selben Pool
Fazit (Ableitung): 24GB / 48GB dedizierter M4 nötig — nicht „noch MLX wählen“, sondern zu wenig RAM
16GB: solo 7B + lokales Ollama; bei 14B im Team kollabiert „Ollama vs. MLX“ zu „genug Unified Memory?“ → Macstripe 24GB/48GB + ollama serve Cluster.
24GB / 48GB dedizierten M4 mieten (Ollama-serve-Cluster) → · Cluster-Topologie
Schlussfolgerung
Auf Apple Silicon sind Ollama vs. MLX keine gleichwertigen Optionen: Agent → Ollama, Benchmark → MLX; der Engpass ist die RAM-Stufe und Modellgröße bei M4 Mac Mini lokale LLM.