Core AI: ejecutar modelos en Apple silicon

Al stack de IA en el dispositivo de Apple le faltaba un peldaño. Foundation Models te da el LLM del sistema, sellado y gratis. Core ML ejecuta un modelo convertido fijo, y el conversor toma por ti las decisiones de hardware. MLX entrega un framework de arrays que tú integras y un modelo que tú 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 “Ejecuta modelos de IA en tu app en Apple silicon.”¹ Es la superficie de ejecución de modelos, el lugar al que recurres cuando quieres gobernar tú mismo la especialización, el caché y la planificación de la inferencia en lugar de aceptar los valores por defecto 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, de modo que tu app pueda usar las arquitecturas de modelos y las técnicas de inferencia más recientes a través del CPU, la GPU y el Neural Engine, con una API de Swift que vuelve simples las tareas comunes y a la vez te da más control sobre la especialización del modelo, el caché y el rendimiento de la inferencia cuando lo necesitas.¹ La tesis de este artículo: recurre 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 recompensa una necesidad específica, no una preferencia por defecto.

TL;DR / Puntos clave

• Core AI separa un AIModelAsset sin especializar (inspecciona la estructura y los metadatos de un modelo de forma barata) de un AIModel especializado (ejecuta la inferencia en un dispositivo), con AIModelCache reteniendo los artefactos específicos del dispositivo y AssetError para los fallos de operaciones sobre assets.²³⁶⁴
• Los datos de inferencia fluyen a través de NDArray, un array multidimensional de valores escalares, descrito por un NDArrayDescriptor que fija la forma, el tipo escalar y las expectativas de disposición en memoria.⁵⁷
• Seleccionas el hardware con ComputeUnitKind (CPU, GPU o Neural Engine) a través de SpecializationOptions, y planificas el trabajo asíncrono sobre un ComputeStream.⁸⁹¹⁰
• Una InferenceFunction posee los pesos y los búferes y ejecuta la inferencia; un InferenceFunctionDescriptor te deja inspeccionar primero su firma de entradas, salidas y estado. La función es Sendable, así que puedes ejecutarla de forma concurrente.¹⁴¹³
• Los modelos se cargan desde un bundle .aimodel en disco, y Core AI incluye herramientas de preparación, conversión y depuración junto al framework. Recurre a Core AI cuando necesites control explícito sobre la especialización y la planificación; de lo contrario, quédate en Core ML o Foundation Models.²¹

Dos palabras que rigen 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 especializar uno en el otro es costoso. El framework le da un tipo a cada uno.

Un AIModelAsset es “un asset de modelo de origen sin especializar.”² 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 la división: un asset de modelo te permite consultar la 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 los metadatos provistos 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: “un modelo especializado para ejecutar inferencia en un dispositivo.”³ Un AIModel representa un asset .aimodel especializado y optimizado para el hardware del dispositivo actual, y creas uno cargando el asset desde disco.³ El asset responde ¿qué es este modelo?; el modelo responde ejecútalo aquí, 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 es 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, “un caché que almacena los artefactos de modelo especializados para la inferencia.”⁶ El caché retiene 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 del caché contiene un asset especializado formado a partir de un .aimodel o .aimodelc específico y una combinación de especialización.⁶ La lectura práctica: la especialización no es algo que quieras repetir en cada arranque. El caché es la forma en que Core AI permite que el paso costoso ocurra una sola vez y que el paso barato (cargar los artefactos en caché) ocurra de ahí en adelante.

Cuando las operaciones sobre un asset salen mal (un bundle ausente, un .aimodel malformado, un archivo que no se puede leer), Core AI expone un AssetError, “un error que ocurre durante las operaciones sobre assets de modelo.”⁴ Trátalo como tratas cualquier frontera de E/S: 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 de entrada y números de salida, y el contenedor de Core AI para esos números es NDArray, “un array multidimensional de valores escalares usado para la inferencia de modelos.”⁵ Si has trabajado con ndarray de NumPy, los arrays de MLX o 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 el resto de sus propiedades descriptivas.⁵

El tipo acompañante es NDArrayDescriptor, “una descripción de la forma de un array, su tipo escalar y las expectativas de disposición en memoria.”⁷ Un descriptor es el contrato. El encuadre de Apple es directo: el descriptor contiene las expectativas para un valor de array que provees a una función de inferencia, y la mayoría de las expectativas son estrictas. Si el descriptor especifica un tipo escalar .float32, el array que provees debe usar .float32.⁷ No adivinas la forma y el tipo que quiere una función; le preguntas al descriptor de la función 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 asset/modelo. Core AI pone de forma consistente un objeto de descripción barato delante de un objeto de valor costoso. Lees el descriptor para conocer el contrato y luego asignas el NDArray que lo satisface, en lugar de asignar primero y descubrir un desajuste en tiempo de inferencia. Para entradas de imagen en concreto, Core AI también define un ImageDescriptor, “una descripción de las dimensiones de una imagen y su formato de píxel,” de modo que la entrada de píxeles de un modelo de visión recibe el mismo tratamiento de descriptor-primero.¹¹

Elegir dónde se ejecuta la inferencia

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

ComputeUnitKind es “un tipo de unidad de cómputo de hardware disponible para la inferencia de modelos.”⁸ Usas los tipos de unidad de cómputo con las opciones de especialización para controlar qué hardware selecciona el framework al especializar un modelo, y por defecto la especialización usa todas las unidades de cómputo disponibles en el dispositivo.⁸ El valor por defecto es la respuesta correcta para la mayoría del trabajo, y ese es el punto: solo lo sobrescribes cuando tienes una razón (una ruta sensible a la latencia que quieras fijar al Neural Engine, una pasada de depuración que quieras forzar al CPU, un pipeline intensivo en GPU que estés coordinando con otro trabajo de GPU).

Pasas esa intención a través de SpecializationOptions, la estructura que lleva las decisiones tomadas en el momento de la especialización.⁹ La especialización es el paso costoso de antes, y SpecializationOptions es donde viven la selección de unidad de cómputo y las demás decisiones de especialización. Como una entrada del caché se indexa por un asset específico y una combinación de especialización, cambiar tus opciones cambia qué artefacto en caché recuperas, lo que cierra el círculo entre selección y caché.⁶

La planificación es el otro eje de “cómo se ejecuta,” y Core AI lo modela como un ComputeStream, “un stream de trabajo que se ejecuta de forma asíncrona.”¹⁰ Un compute stream es lo que provees para codificar el trabajo en el stream, y Apple señala que múltiples inferencias codificadas al mismo stream se serializan según se necesite, en función de los valores leídos y escritos.¹⁰ De ahí se siguen dos implicaciones. Primero, un stream es tu primitiva de ordenación: codifica inferencias dependientes en un mismo stream y Core AI las secuencia por dependencia de datos. Segundo, el trabajo es asíncrono por defecto, así que el stream es también la forma de mantener libre el hilo que llama mientras el Neural Engine o la GPU hacen el trabajo.

Funciones de inferencia: lo que de verdad se ejecuta

Un .aimodel cargado no es un único elemento invocable. Los modelos exponen funciones con nombre (un encoder, un decoder, 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: “una función que realiza inferencia sobre valores de entrada y produce valores de salida.”¹⁴

Antes de llamar a una, la inspeccionas. InferenceFunctionDescriptor es “una descripción de la firma de una función de inferencia,” y usas un descriptor para inspeccionar los nombres y tipos de las entradas, salidas y 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 (un KV cache en un 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 posee 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 exposición de Apple, así que las tres cosas que necesita una llamada son 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 múltiples tareas, y Apple señala que asigna automáticamente búferes intermedios adicionales según se necesite para sustentar esa concurrencia.¹⁴ No serializas las llamadas detrás de un lock para proteger un espacio de trabajo compartido; la función gestiona sus propios búferes por cada llamante concurrente. Esa es una diferencia significativa frente a las API donde un único handle de inferencia es, en la práctica, de un solo hilo.

Los valores que fluyen a través de run son instancias de InferenceValue, “un valor que una función de inferencia acepta como entrada o produce como salida.”¹² Un InferenceValue envuelve ya sea un NDArray o un búfer de píxeles, y recuperas un resultado tras la inferencia usando su propiedad value.¹² El envoltorio es lo que permite que una sola firma de run lleve tanto entradas de tensor como entradas de imagen sin sobrecargas separadas: un modelo de texto pasa valores respaldados por NDArray, un modelo 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 recurrir a Core AI

La parte más difícil de Core AI no es la API. Es saber que debes estar aquí en absoluto, en lugar de una capa más arriba. El árbol de decisión honesto:

• Foundation Models cuando el modelo de sistema de Apple hace la tarea. Resumir, clasificar, extraer, reescribir, salida estructurada: esto pertenece a Foundation Models, que no te cuesta pesos, ni presupuesto de memoria, ni un paso de especialización. Si tu función encaja, detente ahí. Bajar a Core AI para reimplementar lo que el modelo de 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 optimización. Core ML selecciona el Neural Engine con potencia y latencia ajustadas para un modelo de producción cerrado, y no te pide nada sobre especialización ni planificación. Si no quieres pensar en la selección de unidad de cómputo ni en los compute streams, esa es la señal para quedarte en Core ML.
• MLX cuando quieres un framework de arrays de nivel de investigación que integras e iteras: tu propio bucle de entrenamiento, modelos de pesos abiertos cuantizados, fine-tunes con LoRA, experimentación rápida. MLX es una librería que envías junto con los pesos, no una superficie de ejecución de modelos de sistema. Gana en flexibilidad y velocidad de iteración.
• Core AI cuando tienes un modelo que ejecutar y quieres los controles explícitos del framework: un AIModelAsset que inspeccionas antes de comprometerte, SpecializationOptions que fijan unidades de cómputo, un AIModelCache que gestionas, un ComputeStream sobre el que planificas y InferenceFunctions que llamas de forma concurrente. Recurres aquí cuando los valores por defecto de las capas superiores son justo lo que se interpone en tu camino, y puedes nombrar qué valor por defecto necesitas sobrescribir.

El hilo conductor a lo largo de todo el stack: cada capa hacia abajo entrega un valor por defecto a cambio de un control. Foundation Models te entrega todo y no te pide nada. Core AI te entrega las palancas y te pide que sepas 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 de 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 todos los que trabajan con redes neuronales que pasen a Core AI de aquí en adelante, con Core ML quedándose en su lugar pero enfocado en machine learning tradicional, como los árboles de decisión, y todo lo nuevo dirigiéndose a Core AI.¹⁶ Léelo como una señal de dirección de marcha de las personas que construyen el framework, más que como una política documentada: si vas a recurrir a una red neuronal en un proyecto nuevo, el lab encuadró Core AI como la superficie sobre la que construir.

Cómo llega un modelo a Core AI

El framework es la mitad de runtime de un flujo de trabajo más grande. Apple señala que Core AI incluye herramientas adicionales para la preparación, integración y depuración de modelos junto al framework: preparas tus modelos para Apple silicon, los conviertes al formato .aimodel y usas una app acompañante que soporta visualización y depuración numérica.¹ La descripción de esos nombres de herramientas en la ficha técnica está truncada, así que confirma los nombres exactos de las herramientas y su invocación contra la documentación de Core AI de Apple en lugar de confiar en cualquier reconstrucción.¹ Lo que sí está verificado es la forma del pipeline: un modelo de origen se prepara, se convierte a .aimodel, se carga como un AIModelAsset para inspección, se especializa en un AIModel y se ejecuta a través de sus InferenceFunctions, 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 “Ejecuta modelos de IA en tu app en Apple silicon.”¹ Ejecuta la inferencia de modelos a través del CPU, la GPU y el Neural Engine mediante una API de Swift que vuelve simples las tareas comunes y a la vez te da control sobre la especialización del modelo, el caché y el rendimiento de la inferencia cuando lo necesitas.¹ 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 de un modelo, las descripciones de entrada y salida, los tipos de cómputo y almacenamiento, y los metadatos, sin especializar, porque la especialización es costosa, y un asset no puede ejecutar inferencia.² AIModel es el modelo especializado, optimizado para el hardware del dispositivo actual, que sí ejecuta inferencia; creas uno cargando el asset desde disco.³ La división te permite inspeccionar de forma barata y especializar solo cuando te comprometes.

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

Controlas la selección de hardware con ComputeUnitKind a través de SpecializationOptions. Un tipo de unidad de cómputo nombra un tipo de unidad de cómputo de hardware disponible para la inferencia, y lo usas para controlar qué hardware selecciona el framework al especializar un modelo; por defecto la especialización usa todas las unidades de cómputo disponibles en el dispositivo.⁸⁹ Sobrescribes el valor por defecto solo cuando tienes una razón específica, 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 posee los pesos del modelo y los búferes intermedios.¹⁴ Inspeccionas primero su firma a través de un InferenceFunctionDescriptor, que describe los nombres y tipos de las entradas, salidas y 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 asigna búferes intermedios automáticamente para sustentar la concurrencia, así que múltiples 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 de sistema hace la tarea, y Core ML cuando tienes un modelo convertido y fijo y quieres que el conversor tome por ti las decisiones de hardware y optimización. Recurre a Core AI cuando quieras control explícito sobre la especialización (SpecializationOptions, ComputeUnitKind), el caché (AIModelCache) y la planificación (ComputeStream) que las capas superiores gestionan en tu nombre.⁸⁹⁶¹⁰ Si no puedes nombrar el control que necesitas, quédate una capa más arriba.

El cluster completo de Apple Ecosystem: MLX en Apple Silicon para el framework de arrays que integras cuando quieres tu propio modelo y bucle de entrenamiento; TBDR y memoria unificada de Apple Silicon para el sustrato de hardware que hace funcionar el reparto entre CPU/GPU/Neural Engine; inferencia en el dispositivo con Core ML para la capa de modelo fijo por encima de Core AI; y Foundation Models para el LLM de sistema sellado de Apple en la cima del stack. El hub está en la serie Apple Ecosystem. Para un contexto más amplio de iOS con agentes de IA, consulta la guía de desarrollo de agentes en iOS.

Referencias