Intégration Apple Core AI#

Core AI est le nouveau framework d’Apple pour 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 et des outils dédiés au débogage et au profilage.

Apple décrit Core AI comme la prochaine évolution de l’exécution de l’IA sur appareil et comme le framework d’inférence qui sous-tend Apple Intelligence sur 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 l’Apple Neural Engine (ANE).

Core AI est une nouvelle voie de déploiement, et non un nouveau nom pour Core ML. Les 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 de 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 tels que les arbres de décision et les pipelines tabulaires. Apple continue de prendre Core ML en charge et oriente vers celui-ci les développeurs qui utilisent des types de modèles non neuronaux.

Fonctionnement du format Core AI#

Le flux de création 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 à l’aide d’une opération de réduction 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 faire à la première utilisation, demander la spécialisation à l’avance ou fournir un modèle compilé par anticipation afin de 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’utilisation 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 les détails d’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écute le modèle exporté
coreai_model = YOLO("yolo26n.aimodel")
results = coreai_model("https://ultralytics.com/images/bus.jpg")

Pour obtenir la liste complète des arguments, consulte le mode Export. Le graphe est statique : il est tracé avec la valeur imgsz transmise à export ; effectue donc les prédictions avec cette même taille. Les métadonnées Ultralytics sont intégrées au metadata.json propre à la ressource, de sorte que les noms de classe, le stride et la tâche sont conservés 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 d’opération top-k ; cette sélection est donc ramenée à un tri complet, qui entraîne un coût fixe à la frontière de partition de l’Apple Neural Engine — environ 1,7 ms, quelle que soit la valeur de max_det. L’export avec nms=None produit plutôt les prédictions brutes (1, 84, 8400) et laisse la suppression des doublons au prédicteur :

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

Sur un iPhone 17 Pro exécutant iOS 27.0, YOLO26n à 640 atteint 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 s’effectue après un aller-retour via YOLO(...). Utilise nms=False lorsqu’un seul appel au graphe doit renvoyer des détections finalisées, ou conserve la valeur par défaut nms=None pour la NMS externe.

Sur iOS 27 ou macOS 27, une 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, prennent 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 flux de travail Core ML et Vision actuel, le parcours Core AI du SDK iOS Ultralytics effectue lui-même le prétraitement letterbox et la création de 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. Il se charge 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 exportations Core ML et Core AI de YOLO26n FP16 (quantize=16), 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 sur Python 3.13. Chaque cellule indique le temps total (prétraitement + inférence + post-traitement), avec la répartition 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 d'Ultralytics, avec chaque modèle et unité de calcul 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 avec coremltools.ComputeUnit.CPU_ONLY ou CPU_AND_NE ; les lignes Core AI sont spécialisées 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. Sur ce Mac, le modèle sémantique Core ML FP16 est plus lent avec Neural Engine privilégié que sur CPU seul, 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 sur l'appareil de 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 :

• Parcours d'export moderne pour PyTorch : La conversion part de torch.export, préservant un graphe PyTorch plus expressif que le flux de travail de traçage utilisé par de nombreux exportateurs existants.
• Contrôle précis à 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 le placement des calculs.
• Prise en charge avancée des modèles : L'exécution avec état, les formes dynamiques, les fonctions multiples 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 retracer jusqu'au code Python d'origine. Xcode et Instruments permettent de profiler l'exécution.
• Possibilités de copie zéro : Core AI expose des contrôles de stockage et de tampons destinés à réduire les copies entre les charges de travail de la caméra, des graphiques et de l'inférence.
• Optimisation pour les puces Apple : La spécialisation sur l'appareil permet à Apple d'optimiser un modèle pour le CPU, le GPU et le Neural Engine disponibles sur l'appareil concerné.
• Compression flexible : Les outils Core AI Optimization d'Apple prennent en charge la quantification, la palettisation et l'élagage, y compris les formats de poids à faible nombre de bits.

Ces fonctionnalités pourraient être particulièrement utiles pour les futurs modèles YOLO dotés d'une exécution dynamique, de composants multimodaux plus volumineux ou d'opérations personnalisées qui ne correspondent pas clairement aux opérations Core ML existantes.

Inconvénients et limites actuels#

Core AI ne remplace pas actuellement le parcours Core ML de 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 un parc installé beaucoup plus vaste.
• Logiciel bêta : Le framework Core AI d'Apple et certaines parties de sa chaîne d'outils Python sont encore préliminaires et pourraient évoluer 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 beaucoup plus restrictif que la plage de versions de Python et PyTorch prise en charge par Ultralytics.
• Plateformes d'export limitées : coreai-core ne publie que des paquets macosx_26_0_arm64 et manylinux_2_34_x86_64. format=coreai nécessite donc un Mac Apple silicon sous macOS 26 ou une version ultérieure, ou Linux x86_64 avec glibc 2.34 ou une version ultérieure (par exemple Ubuntu 22.04+). L'exécution d'un .aimodel nécessite toujours du matériel Apple.
• Activation facultative dans les SDK Ultralytics, pas par défaut : Sur un iPhone 17 Pro, la comparaison sur l'appareil montre que Core AI est à égalité avec Core ML pour l'ensemble du pipeline, et non en avance ; l'inférence sémantique, de 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 valeur par défaut.
• Utilise la tête brute pour les SDK : Avec nms=False, YOLO26n prend environ deux fois plus de temps sur Core AI que sur Core ML (3.06 contre 1.53 ms lors d'un essai comparatif), et le modèle de pose de bout en bout FP16 ne renvoie aucune détection avec le placement par défaut de Core AI sur 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 NMS dans Swift. Voir Choisir la tête.
• Aucun 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 fournissent une.
• Peu de données probantes en production : Les performances, la consommation d'énergie, le temps de spécialisation lors du premier lancement, la précision et la compression doivent être validés pour l'ensemble des tâches YOLO et des appareils pris en charge.
• Aucun pipeline NMS : Core ML peut intégrer une étape NMS pour les anciens modèles de détection YOLO. Par défaut, Core AI exporte des prédictions brutes un-vers-plusieurs ; utilise nms=False pour la tête sans NMS de YOLO26. Le NMS intégré (nms=True) et dynamic=True ne sont pas pris en charge. coreai-torch ne permet pas d'abaisser torchvision::nms ; le NMS reste donc exécuté sur l'hôte.
• Taille d'entrée fixe : Le graphe exporté est tracé pour une seule imgsz et ne prend pas en charge les formes dynamiques ; effectue donc les prédictions à la taille utilisée lors de l'export.
• Les ressources FP16 peuvent provoquer un arrêt au chargement : Certaines ressources FP16 .aimodel ne parviennent pas à charger leur programme Apple Neural Engine, et MPSGraph déclenche une assertion échouée, ce qui met fin au processus au lieu d'effectuer un repli. Cela se produit dans le moteur 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. Utilise FP32 si une ressource présente ce problème ; les ressources FP16 du SDK vérifiées sur un iPhone 17 Pro (tous les modèles nano, la détection à toutes les tailles et le plus grand modèle de chaque tâche) se sont chargées sans provoquer d'arrêt.

Quel format Apple choisir ?#

Utilise Core ML dès maintenant si tu as besoin de :

• Déployer sur les systèmes d'exploitation Apple actuels et anciens
• Utiliser le parcours par défaut du SDK iOS ou Flutter d'Ultralytics
• Gérer les images avec le framework Vision
• Déployer YOLO en FP16 et INT8 avec des configurations testées
• Intégrer le NMS pour les anciens modèles de détection compatibles

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

• Le moteur d'exécution de réseau neuronal sur appareil le plus récent d'Apple
• La gestion explicite de la spécialisation et des caches
• L'exécution avancée de modèles dynamiques ou avec état
• Des opérations Core AI personnalisées ou des noyaux Metal
• Un débogage détaillé des graphes Core AI et un 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 d'application diffèrent.

Feuille de route Ultralytics#

La cible d'export dédiée coreai est implémentée : l'export et la validation numérique couvrent les modèles YOLO26 pris en charge pour chaque tâche et s'exécutent en continu dans la CI Ultralytics sous macOS 26 ; la latence FP16 est mesurée sur l'appareil. Voici les étapes restantes avant que Core AI atteigne la parité avec le parcours Core ML :

1. Réduire l'écart de latence de bout en bout de la tête sur Apple Neural Engine (apple/coreai-torch#66) et résoudre les problèmes de bon fonctionnement sur Neural Engine (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 des frameworks et outils de conversion Apple (la génération iOS 27 et macOS 27 est actuellement en bêta).
4. Benchmarks de mémoire, de consommation d'énergie et de spécialisation sur l'ensemble des appareils pris en charge.

Le SDK iOS et le plugin Flutter d'Ultralytics proposent Core AI en option à partir d'iOS 27 ; Core ML reste leur option par défaut et la cible recommandée pour les versions antérieures à iOS 27. Suis la feuille de route Ultralytics et les notes de version pour connaître les étapes restantes.

Ressources supplémentaires#

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

FAQ#