Cómo instalar MLX en un Mac con mlx-lm, y qué manda por su cuenta

Instala mlx-lm con pip en un Python 3.11 o posterior nativo, en un Mac con Apple Silicon, y lanza mlx_lm.chat: la primera vez descarga de Hugging Face un modelo de 1,7 GiB y te deja escribiendo. Esa es toda la instalación, 2 pasos. De los 5 programas que comparamos, MLX es el único que no guarda tus chats en ninguna parte y no hace ni una sola llamada por su cuenta en todo un día. Su servidor es otra historia: de fábrica, cualquier web que abras puede usarlo.

Y el paquete acaba de despertar. pip install mlx-lm te da la 0.32.0, publicada el 1 de octubre de 2026 tras más de 5 meses sin versión nueva, y el framework mlx que va por debajo está en la 0.32.3, del 29 de septiembre de 2026. Las dos versiones se confirmaron en PyPI el 1 de octubre de 2026, y cada comando y cada valor de fábrica de esta página se comprobó ese mismo día contra el código de la 0.32.0.

Qué es MLX y qué añade mlx-lm

MLX es el framework de cálculo con arrays de Apple para Apple Silicon, la capa de matemáticas de la misma familia que NumPy o PyTorch, publicado por Apple con licencia MIT. Aprovecha la memoria unificada del Mac: CPU y GPU trabajan sobre el mismo banco de memoria, sin copias entre ellas. Por sí solo no conversa con nadie. mlx-lm es el paquete que va encima: trae modelos de lenguaje de Hugging Face, genera texto, sirve una API y convierte modelos. Cuando alguien dice que ejecuta un modelo «en MLX», el programa que está corriendo es mlx-lm, y es él quien te instala MLX.

Lo que no es, porque cada una de estas cosas se da por hecha:

• No es el Neural Engine. Los tipos de dispositivo del código de MLX son exactamente 2, CPU y GPU. El Neural Engine de tu chip se queda parado.
• No ejecuta GGUF. Ejecuta ficheros en formato MLX y safetensors de Hugging Face. Un GGUF que ya tengas no se puede cargar, y mlx_lm.convert parte de los pesos originales de Hugging Face, no de un GGUF.
• No es una aplicación. No hay ventana: mlx-lm instala herramientas de línea de comandos y una biblioteca de Python. Si quieres modelos MLX con ventana, LM Studio los ejecuta con su propio motor MLX, y Cómo instalar LM Studio y su servidor local, y qué manda por su cuenta cuenta ese camino.

Qué necesitas: Apple Silicon, macOS 14 y Python 3.11

Requisito	Qué significa en la práctica
Apple Silicon	Los Mac con Intel se quedan fuera: todas las compilaciones para macOS de mlx 0.32.3 en PyPI son arm64, y no hay ninguna x86_64
macOS 14.0 o posterior	macOS 15 o posterior para la parte de mlx-lm que acelera los modelos grandes fijando su memoria (lo cuenta el apartado de la memoria)
Un Python 3.11 o posterior nativo	mlx-lm 0.32.0 declara Python 3.11; mlx, por sí solo, aceptaría la 3.10. Con un 3.10, pip no da error: instala sin avisar la vieja 0.31.3, la última que lo acepta

Requisitos de la guía de instalación de MLX en su versión 0.32.2, leída el 27 de septiembre de 2026, y de los metadatos y compilaciones de PyPI de mlx 0.32.3 y mlx-lm 0.32.0, leídos el 1 de octubre de 2026.

Un Python que corre bajo Rosetta no instala nada: pip responde que no encuentra ninguna distribución que encaje. La propia guía de MLX da la comprobación:

python -c "import platform; print(platform.processor())"

Tiene que imprimir arm. Si en un Mac con chip de la serie M imprime i386, ese Python no es nativo.

¿MLX en Windows o Linux? El framework mlx publica compilaciones para los dos: Windows x64 y ARM64 desde julio de 2026, y Linux con backend CUDA (pip install "mlx[cuda12]", arquitectura NVIDIA SM 7.5 o posterior) o solo con CPU (pip install "mlx[cpu]"). mlx-lm es otra cosa. Declara su dependencia de mlx solo para macOS, así que un pip install mlx-lm a secas en Windows o Linux instala las herramientas sin el motor. En Linux, mlx-lm 0.32.0 ofrece los extras cuda12, cuda13 y cpu, que traen la compilación de mlx que corresponde. Instalamos el de cpu en una máquina Linux x86_64 el 1 de octubre de 2026, y su servidor arranca y contesta; qué tal corre ahí un modelo, eso no lo hemos medido. La documentación de ninguno de los dos paquetes menciona Windows.

Cómo instalar mlx-lm y comprobar qué versión tienes

Un entorno virtual lo mantiene aparte de cualquier otro Python que haya en el Mac:

python3 -m venv ~/mlx-env
source ~/mlx-env/bin/activate
pip install mlx-lm

El python3 de la primera línea tiene que ser el 3.11 o posterior nativo del apartado anterior. Con conda, la línea es conda install -c conda-forge mlx-lm, aunque el 1 de octubre de 2026 conda-forge seguía sirviendo la 0.31.3.

Esa sola instalación trae mlx-lm 0.32.0, mlx 0.32.3 (la 0.32.0 pide mlx 0.32.2 o posterior, así que pip coge la última) y transformers 5.7 o posterior para los tokenizadores. También te deja 18 comandos en el PATH, todos empiezan por mlx_lm: los que usa esta página son mlx_lm.chat, mlx_lm.generate, mlx_lm.server, mlx_lm.manage y mlx_lm.convert. Cada uno lista sus opciones con -h.

Para ver qué tienes:

pip show mlx mlx-lm
python -c "import mlx.core as mx; print(mx.__version__)"
mlx_lm --version

El primero enseña los dos paquetes; el segundo, solo el framework, y el tercero, solo mlx-lm. El 1 de octubre de 2026 las respuestas son 0.32.3 para mlx y 0.32.0 para mlx-lm. Si mlx-lm te dice 0.31.3, mira tu Python: con un 3.10, pip no pasa de ahí.

0.32.0, el final de un silencio largo. mlx-lm publicó 19 versiones entre el 25 de agosto de 2025 y el 22 de abril de 2026, la última la 0.31.3, y después nada durante más de 5 meses. El repositorio no se paró: entre el 22 de abril y el 30 de septiembre de 2026 sumó 134 commits en 50 días distintos, y todo ese tiempo pip siguió repartiendo el código de abril. La 0.32.0, publicada el 1 de octubre de 2026, mete ese trabajo en el paquete: la carpeta de definiciones de modelos pasa de 119 a 135 ficheros, con 16 nuevos como mistral4, kimi_k3 u olmo_hybrid, y ninguno quitado. Si instalaste durante la espera, te pones al día con una línea: pip install -U mlx-lm, y después pip show mlx mlx-lm tiene que decir 0.32.3 para mlx y 0.32.0 para mlx-lm.

Tu primer modelo: mlx_lm.chat y mlx_lm.generate

mlx_lm.chat

Sin --model, tanto mlx_lm.chat como mlx_lm.generate usan mlx-community/Llama-3.2-3B-Instruct-4bit, cuyos ficheros pesan 1,70 GiB en Hugging Face. La primera vez lo descarga; a partir de ahí lo carga del disco. En el chat, q sale, r reinicia la conversación y h enseña esos comandos. La conversación vive en la memoria mientras el chat está abierto y no se escribe en ninguna parte: sales y desaparece.

Para elegir el modelo, dale su nombre de Hugging Face o una carpeta local. La organización mlx-community de Hugging Face tiene los que ya vienen convertidos:

mlx_lm.chat --model mlx-community/Qwen3-8B-4bit
mlx_lm.generate --model mlx-community/Qwen3-8B-4bit --prompt "How tall is Mt Everest?" --max-tokens 300

Ojo con --max-tokens: de fábrica, una respuesta se corta a los 100 tokens en mlx_lm.generate, a los 256 en mlx_lm.chat y a los 512 en el servidor. Después de la respuesta, mlx_lm.generate imprime sus cifras: Prompt: N tokens, X tokens-per-sec, Generation: N tokens, X tokens-per-sec y Peak memory: X GB. Esa última línea es la prueba más honrada que tienes de que el modelo cabe: lo que el modelo y la conversación han ocupado de verdad en tu máquina. Desde la 0.32.0, mlx_lm.chat te da lo mismo después de cada respuesta, en una línea que termina en peak X GB.

Qué modelo cabe en tu Mac y cómo usa MLX la memoria

La memoria unificada se comparte con macOS y con todo lo que tengas abierto. Nuestras fichas de equipo apartan 3 GiB para eso y comparan el resto con los 19 modelos que medimos, en Q4_K_M, nuestro suelo de calidad, con un contexto de 8.192 tokens:

Mac	Queda para el modelo	Modelos que caben	El mayor que cabe
Mac con M4 y 16 GB unificados	13,00 GiB	8 de 19	gpt-oss-20b
Mac mini con M6 y 32 GB unificados	29,00 GiB	15 de 19	qwen3.6-35b-a3b
Mac con M4 Max y 64 GB	61,00 GiB	16 de 19	gpt-oss-120b

Cifras que servía cada ficha de equipo el 27 de septiembre de 2026, con el dato de equipos del 23 de septiembre. El buscador de modelos hace la misma cuenta para tu propia máquina, tu contexto y tu idioma, en tu navegador.

Esos tamaños son de ficheros GGUF. Un MLX de 4 bits es otro fichero, con otra compresión, así que comparamos los 3 que coinciden con lo que admite el Mac de 16 GB. En Hugging Face, el 27 de septiembre de 2026, mlx-community/Qwen3-4B-Instruct-2507-4bit pesaba 2,11 GiB frente a 2,33 GiB en Q4_K_M; mlx-community/Qwen3-8B-4bit, 4,29 GiB frente a 4,68, y mlx-community/gpt-oss-20b-MXFP4-Q4, 10,41 GiB frente a 10,83. En memoria, el veredicto del buscador queda del lado seguro en los 3. En calidad no dice nada: MLX de 4 bits y Q4_K_M no son la misma compresión.

Qué hace MLX con la memoria. mlx_lm.generate y mlx_lm.server le preguntan a macOS cuánta memoria recomienda para la GPU y fijan hasta esa cantidad: es la forma que tiene mlx-lm de mantener rápido un modelo grande. Cuando un modelo ocupa más del 90 % de esa recomendación, mlx_lm.generate te avisa: [WARNING] Generating with a model that requires … MB which is close to the maximum recommended size of … MB. This can be slow. El remedio que documenta mlx-lm necesita macOS 15 o posterior:

sudo sysctl iogpu.wired_limit_mb=N

N tiene que ser mayor que el modelo en megabytes y menor que la memoria del Mac. Para conversaciones largas, --max-kv-size pone techo a la memoria que ocupa el contexto con una caché rotatoria: 512 gasta muy poco y responde peor; 4.096 o más gasta más y responde mejor. Y la 0.32.0 lleva a mlx_lm.generate y mlx_lm.chat la opción --prefill-step-size, que el servidor ya tenía: un prompt largo se lee en tramos de 2.048 tokens de fábrica, y un tramo más pequeño baja el pico mientras se lee, a cambio de leerlo más despacio.

Cómo arrancar mlx_lm.server, el servidor compatible con OpenAI en el puerto 8080

mlx_lm.server --model mlx-community/Qwen3-8B-4bit

Escucha en 127.0.0.1:8080; --host y --port lo cambian. Responde a POST /v1/chat/completions y POST /v1/completions, además de GET /v1/models y GET /health. 2 comprobaciones:

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/v1/models

La primera contesta {"status": "ok"}; desde la 0.32.0, si se ha caído el hilo que genera el texto, contesta {"status": "unavailable"} con un 503. La segunda lista todos los modelos de tu caché de Hugging Face que tienen los ficheros que busca mlx-lm, no solo el cargado: también sale un original que bajaste para convertir. Para un cliente de OpenAI, la URL base es http://127.0.0.1:8080/v1; el servidor no comprueba ninguna clave, así que vale cualquier texto. Salvo que el cliente los fije, las respuestas usan temperatura 0,0 y 512 tokens como máximo.

El campo model es una orden. Si una petición nombra otro modelo, el servidor saca de la memoria el actual y carga ese, y antes lo descarga de Hugging Face si no está en tu caché. En memoria hay un solo modelo cada vez. Hasta la 0.31.3 había además una trampa: si la configuración del modelo nombraba un fichero Python propio, mlx-lm lo ejecutaba al cargarlo, sin preguntar. La 0.32.0 se niega salvo que el servidor arranque con --trust-remote-code; lo probamos con un modelo de prueba, y la 0.31.3 ejecutó el fichero mientras la 0.32.0 se paró con un error.

Lo que dejan abierto los valores de fábrica. No hay autenticación de ninguna clase, y el CORS está abierto a cualquier origen, cualquier método y cualquier cabecera. La dirección deja fuera a los demás equipos; el CORS deja entrar a cualquier página web que abras en tu navegador, y esa página puede leer las respuestas y, a través del campo model, hacer que tu Mac descargue un modelo. La documentación de mlx-lm no se anda con rodeos sobre el servidor: The MLX LM server is not recommended for production as it only implements basic security checks. O sea, no lo recomiendan para producción porque solo hace comprobaciones de seguridad básicas. El servidor imprime esa misma advertencia cada vez que arranca. Está construido sobre el servidor HTTP de la biblioteca estándar de Python. Lo que cierra casi todo:

• Deja --host en 127.0.0.1.
• Di qué páginas pueden usarlo: --allowed-origins http://localhost:3000, una lista separada por comas, en vez del * de fábrica.
• Si otro equipo lo necesita, llega a él por un túnel SSH (ssh -L 8080:127.0.0.1:8080 tu-usuario@tu-mac) en lugar de usar --host 0.0.0.0.

Dónde guarda MLX los modelos y cómo borrarlos

Qué	Dónde
Modelos descargados	La caché de Hugging Face: ~/.cache/huggingface/hub, se cambia de sitio con HF_HOME o HF_HUB_CACHE
Modelos que conviertes tú	./mlx_model en la carpeta desde la que lanzaste el comando, salvo que pases --mlx-path
Chats	En ninguna parte. No se escribe nada
Texto de calibración para cuantizar con AWQ, GPTQ o la cuantización dinámica	~/.cache/mlx-lm/, que solo se crea si usas esos métodos

Rutas de la documentación de mlx-lm y de su código, y de la documentación de Hugging Face sobre sus variables de caché, leídas el 27 de septiembre de 2026; las de mlx-lm, comprobadas de nuevo contra el código de la 0.32.0 el 1 de octubre de 2026.

La caché es de Hugging Face, no de MLX, así que la comparten las demás herramientas de Hugging Face que tengas en el Mac. mlx-lm la gestiona con un solo comando:

mlx_lm.manage --scan
mlx_lm.manage --delete --pattern mlx-community/Qwen3-8B-4bit

--scan solo lista los repositorios cuyo nombre contiene mlx, salvo que le des otro --pattern, así que un modelo que cargaste directamente desde su repositorio original no aparece en el escaneo a secas.

Convertir y cuantizar un modelo con mlx_lm.convert

Cuando el modelo que quieres no está en mlx-community, conviértelo tú:

mlx_lm.convert --model Qwen/Qwen3-8B -q

-q a secas significa 4 bits en grupos de 64, en modo affine. --q-bits 8 cambia los bits; --q-mode acepta además mxfp4, nvfp4 y mxfp8; --quant-predicate acepta 4 recetas de bits mixtos, de mixed_2_6 a mixed_4_6. El resultado va a ./mlx_model, y el comando se niega a funcionar si esa carpeta ya existe.

Haz la cuenta de la descarga antes de empezar. La conversión parte de los pesos originales: Qwen3-8B tiene 8.200 millones de parámetros en BF16, unos 15,3 GiB que bajar para un resultado de unos 4,3 GiB. --upload-repo publicaría el modelo convertido en tu cuenta de Hugging Face; sin esa opción, no sale nada.

Qué manda MLX por su cuenta y qué sale cuando lo pides

Por su cuenta, nada. La ficha MLX (mlx-lm): qué manda a casa y si lo puedes auditar cuenta 0 llamadas en un día en reposo: ni comprobación de actualizaciones, ni cuenta, ni telemetría propia. El 25 de agosto de 2026 barrimos el paquete mlx_lm entero, tanto la rama principal como la 0.31.3 publicada, buscando código de telemetría y de analítica, y no encontramos nada; lo mismo en el framework mlx. El 1 de octubre de 2026 repetimos el barrido en la 0.32.0 publicada: sigue sin haber nada.

La red empieza con tu primer comando. mlx-lm descarga con la biblioteca de la propia Hugging Face, huggingface_hub, desde huggingface.co, y no solo la primera vez: cada vez que cargas un modelo por su nombre de Hugging Face, esa biblioteca le pregunta a huggingface.co si los ficheros tienen una versión más nueva, aunque ya estén en la caché. Con la petición va una cabecera de agente de usuario con tu versión de Python, la de huggingface_hub y, si lo tienes instalado, la de PyTorch. mlx-lm no se identifica, así que la cabecera empieza literalmente por unknown/None. La documentación de Hugging Face dice que sus bibliotecas recogen algunos datos de uso de fábrica, y da el interruptor.

Con los modelos ya descargados, 2 variables lo cierran:

export HF_HUB_OFFLINE=1
export HF_HUB_DISABLE_TELEMETRY=1
mlx_lm.chat --model mlx-community/Qwen3-8B-4bit

Con HF_HUB_OFFLINE=1 no se hace ninguna llamada HTTP a Hugging Face: un modelo que está en la caché carga, y uno que no está falla con un error en vez de descargarse. DO_NOT_TRACK=1 hace lo mismo que la segunda línea.

Todo lo demás sale solo cuando lo pides: --upload-repo y mlx_lm.upload publican en Hugging Face; AWQ, GPTQ y la cuantización dinámica se bajan una vez un texto de calibración de un gist de GitHub; DWQ descarga un conjunto de datos de Hugging Face; afinar un modelo con el nombre de un conjunto de datos de Hugging Face descarga ese conjunto, y el campo model del servidor descarga lo que nombre un cliente. Con MLXLM_USE_MODELSCOPE=true, las descargas van a ModelScope en vez de a Hugging Face.

La objeción es justa. «Sin telemetría propia» es una afirmación sobre el código de mlx-lm, no sobre tu red. Se leyó en el código publicado, no en una captura de tráfico, y la ficha lo dice. La única biblioteca que habla, huggingface_hub, no es de Apple, y su versión es la que pip haya resuelto en tu máquina. Aun así, es una cuenta leída en el código, y eso ya es más de lo que permite LM Studio: su aplicación es de código cerrado, así que lo que manda solo se puede describir a partir de lo que declara su fabricante. Y la cuenta es 0, donde Cómo instalar Ollama en local y ver qué manda por su cuenta encuentra 30 llamadas al día con la aplicación abierta.

En este orden acabas con un MLX que funciona y está callado:

1. Comprueba que tu Python es nativo y 3.11 o posterior: platform.processor() tiene que decir arm.
2. Crea un entorno virtual, pip install mlx-lm, y confirma 0.32.0 y 0.32.3 con pip show mlx mlx-lm.
3. Elige el modelo con el buscador de modelos o con la ficha de equipo de tu Mac, y lee Peak memory en mlx_lm.generate.
4. Cuando esté descargado, pon HF_HUB_OFFLINE=1 y HF_HUB_DISABLE_TELEMETRY=1.
5. Antes de lanzar mlx_lm.server, pon --allowed-origins, deja el host en 127.0.0.1 y usa un túnel SSH para otros equipos.

Los 5 programas se comparan justo en esto en 5 programas de IA local: telemetría, llamadas y auditoría.