MLX en Apple Silicon: cuando necesitas tu propio modelo y no el de Apple

El framework Foundation Models de Apple te entrega un solo modelo: el del sistema, sellado, gratuito y actualizado según el calendario de Apple. Para la mayor parte del trabajo lingüístico en el dispositivo esa es la herramienta correcta, y buscar algo más allá es un error. Pero hay trabajos que exigen un modelo elegido por ti: un LLM de pesos abiertos concreto, una versión que fijas, un ajuste fino entrenado con tus propios datos o una capacidad que el modelo del sistema no tiene. Cuando necesitas que tu propio modelo corra en el dispositivo, la capa que hay debajo de Foundation Models es MLX¹.

MLX es el framework de arreglos de Apple para machine learning sobre Apple Silicon, con una API en Swift (MLX Swift) que integras directamente en una app². No es un framework del sistema al que llamas; es una biblioteca que distribuyes junto con los pesos del modelo. Toda la contrapartida está en esa diferencia, y entenderla es lo que te permite decidir si bajas una capa o te quedas donde Apple te puso.

En resumen

• MLX es un framework de arreglos al estilo de NumPy construido para Apple Silicon, con evaluación diferida, transformaciones de funciones componibles y un backend en Metal².
• El modelo de memoria unificada es la razón de que funcione en un teléfono. Los arreglos viven en un único espacio de memoria que comparten la CPU y la GPU, así que MLX opera en ambas sobre los mismos búferes sin pagar el impuesto de copiar del host al dispositivo³.
• Ejecuta un LLM de pesos abiertos en el dispositivo con LLMModelFactory, apuntando a un modelo cuantizado como mlx-community/Llama-3.2-3B-Instruct-4bit, y genera texto a través de una ChatSession⁴.
• Ajusta el modelo con adaptadores LoRA: entrenas un adaptador pequeño, distribuyes adapters.safetensors y load(into:) intercambia en tiempo de ejecución las capas Linear del modelo base por LoRALinear⁵.
• Lo que cuesta tener tu propio modelo: tamaño de la app (los pesos son grandes), presión de memoria, cero integración con el sistema y la responsabilidad de cada actualización. Foundation Models no tiene ninguno de esos costos porque los paga Apple.

Qué es MLX y por qué Apple Silicon lo hace posible

MLX te da arreglos y operaciones que se parecen a NumPy, además de las transformaciones que exige el machine learning: diferenciación automática, vectorización y evaluación diferida que construye un grafo de cómputo y solo lo ejecuta cuando lees un resultado². El proyecto también avanza al ritmo de un framework de investigación: MLX llegó a 0.32.0 en julio de 2026 y MLX Swift a 0.31.6 esa misma semana, con una cadencia de lanzamientos de aproximadamente cada pocas semanas⁷. Fija tus versiones y da por hecho que la superficie de la API va a seguir creciendo. Dicho así, la descripción encaja con una docena de frameworks. Lo que hace que MLX ejecute un modelo de miles de millones de parámetros en un dispositivo que llevas en el bolsillo es el modelo de memoria.

En una GPU de escritorio, los datos viven en la RAM del sistema y los copias por un bus hasta la memoria separada de la GPU para calcular, y luego copias los resultados de vuelta. Esa copia es el impuesto, y con un modelo grande resulta brutal. Apple Silicon tiene memoria unificada: un único espacio que la CPU, la GPU y el Neural Engine direccionan de forma directa. MLX se construyó en torno a ese hecho³. Un arreglo no está “en la CPU” ni “en la GPU”; está en memoria, y cualquier procesador opera sobre él ahí mismo. Sin copias, sin impuesto de bus. Un modelo de 3.000 millones de parámetros cuantizado a 4 bits cabe en unos pocos gigabytes y corre sin los viajes de ida y vuelta que volverían impracticable el mismo trabajo en una máquina con GPU discreta y memoria similar. La decisión de hardware que Apple tomó hace años es la razón de que la inferencia de un modelo real en el dispositivo sea siquiera viable, y la arquitectura de memoria unificada basada en tiles es el sustrato sobre el que se apoya MLX.

Ejecutar un LLM en el dispositivo

El camino que va de “quiero un modelo concreto” hasta ver texto en pantalla es corto. La capa LLM de MLX Swift carga un modelo cuantizado desde el Hub de Hugging Face y lo ejecuta⁴:

let container = try await LLMModelFactory.shared.loadContainer(
    from: HubClient.default,
    using: TokenizersLoader(),
    configuration: .init(id: "mlx-community/Llama-3.2-3B-Instruct-4bit")
)

let session = ChatSession(container)
let response = try await session.respond(to: "Summarize this in one line: \(text)")

Si la UI muestra el texto token a token, genera un flujo y renderiza los fragmentos conforme llegan⁴:

let input = try await container.prepare(input: UserInput(prompt: prompt))
let stream = try await container.generate(input: input, parameters: GenerateParameters())
for await event in stream {
    if case let .chunk(text) = event { /* append to UI */ }
}

Dos detalles concentran casi todo el peso práctico. Primero, el 4bit del identificador del modelo no es un adorno opcional: la cuantización es lo que hace que el modelo quepa en memoria y corra a una velocidad usable en un dispositivo. Distribuyes pesos de 4 bits (o menos), no de precisión completa. Segundo, los pesos son grandes incluso cuantizados, así que decides deliberadamente si los empaquetas dentro de la app (inmediato, pero con una descarga pesada) o los traes en el primer arranque (binario ligero, pero con una espera y una ruta de error que atender). Foundation Models nunca plantea esa pregunta porque el modelo ya está en el dispositivo. Con MLX, los pesos son problema tuyo.

Ajuste fino: un adaptador LoRA, no un modelo nuevo

La razón para traer tu propio modelo rara vez es el modelo base en sí; es enseñarle tu dominio. Hacer un ajuste fino completo de un modelo de miles de millones de parámetros en el dispositivo no es el camino. LoRA (adaptación de rango bajo) sí lo es: entrenas un conjunto pequeño de pesos de adaptador que ajustan el comportamiento del modelo base sin tocarlo. El adaptador pesa megabytes, no gigabytes⁵.

MLX Swift carga un adaptador entrenado desde una carpeta que contiene adapter_config.json y adapters.safetensors, y luego lo aplica a un modelo ya cargado en un contenedor⁵:

let adapter = try LoRAContainer.from(directory: adapterURL)
await container.update { context in
    try? adapter.load(into: context.model)   // swaps Linear layers for LoRALinear
}

load(into:) sustituye las capas Linear estándar del modelo por capas LoRALinear que incorporan los deltas de rango bajo del adaptador, de modo que la inferencia ya refleja tu ajuste fino. Como el modelo vive dentro del contenedor, aplicas el adaptador a través de container.update, y puedes intercambiar adaptadores en caliente durante la ejecución (unload(from:) uno, load(into:) otro) para que un mismo modelo base se comporte de forma distinta según la función. El patrón refleja lo que Apple ofrece para el modelo del sistema mediante los adaptadores personalizados de Foundation Models: la diferencia es que aquí el modelo base, el pipeline de entrenamiento y el resultado son tuyos, en lugar de adaptar un modelo que no puedes ver.

La decisión: Foundation Models, MLX o la nube

Tres capas, y elegir mal te cuesta capacidad o una montaña de trabajo evitable.

• Foundation Models cuando el modelo del sistema puede resolver la tarea. Gratis, privado, cero pesos que distribuir, cero memoria que administrar e integración con el sistema que no te cuesta nada. Empieza aquí por defecto. Las tareas lingüísticas en el dispositivo para las que Apple lo construyó (resumir, clasificar, extraer, reescribir, salida estructurada) van aquí, punto.
• MLX cuando necesitas un modelo que el sistema no te da: un LLM de pesos abiertos concreto, una versión fijada que no se mueva bajo tus pies con una actualización del sistema operativo, un ajuste fino de dominio o una arquitectura (un modelo de visión y lenguaje, un modelo que no sea de texto) fuera del alcance de Foundation Models. Pagas en tamaño de app, memoria y responsabilidad, y compras control.
• La nube cuando el modelo tiene que ser grande de verdad: razonamiento de frontera, análisis de contexto largo, cualquier cosa que hagan los modelos más grandes y que un modelo de unos pocos miles de millones de parámetros en el dispositivo no alcanza. Ejecutar en el dispositivo no sustituye a un modelo de frontera; es otro punto de la curva.

La lectura honesta: MLX es un descenso deliberado de capa por una razón concreta, no una mejor opción por defecto. Si no puedes nombrar la capacidad que le falta a Foundation Models para tu función, no necesitas MLX, y adoptarlo significa cargar con gigabytes de pesos y un presupuesto de memoria que no tenías por qué asumir.

iOS 27 añade una cuarta capa a este mapa. Core AI es el framework del sistema de Apple para ejecutar un modelo que tú aportas, con control explícito sobre especialización, caché y planificación de unidades de cómputo. Se superpone a MLX en el nivel de “tu modelo, en el dispositivo”, pero desde el lado opuesto: Core AI es una superficie de ejecución administrada por el sistema para un .aimodel ya preparado, mientras que MLX es una biblioteca que integras con tu propio bucle de entrenamiento, tu cuantización y tu iteración dentro. Si lo que necesitas es ejecutar rápido un modelo convertido bajo administración del sistema, Core AI compite por el puesto; si lo que necesitas es experimentar, hacer ajuste fino o ser dueño del pipeline completo, MLX sigue siendo la herramienta.⁶

Cuándo no recurrir a MLX

• El modelo del sistema ya lo hace. Vuelve a leer las tareas de Foundation Models. Si la tuya está en la lista, para aquí.
• No puedes permitirte los pesos. Un modelo pequeño cuantizado sigue siendo un recurso grande. Si el tamaño de la app o la descarga del primer arranque son una restricción real para tus usuarios, esa restricción puede resolver la cuestión por sí sola.
• Necesitas la ruta de menor consumo del Neural Engine para un modelo fijo. Para un modelo conocido, ya distribuido y que no cambia, Core ML y su conversor apuntan al Neural Engine con el consumo y la latencia más ajustados, y en iOS 27 Core AI es la dirección declarada de Apple para el trabajo nuevo con redes neuronales, con control explícito de especialización. MLX brilla por su flexibilidad y por permitir iteración con calidad de investigación; los frameworks del sistema brillan con un modelo de producción cerrado. Son herramientas distintas, y “ML en el dispositivo” no es una sola decisión.
• No vas a mantenerlo. Tener tu propio modelo significa hacerte cargo de sus actualizaciones, su seguridad y su deriva. Apple actualiza el modelo del sistema por ti. Si no tienes gente para hacerte cargo de un modelo, no lo adoptes.

La destreza que MLX premia es la contención: saber cuándo usarlo. El framework es genuinamente notable: un modelo de lenguaje real, ajustado a tu dominio, corriendo por completo en el dispositivo sin servidor y sin costo por token, sobre un hardware cuya arquitectura de memoria se construyó exactamente para esto. Vale la pena recurrir a esa capacidad cuando has nombrado la razón. Recurre a ella sin razón y habrás cambiado el modelo gratuito, mantenido e integrado de Apple por una copia más pesada, sin mantenimiento y que ahora es tuya. El criterio es todo el trabajo.

Preguntas frecuentes

¿Qué es el framework MLX de Apple?

MLX es un framework de arreglos para machine learning sobre Apple Silicon, con una API al estilo de NumPy, transformaciones de funciones componibles (diferenciación automática, vectorización), cómputo diferido y un backend en Metal². MLX Swift es la API en Swift para integrarlo en apps, de modo que puedas ejecutar y ajustar tus propios modelos en el dispositivo.

¿Cómo usa MLX la memoria unificada de Apple Silicon?

Los arreglos de MLX viven en memoria compartida, así que las operaciones corren en la CPU o en la GPU sin copiar datos entre espacios de memoria separados³. Esa propiedad de transferencia cero es justo lo que hace eficiente la arquitectura de memoria unificada de Apple Silicon para ejecutar modelos en el dispositivo.

¿Puedo ejecutar un LLM de pesos abiertos en el dispositivo con MLX?

Sí. LLMModelFactory.shared.loadContainer(from:using:configuration:) carga un modelo cuantizado como mlx-community/Llama-3.2-3B-Instruct-4bit desde el Hub de Hugging Face; ChatSession te da respond(to:) para llamadas sueltas, y container.generate(input:parameters:) emite eventos .chunk(text) en flujo para salida incremental⁴.

¿Cómo hago un ajuste fino de un modelo con MLX?

Con un adaptador LoRA, no con un modelo nuevo. LoRAContainer.from(directory:) carga un adaptador desde una carpeta que contiene adapter_config.json y adapters.safetensors; aplicado a través de container.update, sustituye las capas Linear del modelo por capas LoRALinear y permite intercambiar adaptadores en caliente durante la ejecución⁵.

MLX, Foundation Models o Core ML: ¿cuál conviene usar?

Usa Foundation Models por defecto cuando el modelo del sistema de Apple pueda resolver la tarea (gratis, privado, cero pesos que distribuir)¹. Recurre a MLX solo cuando necesites un modelo que el sistema no te da: un LLM de pesos abiertos concreto, una versión fijada, un ajuste fino de dominio o una arquitectura fuera del alcance de Foundation Models. Usa Core ML para un modelo de producción cerrado que necesita la ruta de menor consumo del Neural Engine; Core AI en iOS 27 cuando quieras ejecución administrada por el sistema de tu propio modelo con control explícito de especialización y planificación; y la nube cuando el modelo tenga que ser realmente de escala frontera.

¿Cuándo no debería recurrir a MLX?

Cuando el modelo del sistema ya lo hace, cuando no puedes permitirte distribuir gigabytes de pesos, cuando un modelo fijo se resuelve mejor con la ruta de menor consumo del Neural Engine vía Core ML, o cuando no tienes gente para hacerte cargo de las actualizaciones, la seguridad y la deriva de un modelo. MLX es un descenso deliberado de capa por una razón concreta, no una mejor opción por defecto.