Has invertido en un Mac Studio M3 Ultra para ejecutar IA local y el rendimiento real no llega a lo que prometían los benchmarks. La brecha es real y tiene una causa de software, no de hardware. Un investigador de IA lo señaló con precisión en X: «Performance isn't about the hardware, it's about three software layers stacked on top of it.» (fuente) Probando MLX, Ollama, llama.cpp y el nuevo vllm-mlx en el mismo equipo, las diferencias de rendimiento resultaron considerables, y todas atribuibles a decisiones de software.
Para pymes europeas que evalúan infraestructura de IA on-premise, este matiz es crítico: el stack de inferencia elegido puede duplicar o reducir a la mitad el rendimiento efectivo del mismo hardware.
Las Tres Capas de Software
Para entender por qué dos Mac Studio idénticos pueden rendir de manera muy diferente, hay que analizar tres capas:
1. Capa de cuantización, ¿cuánto se comprimen los pesos del modelo?<br> Q4KM es rápido y eficiente en memoria. Q8_0 preserva mayor calidad al casi doble de consumo de memoria unificada. F16 usa precisión completa pero exige la mayor cantidad de RAM. Esta elección puede cambiar el throughput por un factor de 1,5 a 2 antes de que el motor de inferencia entre en juego.
2. Capa de cómputo, ¿qué framework realiza la inferencia?<br> MLX usa directamente el framework Metal nativo de Apple y está optimizado para la arquitectura de memoria unificada del Apple Silicon. llama.cpp trabaja con offloading a Metal pero es una herramienta genérica multiplataforma. Si los shaders Metal se aprovechan de forma completa o solo parcial determina si la inferencia corre acelerada por GPU o cae en la CPU, con una diferencia de velocidad de varias veces.
3. Capa de servicio, ¿cómo se expone el modelo a las aplicaciones cliente?<br> Ollama añade un servidor REST sobre llama.cpp: cómodo, pero con latencia añadida. Llamar directamente a mlx-lm o llama.cpp elimina esa abstracción. Bajo un volumen alto de solicitudes, la diferencia se acumula rápidamente.
La combinación de estas tres capas, y no solo la especificación del chip, determina los tokens por segundo que experimentan los usuarios en la práctica.
MLX, Ollama, llama.cpp y vllm-mlx Comparados
MLX-LM: Nativo para Apple Silicon
MLX es el framework de machine learning propio de Apple, diseñado específicamente para la arquitectura de memoria unificada del Apple Silicon. mlx-lm proporciona la interfaz de modelos de lenguaje sobre él.
Según mediciones reportadas por la comunidad, un Mac Studio M3 Ultra con 192 GB ejecutando Llama 3.3 70B con cuantización Q4KM alcanza entre 45 y 65 tokens por segundo con MLX-LM, las cifras más altas reportadas para esta clase de hardware. MLX llama directamente a los shaders Metal, eliminando el overhead de middleware presente en otros stacks.
La contrapartida: mlx-lm es una librería de línea de comandos y Python, no un servidor listo para producción. Se adapta mejor a equipos técnicos que construyen backends en Python o a desarrolladores que integran modelos directamente en pipelines.
Ollama: Comodidad con Coste
Ollama es la herramienta más utilizada para LLMs locales, y con razón: un solo comando descarga y sirve cualquier modelo compatible, y su REST API es directamente compatible con Open WebUI, LangChain, LlamaIndex y la mayoría de frameworks de integración.
Bajo el capó, Ollama usa llama.cpp como backend de inferencia. Esa capa de comodidad cuesta alrededor del 20-30 % de throughput respecto a llamar directamente a llama.cpp o mlx-lm, según mediciones reportadas por la comunidad. Para un solo desarrollador esto suele ser aceptable. Para un equipo con solicitudes concurrentes, el overhead se multiplica.
Para la mayoría de pymes europeas que despliegan un chatbot interno o un sistema de preguntas sobre documentos, Ollama sigue siendo la opción práctica por defecto. Una pyme española que financia el proyecto a través del Kit Digital puede combinar Ollama con Open WebUI para ofrecer un asistente de IA privado sin costes de cloud recurrentes. Consulta el kAIra Tools para ver cómo lo integramos en un stack completo.
llama.cpp Directo: Control Sin Envoltorio
llama.cpp es la implementación de referencia en C++ para modelos en formato GGUF. Llamarlo directamente, sin la capa de servicio de Ollama, suele recuperar un 10-20 % de throughput. En Apple Silicon, llama.cpp utiliza su backend ggml-metal; cuando el offloading a Metal está correctamente configurado, el rendimiento se aproxima al nivel de MLX-LM en muchos modelos.
La ventaja de portabilidad es significativa para organizaciones con entornos mixtos: los modelos GGUF funcionan sin cambios en Mac, Linux y Windows. Si el Mac Studio actúa como servidor de inferencia principal y hay máquinas Linux como respaldo, los mismos pesos del modelo funcionan en toda la flota.
vllm-mlx: Throughput de Producción para Equipos Concurrentes
vllm-mlx es el participante más reciente en este comparativo y el más relevante para equipos con varios usuarios simultáneos. vLLM es un servidor de inferencia de nivel de producción conocido por su mecanismo PagedAttention, que comparte eficientemente la memoria de GPU entre solicitudes paralelas. El port a MLX lleva esa ventaja de batching al Apple Silicon.
Para un único usuario en una sesión de chat, vllm-mlx muestra una latencia por solicitud similar a mlx-lm. Con cinco a diez miembros del equipo consultando el mismo Mac Studio de forma simultánea, informes tempranos de la comunidad sugieren que vllm-mlx puede aumentar el throughput total del sistema en un 30-50 % respecto a Ollama, porque las solicitudes se agrupan de forma inteligente en lugar de procesarse de manera secuencial.
Cuantización: La Palanca Infrautilizada
Junto a la elección del motor de inferencia, el formato de cuantización es el factor de rendimiento más infravalorado:
- Q4KM: La mejor eficiencia para la mayoría de casos de uso. Llama 3.3 70B en Q4KM ocupa aproximadamente 40 GB de memoria unificada. Para análisis de documentos, resúmenes y chat, las diferencias de calidad respecto a Q8_0 son mínimas en la práctica.
- Q8_0: Mayor calidad, casi el doble de coste en memoria. Recomendado para generación de código y tareas de razonamiento donde la precisión numérica importa.
- F16: Precisión completa; raramente necesario para despliegues en pymes.
Un M3 Ultra con 192 GB puede ejecutar modelos de hasta aproximadamente 405 B de parámetros en Q4KM, convirtiéndolo en el equipo de escritorio más capaz disponible para IA local sin necesidad de hardware de servidor dedicado.
¿Qué Stack para Qué Escenario?
| Escenario | Stack recomendado |
|---|---|
| Desarrollador/a, integración Python | mlx-lm directo |
| Chatbot de equipo con interfaz, 5-20 usuarios | Ollama + Open WebUI |
| Solicitudes concurrentes, nivel de producción | vllm-mlx |
| Portabilidad GGUF en Mac + Linux | llama.cpp directo |
Esta tabla es un punto de partida. El stack óptimo para tu entorno concreto depende de la topología de red, el tamaño del modelo, el número de usuarios y las aplicaciones que necesitan conectarse al modelo.
RGPD y Soberanía del Dato
Independientemente del stack elegido, cada inferencia se ejecuta íntegramente en el hardware local. Ningún token sale de la red corporativa; no se produce ninguna transferencia a terceros países según el art. 44 del RGPD. Esa ventaja fundamental de la soberanía del dato se mantiene sea cual sea la capa de servicio elegida, MLX-LM, Ollama o vllm-mlx.
Según nuestra interpretación del Reglamento de IA de la UE, los operadores que ejecutan modelos de pesos abiertos localmente están, en muchos escenarios de despliegue, exentos de las obligaciones más exigentes para proveedores de GPAI. La clasificación exacta depende del caso de uso concreto, esta es una valoración informativa, no asesoramiento jurídico.
¿Quieres saber qué stack de IA local se adapta mejor a tu equipo? En un proyecto piloto analizamos tus necesidades y recomendamos el stack de inferencia óptimo, concreto, presupuestado y conforme al RGPD.