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 de faire passer la vitesse de génération du modèle Qwen3.5-35B-A3B 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 en 20 secondes

Ce changement compte particulièrement 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 en permanence d’une API externe, un enjeu qui rejoint la crise de mémoire qui redessine le matériel pour l’IA locale. Il montre aussi que la performance ne dépend plus 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 propres à chaque plateforme.

Ollama a présenté officiellement cette intégration le 30 mars 2026. La version initiale accélérait Qwen3.5-35B-A3B, en exigeant plus de 32 Go de mémoire unifiée pour le modèle de démonstration, et le support du moteur MLX a continué d’évoluer depuis.

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

Les premiers résultats publiés par Ollama montrent une différence notable. La société a comparé Qwen3.5-35B-A3B avec 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 (prefill), la vitesse est passée de 1 154 à 1 810 tokens/s, soit environ 1,57 fois plus rapide. Pour la génération (decode), la vitesse perçue par l’utilisateur à l’apparition de la réponse, la progression va de 58 à 112 tokens/s, soit près de 1,93 fois plus rapide. Ollama indique aussi qu’une variante en int4 pourrait atteindre 1 851 tokens/s en préremplissage et 134 tokens/s en génération, des chiffres qui viennent de l’entreprise elle-même et concernent des modèles avec des quantifications différentes : mieux vaut donc ne pas les lire comme une comparaison exclusive entre MLX et llama.cpp.

Ce saut de performance ne tient pas à une seule optimisation. Changer de moteur implique aussi de changer le format du modèle et, souvent, sa quantification, si bien qu’affirmer que « MLX est 93 % plus rapide que llama.cpp » revient à simplifier un résultat obtenu dans des conditions précises. Une comparaison indépendante réalisée par Ante Kapetanovic quelques jours avant le lancement remet ces chiffres en contexte : sur un M4 Max avec 128 Go de mémoire unifiée, testant Qwen3.5-35B-A3B, 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 empêche d’isoler parfaitement l’impact du moteur, mais les résultats montrent que la couche d’exécution choisie peut peser lourd sur la performance, même sur le même Mac et avec le même type de modèle.

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

C’est probablement le détail 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 profiteront 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 passer par le moteur MLX sous macOS ARM64. Un utilisateur peut donc mettre à jour Ollama sans constater la moindre différence s’il continue d’exécuter exactement le même modèle GGUF : il faut aussi que le modèle utilisé soit lui-même adapté.

Cette séparation permet de conserver une large bibliothèque de modèles autour de GGUF et llama.cpp, tout en laissant Ollama étendre progressivement son catalogue compatible MLX, avec l’inconvénient que ces améliorations restent inégales selon les modèles. La première version pilote était centrée sur qwen3.5:35b-a3b-coding-nvfp4, et d’autres modèles ont suivi : en juin, Ollama a montré l’exécution de gemma4:12b-mlx avec le nouveau moteur. L’évolution des versions montre à elle seule que cette architecture reste jeune, avec des mises à jour qui intègrent régulièrement des corrections sur le chargement des modèles, les couches d’embedding, les opérations matricielles ou de nouvelles architectures.

Pourquoi MLX fonctionne particulièrement bien avec Apple Silicon

MLX n’est pas une simple 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 déplacement explicite des données entre deux espaces mémoire distincts. Cela ne signifie pas que llama.cpp ignore les bénéfices d’Apple Silicon, son backend Metal est lui aussi fortement optimisé pour les Mac, mais MLX ajoute des fonctions comme l’évaluation différée du graphe et des optimisations propres au matériel d’Apple. Ollama a expliqué en juin avoir rendu 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 GPU.

La différence devient encore plus nette 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, et lors de tests avec MLX, la société a mesuré 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 en revanche été bien moins améliorée, avec un gain de 1,19 à 1,27 fois. Ce n’est pas contradictoire : le traitement initial du prompt repose fortement sur la capacité de calcul, ce qui permet aux Neural Accelerators d’intervenir directement, tandis que la génération de tokens, étape par étape, dépend davantage du débit mémoire. Sur le même matériel, ce débit est passé de 120 Go/s sur M4 à 153 Go/s sur M5, soit 28 % de plus. Pour profiter des Neural Accelerators améliorés du M5 avec MLX, Apple exige aussi macOS 26.2 ou une 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 en précision plus élevée, cette quantification à 4 bits réduit la mémoire nécessaire et, surtout lors du décodage, 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, avec environ moitié moins de perte de qualité due à la quantification par rapport au BF16, et des performances environ 20 % plus rapides que Q4_K_M avec le moteur MLX à jour. Ces résultats viennent du fabricant et ne constituent pas un avantage universel pour tous les modèles.

NVFP4 a une utilité pratique au-delà du benchmark : conçu pour les inférences déployées sur une infrastructure NVIDIA, il ouvre la possibilité d’exécuter localement des modèles quantifiés de la même manière que ceux utilisés dans les centres de données. Mais il faut garder en tête qu’en comparant un modèle GGUF Q4_K_M via llama.cpp à un safetensors NVFP4 via MLX, on ne change pas seulement de moteur d’inférence.

Gemma 4 va plus loin : générer plusieurs tokens simultanément

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 ajustant dynamiquement le nombre de tokens à générer. D’après les tests publiés dans ses notes de version, Gemma 4 12B NVFP4 sur un M5 Max est passé de 50,2 à 95 tokens/s lors d’un benchmark Aider Polyglot, soit environ 90 % de plus. La société assure que cette fonction est activée par défaut, ne demande aucune configuration et ne modifie pas la sortie du modèle. Ce gain est distinct de l’amélioration initiale de llama.cpp à MLX, mieux vaut donc ne pas additionner les pourcentages pour calculer une « accélération totale ».

Ce qu’on observe à chaque nouvelle version, c’est une orientation vers une inférence locale de plus en plus taillée pour Apple Silicon, au détriment d’une couche commune et portable entre plateformes, une logique qui rejoint la façon dont le choix du bon modèle devient lui aussi une décision au cas par cas. 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 reste une option cohérente pour la compatibilité, la disponibilité ou la qualité, mais mettre à jour Ollama en gardant les mêmes fichiers ne garantit pas de profiter pleinement des nouvelles performances via MLX.

Questions fréquentes

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 de 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 environ 1,93 fois plus rapide. Ce résultat ne se généralise pas à 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 surtout 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 gagne entre 19 % et 27 % selon le modèle.

Faut-il retélécharger les modèles Ollama ?

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

Sources :

Share on Pinterest Share on LinkedIn
Étiqueté , , ,