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

La pile d’IA on-device d’Apple avait un barreau manquant. Foundation Models vous donne le LLM système, scellé et gratuit. Core ML exécute un modèle converti fixe, 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 couches : Core AI, un framework dont le résumé en une ligne est « Exécutez des modèles d’IA dans votre app sur Apple silicon ».¹ C’est la surface d’exécution des modèles, l’endroit que vous atteignez lorsque vous voulez piloter vous-même la spécialisation, la mise en cache et la planification de l’inférence au lieu d’accepter les valeurs par défaut d’une couche supérieure.

Dans la session 324, Apple positionne Core AI comme le même framework d’inférence qui alimente Apple Intelligence on-device, désormais ouvert à l’intelligence de votre propre app.¹⁵

Ce cadrage compte parce que Core AI se situe sous les abstractions que la plupart des apps devraient utiliser. Apple le décrit comme conçu en pensant à Apple silicon, permettant à votre app d’utiliser les architectures de modèles et 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 davantage de contrôle sur la spécialisation des modèles, la mise en cache et les performances d’inférence lorsque c’est nécessaire.¹ La thèse de ce billet : tournez-vous vers Core AI lorsque vous avez un modèle que vous voulez 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 à moindre 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 spécifiques à l’appareil et AssetError représentant les échecs d’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 de disposition 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ée, de sortie et d’état. La fonction est Sendable, vous pouvez donc l’exécuter de façon concurrente.¹⁴¹³
• Les modèles se chargent depuis un bundle .aimodel sur le disque, et Core AI fournit des outils de préparation, de conversion et de débogage aux côtés du framework. Tournez-vous vers Core AI lorsque vous avez besoin d’un contrôle explicite sur la spécialisation et la planification ; sinon, restez sur Core ML ou Foundation Models.²¹

Deux mots qui régissent 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 des objets différents, et que spécialiser l’un en l’autre coûte cher. Le framework attribue un type à chacun.

Un AIModelAsset est « un asset de modèle source non spécialisé ».² Vous le créez à partir de l’URL d’un bundle .aimodel sur le disque, et vous l’utilisez pour inspecter un modèle sans payer le coût de la spécialisation. Apple explicite la raison de cette séparation : un asset de modèle vous permet d’interroger les informations du modèle sans effectuer de 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é : « un modèle spécialisé pour exécuter l’inférence sur un appareil ».³ 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 est la raison pour laquelle l’API vous oblige à nommer celui que vous voulez. Inspecter une centaine de modèles candidats pour en choisir un coûte peu si vous ne construisez que des assets ; ce serait ruineux si chaque inspection entraînait une spécialisation.

La spécialisation produit des artefacts spécifiques à l’appareil, et ces artefacts ont un foyer : AIModelCache, « un cache qui stocke les artefacts de modèle spécialisés pour l’inférence ».⁶ Le cache conserve les artefacts optimisés et spécifiques à l’appareil qu’un modèle charge pour exécuter ses fonctions d’inférence, et Apple précise que chaque entrée du cache contient un asset spécialisé formé à partir d’un .aimodel ou .aimodelc spécifique et d’une combinaison de spécialisation.⁶ La lecture pratique : la spécialisation n’est pas une chose que vous voulez répéter à chaque lancement. Le cache est la manière dont Core AI laisse l’étape coûteuse se produire une fois et l’étape peu coûteuse (le chargement des artefacts mis en cache) se produire ensuite.

Lorsque les opérations sur les assets échouent (un bundle manquant, un .aimodel malformé, un fichier illisible), Core AI fait remonter une AssetError, « une erreur qui survient pendant les opérations sur les assets de modèle ».⁴ Traitez-la comme vous traitez n’importe quelle frontière d’E/S : 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, « un tableau multidimensionnel de valeurs scalaires utilisé pour l’inférence de modèle ».⁵ Si vous avez travaillé avec le ndarray de NumPy, les tableaux MLX ou MLMultiArray, la forme de l’idée vous est familière : un bloc de scalaires à n dimensions avec une disposition définie. Un NDArray stocke ses données selon une disposition définie par sa forme et le reste de ses propriétés descriptives.⁵

Le type compagnon est NDArrayDescriptor, « une description de la forme, du type scalaire et des attentes de disposition mémoire d’un tableau ».⁷ Un descripteur est le contrat. Le cadrage d’Apple est direct : le descripteur contient les attentes pour une valeur de tableau que vous fournissez à une fonction d’inférence, et la plupart des 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 et le type qu’une fonction attend ; 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 ici reflète la séparation asset/modèle. Core AI place systématiquement un objet description peu coûteux devant un objet 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, « une description des dimensions et du format de pixel d’une image », de sorte que l’entrée pixel d’un modèle de vision reçoive le même traitement descripteur d’abord.¹¹

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

Apple silicon dispose de trois endroits pour calculer : le CPU, le GPU et le Neural Engine. La raison pour laquelle Core AI existe plutôt que Core ML seul, c’est que Core AI vous laisse indiquer lequel d’entre eux le framework cible, au lieu de l’inférer.

ComputeUnitKind est « un type d’unité de calcul matérielle disponible pour l’inférence de modèle ».⁸ Vous utilisez les types d’unité de calcul avec les options de spécialisation pour contrôler quel matériel le framework cible lors de la spécialisation d’un modèle, et par défaut la spécialisation utilise toutes les unités de calcul disponibles sur l’appareil.⁸ La valeur par défaut est la bonne réponse pour la plupart des travaux, et c’est précisément l’intérêt : vous ne la remplacez que lorsque 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 lourd 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 SpecializationOptions est l’endroit où vivent le ciblage des unités de calcul et les autres décisions de spécialisation. Parce qu’une entrée de cache est indexée sur une combinaison spécifique d’asset et de spécialisation, modifier vos options modifie quel artefact mis en cache vous récupérez, ce qui boucle la boucle entre ciblage et mise en cache.⁶

La planification est l’autre axe du « comment cela s’exécute », et Core AI la modélise comme un ComputeStream, « un flux de travail à exécuter de façon asynchrone ».¹⁰ Un compute stream est ce que vous fournissez pour encoder du travail sur le flux, et Apple note que plusieurs inférences encodées sur le même flux sont sérialisées au besoin selon les valeurs lues et écrites.¹⁰ Deux implications en découlent. D’abord, un flux est votre primitive d’ordonnancement : encodez les inférences dépendantes sur un seul flux et Core AI les séquence selon leur dépendance de données. Ensuite, le travail est asynchrone par défaut, de sorte que le flux est aussi la manière de garder le thread appelant libre pendant que le Neural Engine ou le GPU effectue le travail.

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

Un .aimodel chargé n’est pas un unique objet 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 décodage), et l’unité d’exécution de Core AI est l’InferenceFunction : « une fonction qui effectue l’inférence sur des valeurs d’entrée et produit des valeurs de sortie ».¹⁴

Avant d’en appeler une, vous l’inspectez. InferenceFunctionDescriptor est « une description de la signature d’une fonction d’inférence », 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 avec état est la manière dont un modèle à état (un cache KV dans une boucle de décodage de transformer, par exemple) conserve l’information entre les appels, et le descripteur vous indique qu’une fonction en possède avant que vous ne 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 à partir d’un modèle et vous appelez run(inputs:states:outputViews:) pour effectuer l’inférence.¹⁴ La signature de run est nommée dans l’exposé d’Apple lui-même, de sorte 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 de façon concurrente depuis plusieurs tâches, et Apple note qu’elle alloue automatiquement des tampons intermédiaires supplémentaires au besoin pour prendre en charge 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 transitent par run sont des instances d’InferenceValue, « une valeur qu’une fonction d’inférence accepte en entrée ou produit en sortie ».¹² Une InferenceValue enveloppe soit un NDArray, soit un pixel buffer, et vous récupérez un résultat après l’inférence via sa propriété value.¹² L’enveloppe est ce 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 transmet des valeurs adossées à un pixel buffer, et la fonction lit le descripteur pour savoir laquelle elle attend.

Quand se tourner vers Core AI

La partie la plus difficile de Core AI n’est pas l’API. C’est de savoir que vous devriez être ici plutôt qu’une couche au-dessus. L’arbre de décision honnête :

• Foundation Models lorsque le modèle système d’Apple accomplit la tâche. Résumer, classer, extraire, réécrire, produire une sortie structurée : tout cela relève de Foundation Models, qui ne vous coûte aucun poids, aucun budget mémoire et aucune étape de spécialisation. Si votre fonctionnalité s’y prête, 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 lorsque vous avez un modèle fixe converti et que vous voulez que le convertisseur prenne à votre place les décisions matérielles et d’optimisation. Core ML cible le Neural Engine avec une puissance et une latence serrées pour un modèle de production verrouillé, et il ne vous demande rien quant à la spécialisation ou à la planification. Si vous ne voulez pas penser au ciblage des unités de calcul ni aux compute streams, c’est le signal de rester sur Core ML.
• MLX lorsque 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 fine-tunes LoRA, de l’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 l’emporte sur la flexibilité et la vitesse d’itération.
• Core AI lorsque vous avez un modèle à exécuter et que vous voulez les leviers 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 de façon concurrente. Vous arrivez ici lorsque les valeurs par défaut des couches supérieures sont ce qui vous gêne, et que vous pouvez nommer la valeur par défaut que vous devez remplacer.

Le fil rouge de toute la pile : chaque couche inférieure échange une valeur par défaut contre un levier. Foundation Models vous remet tout et ne demande rien. Core AI vous remet les leviers et vous demande de savoir lequel actionner. Si vous ne pouvez pas nommer le contrôle de spécialisation, de mise en cache ou de planification 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ù se situe la frontière entre Core AI et Core ML pour les nouveaux travaux. Paraphrasé à partir d’un enregistrement transcrit localement du WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab, un ingénieur Core AI du panel a déclaré qu’Apple demande à toute personne travaillant avec des réseaux de neurones de migrer vers Core AI désormais, Core ML restant en place mais centré sur le machine learning traditionnel comme les arbres de décision, et tout ce qui est nouveau se dirigeant vers Core AI.¹⁶ Lisez cela comme un signal de cap de la part des personnes qui construisent le framework, plutôt que comme une politique documentée : si vous vous tournez vers un réseau de neurones sur un nouveau projet, le lab a présenté Core AI comme la surface sur laquelle bâtir.

Comment un modèle parvient jusqu’à Core AI

Le framework est la moitié runtime d’un workflow plus large. Apple note que Core AI inclut des outils supplémentaires de préparation, d’intégration et de débogage de modèles aux côtés du framework : vous préparez vos modèles pour Apple silicon, vous les convertissez au format .aimodel, et vous utilisez une app compagne qui prend en charge la visualisation et le débogage numérique.¹ La description que la fiche technique donne des noms de ces outils est tronquée, alors confirmez les noms exacts des outils et leur invocation dans la documentation Core AI d’Apple plutôt que de vous fier à une quelconque reconstruction.¹ Ce qui est vérifié, c’est la forme du pipeline : un modèle source est préparé, converti en .aimodel, chargé comme AIModelAsset pour inspection, spécialisé en AIModel, puis exécuté via ses InferenceFunction, AIModelCache conservant les artefacts spécialisés afin que l’étape coûteuse ne se produise qu’une fois.¹²³⁶¹⁴

FAQ

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 par « Exécutez des modèles d’IA dans votre app sur Apple silicon ».¹ Il exécute l’inférence de modèle sur le CPU, le GPU et le Neural Engine via une API Swift qui simplifie les tâches courantes tout en vous donnant le contrôle sur la spécialisation des modèles, la mise en cache et les performances d’inférence lorsque vous en avez besoin.¹ Il se situe sous Foundation Models et Core ML en tant que surface d’exécution des 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 est coûteuse, 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, lui, exécute l’inférence ; vous en créez un en chargeant l’asset depuis le disque.³ La séparation vous permet d’inspecter à moindre coût et de spécialiser seulement lorsque vous vous engagez.

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 nomme un type d’unité de calcul matérielle disponible pour l’inférence, et vous l’utilisez pour contrôler quel matériel 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 la valeur par défaut que lorsque vous avez une raison précise, comme épingler un chemin sensible à la latence à une seule unité de calcul.

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 via 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 prendre en charge la concurrence, de sorte que plusieurs tâches peuvent l’exécuter en même temps.¹⁴

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

Utilisez Foundation Models lorsque le modèle système accomplit la tâche, et Core ML lorsque vous avez un modèle fixe converti et que vous voulez que le convertisseur prenne les décisions matérielles et d’optimisation à votre place. Tournez-vous vers Core AI lorsque vous voulez un contrôle explicite sur la spécialisation (SpecializationOptions, ComputeUnitKind), la mise en cache (AIModelCache) et la planification (ComputeStream) que les couches supérieures gèrent pour vous.⁸⁹⁶¹⁰ Si vous ne pouvez pas nommer le contrôle dont vous avez besoin, restez une couche au-dessus.

Le cluster complet Apple Ecosystem : 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/Neural Engine ; l’inférence on-device de Core ML pour la couche à modèle fixe au-dessus de Core AI ; et Foundation Models pour le LLM système scellé d’Apple au sommet de la pile. Le hub se trouve dans la série Apple Ecosystem. Pour un contexte plus large d’iOS avec des agents IA, consultez le guide iOS Agent Development.

Références