Ejecuta LLM locales en un Mac con MLX en lugar del motor llama.cpp por defecto

Si has instalado Ollama en un Mac, has descargado un modelo y has dado por hecho que ya ejecutas IA en local, es verdad. Pero lo más probable es que lo estés haciendo con el motor equivocado y estés renunciando a entre un 15 % y el triple de la velocidad de la máquina sin darte cuenta.

El camino por defecto

Casi todo el mundo sigue la misma ruta. Instala Ollama, ejecuta ollama run llama3.2 (o el modelo de moda esa semana), ve cómo fluyen los tokens y asume que ese es el techo en un Mac.

Durante mucho tiempo fue una suposición razonable. Por dentro, Ollama envuelve llama.cpp, un motor de inferencia en C/C++ que funciona prácticamente en cualquier cosa: Windows, Linux, Macs con Intel e incluso una Raspberry Pi. Es una ingeniería excelente. Simplemente no se diseñó en torno al funcionamiento de Apple Silicon.

Apple tiene su propio framework de aprendizaje automático, MLX, desde finales de 2023, y está construido alrededor de lo que distingue a los chips de la serie M: la memoria unificada. La CPU, la GPU y el Neural Engine tiran de un único bloque compartido. El backend Metal de llama.cpp tiene que sortear eso. MLX se escribió pensando en ello desde el primer día. La distancia entre «funciona en Apple Silicon» y «hecho para Apple Silicon» resulta ser mayor de lo que casi nadie imaginaba.

Cuando la propia Ollama le dio la razón

Era fácil despachar MLX como un proyecto de aficionados, algo que se mencionaba en foros de LLM locales. Eso cambió en marzo de 2026, cuando Ollama lanzó un backend MLX opcional para Apple Silicon. En la práctica, la herramienta de LLM locales más popular admitió que su motor por defecto no es la opción más rápida en el hardware que tiene la mayoría de sus usuarios de Mac. Motivo de sobra para mirar cifras reales en lugar de fiarse de la palabra de nadie.

Lo que ganas al cambiar

La diferencia varía mucho según el tamaño del modelo, la arquitectura y tu chip concreto, pero las pruebas independientes apuntan en la misma dirección:

• Modelos mixture-of-experts de tamaño medio, como los de la clase Qwen3-Coder-30B, en un Mac mini con M4 Pro: unos 130 tokens por segundo con MLX frente a 43 con el backend llama.cpp de Ollama. Eso es el triple, muy lejos de cualquier margen de error.
• Modelos densos de menos de unos 14B parámetros: MLX va entre un 20 % y un 87 % más rápido que la vía Metal de llama.cpp.
• Por encima de unos 27B parámetros: la diferencia se reduce y casi desaparece. A ese tamaño el límite es el ancho de banda de memoria, no el cómputo, así que la velocidad de la RAM pesa más que el motor.
• El tiempo hasta el primer token, esa pausa molesta antes de que empiece el streaming, también mejora con MLX, sobre todo en los chips de la generación M5 con Neural Accelerators dedicados.

Así que el resumen justo no es que MLX gane siempre. Gana por amplio margen en los tamaños de modelo que la mayoría de la gente ejecuta de verdad en local, y la ventaja se diluye a medida que los modelos se vuelven enormes.

Tres formas de probarlo

Quedarte en Ollama y cambiar el backend

Con Ollama 0.19 o posterior puedes activar el backend MLX sin abandonar tu configuración actual. Es lo que menos esfuerzo requiere y te permite comparar en tu propio hardware antes de comprometerte.

Pasarte a lo nativo con mlx-lm

Instala el paquete y genera directamente desde la línea de comandos:

pip install mlx-lm
python -m mlx_lm.generate --model mlx-community/Qwen3.5-35B-A3B-MLX-4bit --prompt "your prompt here"

Los modelos de la organización mlx-community en Hugging Face ya vienen cuantizados para esto. Es la vía para obtener la máxima velocidad, siempre que no te importe vivir un poco más cerca del terminal.

Usar LM Studio

Si Python no es una opción, LM Studio ya admite modelos MLX con un interruptor de un clic en su navegador de modelos. Es la puerta de entrada más fácil si mlx-lm te parece demasiada configuración.

Trampas al cambiar

• No es un simple cambio de modelo. MLX necesita sus propias versiones cuantizadas de los modelos (los repositorios de mlx-community), no los archivos GGUF con los que alimentabas a Ollama. Si apuntas mlx-lm a un GGUF, simplemente falla.
• El margen de RAM sigue contando. La memoria unificada es eficiente, pero en una máquina que ya va al límite, por ejemplo un Mac de la serie M con 16 GB, hay que elegir con cuidado el nivel de cuantización. Para equipos con menos de 32 GB de memoria unificada, 4 bits suele ser el mejor equilibrio.
• Un modelo de 70B no gana nada. Encaja con la convergencia por encima de unos 27B: si cargas el modelo más grande que tu Mac puede albergar técnicamente, el techo de ancho de banda es el mismo lo ejecute el motor que lo ejecute.
• No te deshagas de Ollama. Para pruebas rápidas puntuales, flujos con llamadas a herramientas y modelos de visión, su ecosistema y su biblioteca siguen siendo más cómodos. Lo sensato es dejar de usarlo por defecto para todo lo que dependa del rendimiento, no desinstalarlo.

A quién le compensa

• Macs con Intel: olvídalo. MLX necesita Apple Silicon, M1 o posterior, así que quédate con llama.cpp y Ollama.
• M1 o M2 básicos con 8 a 16 GB de RAM: espera una mejora real, aunque menor. Las ganancias crecen con el número de núcleos de GPU y el ancho de banda de memoria, así que un M1 básico no se va a sentir como un M4 Max.
• Chips Pro, Max y Ultra con modelos de unos 3B a 20B: aquí el cambio compensa de forma más evidente e inmediata.
• Quien ejecute modelos MoE de 30B o más: la categoría con mayor ganancia en los benchmarks anteriores.
• Quien use modelos densos de más de unos 27B parámetros: cambia por la pequeña mejora en el tiempo hasta el primer token, pero no cuentes con las cifras de titular.

Elige el motor según el chip

Nada de esto hace que MLX sea mejor en abstracto. Se trata de usar una herramienta en el hardware para el que se diseñó. llama.cpp es un software brillante y portable, y precisamente esa portabilidad es la razón por la que no puede ajustarse tanto a una familia de chips como un framework de la empresa que fabrica el chip.

Si te tomas en serio los modelos locales en un Mac, por privacidad, coste o control, el motor que hay debajo de tu prompt importa tanto como el modelo que hayas elegido. Hay quien pasa horas decidiendo qué modelo descargar y nunca se pregunta qué lo está ejecutando. Revisa el tuyo, porque puede que haya más rendimiento esperando del que crees.