Intégration d’Apple Core AI#

Core AI est le nouveau framework d’Apple permettant d’exécuter des réseaux neuronaux directement sur Apple silicon. Il introduit le format de modèle .aimodel, une API d’inférence Swift moderne, des outils de conversion basés sur PyTorch, la compilation anticipée, la spécialisation des modèles, ainsi que des outils dédiés au débogage et au profilage.

Apple présente Core AI comme la prochaine évolution de l’exécution de l’IA sur l’appareil et comme le framework d’inférence utilisé par Apple Intelligence sur l’appareil. Il est conçu pour les architectures de réseaux neuronaux actuelles, des modèles de vision compacts aux grands modèles génératifs, et peut répartir les tâches entre le CPU, le GPU et le moteur neuronal Apple (ANE).

Core AI est une nouvelle voie de déploiement, et non un nouveau nom pour Core ML. Ces frameworks utilisent des formats de modèle, des outils de conversion, des API d’exécution et des modes d’intégration aux applications différents.

Comparaison entre Core AI et Core ML#

Core ML reste le choix approprié lorsqu’une application nécessite une large compatibilité avec les appareils, une intégration au framework Vision ou des types de modèles comme les arbres de décision et les pipelines tabulaires. Apple continue de prendre en charge Core ML et oriente vers celui-ci les développeurs qui utilisent des types de modèles non neuronaux.

Fonctionnement du format Core AI#

Le workflow de création avec Core AI part d’un modèle PyTorch :

PyTorch model
    ↓ torch.export
ExportedProgram
    ↓ coreai-torch
Core AI program
    ↓ optimize and save
.aimodel
    ↓ specialize or compile ahead of time
Apple silicon executable

Le package coreai-torch d’Apple convertit un torch.export.ExportedProgram en abaissant les opérations PyTorch ATen en opérations Core AI. Les opérations non prises en charge peuvent être implémentées au moyen d’une conversion personnalisée ou d’un noyau Metal personnalisé.

Le .aimodel obtenu est une ressource de modèle non spécialisée. Lorsqu’une application prépare le modèle, Core AI le spécialise pour l’appareil cible. Les applications peuvent laisser cette opération se produire à la première utilisation, demander la spécialisation plus tôt ou distribuer un modèle compilé par anticipation pour réduire le temps de chargement initial.

En Swift, les applications chargent la ressource avec le framework Core AI, sélectionnent une fonction d’inférence, fournissent des entrées typées NDArray et reçoivent des sorties nommées. Cette approche diffère de l’encapsulation d’un modèle Core ML dans une requête Vision. Adopter Core AI nécessite donc un environnement d’exécution d’application conçu pour les ressources .aimodel.

Pour plus de détails sur l’implémentation, consulte la documentation d’Apple sur AIModel, la spécialisation et la mise en cache des modèles et la compilation anticipée.

Exporter des modèles YOLO26 vers Core AI#

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.export(format="coreai")  # crée 'yolo26n.aimodel'
model.export(format="coreai", quantize=16)  # FP16 asset

# Exécuter le modèle exporté
coreai_model = YOLO("yolo26n.aimodel")
results = coreai_model("https://ultralytics.com/images/bus.jpg")

Pour consulter la liste complète des arguments, voir le mode Export. Le graphe est statique : il est tracé à la taille imgsz fournie à export ; effectue donc les prédictions à cette même taille. Les métadonnées Ultralytics sont intégrées dans le metadata.json propre à la ressource, ce qui permet de conserver les noms de classes, le stride et la tâche lors de l’aller-retour.

Choisir la tête#

Avec nms=False, YOLO26 exporte sa tête de bout en bout, qui sélectionne les détections dans le graphe. Core AI ne dispose pas de primitive top-k ; cette sélection est donc convertie en tri complet et entraîne un coût fixe à la frontière de partition du moteur neuronal Apple — environ 1,7 ms, quelle que soit la valeur de max_det. L’export avec nms=None émet plutôt les prédictions (1, 84, 8400) brutes et laisse le prédicteur effectuer la suppression des non-maxima :

yolo export model=yolo26n.pt format=coreai nms=None quantize=16

Sur un iPhone 17 Pro exécutant iOS 27.0, YOLO26n à 640 prend 3,01 ms avec la tête dans le graphe et 1,28 ms sans celle-ci (FP16, compilation anticipée, trois blocs entrelacés de 50 itérations). Dans les deux cas, l’inférence passe par YOLO(...). Utilise nms=False lorsqu’un seul appel au graphe doit renvoyer des détections finalisées, ou conserve nms=None, la valeur par défaut, pour effectuer la NMS à l’extérieur.

Sous iOS 27 ou macOS 27, l’application chargerait et exécuterait ensuite la ressource exportée via l’API Swift Core AI d’Apple. Les ressources exportées utilisent le point d’entrée main, acceptent une seule entrée images de forme [batch, 3, imgsz, imgsz] et renvoient output0 (les modèles de segmentation d’instances renvoient également output1) :

import CoreAI

let modelURL = Bundle.main.url(forResource: "yolo26n", withExtension: "aimodel")!
let model = try await AIModel(contentsOf: modelURL)
guard let function = try model.loadFunction(named: "main") else {
    throw AppError.missingInferenceFunction
}

let outputs = try await function.run(inputs: ["images": imageTensor])

Contrairement au workflow actuel avec Core ML et Vision, la voie Core AI du SDK iOS d’Ultralytics effectue son propre prétraitement letterbox et construit NDArray, lit les mêmes métadonnées Ultralytics dans le metadata.json de la ressource et réutilise les décodeurs de sortie Core ML. Le chargement se déclenche lorsqu’une application transmet un chemin .aimodel ou une URL .aimodel.zip. Apple fournit les détails actuels de l’API dans la documentation du framework Core AI et des exemples de modèles fonctionnels dans le dépôt de modèles Core AI.

Performances mesurées#

Inférence de bout en bout sur une seule image pour les exports YOLO26n FP16 (quantize=16) Core ML et Core AI avec la tête brute par défaut (nms=None) sur un Mac mini équipé d'une Apple M4 (4 cœurs CPU Performance et 6 cœurs CPU Efficiency, GPU à 10 cœurs, Neural Engine à 16 cœurs), de 16 Go de mémoire et de macOS 27.0, avec ultralytics 8.4.168, coremltools 9.0 pour l'inférence Core ML et coreai-torch 0.4.3 avec coreai-core 1.0.0b3 pour l'inférence Core AI sous Python 3.13. Chaque cellule indique le temps total (prétraitement + inférence + post-traitement), avec le détail par étape en dessous.

• Les valeurs de vitesse correspondent aux latences en rafale sur une seule image : la moyenne de 15 appels à predict après 3 appels de préchauffage sur bus.jpg via l'API Python Ultralytics, chaque modèle et chaque unité de calcul étant exécutés dans un processus distinct. L'ordre CPU/accélérateur alternait entre les tâches au cours d'un balayage séquentiel. Les lignes Core ML chargent les modèles avec coremltools.ComputeUnit.CPU_ONLY ou CPU_AND_NE ; les lignes Core AI spécialisent les modèles avec SpecializationOptions.cpu_only() ou SpecializationOptions.from_preferred_compute_unit_kind(ComputeUnitKind.neural_engine()), le placement final des opérations étant contrôlé par chaque framework.
• La détection, la segmentation, la classification, l'estimation de pose et l'OBB ont renvoyé les mêmes prédictions dans les deux formats sur chaque unité de calcul. Le modèle sémantique Core ML FP16 est plus lent lorsque le Neural Engine est privilégié que sur CPU uniquement sur ce Mac, et le post-traitement sémantique Core AI prend de 6.4 à 7.4 ms, contre 0.4 ms pour Core ML.
• Compare les résultats obtenus sur l'iPhone 17 Pro dans l'intégration CoreML.

Avantages de Core AI#

Core AI présente plusieurs avantages prometteurs pour les futurs déploiements Ultralytics :

• Voie d’export PyTorch moderne : la conversion part de torch.export, ce qui préserve un graphe PyTorch plus expressif que le workflow de traçage utilisé par de nombreux exporteurs existants.
• Contrôle précis de l’exécution : les applications peuvent gérer la spécialisation, les caches de modèles compilés, les fonctions d’inférence, la mémoire et l’affectation des calculs.
• Prise en charge avancée des modèles : l’exécution avec état, les formes dynamiques, plusieurs fonctions dans un même artefact et les noyaux Metal personnalisés sont conçus pour les architectures modernes de vision et génératives.
• Outils dédiés aux développeurs : le débogueur Core AI peut examiner les graphes et les valeurs des tenseurs, puis les relier au code Python d’origine. Xcode et Instruments permettent de profiler l’exécution.
• Possibilités de copie sans transfert : Core AI expose des contrôles de stockage et de tampons destinés à réduire les copies entre les traitements de la caméra, des graphismes et de l’inférence.
• Optimisation pour Apple silicon : la spécialisation de l’appareil permet à Apple d’optimiser un modèle pour le CPU, le GPU et le Neural Engine disponibles sur cet appareil précis.
• Compression flexible : les outils d’optimisation Core AI d’Apple prennent en charge la quantification, la palettisation et l’élagage, y compris les formats de poids à faible nombre de bits.

Ces capacités pourraient être particulièrement utiles pour les futurs modèles YOLO utilisant une exécution dynamique, des composants multimodaux plus volumineux ou des opérations personnalisées qui ne correspondent pas facilement aux opérations Core ML existantes.

Inconvénients et limites actuels#

Core AI ne remplace pas actuellement la voie Core ML utilisée en production :

• Nouveaux systèmes d’exploitation requis : le framework public cible la génération iOS 27 et macOS 27, tandis que Core ML prend en charge une base installée bien plus vaste.
• Logiciel en bêta : le framework Core AI d’Apple et certaines parties de sa chaîne d’outils Python sont encore préliminaires et peuvent changer avant leur version stable.
• Environnement d’export plus restreint : coreai-torch nécessite actuellement Python 3.11 à 3.14, ainsi que des versions récentes de PyTorch, ce qui est bien plus restrictif que les plages de versions Python et PyTorch prises en charge par Ultralytics.
• Plateformes d'export limitées : coreai-core publie uniquement les wheels macosx_26_0_arm64 et manylinux_2_34_x86_64. Par conséquent, format=coreai nécessite un Mac Apple silicon sous macOS 26 ou ultérieur, ou Linux x86_64 avec glibc 2.34 ou ultérieure (par exemple Ubuntu 22.04+). L'exécution d'un .aimodel nécessite toujours du matériel Apple.
• Option facultative dans les SDK Ultralytics, et non option par défaut : sur un iPhone 17 Pro, la comparaison sur l’appareil montre que Core AI est à égalité avec Core ML pour le pipeline complet, et non plus rapide ; l’inférence sémantique, en profondeur et sur CPU uniquement est plus lente, et les ressources FP16 font environ deux fois la taille au téléchargement. Le SDK iOS et le plugin Flutter conservent donc Core ML comme option par défaut.
• Utilise la tête brute dans les SDK : avec nms=False, YOLO26n est environ deux fois plus lent avec Core AI qu’avec Core ML (3,06 contre 1,53 ms lors d’un test comparatif), et le modèle de pose FP16 de bout en bout ne renvoie aucune détection avec l’affectation par défaut de Core AI sous iOS 27.0 (apple/coreai-torch#115). La tête brute (nms=None, la valeur par défaut) évite ces deux problèmes, et les SDK exécutent la NMS en Swift. Voir Choisir la tête.
• Pas d’environnement d’exécution pour le simulateur iOS : le SDK du simulateur iOS n’inclut pas Core AI.
• Migration de l’application requise : un .aimodel ne peut pas remplacer un .mlpackage ; le chargement du modèle, le prétraitement, les appels d’inférence, la gestion des métadonnées et le décodage des sorties nécessitent une implémentation Core AI en dehors des SDK Ultralytics, qui en proposent une.
• Peu de données en production : les performances, la consommation électrique, le temps de spécialisation lors du premier lancement, la précision et la compression doivent être validés sur l’ensemble de tâches YOLO et d’appareils pris en charge.
• Pas de pipeline NMS : Core ML peut intégrer une étape NMS aux anciens modèles YOLO de détection. Par défaut, les exports Core AI produisent des prédictions brutes one-to-many ; utilise nms=False pour la tête sans NMS de YOLO26. La NMS intégrée (nms=True) et dynamic=True ne sont pas pris en charge. coreai-torch ne propose aucune conversion pour torchvision::nms ; la NMS reste donc exécutée sur l’hôte.
• Taille d’entrée fixe : le graphe exporté est tracé avec un seul imgsz et n’a pas de formes dynamiques. Effectue donc les prédictions à la taille utilisée pour l’export.
• Les ressources FP16 peuvent provoquer un arrêt brutal au chargement : certaines ressources .aimodel FP16 ne parviennent pas à charger leur programme Apple Neural Engine ; MPSGraph déclenche alors une assertion qui échoue, mettant fin au processus au lieu de passer à une autre solution. Cela se produit dans l’environnement d’exécution d’Apple, avant l’exécution de tout code Ultralytics, et la même ressource se charge avec une spécialisation CPU uniquement. Passe à FP32 si une ressource présente ce problème ; les ressources FP16 du SDK testées sur un iPhone 17 Pro (tous les modèles nano, détection à toutes les tailles et plus grand modèle de chaque tâche) se sont chargées sans arrêt brutal.

Quel format Apple choisir ?#

Choisis Core ML dès aujourd’hui si tu as besoin :

• D’un déploiement sur les systèmes d’exploitation Apple actuels et plus anciens
• De la voie par défaut du SDK iOS ou Flutter d’Ultralytics
• Du traitement des images par le framework Vision
• D’un déploiement YOLO FP16 et INT8 testé
• De la NMS intégrée pour les modèles de détection hérités compatibles

Évalue Core AI si tu peux exiger iOS 27 ou macOS 27 et que tu as besoin :

• Du tout dernier environnement d’exécution des réseaux neuronaux sur appareil d’Apple
• D’un contrôle explicite de la spécialisation et de la gestion du cache
• D’une exécution avancée de modèles dynamiques ou avec état
• D’opérations Core AI personnalisées ou de noyaux Metal
• D’un débogage détaillé des graphes Core AI et du profilage de l’exécution

Core ML et Core AI devraient coexister pendant la transition des applications. La prise en charge de Core AI ne supprime pas immédiatement le besoin de Core ML, car leurs cibles de déploiement et leurs contrats applicatifs diffèrent.

Feuille de route d’Ultralytics#

La cible d’export dédiée coreai est implémentée : l’export et la validation numérique couvrent les modèles des tâches YOLO26 prises en charge et s’exécutent en continu dans l’intégration continue d’Ultralytics sur macOS 26 ; la latence FP16 est mesurée sur l’appareil. Voici les étapes restantes avant que Core AI n’atteigne la parité avec la voie Core ML :

1. Réduire l’écart de latence de la tête de bout en bout sur le moteur neuronal Apple (apple/coreai-torch#66) et résoudre les problèmes de bon fonctionnement du moteur neuronal (apple/coreai-torch#115, #116).
2. Ressources Core AI INT8 et palettisées ; les ressources du SDK sont en FP16 et font environ deux fois la taille au téléchargement des ressources Core ML INT8.
3. Versions stables du framework Apple et des outils de conversion (la génération iOS 27 et macOS 27 est actuellement en bêta).
4. Tests de mémoire, de consommation électrique et de spécialisation sur l’ensemble des appareils pris en charge.

Le SDK iOS et le plugin Flutter d’Ultralytics chargent Core AI en option sous iOS 27 et les versions ultérieures ; Core ML reste leur option par défaut et la cible recommandée pour les appareils sous iOS antérieur à iOS 27. Consulte la feuille de route d’Ultralytics et les notes de version pour connaître les étapes restantes.

Ressources supplémentaires#

• Présentation d’Apple Core AI
• Documentation du framework Core AI
• Extensions PyTorch de Core AI
• Optimisation Core AI
• Dépôt de modèles Apple Core AI
• Intégration Core ML d’Ultralytics

FAQ#