Verdict en 10 secondes (runbook)
Claude Code passe toujours par Ollama (:11434). MLX uniquement pour benchmarks hors ligne et validation de modèles.
Dans ce guide (Claude Code / Cursor modèle local), le choix se fait uniquement au niveau runtime — par défaut et recommandé : Ollama. Pas de troisième « chemin officiel ».
Beaucoup comparent Ollama vs MLX au niveau runtime ; pour Claude Code modèle local, la réponse de cette page est la suivante.
Conclusion verrouillée
Claude Code n'a qu'une pile par défaut : Ollama. MLX n'entre pas dans le choix runtime Agent de cet article — seulement benchmark, CI et recherche.
- Runtime (Claude Code / API locale) → Ollama seulement
- Hors ligne (benchmark / CI / recherche) → MLX
- LLM local Mac Mini M4 · 16GB → d'abord la classe 7B, puis
ollama serve
Différences en un coup d'œil (table unique)
En LLM local sur Mac Mini M4, pour Claude Code modèle local (Ollama vs MLX), regardez d'abord les deux lignes « critiques » — MLX n'est pas un runtime de secours : il ne doit pas être sur le chemin Agent.
| Dimension | Ollama | MLX |
|---|---|---|
| Peut servir de runtime Agent (Claude Code / Cursor / tool loop) | ✅ | ❌ |
| Utilisable par Claude Code sans glue (zero glue code) | ✅ :11434 | ❌ passerelle maison obligatoire |
| Service HTTP d'inférence intégré | ✅ | ❌ (pas de passerelle maison dans ce guide) |
| tok/s (8B, sans swap) | Référence | env. +3 % à +12 % (hors ligne seulement) |
Équipe ollama serve | ✅ standard | ❌ hors chemin Agent |
Les deux premières lignes tranchent ; tok/s voir ci-dessous — hors choix runtime Claude Code.
Idée reçue : 90 % posent la mauvaise question
Sur Ollama vs MLX, on demande : « lequel est plus rapide ? » — en LLM local Mac Mini M4, c'est la mauvaise question.
Idem pour Claude Code modèle local. La bonne question :
Ce modèle peut-il servir de runtime de production pour un Agent ?
Mauvais ordre (7B/14B, palier RAM d'abord) → parcours en tête d'article.
Erreur MLX la plus fréquente (point de conversion)
Voir MLX plus rapide sur Apple Silicon en benchmark et le brancher derrière Claude Code — c'est faux.
Pour Claude Code, le goulot n'est rarement le tok/s :
- HTTP serve stable (
:11434) - Latence et timeouts en tool loop
- Gestion contexte / tags modèle et partage équipe
Pour Claude Code / Cursor : MLX pas comme backend runtime ; passerelle FastAPI maison = coût ops souvent supérieur à Ollama direct.
Couches runtime Claude Code (choix au milieu seulement)
Claude Code modèle local : pas « Ollama ou MLX », mais trois couches :
| Couche | Quoi | Choix ? |
|---|---|---|
| Application | Claude Code, Cursor, tool loop Agent | Non (vous travaillez ici) |
| Runtime | Ollama (seule reco) · HTTP :11434 | Oui — verrouillé Ollama |
| Calcul | MLX · benchmark hors ligne / CI / recherche | Non (hors chemin principal Claude Code) |
Le choix est au runtime, pas au calcul. Pour Claude Code modèle local, MLX plus rapide ne change pas la reco runtime.
Brancher Claude Code au modèle local (pratique)
Claude Code modèle local : ANTHROPIC_BASE_URL → Ollama :11434. MLX hors de cette chaîne.
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=Claude Code utilise alors le modèle local. Ou ollama launch claude --model qwen2.5-coder:7b. Coûts & équipe → test Claude Code + Ollama.
Mac Mini M4 16GB : fortement recommandé
- Modèle 7B (ex.
qwen2.5-coder:7b) - Ne pas saturer la RAM avec 14B + Chrome + IDE
- Passer à MLX ne « répare » pas le swap
Pourquoi MLX est parfois plus rapide (ne change pas le runtime)
Les chiffres expliquent Ollama vs MLX en bench Apple Silicon — ils ne changent pas « Claude Code → Ollama seul ».
- MLX : kernels Metal directs + calcul array
- Ollama : llama.cpp + HTTP + overhead service
MLX a moins de « coquille service » — écart souvent modeste :
- 16GB : env. 0 %–5 %
- 24GB : env. 5 %–8 %
- 48GB : env. 8 %–12 %
Note : fourchettes = tendance Macstripe Lab (Llama-3.1-8B 4-bit, juin 2026), pas pour choisir. 16GB Ollama env. 27–31, MLX env. 28–32 tok/s ; 48GB Ollama env. 72–78, MLX env. 80–88 tok/s. Méthode → hub labo.
Pourquoi Claude Code n'a qu'un chemin : Ollama
Au quotidien LLM local Mac Mini M4, Claude Code ne regarde pas que la vitesse de génération :
| Indicateur | Importance Agent |
|---|---|
| tok/s | faible |
| API stable | élevée |
| latence tool loop | très élevée |
| maintenabilité (pull / serve / partage) | très élevée |
Comment l'Agent se branche ≫ quelques points d'inférence.
Échec réel (16GB · LLM local Mac Mini M4)
Sous charge Claude Code modèle local : Claude Code · Ollama qwen2.5-coder:14b · Chrome (~15 onglets) · VS Code (m4-16gb-lab-01, 2026-05-28).
- Pression mémoire : rouge
- Swap : 8GB+
- tok/s : env. 28–31 → chiffres unitaires
- Claude Code : timeout
Conclusion : pas MLX/Ollama — mauvais palier RAM et taille de modèle. → 7B vs 14B
Combinaisons de modèles 2026
| Scénario | Recommandation |
|---|---|
| Claude Code | qwen2.5-coder:7b |
| Agent général | Qwen3 8B (ollama pull qwen3:8b) |
| Raisonnement | DeepSeek-R1 distill |
| Référence bench | Llama 3.1 8B |
LLM local Mac Mini M4 en équipe : une machine ollama serve, tous les Claude Code sur le même :11434 ; MLX la nuit pour bench, pas l'Agent.
Règle finale (spec runtime de cet article)
Dans Claude Code / Cursor / tool loop Agent standard, le modèle local passe par une runtime HTTP — ici Ollama. MLX = outil de calcul, pas runtime Agent clé en main ; « MLX + HTTP maison » n'est pas recommandé pour Claude Code.
Clause ingénierie : runtime Agent maison (hors Claude Code/Cursor, SLA passerelle) : MLX + HTTP possible — hors périmètre, sans changer la conclusion Claude Code.
FAQ
HTTP MLX maison pour Claude Code ?
Pour Claude Code : déconseillé. Faisable, mais compatibilité, modèles, stabilité — souvent pire qu'Ollama. Plateforme Agent maison : MLX+HTTP possible, pas reco ici (voir clause).
MLX remplace Ollama ?
Dans ce guide : non. Claude Code/Cursor → Ollama ; MLX pour bench hors ligne, ne remplace pas Ollama côté Agent.
Ollama plus lent ?
Sans swap, même modèle : Ollama peut être quelques points plus lent. Au quotidien à peine visible — goulot = branchement et RAM.
24GB vs 48GB ?
24GB : 7B/8B, solo ou Agent léger. 48GB : 14B, partage équipe, num_ctx plus long. Le matériel bat souvent Ollama↔MLX.
Quand MLX est-il obligatoire ?
Benchmark, régression CI, scripts recherche seulement. Pas dans le runtime Claude Code ; MLX installé, Agent toujours sur Ollama.
Chemin de décision (synthèse)
Détails → règle finale. Config → Claude Code + Ollama (étape ④).
Nœud mémoire (déduction, pas opinion)
Prémisse (verrouillée) : runtime = Ollama (spec Claude Code modèle local)
Charge : Claude Code (Ollama) + 14B + tool loop équipe + ollama serve
Goulot unique : mémoire unifiée — poids + KV + contexte + IDE/navigateur
Conclusion (déduite) : M4 dédié 24GB / 48GB requis — pas « encore MLX », mais RAM insuffisante
16GB : solo 7B + Ollama local ; dès 14B partagé, « Ollama vs MLX » → « assez de mémoire unifiée ? » → Macstripe 24GB/48GB + cluster ollama serve.
Louer un M4 dédié 24GB / 48GB (cluster ollama serve) → · Topologie cluster
Conclusion
Sur Apple Silicon, Ollama vs MLX ne sont pas équivalents : Agent → Ollama, bench → MLX ; le vrai frein = palier RAM et taille de modèle en LLM local Mac Mini M4.
