Core AI: ejecutar modelos en Apple Silicon

Al stack de IA en el dispositivo de Apple le faltaba un peldaño. Foundation Models te entrega el LLM del sistema, sellado y gratuito. Core ML ejecuta un modelo convertido y fijo, y deja que el conversor tome por ti las decisiones de hardware. MLX ofrece un framework de arreglos que integras y un modelo que eliges. iOS 27 añade el peldaño que está por debajo de los tres: Core AI, un framework cuyo resumen de una línea es «Run AI models in your app on Apple silicon».¹ Es la superficie de ejecución de modelos, el lugar al que acudes cuando quieres dirigir tú mismo la especialización, el almacenamiento en caché y la planificación de la inferencia en lugar de aceptar los valores predeterminados de una capa superior.

En la sesión 324, Apple posiciona Core AI como el mismo framework de inferencia que impulsa Apple Intelligence en el dispositivo, ahora abierto para la inteligencia de tu propia app.¹⁵

El encuadre importa porque Core AI se sitúa por debajo de las abstracciones que la mayoría de las apps deberían usar. Apple lo describe como diseñado pensando en Apple silicon: permite que tu app use las arquitecturas de modelos y las técnicas de inferencia más recientes en la CPU, la GPU y el Neural Engine, con una API de Swift que simplifica las tareas comunes y, cuando hace falta, te da más control sobre la especialización del modelo, el almacenamiento en caché y el rendimiento de la inferencia.¹ La tesis de este artículo: acude a Core AI cuando tengas un modelo que quieras ejecutar con control explícito sobre dónde y cómo se ejecuta, y quédate en Core ML o Foundation Models cuando no sea así. El framework premia una necesidad concreta, no una preferencia por defecto.

TL;DR / conclusiones clave

• Core AI separa un AIModelAsset sin especializar (inspeccionar la estructura y los metadatos de un modelo a bajo costo) de un AIModel especializado (ejecutar inferencia en un dispositivo), con AIModelCache guardando los artefactos específicos del dispositivo y AssetError para los fallos en las operaciones sobre assets.²³⁶⁴
• Los datos de inferencia fluyen a través de NDArray, un arreglo multidimensional de valores escalares, descrito por un NDArrayDescriptor que fija la forma, el tipo escalar y las expectativas de disposición en memoria.⁵⁷
• Eliges el hardware con ComputeUnitKind (CPU, GPU o Neural Engine) mediante SpecializationOptions, y planificas el trabajo asíncrono sobre un ComputeStream.⁸⁹¹⁰
• Una InferenceFunction es dueña de los pesos y los búferes y ejecuta la inferencia; un InferenceFunctionDescriptor te permite inspeccionar antes su firma de entradas, salidas y estados. La función es Sendable, así que puedes ejecutarla de forma concurrente.¹⁴¹³
• Los modelos se cargan desde un bundle .aimodel en disco. Las herramientas alrededor del framework ya están documentadas: el paquete de Python coreai-torch convierte modelos de PyTorch, la CLI coreai-build compila .aimodel en assets .aimodelc por arquitectura de forma anticipada, y la app Core AI Debugger, junto con un medidor de depuración en Xcode y una plantilla de Instruments, cubren la inspección y el perfilado.¹⁷ Acude a Core AI cuando necesites control explícito sobre la especialización y la planificación; en caso contrario, quédate en Core ML o Foundation Models.²¹

Dos palabras que gobiernan todo el diseño: asset y modelo

Lo primero que Core AI te pide interiorizar es que un modelo en disco y un modelo que ejecuta inferencia son objetos distintos, y que especializar uno en el otro es costoso. El framework le da a cada uno su propio tipo.

Un AIModelAsset es «an unspecialized source model asset».² Lo creas a partir de la URL de un bundle .aimodel en disco y lo usas para inspeccionar un modelo sin pagar el costo de la especialización. Apple es explícito sobre por qué existe esta división: un asset de modelo te permite consultar información del modelo sin realizar la especialización, que es una operación costosa. Desde un asset puedes leer firmas de funciones, descripciones de entrada y salida, tipos de cómputo y almacenamiento, y metadatos proporcionados por el autor. Lo que no puedes hacer es ejecutar inferencia; un asset sirve solo para inspección.²

// 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.

El AIModel es la otra mitad: «a specialized model for running inference on a device».³ Un AIModel representa un asset .aimodel especializado y optimizado para el hardware del dispositivo actual, y creas uno cargando el asset desde el disco.³ El asset responde a ¿qué es este modelo?; el modelo responde ejecútalo aquí y ahora. La asimetría de costo entre ambos es la razón por la que la API te obliga a nombrar cuál de los dos quieres. Inspeccionar cien modelos candidatos para elegir uno resulta barato si solo construyes assets; sería ruinoso si cada inspección especializara.

La especialización produce artefactos específicos del dispositivo, y esos artefactos tienen un hogar: AIModelCache, «a cache that stores the specialized model artifacts for inference».⁶ La caché guarda los artefactos optimizados y específicos del dispositivo que un modelo carga para ejecutar sus funciones de inferencia, y Apple señala que cada entrada de la caché contiene un asset especializado formado a partir de un .aimodel o .aimodelc concreto y de una combinación de especialización.⁶ La lectura práctica: la especialización no es algo que quieras repetir en cada arranque. La caché es la forma en que Core AI deja que el paso costoso ocurra una vez y que el paso barato, cargar los artefactos en caché, ocurra de ahí en adelante.

Cuando las operaciones sobre assets salen mal (un bundle que falta, un .aimodel mal formado, un archivo ilegible), Core AI expone un AssetError, «an error that occurs during model asset operations».⁴ Trátalo como tratas cualquier frontera de entrada/salida: el asset vive en disco, las operaciones de disco fallan, y el sistema de tipos te dice exactamente dónde poner el catch.

Tensores: NDArray y su descriptor

La inferencia mueve números hacia dentro y hacia fuera, y el contenedor de Core AI para esos números es NDArray, «a multidimensional array of scalar values used for model inference».⁵ Si has trabajado con el ndarray de NumPy, con los arreglos de MLX o con MLMultiArray, la forma de la idea te resultará familiar: un bloque n-dimensional de escalares con una disposición definida. Un NDArray almacena sus datos en una disposición definida por su forma y por el resto de sus propiedades descriptivas.⁵

El tipo que lo acompaña es NDArrayDescriptor, «a description of an array’s shape, scalar type, and memory layout expectations».⁷ Un descriptor es el contrato. El planteamiento de Apple es directo: el descriptor contiene las expectativas para un valor de arreglo que le entregas a una función de inferencia, y la mayoría de esas expectativas son estrictas. Si el descriptor especifica un tipo escalar .float32, el arreglo que entregues debe usar .float32.⁷ No adivinas la forma ni el tipo que quiere una función; se lo preguntas a su descriptor y te ajustas a él.

// 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 lección de diseño aquí refleja la división entre asset y modelo. Core AI coloca de manera consistente un objeto de descripción barato delante de un objeto de valor costoso. Lees el descriptor para conocer el contrato y luego reservas el NDArray que lo satisface, en vez de reservar primero y descubrir una discrepancia en el momento de la inferencia. Para las entradas de imagen en concreto, Core AI también define un ImageDescriptor, «a description of an image’s dimensions and pixel format», de modo que la entrada en píxeles de un modelo de visión recibe el mismo tratamiento centrado en el descriptor.¹¹

Elegir dónde se ejecuta la inferencia

Apple silicon tiene tres lugares donde calcular: la CPU, la GPU y el Neural Engine. La razón por la que existe Core AI y no solo Core ML es que Core AI te deja decir a cuál de ellos apunta el framework, en lugar de deducirlo.

ComputeUnitKind es «a type of hardware compute unit available for model inference».⁸ Usas los tipos de unidad de cómputo junto con las opciones de especialización para controlar a qué hardware apunta el framework al especializar un modelo, y de forma predeterminada la especialización usa todas las unidades de cómputo disponibles en el dispositivo.⁸ El valor predeterminado es la respuesta correcta para la mayoría del trabajo, y ese es justamente el punto: solo lo sobrescribes cuando tienes un motivo (una ruta sensible a la latencia que quieres fijar al Neural Engine, una pasada de depuración que quieres forzar en la CPU, una canalización intensiva en GPU que estás coordinando con otro trabajo de GPU).

Esa intención la transmites mediante SpecializationOptions, la estructura que lleva las decisiones tomadas en el momento de la especialización.⁹ La especialización es el paso costoso del que hablábamos antes, y en SpecializationOptions viven la elección de unidades de cómputo y el resto de decisiones de especialización. Como una entrada de caché se indexa por un asset y una combinación de especialización concretos, cambiar tus opciones cambia qué artefacto en caché recibes de vuelta, lo que cierra el círculo entre la elección de hardware y la caché.⁶

La planificación es el otro eje del «cómo se ejecuta», y Core AI lo modela como un ComputeStream, «a stream of work to be run asynchronously».¹⁰ Un stream de cómputo es lo que proporcionas para codificar trabajo sobre él, y Apple señala que varias inferencias codificadas en el mismo stream se serializan según haga falta, a partir de los valores leídos y escritos.¹⁰ De ahí se siguen dos implicaciones. Primera, un stream es tu primitiva de ordenación: codifica inferencias dependientes en un mismo stream y Core AI las secuencia por dependencia de datos. Segunda, el trabajo es asíncrono de forma predeterminada, así que el stream es también la manera de mantener libre el hilo que llama mientras el Neural Engine o la GPU hacen el trabajo.

Funciones de inferencia: lo que realmente se ejecuta

Un .aimodel cargado no es un único invocable. Los modelos exponen funciones con nombre (un codificador, un decodificador, una torre de visión, un paso de prefill frente a uno de decode), y la unidad de ejecución de Core AI es la InferenceFunction: «a function that performs inference on input values and produces output values».¹⁴

Antes de llamar a una, la inspeccionas. InferenceFunctionDescriptor es «a description of an inference function’s signature», y usas un descriptor para inspeccionar los nombres y los tipos de las entradas, las salidas y los estados de una función antes de ejecutar la inferencia.¹³ Los estados son el detalle en el que vale la pena detenerse: una función con estado es la forma en que un modelo con estado —una caché KV en el bucle de decode de un transformer, por ejemplo— conserva información entre llamadas, y el descriptor te dice que una función los tiene antes de que intentes manejarla.

La propia InferenceFunction es dueña de los recursos que la inferencia necesita, incluidos los pesos del modelo y los búferes intermedios. Cargas una función desde un modelo y llamas a run(inputs:states:outputViews:) para realizar la inferencia.¹⁴ La firma de run aparece nombrada en la propia explicación de Apple, así que las tres cosas que necesita una llamada quedan explícitas: los valores de entrada, los valores de estado y las vistas de salida que quieres que se escriban.

// 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
)

Dos propiedades hacen que la función sea agradable bajo carga. Es Sendable, así que puedes ejecutarla de forma concurrente desde varias tareas, y Apple señala que reserva automáticamente búferes intermedios adicionales según haga falta para admitir esa concurrencia.¹⁴ No serializas las llamadas detrás de un cerrojo para proteger un espacio de trabajo compartido; la función gestiona sus propios búferes para cada llamador concurrente. Esa es una diferencia significativa frente a las API en las que un único manejador de inferencia es, en la práctica, de un solo hilo.

Los valores que circulan por run son instancias de InferenceValue, «a value that an inference function accepts as input or produces as output».¹² Un InferenceValue envuelve o bien un NDArray o bien un búfer de píxeles, y recuperas un resultado después de la inferencia usando su propiedad value.¹² El envoltorio es lo que permite que una sola firma de run transporte tanto entradas tensoriales como entradas de imagen sin sobrecargas separadas: un modelo de texto pasa valores respaldados por NDArray, uno de visión pasa valores respaldados por un búfer de píxeles, y la función lee el descriptor para saber cuál espera.

Cuándo acudir a Core AI

Lo más difícil de Core AI no es la API. Es saber que debes estar aquí y no una capa más arriba. El árbol de decisión honesto:

• Foundation Models cuando el modelo del sistema de Apple hace la tarea. Resumir, clasificar, extraer, reescribir, salida estructurada: eso pertenece al framework Foundation Models, que no te cuesta pesos, ni presupuesto de memoria, ni un paso de especialización. Si tu función encaja ahí, detente. Bajar a Core AI para reimplementar lo que el modelo del sistema ya hace es trabajo desperdiciado.
• Core ML cuando tienes un modelo convertido y fijo y quieres que el conversor tome por ti las decisiones de hardware y de optimización. Core ML apunta al Neural Engine con consumo y latencia ajustados para un modelo de producción cerrado, y no te pide nada sobre especialización ni planificación. Si no quieres pensar en la elección de unidades de cómputo ni en streams de cómputo, esa es la señal para quedarte en Core ML.
• MLX cuando quieres un framework de arreglos de nivel de investigación que integras y sobre el que iteras: tu propio bucle de entrenamiento, modelos de pesos abiertos cuantizados, ajustes finos con LoRA, experimentación rápida. MLX es una biblioteca que distribuyes junto con los pesos, no una superficie de ejecución de modelos del sistema. Gana en flexibilidad y en velocidad de iteración.
• Core AI cuando tienes un modelo que ejecutar y quieres las palancas explícitas del framework: un AIModelAsset que inspeccionas antes de comprometerte, unas SpecializationOptions que fijan unidades de cómputo, un AIModelCache que gestionas, un ComputeStream sobre el que planificas y unas InferenceFunction que llamas de forma concurrente. Llegas aquí cuando los valores predeterminados de las capas superiores son justo lo que te estorba y puedes nombrar cuál necesitas sobrescribir.

El hilo conductor de todo el stack: cada capa hacia abajo cambia un valor predeterminado por una palanca. Foundation Models te lo entrega todo y no te pide nada. Core AI te entrega las palancas y te pide saber de cuál tirar. Si no puedes nombrar el control de especialización, caché o planificación que necesitas, todavía no necesitas Core AI.

Una declaración hecha en un lab de la WWDC 2026 afina dónde está la línea entre Core AI y Core ML para el trabajo nuevo. Parafraseado a partir de una grabación transcrita localmente del WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab, un ingeniero de Core AI del panel dijo que Apple está pidiendo a todo el que trabaje con redes neuronales que pase a Core AI de aquí en adelante, con Core ML manteniéndose en su sitio pero centrado en el aprendizaje automático tradicional, como los árboles de decisión, y con todo lo nuevo dirigiéndose a Core AI.¹⁶ Léelo como una señal de dirección por parte de quienes construyen el framework, y no como una política documentada: si vas a recurrir a una red neuronal en un proyecto nuevo, el lab planteó Core AI como la superficie sobre la que construir.

Cómo llega un modelo a Core AI

El framework es la mitad de tiempo de ejecución de un flujo de trabajo mayor, y desde las betas de junio Apple ha publicado la mitad de herramientas al completo.¹⁷ La canalización funciona así.

Convertir. Empiezas con un archivo .aimodel, ya sea convertido desde un modelo de origen con el paquete coreai-torch (las Core AI PyTorch Extensions de Apple para Python) o ya preparado en ese formato.¹⁷ El .aimodel entra en tu target de Xcode como cualquier otro recurso, aparece en la fase de compilación Compile Sources y obtiene un visor de modelos en Xcode que muestra parámetros, tamaño de almacenamiento, metadatos y el grafo de operaciones. Una dependencia del sistema de compilación que conviene conocer de entrada: la integración de modelos de Core AI requiere la Metal Toolchain, que Xcode no instala de forma predeterminada, y sin ella las compilaciones que contienen archivos .aimodel fallan con un error de compilador de Metal ausente.¹⁷

Compilar de forma anticipada, opcionalmente. La especialización ocurre automáticamente cuando creas un AIModel, y en los modelos grandes ese costo de la primera carga es real. La herramienta de línea de comandos coreai-build traslada la parte más costosa, la compilación del modelo, a tu máquina de compilación: convierte .aimodel en assets .aimodelc, uno por arquitectura de dispositivo (compilar MyModel.aimodel produce MyModel.<arch>.aimodelc), y en tiempo de ejecución la app elige el asset que corresponde al dispositivo actual, de modo que Core AI se salta el paso de compilación.¹⁷ La compilación anticipada apunta al piso de hardware de Apple Intelligence: iPhone o iPad con A17 Pro o posterior, Mac con M1 o posterior, y Apple Vision Pro con M2.¹⁷

Depurar y perfilar. Tres herramientas cubren la observabilidad: el Core AI Debugger, una app independiente de macOS para inspeccionar el grafo de operaciones de un modelo, ejecutarlo contra un dispositivo y comparar salidas con una ejecución de referencia; un medidor de depuración de Core AI en Xcode que supervisa en vivo la carga, la especialización y la actividad de inferencia durante una sesión de depuración; y un instrumento de Core AI, una plantilla de Instruments que perfila los tiempos de ejecución en la CPU, la GPU y el Neural Engine.¹⁷

La forma de ejecución descrita antes encaja sin cambios en ese flujo de trabajo: el modelo preparado se carga como un AIModelAsset para inspeccionarlo, se especializa en un AIModel y se ejecuta a través de sus InferenceFunction, con AIModelCache conservando los artefactos especializados para que el paso costoso ocurra una sola vez.¹²³⁶¹⁴

Preguntas frecuentes

¿Qué es el framework Core AI de Apple?

Core AI es el framework de bajo nivel de iOS 27 para ejecutar modelos de IA en Apple silicon, resumido por Apple como «Run AI models in your app on Apple silicon».¹ Ejecuta la inferencia de modelos en la CPU, la GPU y el Neural Engine mediante una API de Swift que simplifica las tareas comunes y, cuando lo necesitas, te da control sobre la especialización del modelo, el almacenamiento en caché y el rendimiento de la inferencia.¹ Se sitúa por debajo de Foundation Models y Core ML como superficie de ejecución de modelos.

¿Cuál es la diferencia entre AIModelAsset y AIModel?

AIModelAsset es un asset de origen sin especializar que creas a partir de la URL de un bundle .aimodel en disco; lo usas para inspeccionar las firmas de funciones, las descripciones de entrada y salida, los tipos de cómputo y almacenamiento y los metadatos de un modelo sin especializar, porque la especialización es costosa, y un asset no puede ejecutar inferencia.² AIModel es el modelo especializado y optimizado para el hardware del dispositivo actual que sí ejecuta la inferencia; creas uno cargando el asset desde el disco.³ La división te permite inspeccionar a bajo costo y especializar solo cuando te comprometes.

¿Cómo elige Core AI entre la CPU, la GPU y el Neural Engine?

Controlas la elección de hardware con ComputeUnitKind mediante SpecializationOptions. Un tipo de unidad de cómputo nombra una clase de unidad de hardware disponible para la inferencia, y lo usas para controlar a qué hardware apunta el framework al especializar un modelo; de forma predeterminada, la especialización usa todas las unidades de cómputo disponibles en el dispositivo.⁸⁹ Solo sobrescribes ese valor predeterminado cuando tienes un motivo concreto, como fijar una ruta sensible a la latencia a una unidad de cómputo.

¿Qué es una InferenceFunction y cómo la ejecuto?

Una InferenceFunction realiza inferencia sobre valores de entrada y produce valores de salida, y es dueña de los pesos del modelo y de los búferes intermedios.¹⁴ Primero inspeccionas su firma con un InferenceFunctionDescriptor, que describe los nombres y los tipos de las entradas, las salidas y los estados de la función; luego cargas la función desde un AIModel y llamas a run(inputs:states:outputViews:).¹³¹⁴ La función es Sendable y reserva búferes intermedios automáticamente para admitir la concurrencia, de modo que varias tareas pueden ejecutarla a la vez.¹⁴

¿Debería usar Core AI en lugar de Core ML o Foundation Models?

Usa Foundation Models cuando el modelo del sistema haga la tarea, y Core ML cuando tengas un modelo convertido y fijo y quieras que el conversor tome por ti las decisiones de hardware y optimización. Acude a Core AI cuando quieras control explícito sobre la especialización (SpecializationOptions, ComputeUnitKind), la caché (AIModelCache) y la planificación (ComputeStream) de las que se encargan por ti las capas superiores.⁸⁹⁶¹⁰ Si no puedes nombrar el control que necesitas, quédate una capa más arriba.

El clúster completo del Ecosistema Apple: MLX en Apple Silicon para el framework de arreglos que integras cuando quieres tu propio modelo y tu propio bucle de entrenamiento; el TBDR y la memoria unificada de Apple Silicon para el sustrato de hardware que hace posible compartir CPU, GPU y Neural Engine; la inferencia en el dispositivo con Core ML para la capa de modelo fijo que está por encima de Core AI; y Foundation Models para el LLM del sistema sellado de Apple, en la cima del stack. El punto central está en la Serie del Ecosistema Apple. Para un contexto más amplio sobre iOS con agentes de IA, consulta la guía de desarrollo de agentes en iOS.

Referencias