Core ML vs MLX vs Foundation Models: cómo elegir el stack de IA en el dispositivo de Apple

Apple ya ofrece cuatro maneras distintas de ejecutar un modelo en el hardware de tus usuarios, y equivocarte al elegir cuesta una reescritura. En la M2 Max desde la que escribo esto, MLX sostiene 11.2 TFLOPS de cálculo matricial fp16 y mueve datos a 351 GB/s de ancho de banda medido en memoria unificada¹. Para la mayoría de las apps esa potencia es la elección equivocada, porque el framework integrado Foundation Models hace el trabajo en seis líneas de Swift y sin sumar un solo megabyte a la descarga. Los cuatro frameworks no son competidores. Son cuatro respuestas distintas a una sola pregunta: ¿de quién es el modelo y quién se encarga de la ejecución?

TL;DR

• Foundation Models es la opción por defecto. Si el LLM en el dispositivo de Apple, un generalista de ~3B parámetros, puede resolver la tarea (resumir, extraer, clasificar, generar salida estructurada, llamar a tus herramientas), no envías ningún peso de modelo, no pagas costo de inferencia y heredas gratis cada mejora del modelo que llega con el sistema operativo.²
• Core ML sirve para enviar tu modelo entrenado dentro de una app. Es la única vía con despacho de primer nivel al Neural Engine, empaquetado compatible con la App Store y un contrato de compilación anticipada que cambia flexibilidad por duración de batería y previsibilidad.³
• MLX entra cuando el modelo es el producto: investigación, fine-tuning, ejecución de LLM de pesos abiertos o cualquier carga de trabajo donde necesitas control directo sobre los tensores. Es una herramienta para tu máquina de desarrollo y para apps de Mac, no un vehículo de distribución en iOS.⁴
• Core AI (iOS 27) es el nuevo piso debajo de todo esto: un framework de ejecución de modelos de bajo nivel con tensores NDArray y selección explícita de unidades de cómputo, pensado para equipos que hoy fuerzan a Core ML a comportarse como un runtime de tensores.
• La decisión suele resolverse con una pregunta: modelo integrado → Foundation Models; tu modelo en iOS → Core ML; tu modelo en tu Mac → MLX; control a nivel de tensores en iOS → Core AI. El resto de este artículo trata el 20 % de los casos en los que esa heurística se rompe.

La pregunta detrás de la pregunta

Cada debate sobre «qué framework usar» que he visto termina reduciéndose a dos ejes. (He escrito un análisis a fondo de cada uno: Foundation Models, Core ML, MLX, Core AI.)

Primer eje: ¿de quién son los pesos? El modelo integrado de Apple, un modelo que entrenaste o convertiste, o pesos abiertos que bajaste de un hub. Foundation Models solo ejecuta el modelo de Apple (más tus adaptadores estilo LoRA).⁵ Core ML y MLX solo ejecutan los pesos que tú proporcionas. Ese único hecho elimina la mitad del espacio de opciones antes de que el rendimiento entre siquiera en la conversación.

Segundo eje: ¿quién es dueño de la ejecución? Foundation Models lo esconde todo: nada de tensores, nada de unidades de cómputo, ninguna gestión de la ventana de contexto más allá de un objeto de sesión. Core ML esconde casi todo: le entregas un .mlmodelc compilado y sugieres unidades de cómputo; el framework decide el despacho. MLX no esconde nada: escribes tú la aritmética de arrays, y la evaluación diferida junto con la memoria unificada son tus herramientas. Core AI se ubica entre Core ML y MLX: tensores explícitos y selección de unidades de cómputo, pero con ejecución administrada por Apple.

Ubica cualquier función real sobre esos dos ejes y el framework se elige solo.

Foundation Models: la opción por defecto de cero megabytes

El framework que la mayoría de los equipos debería probar primero es el que no requiere modelo alguno. Foundation Models expone el LLM en el dispositivo que hay detrás de Apple Intelligence a través de LanguageModelSession, y su función estrella no es el modelo. Es la generación guiada: anotas una struct de Swift con @Generable y el framework restringe la decodificación para que la salida del modelo sea tu tipo, en lugar de una cadena que analizas y rezas para que salga bien.²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

Esa es toda la integración. Sin paso de descarga, sin decisiones de cuantización, sin comportamiento térmico que anticipar; el sistema operativo planifica el modelo, lo comparte entre todas las apps del dispositivo y lo actualiza con cada versión. La llamada a herramientas permite que el modelo invoque funciones que tú defines, lo que basta para construir funciones genuinamente agénticas sin ningún servidor.²

La restricción es simétrica: el modelo es un generalista de ~3B parámetros. Resume, extrae, clasifica y produce bien salida estructurada; no hace conocimiento del mundo en dominio abierto, ni análisis documental de contexto largo, ni nada de lo que hace un modelo de frontera. Cuando el modelo integrado no alcanza, la respuesta de Apple son los adaptadores (fine-tunes estilo LoRA que entrenas con el toolkit de Apple sobre el modelo base), pero un adaptador es un compromiso: lo reentrenas cada vez que Apple actualiza el modelo base.⁵ Mi desarme completo, incluida la gestión de sesiones y los modos de falla con los que se topan los revisores, está en el análisis a fondo de Foundation Models.

Elígelo cuando: la tarea tenga forma de lenguaje, el modelo integrado supere tu listón de calidad y enviar cero pesos importe. Eso abarca más funciones de las que la mayoría de los equipos supone; pruébalo antes de recurrir a cualquier cosa de las siguientes.

Core ML: tu modelo, la ejecución de Apple

Core ML responde a otra pregunta. Ya tienes un modelo (un clasificador de visión, un modelo de embeddings, un pipeline de voz, un LLM destilado) y necesita correr dentro de una app iOS, con batería, dentro de los límites de tamaño de la App Store, este año.

El contrato es de compilación anticipada. Conviertes los pesos con coremltools, el modelo se compila a .mlmodelc y, en tiempo de ejecución, el framework despacha entre Neural Engine, GPU y CPU; el ANE es la parte que hoy nada más de esta lista te da en iOS. El paso de conversión es donde vive la ingeniería de verdad: cobertura de operadores, cuantización (paletización, lineal de 8/4 bits, sparsity; el stack de optimización de coremltools es realmente profundo⁶) y las sugerencias de unidad de cómputo que deciden si tu modelo corre a 2 vatios o a 8. Los patrones que de verdad sobreviven a producción (sugerencias de despacho, presupuestos de latencia, la escalera de cuantización) son el tema de el pilar sobre Core ML.

Lo que Core ML no hace también sostiene la decisión: no entrena, no hace fine-tuning y no te da tensores a mitad del grafo. Es un electrodoméstico de inferencia. Los equipos que necesitan «correr mi grafo Y hurgar en los resultados intermedios» han retorcido históricamente Core ML hasta convertirlo en un runtime de tensores; esa contorsión es exactamente lo que Core AI existe ahora para absorber.

Elígelo cuando: los pesos sean tuyos, el objetivo sea iOS/iPadOS (o multiplataforma dentro de Apple) y batería, tamaño o ANE importen. Es decir: casi todas las funciones con modelo propio que se han enviado en la plataforma.

MLX: la máquina de investigación dentro de tu Mac

MLX es el raro del grupo: un framework de arrays de código abierto del grupo de investigación en ML de Apple, no un framework del sistema operativo.⁴ Se parece a NumPy, evalúa de forma diferida y trata la memoria unificada de Apple silicon como la función que es: sin copias de host a dispositivo, porque no existe una memoria de dispositivo separada.

Las cifras de esta máquina vuelven concreto el argumento. Una M2 Max sostiene 11.2 TFLOPS de matmul fp16 en 4096×4096 y 351 GB/s de ancho de banda de streaming medido bajo MLX sin ningún ajuste¹: suficiente para ejecutar de forma interactiva modelos de pesos abiertos cuantizados de 30B parámetros, hacer fine-tuning de modelos de 7B con LoRA de un día para otro e iterar sobre entrenamientos que de otro modo implicarían alquilar GPU en la nube. Gracias al ecosistema mlx-lm, la mayoría de los modelos abiertos están a un pip install y una descarga de distancia.

Los límites son igual de concretos. Sin Neural Engine: MLX programa la GPU (y la CPU), no el ANE. Sin historia de distribución en iOS: técnicamente puedes empotrarlo, pero la distribución de pesos, la disipación térmica y las guías de revisión lo convierten en la herramienta equivocada; MLX es para tu Mac, las Mac de tus usuarios y tu ciclo de investigación. Y nadie administra la ejecución por ti: la presión de memoria, las decisiones de cuantización y la planificación de las evaluaciones son cosa tuya. El pilar sobre MLX cubre cuándo «mi propio modelo, no el de Apple» vale esa responsabilidad.

Elígelo cuando: estés entrenando o haciendo fine-tuning, ejecutando LLM de pesos abiertos en local o construyendo herramientas nativas de Mac donde el control del modelo es el producto. Si tu máquina diaria es una Mac con Apple silicon y RAM de verdad, MLX la convierte en una estación de trabajo de ML legítima.

Core AI: el nuevo piso

iOS 27 añadió la capa que a Apple le faltaba: Core AI, un framework de ejecución de modelos de bajo nivel con tensores NDArray, una separación entre asset y modelo, selección explícita de unidades de cómputo y funciones de inferencia invocables.⁷ Es lo que usas cuando el contrato de Core ML, «dame un modelo compilado y recibe predicciones», resulta demasiado rígido: pipelines que entrelazan aritmética de tensores con llamadas al modelo, pre y posprocesado propio que corresponde al ANE, grafos multimodelo con búferes compartidos.

Dos aclaraciones le ahorran a casi todo lector un giro equivocado. Core AI no es una alternativa a Foundation Models (en esta capa sigue sin haber un LLM integrado; tú traes los assets compilados). Y no es MLX en iOS: sin entrenamiento, sin autograd, sin ciclo eager de investigación. Es la sala de máquinas de Core ML con la escotilla abierta. Si nunca has peleado con la abstracción de Core ML, no necesitas Core AI; en el momento en que hayas enviado acrobacias con MLMultiArray o encadenado modelos a través de conversiones innecesarias, ya lo necesitas. El modelo de tensores y la API de selección se cubren en el pilar sobre Core AI.

Los casos que de verdad se discuten

«Necesitamos un LLM, pero el nuestro, o uno más grande.» Foundation Models no puede cargar pesos externos, punto. Un LLM pequeño destilado a través de Core ML funciona y te da el ANE; un modelo abierto cuantizado a través de MLX funciona en Mac. Sé honesto sobre la alternativa que nadie del bando del dispositivo quiere decir en voz alta: si la tarea exige calidad de frontera, la respuesta es una llamada al servidor, y las capas locales se encargan del respaldo y de los subconjuntos sensibles a la privacidad.

«Queremos un solo stack para iPhone y Mac.» Foundation Models y Core ML son multiplataforma dentro del ecosistema de Apple; MLX en la práctica es solo para Mac. Los equipos que envían una app profesional de Mac más un acompañante para iOS suelen quedarse con MLX en Mac (modelos grandes, pesos aportados por el usuario) y Core ML o Foundation Models en iOS: la misma función, dos motores y una admisión honesta de que los dispositivos son distintos.

«Ya tenemos un pipeline de Core ML; ¿es Core AI un destino de migración?» Solo donde el pipeline duele. Core AI absorbe los bordes con forma de tensor; el núcleo de modelo compilado que hoy funciona sigue funcionando. Migrar en bloque un despliegue sano de Core ML no compra nada.

«¿SwiftData o App Intents cambian algo de esto?» Son adyacentes, no se superponen: tu capa de modelos alimenta funciones que App Intents expone al sistema, y todo lo que persistas obedece las reglas de esquema de SwiftData. Los frameworks de este artículo deciden cómo corre la inferencia, no cómo se construye la app que la rodea.

Un árbol de decisión

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

Conclusiones clave

Para equipos de apps que envían funciones: - Prototipa primero contra Foundation Models; seis líneas de Swift son el experimento más barato posible, y «el modelo integrado alcanza» es la sorpresa más frecuente. - Presupuesta el tiempo de conversión a Core ML por separado del tiempo de inferencia; la cobertura de operadores y la cuantización son donde se van las semanas.

Para ingenieros de ML: - Una Mac con Apple silicon y 64GB+ es un banco de fine-tuning real bajo MLX; mide antes de alquilar GPU en la nube. Las cifras de 11.2 TFLOPS / 351 GB/s de arriba salieron de un chip de portátil de hace dos generaciones.¹ - El ANE sigue siendo la ventaja defendible de Core ML, y ahora de Core AI. Si el consumo de batería por inferencia importa, ninguna ruta por GPU compite.

Para arquitectos: - Trata los cuatro frameworks como capas, no como rivales: Foundation Models para funciones de lenguaje, Core ML para modelos propios que se envían, Core AI para los bordes de tensores, MLX para el Mac y el laboratorio. Los despliegues mixtos son la norma en apps serias, no una señal de alarma. - La propiedad del modelo es el centro de costos a largo plazo: Apple mantiene los pesos de Foundation Models, tú mantienes los de todo lo demás. Mete eso en el precio de la decisión.

Preguntas frecuentes

¿Qué framework de Apple debería usar para ejecutar un modelo en el dispositivo?

La decisión suele resolverse con una pregunta. Modelo integrado: usa Foundation Models; tu modelo en iOS: usa Core ML; tu modelo en tu Mac: usa MLX; control a nivel de tensores en iOS: usa Core AI. Ubica la función sobre dos ejes, de quién son los pesos que ejecuta y quién es dueño de la ejecución, y el framework se elige solo. Trata los cuatro como capas, no como rivales; los despliegues mixtos son la norma en apps serias.

¿Puede Foundation Models ejecutar mis propios pesos de modelo?

No. Foundation Models solo ejecuta el modelo integrado de Apple en el dispositivo, un generalista de aproximadamente 3B parámetros, más tus adaptadores estilo LoRA. No puede cargar pesos externos, punto. Si necesitas tu propio LLM, un modelo pequeño destilado a través de Core ML funciona y te da el Neural Engine, y un modelo abierto cuantizado a través de MLX funciona en la Mac. Si la tarea exige calidad de frontera, la respuesta es una llamada al servidor.⁵

¿Puedo enviar MLX dentro de una app iOS?

No de forma realista. MLX es un framework de arrays de código abierto del grupo de investigación en ML de Apple más que un framework del sistema operativo, programa la GPU y la CPU sin ningún acceso al Neural Engine, y la distribución de pesos, la disipación térmica y las guías de revisión lo convierten en la herramienta equivocada para un bundle de iOS. MLX es para tu Mac, las Mac de tus usuarios y tu ciclo de investigación.⁴

¿Cuál es la diferencia entre Core ML y Core AI?

Core ML es inferencia de compilación anticipada: le entregas un .mlmodelc compilado, sugieres unidades de cómputo y el framework decide el despacho. Core AI, añadido en iOS 27, es esa misma sala de máquinas con la escotilla abierta: tensores NDArray, separación entre asset y modelo y selección explícita de unidades de cómputo. Sigue sin hacer entrenamiento y sin traer un LLM integrado. Si nunca has peleado con la abstracción de Core ML, no lo necesitas.⁷

¿Qué tan rápida es una M2 Max para machine learning local?

En la M2 Max desde la que escribo esto, MLX sostiene 11.2 TFLOPS de matmul fp16 en 4096×4096 y 351 GB/s de ancho de banda de streaming medido, sin ningún ajuste. Eso alcanza para ejecutar de forma interactiva modelos de pesos abiertos cuantizados de 30B parámetros y hacer fine-tuning de modelos de 7B con LoRA de un día para otro. Mide antes de alquilar GPU en la nube; esas cifras salieron de un chip de portátil de hace dos generaciones.¹

Referencias