Integración de 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 de inferencia moderna 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 próxima evolución de la ejecución de IA en el dispositivo y como el framework de inferencia que sustenta 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 distribuir el trabajo entre 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 tiempo 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 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 dirige a quienes desarrollan modelos no neuronales a esta opción.

Cómo funciona el formato Core AI#

El flujo de trabajo de creación de Core AI parte de un modelo de 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 transformación o un kernel de Metal personalizados.

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 durante el primer uso, solicitar la especialización de antemano o distribuir un modelo compilado por adelantado 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 tipadas NDArray y reciben salidas con nombre. Esto es distinto de envolver un modelo de Core ML en una solicitud de Vision, por lo que adoptar Core AI requiere un entorno de ejecución de aplicaciones diseñado para recursos .aimodel.

Para obtener detalles de 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")

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

Cómo elegir la cabecera#

Con nms=False, YOLO26 exporta su cabecera de extremo a extremo, que selecciona las detecciones dentro del grafo. Core AI no tiene una primitiva top-k, por lo que esa selección se transforma 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, al exportar con nms=None se emiten las predicciones (1, 84, 8400) sin procesar y se deja la supresión no máxima al 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 la cabecera en el grafo y 1,28 ms sin ella (FP16, compilado por adelantado, tres bloques intercalados de 50 iteraciones). En ambos casos, la inferencia se realiza mediante YOLO(...). Usa nms=False cuando una sola llamada al grafo deba devolver detecciones listas, o conserva el nms=None predeterminado para aplicar NMS externamente.

En iOS 27 o macOS 27, una aplicación cargaría y ejecutaría el recurso exportado mediante la API Swift de Core AI de Apple. Los recursos exportados usan el punto de entrada main, aceptan 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 de Core ML y Vision, la ruta de Core AI en el SDK de iOS de Ultralytics realiza su propio preprocesamiento letterbox y construye NDArray, lee los mismos metadatos de Ultralytics desde el 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 sobre 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 de YOLO26n FP16 (quantize=16) a Core ML y Core AI con la cabeza sin procesar predeterminada (nms=None), en un Mac mini con un Apple M4 (CPU con 4 núcleos de rendimiento y 6 de eficiencia, GPU de 10 núcleos y Neural Engine de 16 núcleos), 16 GB de memoria y macOS 27.0; con ultralytics 8.4.168, coremltools 9.0 para la inferencia con Core ML y coreai-torch 0.4.3 con coreai-core 1.0.0b3 para la inferencia con 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 de CPU/acelerador se alternó entre tareas en una única ejecución 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 cada framework controla la ubicación final de las operaciones.
• La detección, la segmentación, la clasificación, la estimación de pose y OBB devolvieron las mismas predicciones en ambos formatos y en todas las unidades de cálculo. En este Mac, el modelo semántico FP16 de Core ML funciona más despacio con Neural Engine como opción preferida que usando solo la CPU; el posprocesamiento semántico de Core AI tarda entre 6.4 y 7.4 ms, frente a los 0.4 ms de Core ML.
• Compara los resultados obtenidos en el dispositivo iPhone 17 Pro en la integración de CoreML.

Ventajas de Core AI#

Core AI ofrece varias ventajas prometedoras para futuras implementaciones de Ultralytics:

• Ruta moderna de exportación de PyTorch: La conversión parte de torch.export, lo que conserva un grafo de PyTorch más expresivo que el flujo de trazado utilizado por muchos exportadores actuales.
• Control detallado del tiempo 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, las funciones múltiples en un mismo artefacto y los kernels de Metal personalizados están diseñados para arquitecturas modernas de visión y generación.
• Herramientas específicas para desarrolladores: Core AI Debugger puede inspeccionar grafos y valores de tensores, y rastrearlos hasta el código Python de origen. Xcode e Instruments permiten crear perfiles del tiempo de ejecución.
• Posibilidades de copia cero: Core AI ofrece controles de almacenamiento y búfer diseñados para reducir las copias entre las cargas de trabajo de cámara, gráficos e inferencia.
• Optimización para Apple silicon: La especialización del dispositivo permite a Apple optimizar un modelo para la CPU, la GPU y el motor neuronal disponibles en ese dispositivo concreto.
• Compresión flexible: Las herramientas de optimización de Core AI de Apple admiten cuantización, paletización y poda, incluidos 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#

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

• Se requieren sistemas operativos nuevos: El framework público está dirigido a la generación de iOS 27 y macOS 27, mientras que Core ML es compatible con una base instalada mucho mayor.
• Software en beta: El framework Core AI de Apple y parte de su cadena de herramientas de Python aún son preliminares 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 intervalo 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 wheels de macosx_26_0_arm64 y manylinux_2_34_x86_64, por lo que format=coreai requiere 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 haciendo falta hardware Apple.
• Opción voluntaria 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 en 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 descargarse. 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 devuelve detecciones 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.
• Se requiere 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 salidas necesitan una implementación de Core AI fuera de los SDK de Ultralytics, que sí proporcionan una.
• Evidencia de producción limitada: Es necesario validar el rendimiento, el consumo energético, el tiempo de especialización del primer uso, la precisión y la compresión en toda la matriz de tareas YOLO y dispositivos compatibles.
• Sin flujo de trabajo de NMS: Core ML puede incluir una etapa de NMS para modelos de detección YOLO antiguos. Las exportaciones de Core AI generan predicciones de uno a muchos sin procesar de forma predeterminada; usa nms=False para la cabecera de YOLO26 sin NMS. No se admiten el NMS integrado (nms=True) ni dynamic=True. coreai-torch no tiene una transformación para torchvision::nms, por lo que NMS se ejecuta en el host.
• Tamaño de entrada fijo: El grafo exportado se traza con un único imgsz y no admite formas dinámicas, así que haz predicciones con el tamaño utilizado para exportarlo.
• Los recursos FP16 pueden provocar un fallo al cargarse: Algunos recursos FP16 .aimodel no consiguen cargar su programa del motor neuronal de Apple y MPSGraph genera una aserción fallida, lo que finaliza el proceso en lugar de recurrir a otra opción. Esto ocurre dentro del tiempo de ejecución de Apple, antes de que se ejecute código de Ultralytics, y el mismo recurso se carga con una especialización solo para CPU. Si ocurre, recurre a FP32; los recursos FP16 del SDK comprobados en un iPhone 17 Pro (todos los modelos nano, los modelos de detección en todos los tamaños y el modelo más grande de cada tarea) se cargaron sin fallos.

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

Usa Core ML hoy si necesitas:

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

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

• El entorno de ejecución de redes neuronales en 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 creación de perfiles del tiempo de ejecución

Se espera que Core ML y Core AI coexistan durante la transición de las aplicaciones. La compatibilidad con Core AI no elimina de inmediato la necesidad de Core ML, ya que sus destinos de implementación y contratos de aplicación 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 de las tareas YOLO26 compatibles y se ejecutan continuamente en la CI de Ultralytics en macOS 26; además, la latencia FP16 se mide en el dispositivo. La hoja de ruta restante para que Core AI alcance la paridad con la ruta de Core ML:

1. Cerrar la brecha de latencia de la cabecera de extremo a extremo en el motor neuronal de Apple (apple/coreai-torch#66) y resolver los problemas de precisión del motor neuronal (apple/coreai-torch#115, #116).
2. Recursos Core AI INT8 y paletizados; los recursos del SDK son FP16 y ocupan aproximadamente el doble al descargarse que los recursos Core ML INT8.
3. Versiones estables del framework y las herramientas de conversión de Apple (la generación de iOS 27 y macOS 27 está 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 de forma opcional en iOS 27 y posteriores; Core ML sigue siendo la opción predeterminada y el destino recomendado para ofrecer compatibilidad con versiones anteriores a iOS 27. Consulta la hoja de ruta de Ultralytics y las notas de la versión para ver los elementos pendientes.

Recursos adicionales#

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

Preguntas frecuentes#