LLM Local en Mac Studio: el Software Decide el Rendimiento

Los equipos que invierten en un Mac Studio para ejecutar IA local suelen encontrarse con la misma sorpresa: los benchmarks de internet rara vez coinciden con lo que ven en la práctica. Un modelo de 32B rinde bastante menos de lo esperado tras la instalación. Cambiar de framework añade un 40 por ciento de rendimiento sin tocar el hardware. La máquina es la misma. El software no.

El investigador de IA rewind02 en X lo resumió en un post ampliamente compartido a principios de julio. Después de comparar MLX, Ollama, llama.cpp y el nuevo vllm-mlx sobre el mismo Mac Studio M3 Ultra, su conclusión fue: "Performance isn't about the hardware, it's about three software layers stacked on top of it." Las diferencias fueron sustanciales, con hardware idéntico en ambos casos.

Este artículo explica qué hay detrás de esas tres capas, cómo se posiciona cada motor de inferencia y cómo las pymes europeas pueden tomar la decisión correcta desde el principio.

La inversión y lo que realmente la determina

Un Mac Studio M3 Ultra con 192 GB de Unified Memory tiene un precio de lista de entre 4.999 y 5.999 euros. Para muchas empresas, es un desembolso único con retorno calculable: un equipo que usa APIs en la nube de forma intensiva puede acumular fácilmente varios cientos de euros al mes en costes de API. En dos o tres años, esos costes recurrentes superan con frecuencia la inversión inicial en hardware.

La pregunta que más importa no es si comprar el hardware, sino si el stack de software que corre sobre él entrega el rendimiento necesario para que la máquina resulte útil. Según mediciones reportadas por la comunidad, las tasas de generación de tokens para un modelo de 32B pueden diferir entre 2 y 4 veces en hardware idéntico, dependiendo del motor de inferencia utilizado. Esa diferencia decide si cinco compañeras pueden usar el sistema con comodidad o si colapsa bajo la carga.

Las tres capas de software

¿Qué determina realmente la velocidad de un LLM local en Apple Silicon? Tres capas interactúan entre sí:

Capa 1: El backend de inferencia

Es la capa más baja. Ejecuta las operaciones tensoriales y habla directamente con el hardware. Cuatro frameworks compiten aquí:

• MLX: el framework de machine learning propio de Apple, que delega operaciones como la multiplicación matricial directamente a la GPU y la Neural Engine del chip M. Los benchmarks de la comunidad reportan el mayor rendimiento bruto para peticiones individuales en Apple Silicon.
• llama.cpp: una implementación en C++ con soporte sólido para cuantización y CPU offloading. Relevante cuando un modelo es demasiado grande para caber completamente en la Unified Memory.
• vllm-mlx: un proyecto más reciente que combina el algoritmo de Continuous Batching de vLLM con el backend MLX. Según mediciones reportadas por la comunidad, ofrece un rendimiento agregado notablemente superior en escenarios multiusuario, al procesar peticiones en lotes eficientes.

Capa 2: El servidor de API

Ollama es el ejemplo más conocido de esta capa. Envuelve un backend de inferencia en una API REST compatible con OpenAI y gestiona el cambio de modelos, las ventanas de contexto y las conexiones paralelas. Dependiendo de la configuración, Ollama usa MLX o llama.cpp por debajo. La capa de servidor añade comodidad: una interfaz unificada, gestión automática de modelos y compatibilidad amplia con clientes.

Capa 3: La aplicación cliente

Open WebUI, LM Studio, llamadas directas a la API o una aplicación interna personalizada: es la capa con la que los usuarios interactúan a diario. Formatos de prompt mal configurados, ventanas de contexto innecesariamente grandes o serialización ineficiente pueden introducir pérdidas de rendimiento ocultas que a primera vista parecen problemas de hardware.

MLX, Ollama, llama.cpp y vllm-mlx: comparativa

MLX directo ofrece el mayor rendimiento bruto para peticiones individuales en Apple Silicon, según benchmarks de la comunidad. Apple puede enrutar operaciones matriciales a la Neural Engine de forma nativa. Para un desarrollador o investigador en solitario que necesita la máxima velocidad sin overhead de API, MLX directo es una opción sólida. La configuración requiere más conocimiento técnico que Ollama.

Ollama es el punto de entrada estándar y la elección correcta para la mayoría de las pymes. La instalación lleva minutos, la compatibilidad con clientes como Open WebUI o LibreChat es amplia, la documentación es buena y el proyecto publica actualizaciones con regularidad. El ligero overhead frente a MLX directo es asumible para la mayoría de casos de uso.

llama.cpp es la primera opción cuando los modelos superan la Unified Memory disponible. Las variantes de 70B en un Mac Studio con 64 o 96 GB se benefician del soporte maduro de CPU offloading. La configuración es más compleja, pero el beneficio para escenarios con modelos grandes es claro.

vllm-mlx es el recién llegado que atrae la atención de la comunidad. Combina el planificador de Continuous Batching de vLLM, que agrupa varias peticiones entrantes en un único lote de procesamiento optimizado, con el framework MLX de Apple. Según mediciones reportadas por la comunidad, supera a Ollama en escenarios de 5 a 20 usuarios concurrentes, donde la ventaja del batching se traduce directamente en mayor rendimiento global.

Saiyam Pathak describió así el estado actual del ecosistema en X: "The Local LLM space in 2026 is where Kubernetes was in 2017. Lots of tools. Confusing landscape. Best practices still emerging." Los equipos que entienden el stack ahora construyen una ventaja acumulada sobre quienes esperan a que el mercado se consolide.

Elegir el stack adecuado

Para un desarrollador en solitario o un grupo pequeño con uso ocasional: Ollama con el backend MLX estándar. Instalación más sencilla, mayor compatibilidad con clientes, rendimiento suficiente para este escenario.

Para un equipo de 5 a 20 personas que comparte el mismo endpoint de inferencia: vllm-mlx como servidor compartido, combinado con Open WebUI u otro frontend similar. La ventaja del batching se nota de forma medible.

Para modelos superiores a 70 mil millones de parámetros en hardware con Unified Memory limitada: llama.cpp con una configuración de offloading correctamente ajustada. El esfuerzo inicial de configuración merece la pena.

Las actualizaciones de frameworks llegan aproximadamente cada dos semanas. Una versión de Ollama puede cambiar el rendimiento en modelos concretos entre un 20 y un 30 por ciento. Vale la pena hacer una prueba rápida tras actualizaciones importantes.

Privacidad, cumplimiento normativo y financiación

Elegir IA local en Europa suele estar motivado por la privacidad: ningún dato sale de las instalaciones, no se requiere contrato de encargo de tratamiento con un proveedor en la nube, sin exposición a cambios en condiciones de servicio de terceros. Esto aplica con independencia del framework de inferencia elegido.

Lo que sí afecta la elección del framework es si la inversión se justifica económicamente. Un stack que entrega poco rendimiento implica comprar más hardware para el mismo resultado, o una adopción deficiente por parte de los usuarios debido a tiempos de respuesta demasiado largos. Ambas opciones socavan el caso de negocio para la IA local.

Para pymes españolas que buscan reducir el coste inicial: la inversión en infraestructura de IA local puede ser elegible como gasto dentro de la categoría de inteligencia artificial del programa Kit Digital, según nuestro análisis de las condiciones vigentes. La elegibilidad depende del agente digitalizador y del plan de digitalización concreto.

Para los fundamentos técnicos del stack MLX y una comparativa con Rapid-MLX, consulte nuestro artículo Rapid-MLX: inferencia local más rápida en Apple Silicon. Los equipos que quieran configurar un servidor de inferencia compartido encontrarán el punto de partida adecuado en vLLM y SGLang como servidor local para equipos.

¿Listo para evaluar el stack adecuado para su infraestructura? Inicia un proyecto piloto o contáctanos para diseñar la arquitectura correcta.