¿Puede un Mac ejecutar modelos de lenguaje grandes localmente sin una GPU dedicada?

Sí — esa es la fortaleza de Apple Silicon. Su memoria unificada se comparte entre el CPU y la GPU con alto ancho de banda, por lo que la GPU puede usar todo el pool de memoria. Un Mac de 64 GB puede ejecutar un modelo de 70B a 4 bits, algo que una GPU discreta de 24 GB no puede alojar, y los modelos más pequeños se ejecutan rápido. No se necesita una GPU separada.

¿Cuánta memoria unificada necesito para ejecutar un modelo de 7B, 30B o 70B?

Con cuantización de 4 bits: unos 16 GB para un modelo de 7B–8B, 32 GB para hasta aproximadamente 30B, y 64 GB para un 70B (que ocupa alrededor de 40 GB de pesos, dejando poco margen para el contexto). Con 128 GB puedes ejecutar un 70B a mayor precisión con espacio para contextos grandes. Siempre deja margen para la caché KV, que crece con la longitud del contexto.

¿Es MLX más rápido que llama.cpp en Apple Silicon?

Con frecuencia, en modelos pequeños — MLX es el framework de Apple construido para la memoria unificada y es notablemente más rápido por debajo de unos 14B, y brilla en modelos de mezcla de expertos. Por encima de unos 27B los dos convergen porque ambos quedan limitados por el ancho de banda. La ventaja de llama.cpp es la mayor biblioteca de modelos GGUF y la consistencia multiplataforma. Usa MLX para máxima velocidad en modelos pequeños y MoE.

¿Por qué mi Mac tarda en empezar a responder ante prompts largos?

Porque el procesamiento de prompts (tiempo hasta el primer token) es el punto débil de Apple Silicon. El prefill está limitado por cómputo y las GPU de Apple carecen de los tensor cores dedicados que usa NVIDIA para ello, así que un prompt largo tarda un tiempo antes de que aparezca el primer token — incluso cuando la generación de tokens posterior es rápida. Es la principal limitación específica de Apple para el trabajo con contextos largos.

¿Cuál es la herramienta más rápida para ejecutar LLMs en un Mac?

Para máximo rendimiento, MLX-LM (el framework de Apple), especialmente en modelos pequeños y MoE. Para facilidad de uso, Ollama (CLI más una API compatible con OpenAI) o LM Studio (la mejor interfaz gráfica) son las opciones populares, y varios usan ahora backends MLX en Apple Silicon. La elección correcta depende de si quieres máxima velocidad o máxima comodidad.

¿Puedo ejecutar un modelo de 70B en un MacBook Pro de 64 GB?

Sí, a 4 bits — un 70B a Q4 ocupa unos 40 GB, que caben en 64 GB con margen para el runtime y una ventana de contexto modesta. Es el punto de entrada práctico para 70B en un Mac; el margen de contexto es limitado, así que para contextos grandes o mayor precisión querrías 128 GB. Espera una velocidad de generación sólida pero un tiempo hasta el primer token más lento en prompts largos.

¿Apple Silicon o NVIDIA para LLMs locales?

Apple Silicon es excelente para inferencia local privada de un único usuario — la gran memoria unificada permite a un Mac ejecutar modelos que necesitarían múltiples GPU discretas, con menor consumo energético. NVIDIA gana en ancho de banda bruto (varias veces mayor), velocidad de procesamiento de prompts, servicio de alta concurrencia y ecosistema (CUDA). Elige Apple para uso local personal y modelos grandes en una sola máquina; NVIDIA para rendimiento y servicio con contextos largos.

← Resources

By Ren Sugaya — Performance Engineer, GPU & Inference · 2026-05-02 · TUTORIAL

Ejecutar LLMs en Apple Silicon: Memoria Unificada y Qué Cabe

Apple Silicon es excepcionalmente bueno para ejecutar LLMs porque su memoria unificada es compartida, de alto ancho de banda y amplia — un Mac de 64 GB puede ejecutar un modelo de 70B. Esta guía explica qué cabe en cada nivel de RAM, MLX frente a llama.cpp, la única debilidad real (el procesamiento de prompts) y las herramientas disponibles.

Por qué la memoria unificada es la ventaja

Apple Silicon comparte un único pool de memoria de alto ancho de banda entre el CPU, la GPU y el Neural Engine — no hay VRAM separada ni copias lentas a través de un bus PCIe. Por eso un Mac de 64 GB puede cargar un modelo que no cabe en una GPU discreta de 24 GB: todo el pool está disponible para la GPU.

Esto importa porque la generación de tokens en un LLM está [limitada por el ancho de banda de memoria](/articles/running-llms-on-cpu) — cada token requiere leer el modelo desde la memoria — y el ancho de banda unificado de Apple es lo suficientemente alto como para ser genuinamente competitivo en decode. El ancho de banda, no el cómputo bruto, es la especificación que determina la velocidad de generación aquí.

Qué cabe, según el nivel de memoria

La memoria unificada es la restricción determinante, así que ajusta el modelo a tu Mac (cifras con cuantización de 4 bits):

16 GB: modelos de 7B–8B sin problemas.
32 GB: hasta aproximadamente 30B.
64 GB: un modelo de 70B es viable (un 70B a Q4 ocupa unos 40 GB), aunque el margen para el contexto es ajustado — este es el punto de entrada práctico para 70B.
128 GB: un 70B a mayor precisión (Q5/Q8) con espacio para contextos grandes.
Nivel Ultra (192 GB+): 70B a alta precisión, modelos muy grandes o varios modelos residentes a la vez.

Regla general: calcula aproximadamente 0,5–0,6 GB por mil millones de parámetros para los pesos a Q4, y deja margen para la caché KV, que crece con la longitud del contexto y suele ser lo que decide si cabe un contexto de 16K o 32K.

MLX vs llama.cpp

Dos runtimes dominan en Mac. El backend Metal de llama.cpp traduce el cómputo GPU en shaders Metal y usa el formato multiplataforma GGUF con la mayor biblioteca de modelos. MLX es el framework propio de Apple, construido desde cero para la memoria unificada — generalmente más rápido en modelos pequeños (con frecuencia de forma notable por debajo de ~14B), con una diferencia que se reduce por encima de ~27B, donde ambos alcanzan el techo de ancho de banda.

MLX tiene impulso: Apple lo posicionó como el framework preferido para Apple Silicon, los runtimes más populares añadieron backends MLX y brilla en modelos de mezcla de expertos. La conclusión pragmática: MLX para máxima velocidad en modelos pequeños y MoE, llama.cpp/GGUF para la mayor selección de modelos y consistencia multiplataforma.

La debilidad real: el procesamiento de prompts

La limitación honesta de Apple Silicon no está en la generación, sino en el procesamiento de prompts (tiempo hasta el primer token). El prefill está limitado por cómputo, implica grandes multiplicaciones de matrices y las GPU de Apple carecen de los tensor cores dedicados que hacen a NVIDIA rápido aquí. Por eso, incluso cuando la generación de tokens es competitiva, el modelo puede ser notablemente lento al comenzar a responder ante un prompt largo, lo que domina la sensación real del trabajo con contextos largos.

La otra limitación es el ecosistema: la mayoría de las herramientas apuntan a CUDA, hay menos modelos MLX pre-cuantizados que GGUF, y una GPU NVIDIA de gama alta sigue teniendo varias veces más ancho de banda bruto. Para uso local interactivo de un único usuario, Apple Silicon es excelente; para trabajo con contextos largos o servicio de alto rendimiento, esas brechas importan.

Herramientas y cuantización

El ecosistema de herramientas para Mac es maduro: Ollama (CLI más una API compatible con OpenAI, el inicio más sencillo), LM Studio (la mejor interfaz gráfica), MLX-LM (rendimiento máximo y fine-tuning, mediante Python) y aplicaciones offline centradas en la privacidad. GGUF es el formato de cuantización dominante entre herramientas; el formato MLX es nativo de Apple y más rápido, pero tiene una biblioteca más pequeña.

Como en todas partes, la [cuantización](/articles/llm-quantization-explained-gguf) es lo que hace que funcione — bajar a 4 bits reduce un modelo aproximadamente cuatro veces (un 70B de ~140 GB a ~40 GB) con una pérdida de calidad modesta, y Q4_K_M suele ser el punto óptimo. Sube a Q5 o Q8 si tu memoria unificada lo permite.

Apple Silicon en osFoundry

osFoundry ejecuta inferencia local en Apple Silicon mediante las rutas Metal y MLX, de modo que el modelo se ejecuta completamente en la GPU de tu Mac usando su memoria unificada — los datos no salen del dispositivo y no hay penalización por copia PCIe. Como la restricción es simplemente cuánta memoria unificada tienes, osFoundry te ayuda a elegir un modelo adecuado a tu Mac — un modelo de 7B–8B en una máquina de 16 GB, hasta un 70B en una de 64 GB o más — y selecciona la cuantización para ajustar el modelo a la memoria disponible preservando la mayor calidad posible, para que no tengas que razonar manualmente sobre formatos GGUF o los compromisos Q4/Q5/Q8. El resultado es inferencia local completamente privada y con capacidad offline, ajustada al nivel de memoria de cada Mac — y el mismo modelo puede escalarse a un endpoint GPU dedicado cuando necesitas procesamiento de prompts más rápido o mayor rendimiento. (Para la historia del ancho de banda subyacente, consulta nuestra [guía de inferencia en CPU](/articles/running-llms-on-cpu).)

Frequently asked questions

¿Puede un Mac ejecutar modelos de lenguaje grandes localmente sin una GPU dedicada?: Sí — esa es la fortaleza de Apple Silicon. Su memoria unificada se comparte entre el CPU y la GPU con alto ancho de banda, por lo que la GPU puede usar todo el pool de memoria. Un Mac de 64 GB puede ejecutar un modelo de 70B a 4 bits, algo que una GPU discreta de 24 GB no puede alojar, y los modelos más pequeños se ejecutan rápido. No se necesita una GPU separada.
¿Cuánta memoria unificada necesito para ejecutar un modelo de 7B, 30B o 70B?: Con cuantización de 4 bits: unos 16 GB para un modelo de 7B–8B, 32 GB para hasta aproximadamente 30B, y 64 GB para un 70B (que ocupa alrededor de 40 GB de pesos, dejando poco margen para el contexto). Con 128 GB puedes ejecutar un 70B a mayor precisión con espacio para contextos grandes. Siempre deja margen para la caché KV, que crece con la longitud del contexto.
¿Es MLX más rápido que llama.cpp en Apple Silicon?: Con frecuencia, en modelos pequeños — MLX es el framework de Apple construido para la memoria unificada y es notablemente más rápido por debajo de unos 14B, y brilla en modelos de mezcla de expertos. Por encima de unos 27B los dos convergen porque ambos quedan limitados por el ancho de banda. La ventaja de llama.cpp es la mayor biblioteca de modelos GGUF y la consistencia multiplataforma. Usa MLX para máxima velocidad en modelos pequeños y MoE.
¿Por qué mi Mac tarda en empezar a responder ante prompts largos?: Porque el procesamiento de prompts (tiempo hasta el primer token) es el punto débil de Apple Silicon. El prefill está limitado por cómputo y las GPU de Apple carecen de los tensor cores dedicados que usa NVIDIA para ello, así que un prompt largo tarda un tiempo antes de que aparezca el primer token — incluso cuando la generación de tokens posterior es rápida. Es la principal limitación específica de Apple para el trabajo con contextos largos.
¿Cuál es la herramienta más rápida para ejecutar LLMs en un Mac?: Para máximo rendimiento, MLX-LM (el framework de Apple), especialmente en modelos pequeños y MoE. Para facilidad de uso, Ollama (CLI más una API compatible con OpenAI) o LM Studio (la mejor interfaz gráfica) son las opciones populares, y varios usan ahora backends MLX en Apple Silicon. La elección correcta depende de si quieres máxima velocidad o máxima comodidad.
¿Puedo ejecutar un modelo de 70B en un MacBook Pro de 64 GB?: Sí, a 4 bits — un 70B a Q4 ocupa unos 40 GB, que caben en 64 GB con margen para el runtime y una ventana de contexto modesta. Es el punto de entrada práctico para 70B en un Mac; el margen de contexto es limitado, así que para contextos grandes o mayor precisión querrías 128 GB. Espera una velocidad de generación sólida pero un tiempo hasta el primer token más lento en prompts largos.
¿Apple Silicon o NVIDIA para LLMs locales?: Apple Silicon es excelente para inferencia local privada de un único usuario — la gran memoria unificada permite a un Mac ejecutar modelos que necesitarían múltiples GPU discretas, con menor consumo energético. NVIDIA gana en ancho de banda bruto (varias veces mayor), velocidad de procesamiento de prompts, servicio de alta concurrencia y ecosistema (CUDA). Elige Apple para uso local personal y modelos grandes en una sola máquina; NVIDIA para rendimiento y servicio con contextos largos.