Exprime tu Mac Apple Silicon con oMLX: LLM en local sin GPU NVIDIA

Puntos clave

• oMLX es un servidor de inferencia LLM construido sobre MLX, el framework que Apple publicó en diciembre de 2023 para Apple Silicon. Añade continuous batching, KV cache en dos niveles (RAM + SSD) y una API compatible con OpenAI y Anthropic.
• Versión actual: 0.3.8 (30 de abril de 2026), licencia Apache 2.0, 14,3k estrellas en GitHub y 71 releases. Proyecto joven pero con ritmo de publicación alto.
• En cualquier Mac M1-M5 con macOS 15+, supera a Ollama cuando necesitas concurrencia real o quieres apuntar tu app al endpoint OpenAI sin reescribir el cliente.
• Cuándo no es lo tuyo: si necesitas portabilidad a Linux con GPU NVIDIA, características de empresa (auth nativa, OTEL, multi-tenant) o ya tienes una colección grande en formato GGUF, Ollama sigue ganando.

Por qué Apple Silicon necesita su propio runtime

La memoria unificada es la diferencia material entre un Mac M-series y una caja con GPU NVIDIA. En la familia Apple Silicon, CPU, GPU y Neural Engine comparten la misma DRAM; en una RTX 4090 tienes 24 GB de VRAM aparte y los tensores viajan por PCIe.

Para un servidor de LLM eso cambia la pregunta. Deja de ser «cuántos gigabytes caben en la VRAM» y pasa a ser «cómo aprovecho la memoria unificada y los Apple Matrix coprocessors sin escribir kernels de Metal a mano».

CUDA no aplica. ROCm tampoco. Apple publicó MLX como su respuesta oficial: un framework de arrays al estilo NumPy/PyTorch que compila a Metal y está pensado para memoria unificada. Encima de MLX, el equipo de mlx-lm (oficial de Apple) mantiene los pesos de los modelos LLM convertidos al formato MLX (Qwen, Llama, Mistral, GLM, DeepSeek), con cuantizaciones de 4 y 8 bit ajustadas para la familia M.

mlx-lm por sí mismo es una librería: un modelo, una petición cada vez, sin batching real. Para cualquier uso 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 en el día a día:

• Continuous batching. Cuando un cliente pide tokens, oMLX no espera a terminarlo 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 vez de hacer cola. Sin esta pieza, un Mac M4 Max alimentando dos terminales se comporta como un teléfono atendiendo turnos.
• KV cache en dos niveles (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, y comparte prefijos entre peticiones que arrancan igual (el típico «Eres un asistente útil…»). En la práctica permite mantener ventanas de contexto largas sin agotar la RAM disponible.
• Multi-modelo con desalojo LRU. Cargas Qwen3, Llama 3.3 y un modelo de OCR a la vez y oMLX decide cuál descargar cuando la memoria aprieta. También puedes hacerlo 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 todo funciona sin reescribir nada. Lo mismo para tool calling y structured output.
• App de barra de menús más dashboard de administración. Aplicación nativa de macOS en la barra superior, junto a un dashboard web con chat, descargador de modelos y benchmark integrado en :8000/admin/chat. No tienes que vivir en la terminal.

Modelos de visión (Qwen3.5-VL, GLM-4V, Pixtral), OCR (DeepSeek-OCR, DOTS-OCR), embeddings (BGE-M3, ModernBERT) y rerankers conviven en la misma instancia. Para un flujo de RAG donde generación, embeddings y rerank comparten proceso, ese único endpoint es muy práctico.

Cómo se pone en marcha

Instalación por Homebrew, con .dmg y pip install -e . desde fuente como alternativas:

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 barra de menús muestra modelos cargados, peticiones activas y consumo 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 y GGUF. LM Studio es la opción «no quiero terminal», con GUI completa. mlx-lm es pip install puro con modelos pulled directamente 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 una URL.

Batching real con 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 con el mismo modelo a la vez, 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 y posteriores. Para el mismo modelo, MLX cuantizado a 4 bit suele entregar entre un 15 y un 30% más tokens/s en M3 y M4 que el GGUF equivalente en Ollama, según los benchmarks que circulan en mlx-community y en hilos de Hacker News durante 2025 y 2026. Es una diferencia medible, no un argumento de venta.

API y herramientas

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

Veredicto por escenario

• Mac de a diario, un solo usuario, un chat: LM Studio o Ollama. No vas a notar el batching.
• Demo para un cliente: LM Studio. La GUI se 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 flujo pero quieres moverlo 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 todo lo que tengas abierto. 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 el espacio para modelos y KV cache. Todas las tallas asumen cuantización MLX 4-bit desde mlx-community en Hugging Face^[1], un solo usuario y contexto de 4k. Subir de 4k a 32k puede sumar entre 4 y 15 GB de KV cache según el modelo. El nivel de SSD frío de oMLX ayuda, pero conviene dejar margen en RAM caliente.

Chips disponibles por tramo:

• 24 GB: M4 base (configuración alta) y M4 Pro de entrada. Cuando salga la familia M5, el M5 base se ubicará aquí.
• 32 GB: M4 base (tope) o M5 base. Pocas configuraciones Pro caen exactamente en este nivel.
• 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 abrir 192 y 256 GB.

24 GB — alrededor de 12-14 GB útiles

El Mac Mini M4 bien configurado y el MacBook Pro M4 Pro de entrada. Toca elegir entre un modelo bueno o un setup multi-modelo, no las dos cosas a la vez.

Para máxima calidad, Mistral-Small-3.2-24B-Instruct-4bit (~13 GB) entra justo y deja poco aire para contexto largo. Más cómodo: Qwen3-14B-Instruct-4bit (~8 GB), que mantiene calidad razonable y deja sitio para BGE-M3 (~1,2 GB) más un reranker pequeño. Si lo que buscas es velocidad pura, Llama-3.2-3B-Instruct-4bit o Gemma-3-4B-4bit (~2-3 GB) llegan a 80-120 tok/s en M4 Pro. Como modelo de visión, Qwen2.5-VL-7B-4bit (~5 GB) es viable para OCR ocasional.

32 GB — alrededor de 18-22 GB útiles

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

La opción de calidad es Qwen3-32B-Instruct-4bit (~17 GB). Es el punto óptimo de este tramo: rinde como un 70B en muchas tareas y deja margen de contexto. Si prefieres velocidad, bajar a Qwen3-14B-Instruct-4bit lleva a 40-60 tok/s en M4 Pro. Multi-modelo realista: 14B de chat más Pixtral-12B-4bit (~7 GB) para visión, embed y reranker, con la política LRU de oMLX moviendo los fríos al SSD cuando aprieta.

64 GB — alrededor de 50 GB útiles

El tramo en el que un Mac empieza a parecerse a una caja con GPU media, sin el ruido del ventilador que esa caja arrastra.

Para calidad, Llama-3.3-70B-Instruct-4bit (~40 GB) es la referencia para escribir y razonar bien. Mistral-Large-2-123B solo entra cuantizado a 3-bit y queda apretado. Si quieres velocidad sin sacrificar mucha calidad, Qwen3-30B-A3B-Instruct-4bit (MoE: ocupa ~17 GB en disco pero solo activa ~3B parámetros por token) sostiene 50-60 tok/s en M4 Max. Es el modelo que más cambia la experiencia en este tramo. Multi-modelo realista: 70B de chat más Qwen2.5-VL-32B-4bit (~18 GB), embeddings y reranker, con LRU gestionando los picos.

128 GB — alrededor de 110 GB útiles

Aquí cabe lo que no cabe en ningún consumer hardware NVIDIA razonable. El argumento «compré un Mac en vez de montar un servidor» empieza a sostenerse solo.

Para calidad tope, Mistral-Large-2-123B-Instruct-4bit (~70 GB) es la elección clara en razonamiento general. DeepSeek-V3-MoE entra en cuantización agresiva (~80 GB). Qwen3-235B-A22B-4bit roza los 140 GB; 3-bit es más realista a cambio de algo de calidad. Para velocidad, el mismo patrón MoE (30B-A3B o equivalente) si tienes bucles de agente que necesitan latencia baja. Multi-modelo serio: 123B de chat más un 70B alternativo bajo LRU más Qwen2.5-VL-72B-4bit (~40 GB) para visión. Tener tres modelos grandes cargados a la vez con cache SSD para los fríos es realista en este tramo.

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

Para los modelos densos en 4-bit, como referencia de orden de magnitud: 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), por lo 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 a la mitad. M5 se espera entre un 10 y un 25% más rápido al mismo tramo, con la mejora más visible en prefill que en decode.

Limitaciones a tener en cuenta

Es un proyecto joven: v0.3.8 no es v1.0. La instancia no trae autenticación de fábrica (la dejas escuchando en localhost o la tapas con un reverse proxy y basic auth), no hay integración OTEL nativa para métricas y trazas, y no está pensado para multi-tenant. Si vienes del mundo enterprise con compliance encima, esas capas las pones tú por separado.

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

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

Para quién es esta guía

Para un fundador o CTO con un Mac M3, M4 o M5 que quiera probar IA local antes de comprometerse con infraestructura dedicada, la respuesta es sí. Te ahorras montar Docker, configurar Open WebUI y exponer detrás de Traefik, que son los pasos que cubre el tutorial de Ollama + Llama 3.3 en Ubuntu 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 calidad suficiente antes de poner una GPU en producción.

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

Repositorios 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].

Configuración completa en un Mac M5 Max 40-core con 128 GB (Claude Code y multi-LLM)

Esta sección documenta una instalación real de oMLX como referencia para la configuración tope que verás en 2026: Mac Studio o MacBook Pro con M5 Max 40 GPU cores y 128 GB de memoria unificada. La familia M5 no se ha presentado oficialmente a fecha de hoy (mayo de 2026); los números de throughput están extrapolados de benchmarks publicados de M4 Max añadiendo entre un 15 y un 25% por mejoras esperadas de ancho de banda. Las capturas, en cambio, vienen de una instancia oMLX en funcionamiento.

Instalación y primer arranque

Instalación por Homebrew, igual que en cualquier Mac Apple Silicon:

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

Alternativamente, abre la app de la barra de menús (.dmg desde Releases) y deja que arranque el daemon en background. El primer acceso al panel en http://localhost:8000/admin pide la API key que protege la instancia.

Cambia la API key por defecto

La instalación trae letmein como API key de desarrollo. Para uso local sin exposición a otros equipos de la red, vale; en cuanto la instancia escucha en algo distinto de 127.0.0.1 o vas a compartir el endpoint, sustitúyela en Settings → Auth & Info por una cadena larga y aleatoria. La sección permite registrar varias claves a la vez, por si quieres dar acceso a un colega sin compartir la principal.

Ajustes del servidor para 128 GB de memoria unificada

En Settings → Global Settings vive el panel de configuración del servidor. Para una máquina con 128 GB las decisiones razonables son:

• Server → Host: Localhost only (127.0.0.1). Si quieres exponer a la red local, cambia a LAN y añade autenticación en serio antes de hacerlo.
• Server → Port: 8000 por defecto.
• Resource Management → Memory Limit (Total): Auto. oMLX calcula el límite restando lo que reserva macOS; con 128 GB acaba alrededor de 110-114 GB disponibles para inferencia.
• Resource Management → Memory Limit (Models Only): Auto. Mantiene un porcentaje para activaciones, KV cache y procesos auxiliares.
• Resource Management → Hot Cache Limit: Off. Con 128 GB no necesitas el nivel hot intermedio del KV cache; reduce complejidad. Si ejecutas tres o más modelos grandes a la vez con contextos largos, súbelo a 5-10%.
• Resource Management → Cold Cache Limit (SSD Cache): 10%. Sano por defecto. Reserva ~80 GB del disco para tokens fríos sin saturar el SSD.
• Resource Management → Max Concurrent Requests: 16. Cómodo para un usuario con un agente, una sesión de chat y un IDE pidiendo a la vez; sube a 32 si lo compartes con un equipo pequeño.
• Resource Management → Idle Timeout: None. Mantiene los modelos calientes; la latencia del primer token baja de varios segundos a sub-segundo.
• Generation Defaults → Max Context Window: 32768 por defecto. Cada modelo puede sobrescribirlo en Model Settings.
• Generation Defaults → Temperature: 1.0 para uso general, 0.2-0.5 para modelos de código.

Stack de modelos recomendado para multi-LLM

Con 128 GB tienes margen para cargar a la vez un modelo de código, uno general de razonamiento, un helper rápido, un VLM, embeddings y un reranker. Carga sugerida desde Models → Downloader pegando la URL del repo de Hugging Face:

• Código primario: Qwen3-Coder-30B-A3B-Instruct-mlx-8bit (~32 GB). Arquitectura MoE: ocupa ese disco pero solo activa ~3B parámetros por token, así que rinde más rápido que su tamaño sugiere.
• Razonamiento general: Llama-3.3-70B-Instruct-mlx-4bit (~40 GB) o Mistral-Large-2-123B-Instruct-mlx-4bit (~70 GB). Elige uno según prefieras calidad cruda (Mistral Large) o velocidad de respuesta (Llama).
• Helper rápido: Qwen3-14B-Instruct-mlx-4bit (~8 GB). Para tareas baratas en agentes, parseo y resúmenes.
• Modelo de visión: Qwen2.5-VL-32B-Instruct-mlx-4bit (~18 GB) cubre OCR, descripción de imágenes y razonamiento multimodal.
• Embeddings: BGE-M3-mlx (~1,2 GB), denso + sparse + multi-vector en un solo modelo.
• Reranker: ModernBERT-base-mlx (~150 MB) para cerrar el lazo de un RAG decente.

Carga simultánea cómoda: alrededor de 95 GB. Con LRU eviction activado, puedes registrar los seis y dejar que oMLX intercambie entre RAM caliente y caché frío en SSD cuando algún modelo se queda inactivo.

Conectar Claude Code al endpoint local

oMLX expone un endpoint compatible con la API de Anthropic en http://127.0.0.1:8000 (raíz, no /v1). Claude Code respeta la variable ANTHROPIC_BASE_URL, así que apuntar el CLI a tu Mac es una cuestión de exportar variables:

export ANTHROPIC_BASE_URL=http://127.0.0.1:8000
export ANTHROPIC_AUTH_TOKEN=<tu_api_key>
export ANTHROPIC_DEFAULT_OPUS_MODEL=Qwen3-Coder-30B-A3B-Instruct-mlx-8bit
export ANTHROPIC_DEFAULT_SONNET_MODEL=Qwen3-Coder-30B-A3B-Instruct-mlx-8bit
export ANTHROPIC_DEFAULT_HAIKU_MODEL=Qwen3-14B-Instruct-mlx-4bit
export ANTHROPIC_DEFAULT_MODEL=Qwen3-Coder-30B-A3B-Instruct-mlx-8bit
export API_TIMEOUT_MS=600000
export CLAUDE_CODE_USE_BEDROCK=0
export DISABLE_NONESSENTIAL_TRAFFIC=1
claude

El propio dashboard de oMLX construye este comando por ti en la sección Claude Code with oMLX: eliges Opus, Sonnet y Haiku desde tres desplegables y copias el comando ya armado. La opción Context scaling for Claude Code ajusta el contexto al máximo viable del modelo (Claude Code pide 200k tokens por defecto; la familia Qwen3 maneja 128k cómodos, y la opción adapta el valor por petición).

Hay que decirlo claro: Claude Code está afinado al formato de tool-use y a los patrones de respuesta de Claude. Un modelo que no es Claude detrás de ANTHROPIC_BASE_URL funciona para autocompletado y razonamiento, pero notarás caídas de fiabilidad en bucles agénticos y en llamadas a herramientas. Sirve para trabajo offline, datos sensibles que no salen del Mac o fallback cuando api.anthropic.com te limita la cuota; no es un reemplazo 1:1 de Claude Opus 4.7.

Otras integraciones (Codex, OpenCode, OpenClaw)

El mismo dashboard incluye launchers de un click para clientes externos: Codex (CLI estilo OpenAI), OpenCode (agente de código open source) y OpenClaw (wrapper estilo Claude). Cada uno tiene su propio dropdown de modelo y, en el caso de OpenCode, un selector de Tools que define qué herramientas estándar exponer al agente. La idea es que llegues, elijas modelo y copies el comando.

Benchmark del rendimiento real

En Bench → Performance lanzas pruebas en tu hardware concreto. El panel cubre prefill a varios tamaños de prompt (pp512, pp1k, pp2k, pp4k, pp16k, pp32k) y continuous batching con 2x, 4x y 8x de concurrencia. Puedes enviar tus resultados al leaderboard público de oMLX desde My Submissions.

Cifras esperadas para un M5 Max 40-core con 128 GB, extrapoladas de M4 Max publicados con un margen de mejora del 15-25%:

• Qwen3-Coder-30B-A3B 8-bit: alrededor de 70-90 tok/s en decode, 1.000-1.500 tok/s de prefill.
• Llama 3.3 70B 4-bit: alrededor de 15-20 tok/s en decode.
• Mistral Large 2 123B 4-bit: alrededor de 8-12 tok/s en decode.

Cuando llegue el hardware real, sustituye estas estimaciones por las cifras que te dé tu propio Bench → Performance: las arquitecturas MoE son las que más se benefician de los Apple Matrix coprocessors actualizados de M5.

Verificación end-to-end

Una llamada por curl a la API OpenAI-compatible para confirmar que el servidor está vivo y un modelo responde:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Authorization: Bearer <tu_api_key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen3-Coder-30B-A3B-Instruct-mlx-8bit",
    "messages": [{"role":"user","content":"Hola desde oMLX"}]
  }'

Y desde Claude Code, una vez exportadas las variables de la sección anterior:

claude --print "¿Estás respondiendo desde mi Mac?"

La respuesta debe llegar en local, sin tocar api.anthropic.com. Si la quieres confirmar a nivel red, abre Activity Monitor → Network, filtra por proceso claude y comprueba que la conexión saliente es contra 127.0.0.1:8000.

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