MLX sur Apple Silicon : quand il vous faut votre propre modèle, pas celui d'Apple

Le framework Foundation Models d’Apple vous tend un seul modèle : celui du système, scellé, gratuit, mis à jour au rythme d’Apple. Pour l’essentiel du traitement du langage embarqué, c’est l’outil adéquat, et chercher à aller plus loin est une erreur. Mais certains travaux exigent un modèle que vous choisissez : un LLM open-weight précis, une version que vous figez, un affinage entraîné sur vos propres données, ou une capacité dont le modèle système ne dispose pas. Lorsqu’il vous faut votre propre modèle exécuté sur l’appareil, la couche située sous Foundation Models s’appelle MLX¹.

MLX est le framework de calcul matriciel d’Apple pour l’apprentissage automatique sur Apple Silicon, doté d’une API Swift (MLX Swift) que vous intégrez directement dans une application². Ce n’est pas un framework système que vous appelez ; c’est une bibliothèque que vous livrez, poids du modèle compris. Toute la contrepartie tient dans cette différence, et c’est en la comprenant que vous déciderez s’il faut descendre d’une couche ou rester là où Apple vous a placé.

En bref

• MLX est un framework de calcul matriciel de type NumPy conçu pour Apple Silicon, avec évaluation paresseuse, transformations de fonctions composables et un backend Metal².
• Le modèle de mémoire unifiée explique pourquoi cela fonctionne sur un téléphone. Les tableaux résident dans un espace mémoire unique que le CPU et le GPU partagent : MLX s’exécute donc sur les deux à partir des mêmes tampons, sans la taxe de copie entre hôte et périphérique³.
• Exécutez un LLM open-weight sur l’appareil avec LLMModelFactory, en pointant vers un modèle quantifié comme mlx-community/Llama-3.2-3B-Instruct-4bit, puis générez via une ChatSession⁴.
• Affinez le modèle avec des adaptateurs LoRA : entraînez un petit adaptateur, livrez adapters.safetensors, et load(into:) remplace à l’exécution les couches Linear du modèle de base par des LoRALinear⁵.
• Ce que coûte votre propre modèle : la taille de l’application (les poids sont volumineux), la pression sur la mémoire, l’absence d’intégration système, et la charge de chaque mise à jour. Foundation Models n’a aucun de ces coûts, parce qu’Apple les assume.

Ce qu’est MLX, et pourquoi Apple Silicon le rend possible

MLX vous offre des tableaux et des opérations qui ressemblent à NumPy, auxquels s’ajoutent les transformations dont l’apprentissage automatique a besoin : différenciation automatique, vectorisation et évaluation paresseuse qui construit un graphe de calcul et ne l’exécute qu’au moment où vous lisez un résultat². Le projet avance par ailleurs au rythme d’un framework de recherche : MLX est passé en 0.32.0 en juillet 2026 et MLX Swift en 0.31.6 la même semaine, avec une nouvelle version toutes les quelques semaines environ⁷. Figez vos versions et attendez-vous à voir la surface de l’API continuer de s’étendre. En soi, cette description vaut pour une douzaine de frameworks. Ce qui permet à MLX d’exécuter un modèle de plusieurs milliards de paramètres sur un appareil que vous avez en poche, c’est le modèle de mémoire.

Sur un GPU de bureau, les données résident dans la RAM système et vous les copiez à travers un bus vers la mémoire distincte du GPU pour calculer, avant de recopier les résultats en sens inverse. Cette copie est une taxe, et pour un modèle volumineux elle est brutale. Apple Silicon repose sur une mémoire unifiée : un espace unique que le CPU, le GPU et le Neural Engine adressent tous directement. MLX est construit autour de ce fait³. Un tableau n’est ni « sur le CPU » ni « sur le GPU » : il est en mémoire, et n’importe quel processeur y travaille sur place. Aucune copie, aucune taxe de bus. Un modèle de 3 milliards de paramètres quantifié en 4 bits tient dans quelques gigaoctets et s’exécute sans les allers-retours qui rendraient le même travail impraticable sur une machine à GPU dédié disposant d’autant de mémoire. La décision matérielle prise par Apple il y a des années est la raison pour laquelle l’inférence embarquée d’un vrai modèle est envisageable, et l’architecture à tuiles et mémoire unifiée constitue le substrat sur lequel MLX s’appuie.

Exécuter un LLM sur l’appareil

Le chemin entre « je veux un modèle précis » et du texte à l’écran est court. La couche LLM de MLX Swift charge un modèle quantifié depuis le Hub Hugging Face et l’exécute⁴ :

let container = try await LLMModelFactory.shared.loadContainer(
    from: HubClient.default,
    using: TokenizersLoader(),
    configuration: .init(id: "mlx-community/Llama-3.2-3B-Instruct-4bit")
)

let session = ChatSession(container)
let response = try await session.respond(to: "Summarize this in one line: \(text)")

Pour une UI qui affiche le texte token par token, générez plutôt un flux et affichez les fragments à mesure qu’ils arrivent⁴ :

let input = try await container.prepare(input: UserInput(prompt: prompt))
let stream = try await container.generate(input: input, parameters: GenerateParameters())
for await event in stream {
    if case let .chunk(text) = event { /* append to UI */ }
}

Deux détails concentrent l’essentiel des enjeux pratiques. D’abord, le 4bit de l’identifiant du modèle n’est pas un ornement facultatif : c’est la quantification qui permet au modèle de tenir en mémoire et de tourner à une vitesse utilisable sur un appareil. Vous livrez des poids en 4 bits (ou moins), pas en pleine précision. Ensuite, ces poids restent volumineux même quantifiés : vous décidez donc délibérément de les embarquer dans l’application (disponibilité immédiate, mais téléchargement massif) ou de les récupérer au premier lancement (binaire léger, mais une attente et un scénario d’échec à gérer). Foundation Models ne pose jamais cette question, puisque le modèle se trouve déjà sur l’appareil. Avec MLX, les poids sont votre problème.

Affinage : un adaptateur LoRA, pas un nouveau modèle

Ce qui justifie d’apporter votre propre modèle, ce n’est presque jamais le modèle de base lui-même : c’est de lui enseigner votre domaine. Un affinage complet d’un modèle de plusieurs milliards de paramètres sur l’appareil n’est pas la bonne approche. LoRA (adaptation de rang faible) l’est : vous entraînez un petit jeu de poids d’adaptateur qui ajustent le comportement du modèle de base, en laissant celui-ci intact. L’adaptateur pèse des mégaoctets, pas des gigaoctets⁵.

MLX Swift charge un adaptateur entraîné depuis un dossier contenant adapter_config.json et adapters.safetensors, puis l’applique à un modèle déjà chargé dans un conteneur⁵ :

let adapter = try LoRAContainer.from(directory: adapterURL)
await container.update { context in
    try? adapter.load(into: context.model)   // swaps Linear layers for LoRALinear
}

load(into:) remplace les couches Linear standard du modèle par des couches LoRALinear qui intègrent les deltas de rang faible de l’adaptateur : l’inférence reflète dès lors votre affinage. Comme le modèle vit à l’intérieur du conteneur, vous appliquez l’adaptateur via container.update, et vous pouvez permuter les adaptateurs à chaud pendant l’exécution (unload(from:) pour l’un, load(into:) pour l’autre) afin de donner à un même modèle de base un comportement différent selon la fonctionnalité. Ce schéma reprend ce qu’Apple propose pour le modèle système via les adaptateurs personnalisés de Foundation Models : la différence, c’est qu’ici le modèle de base, la chaîne d’entraînement et le résultat vous appartiennent, au lieu d’adapter un modèle que vous ne pouvez pas voir.

La décision : Foundation Models, MLX ou le cloud

Trois couches, et se tromper vous coûte soit des capacités, soit une montagne de travail évitable.

• Foundation Models quand le modèle système sait faire la tâche. Gratuit, confidentiel, aucun poids à livrer, aucune mémoire à gérer, et une intégration système obtenue sans rien payer. Par défaut, c’est ici. Les tâches de langage embarquées pour lesquelles Apple l’a conçu (résumer, classifier, extraire, réécrire, produire des sorties structurées) relèvent de cette couche, point final.
• MLX quand il vous faut un modèle que le système ne fournit pas : un LLM open-weight précis, une version figée qui ne bougera pas sous l’effet d’une mise à jour de l’OS, un affinage métier, ou une architecture (modèle vision-langage, modèle non textuel) hors du périmètre de Foundation Models. Vous payez en taille d’application, en mémoire et en responsabilité, et vous achetez du contrôle.
• Le cloud quand le modèle doit véritablement être immense : raisonnement de pointe, analyse à contexte long, tout ce que font les plus grands modèles et qu’un modèle embarqué de quelques milliards de paramètres ne peut pas faire. L’embarqué ne remplace pas un modèle de pointe ; c’est un autre point sur la courbe.

Le constat honnête : MLX est une descente délibérée d’un cran pour une raison précise, pas une meilleure valeur par défaut. Si vous ne savez pas nommer la capacité qui manque à Foundation Models pour votre fonctionnalité, MLX ne vous est pas nécessaire, et le livrer revient à transporter des gigaoctets de poids et un budget mémoire dont vous auriez pu vous passer.

iOS 27 ajoute une quatrième couche à cette carte. Core AI est le framework système d’Apple pour exécuter un modèle que vous fournissez, avec un contrôle explicite sur la spécialisation, la mise en cache et l’ordonnancement des unités de calcul. Il chevauche MLX au niveau « votre modèle, sur l’appareil », mais en sens inverse : Core AI est une surface d’exécution gérée par le système pour un .aimodel déjà préparé, tandis que MLX est une bibliothèque que vous intégrez, avec à l’intérieur votre propre boucle d’entraînement, votre quantification et vos itérations. Si votre besoin est d’exécuter rapidement un modèle converti sous la houlette du système, Core AI se pose en concurrent ; si votre besoin est d’expérimenter, d’affiner ou de maîtriser toute la chaîne, MLX reste l’outil.⁶

Quand ne pas se tourner vers MLX

• Le modèle système sait déjà le faire. Relisez la liste des tâches couvertes par Foundation Models. Si la vôtre y figure, arrêtez-vous là.
• Vous ne pouvez pas assumer le coût des poids. Un petit modèle quantifié reste une ressource volumineuse. Si la taille de l’application ou le téléchargement au premier lancement constitue une contrainte réelle pour vos utilisateurs, cette contrainte peut trancher la question à elle seule.
• Il vous faut le chemin le moins gourmand en énergie du Neural Engine pour un modèle figé. Pour un modèle connu, livré et immuable, Core ML et son convertisseur ciblent le Neural Engine avec la consommation et la latence les plus serrées ; sur iOS 27, Core AI est la direction affichée par Apple pour tout nouveau travail sur les réseaux de neurones, avec un contrôle explicite de la spécialisation. MLX brille par sa souplesse et par une itération digne de la recherche ; les frameworks système brillent sur un modèle de production verrouillé. Ce sont des outils différents, et « l’apprentissage automatique embarqué » n’est pas une décision unique.
• Vous ne l’entretiendrez pas. Votre propre modèle signifie que ses mises à jour, sa sécurité et sa dérive vous incombent. Apple met le modèle système à jour pour vous. Si vous n’avez pas les moyens humains d’assumer un modèle, n’en adoptez pas.

La compétence que récompense MLX, c’est la retenue quant au moment de l’employer. Le framework est réellement remarquable : un vrai modèle de langage, affiné pour votre domaine, tournant intégralement sur l’appareil sans serveur ni coût au token, sur un matériel dont l’architecture mémoire a été conçue précisément pour cela. Cette capacité mérite qu’on aille la chercher lorsqu’on en a nommé la raison. Allez la chercher sans raison, et vous aurez échangé le modèle gratuit, maintenu et intégré d’Apple contre une copie plus lourde, non maintenue, qui vous appartient désormais. Le discernement, c’est tout le métier.

FAQ

Qu’est-ce que le framework MLX d’Apple ?

MLX est un framework de calcul matriciel pour l’apprentissage automatique sur Apple Silicon, doté d’une API de type NumPy, de transformations de fonctions composables (différenciation automatique, vectorisation), d’un calcul paresseux et d’un backend Metal². MLX Swift est l’API Swift qui permet de l’intégrer dans des applications, afin d’exécuter et d’affiner vos propres modèles directement sur l’appareil.

Comment MLX exploite-t-il la mémoire unifiée d’Apple Silicon ?

Les tableaux MLX résident en mémoire partagée : les opérations s’exécutent donc sur le CPU ou le GPU sans copier les données entre des espaces mémoire distincts³. C’est précisément cette absence de transfert qui rend l’architecture à mémoire unifiée d’Apple Silicon efficace pour l’exécution de modèles sur l’appareil.

Puis-je exécuter un LLM open-weight sur l’appareil avec MLX ?

Oui. LLMModelFactory.shared.loadContainer(from:using:configuration:) charge un modèle quantifié tel que mlx-community/Llama-3.2-3B-Instruct-4bit depuis le Hub Hugging Face ; ChatSession vous donne respond(to:) pour les appels uniques, et container.generate(input:parameters:) diffuse des événements .chunk(text) pour une sortie incrémentale⁴.

Comment affiner un modèle avec MLX ?

Avec un adaptateur LoRA plutôt qu’un nouveau modèle. LoRAContainer.from(directory:) charge un adaptateur depuis un dossier contenant adapter_config.json et adapters.safetensors ; appliqué via container.update, il remplace les couches Linear du modèle par des couches LoRALinear et autorise la permutation à chaud des adaptateurs pendant l’exécution⁵.

MLX, Foundation Models ou Core ML : lequel choisir ?

Par défaut, Foundation Models dès que le modèle système d’Apple sait faire la tâche (gratuit, confidentiel, aucun poids à livrer)¹. Ne vous tournez vers MLX que s’il vous faut un modèle que le système ne fournit pas : un LLM open-weight précis, une version figée, un affinage métier, ou une architecture hors du périmètre de Foundation Models. Retenez Core ML pour un modèle de production verrouillé qui exige le chemin le moins gourmand en énergie du Neural Engine, Core AI sur iOS 27 lorsque vous voulez une exécution gérée par le système de votre propre modèle avec un contrôle explicite de la spécialisation et de l’ordonnancement, et le cloud quand le modèle doit véritablement être de la taille des modèles de pointe.

Quand faut-il éviter MLX ?

Quand le modèle système sait déjà le faire, quand vous ne pouvez pas assumer la livraison de gigaoctets de poids, quand un modèle figé serait mieux servi par le chemin Neural Engine à faible consommation de Core ML, ou quand vous n’avez pas les moyens humains d’assumer les mises à jour, la sécurité et la dérive d’un modèle. MLX est une descente délibérée d’un cran pour une raison nommée, pas une meilleure valeur par défaut.