Sacar el máximo partido a un Mac Apple Silicon

#Optimizar un LLM en Apple Silicon: las cuatro palancas

Para extraer el máximo rendimiento de un Mac Apple Silicon, cuatro factores cuentan, en este orden: el límite de memoria que macOS permite usar a la GPU, el tamaño y la cuantización del modelo, la caché KV y la atención flash para contextos largos, y la elección del motor (Ollama, llama.cpp, MLX o LM Studio). Todo parte de un hecho: la memoria unificada se comparte entre CPU y GPU, por lo que la RAM total sirve como VRAM, pero macOS limita la parte que la GPU puede reservar de forma fija. Elevar este límite permite usar modelos más grandes; los demás factores evitan saturar la memoria o ralentizar la generación. Ninguno hace que la máquina sea más rápida de lo que permite su ancho de banda.

Memoria unificada

La CPU y la GPU leen los mismos datos sin copiarlos. MLX lo resume así: los arrays residen en una memoria compartida. Por tanto, un Mac de 64 GB puede cargar un modelo que no cabe en ninguna tarjeta gráfica de consumo de 24 o 32 GB.

Eficiencia

Un Mac consume mucho menos que un PC equipado con una tarjeta de gama alta, cuya potencia supera los 500 W en el caso de la RTX 5090 de NVIDIA: el Mac se mantiene silencioso y consume poco con cargas ligeras.

Ecosistema

El repositorio de llama.cpp describe Apple silicon como una plataforma con soporte de primer nivel, optimizada mediante ARM NEON, Accelerate y Metal. Ollama, LM Studio y MLX también aprovechan Metal.

Límites

Sin CUDA, por lo que las bibliotecas que lo requieren no funcionan; el ancho de banda de un Mac (hasta 546 GB/s en un M4 Max) sigue por debajo del de una tarjeta gráfica de gama alta; el fine-tuning es posible, pero más lento.

#VRAM de un Mac: límite de memoria GPU y iogpu.wired_limit_mb

En un Mac, no hay VRAM separada: la «VRAM» es una parte de la memoria unificada que macOS permite fijar en memoria para la GPU. Esta parte es inferior a la RAM total. Las fuentes públicas no coinciden sobre la fracción predeterminada, que oscila entre dos tercios y tres cuartos según el caso; no la des por supuesta, consulta su valor en tu máquina. MLX muestra el valor establecido por el sistema mediante device_info(), en el campo max_recommended_working_set_size, y la documentación de MLX indica que se puede aumentar este límite del sistema con sudo sysctl iogpu.wired_limit_mb seguido del tamaño en megabytes.

El repositorio mlx-lm establece la regla de precaución: el valor debe superar el tamaño del modelo en megabytes, pero mantenerse por debajo de la memoria de la máquina. Apple no documenta este ajuste como un parámetro para el público general: trátalo como una modificación del sistema que conlleva riesgos.

La fórmula es simple: valor en MB = memoria deseada en GB × 1 024. La reserva es una medida de prudencia adoptada en esta guía, no un dato de Apple: depende de las aplicaciones que dejes abiertas. Si la máquina se ralentiza, escribe en el disco o se vuelve inestable, reduce el valor.

Para consultar el límite que macOS aplica realmente, basta con una línea de Python si el paquete mlx está instalado. La salida contiene el campo max_recommended_working_set_size, expresado en bytes: divide entre 1.073.741.824 para obtener gigabytes. Compara esa cifra con el tamaño de tu modelo antes de modificar cualquier ajuste: si el modelo ya cabe por debajo de ese límite, aumentarlo no aporta nada.

python3 -c "import mlx.core as mx; print(mx.device_info())"

1. 01
   Leer el valor actual

   En el Terminal, el comando sysctl iogpu.wired_limit_mb muestra el valor. Un cero indica generalmente que macOS aplica su límite predeterminado.
2. 02
   Calcular el nuevo valor

   Suma el tamaño del modelo y el de su caché KV, añade un margen y después deja al sistema una reserva de al menos 5 GB. Convierte el resultado a megabytes.
3. 03
   Aplicar el ajuste

   Ejecuta sudo sysctl iogpu.wired_limit_mb con el valor deseado. El ajuste se aplica sin reiniciar, según las guías publicadas.
4. 04
   Verificar

   Reinicia el modelo: los registros de Ollama o de llama.cpp indican la memoria de trabajo recomendada; con MLX, vuelve a leer device_info(). Monitorea la presión de memoria en el Monitor de actividad.
5. 05
   Volver atrás

   Vuelve a poner el valor a 0 para devolver el control al sistema, o reinicia: el ajuste no necesariamente se conserva tras un reinicio; compruébalo con sysctl.

# Lire la valeur actuelle (0 = plafond par défaut du système)
sysctl iogpu.wired_limit_mb

# Exemple : 24 Go au GPU sur un Mac de 32 Go (24 x 1024)
sudo sysctl iogpu.wired_limit_mb=24576

# Retour au comportement par défaut
sudo sysctl iogpu.wired_limit_mb=0

#¿Qué modelos según la memoria del Mac?

El peso de un modelo en Q4 sigue las cifras de referencia del sitio: 3B, aproximadamente 2 GB; 7-8B, aproximadamente 5 GB; 14B, aproximadamente 9 GB; 32B, aproximadamente 19 a 20 GB; 70B, aproximadamente 40 GB. A este peso se añaden el caché KV y el margen del sistema. La tabla cruza estas cifras de referencia con la memoria del Mac, antes y después de aumentar el límite de la GPU.

La velocidad máxima se calcula a partir del ancho de banda del chip: el ancho de banda dividido por el tamaño en gigabytes. Este dato se indica en la ficha de cada máquina: ver las guías de MacBook Air, MacBook Pro, Mac mini y Mac Studio, que incluyen las cifras del chip de cada uno.

Caso concreto: en un Mac de 32 GB, un modelo de 32 mil millones de parámetros en Q4 pesa aproximadamente entre 19 y 20 GB. Con un contexto de 8.000 tokens y una caché KV en f16, hay que contar con unos gigabytes más, es decir, unos 23 a 24 GB en total. Si el límite de memoria de la GPU por defecto es más bajo, parte del modelo pasa a la CPU y la velocidad cae: aumentar el límite a 24 o 26 GB soluciona el problema, siempre que se deje suficiente memoria para que el sistema funcione con holgura. Si la presión de memoria pasa a rojo, elige mejor un modelo de 24 mil millones de parámetros.

#Cuantización: por qué Q4 sigue siendo una buena opción por defecto en Mac

En un Mac, la generación está limitada por el ancho de banda de la memoria: un modelo más pequeño se lee más rápido. Por tanto, Q4_K_M sigue siendo la opción por defecto, con la mejor relación entre tamaño, velocidad y calidad. Q5_K_M y Q6_K reducen la velocidad unos pocos puntos porcentuales a cambio de una mejora modesta de calidad; Q8_0 casi duplica el tamaño de Q4 y, por tanto, reduce aproximadamente a la mitad la velocidad máxima. Los formatos MLX de 4 bits desempeñan el mismo papel en el ecosistema MLX. La guía sobre cuantización explica este equilibrio, sin necesidad de repetir aquí las cifras.

#Metal y atención flash

Los motores habituales aprovechan la GPU del Mac a través de Metal, sin necesidad de ajustes. Con Ollama, el comando ollama ps indica si el modelo está cargado en la GPU. La atención flash reduce la memoria utilizada por los contextos largos: Ollama la activa automáticamente cuando el motor y el hardware lo permiten, y la variable OLLAMA_FLASH_ATTENTION=1 fuerza su activación. En llama.cpp, la opción -fa acepta on, off o auto, con auto como valor por defecto; la opción -ngl fija el número de capas colocadas en la GPU.

# Ollama : forcer l'attention flash
export OLLAMA_FLASH_ATTENTION=1
ollama serve

# llama.cpp : toutes les couches sur le GPU, attention flash active
llama-server -m modele.gguf -ngl all -fa on -c 16384

#Caché KV: la parte de memoria que se olvida

El caché KV almacena, para cada token del contexto, vectores de cada capa. Su tamaño es dos veces el número de capas, multiplicado por el número de cabezas KV, por su dimensión, por la longitud del contexto y por los bytes por valor. Ejemplo puramente aritmético, con una arquitectura típica de 32 capas, 8 cabezas KV de dimensión 128 y un contexto de 32 000 tokens en f16: 2 × 32 × 8 × 128 × 32 000 × 2 bytes, es decir, aproximadamente 4,2 GB, además de los pesos. En q8_0, este caché se reduce aproximadamente a la mitad; en q4_0, aproximadamente a un cuarto, con una ligera pérdida de precisión.

Ollama aplica cuantización a la caché con la variable OLLAMA_KV_CACHE_TYPE (f16 por defecto); llama.cpp lo hace con la opción -ctk para las claves y -ctv para los valores. En un Mac de 32 GB que asigna 24 GB a la GPU, ahorrar unos gigabytes de caché marca la diferencia entre un contexto que no cabe en la memoria y uno que cabe holgadamente. Ollama también elige el contexto predeterminado según la memoria: 4.000 tokens con menos de 24 GiB.

# Ollama
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve

# llama.cpp
llama-server -m modele.gguf -ngl all -fa on -ctk q8_0 -ctv q8_0 -c 32768

#Ollama, LM Studio, llama.cpp o MLX

El repositorio mlx-lm presenta el paquete como una herramienta de generación de texto y fine-tuning de modelos en Apple Silicon, con soporte para modelos cuantizados. Para comparar las velocidades entre MLX y llama.cpp, la guía dedicada al tema sirve de referencia; esta página se limita a los ajustes comunes.

#Batería y modo de ahorro de energía

En un MacBook, la generación continua mantiene la GPU trabajando constantemente: la autonomía queda muy por debajo de la que Apple anuncia para la navegación web. Esta página no da una duración precisa por falta de una fuente; depende del modelo y de la carga. El modo de ahorro de energía de macOS reduce el rendimiento: resérvalo para los desplazamientos en los que la autonomía prima sobre la velocidad y conecta el equipo a la corriente para cualquier sesión larga.

• MLX frente a llama.cpp: comparativa de velocidades
• MacBook Pro M4 Pro y Max
• Mac Studio: hasta 512 GB
• Compilar llama.cpp con Metal
• Cuantizar la caché KV
• Calculadora de VRAM del sitio

• Fuente: repositorio mlx-lm (límite de memoria no paginable)
• Fuente: documentación MLX, set_wired_limit
• Fuente: preguntas frecuentes de Ollama, atención flash y caché KV
• Fuente: repositorio llama.cpp

#Preguntas frecuentes