oMLX: servir LLM en local en Mac Apple Silicon sin pelearse con Metal

Puntos clave

• oMLX es un servidor de inferencia LLM montado sobre MLX (el framework de Apple para Apple Silicon) que añade lo que a mlx-lm solo le falta para servir en serio: continuous batching, KV cache por tiers RAM+SSD con prefix sharing, multi-modelo con LRU eviction y API compatible con OpenAI y Anthropic.
• La versión publicada a fecha de hoy es 0.3.8 (30-abr-2026), Apache 2.0, 14,3k estrellas en GitHub y 71 releases. Proyecto joven con cadencia alta, no v1.0.
• En un Mac M1–M4 con macOS 15+, sustituye con holgura a Ollama en cuanto pides concurrencia o quieres usar el endpoint OpenAI desde una app propia.
• Cuándo NO elegirlo: si necesitas portabilidad multi-OS (Linux, NVIDIA), perfil enterprise (auth nativa, OTEL, multi-tenancy) o vives en GGUF heredado, Ollama sigue ganando.

Por qué Apple Silicon necesita su propio runtime

La memoria unificada (CPU, GPU y Neural Engine compartiendo la misma DRAM) es la diferencia material entre un Mac M-series y una caja con GPU NVIDIA. En una RTX 4090 tienes 24 GB de VRAM separada y mueves tensores por PCIe; en un M4 Max con 64 GB unificados, el modelo y los KV cache viven en el mismo bus que la CPU. El problema deja de ser «cuántos GB caben en la VRAM» y pasa a ser «cómo aprovecho la memoria y los Apple Matrix coprocessors sin pelearme con Metal a pelo».

CUDA no aplica. ROCm tampoco. Apple publicó MLX en diciembre de 2023 como su respuesta oficial: un framework de arrays estilo NumPy/PyTorch que compila a Metal por debajo y está diseñado para memoria unificada. Encima de MLX, el equipo de mlx-lm (oficial de Apple) mantiene los modelos LLM convertidos a formato MLX (Qwen, Llama, Mistral, GLM, DeepSeek) y hay cuantizaciones de 4 y 8 bit pensadas para M-series.

mlx-lm por sí mismo es una librería. Sirve un modelo, una petición cada vez, sin batching real. Para cualquier uso que vaya más allá del chat experimental contigo mismo, falta la capa de servidor. Ahí entra oMLX.

Qué aporta oMLX encima de mlx-lm

oMLX se describe como «LLM inference, optimized for your Mac — continuous batching and tiered KV caching, managed directly from your menu bar». Las piezas que importan:

• Continuous batching. Cuando un cliente pide tokens, oMLX no espera a terminar para atender al siguiente; intercala peticiones a nivel de token. Si tres usuarios conversan a la vez con el mismo modelo, los tres avanzan en paralelo en lugar de hacer cola. Sin batching, un Mac M4 Max alimentando dos terminales encadena turnos como si fuera un teléfono.
• KV cache tiered (RAM caliente + SSD frío) con prefix sharing. El KV cache es la memoria de los tokens ya procesados. oMLX mantiene los recientes en RAM y aparca los más fríos en SSD comprimidos, además de compartir prefijos entre peticiones que arrancan igual (el típico «Eres un asistente útil…»). En la práctica significa que puedes mantener ventanas de contexto largas sin reventar la RAM disponible.
• Multi-modelo con LRU eviction. Cargas Qwen3, Llama 3.3 y un OCR a la vez y oMLX decide cuál descargar cuando la memoria aprieta. También puedes descargar manualmente desde el dashboard si quieres más control.
• API compatible con OpenAI y Anthropic. Apuntas un cliente del SDK de OpenAI a http://localhost:8000/v1 y la integración funciona sin reescritura. Igual para tool calling y structured output.
• Menu bar app y admin dashboard. Aplicación nativa macOS en la barra superior y dashboard web con chat, descarga de modelos y benchmark integrado en :8000/admin/chat. No tienes que vivir en la terminal.

VLM (Qwen3.5-VL, GLM-4V, Pixtral), OCR (DeepSeek-OCR, DOTS-OCR), embeddings (BGE-M3, ModernBERT) y rerankers entran en la misma instancia. Para un workflow de RAG donde generación, embeddings y rerank conviven en el mismo proceso, ese único endpoint vale oro.

Cómo se ve en marcha

Instalación por Homebrew (también hay .dmg y pip install -e . desde fuente):

brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx
omlx serve --model-dir ~/models

Una vez levantado, descargas modelos desde el dashboard en http://localhost:8000/admin/chat y consumes desde cualquier SDK contra http://localhost:8000/v1. La menu bar muestra modelos cargados, peticiones activas y uso de RAM y SSD.

Comparativa pragmática (mayo de 2026)

Cuatro ejes que importan en un Mac:

Instalación y modelos. Ollama es lo más cómodo (curl | sh, library propia, GGUF). LM Studio es la opción «yo no quiero terminal», con GUI completa. mlx-lm es pip install puro y modelos directos de Hugging Face en formato MLX. oMLX se instala por Homebrew o .dmg, descarga modelos MLX desde el dashboard y, a partir de v0.3.x, importa cualquier repo MLX de Hugging Face pegando la URL.

Batching real bajo concurrencia. Aquí Ollama llama-server flojea: serializa peticiones por modelo. LM Studio igual. mlx-lm, una a una. oMLX es el único de los cuatro que hace continuous batching estilo vLLM. Si vas a poner dos personas, un agente y un editor a hablar a la vez con el mismo modelo, oMLX cambia la sensación de uso.

Formato de modelos. Ollama vive en GGUF (llama.cpp). MLX y oMLX viven en formato MLX, que cuantiza específicamente para Metal y aprovecha mejor los Apple Matrix coprocessors en M3+. Para el mismo modelo, MLX cuantizado a 4 bit suele dar 15-30% más tokens/s en M3/M4 que el GGUF equivalente en Ollama, según benchmarks que circulan en mlx-community y en hilos de Hacker News durante 2025-2026. Es una diferencia medible, no un argumento de venta.

API y herramientas. Ollama tiene API propia más compatibilidad OpenAI parcial. LM Studio expone endpoint OpenAI también. mlx-lm no es un servidor. oMLX trae OpenAI y Anthropic compatibles, tool calling, structured output y benchmarking integrado.

Veredicto por escenario:

• Mac de a diario, un usuario, un chat: LM Studio o Ollama. No vas a notar el batching.
• Demo a un cliente: LM Studio (la GUI vende sola).
• API tipo OpenAI para una app propia o un agente que mantienes: oMLX. Menos fricción y menos sorpresas con tool calling.
• Evaluación con concurrencia o RAG con generación, embeddings y rerank en el mismo host: oMLX, sin discusión.
• Mismo workflow pero quieres trasladarlo a Linux mañana: Ollama. La portabilidad pesa.

Configuración recomendada por RAM (M4 y M5)

Antes de los números: oMLX comparte la RAM unificada con macOS y el resto de apps abiertas. Una regla útil en la práctica es restar entre 10 y 14 GB al total para Finder, Safari, IDE y demás antes de calcular cuánto te queda para modelos y KV cache. Todas las tallas que siguen asumen cuantización MLX 4-bit desde mlx-community en Hugging Face^[1], un solo usuario y contexto de 4k. Subir a 32k puede sumar entre 4 y 15 GB de KV cache según el modelo — el tier SSD frío de oMLX ayuda, pero quieres dejar margen en RAM caliente.

Los chips disponibles en cada tramo:

• 24 GB: M4 base (configuración alta) y M4 Pro de entrada. Cuando salga la familia M5, el M5 base ocupará este hueco.
• 32 GB: M4 base (tope) o M5 base. Pocas configuraciones llegan hasta aquí en la gama Pro.
• 64 GB: M4 Max (intermedio) y, esperado para 2026, M5 Pro alto y M5 Max base.
• 128 GB: M4 Max tope y M5 Max alto. El esperado M5 Ultra debería desbloquear 192 y 256 GB.

24 GB — alrededor de 12-14 GB útiles

La franja del Mac Mini M4 base bien configurado y del MacBook Pro M4 Pro de entrada. Manda elegir entre un modelo bueno o un setup multi-modelo, no las dos cosas.

• Calidad: Mistral-Small-3.2-24B-Instruct-4bit (~13 GB). Entra justo, queda poco para contexto largo.
• Más cómodo: Qwen3-14B-Instruct-4bit (~8 GB). Buen balance calidad/RAM, deja sitio para un BGE-M3 (~1,2 GB) y un reranker pequeño.
• Velocidad pura: Llama-3.2-3B-Instruct-4bit o Gemma-3-4B-4bit (~2-3 GB) — 80-120 tok/s en M4 Pro.
• VLM viable: Qwen2.5-VL-7B-4bit (~5 GB) si vas a usar OCR ocasional.

32 GB — alrededor de 18-22 GB útiles

Suficiente para un modelo serio de chat con embeddings y reranker activos en paralelo.

• Calidad: Qwen3-32B-Instruct-4bit (~17 GB). Es el sweet spot de este tier: rinde como un 70B en muchas tareas y deja headroom de contexto.
• Velocidad: bajar a Qwen3-14B-Instruct-4bit para llegar a 40-60 tok/s en M4 Pro.
• Multi-modelo: 14B chat + Pixtral-12B-4bit (~7 GB) para visión + embed + reranker entran a la vez, y la LRU eviction de oMLX se encarga de mover los fríos al SSD cuando aprieta.

64 GB — alrededor de 50 GB útiles

El tier donde el Mac empieza a parecerse a una caja con una GPU mid-range, sin el ruido.

• Calidad: Llama-3.3-70B-Instruct-4bit (~40 GB), el referente para escribir y razonar. Mistral-Large-2-123B entra solo en cuantización 3-bit y queda apretado.
• Velocidad sin pagar mucha calidad: Qwen3-30B-A3B-Instruct-4bit (MoE; ocupa ~17 GB pero solo activa ~3B parámetros por token), ~50-60 tok/s en M4 Max. Es el modelo que cambia la experiencia de uso en este tier.
• Multi-modelo realista: 70B chat + Qwen2.5-VL-32B-4bit (~18 GB) + embeddings + reranker, con LRU para mover cosas cuando aprieta.

128 GB — alrededor de 110 GB útiles

Aquí cabe lo que no cabe en ningún consumer hardware NVIDIA decente. Es donde el argumento “compré un Mac en vez de montar un servidor” empieza a justificarse solo.

• Calidad tope: Mistral-Large-2-123B-Instruct-4bit (~70 GB) sin discusión para tareas de razonamiento general. DeepSeek-V3-MoE en cuantización agresiva entra (~80 GB). Qwen3-235B-A22B-4bit aprieta los 140 GB y conviene bajar a 3-bit; pierdes algo de calidad pero gana viabilidad.
• Velocidad: mismo patrón MoE (30B-A3B o equivalente) si quieres latencia baja para agentes.
• Multi-modelo serio: 123B chat + 70B alternativo con LRU + Qwen2.5-VL-72B-4bit (~40 GB) para visión. Es realista tener tres modelos grandes cargados a la vez con cache SSD para los fríos.

Rendimiento esperado (M4 Max, un usuario, contexto 4k)

Como referencia de orden de magnitud para los modelos densos en 4-bit: 14B alrededor de 50-70 tok/s, 32B alrededor de 25-35, 70B alrededor de 10-15, 123B alrededor de 6-9. Las arquitecturas MoE (30B-A3B, 235B-A22B) suelen rendir como un modelo denso de su tamaño activo (~3B y ~22B respectivamente), así que un 30B-A3B sostiene 50-60 tok/s. En M4 Pro recorta esos números entre un 30 y un 40% por ancho de banda; en M4 base, casi la mitad. M5 se espera entre un 10 y un 25% más rápido al mismo tier, con la mejora más visible en prefill que en decode.

Lo que oMLX todavía no es

Hay que decirlo claro: es un proyecto joven. v0.3.8 no es v1.0. La instancia no trae auth out-of-the-box (la dejas escuchando en localhost o la tapas con un reverse proxy con basic auth), no hay integración OTEL nativa para métricas y trazas, y no está pensado para multi-tenancy. Quien venga del mundo enterprise con compliance encima tiene que poner esas capas por su cuenta.

Otro punto: GGUF. Si tu colección actual son GGUF descargados durante el último año, oMLX no los come. O conviertes a MLX (hay scripts upstream para los modelos populares) o sigues con Ollama. La conversión no es trivial para arquitecturas exóticas o tokenizers custom, y conviene mirar el repo mlx-community en Hugging Face antes de empezar a convertir a mano.

Y, evidentemente, Mac. No hay versión Linux ni Windows. Si tu portátil de desarrollo es Mac y tu servidor casero es un Linux con NVIDIA, el binario de oMLX no te sirve para el segundo. Necesitas dos runtimes distintos para los dos mundos.

Sentido para el público de jacar.es

Para un fundador o CTO con un Mac M3/M4 que quiera probar IA local antes de comprometerse con infra dedicada, sí. Te ahorra montar Docker, configurar Open WebUI y exponer tras Traefik, que son los pasos que el tutorial de Ollama + Llama 3.3 en Ubuntu cubre cuando ya has decidido que merece la pena. oMLX es el paso cero: comprobar en tu propio portátil si los modelos abiertos te dan suficiente calidad antes de poner una GPU en producción.

Si encaja, lo siguiente es atarlo a un cliente de verdad: ver cómo el tutorial de Anthropic SDK con agentes se reescribe apuntando al endpoint local, o cómo encaja en una pila MCP multi-vendor sin pagar por tokens cada vez.

Repos de referencia: github.com/jundot/omlx^[2], github.com/ml-explore/mlx^[3], github.com/ml-explore/mlx-lm^[4], huggingface.co/mlx-community^[1].

1. mlx-community en Hugging Face
2. github.com/jundot/omlx
3. github.com/ml-explore/mlx
4. github.com/ml-explore/mlx-lm