MLX

MLX est un framework de tableaux open source pour l'apprentissage automatique, publié par Apple ML Research en décembre 2023 sous licence MIT. Il est spécialement conçu pour les puces Apple Silicon (M1, M2, M3, M4 et M5) et s'articule autour d'un avantage architectural majeur : la mémoire unifiée d'Apple, où le CPU et le GPU partagent le même pool physique de RAM. Cette conception élimine le goulot d'étranglement lié à la copie des données qui ralentit des frameworks comme PyTorch lors du déplacement des tenseurs entre les types de processeurs. Résultat : MLX peut exécuter de grands modèles de langage plus rapidement sur un MacBook que la plupart des alternatives, sans aucun abonnement cloud payant ni API externe.

Le framework propose des API Python, C++, C et Swift. L'interface Python reflète les conventions de NumPy ; les couches de niveau supérieur pour les réseaux de neurones et les optimiseurs suivent les idiomes de PyTorch, permettant aux chercheurs familiers avec l'un ou l'autre de s'y adapter rapidement. MLX-LM, le package compagnon pour l'inférence et le fine-tuning de LLM, gère les téléchargements de modèles depuis Hugging Face, la quantification (4-bit, 8-bit, bf16), la mise en cache des prompts, le cache clé-valeur rotatif pour l'efficacité de la mémoire, le fine-tuning LoRA et QLoRA, ainsi que l'inférence distribuée sur plusieurs Mac. L'installation se fait via une simple commande pip. La communauté MLX sur Hugging Face héberge des milliers de modèles pré-quantifiés prêts à l'emploi. En avril 2026, MLX en est à la version 0.31.2 avec 73 versions publiées et une maintenance active par les ingénieurs d'Apple.

Ce que fait réellement MLX en mai 2026

MLX est le moteur d'inférence et d'entraînement pour les charges de travail ML locales sur Mac. Côté inférence, MLX-LM vous permet de récupérer n'importe quel modèle Hugging Face, de le quantifier à la volée et d'exécuter une interface de chat directement depuis le terminal. Il n'y a aucun serveur à configurer, aucun conteneur Docker, aucune pile de pilotes GPU. Sur un M3 Max avec 96GB de mémoire unifiée, vous pouvez charger un Llama 70B en 4-bit et générer 10-15 tokens par seconde. Sur un M4 Max exécutant un modèle Mixture-of-Experts de 35B, les benchmarks réels affichent environ 130 tokens par seconde. La puce M5 a fait chuter le délai d'obtention du premier token (time-to-first-token) sous les 10 secondes pour les architectures denses de 14B, et sous les 3 secondes pour les modèles MoE de 30B, grâce aux nouveaux GPU Neural Accelerators d'Apple qui fournissent des circuits dédiés à la multiplication matricielle que MLX exploite directement via Metal 4.

Côté entraînement, MLX prend en charge le fine-tuning LoRA et QLoRA via une seule commande. Vous spécifiez votre modèle, votre jeu de données au format JSONL et la durée de votre entraînement. L'entraînement de Mistral-7B sur 5,000 exemples prend environ 45-90 minutes sur un M2 Max, avec un pic de mémoire autour de 7GB en pleine précision. L'entraînement sur un modèle quantifié en 4-bit réduit la mémoire d'environ 3.5x avec une perte de précision minime. Les adaptateurs peuvent ensuite être téléchargés sur Hugging Face et partagés. L'entraînement distribué est disponible via mx.distributed pour les équipes disposant de plusieurs machines Apple Silicon.

Le calcul paresseux (lazy computation) signifie que les tableaux ne sont évalués que lorsque les résultats sont nécessaires. Les graphes de calcul dynamiques se reconstruisent lorsque les formes d'entrée changent, évitant ainsi une recompilation lente lors des itérations de recherche. L'API Swift est suffisamment stable pour que les développeurs d'applications iOS et macOS intègrent des modèles directement dans leurs applications sans dépendance au cloud. Lors de la WWDC 2025, Apple a consacré trois sessions dédiées à MLX, le positionnant comme le framework de choix pour l'inférence LLM sur Apple Silicon. L'annonce de mars 2026 selon laquelle Ollama passait à MLX comme moteur d'inférence, offrant une génération de réponses 2x plus rapide dans sa version bêta, a validé le framework en tant qu'infrastructure prête pour la production.

Où se situe MLX par rapport à llama.cpp et PyTorch MPS

MLX vs. llama.cpp : llama.cpp utilise le format GGUF et s'exécute sur CPU, Metal, Vulkan, CUDA et d'autres backends. Il est véritablement multiplateforme : Windows, Linux, macOS, Android. MLX ne fonctionne que sur macOS. Sur le débit brut pour les modèles de moins de 14B paramètres, MLX l'emporte clairement : un M2 Ultra avec Qwen-2.5 7B atteint environ 230 tok/s dans MLX contre 150 tok/s dans llama.cpp, soit un avantage de 53%. Sur un M4 Max avec un modèle de 0.6B, MLX affiche 525 tok/s contre 281 tok/s pour llama.cpp. À partir de 27B+ paramètres, où la bande passante mémoire devient le goulot d'étranglement, les deux frameworks convergent et les performances deviennent approximativement égales.

La différence architecturale significative réside dans la gestion de la mémoire. MLX utilise une véritable mémoire unifiée sans copie (zero-copy) grâce à l'évaluation paresseuse. llama.cpp utilise la séparation des couches CPU+GPU via l'indicateur -ngl, ce qui signifie que vous pouvez charger un modèle plus grand que la mémoire de votre GPU en déversant des couches vers la RAM du CPU. MLX n'a aucune capacité équivalente : si le modèle ne tient pas dans la mémoire unifiée, il ne s'exécutera pas. llama.cpp prend également en charge plus de 10 formats de quantification (variantes Q2_K, Q4_0, Q8_0, IQ) contre quatre pour MLX. De plus, llama.cpp est uniquement destiné à l'inférence ; MLX inclut nativement le fine-tuning LoRA sur l'appareil. Pour les utilisateurs sous Windows ou Linux, ou ceux qui ont besoin de charger des modèles proches ou supérieurs à leur plafond de mémoire, llama.cpp est le choix pragmatique. Pour une inférence axée sur Mac où le débit est primordial et où les modèles tiennent confortablement en mémoire, MLX l'emporte.

MLX vs. backend PyTorch MPS : Le backend Metal Performance Shaders de PyTorch permet aux utilisateurs Mac d'exécuter du code PyTorch existant sur le GPU Apple. Pour la génération de tokens de modèles de langage, l'écart est immense : MLX atteint environ 230 tok/s sur M2 Ultra pour l'inférence LLM ; PyTorch MPS plafonne à 7-9 tok/s. Ce n'est pas une erreur de frappe. La différence provient de l'architecture de mémoire unifiée : PyTorch copie toujours les tenseurs entre le CPU et le GPU de manière traditionnelle, entraînant une surcharge que MLX évite entièrement. Un benchmark sur un M3 Pro a révélé que PyTorch MPS était 5.5x plus rapide que MLX pour la multiplication matricielle brute (128x128, 10K itérations), ce qui montre que l'avantage de MLX est spécifiquement optimisé pour les charges de travail LLM de bout en bout, et non pour chaque opération primitive. Si vous disposez d'un vaste pipeline d'entraînement PyTorch existant et que vous souhaitez l'exécuter sur Mac sans le réécrire, PyTorch MPS est la voie de la compatibilité. Si vous partez de zéro et souhaitez les meilleures performances LLM sur Mac, MLX est la fondation idéale.

"C'est extrêmement impressionnant, l'ampleur de l'avancée technique ici change totalement ma façon d'envisager ma prochaine application." - Nathan Tarbert, développeur, fil de discussion de la session WWDC 2025 sur dev.to, juin 2025

"Lorsque j'ai exécuté ce code pour la première fois et que j'ai vu du texte apparaître sur mon écran, généré entièrement sur mon ordinateur portable sans aucun appel d'API, j'ai eu l'impression de vivre une petite révolution. Mon MacBook était soudainement devenu une véritable centrale d'IA autonome." - témoignage d'un développeur, willitrunai.com, 2025

À quoi ressemble la réalité quotidienne du développement

La prise en main est véritablement rapide. Installez MLX-LM avec pip dans un environnement virtuel, puis exécutez une seule commande pour lancer une session de chat pointant vers n'importe quel slug de modèle Hugging Face. Le modèle se télécharge et se quantifie automatiquement. Vous pouvez passer de Mistral-7B à Llama-3-70B en modifiant simplement un indicateur. La mise en cache des prompts signifie que les sessions répétées à contexte long ne retraitent pas l'intégralité du contexte à chaque tour, ce qui est crucial pour les agents de codage qui maintiennent de longs prompts système.

Le fine-tuning suit un schéma similaire. Préparez vos données au format JSONL, exécutez mlx_lm.lora avec le modèle, le chemin des données et le nombre d'itérations. Aucune installation de pilote CUDA, aucune configuration de variable d'environnement, aucune matrice de compatibilité à déchiffrer. Un développeur a décrit le fine-tuning de Mistral-7B pour générer de la documentation d'API dans un format spécifique, l'exécution complète prenant 45 minutes sur un MacBook Pro avec un pic de mémoire d'environ 6.8GB. L'entraînement sur un modèle de base quantifié en 4-bit réduit la mémoire d'environ 3.5x, ce qui rend possible le fine-tuning de modèles de 13B sur des systèmes de 24GB.

L'intégration avec d'autres outils continue de s'améliorer. LM Studio prend désormais en charge MLX comme backend, offrant aux utilisateurs une interface graphique pour l'inférence MLX. Ollama a annoncé en mars 2026 être passé à MLX comme moteur d'inférence sur Apple Silicon, offrant aux utilisateurs d'Ollama une génération 2x plus rapide sans aucun changement de flux de travail. La communauté MLX de Hugging Face héberge des milliers de modèles pré-quantifiés au format safetensors, couvrant la plupart des architectures qui n'apparaîtraient autrement qu'en GGUF en premier lieu. Les utilisateurs qui souhaitent exécuter des modèles dans une interface graphique (GUI) en parallèle de recherches web ou de flux de travail documentaires associent souvent l'inférence MLX à la couche d'API REST d'Ollama, acceptant une légère baisse de débit pour le confort de points de terminaison standardisés.

Le lancement public de décembre 2023 a été remarquable pour Apple. L'entreprise a publié MLX sur GitHub sans conférence de presse le 5 décembre 2023, la même semaine où Google lançait Gemini. La couverture de la presse technologique s'est presque entièrement concentrée sur Gemini. En quelques jours, la communauté ML a découvert MLX et les premiers benchmarks ont montré des performances 30% plus rapides que PyTorch pour certaines charges de travail sur le matériel Apple. La licence MIT a été perçue comme un signal fort : Apple n'essayait pas de contrôler l'écosystème de la même manière que CUDA a lié le monde des GPU à NVIDIA. Cette approche a accéléré l'adoption parmi les chercheurs qui étaient sceptiques quant au sérieux d'Apple en matière d'IA.

À qui s'adresse MLX

MLX est le choix idéal pour les chercheurs et développeurs ML sur Mac qui souhaitent exécuter ou affiner de grands modèles de langage sans frais de cloud ni envoi de données hors de l'appareil. Les data scientists frustrés par les vitesses d'inférence de PyTorch MPS trouveront en MLX une mise à niveau substantielle. Les professionnels soucieux de la confidentialité qui ne peuvent pas envoyer de données à des API externes ont une raison évidente de l'adopter : toute l'inférence et l'entraînement restent sur la machine locale. Les développeurs Swift créant des applications iOS ou macOS avec des modèles intégrés peuvent utiliser l'API Swift de MLX sans couche d'interpréteur Python. Les équipes développant sur l'écosystème Apple à long terme devraient considérer MLX comme une dépendance stratégique, compte tenu de l'optimisation matérielle intentionnelle du M5 par Apple pour les charges de travail MLX.

Les utilisateurs qui souhaitent explorer une large gamme de modèles à poids ouverts sur plusieurs plateformes devraient également consulter llama.cpp et Llama directement, car l'écosystème GGUF de llama.cpp offre une plus grande disponibilité de modèles pour les architectures récemment publiées. Les deux outils se complètent en fonction de la tâche.

Ce que MLX n'est pas

MLX n'est pas un framework multiplateforme. Si votre équipe comprend des développeurs Windows ou Linux, ou si vous déployez des modèles sur des serveurs Linux, MLX ne pourra pas vous y suivre. llama.cpp fonctionne sur les trois plateformes avec les mêmes fichiers de modèle. Les modèles safetensors de MLX ne seront pas portables.

MLX ne gère pas les modèles qui dépassent la mémoire unifiée. Il n'y a pas de déversement de couches vers le CPU de type -ngl. Si votre Mac dispose de 24GB de mémoire unifiée et que vous souhaitez charger un modèle de 32B avec une précision de 8-bit, MLX refusera. llama.cpp peut diviser ce modèle entre le CPU et le GPU. Cela a son importance pour les utilisateurs de modèles de base M1 ou M2 (8-16GB) qui souhaitent exécuter quoi que ce soit de plus grand qu'un 7B avec une qualité décente.

Les performances de pré-remplissage (prefill) constituent une véritable faiblesse. Pour de courts échanges de chat, l'avantage de génération de MLX peut être contrebalancé par son traitement plus lent des prompts. Un prompt de 650 tokens sur un M1 Max a signalé 94% du temps passé sur le pré-remplissage, faisant chuter le débit effectif en dessous de llama.cpp. Les puces M1 et M2 manquent de prise en charge native du bf16, ce qui aggrave le problème sur le matériel plus ancien.

MLX n'est pas une plateforme de service LLM de production. Il n'y a pas de traitement par lots des requêtes (batching) intégré, de limitation de débit ou de gestion de session multi-utilisateurs. L'écosystème de serveurs basés sur MLX (mlx-lm server, Rapid-MLX, vLLM-MLX, oMLX) est encore fragmenté. Pour un développeur seul sur sa propre machine, c'est parfait. Pour les équipes déployant un point de terminaison interne partagé, les outils ne sont pas encore matures.

Enfin, MLX n'est pas un outil pour débutants. Il n'y a pas d'interface graphique proposée directement par Apple. Le point d'entrée principal est un terminal Python. Les utilisateurs qui souhaitent une expérience GUI soignée devraient commencer par LM Studio ou Ollama avec une interface graphique, qui utilisent de toute façon désormais MLX en arrière-plan sur Apple Silicon sans vous obliger à interagir directement avec le framework.