Inférence Core ML sur l'appareil : les patterns qui partent vraiment en production

Core ML est le moteur d’inférence sur l’appareil livré avec chaque appareil Apple moderne. Le framework aiguille le calcul vers le Neural Engine lorsqu’il est disponible, vers le GPU sinon, et vers le CPU en dernier recours, en choisissant automatiquement le chemin le plus rapide selon le modèle et le matériel¹. Sur un iPhone récent, on obtient une inférence dont la latence va de la sous-milliseconde à quelques dizaines de millisecondes pour la plupart des tailles de modèles en production, gratuite à chaque appel, sans aller-retour réseau et sans exposition de données à des tiers.

La réputation de « plomberie obscure » attachée au framework est datée. Core ML alimente depuis près de dix ans des fonctionnalités exécutées sur l’appareil, de la recherche sémantique de Photos à la plupart des applications tierces qui embarquent du ML local, et il reste la surface de production d’un modèle figé et converti, sur tous les systèmes jusqu’à iOS 11. Sa place dans la pile a toutefois bougé à la WWDC 2026 : Apple a présenté Core AI comme le framework de bas niveau qui alimente Apple Intelligence sur l’appareil, et l’a désigné comme la direction à suivre pour les nouveaux travaux sur les réseaux de neurones¹¹¹². Les patterns qui font qu’un déploiement Core ML part réellement en production, au lieu de se limiter à « ça marche sur mon Mac », n’ont pas changé et restent peu nombreux : conversion de modèle, orientation de la répartition, budgétisation de la latence et quantification. Cet article passe chacun d’eux en revue à la lumière de la documentation d’Apple, puis situe Core ML dans la pile d’après la WWDC26.

TL;DR

• Core ML exécute des fichiers .mlpackage et .mlmodel sur le Neural Engine, le GPU et le CPU d’Apple Silicon. La répartition est automatique, mais elle peut être orientée par MLModelConfiguration.computeUnits².
• La conversion de modèle passe par coremltools (PyTorch, TensorFlow, ONNX → Core ML). La conversion relève de l’outillage, pas de l’exécution ; une fois le modèle converti et embarqué, l’application le charge et l’exécute.
• L’architecture à mémoire unifiée d’Apple Silicon signifie que les poids du modèle ne sont pas copiés entre le CPU, le GPU et le NE : la même mémoire alimente les trois³. C’est ce détail architectural qui rend possible une inférence sous la milliseconde.
• La quantification (INT8, INT4 dans les versions récentes de Core ML) réduit la taille du modèle et accélère l’inférence sur le Neural Engine, au prix d’une perte de précision mesurable qui dépend du modèle. coremltools 9.0 (novembre 2025) ajoute des cibles de déploiement iOS 26, la lecture et l’écriture de l’état du modèle, ainsi que des entrées et sorties de modèle en int8¹³.
• La pile a changé à la WWDC 2026 : Apple positionne Core AI comme le framework d’inférence derrière Apple Intelligence sur l’appareil et comme la surface des nouveaux travaux sur les réseaux de neurones, Core ML restant la couche de production des modèles figés et convertis et du ML traditionnel¹¹¹².

Le modèle mental : trois chemins de calcul, une seule mémoire

Apple Silicon (Mac de la série M et iPhone de la série A depuis l’A12 Bionic) embarque trois cibles d’inférence :

Neural Engine. Un accélérateur spécialisé dans la multiplication matricielle à faible précision. Le plus rapide pour les opérations dont dépendent les modèles de ML modernes (convolutions, attention, embeddings). Consommation la plus faible. Limité à certains types d’opérations et à certaines formes de tenseurs ; les opérations non prises en charge basculent couche par couche vers le GPU ou le CPU.

GPU. Calcul parallèle généraliste via Metal. Plus lent que le Neural Engine sur les travaux de forme ML, mais plus rapide que le CPU. Il prend en charge les opérations que le Neural Engine ne gère pas.

CPU. Le repli. Lent pour l’inférence ML, mais toujours disponible, toujours capable de traiter n’importe quelle opération, et prévisible.

L’architecture à mémoire unifiée signifie que la même mémoire vive physique alimente les trois³. Les poids d’un modèle, chargés une seule fois, ne sont pas recopiés lorsque la répartition passe d’une cible à l’autre. C’est ce fait architectural qui transforme la répartition multi-cibles : au lieu d’un coût de copie par couche, il s’agit d’une décision d’ordonnancement par couche.

MLModelConfiguration.computeUnits contrôle la répartition :

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all est la valeur par défaut et le bon choix pour presque toutes les applications. Le framework retient le chemin le plus rapide opération par opération, et cette décision par opération vaut mieux que n’importe quelle heuristique écrite à la main. Les rares raisons de passer outre : forcer .cpuOnly pour une parité de test (un modèle se comporte différemment selon le chemin et le test exige le chemin déterministe) ou forcer .cpuAndGPU afin de libérer le Neural Engine pour une autre tâche concurrente.

Conversion de modèle : la tâche d’outillage

La plupart des modèles de ML sont entraînés dans PyTorch, dans TensorFlow ou directement avec Create ML d’Apple. Core ML accepte les fichiers .mlpackage, le format moderne introduit avec Xcode 13 qui remplace l’ancien .mlmodel⁴. La conversion passe par coremltools, le paquet Python open source d’Apple⁵.

Une conversion typique de PyTorch vers Core ML suit trois étapes :

1. Charger le modèle PyTorch entraîné et le placer en mode inférence.
2. Tracer le modèle avec un tenseur d’entrée d’exemple correspondant à la forme d’entrée de production.
3. Convertir le modèle tracé avec coremltools en visant une version iOS de déploiement.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

La conversion a lieu une seule fois, dans un environnement de développement, en visant une version iOS de déploiement (minimum_deployment_target). Le .mlpackage produit est ce que l’on dépose dans le projet Xcode. L’application n’exécute pas coremltools à l’exécution. La version actuelle, coremltools 9.0, ajoute des cibles de déploiement jusqu’à iOS 26, la possibilité de lire et d’écrire l’état du modèle (pour les modèles à état comme les décodeurs de transformeurs avec caches KV), les entrées et sorties de modèle en int8, ainsi que la prise en charge de Python 3.13 et de PyTorch 2.7¹³.

Deux pièges pratiques lors de la conversion. D’abord, les entrées de forme dynamique exigent un traitement explicite via ct.RangeDim, car la forme statique retenue par défaut par Core ML produit des erreurs peu utiles dès que l’application de production lui fournit des tailles d’entrée variables. Ensuite, les opérations personnalisées de PyTorch sans équivalent Core ML réclament soit une couche personnalisée Core ML (du code Swift qui exécute l’opération manquante), soit une modification de l’architecture du modèle qui retire l’opération avant la conversion. Les deux cas sont bien documentés⁵.

Des budgets de latence qui s’appliquent vraiment

Trois budgets de latence comptent pour les applications en production :

16 ms (interface en direct à 60 fps). Un filtre de caméra en temps réel, une scène AR mise à jour à chaque image, un analyseur audio en direct. Le budget couvre tout : prétraitement de l’image, inférence du modèle, post-traitement, mise à jour de l’interface. Les modèles qui tiennent dedans sont généralement petits (classe MobileNetV3, moins de 100 M de paramètres) et s’exécutent sur le Neural Engine.

100 ms (interface interactive). L’utilisateur effectue une action et attend le résultat : toucher pour identifier, dessiner pour reconnaître, dicter pour transcrire. Le budget est plus permissif et supporte des modèles plus gros. Les modèles de langage de moins d’un milliard de paramètres, les petits transformeurs de vision et la plupart des classifieurs de qualité production y tiennent confortablement.

1 s et plus (arrière-plan ou traitement par lots). Indexation de la photothèque, analyse de documents, préchauffage du modèle au lancement de l’application. Les modèles plus gros fonctionnent, mais il faut cadrer l’attente de l’utilisateur avec un indicateur de progression. Le LLM sur l’appareil de Foundation Models se situe ici pour les opérations à grande fenêtre de contexte.

Ces budgets sont des repères, pas des limites strictes. Le bon réflexe est de mesurer sur un appareil cible avec os_signpost ou le modèle Core ML d’Instruments⁶ plutôt que de se fier à des chiffres théoriques venus d’une autre machine.

Quantification : quand plus petit veut dire plus rapide

Core ML prend en charge plusieurs niveaux de quantification⁷:

• Float32 (pleine précision). La valeur par défaut à l’entraînement. Le plus volumineux, le plus précis, le plus lent.
• Float16. Demi-précision. Plus compact et plus rapide sur le GPU et le NE ; la perte de précision est généralement négligeable pour les modèles bien conditionnés.
• INT8. Quantification entière sur 8 bits avec calibration. Environ 4x plus compact que Float32, souvent 2-4x plus rapide sur le NE. La perte de précision varie ; pour les modèles de vision, une perte de précision top-1 inférieure à 1 % est atteignable avec un entraînement tenant compte de la quantification.
• INT4 et en dessous. Quantification agressive que les versions récentes de Core ML prennent en charge pour certaines architectures (LLM, grands modèles de vision). La contrepartie est une perte de précision importante ; la technique donne son meilleur résultat associée à un entraînement tenant compte de la quantification et adapté au modèle.

La configuration de la quantification linéaire via coremltools.optimize.coreml.linear_quantize_weights accepte une configuration d’opérations globale qui choisit le mode de quantification (linear_symmetric ou linear) ainsi qu’un seuil de taille de poids en dessous duquel les poids restent en pleine précision. La conversion s’applique à un .mlpackage existant et produit un nouveau paquet quantifié ; les deux peuvent cohabiter dans le bundle, l’application choisissant lequel charger selon la classe de l’appareil.

La décision de quantifier se prend modèle par modèle : un petit classifieur n’en tirera peut-être aucun bénéfice, son calcul étant déjà bon marché ; un grand modèle de langage en tire un bénéfice énorme, son calcul étant dominé par les multiplications matricielles sur les poids quantifiés. La bonne approche consiste à quantifier, à mesurer la précision sur un jeu de test mis de côté, puis à livrer si la perte de précision reste acceptable pour l’usage visé.

Les modèles intégrés d’Apple que vous pouvez reprendre tels quels

Apple propose plusieurs modèles Core ML pré-entraînés sur la page Core ML Models⁸. Les catégories à connaître :

• Classification d’images : MobileNetV2, ResNet50, variantes de SqueezeNet, toutes prêtes à être déposées dans un VNCoreMLRequest du framework Vision.
• Détection d’objets : YOLOv3, MNIST, variantes de CenterNet.
• Estimation de pose : PoseNet pour la pose corporelle (une solution de référence face au VNDetectHumanBodyPoseRequest de Vision).
• Segmentation sémantique : DeepLabV3 pour la segmentation d’images.
• Reconnaissance de texte : des alternatives OCR fondées sur le ML à la reconnaissance intégrée de Vision.

Pour la plupart des applications, les modèles pré-entraînés d’Apple couvrent les primitives de perception (classer, détecter, segmenter) sans exiger d’entraînement sur mesure. Pour les tâches de langage, le LLM sur l’appareil du système se place entièrement au-dessus de cette couche : le framework Foundation Models l’expose derrière une API Swift de haut niveau, hors ligne et gratuite, sans fichier de modèle à embarquer ni à convertir.

Chiffrement des modèles et considérations App Store

Un .mlpackage présent dans le bundle de l’application est lisible par quiconque décompresse l’IPA. Pour les modèles qui représentent une propriété intellectuelle réelle, Apple prend en charge le chiffrement de modèle via la procédure Encrypt your Core ML model⁹: une clé de chiffrement est générée depuis Xcode et gérée via CloudKit, le modèle présent dans le bundle est chiffré, et Core ML le déchiffre au chargement.

Pour la plupart des applications, le chiffrement est excessif. Un modèle entraîné sur des données ImageNet banales n’est pas un facteur de différenciation concurrentielle ; le chiffrer ajoute de la complexité opérationnelle sans rien protéger de précieux. Réservez le chiffrement aux modèles qui incarnent un vrai investissement en données d’entraînement ou un avantage concurrentiel.

Confidentialité sur l’appareil : le gain architectural

L’argument de confidentialité est direct. L’inférence Core ML se déroule entièrement sur l’appareil. Les données d’entrée (images, audio, texte) ne quittent pas l’appareil. Le fichier de modèle est local ; l’inférence est locale ; le résultat est local.

Pour les applications de secteurs réglementés (santé, finance, éducation), ce fait architectural élimine toute une catégorie de travail de conformité. Il n’y a aucun sous-traitant de données tiers à ajouter à une politique de confidentialité. Il n’y a aucun point de terminaison d’API de modèle dont il faut évaluer la sécurité. Il n’y a aucune question de localisation des données, puisque les données ne bougent jamais.

Le format Privacy Manifest¹⁰ formalise cet argument pour la soumission à l’App Store : une application qui utilise Core ML pour l’inférence sur l’appareil, et rien d’autre, peut déclarer un partage de données avec des tiers nul pour le chemin d’inférence. La soumission est plus rapide, l’examen de confidentialité plus court et l’étiquette de confidentialité affichée à l’utilisateur plus propre.

Le lien avec les workflows d’agents

Core ML se combine avec trois patterns que ce cluster a déjà traités :

Le VNCoreMLRequest du framework Vision. Les modèles Core ML personnalisés passent par le pipeline Vision avec un prétraitement automatique. Ce pattern (traité dans Vision Framework) est la bonne façon de livrer un classifieur ou un détecteur d’images sur mesure dans une application iOS.

Le LLM sur l’appareil de Foundation Models. Le LLM système d’Apple Intelligence se trouve derrière le framework Foundation Models, et depuis la WWDC 2026 Apple désigne Core AI comme le framework d’inférence qui l’alimente¹¹. Les concepts de cet article se transposent toujours directement : la répartition entre unités de calcul, les poids quantifiés et les budgets de latence régissent le LLM système exactement comme ils régissent un modèle que vous avez converti vous-même. L’article sur le framework traite l’API du LLM ; celui-ci traite les patterns d’inférence en dessous.

Les outils App Intents qui utilisent du ML local. Un AppIntent qui exécute un classifieur d’images ou de texte local renvoie des résultats structurés à Apple Intelligence sans aller-retour réseau. C’est cette combinaison qui rend un « Apple agentique » réellement privé : les outils de l’agent s’exécutent localement parce que le framework le permet.

Quand l’inférence dans le cloud est le bon choix

Le plafond de Core ML, c’est la puissance de calcul de l’appareil. Trois cas où le cloud a raison :

Des modèles trop volumineux pour être embarqués. Un LLM de 70 milliards de paramètres ne tient pas dans un bundle applicatif. À cette échelle, l’inférence dans le cloud (ou l’exécution sur l’appareil avec des poids diffusés en flux, un autre pattern) est le bon outil.

Un état partagé entre appareils pendant l’inférence. Les modèles qui doivent lire ou écrire dans une base de données partagée pendant l’inférence (systèmes de recommandation à filtrage collaboratif sur des milliards d’enregistrements). Le modèle purement local de Core ML ne convient pas.

L’itération rapide sur les modèles. Une équipe qui livre des mises à jour de modèle chaque jour gagne à faire de l’inférence côté serveur, car les déploiements n’exigent pas de cycle de validation App Store. Le schéma de Core ML, qui consiste à embarquer le modèle dans l’application, ajoute des frictions à la cadence des révisions ; ce compromis est réel.

Le pattern : le cloud l’emporte sur l’échelle et la vitesse d’itération ; Core ML l’emporte sur la latence, le coût et la confidentialité.

La place de Core ML après la WWDC 2026

La WWDC 2026 a redessiné la carte sous cet article sans l’invalider. Apple a présenté Core AI, un framework iOS 27 dont le résumé est « Run AI models in your app on Apple silicon », et a déclaré dans la session 324 que Core AI est le framework d’inférence qui alimente Apple Intelligence sur l’appareil, désormais ouvert aux applications tierces¹¹. Là où le convertisseur de Core ML prend pour vous les décisions de matériel et d’optimisation, Core AI vous tend les leviers : spécialisation explicite du modèle, cache d’artefacts géré, ciblage des unités de calcul et flux de calcul asynchrones. L’analyse complète se trouve dans Core AI : exécuter des modèles sur Apple silicon.

Le signal de direction est plus net que ne le laisse penser la documentation seule. Au group lab consacré à l’apprentissage automatique de la WWDC 2026, un ingénieur Core AI a indiqué qu’Apple demande à toutes les personnes qui travaillent sur des réseaux de neurones de passer désormais à Core AI, Core ML restant en place mais recentré sur l’apprentissage automatique traditionnel, comme les arbres de décision¹². Cette déclaration est une paraphrase issue d’un lab, pas une politique publiée, mais elle épouse la forme de la version livrée : Core AI a reçu le nouvel outillage, les nouveaux formats et la charge de travail d’Apple Intelligence.

La lecture pratique pour une application livrée aujourd’hui :

• Les déploiements Core ML existants continuent de fonctionner. Rien dans iOS 27 ne rend obsolète la voie .mlpackage, et coremltools 9.0 a apporté de nouvelles capacités (cibles iOS 26, modèles à état, entrées-sorties en int8) pas plus tard qu’en novembre 2025¹³.
• Core ML reste la seule option en dessous d’iOS 27, et l’option pragmatique pour un modèle figé et converti dont les valeurs par défaut du convertisseur vous conviennent.
• Tout nouveau travail sur les réseaux de neurones visant iOS 27+ devrait d’abord évaluer Core AI, surtout là où vous pouvez nommer la spécialisation, la mise en cache ou le contrôle d’ordonnancement dont vous avez besoin.
• Les autres couches ne bougent pas. Le LLM système reste derrière Foundation Models, et MLX reste le framework de tableaux intégrable pour les modèles à poids ouverts et les ajustements fins que vous possédez. Core ML face à Core AI, c’est une question sur la couche d’exécution de votre modèle, pas sur ces deux-là.

Ce que ce pattern implique pour les applications iOS 26+

Trois enseignements.

1. Prenez Core ML par défaut pour tout modèle qui tient dans le bundle et produit, à chaque appel, un résultat exploitable par l’utilisateur. Classification d’images, détection d’objets, classification audio, reconnaissance de gestes, génération d’embeddings, tâches de langage de petite à moyenne taille. La répartition automatique du framework et le NPU d’Apple Silicon produisent gratuitement une inférence allant de la sous-milliseconde à quelques dizaines de millisecondes.

2. Quantifiez agressivement tant que la perte de précision reste acceptable. INT8 est généralement sans danger ; INT4 convient aux grands modèles pour lesquels le gain de taille compte. Mesurez la précision sur un jeu mis de côté au lieu de supposer que la quantification est universellement sans risque.

3. Associez Vision et Foundation Models pour des pipelines entièrement locaux. Core ML est le moteur ; Vision est l’API de perception posée dessus ; Foundation Models est le LLM posé dessus. L’article sur Vision et l’article sur Foundation Models de ce cluster traitent les surfaces de plus haut niveau.

Le cluster complet sur l’écosystème Apple : les App Intents typés ; les serveurs MCP ; la question du routage ; Foundation Models ; la distinction entre LLM d’exécution et LLM d’outillage ; les trois surfaces ; le pattern de la source unique de vérité ; Deux serveurs MCP ; les hooks pour le développement Apple ; les Live Activities ; le contrat d’exécution watchOS ; les rouages de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les patterns Liquid Glass ; la livraison multiplateforme ; la matrice des plateformes ; le framework Vision ; les Symbol Effects ; ce sur quoi je refuse d’écrire. Le hub se trouve dans la série Écosystème Apple. Pour un contexte plus large sur iOS et les agents d’IA, voyez le guide de développement d’agents iOS.

Questions

Comment Core ML choisit-il entre le Neural Engine, le GPU et le CPU ?

Core ML examine chaque opération du graphe du modèle et l’affecte à la cible la plus rapide qui la prend en charge. Le Neural Engine traite les opérations supportées (la plupart des multiplications matricielles, les convolutions, l’attention) avec la latence et la consommation les plus faibles. Le GPU traite les opérations que le NE ne gère pas. Le CPU traite le reste. La décision se prend opération par opération, automatiquement, et elle vaut mieux qu’une heuristique écrite à la main.

Faut-il toujours utiliser .computeUnits = .all ?

Presque toujours. La répartition automatique du framework est bien réglée. Passez à .cpuOnly pour tester la parité des sorties (le même modèle renvoie des résultats légèrement différents sur le NE et sur le CPU, à cause des arrondis en virgule flottante) ou à .cpuAndGPU pour libérer le Neural Engine au profit d’une tâche concurrente.

Quelle est la différence pratique entre .mlpackage et .mlmodel ?

.mlpackage est le format moderne introduit avec Xcode 13. Il prend en charge les métadonnées stockées, plusieurs variantes de modèle pour la compilation ML Program (mlprogram) et la chaîne d’outils postérieure à iOS 13. .mlmodel est le format historique. Les deux se chargent toujours via MLModel ; tout nouveau développement devrait utiliser .mlpackage.

Quelle taille peut atteindre un modèle Core ML dans un bundle applicatif ?

Il n’existe pas de limite fixe, mais la taille des bundles App Store est plafonnée à 4 Go au téléchargement et se heurte à des limites pratiques pour l’installation sans fil. Le LLM sur l’appareil du système contourne entièrement la question : le système d’exploitation le distribue, et les applications l’atteignent via Foundation Models sans rien embarquer. Pour les modèles embarqués dans l’application, moins de 100 Mo est confortable ; de 100 à 500 Mo reste faisable avec une stratégie de chargement au lancement ; au-delà de 500 Mo, mieux vaut passer par un téléchargement en arrière-plan avec BGProcessingTask ou par des ressources à la demande.

Faut-il utiliser Core ML ou Core AI pour un nouveau modèle ?

En dessous d’iOS 27, Core ML est la seule option. Sur iOS 27+, la direction annoncée par Apple est Core AI pour les réseaux de neurones, Core ML continuant pour l’apprentissage automatique traditionnel et les déploiements existants¹¹¹². Si vous disposez d’un modèle figé et converti et que les valeurs par défaut du convertisseur vous conviennent, Core ML se livre encore très bien ; s’il vous faut un contrôle explicite sur la spécialisation, la mise en cache ou l’ordonnancement, c’est précisément ce contrôle que Core AI est là pour offrir.

Comment savoir si la quantification a dégradé la précision de mon modèle ?

Mettez de côté un jeu de test, exécutez l’inférence sur le modèle Float32 d’origine et sur le modèle quantifié, comparez les métriques (précision top-1 pour les classifieurs, F1 pour les détecteurs, perplexité pour les modèles de langage, BLEU pour la traduction, etc.), puis tranchez selon les exigences de précision de l’application. L’entraînement tenant compte de la quantification (entraîner le modèle avec la quantification simulée dans la fonction de perte) récupère en général l’essentiel de la précision perdue.

Références