Inferencia con Core ML en el dispositivo: los patrones que de verdad llegan a producción

Core ML es el motor de inferencia en el dispositivo que viene incluido en todos los dispositivos Apple modernos. El framework reparte el trabajo al Neural Engine cuando está disponible, a la GPU cuando no lo está y a la CPU como último recurso, eligiendo automáticamente la ruta más rápida según el modelo y el hardware¹. En un iPhone reciente el resultado es una inferencia con latencias que van de menos de un milisegundo a unas pocas decenas de milisegundos para la mayoría de los tamaños de modelo de producción, gratuita en cada llamada, sin viaje de ida y vuelta a la red y sin exponer datos a terceros.

La fama del framework como «fontanería oscura» está desfasada. Core ML lleva casi una década impulsando funciones que se ejecutan en el dispositivo, desde la búsqueda semántica de Fotos hasta la mayoría de las apps de terceros que llevan ML local, y sigue siendo la superficie de producción de un modelo fijo y convertido en todos los sistemas operativos hasta iOS 11. Su lugar en la pila sí cambió en la WWDC 2026: Apple presentó Core AI como el framework de bajo nivel que impulsa Apple Intelligence en el dispositivo y lo señaló como la dirección para el trabajo nuevo con redes neuronales¹¹¹². Los patrones que hacen que un despliegue de Core ML llegue realmente a producción, en lugar de quedarse en «funciona en mi Mac», no han cambiado y siguen siendo un conjunto pequeño: conversión del modelo, orientación del reparto, presupuestos de latencia y cuantización. Este artículo recorre cada uno de ellos contrastándolo con la documentación de Apple y después sitúa a Core ML en la pila posterior a la WWDC26.

TL;DR

• Core ML ejecuta archivos .mlpackage y .mlmodel en el Neural Engine, la GPU y la CPU de Apple Silicon. El reparto es automático, pero se puede orientar mediante MLModelConfiguration.computeUnits².
• La conversión del modelo ocurre a través de coremltools (PyTorch, TensorFlow, ONNX → Core ML). La conversión es una tarea de herramientas, no de tiempo de ejecución; una vez convertido y empaquetado el modelo, la app lo carga y lo ejecuta.
• La arquitectura de memoria unificada de Apple Silicon implica que los pesos del modelo no se copian entre CPU, GPU y NE: la misma memoria respalda a las tres³. Ese detalle arquitectónico es lo que hace posible una inferencia por debajo del milisegundo.
• La cuantización (INT8 e INT4 en las versiones recientes de Core ML) reduce el tamaño del modelo y acelera la inferencia en el Neural Engine, con un costo de precisión medible que depende del modelo. coremltools 9.0 (noviembre de 2025) añade objetivos de despliegue para iOS 26, lectura y escritura del estado del modelo, y entradas y salidas de modelo en int8¹³.
• La pila cambió en la WWDC 2026: Apple posiciona a Core AI como el framework de inferencia detrás de Apple Intelligence en el dispositivo y como la superficie para el trabajo nuevo con redes neuronales, mientras Core ML continúa como la capa de producción para modelos fijos ya convertidos y para el ML tradicional¹¹¹².

El modelo mental: tres rutas de cómputo, una sola memoria

Apple Silicon (Mac de la serie M y iPhone de la serie A desde el A12 Bionic) trae tres destinos de inferencia:

Neural Engine. Un acelerador especializado en multiplicación de matrices con precisión baja. El más rápido para las operaciones de las que dependen los modelos de ML modernos (convoluciones, atención, embeddings). El de menor consumo. Está limitado a tipos de operación y formas de tensor concretos; las operaciones no admitidas caen capa por capa a la GPU o a la CPU.

GPU. Cómputo paralelo de propósito general a través de Metal. Más lenta que el Neural Engine para el trabajo con forma de ML, pero más rápida que la CPU. Se encarga de las operaciones que el Neural Engine no admite.

CPU. El respaldo. Lenta para la inferencia de ML, pero siempre disponible, siempre capaz de ejecutar cualquier operación y predecible.

La arquitectura de memoria unificada implica que la misma RAM física respalda a las tres³. Los pesos de un modelo, cargados una sola vez, no se copian cuando el reparto se desplaza entre destinos. Ese hecho arquitectónico es lo que convierte el reparto entre varios destinos: en lugar de un costo de copia por capa, queda una decisión de planificación por capa.

MLModelConfiguration.computeUnits controla el reparto:

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all es el valor predeterminado y la elección correcta para casi cualquier app. El framework elige la ruta más rápida operación por operación, y esa decisión por operación es mejor que cualquier heurística que escribieras a mano. La razón poco frecuente para anularlo es forzar .cpuOnly para lograr paridad en las pruebas (un modelo se comporta de forma distinta en cada ruta y la prueba necesita la ruta determinista) o forzar .cpuAndGPU para liberar el Neural Engine y dedicarlo a otra tarea concurrente.

Conversión del modelo: la tarea de herramientas

La mayoría de los modelos de ML se entrenan en PyTorch, en TensorFlow o directamente con Create ML de Apple. Core ML acepta archivos .mlpackage, el formato moderno introducido en Xcode 13 que sustituye al antiguo .mlmodel⁴. La conversión ocurre a través de coremltools, el paquete de Python de código abierto de Apple⁵.

Una conversión típica de PyTorch a Core ML sigue tres pasos:

1. Cargar el modelo de PyTorch entrenado y ponerlo en modo de inferencia.
2. Trazar el modelo con un tensor de entrada de ejemplo que coincida con la forma de entrada de producción.
3. Convertir el modelo trazado con coremltools contra una versión de iOS de destino.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

La conversión sucede una sola vez, en un entorno de desarrollo, contra una versión de iOS de destino (minimum_deployment_target). El .mlpackage resultante es lo que se coloca en el proyecto de Xcode. La app en ejecución no ejecuta coremltools. La versión actual, coremltools 9.0, añade objetivos de despliegue hasta iOS 26, la capacidad de leer y escribir el estado del modelo (para modelos con estado, como los decodificadores de transformers con caché KV), entradas y salidas de modelo en int8, y compatibilidad con Python 3.13 y PyTorch 2.7¹³.

Hay dos trampas prácticas en la conversión. Primera: las entradas de forma dinámica necesitan un tratamiento explícito mediante ct.RangeDim, porque la forma estática que Core ML asume por defecto produce errores poco útiles cuando la app de producción le entrega tamaños de entrada variables. Segunda: las operaciones personalizadas de PyTorch que no tienen equivalente en Core ML requieren o bien una capa personalizada de Core ML (código Swift que ejecuta la operación ausente) o bien un cambio en la arquitectura del modelo que elimine esa operación antes de convertir. Ambos casos están bien documentados⁵.

Presupuestos de latencia que sí se aplican

Para las apps que llegan a producción importan tres presupuestos de latencia:

16 ms (interfaz en vivo a 60 fps). Un filtro de cámara en tiempo real, una escena de AR que se actualiza en cada fotograma, un analizador de audio en vivo. El presupuesto lo incluye todo: preprocesamiento de la imagen, inferencia del modelo, posprocesamiento y actualización de la interfaz. Los modelos que caben suelen ser pequeños (clase MobileNetV3, menos de 100 M de parámetros) y se ejecutan en el Neural Engine.

100 ms (interfaz interactiva). El usuario realiza una acción y espera el resultado: tocar para identificar, dibujar para reconocer, dictar para transcribir. El presupuesto es más permisivo y admite modelos más grandes. Los modelos de lenguaje de menos de mil millones de parámetros, los transformers de visión pequeños y la mayoría de los clasificadores de calidad de producción caben con holgura.

1 s o más (segundo plano o por lotes). Indexación de la fototeca, análisis de documentos, calentamiento del modelo al abrir la app. Los modelos más grandes funcionan, pero hay que ajustar la expectativa del usuario con un indicador de progreso. El LLM en el dispositivo de Foundation Models vive aquí para las operaciones con ventana de contexto grande.

Los presupuestos son guías, no límites estrictos. Lo correcto es medir en un dispositivo de destino con os_signpost o con la plantilla de Core ML de Instruments⁶ en lugar de confiar en cifras teóricas obtenidas en otra máquina.

Cuantización: cuando más pequeño es más rápido

Core ML admite varios niveles de cuantización⁷:

• Float32 (precisión completa). El valor predeterminado del entrenamiento. El más grande, el más preciso, el más lento.
• Float16. Media precisión. Más pequeño y más rápido en la GPU y en el NE; la pérdida de precisión suele ser insignificante en modelos bien condicionados.
• INT8. Cuantización entera de 8 bits con calibración. Alrededor de 4x más pequeño que Float32 y a menudo entre 2-4x más rápido en el NE. La pérdida de precisión varía; en modelos de visión es alcanzable una pérdida de precisión top-1 inferior al 1 % con entrenamiento consciente de la cuantización.
• INT4 y por debajo. Cuantización agresiva que las versiones recientes de Core ML admiten para arquitecturas concretas (LLM y modelos de visión grandes). La contrapartida es una pérdida de precisión significativa; la técnica funciona mejor combinada con entrenamiento consciente de la cuantización y adaptado al modelo.

La configuración de la cuantización lineal mediante coremltools.optimize.coreml.linear_quantize_weights acepta una configuración global de operaciones que elige el modo de cuantización (linear_symmetric o linear) y un umbral de tamaño de peso por debajo del cual los pesos se mantienen en precisión completa. La conversión se ejecuta sobre un .mlpackage existente y produce un paquete cuantizado nuevo; ambos pueden convivir en el bundle, y la app decide cuál cargar según la clase de dispositivo.

La decisión de cuantizar se toma modelo a modelo: un clasificador pequeño puede no beneficiarse porque su cómputo ya es barato; un modelo de lenguaje grande se beneficia enormemente porque su cómputo lo dominan las multiplicaciones de matrices sobre los pesos cuantizados. El enfoque correcto es cuantizar, medir la precisión en un conjunto de prueba reservado y publicar si la pérdida resulta aceptable para el caso de uso.

Los modelos integrados de Apple que puedes usar tal cual

Apple ofrece varios modelos de Core ML preentrenados en la página Core ML Models⁸. Categorías que conviene conocer:

• Clasificación de imágenes: MobileNetV2, ResNet50 y variantes de SqueezeNet, todas empaquetadas y listas para colocarse en un VNCoreMLRequest del framework Vision.
• Detección de objetos: YOLOv3, MNIST y variantes de CenterNet.
• Estimación de pose: PoseNet para la pose corporal (una alternativa de referencia frente a VNDetectHumanBodyPoseRequest de Vision).
• Segmentación semántica: DeepLabV3 para segmentación de imágenes.
• Reconocimiento de texto: alternativas de OCR basadas en ML frente al reconocimiento integrado de Vision.

Para la mayoría de las apps, los modelos preentrenados de Apple cubren las primitivas de percepción (clasificar, detectar, segmentar) sin necesidad de entrenamiento propio. Para las tareas de lenguaje, el LLM del sistema en el dispositivo se sitúa por completo encima de esta capa: el framework Foundation Models lo expone tras una API de Swift de alto nivel, sin conexión y sin costo, sin ningún archivo de modelo que tengas que empaquetar ni convertir.

Cifrado del modelo y consideraciones para la App Store

Un .mlpackage dentro del bundle de la app puede leerlo cualquiera que descomprima el IPA. Para modelos que representan propiedad intelectual de peso, Apple admite el cifrado del modelo mediante el flujo Encrypt your Core ML model⁹: se genera una clave de cifrado desde Xcode y se gestiona mediante CloudKit, el modelo del bundle queda cifrado y Core ML lo descifra al cargarlo.

Para la mayoría de las apps, el cifrado es excesivo. Un modelo entrenado con datos corrientes de ImageNet no es un factor de diferenciación competitiva; cifrarlo añade complejidad operativa sin proteger nada valioso. Reserva el cifrado para modelos que representen una inversión real en datos de entrenamiento o una ventaja competitiva.

Privacidad en el dispositivo: la victoria arquitectónica

El argumento de privacidad es directo. La inferencia de Core ML ocurre por completo en el dispositivo. Los datos de entrada (imágenes, audio, texto) no salen del dispositivo. El archivo del modelo es local; la inferencia es local; el resultado es local.

Para apps de sectores regulados (salud, finanzas, educación), ese hecho arquitectónico elimina toda una categoría de trabajo de cumplimiento. No hay ningún encargado del tratamiento de datos externo que añadir a una política de privacidad. No hay ningún endpoint de API de modelo cuya seguridad haya que auditar. No hay ninguna pregunta sobre residencia de datos, porque los datos nunca se mueven.

El formato Privacy Manifest¹⁰ deja por escrito ese argumento de privacidad para el envío a la App Store: una app que usa Core ML para inferencia en el dispositivo y nada más puede declarar cero intercambio de datos con terceros en la ruta de inferencia. El proceso de envío es más rápido, la revisión de privacidad más corta y la etiqueta de privacidad que ve el usuario más limpia.

La conexión con los flujos de trabajo de agentes

Core ML se combina con tres patrones que este grupo de artículos ya ha cubierto:

El VNCoreMLRequest del framework Vision. Los modelos personalizados de Core ML pasan por el pipeline de Vision con preprocesamiento automático. Ese patrón (tratado en Vision Framework) es la forma correcta de publicar un clasificador o un detector de imágenes propio dentro de una app de iOS.

El LLM en el dispositivo de Foundation Models. El LLM del sistema de Apple Intelligence vive detrás del framework Foundation Models y, desde la WWDC 2026, Apple identifica a Core AI como el framework de inferencia que lo impulsa¹¹. Los conceptos de este artículo se trasladan igual de bien: el reparto entre unidades de cómputo, los pesos cuantizados y los presupuestos de latencia gobiernan el LLM del sistema del mismo modo que gobiernan un modelo que convertiste tú. El artículo sobre el framework cubre la API del LLM; este cubre los patrones de inferencia que hay debajo.

Herramientas de App Intents que usan ML local. Un AppIntent que ejecuta un clasificador local de imágenes o de texto devuelve resultados estructurados a Apple Intelligence sin viaje de ida y vuelta a la red. Esa combinación es lo que hace que un «Apple con agentes» sea de verdad privado: las herramientas del agente se ejecutan en local porque el framework lo permite.

Cuándo la inferencia en la nube es la decisión correcta

El techo de Core ML es el cómputo del dispositivo. Tres casos en los que la nube es lo correcto:

Modelos demasiado grandes para empaquetarlos. Un LLM de 70 000 millones de parámetros no cabe en el bundle de una app. Para cargas de trabajo de esa escala, la inferencia en la nube (o la ejecución en el dispositivo con pesos transmitidos en streaming, que es otro patrón) es la herramienta adecuada.

Estado compartido entre dispositivos durante la inferencia. Modelos que necesitan leer o escribir en una base de datos compartida durante la inferencia (sistemas de recomendación con filtrado colaborativo sobre miles de millones de registros). El modelo puramente local de Core ML no encaja.

Iteración rápida del modelo. Un equipo que publica actualizaciones del modelo a diario se beneficia de la inferencia en el servidor, porque los despliegues no requieren ciclos de revisión de la App Store. El patrón de Core ML de empaquetar el modelo dentro de la app añade fricción a la cadencia de revisiones del modelo; esa compensación es real.

El patrón: la nube gana en escala y velocidad de iteración; Core ML gana en latencia, costo y privacidad.

Dónde queda Core ML después de la WWDC 2026

La WWDC 2026 redibujó el mapa que hay bajo este artículo sin invalidarlo. Apple presentó Core AI, un framework de iOS 27 cuyo resumen dice «Run AI models in your app on Apple silicon», y afirmó en la sesión 324 que Core AI es el framework de inferencia que impulsa Apple Intelligence en el dispositivo y que ahora se abre a apps de terceros¹¹. Donde el conversor de Core ML toma por ti las decisiones de hardware y optimización, Core AI te entrega las palancas: especialización explícita del modelo, una caché de artefactos gestionada, selección de unidades de cómputo y flujos de cómputo asíncronos. El desglose completo está en Core AI: ejecutar modelos en Apple silicon.

La señal sobre la dirección del viaje es más fuerte de lo que sugiere la documentación por sí sola. En el group lab de aprendizaje automático de la WWDC 2026, un ingeniero de Core AI dijo que Apple está pidiendo a todo el que trabaje con redes neuronales que se pase a Core AI de aquí en adelante, y que Core ML se mantiene, pero centrado en el aprendizaje automático tradicional, como los árboles de decisión¹². Esa afirmación es una paráfrasis de un lab y no una política publicada, pero encaja con la forma del lanzamiento: Core AI recibió las herramientas nuevas, los formatos nuevos y la carga de trabajo de Apple Intelligence.

La lectura práctica para una app que se publica hoy:

• Los despliegues existentes de Core ML siguen funcionando. Nada en iOS 27 declara obsoleta la vía de .mlpackage, y coremltools 9.0 trajo capacidades nuevas (objetivos de iOS 26, modelos con estado, E/S en int8) tan recientemente como en noviembre de 2025¹³.
• Core ML sigue siendo la única opción por debajo de iOS 27 y la opción pragmática para un modelo fijo ya convertido cuando los valores predeterminados del conversor son justo lo que quieres.
• El trabajo nuevo con redes neuronales dirigido a iOS 27+ debería evaluar primero Core AI, sobre todo cuando puedes nombrar la especialización, el almacenamiento en caché o el control de planificación que necesitas.
• Las demás capas no se mueven. El LLM del sistema sigue detrás de Foundation Models, y MLX sigue siendo el framework de arreglos incrustable para modelos de pesos abiertos y ajustes finos propios. Core ML frente a Core AI es una pregunta sobre la capa de ejecución de tu modelo, no sobre esas otras piezas.

Qué significa este patrón para las apps de iOS 26 en adelante

Tres conclusiones.

1. Elige Core ML por defecto para cualquier modelo que quepa en el bundle y produzca por llamada un resultado sobre el que el usuario pueda actuar. Clasificación de imágenes, detección de objetos, clasificación de audio, reconocimiento de gestos, generación de embeddings y tareas de lenguaje de tamaño pequeño a medio. El reparto automático del framework y la NPU de Apple Silicon producen gratis una inferencia que va de menos de un milisegundo a unas pocas decenas de milisegundos.

2. Cuantiza de forma agresiva mientras la pérdida de precisión sea aceptable. INT8 suele ser seguro; INT4 es apropiado para modelos grandes donde el ahorro de tamaño importa. Mide la precisión en un conjunto reservado en lugar de dar por hecho que la cuantización es segura siempre.

3. Combínalo con Vision y Foundation Models para pipelines totalmente locales. Core ML es el motor; Vision es la API de percepción que va encima; Foundation Models es el LLM que va encima. El artículo sobre Vision y el artículo sobre Foundation Models de este grupo cubren las superficies de más alto nivel.

El grupo completo sobre el ecosistema Apple: los App Intents tipados; los servidores MCP; la cuestión del enrutado; Foundation Models; la distinción entre el LLM de ejecución y el de herramientas; las tres superficies; el patrón de la fuente única de verdad; Dos servidores MCP; los hooks para el desarrollo en Apple; las Live Activities; el contrato de ejecución de watchOS; las entrañas de SwiftUI; el modelo mental espacial de RealityKit; la disciplina de esquema en SwiftData; los patrones de Liquid Glass; la publicación multiplataforma; la matriz de plataformas; el framework Vision; los Symbol Effects; sobre qué me niego a escribir. El eje central es la serie sobre el ecosistema Apple. Para un contexto más amplio sobre iOS con agentes de IA, consulta la guía de desarrollo de agentes en iOS.

Preguntas frecuentes

¿Cómo decide Core ML entre Neural Engine, GPU y CPU?

Core ML examina cada operación del grafo del modelo y la envía al destino más rápido que la admita. El Neural Engine se encarga de las operaciones admitidas (la mayoría de las multiplicaciones de matrices, las convoluciones y la atención) con la latencia y el consumo más bajos. La GPU se encarga de las operaciones que el NE no admite. La CPU se encarga del resto. La decisión se toma operación por operación, de forma automática, y es mejor que una heurística escrita a mano.

¿Debería usar siempre .computeUnits = .all?

Casi siempre. El reparto automático del framework está bien afinado. Cambia a .cpuOnly cuando pruebes la paridad de salidas (el mismo modelo devuelve resultados ligeramente distintos en el NE y en la CPU por el redondeo en coma flotante) o a .cpuAndGPU para liberar el Neural Engine y dedicarlo a una tarea concurrente.

¿Cuál es la diferencia práctica entre .mlpackage y .mlmodel?

.mlpackage es el formato moderno introducido en Xcode 13. Admite metadatos almacenados, varias variantes de modelo para la compilación como ML Program (mlprogram) y la cadena de herramientas posterior a iOS 13. .mlmodel es el formato heredado. Ambos se siguen cargando con MLModel; el desarrollo nuevo debería usar .mlpackage.

¿Cuánto puede pesar un modelo de Core ML dentro del bundle de una app?

No hay un límite fijo, pero el tamaño de los bundles de la App Store está limitado a 4 GB para la descarga y tiene límites prácticos para la instalación por aire. El LLM del sistema en el dispositivo esquiva la pregunta por completo: lo distribuye el sistema operativo y las apps lo alcanzan mediante Foundation Models sin empaquetar nada. Para modelos empaquetados en la app, menos de 100 MB resulta cómodo; entre 100 y 500 MB es viable con una estrategia de carga en el arranque; a partir de 500 MB conviene resolverlo con una descarga en segundo plano vía BGProcessingTask o con recursos bajo demanda.

¿Debería usar Core ML o Core AI para un modelo nuevo?

Por debajo de iOS 27, Core ML es la única opción. En iOS 27 y posteriores, la dirección declarada por Apple es Core AI para redes neuronales, mientras Core ML continúa para el aprendizaje automático tradicional y los despliegues existentes¹¹¹². Si tienes un modelo fijo ya convertido y los valores predeterminados del conversor te sirven, Core ML sigue publicándose sin problema; si necesitas control explícito sobre la especialización, el almacenamiento en caché o la planificación, ese control es justo lo que Core AI existe para dar.

¿Cómo sé si la cuantización dañó la precisión de mi modelo?

Reserva un conjunto de prueba, ejecuta la inferencia en el modelo Float32 original y en el cuantizado, compara métricas (precisión top-1 para clasificadores, F1 para detectores, perplejidad para modelos de lenguaje, BLEU para traducción, etc.) y decide según los requisitos de precisión de la aplicación. El entrenamiento consciente de la cuantización (entrenar el modelo con la cuantización simulada en la función de pérdida) suele recuperar la mayor parte de la precisión perdida.

Referencias