Core ML vs MLX vs Foundation Models : choisir la pile d'IA embarquée d'Apple

Apple propose désormais quatre façons distinctes d’exécuter un modèle sur le matériel de vos utilisateurs, et se tromper de choix coûte une réécriture. Sur le M2 Max depuis lequel j’écris ces lignes, MLX maintient 11.2 TFLOPS de calcul matriciel fp16 et déplace les données à 351 GB/s de bande passante mémoire unifiée mesurée¹. Pour la plupart des applications, cette puissance est le mauvais choix, car le framework Foundation Models intégré fait le travail en six lignes de Swift, sans ajouter le moindre mégaoctet au téléchargement. Les quatre frameworks ne sont pas concurrents. Ce sont quatre réponses différentes à une seule question : à qui appartient le modèle, et qui gère l’exécution ?

TL;DR

• Foundation Models est le choix par défaut. Si le LLM embarqué d’Apple, un généraliste de ~3B paramètres, peut accomplir la tâche (résumer, extraire, classer, générer une sortie structurée, appeler vos outils), vous ne livrez aucun poids de modèle, ne payez aucun coût d’inférence et héritez gratuitement de chaque mise à niveau du modèle au niveau du système.²
• Core ML sert à livrer votre modèle entraîné à l’intérieur d’une application. C’est la seule voie qui offre une répartition de premier ordre sur le Neural Engine, un empaquetage compatible avec l’App Store et un contrat de compilation anticipée qui échange de la souplesse contre de l’autonomie et de la prévisibilité.³
• MLX intervient quand le modèle est le produit : recherche, fine-tuning, exécution de LLM à poids ouverts, ou toute charge de travail exigeant un contrôle direct sur les tenseurs. C’est un outil pour machine de développement et application Mac, pas un véhicule de livraison iOS.⁴
• Core AI (iOS 27) est le nouveau socle sous l’ensemble : un framework d’exécution de modèles bas niveau, avec des tenseurs NDArray et un ciblage explicite des unités de calcul, destiné aux équipes qui détournent aujourd’hui Core ML en runtime de tenseurs.
• La décision tient généralement en une question : modèle intégré → Foundation Models ; votre modèle sur iOS → Core ML ; votre modèle sur votre Mac → MLX ; contrôle au niveau des tenseurs sur iOS → Core AI. Le reste de cet article traite des 20 % de cas où cette heuristique casse.

La question derrière la question

Chaque débat « quel framework ? » auquel j’ai assisté se ramène à deux axes. (J’ai écrit une analyse approfondie pour chacun d’eux : Foundation Models, Core ML, MLX, Core AI.)

Premier axe : à qui appartiennent les poids ? Le modèle intégré d’Apple, un modèle que vous avez entraîné ou converti, ou des poids ouverts récupérés sur un hub. Foundation Models n’exécute jamais que le modèle d’Apple (plus vos adaptateurs de type LoRA).⁵ Core ML et MLX n’exécutent jamais que les poids que vous fournissez. Ce seul fait élimine la moitié de l’espace des options avant même que la performance n’entre dans la conversation.

Deuxième axe : qui possède l’exécution ? Foundation Models masque tout : ni tenseurs, ni unités de calcul, ni gestion de la fenêtre de contexte au-delà d’un objet de session. Core ML masque l’essentiel : vous lui remettez un .mlmodelc compilé et suggérez des unités de calcul ; le framework décide de la répartition. MLX ne masque rien : vous écrivez le calcul sur les tableaux, et l’évaluation paresseuse conjuguée à la mémoire unifiée constitue votre outillage. Core AI se situe entre Core ML et MLX : tenseurs explicites et ciblage des unités de calcul, mais exécution gérée par Apple.

Placez n’importe quelle fonctionnalité réelle sur ces deux axes et le framework se choisit tout seul.

Foundation Models : le choix par défaut à zéro mégaoctet

Le framework que la plupart des équipes devraient essayer en premier est celui qui ne réclame aucun modèle. Foundation Models expose le LLM embarqué derrière Apple Intelligence via LanguageModelSession, et sa fonctionnalité maîtresse n’est pas le modèle. C’est la génération guidée : annotez une struct Swift avec @Generable et le framework contraint le décodage pour que la sortie du modèle soit votre type, au lieu d’une chaîne que vous analysez en croisant les doigts.²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

Voilà toute l’intégration. Aucune étape de téléchargement, aucune décision de quantification, aucune contrainte thermique à anticiper ; l’OS planifie le modèle, le partage entre toutes les applications de l’appareil et le met à niveau à chaque version. L’appel d’outils permet au modèle d’invoquer des fonctions que vous définissez, ce qui suffit à construire de véritables fonctionnalités agentiques sans le moindre serveur.²

La contrainte est symétrique : le modèle est un généraliste de ~3B paramètres. Il résume, extrait, classe et produit correctement des sorties structurées ; il ne fait pas de connaissance générale du monde en domaine ouvert, ni d’analyse documentaire à long contexte, ni rien de ce que fait un modèle de frontière. Quand le modèle intégré ne suffit pas, la réponse d’Apple tient dans les adaptateurs (des fine-tunes de type LoRA que vous entraînez avec la boîte à outils d’Apple par-dessus le modèle de base), mais un adaptateur est un engagement : vous le réentraînez chaque fois qu’Apple fait évoluer le modèle de base.⁵ Mon démontage complet, y compris la gestion des sessions et les modes de défaillance que rencontrent les relecteurs, se trouve dans l’analyse approfondie de Foundation Models.

À privilégier quand : la tâche est de nature langagière, le modèle intégré atteint votre niveau d’exigence, et livrer zéro poids compte. Cela concerne davantage de fonctionnalités que la plupart des équipes ne le supposent ; essayez-le avant de vous tourner vers quoi que ce soit d’autre ci-dessous.

Core ML : votre modèle, l’exécution d’Apple

Core ML répond à une tout autre question. Vous avez déjà un modèle (un classifieur visuel, un modèle d’embeddings, un pipeline de parole, un LLM distillé), et il doit tourner dans une application iOS, sur batterie, dans les limites de taille de l’App Store, cette année.

Le contrat, c’est la compilation anticipée. Vous convertissez les poids avec coremltools, le modèle se compile en .mlmodelc, et à l’exécution le framework répartit le travail entre Neural Engine, GPU et CPU ; l’ANE est la partie qu’aucun autre élément de cette liste ne vous donne sur iOS aujourd’hui. L’étape de conversion est là où se joue la véritable ingénierie : couverture des opérateurs, quantification (palettisation, linéaire en 8/4 bits, sparsité ; la pile d’optimisation de coremltools est vraiment fournie⁶), et le réglage des unités de calcul qui décide si votre modèle tourne à 2 watts ou à 8. Les schémas qui survivent réellement à la production (indications de répartition, budgets de latence, échelle de quantification) font l’objet du pilier Core ML.

Ce que Core ML ne fait pas porte tout autant : il n’entraîne pas, il ne fine-tune pas, et il ne vous donne pas de tenseurs en plein graphe. C’est un appareil d’inférence. Les équipes qui ont besoin d’« exécuter mon graphe ET fouiller les résultats intermédiaires » ont historiquement tordu Core ML en runtime de tenseurs ; c’est précisément cette contorsion que Core AI existe désormais pour absorber.

À privilégier quand : les poids sont les vôtres, la cible est iOS/iPadOS (ou multiplateforme Apple), et l’autonomie, la taille ou l’ANE comptent. Autrement dit : presque toutes les fonctionnalités à modèle personnalisé livrées sur la plateforme.

MLX : la machine de recherche dans votre Mac

MLX est l’intrus de la liste : un framework de tableaux open source issu du groupe de recherche en ML d’Apple, et non un framework de l’OS.⁴ Il ressemble à NumPy, évalue paresseusement, et traite la mémoire unifiée d’Apple silicon comme la fonctionnalité qu’elle est : aucune copie de l’hôte vers le périphérique, puisqu’il n’existe pas de mémoire de périphérique séparée.

Les chiffres relevés sur cette machine rendent l’argument concret. Un M2 Max maintient 11.2 TFLOPS de matmul fp16 en 4096×4096 et 351 GB/s de bande passante de streaming mesurée sous MLX sans le moindre réglage¹ : de quoi exécuter interactivement des modèles à poids ouverts quantifiés de 30B paramètres, fine-tuner des modèles de 7B avec LoRA en une nuit, et itérer sur des entraînements qui exigeraient sinon de louer des GPU dans le cloud. Grâce à l’écosystème mlx-lm, la plupart des modèles ouverts ne sont qu’à un pip install et un téléchargement de distance.

Les limites sont tout aussi concrètes. Pas de Neural Engine : MLX programme le GPU (et le CPU), pas l’ANE. Aucune perspective de livraison iOS : vous pouvez techniquement l’embarquer, mais la distribution des poids, la thermique et les règles de validation en font le mauvais outil ; MLX est fait pour votre Mac, les Mac de vos utilisateurs et votre boucle de recherche. Et personne ne gère l’exécution à votre place : pression mémoire, choix de quantification et planification des évaluations vous appartiennent. Le pilier MLX explique quand « mon propre modèle, pas celui d’Apple » vaut cette prise en charge.

À privilégier quand : vous entraînez ou fine-tunez, vous exécutez des LLM à poids ouverts en local, ou vous construisez des outils natifs Mac où le contrôle du modèle est le produit. Si votre machine quotidienne est un Mac Apple silicon avec de la vraie RAM, MLX en fait une véritable station de travail ML.

Core AI : le nouveau socle

iOS 27 a ajouté la couche qui manquait à Apple : Core AI, un framework d’exécution de modèles bas niveau doté de tenseurs NDArray, d’une séparation entre asset et modèle, d’un ciblage explicite des unités de calcul et de fonctions d’inférence appelables.⁷ C’est ce que vous utilisez quand le contrat de Core ML, « donnez-moi un modèle compilé, recevez des prédictions », devient trop rigide : pipelines qui entrelacent calcul tensoriel et appels de modèle, pré-traitements et post-traitements personnalisés qui ont leur place sur l’ANE, graphes multi-modèles à tampons partagés.

Deux précisions épargnent à la plupart des lecteurs un mauvais virage. Core AI n’est pas une alternative à Foundation Models (il n’y a toujours pas de LLM intégré à cette couche ; vous apportez des assets compilés). Et ce n’est pas MLX porté sur iOS : pas d’entraînement, pas d’autograd, pas de boucle de recherche eager. C’est la salle des machines de Core ML avec la trappe ouverte. Si vous ne vous êtes jamais battu avec l’abstraction de Core ML, vous n’avez pas besoin de Core AI ; dès l’instant où vous avez livré des acrobaties MLMultiArray ou enchaîné des modèles au prix de conversions inutiles, c’est déjà le cas. Le modèle de tenseurs et l’API de ciblage sont traités dans le pilier Core AI.

Les cas qui font vraiment débat

« Il nous faut un LLM, mais le nôtre, ou un plus gros. » Foundation Models ne peut pas charger de poids externes, point final. Un petit LLM distillé via Core ML fonctionne et vous donne l’ANE ; un modèle ouvert quantifié via MLX fonctionne sur Mac. Soyez honnête sur l’alternative que personne, dans le camp de l’embarqué, ne veut dire à voix haute : si la tâche exige une qualité de frontière, la réponse est un appel serveur, et les couches embarquées gèrent le repli et les sous-ensembles sensibles à la vie privée.

« Nous voulons une seule pile pour l’iPhone et le Mac. » Foundation Models et Core ML sont tous deux multiplateformes au sein de l’écosystème Apple ; MLX est en pratique réservé au Mac. Les équipes qui livrent une application Mac professionnelle assortie d’un compagnon iOS retiennent couramment MLX pour le Mac (gros modèles, poids fournis par l’utilisateur) et Core ML ou Foundation Models sur iOS : même fonctionnalité, deux moteurs, un aveu honnête que les appareils sont différents.

« Nous avons déjà un pipeline Core ML ; Core AI est-il une cible de migration ? » Seulement là où le pipeline fait mal. Core AI absorbe les bords de nature tensorielle ; le cœur en modèle compilé qui fonctionne aujourd’hui continue de fonctionner. Migrer en bloc un déploiement Core ML en bonne santé n’apporte rien.

« SwiftData ou App Intents changent-ils quelque chose à tout cela ? » Adjacents, pas superposés : votre couche modèle alimente des fonctionnalités que App Intents expose au système, et tout ce que vous persistez obéit aux règles de schéma de SwiftData. Les frameworks présentés ici décident comment l’inférence s’exécute, pas comment se construit l’application qui l’entoure.

Un arbre de décision

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

Points clés à retenir

Pour les équipes applicatives qui livrent des fonctionnalités : - Prototypez d’abord avec Foundation Models ; six lignes de Swift, c’est l’expérience la moins coûteuse possible, et « le modèle intégré suffit » est la surprise la plus fréquente. - Budgétez le temps de conversion Core ML séparément du temps d’inférence ; la couverture des opérateurs et la quantification sont là où passent les semaines.

Pour les ingénieurs ML : - Un Mac Apple silicon avec 64GB+ est un vrai banc de fine-tuning sous MLX ; mesurez avant de louer des GPU dans le cloud. Les chiffres de 11.2 TFLOPS / 351 GB/s cités plus haut proviennent d’une puce de portable vieille de deux générations.¹ - L’ANE reste le fossé défensif de Core ML, et désormais de Core AI. Si la consommation par inférence compte, aucune voie GPU ne rivalise.

Pour les architectes : - Traitez les quatre frameworks comme des couches, pas comme des rivaux : Foundation Models pour les fonctionnalités langagières, Core ML pour les modèles personnalisés livrés, Core AI pour les bords tensoriels, MLX pour le Mac et le labo. Les déploiements mixtes sont la norme dans les applications sérieuses, pas un signal d’alarme. - La propriété du modèle est le vrai centre de coûts à long terme : Apple maintient les poids de Foundation Models, vous maintenez ceux de tout le reste. Intégrez cela au calcul du choix.

Questions fréquentes

Quel framework Apple utiliser pour exécuter un modèle en local ?

La décision tient généralement en une question. Modèle intégré : utilisez Foundation Models ; votre modèle sur iOS : utilisez Core ML ; votre modèle sur votre Mac : utilisez MLX ; contrôle au niveau des tenseurs sur iOS : utilisez Core AI. Placez la fonctionnalité sur deux axes, à qui appartiennent les poids qu’elle exécute et qui possède l’exécution, et le framework se choisit tout seul. Traitez les quatre comme des couches, pas comme des rivaux ; les déploiements mixtes sont la norme dans les applications sérieuses.

Foundation Models peut-il exécuter mes propres poids de modèle ?

Non. Foundation Models n’exécute jamais que le modèle embarqué d’Apple, un généraliste d’environ 3B paramètres, plus vos adaptateurs de type LoRA. Il ne peut pas charger de poids externes, point final. Si vous avez besoin de votre propre LLM, un petit modèle distillé via Core ML fonctionne et vous donne le Neural Engine, et un modèle ouvert quantifié via MLX fonctionne sur le Mac. Si la tâche exige une qualité de frontière, la réponse est un appel serveur.⁵

Puis-je livrer MLX à l’intérieur d’une application iOS ?

Pas de façon réaliste. MLX est un framework de tableaux open source issu du groupe de recherche en ML d’Apple plutôt qu’un framework de l’OS, il programme le GPU et le CPU sans aucun accès au Neural Engine, et la distribution des poids, la thermique et les règles de validation en font le mauvais outil pour un bundle iOS. MLX est fait pour votre Mac, les Mac de vos utilisateurs et votre boucle de recherche.⁴

Quelle est la différence entre Core ML et Core AI ?

Core ML, c’est de l’inférence à compilation anticipée : vous lui remettez un .mlmodelc compilé, vous suggérez des unités de calcul, et le framework décide de la répartition. Core AI, ajouté dans iOS 27, c’est cette même salle des machines avec la trappe ouverte : tenseurs NDArray, séparation entre asset et modèle, et ciblage explicite des unités de calcul. Il ne fait toujours aucun entraînement et ne livre aucun LLM intégré. Si vous ne vous êtes jamais battu avec l’abstraction de Core ML, vous n’en avez pas besoin.⁷

Quelle est la vitesse d’un M2 Max pour le machine learning en local ?

Sur le M2 Max depuis lequel j’écris ces lignes, MLX maintient 11.2 TFLOPS de matmul fp16 en 4096×4096 et 351 GB/s de bande passante de streaming mesurée, sans aucun réglage. C’est assez pour exécuter interactivement des modèles à poids ouverts quantifiés de 30B paramètres et pour fine-tuner des modèles de 7B avec LoRA en une nuit. Mesurez avant de louer des GPU dans le cloud ; ces chiffres proviennent d’une puce de portable vieille de deux générations.¹

Références