LLM local sur Mac M5 : MLX écrase désormais llama.cpp (chiffres 2026)

#Pourquoi le M5 change la donne pour un LLM local sur Mac

La puce M5 apporte deux choses qui comptent vraiment pour l'inférence : des cœurs GPU avec des unités de multiplication matricielle (Neural Accelerators) intégrées à chaque cœur, et une bande passante mémoire relevée. Or l'inférence d'un LLM est d'abord un problème de bande passante mémoire — chaque token généré relit l'intégralité des poids du modèle. Plus la mémoire unifiée est rapide, plus les tokens sortent vite.

C'est précisément là que le framework MLX d'Apple prend l'avantage sur llama.cpp. MLX est écrit pour exploiter directement ces nouvelles unités matricielles du GPU M5, là où le chemin Metal de llama.cpp reste plus générique. Résultat concret : sur la même machine, le même modèle et la même quantification, MLX génère nettement plus de tokens par seconde. L'écart, marginal sur M3, devient franc sur M5.

#Benchmarks M5 et M5 Max : les chiffres 2026

Voici des ordres de grandeur mesurés en génération (decode) avec MLX, sur des modèles courants en quantification 4-bit. Comme toujours en inférence locale, ces débits varient selon la longueur de contexte, la version exacte du modèle et la température thermique de la machine : traitez-les comme des repères, pas comme des garanties au token près.

M5 (GPU 10 cœurs) — 8B Q4

~55-70 tokens/s en génération. Un modèle 8B (Qwen 3.5, Granite 4.2, Gemma 4) reste très confortable sur la puce de base.

M5 Max — 8B Q4

~230 tokens/s. La bande passante mémoire supérieure du Max fait la différence sur les petits modèles, où le GPU n'est jamais le goulot.

M5 Max — 32B Q4

~55-65 tokens/s. Un 32B (Qwen 3.8 27B, Devstral) tourne à vitesse de lecture confortable, largement utilisable en interactif.

M5 Max — 70B Q4

~28 tokens/s. Un 70B en Q4 tient en mémoire dès 48-64 Go de RAM unifiée et reste fluide pour du chat et de la génération de code.

Le point marquant, c'est le 70B à ~28 tokens/s sur une machine sans carte graphique dédiée, silencieuse et qui tient dans un sac. Pour comparaison, il faut une RTX 4090 24 Go (et un déchargement partiel CPU, car un 70B Q4 pèse ~40 Go et ne rentre pas dans 24 Go de VRAM) pour rivaliser côté PC — avec bien plus de bruit et de consommation.

#MLX vs llama.cpp : où se creuse l'écart

L'écart de 30 à 40 % en faveur de MLX n'est pas uniforme : il dépend du profil de la charge. Comprendre où il se creuse aide à savoir quand basculer en MLX vaut vraiment le coup.

Génération (decode)

C'est là que MLX domine le plus nettement sur M5, grâce à l'usage direct des unités matricielles du GPU. Pour du chat interactif, c'est l'écart que vous ressentez.

Traitement du prompt (prefill)

MLX garde l'avantage, mais l'écart est un peu plus resserré. Sur de très longs contextes, les deux moteurs deviennent limités par la mémoire.

Support des modèles

llama.cpp reste plus universel via le format GGUF ; MLX exige une version convertie au format MLX. Sur les modèles populaires, la conversion existe presque toujours (hub mlx-community sur Hugging Face).

Intégration Python

MLX est natif Python, ce qui en fait le choix évident pour du prototypage, du fine-tuning léger ou un pipeline maison. llama.cpp passe par des bindings.

#Prérequis et RAM conseillée par modèle

Avant d'installer, calibrez la taille de modèle sur votre mémoire unifiée. Voici les paliers réalistes sur M5 et M5 Max, en Q4.

16 Go (M5)

Modèles 3B à 8B en Q4 confortables. Un 14B passe mais laisse peu de marge pour un gros contexte.

24-32 Go (M5 / M5 Pro)

Un 14B à l'aise, un 32B Q4 jouable en haut de fourchette. Le sweet spot pour un usage quotidien polyvalent.

48 Go (M5 Max)

Un 32B Q4 très confortable, un 70B Q4 tout juste — mieux vaut viser 64 Go pour un 70B avec du contexte.

64-128 Go (M5 Max)

Un 70B Q4 fluide avec grand contexte, ou plusieurs modèles chargés en parallèle. Territoire power user.

Côté logiciel, il vous faut macOS à jour et l'un des deux chemins d'accès à MLX : LM Studio (qui bascule automatiquement sur MLX quand une version MLX du modèle existe) ou Ollama depuis sa mise à jour de juin 2026, détaillée juste après.

#Le moteur MLX d'Ollama (juin 2026)

Historiquement, Ollama s'appuyait sur son moteur maison et sur llama.cpp, donc empruntait le chemin Metal sur Mac. Depuis sa mise à jour de juin 2026, Ollama sait exécuter les modèles via MLX sur Apple Silicon quand une version MLX est disponible — ce qui aligne enfin l'outil le plus utilisé pour l'IA locale sur les performances que LM Studio offrait déjà via MLX.

Concrètement, cela veut dire que vous récupérez le gain MLX sans changer vos habitudes : même daemon Ollama sur le port 11434 par défaut, mêmes commandes, même API compatible OpenAI. Le moteur choisit MLX quand c'est pertinent, et retombe sur le chemin classique sinon.

#Installer et lancer un modèle en MLX

Deux voies selon votre confort avec le terminal. La plus directe pour tester MLX sans configuration, c'est LM Studio ; la plus intégrable dans une stack, c'est Ollama.

1. 01
   1. Mettre à jour l'outil

   Installez la dernière version d'Ollama (juin 2026 ou plus récent) ou de LM Studio. C'est le prérequis pour bénéficier du chemin MLX.
2. 02
   2. Choisir un modèle avec version MLX

   Sur LM Studio, la recherche propose en priorité les variantes MLX sur Apple Silicon. Sur Ollama, tirez un modèle courant : le moteur bascule en MLX quand une version convertie existe.
3. 03
   3. Lancer et vérifier le débit

   Posez une question longue et regardez les tokens/s affichés. Comparez éventuellement avec le même modèle en GGUF pour mesurer l'écart réel sur votre machine.
4. 04
   4. Ajuster la quantification si besoin

   Si le modèle sature votre mémoire unifiée, descendez d'un cran (Q5 → Q4_K_M) plutôt que de changer d'outil : c'est la mémoire qui borne, pas le moteur.

# Vérifier la version d'Ollama (le support MLX date de juin 2026)
ollama --version

# Lancer un modèle : Ollama emprunte MLX quand une version MLX existe
ollama run qwen3:8b

# Le daemon expose l'API compatible OpenAI sur le port par défaut
curl http://localhost:11434/api/tags

Côté Python, MLX se prête directement au scripting, ce qui est utile pour benchmarker ou intégrer l'inférence dans un pipeline maison :

# Installer les outils MLX pour LLM (framework Apple, natif Python)
pip install mlx-lm

# Générer avec un modèle converti au format MLX (hub mlx-community)
mlx_lm.generate --model mlx-community/Qwen3-8B-4bit \
  --prompt "Explique la mémoire unifiée du M5 en trois phrases"

#Clusters Thunderbolt 5 pour les modèles 120B+

Un seul Mac, même un M5 Max bien doté, plafonne à sa mémoire unifiée. Pour dépasser — faire tourner un 120B+ ou un gros MoE — l'approche 2026 consiste à relier plusieurs machines Apple Silicon en Thunderbolt 5 et à répartir le modèle entre elles. Thunderbolt 5 offre une bande passante nettement supérieure à Thunderbolt 4, ce qui rend l'échange d'activations entre nœuds enfin viable pour de l'inférence.

Le principe : le modèle est découpé en tranches de couches, chaque machine héberge une part des poids en mémoire, et les activations circulent d'un nœud au suivant à chaque token. On additionne ainsi la mémoire unifiée de plusieurs Mac pour charger un modèle qui ne tiendrait sur aucun d'eux seul.

Ce que ça débloque

Des modèles 120B+ en Q4, voire de très gros MoE, en cumulant par exemple deux M5 Max 128 Go pour approcher 256 Go de mémoire adressable.

Le compromis

La latence inter-nœuds coûte des tokens/s : un cluster est plus lent qu'une machine unique qui tiendrait le même modèle. On y va parce qu'aucune machine seule ne suffit, pas pour gagner en vitesse.

Le câblage

Thunderbolt 5 est la clé : sa bande passante rend le transfert d'activations acceptable. En Thunderbolt 4 ou en Ethernet, l'interconnexion redevient le goulot d'étranglement.

#Astuces et dépannage

« MLX ne va pas plus vite »

Vérifiez d'abord que vous êtes bien sur le chemin MLX (version d'outil à jour, variante MLX du modèle réellement chargée). Un GGUF chargé via le chemin Metal ne bénéficie pas de MLX.

Débit qui s'effondre après quelques minutes

C'est du throttling thermique, surtout sur MacBook Air (sans ventilateur). Sur charge longue, un MacBook Pro ou un Mac mini/Studio tient un débit plus stable.

Modèle qui refuse de se charger

La mémoire unifiée est saturée. Descendez d'une taille de modèle ou d'un cran de quantification ; fermez les applications gourmandes en RAM.

Contexte long qui rame

Le prefill d'un très long prompt est coûteux en mémoire. Réduisez la fenêtre de contexte si vous n'en avez pas besoin, ou acceptez un premier token plus lent.

#Pour aller plus loin

Ces guides prolongent naturellement ce que vous venez de lire, du comparatif de fond à la mise en place concrète :

MLX vs llama.cpp en détail

« MLX vs llama.cpp sur Mac M-series : qui gagne en 2026 ? » creuse le comparatif de fond (support modèles, quantization, intégration Python) au-delà des seuls chiffres M5.

Installer Ollama sur macOS

« Installer Ollama sur macOS (Apple Silicon) » couvre l'installation pas à pas et l'exploitation de la mémoire unifiée, base indispensable avant de viser MLX.

Choisir sa quantification

« Choisir sa quantification (Q4, Q5, Q8, FP16) » explique le compromis qualité/mémoire — le vrai levier pour caler un modèle dans votre RAM unifiée.