Share on Pinterest Share on LinkedIn

Ollama a opéré une modification majeure de son architecture pour exécuter des modèles d’intelligence artificielle sur les Mac équipés de la puce Apple Silicon. Depuis la version 0.19, il intègre en phase pilote un moteur basé sur MLX, le framework d’apprentissage automatique développé par Apple, capable d’augmenter la vitesse de génération du modèle Qwen3.5-35B-A3B, passant de 58 à 112 tokens par seconde selon les tests publiés par la société. Cette amélioration atteint près de 93 %, mais sous une condition essentielle : les modèles GGUF, que de nombreux utilisateurs avaient déjà téléchargés, continuent à utiliser llama.cpp et ne bénéficient pas automatiquement de cette accélération.

Les points clés d’Ollama et MLX en 20 secondes

  • Ollama 0.19 a lancé en mars un moteur MLX dédié à Apple Silicon.
  • Pour Qwen3.5-35B-A3B, la vitesse de génération est passée de 58 à 112 tokens/s dans les tests réalisés par Ollama.
  • Les modèles GGUF continuent d’utiliser llama.cpp ; MLX fonctionne avec des modèles compatibles en safetensors.
  • En juin, de nouvelles optimisations ont encore augmenté de 20 % le rendement du moteur MLX.
  • Ollama 0.31.1 a introduit la fonctionnalité Multi-Token Prediction pour accélérer Gemma 4.

Ce changement est particulièrement pertinent pour les développeurs qui utilisent un Mac comme station locale pour exécuter des LLM, des agents de programmation ou des assistants, sans dépendre constamment d’une API externe. Il démontre également que la performance dépend désormais non seulement du modèle et du matériel, mais aussi du moteur d’inférence, du format des poids, de la quantification et des optimisations spécifiques à chaque plateforme.

Ollama a officiellement présenté cette intégration le 30 mars 2026. La version initiale permettait d’accélérer Qwen3.5-35B-A3B, requérant plus de 32 Go de mémoire unifiée pour le modèle de démonstration. Depuis, le support et le moteur MLX ont continué leur évolution.

De 58 à 112 tokens par seconde en changeant simplement de moteur

Les premiers résultats publiés par Ollama illustrent une différence notable.

La société a comparé Qwen3.5-35B-A3B en utilisant Ollama 0.18 et sa précédente implémentation Q4_K_M, face à la version basée sur MLX et le modèle quantifié en NVFP4. En traitement du prompt ou prefill, la vitesse est passée de 1 154 à 1 810 tokens/s, soit une amélioration d’environ 1,57 fois.

Pour la génération, ou decode, qui correspond à la vitesse perçue par l’utilisateur lors de l’apparition de la réponse, la progression est de 58 à 112 tokens/s, soit près de 1,93 fois plus rapide.

Ollama indique également qu’une variante en int4 pourrait atteindre 1 851 tokens/s en préremplissage et 134 tokens/s en génération. Ces chiffres proviennent de l’entreprise elle-même et concernent des modèles avec différentes quantifications, il ne faut donc pas les interpréter comme une comparaison exclusive entre MLX et llama.cpp.

Ce point est crucial.

Ce saut de performance n’est pas dû à une seule optimisation. Le changement de méthode implique aussi une modification du format utilisé par le modèle et, éventuellement, de sa quantification. Ainsi, affirmer que « MLX est 93 % plus rapide que llama.cpp » revient à simplifier excessivement un résultat obtenu dans des conditions spécifiques.

Une comparaison indépendante effectuée par Ante Kapetanovic quelques jours avant le lancement permet de mettre ces différences en contexte. En testant Qwen3.5-35B-A3B sur un M4 Max avec 128 Go de mémoire unifiée, il a obtenu 48,1 tokens/s avec Ollama sur llama.cpp, 72,4 tokens/s en exécutant directement llama.cpp, et 131,8 tokens/s via mlx-lm.

Les quantifications n’étaient pas identiques dans ces tests, ce qui ne permet pas d’isoler parfaitement l’impact du moteur. Cependant, ces résultats montrent que la couche d’exécution choisie peut considérablement influencer la performance, même sur le même Mac et avec un même type de modèle.

Mettre à jour Ollama ne rend pas automatique les anciens modèles plus rapides

Ce détail est probablement le plus important pour ceux qui utilisent déjà Ollama.

Installer une nouvelle version ne signifie pas que tous les modèles stockés sur l’ordinateur bénéficieront automatiquement du moteur MLX.

L’architecture maintient deux voies d’inférence : les modèles GGUF continuent d’utiliser llama.cpp, tandis que les modèles compatibles, distribués en safetensors, peuvent utiliser le moteur MLX sous macOS ARM64.

Ainsi, un utilisateur peut mettre à jour Ollama sans constater de différence de performance si il continue d’exécuter exactement le même modèle GGUF.

Il faut aussi que le modèle utilisé lui-même soit adapté.

Cette séparation permet de conserver une large bibliothèque de modèles autour de GGUF et llama.cpp, tout en permettant à Ollama d’étendre progressivement son catalogue compatible avec MLX. L’inconvénient étant que ces améliorations ne sont pas uniformes.

La première version pilote était centrée sur qwen3.5:35b-a3b-coding-nvfp4. D’autres modèles et optimisations ont suivi, dont en juin Ollama a montré l’exécution de gemma4:12b-mlx avec le nouveau moteur.

L’évolution même des versions témoigne encore que cette architecture reste jeune. Les mises à jour ont intégré des corrections concernant le chargement des modèles, les couches d’embedding, les opérations matricielles ou encore de nouvelles architectures.

Pourquoi MLX fonctionne particulièrement bien avec Apple Silicon

MLX n’est pas simplement une interface supplémentaire sur Metal.

Apple l’a conçu spécifiquement pour ses processeurs et leur architecture de mémoire unifiée, où CPU et GPU partagent la même mémoire physique. Selon Apple, les opérations MLX peuvent s’exécuter sur CPU ou GPU sans nécessiter de déplacement explicite des données entre deux espaces mémoire distincts.

Cela ne veut pas dire que llama.cpp ignore les bénéfices d’Apple Silicon. Son backend Metal est également fortement optimisé pour les Mac.

MLX ajoute toutefois des fonctionnalités comme l’évaluation différée du graphe et des optimisations spécifiques au hardware d’Apple.

Ollama a expliqué en juin avoir réussi à rendre son moteur MLX jusqu’à 20 % plus rapide que la version précédente, en fusionnant plusieurs opérations dans des kernels Metal grâce au compilateur JIT de MLX, en plus d’ajuster le traitement sur GPU.

La différence devient encore plus palpable avec la génération M5.

Apple a intégré des Neural Accelerators dans ses cœurs GPU pour accélérer les opérations matricielles. Lors de tests avec MLX, la société a constaté des améliorations de l’ordre de 3,33 à 4,06 fois sur le temps jusqu’au premier token, par rapport à un MacBook Pro M4, selon le modèle testé.

La génération suivante de tokens a été beaucoup moins améliorée, avec un gain de 1,19 à 1,27 fois.

Ce n’est pas contradictoire.

Apple explique que le traitement initial du prompt repose fortement sur la capacité de calcul, ce qui permet aux Neural Accelerators d’intervenir directement. En revanche, la génération de tokens, étape par étape, dépend davantage du débit mémoire.

Sur le même matériel, le débit mémoire est passé de 120 Go/s sur M4 à 153 Go/s sur M5, soit une augmentation de 28 %.

Pour tirer parti des Neural Accelerators améliorés du M5 avec MLX, Apple exige également macOS 26.2 ou version ultérieure.

NVFP4, un autre élément clé

L’évolution du moteur s’accompagne d’un autre composant technique : NVFP4.

Ollama utilise ce format de faible précision développé par NVIDIA pour certains de ses modèles compatibles MLX. Contrairement à des poids avec une précision plus élevée, cette quantification à 4 bits réduit la mémoire exigée et, surtout lors de la décodification, la quantité d’informations à transférer en continu depuis la mémoire.

Ollama affirme que NVFP4 conserve une meilleure qualité qu’un format Q4_K_M, selon ses tests avec Gemma 4 12B. La société indique que cela réduit d’environ moitié la perte de qualité induite par la quantification par rapport au BF16, et que, avec son moteur MLX à jour, il génère des performances environ 20 % plus rapides que Q4_K_M. Ces résultats sont du fabricant et ne constituent pas une avantage universel pour tous les modèles.

Il existe cependant une utilité pratique à ce format.

NVFP4 est conçu pour les inférences déployées dans une infrastructure NVIDIA. Ollama suggère ainsi la possibilité d’exécuter localement des modèles quantifiés de cette manière, semblables à ceux utilisés dans les centres de données.

Mais encore une fois, il faut prendre en compte que quand on compare un modèle GGUF Q4_K_M via llama.cpp avec un safetensors NVFP4 via MLX, on ne change pas uniquement de moteur d’inférence.

Gemma 4 optimise encore davantage : générer plusieurs tokens simultanément

L’évolution ne s’arrête pas là.

Ollama 0.31.1, sortie le 30 juin, a intégré une amélioration pour la Multi-Token Prediction (MTP) dans Gemma 4 sur Apple Silicon.

Le principe consiste à anticiper plusieurs tokens pendant la génération, plutôt que d’en produire un à chaque étape. Ollama ajuste dynamiquement le nombre de tokens à générer.

D’après les tests dans ses notes de version, Gemma 4 12B NVFP4 sur un M5 Max a vu sa vitesse passer de 50,2 à 95 tokens/s lors d’un benchmark Aider Polyglot, soit une amélioration d’environ 90 %. La société assure que cette fonctionnalité est activée par défaut, ne nécessite aucune configuration, et ne modifie pas la sortie du modèle.

Ce gain est distinct de l’augmentation de performance initiale de llama.cpp à MLX ; il ne faut donc pas additionner ces pourcentages pour calculer une « accélération totale ».

Ce qu’on observe aussi avec chaque nouvelle version, c’est une orientation vers une inférence locale de plus en plus optimisée pour Apple Silicon : tirer parti de ses caractéristiques spécifiques plutôt que d’utiliser une couche commune, portable entre plateformes.

Pour un développeur, cela pose une nouvelle question stratégique : il ne suffit plus de savoir quel modèle fonctionne avec Ollama, mais aussi quelle variante, avec quelle quantification, et quel moteur de traitement.

GGUF parfaitement compatible reste une option cohérente pour la compatibilité, la disponibilité ou la qualité. Mais mettre à jour Ollama et continuer à utiliser les mêmes fichiers ne garantit pas que l’on profite pleinement des nouvelles performances via MLX.

Questions fréquemment posées

Ollama utilise-t-il MLX automatiquement sur tous les Mac ?

Ollama dispose d’un moteur MLX pour Apple Silicon, mais tous les modèles ne l’utilisent pas. Les modèles GGUF existants continuent à fonctionner via llama.cpp, tandis que les variantes compatibles MLX empruntent une autre voie d’inférence.

MLX rend-il Ollama deux fois plus rapide ?

Lors du test initial d’Ollama avec Qwen3.5-35B-A3B, la vitesse en décodage est passée de 58 à 112 tokens/s, soit une augmentation d’environ 1,93 fois. Toutefois, ce résultat ne peut pas être généralisé à tous les modèles, Mac ou modes de quantification.

Qu’apporte le M5 par rapport aux générations précédentes ?

Les Neural Accelerators de la GPU M5 accélèrent principalement les opérations matricielles lors du traitement initial du prompt. Apple a mesuré des améliorations allant jusqu’à 4,06 fois le temps jusqu’au premier token par rapport au M4, tandis que la génération suivante a amélioré la vitesse entre 19 % et 27 % selon le modèle.

Faut-il re-télécharger les modèles Ollama ?

Pour exploiter une variante optimisée pour MLX, il faut utiliser le modèle correspondant. Mettre à jour Ollama seul ne suffit pas pour convertir les modèles GGUF existants en modèles MLX.

Sources :

Share on Pinterest Share on LinkedIn