Core AI : exécuter des modèles sur Apple Silicon

Il manquait un barreau à l’échelle de l’IA sur appareil d’Apple. Foundation Models vous donne le LLM système, scellé et gratuit. Core ML exécute un modèle converti figé, le convertisseur prenant les décisions matérielles à votre place. MLX fournit un framework de tableaux que vous intégrez et un modèle que vous choisissez. iOS 27 ajoute le barreau situé sous ces trois-là : Core AI, un framework dont le résumé en une ligne est « Run AI models in your app on Apple silicon. »¹ C’est la surface d’exécution des modèles, l’endroit où vous allez lorsque vous voulez piloter vous-même la spécialisation, la mise en cache et l’ordonnancement de l’inférence au lieu d’accepter les réglages par défaut d’une couche supérieure.

Dans la session 324, Apple présente Core AI comme le framework d’inférence qui alimente Apple Intelligence sur appareil, désormais ouvert à l’intelligence de votre propre application.¹⁵

Ce cadrage compte, car Core AI se situe sous les abstractions que la plupart des applications devraient utiliser. Apple le décrit comme conçu pour Apple silicon : il permet à votre application d’utiliser les architectures de modèles et les techniques d’inférence les plus récentes sur le CPU, le GPU et le Neural Engine, avec une API Swift qui simplifie les tâches courantes tout en vous donnant, si besoin, davantage de contrôle sur la spécialisation des modèles, la mise en cache et les performances d’inférence.¹ La thèse de cet article : tournez-vous vers Core AI lorsque vous avez un modèle à exécuter avec un contrôle explicite sur l’endroit et la manière dont il s’exécute, et restez sur Core ML ou Foundation Models dans le cas contraire. Le framework récompense un besoin précis, pas une préférence par défaut.

TL;DR / points clés

• Core AI sépare un AIModelAsset non spécialisé (inspecter à faible coût la structure et les métadonnées d’un modèle) d’un AIModel spécialisé (exécuter l’inférence sur un appareil), AIModelCache conservant les artefacts propres à l’appareil et AssetError signalant les échecs des opérations sur les assets.²³⁶⁴
• Les données d’inférence transitent par NDArray, un tableau multidimensionnel de valeurs scalaires, décrit par un NDArrayDescriptor qui fixe la forme, le type scalaire et les attentes en matière d’agencement mémoire.⁵⁷
• Vous ciblez le matériel avec ComputeUnitKind (CPU, GPU ou Neural Engine) via SpecializationOptions, et vous planifiez le travail asynchrone sur un ComputeStream.⁸⁹¹⁰
• Une InferenceFunction possède les poids et les tampons et exécute l’inférence ; un InferenceFunctionDescriptor vous permet d’inspecter au préalable sa signature d’entrées, de sorties et d’états. La fonction est Sendable, vous pouvez donc l’exécuter en parallèle.¹⁴¹³
• Les modèles se chargent depuis un bundle .aimodel sur le disque. L’outillage autour du framework est désormais documenté : le paquet Python coreai-torch convertit les modèles PyTorch, la CLI coreai-build compile .aimodel en assets .aimodelc par architecture en amont, et l’application Core AI Debugger, une jauge de débogage Xcode et un modèle Instruments couvrent l’inspection et le profilage.¹⁷ Tournez-vous vers Core AI lorsque vous avez besoin d’un contrôle explicite sur la spécialisation et l’ordonnancement ; sinon, restez sur Core ML ou Foundation Models.²¹

Deux mots qui gouvernent toute la conception : asset et modèle

La première chose que Core AI vous demande d’intégrer, c’est qu’un modèle sur le disque et un modèle qui exécute l’inférence sont deux objets différents, et que spécialiser le premier en le second coûte cher. Le framework donne à chacun son propre type.

Un AIModelAsset est « an unspecialized source model asset. »² Vous le créez à partir de l’URL d’un bundle .aimodel présent sur le disque et vous l’utilisez pour inspecter un modèle sans payer le coût de la spécialisation. Apple explique clairement pourquoi cette séparation existe : un asset de modèle vous permet d’interroger les informations du modèle sans effectuer la spécialisation, qui est une opération coûteuse. Depuis un asset, vous pouvez lire les signatures de fonctions, les descriptions d’entrée et de sortie, les types de calcul et de stockage, ainsi que les métadonnées fournies par l’auteur. Ce que vous ne pouvez pas faire, c’est exécuter l’inférence ; un asset sert uniquement à l’inspection.²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

L’AIModel est l’autre moitié : « a specialized model for running inference on a device. »³ Un AIModel représente un asset .aimodel spécialisé, optimisé pour le matériel de l’appareil courant, et vous en créez un en chargeant l’asset depuis le disque.³ L’asset répond à la question qu’est-ce que ce modèle ? ; le modèle répond exécute-le ici, maintenant. L’asymétrie de coût entre les deux explique pourquoi l’API vous force à nommer celui que vous voulez. Inspecter une centaine de modèles candidats pour en choisir un revient peu cher si vous ne construisez que des assets ; ce serait ruineux si chaque inspection entraînait une spécialisation.

La spécialisation produit des artefacts propres à l’appareil, et ces artefacts ont un foyer : AIModelCache, « a cache that stores the specialized model artifacts for inference. »⁶ Le cache conserve les artefacts optimisés, propres à l’appareil, qu’un modèle charge pour exécuter ses fonctions d’inférence, et Apple précise que chaque entrée de cache contient un asset spécialisé formé à partir d’un .aimodel ou d’un .aimodelc donné et d’une combinaison de spécialisation.⁶ Lecture pratique : la spécialisation n’est pas une opération que vous voulez répéter à chaque lancement. Le cache est le moyen par lequel Core AI fait advenir l’étape coûteuse une seule fois et l’étape bon marché — le chargement des artefacts mis en cache — toutes les fois suivantes.

Lorsque les opérations sur les assets échouent (bundle manquant, .aimodel malformé, fichier illisible), Core AI remonte une AssetError, « an error that occurs during model asset operations. »⁴ Traitez-la comme n’importe quelle frontière d’entrées-sorties : l’asset vit sur le disque, les opérations disque échouent, et le système de types vous indique exactement où placer le catch.

Tenseurs : NDArray et son descripteur

L’inférence fait entrer des nombres et en fait sortir, et le conteneur de Core AI pour ces nombres est NDArray, « a multidimensional array of scalar values used for model inference. »⁵ Si vous avez travaillé avec les ndarray de NumPy, les tableaux MLX ou MLMultiArray, la forme de l’idée vous est familière : un bloc de scalaires à n dimensions doté d’un agencement défini. Un NDArray stocke ses données selon un agencement défini par sa forme et par le reste de ses propriétés descriptives.⁵

Le type qui l’accompagne est NDArrayDescriptor, « a description of an array’s shape, scalar type, and memory layout expectations. »⁷ Un descripteur est le contrat. La formulation d’Apple est directe : le descripteur contient les attentes relatives à une valeur de tableau que vous fournissez à une fonction d’inférence, et la plupart de ces attentes sont strictes. Si le descripteur spécifie un type scalaire .float32, le tableau que vous fournissez doit utiliser .float32.⁷ Vous ne devinez pas la forme ni le type qu’attend une fonction ; vous interrogez le descripteur de la fonction et vous vous y conformez.

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

La leçon de conception reflète ici la séparation asset/modèle. Core AI place systématiquement un objet de description bon marché devant un objet de valeur coûteux. Vous lisez le descripteur pour connaître le contrat, puis vous allouez le NDArray qui le satisfait, plutôt que d’allouer d’abord et de découvrir une incompatibilité au moment de l’inférence. Pour les entrées image en particulier, Core AI définit aussi un ImageDescriptor, « a description of an image’s dimensions and pixel format », si bien que l’entrée en pixels d’un modèle de vision reçoit le même traitement, descripteur d’abord.¹¹

Choisir où s’exécute l’inférence

Apple silicon offre trois endroits où calculer : le CPU, le GPU et le Neural Engine. Si Core AI existe et pas seulement Core ML, c’est parce que Core AI vous laisse dire lequel de ces trois le framework doit cibler, au lieu de le déduire.

ComputeUnitKind est « a type of hardware compute unit available for model inference. »⁸ Vous utilisez les types d’unités de calcul avec les options de spécialisation pour contrôler le matériel que le framework cible lors de la spécialisation d’un modèle ; par défaut, la spécialisation utilise toutes les unités de calcul disponibles sur l’appareil.⁸ Ce comportement par défaut est la bonne réponse dans la plupart des cas, et c’est justement le point : vous ne le remplacez que si vous avez une raison (un chemin sensible à la latence que vous voulez épingler au Neural Engine, une passe de débogage que vous voulez forcer sur le CPU, un pipeline gourmand en GPU que vous coordonnez avec d’autres travaux GPU).

Vous transmettez cette intention via SpecializationOptions, la structure qui porte les choix effectués au moment de la spécialisation.⁹ La spécialisation est l’étape coûteuse évoquée plus haut, et c’est dans SpecializationOptions que résident le ciblage des unités de calcul et les autres décisions de spécialisation. Comme une entrée de cache est indexée sur un asset et une combinaison de spécialisation donnés, changer vos options change l’artefact mis en cache qui vous est rendu, ce qui boucle la relation entre ciblage et mise en cache.⁶

L’ordonnancement est l’autre axe du « comment cela s’exécute », et Core AI le modélise sous la forme d’un ComputeStream, « a stream of work to be run asynchronously. »¹⁰ Un flux de calcul est ce que vous fournissez pour encoder du travail dessus, et Apple précise que plusieurs inférences encodées sur le même flux sont sérialisées au besoin, selon les valeurs lues et écrites.¹⁰ Deux conséquences en découlent. D’abord, un flux est votre primitive d’ordonnancement : encodez des inférences dépendantes sur un même flux et Core AI les séquence par dépendance de données. Ensuite, le travail est asynchrone par défaut, si bien que le flux est aussi le moyen de garder le thread appelant libre pendant que le Neural Engine ou le GPU travaille.

Fonctions d’inférence : ce qui s’exécute réellement

Un .aimodel chargé n’est pas un unique appelable. Les modèles exposent des fonctions nommées (un encodeur, un décodeur, une tour de vision, une étape de prefill par opposition à une étape de decode), et l’unité d’exécution de Core AI est l’InferenceFunction : « a function that performs inference on input values and produces output values. »¹⁴

Avant d’en appeler une, vous l’inspectez. InferenceFunctionDescriptor est « a description of an inference function’s signature », et vous utilisez un descripteur pour inspecter les noms et les types des entrées, des sorties et des états d’une fonction avant d’exécuter l’inférence.¹³ Les états sont le détail sur lequel il vaut la peine de s’arrêter : une fonction dotée d’un état est le moyen par lequel un modèle à état — un cache KV dans la boucle de decode d’un transformeur, par exemple — conserve de l’information d’un appel à l’autre, et le descripteur vous signale qu’une fonction en possède avant que vous tentiez de la piloter.

L’InferenceFunction elle-même possède les ressources dont l’inférence a besoin, y compris les poids du modèle et les tampons intermédiaires. Vous chargez une fonction depuis un modèle et vous appelez run(inputs:states:outputViews:) pour effectuer l’inférence.¹⁴ La signature de run est nommée dans la discussion d’Apple elle-même, si bien que les trois éléments dont un appel a besoin sont explicites : les valeurs d’entrée, les valeurs d’état et les vues de sortie que vous voulez voir écrites.

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

Deux propriétés rendent la fonction agréable sous charge. Elle est Sendable, vous pouvez donc l’exécuter en parallèle depuis plusieurs tâches, et Apple précise qu’elle alloue automatiquement des tampons intermédiaires supplémentaires pour soutenir cette concurrence.¹⁴ Vous ne sérialisez pas les appels derrière un verrou pour protéger un espace de travail partagé ; la fonction gère ses propres tampons pour chaque appelant concurrent. C’est une différence notable par rapport aux API où un unique handle d’inférence est de fait mono-thread.

Les valeurs qui circulent dans run sont des instances d’InferenceValue, « a value that an inference function accepts as input or produces as output. »¹² Un InferenceValue enveloppe soit un NDArray, soit un tampon de pixels, et vous récupérez un résultat après l’inférence grâce à sa propriété value.¹² C’est cette enveloppe qui permet à une seule signature de run de porter à la fois des entrées tensorielles et des entrées image sans surcharges distinctes : un modèle de texte transmet des valeurs adossées à un NDArray, un modèle de vision des valeurs adossées à un tampon de pixels, et la fonction lit le descripteur pour savoir laquelle elle attend.

Quand se tourner vers Core AI

Le plus difficile avec Core AI n’est pas l’API. C’est de savoir que vous devez être ici plutôt qu’un étage plus haut. L’arbre de décision honnête :

• Foundation Models quand le modèle système d’Apple fait le travail. Résumer, classer, extraire, réécrire, produire une sortie structurée : cela relève du framework Foundation Models, qui ne vous coûte ni poids, ni budget mémoire, ni étape de spécialisation. Si votre fonctionnalité y trouve sa place, arrêtez-vous là. Descendre jusqu’à Core AI pour réimplémenter ce que le modèle système fait déjà est du travail perdu.
• Core ML quand vous avez un modèle converti et figé et que vous voulez que le convertisseur prenne les décisions matérielles et d’optimisation à votre place. Core ML cible le Neural Engine avec une consommation et une latence serrées pour un modèle de production verrouillé, et il ne vous demande rien en matière de spécialisation ou d’ordonnancement. Si vous ne voulez pas penser au ciblage des unités de calcul ni aux flux de calcul, c’est le signal qu’il faut rester sur Core ML.
• MLX quand vous voulez un framework de tableaux de qualité recherche que vous intégrez et sur lequel vous itérez : votre propre boucle d’entraînement, des modèles à poids ouverts quantifiés, des ajustements LoRA, une expérimentation rapide. MLX est une bibliothèque que vous livrez avec des poids, pas une surface système d’exécution de modèles. Il gagne sur la souplesse et la vitesse d’itération.
• Core AI quand vous avez un modèle à exécuter et que vous voulez les poignées explicites du framework : un AIModelAsset que vous inspectez avant de vous engager, des SpecializationOptions qui épinglent les unités de calcul, un AIModelCache que vous gérez, un ComputeStream sur lequel vous planifiez, et des InferenceFunction que vous appelez en parallèle. Vous venez ici quand les réglages par défaut des couches supérieures sont précisément ce qui vous gêne, et que vous savez nommer celui que vous devez remplacer.

Le fil conducteur de toute la pile : chaque couche vers le bas échange un réglage par défaut contre une poignée. Foundation Models vous donne tout et ne vous demande rien. Core AI vous tend les leviers et vous demande de savoir lequel tirer. Si vous ne savez pas nommer le contrôle de spécialisation, de mise en cache ou d’ordonnancement dont vous avez besoin, vous n’avez pas encore besoin de Core AI.

Une déclaration faite lors d’un lab de la WWDC 2026 précise où passe la frontière entre Core AI et Core ML pour les nouveaux projets. Paraphrasé à partir d’un enregistrement transcrit localement du WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab, un ingénieur Core AI présent sur le panel a dit qu’Apple demande à tous ceux qui travaillent avec des réseaux de neurones de passer à Core AI à l’avenir, Core ML restant en place mais recentré sur l’apprentissage automatique traditionnel, comme les arbres de décision, tout ce qui est nouveau se dirigeant vers Core AI.¹⁶ Lisez cela comme un signal de direction venant de ceux qui construisent le framework, et non comme une politique documentée : si vous vous tournez vers un réseau de neurones dans un nouveau projet, le lab a présenté Core AI comme la surface sur laquelle bâtir.

Comment un modèle parvient à Core AI

Le framework est la moitié « exécution » d’un flux de travail plus large, et depuis les bêtas de juin, Apple en a publié la moitié « outillage » dans son intégralité.¹⁷ Le pipeline se déroule ainsi.

Convertir. Vous partez d’un fichier .aimodel, soit converti depuis un modèle source à l’aide du paquet coreai-torch (les Core AI PyTorch Extensions d’Apple pour Python), soit déjà préparé dans ce format.¹⁷ Le .aimodel entre dans votre cible Xcode comme n’importe quelle ressource, apparaît dans la phase de build Compile Sources et bénéficie d’une visionneuse de modèle dans Xcode qui affiche les paramètres, la taille de stockage, les métadonnées et le graphe d’opérations. Une dépendance du système de build à connaître d’emblée : l’intégration de modèles Core AI exige la Metal Toolchain, que Xcode n’installe pas par défaut, et sans elle les builds contenant des fichiers .aimodel échouent avec une erreur de compilateur Metal manquant.¹⁷

Compiler en amont, facultativement. La spécialisation se produit automatiquement lorsque vous créez un AIModel, et pour les grands modèles ce coût au premier chargement est bien réel. L’outil en ligne de commande coreai-build déplace la partie la plus coûteuse, la compilation du modèle, vers votre machine de build : il convertit .aimodel en assets .aimodelc, un par architecture d’appareil (compiler MyModel.aimodel produit MyModel.<arch>.aimodelc), et à l’exécution l’application choisit l’asset correspondant à l’appareil courant, ce qui permet à Core AI de sauter l’étape de compilation.¹⁷ La compilation en amont vise le plancher matériel d’Apple Intelligence : iPhone ou iPad avec A17 Pro ou plus récent, Mac avec M1 ou plus récent, et Apple Vision Pro avec M2.¹⁷

Déboguer et profiler. Trois outils couvrent le volet observabilité : le Core AI Debugger, une application macOS autonome pour inspecter le graphe d’opérations d’un modèle, l’exécuter sur un appareil et comparer les sorties à une exécution de référence ; une jauge de débogage Core AI dans Xcode qui surveille en direct le chargement, la spécialisation et l’activité d’inférence pendant une session de débogage ; et un instrument Core AI, un modèle Instruments qui profile les temps d’exécution sur le CPU, le GPU et le Neural Engine.¹⁷

La forme d’exécution décrite plus haut s’insère telle quelle dans ce flux de travail : le modèle préparé est chargé comme AIModelAsset pour inspection, spécialisé en AIModel et exécuté via ses InferenceFunction, AIModelCache conservant les artefacts spécialisés pour que l’étape coûteuse n’ait lieu qu’une fois.¹²³⁶¹⁴

Questions

Qu’est-ce que le framework Core AI d’Apple ?

Core AI est le framework bas niveau d’iOS 27 pour exécuter des modèles d’IA sur Apple silicon, résumé par Apple ainsi : « Run AI models in your app on Apple silicon. »¹ Il exécute l’inférence de modèles sur le CPU, le GPU et le Neural Engine grâce à une API Swift qui simplifie les tâches courantes tout en vous donnant, quand vous en avez besoin, le contrôle de la spécialisation des modèles, de la mise en cache et des performances d’inférence.¹ Il se situe sous Foundation Models et Core ML comme surface d’exécution de modèles.

Quelle est la différence entre AIModelAsset et AIModel ?

AIModelAsset est un asset source non spécialisé que vous créez à partir de l’URL d’un bundle .aimodel sur le disque ; vous l’utilisez pour inspecter les signatures de fonctions, les descriptions d’entrée et de sortie, les types de calcul et de stockage et les métadonnées d’un modèle sans spécialiser, parce que la spécialisation coûte cher, et un asset ne peut pas exécuter l’inférence.² AIModel est le modèle spécialisé, optimisé pour le matériel de l’appareil courant, qui exécute réellement l’inférence ; vous en créez un en chargeant l’asset depuis le disque.³ Cette séparation vous permet d’inspecter à faible coût et de ne spécialiser qu’au moment de vous engager.

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

Vous contrôlez le ciblage matériel avec ComputeUnitKind via SpecializationOptions. Un type d’unité de calcul désigne un type d’unité matérielle disponible pour l’inférence, et vous l’utilisez pour contrôler le matériel que le framework cible lors de la spécialisation d’un modèle ; par défaut, la spécialisation utilise toutes les unités de calcul disponibles sur l’appareil.⁸⁹ Vous ne remplacez ce comportement par défaut que pour une raison précise, par exemple épingler un chemin sensible à la latence sur une unité de calcul donnée.

Qu’est-ce qu’une InferenceFunction et comment l’exécuter ?

Une InferenceFunction effectue l’inférence sur des valeurs d’entrée et produit des valeurs de sortie, en possédant les poids du modèle et les tampons intermédiaires.¹⁴ Vous inspectez d’abord sa signature au moyen d’un InferenceFunctionDescriptor, qui décrit les noms et les types des entrées, des sorties et des états de la fonction, puis vous chargez la fonction depuis un AIModel et appelez run(inputs:states:outputViews:).¹³¹⁴ La fonction est Sendable et alloue automatiquement des tampons intermédiaires pour soutenir la concurrence, de sorte que plusieurs tâches peuvent l’exécuter en même temps.¹⁴

Dois-je utiliser Core AI plutôt que Core ML ou Foundation Models ?

Utilisez Foundation Models quand le modèle système fait le travail, et Core ML quand vous avez un modèle converti et figé et que vous voulez que le convertisseur prenne les décisions matérielles et d’optimisation à votre place. Tournez-vous vers Core AI quand vous voulez un contrôle explicite sur la spécialisation (SpecializationOptions, ComputeUnitKind), la mise en cache (AIModelCache) et l’ordonnancement (ComputeStream) que les couches supérieures gèrent pour vous.⁸⁹⁶¹⁰ Si vous ne savez pas nommer le contrôle dont vous avez besoin, restez un étage plus haut.

L’ensemble du cluster Écosystème Apple : MLX sur Apple Silicon pour le framework de tableaux que vous intégrez lorsque vous voulez votre propre modèle et votre propre boucle d’entraînement ; le TBDR et la mémoire unifiée d’Apple Silicon pour le substrat matériel qui rend possible le partage entre CPU, GPU et Neural Engine ; l’inférence sur appareil avec Core ML pour la couche à modèle figé située au-dessus de Core AI ; et Foundation Models pour le LLM système scellé d’Apple, au sommet de la pile. Le point central 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.

Références