Para ejecutar modelos de lenguaje en un Mac, añadir una capa de servicio como oMLX encima de mlx-lm no acelera las respuestas mientras el servidor sigue en marcha, pero sí evita repetir un preprocesado de más de un minuto cada vez que se reinicia. Así lo concluyen las pruebas de Michael Hannecke en un Mac Studio M4 Max de 64 GB, que Revista Cloud ha analizado en detalle y que importan a quien usa agentes de programación con modelos locales.
Las claves de mlx-lm y oMLX para la IA local en Mac en 30 segundos
- mlx-lm es el entorno de referencia de Apple para modelos de lenguaje; oMLX es una capa de servicio que se apoya en él.
- Con el contexto en memoria, ambos tardaron unos 3,5 segundos en dar el primer token.
- La generación fue prácticamente igual, con 22 y 25 tokens por segundo.
- Tras reiniciar, oMLX recuperó de su caché en SSD un contexto de 8.000 tokens en 7,2 segundos.
Los agentes de programación envían una y otra vez el mismo contexto largo: instrucciones del sistema, archivos del proyecto e historial. Procesar ese contexto, la fase de prellenado, puede ser lo que más hace esperar en local, y por eso la caché que guarda ese trabajo ya hecho, la caché de claves y valores (KV), pesa tanto en la experiencia. Hannecke esperaba que la caché por niveles de oMLX, con una parte en RAM y otra en SSD, aplastara a mlx-lm. No fue así, porque el servidor de mlx-lm ya guarda en memoria los prompts recientes.
Lo que cambia y lo que no
Las pruebas, hechas con el modelo gemma-4-31b-it en 4 bits, mlx-lm 0.31.3 y oMLX 0.4.4, dejaron empates en lo que se suele medir: unos 3,5 segundos hasta el primer token con un prefijo de 8.000 tokens ya en memoria y una velocidad de generación equivalente, porque oMLX no genera tokens por su cuenta, sino que usa el motor de mlx-lm. Con cuatro peticiones simultáneas, el servidor de mlx-lm escaló mejor en esa ejecución, algo que el autor presenta con cautela.
La diferencia apareció al reiniciar. La caché de mlx-lm desaparece con el proceso, de modo que la primera petición tras el reinicio fue cinco veces más lenta que con la caché caliente; oMLX restauró el contexto desde el SSD y respondió en 7,2 segundos, unos 10 segundos antes que mlx-lm. A cambio, su primer arranque en frío fue más lento, 64 segundos frente a 32, porque carga el modelo y prepara la caché en esa primera petición.
Cuándo elegir cada uno
Hannecke recomienda mlx-lm para una sola persona, scripts, ajustes finos o mediciones de referencia, y oMLX cuando se reinicia con frecuencia el servidor, cuando el contexto debe sobrevivir a una expulsión de memoria o cuando se sirven varios modelos en la misma máquina, además de quien prefiera gestionarlo desde la barra de menús de macOS. Según su repositorio, oMLX tiene licencia Apache 2.0, ofrece puntos de acceso compatibles con las API de OpenAI y Anthropic y requiere macOS 15 o posterior.
El autor insiste en que sus cifras salen de una sola máquina y una sola ejecución, y en que ambas herramientas cambian a menudo. También deja una lección de método: antes de comparar hay que controlar la caché de prompts de mlx-lm y la carga diferida de oMLX, y vaciar ~/.omlx/cache, porque si no se acaba midiendo la propia caché y no el motor.
Preguntas frecuentes
¿oMLX acelera la generación de texto en Mac?
No. En las pruebas de Michael Hannecke la velocidad de generación fue equivalente, porque oMLX usa el motor de mlx-lm.
¿Cuándo compensa usar oMLX?
Cuando el servidor se reinicia a menudo, cuando hay que conservar el contexto procesado o cuando se sirven varios modelos en el mismo Mac.
¿Qué ventaja tiene su caché en SSD?
Permite restaurar un contexto ya procesado tras un reinicio: en la prueba, 7,2 segundos en lugar de repetir un preprocesado de más de un minuto.
¿Qué requisitos tiene oMLX?
Según su repositorio, un Mac con Apple Silicon (M1 a M5) y macOS 15 o posterior.
Fuentes:
- Revista Cloud: mlx-lm frente a oMLX
- Michael Hannecke en Medium: «mlx-lm vs oMLX: I Was Wrong About the Winner» (23/06/2026)
- GitHub: jundot/omlx
- GitHub: ml-explore/mlx-lm
