Integración con Apple Core AI#

Core AI es el nuevo framework de Apple para ejecutar redes neuronales directamente en Apple silicon. Introduce el formato de modelo .aimodel, una API moderna de inferencia en Swift, herramientas de conversión basadas en PyTorch, compilación anticipada, especialización de modelos y herramientas específicas de depuración y creación de perfiles.

Apple describe Core AI como la siguiente evolución de la ejecución de IA en el dispositivo y como el framework de inferencia que hay detrás de Apple Intelligence en el dispositivo. Está diseñado para arquitecturas de redes neuronales actuales, desde modelos de visión compactos hasta grandes modelos generativos, y puede programar tareas en la CPU, la GPU y el motor neuronal de Apple (ANE).

Core AI es una nueva vía de implementación, no un nuevo nombre para Core ML. Los frameworks utilizan formatos de modelo, herramientas de conversión, API de ejecución y patrones de integración en aplicaciones distintos.

Comparación entre Core AI y Core ML#

Core ML sigue siendo la opción adecuada cuando una aplicación necesita una amplia compatibilidad con dispositivos, integración con el framework Vision o tipos de modelos como árboles de decisión y flujos de trabajo tabulares. Apple sigue dando soporte a Core ML y recomienda utilizarlo a los desarrolladores que trabajen con tipos de modelos no neuronales.

Cómo funciona el formato Core AI#

El flujo de trabajo de creación de Core AI parte de un modelo PyTorch:

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

El paquete coreai-torch de Apple convierte un torch.export.ExportedProgram transformando las operaciones ATen de PyTorch en operaciones de Core AI. Las operaciones no compatibles se pueden implementar mediante una reducción personalizada o un kernel de Metal personalizado.

El .aimodel resultante es un recurso de modelo sin especializar. Cuando una aplicación prepara el modelo, Core AI lo especializa para el dispositivo de destino. Las aplicaciones pueden dejar que esto ocurra en el primer uso, solicitar la especialización con antelación o distribuir un modelo compilado de antemano para reducir el tiempo de carga inicial.

En Swift, las aplicaciones cargan el recurso con el framework Core AI, seleccionan una función de inferencia, proporcionan entradas NDArray tipadas y reciben salidas con nombre. Esto difiere de envolver un modelo Core ML en una solicitud de Vision, por lo que adoptar Core AI requiere un entorno de ejecución de aplicaciones diseñado para los recursos .aimodel.

Para obtener información sobre la implementación, consulta la documentación de Apple sobre AIModel, la especialización y el almacenamiento en caché de modelos y la compilación anticipada.

Exportación de modelos YOLO26 a Core AI#

from ultralytics import YOLO

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

# Ejecuta el modelo exportado
coreai_model = YOLO("yolo26n.aimodel")
results = coreai_model("https://ultralytics.com/images/bus.jpg")

Para ver la lista completa de argumentos, consulta el modo de exportación. El grafo es estático: se traza con el imgsz proporcionado a export, así que haz las predicciones con ese mismo tamaño. Los metadatos de Ultralytics se incluyen en el metadata.json propio del recurso, por lo que los nombres de clase, el stride y la tarea se conservan en el proceso de ida y vuelta.

Elección del cabezal#

Con nms=False, YOLO26 exporta su cabezal de extremo a extremo, que selecciona las detecciones dentro del grafo. Core AI no tiene una primitiva top-k, así que esa selección se convierte en una ordenación completa y conlleva un coste fijo en el límite de partición del motor neuronal de Apple: unos 1,7 ms, independientemente de max_det. En cambio, la exportación con nms=None genera las predicciones (1, 84, 8400) sin procesar y deja la supresión de no máximos a cargo del predictor:

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

En un iPhone 17 Pro con iOS 27.0, YOLO26n a 640 mide 3,01 ms con el cabezal en el grafo y 1,28 ms sin él (FP16, compilado de antemano, tres bloques intercalados de 50 iteraciones). En ambos casos, el proceso de ida y vuelta se realiza mediante YOLO(...) para la inferencia. Usa nms=False cuando una única llamada al grafo tenga que devolver detecciones ya procesadas, o mantén el nms=None predeterminado para usar NMS externa.

En iOS 27 o macOS 27, la aplicación cargaría y ejecutaría el recurso exportado mediante la API Swift Core AI de Apple. Los recursos exportados utilizan el punto de entrada main, reciben una única entrada images con la forma [batch, 3, imgsz, imgsz] y devuelven output0 (los modelos de segmentación de instancias también devuelven 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])

A diferencia del flujo de trabajo actual con Core ML y Vision, la vía de Core AI del SDK de iOS de Ultralytics realiza su propio preprocesamiento letterbox y crea NDArray, lee los mismos metadatos de Ultralytics del metadata.json del recurso y reutiliza los decodificadores de salida de Core ML. Se carga cuando una aplicación proporciona una ruta .aimodel o una URL .aimodel.zip. Apple ofrece información actualizada de la API en la documentación del framework Core AI y ejemplos de modelos funcionales en el repositorio de modelos Core AI.

Rendimiento medido#

Inferencia de extremo a extremo de una sola imagen para las exportaciones Core ML y Core AI de YOLO26n FP16 (quantize=16) con el cabezal sin procesar predeterminado (nms=None) en un Mac mini con Apple M4 (4 núcleos de CPU de rendimiento y 6 de eficiencia, GPU de 10 núcleos, motor neuronal de 16 núcleos), 16 GB de memoria y macOS 27.0, con ultralytics 8.4.168, coremltools 9.0 para la inferencia de Core ML y coreai-torch 0.4.3 con coreai-core 1.0.0b3 para la inferencia de Core AI en Python 3.13. Cada celda muestra el tiempo total (preprocesamiento + inferencia + posprocesamiento) y, debajo, el desglose por etapa.

• Los valores de velocidad son latencias de ráfaga de una sola imagen: la media de 15 llamadas a predict después de 3 llamadas de calentamiento en bus.jpg, a través de la API de Python de Ultralytics, con cada modelo y unidad de cálculo en un proceso nuevo. El orden CPU/acelerador se alternó entre tareas en una sola pasada secuencial. Las filas de Core ML se cargan con coremltools.ComputeUnit.CPU_ONLY o CPU_AND_NE; las filas de Core AI se especializan con SpecializationOptions.cpu_only() o SpecializationOptions.from_preferred_compute_unit_kind(ComputeUnitKind.neural_engine()), y la ubicación final de las operaciones depende de cada framework.
• Detectar, segmentar, clasificar, estimar la pose y OBB devolvieron las mismas predicciones en ambos formatos en todas las unidades de cálculo. El modelo semántico FP16 de Core ML funciona más despacio con Neural Engine como opción preferida que usando solo la CPU en este Mac, y el posprocesamiento semántico de Core AI tarda de 6,4 a 7,4 ms, frente a 0,4 ms en Core ML.
• Compara los resultados en el propio iPhone 17 Pro en la integración de CoreML.

Ventajas de Core AI#

Core AI ofrece varias ventajas prometedoras para futuros despliegues de Ultralytics:

• Ruta moderna de exportación de PyTorch: La conversión parte de torch.export y conserva un grafo de PyTorch más expresivo que el flujo de trabajo de trazado utilizado por muchos exportadores existentes.
• Control detallado del entorno de ejecución: Las aplicaciones pueden gestionar la especialización, las cachés de modelos compilados, las funciones de inferencia, la memoria y la ubicación de los cálculos.
• Compatibilidad avanzada con modelos: La ejecución con estado, las formas dinámicas, varias funciones en un mismo artefacto y los kernels personalizados de Metal están diseñados para arquitecturas modernas de visión y generación.
• Herramientas de desarrollo específicas: Core AI Debugger puede inspeccionar grafos y valores de tensores, y rastrearlos hasta el código Python de origen. Xcode e Instruments permiten analizar el rendimiento en tiempo de ejecución.
• Posibilidades de copia cero: Core AI expone controles de almacenamiento y búferes pensados para reducir las copias entre las cargas de trabajo de cámara, gráficos e inferencia.
• Optimización para Apple Silicon: La especialización para cada dispositivo permite a Apple optimizar un modelo para la CPU, la GPU y Neural Engine disponibles en ese dispositivo concreto.
• Compresión flexible: Las herramientas Core AI Optimization de Apple admiten la cuantización, la paletización y la poda, incluidos los formatos de pesos de pocos bits.

Estas capacidades podrían ser especialmente útiles para futuros modelos YOLO con ejecución dinámica, componentes multimodales de mayor tamaño u operaciones personalizadas que no se adapten bien a las operaciones existentes de Core ML.

Desventajas y limitaciones actuales#

Actualmente, Core AI no sustituye a la ruta de producción de Core ML:

• Se requieren sistemas operativos nuevos: El framework público está destinado a las generaciones de iOS 27 y macOS 27, mientras que Core ML es compatible con una base instalada mucho más amplia.
• Software beta: El framework Core AI de Apple y parte de su cadena de herramientas de Python siguen en fase preliminar y pueden cambiar antes de sus versiones estables.
• Entorno de exportación más limitado: coreai-torch requiere actualmente Python 3.11 a 3.14, además de versiones recientes de PyTorch, un rango mucho más limitado que el de las versiones de Python y PyTorch compatibles con Ultralytics.
• Plataformas de exportación limitadas: coreai-core solo publica ruedas macosx_26_0_arm64 y manylinux_2_34_x86_64, por lo que format=coreai necesita un Mac con Apple Silicon y macOS 26 o posterior, o Linux x86_64 con glibc 2.34 o posterior (por ejemplo, Ubuntu 22.04 o posterior). Para ejecutar un .aimodel sigue siendo necesario disponer de hardware de Apple.
• Activación opcional en los SDK de Ultralytics, no predeterminada: En un iPhone 17 Pro, la comparación en el dispositivo sitúa Core AI al nivel de Core ML para el flujo completo, no por delante; la inferencia semántica, de profundidad y solo con CPU es más lenta, y los recursos FP16 ocupan aproximadamente el doble al descargarlos. Por eso, el SDK de iOS y el complemento de Flutter mantienen Core ML como opción predeterminada.
• Usa la cabecera sin procesar en los SDK: Con nms=False, YOLO26n tarda aproximadamente el doble en Core AI que en Core ML (3.06 frente a 1.53 ms en una ejecución comparativa), y el modelo de pose FP16 de extremo a extremo no detecta nada con la ubicación predeterminada de Core AI en iOS 27.0 (apple/coreai-torch#115). La cabecera sin procesar (nms=None, la opción predeterminada) evita ambos problemas, y los SDK ejecutan NMS en Swift. Consulta Cómo elegir la cabecera.
• No hay entorno de ejecución en el simulador de iOS: El SDK del simulador de iOS no incluye Core AI.
• Es necesario migrar la aplicación: Un .aimodel no puede sustituir a un .mlpackage; la carga del modelo, el preprocesamiento, las llamadas de inferencia, la gestión de metadatos y la decodificación de las salidas requieren una implementación de Core AI fuera de los SDK de Ultralytics, que proporcionan una.
• Evidencia de producción limitada: Hay que validar el rendimiento, el consumo energético, el tiempo de especialización inicial, la precisión y la compresión en toda la matriz de tareas y dispositivos YOLO compatibles.
• Sin flujo de NMS: Core ML puede incluir una etapa de NMS para modelos de detección YOLO antiguos. Core AI exporta de forma predeterminada predicciones sin procesar de tipo uno a muchos; usa nms=False para la cabecera sin NMS de YOLO26. No se admiten NMS integrado (nms=True) ni dynamic=True. coreai-torch no tiene una conversión a nivel inferior para torchvision::nms, por lo que NMS se ejecuta en el host.
• Tamaño de entrada fijo: El grafo exportado se traza con un solo imgsz y no admite formas dinámicas, así que predice con el tamaño con el que se exportó.
• Los recursos FP16 pueden provocar un fallo al cargarse: Algunos recursos .aimodel FP16 no consiguen cargar el programa de Apple Neural Engine y MPSGraph genera una aserción fallida, lo que termina el proceso en lugar de recurrir a otra opción. Esto ocurre dentro del entorno de ejecución de Apple, antes de que se ejecute ningún código de Ultralytics, y el mismo recurso se carga con una especialización solo para CPU. Si ocurre, usa FP32 como alternativa; los recursos FP16 del SDK probados en un iPhone 17 Pro (todos los modelos nano, detección en todos los tamaños y el modelo más grande de cada tarea) se cargaron sin provocar fallos.

¿Qué formato de Apple deberías usar?#

Usa Core ML hoy si necesitas:

• Desplegar en sistemas operativos Apple actuales y antiguos
• La ruta predeterminada del SDK de iOS o Flutter de Ultralytics
• Procesamiento de imágenes con el framework Vision
• Despliegue de YOLO con FP16 e INT8 probado
• NMS integrado para modelos de detección heredados compatibles

Evalúa Core AI si puedes exigir iOS 27 o macOS 27 y necesitas:

• El entorno de ejecución de redes neuronales en el dispositivo más reciente de Apple
• Gestión explícita de la especialización y la caché
• Ejecución avanzada de modelos dinámicos o con estado
• Operaciones personalizadas de Core AI o kernels de Metal
• Depuración detallada de grafos de Core AI y análisis del rendimiento en tiempo de ejecución

Se espera que Core ML y Core AI coexistan mientras las aplicaciones realizan la transición. La compatibilidad con Core AI no elimina de inmediato la necesidad de Core ML, porque sus sistemas operativos de destino y los contratos de sus aplicaciones son distintos.

Hoja de ruta de Ultralytics#

El destino de exportación específico coreai ya está implementado: la exportación y la validación numérica abarcan los modelos YOLO26 compatibles con las tareas y se ejecutan continuamente en CI de Ultralytics en macOS 26; además, se mide la latencia FP16 en el dispositivo. La hoja de ruta restante para que Core AI alcance la paridad con la ruta de Core ML es:

1. Reducir la diferencia de latencia de la cabecera de extremo a extremo en Apple Neural Engine (apple/coreai-torch#66) y resolver los problemas de corrección de Neural Engine (apple/coreai-torch#115, #116).
2. Recursos Core AI INT8 y paletizados; los recursos del SDK son FP16 y ocupan aproximadamente el doble al descargarlos que los recursos Core ML INT8.
3. Versiones estables del framework de Apple y de las herramientas de conversión (las generaciones de iOS 27 y macOS 27 están actualmente en beta).
4. Pruebas de memoria, consumo energético y especialización en toda la matriz de dispositivos compatibles.

El SDK de iOS y el complemento de Flutter de Ultralytics cargan Core AI como opción voluntaria en iOS 27 y versiones posteriores; Core ML sigue siendo su opción predeterminada y el destino recomendado para dar cobertura a versiones anteriores a iOS 27. Consulta la hoja de ruta de Ultralytics y las notas de la versión para conocer los puntos pendientes.

Recursos adicionales#

• Descripción general de Apple Core AI
• Documentación del framework Core AI
• Extensiones de PyTorch de Core AI
• Optimización de Core AI
• Repositorio de modelos Apple Core AI
• Integración de Core ML de Ultralytics

Preguntas frecuentes#