LLM local en MacBook Pro: M4 Pro, RAM y benchmarks

El MacBook Pro representa la estación de trabajo portátil de referencia para la inferencia de inteligencia artificial local. Mientras que dispositivos ultracompactos como el iPhone o el MacBook Air destacan en asistencia de voz y modelos ligeros, ejecutar arquitecturas densas de 14B, 32B o 70B parámetros exige un ancho de banda de memoria masivo, amplios presupuestos de memoria unificada (UMA) y una disipación térmica sostenida. Los procesadores Apple Silicon de la gama MacBook Pro —desde el M4 base hasta el M4 Pro de alto rendimiento y el M4 Max de ancho de banda extremo— acortan la distancia entre la informática portátil y las estaciones de trabajo dedicadas. Sin embargo, ajustar modelos abiertos a tu configuración exacta requiere entender la física de la decodificación autorregresiva, los límites reales de memoria cableada en macOS y las diferencias arquitectónicas entre runtimes nativos en Swift y aplicaciones empaquetadas en Electron.

El cuello de botella del ancho de banda: por qué destaca el MacBook Pro

La ejecución de modelos de lenguaje se divide en dos fases computacionales muy distintas: el procesamiento del prompt (prefill) y la generación autorregresiva de tokens (decode). Mientras que el prefill se paraleliza en todos los núcleos de GPU disponibles para procesar las matrices de atención sobre la consulta inicial, la generación de tokens opera de forma estrictamente secuencial. Para emitir un solo token, el runtime debe cargar la totalidad de los pesos del modelo desde la memoria DRAM hasta los registros del procesador, realizar las operaciones aritméticas matriciales con el estado oculto actual y escribir las activaciones de clave y valor en la memoria.

Bajo el modelo de rendimiento Roofline, la decodificación autorregresiva presenta una intensidad operativa inferior a 1,0 FLOP por byte transferido. Como consecuencia directa, la velocidad de generación de tokens está limitada por el ancho de banda del bus de memoria y no por los teraflops brutos de cómputo. El rendimiento teórico de decodificación puede modelarse con precisión:

Rendimiento (tokens/s) ≈ (Ancho de banda efectivo de memoria en GB/s / Tamaño del modelo cuantizado en GB) × η

Donde η representa la eficiencia del controlador de memoria (típicamente entre el 72 % y el 82 % en Apple Silicon bajo Metal Shading Language). Esta realidad matemática explica por qué el ancho de banda del bus de memoria en la familia MacBook Pro determina directamente las capacidades de IA local:

• M4 base (bus de 128 bits): Ofrece aproximadamente 150 GB/s de ancho de banda en memoria unificada. Aunque resulta solvente para modelos de hasta 8B parámetros (~25 tok/s en Q4_K_M), los modelos superiores experimentan un cuello de botella evidente.
• M4 Pro (bus de 192 bits): Ofrece 273 GB/s de ancho de banda: un incremento del 82 % respecto al chip base. Esta arquitectura alcanza ~23 tok/s en modelos de 14B y supera los 40 tok/s en arquitecturas de 8B.
• M4 Max (bus de 384 o 512 bits): Proporciona 410 GB/s (en configuraciones con GPU de 32 núcleos) o 546 GB/s (en configuraciones con GPU de 40 núcleos). A 546 GB/s, las transferencias de memoria rivalizan con aceleradores de centro de datos, permitiendo que modelos de 32B generen a más de 22 tok/s y modelos de 70B alcancen ~10 tok/s.

Al comparar estas especificaciones con generaciones anteriores de Apple Silicon, el salto resulta determinante. El M3 Pro estaba limitado a 150 GB/s, mientras que el M4 Pro recupera canales de memoria de 192 bits de alto rendimiento. Para profesionales e investigadores que evalúan una inversión en hardware portátil, el ancho de banda de memoria es la variable primordial que define la fluidez de trabajo diario.

Para comprender la formulación física del modelo Roofline y la saturación del bus de DRAM, consulta nuestro análisis sobre ancho de banda en Apple Silicon para LLMs.

Matriz de dimensionamiento de RAM: configuraciones de 16 GB a 128 GB

A diferencia de las arquitecturas tradicionales de PC donde la tarjeta gráfica depende de memoria VRAM dedicada (a menudo limitada entre 8 GB y 24 GB) conectada por un bus PCIe con latencias elevadas, Apple Silicon implementa una Arquitectura de Memoria Unificada (UMA). La CPU, la GPU Metal y el Apple Neural Engine (ANE) acceden a un único espacio de memoria DRAM de baja latencia sin copias intermedias.

No obstante, ejecutar LLMs locales en macOS exige una planificación rigurosa de la memoria. A diferencia de iOS, que cierra procesos abruptamente cuando superan los umbrales de memoria anónima sucia mediante el demonio jetsam, macOS cuenta con un sistema de memoria virtual avanzado. Sin embargo, si el conjunto de trabajo de un modelo excede la memoria RAM física, macOS comienza a paginar los tensores hacia el disco SSD interno (memoria swap). La paginación degrada el rendimiento de decenas de tokens por segundo a fracciones de token por segundo, generando desgaste innecesario en el almacenamiento y saturación térmica.

Para garantizar una latencia predecible, los runtimes de alto rendimiento fijan los pesos del modelo y la caché de contexto KV en memoria cableada (wired memory o RAM física no paginable). Por defecto, macOS limita la memoria cableada que un proceso puede retener mediante el parámetro de kernel sysctl iogpu.wired_mem_limit a aproximadamente entre el 75 % y el 80 % del total instalado. El espacio restante queda reservado para el kernel de macOS, WindowServer, frameworks del sistema y aplicaciones del usuario.

Tal como reflejan las especificaciones técnicas del MacBook Pro, optar por 48 GB en el M4 Pro o entre 64 GB y 128 GB en el M4 Max transforma las posibilidades de cómputo local. Una configuración de 48 GB aloja holgadamente modelos de 32B parámetros junto a una ventana de contexto de 32.768 tokens, trasladando capacidades de investigación a un formato verdaderamente portátil.

Para calcular los requisitos exactos de memoria según la cuantización y la longitud de contexto, consulta nuestra guía de cuánta RAM necesita un LLM local.

Térmicas activas de doble turbina frente a estrangulamiento pasivo

Una de las diferencias técnicas más significativas entre ejecutar LLMs en un MacBook Air y un MacBook Pro radica en su arquitectura de disipación térmica. La inferencia autorregresiva continua y los bucles de razonamiento prolongados imponen cargas sostenidas sobre la GPU y los controladores de memoria durante decenas de minutos.

En equipos sin ventilador como el MacBook Air, el calor generado por el silicio se disipa exclusivamente por conducción pasiva hacia el chasis de aluminio. Al generar respuestas largas o indexar bibliotecas documentales, la temperatura del encapsulado asciende con rapidez. Tras 8 o 10 minutos de computación ininterrumpida, el chip alcanza entre 95 °C y 100 °C. Para preservar el hardware, el gestor térmico de macOS activa un estrangulamiento progresivo que reduce la frecuencia de la GPU entre un 25 % y un 35 %, degradando la velocidad de generación a medida que avanza la sesión.

El MacBook Pro incorpora un sistema de refrigeración activa diseñado para soportar cargas continuadas de computación. Tanto en los chasis de 14 como de 16 pulgadas, Apple integra dos ventiladores centrífugos de alto rendimiento conectados a caloductos y cámaras de vapor. El aire fresco entra por las toberas laterales, atraviesa los radiadores internos y se expulsa por la bisagra posterior.

En pruebas de inferencia ininterrumpida de 45 minutos ejecutando Qwen 2.5 32B en un M4 Pro, el sistema activo mantiene la temperatura del silicio estabilizada entre 78 °C y 84 °C. El nivel sonoro es prácticamente imperceptible durante consultas aisladas y se eleva de manera suave bajo cargas intensivas. Al mantenerse muy por debajo del umbral de estrangulamiento, los núcleos Metal conservan su frecuencia máxima de reloj (hasta 1,5 GHz en M4), garantizando que el token número 3.000 se genere exactamente a la misma velocidad que el primero.

Para contrastar el comportamiento de portátiles con refrigeración activa frente a la disipación pasiva de chasis delgados, lee nuestro análisis de LLM local en MacBook Air.

Benchmarks de modelos abiertos: desde 7B hasta 70B parámetros

Determinar qué modelo abierto encaja con tu MacBook Pro requiere evaluar la densidad de parámetros, la precisión de cuantización y el comportamiento real en Apple Silicon:

• Asistentes compactos (1,7B a 3B): Arquitecturas como SmolLM2 1,7B y Llama 3.2 3B requieren menos de 2,5 GB de memoria en 4 bits. En un chip M4 Pro, estos modelos generan entre 75 y 110 tokens por segundo. Su respuesta es instantánea, resultando ideales para transcripción de voz local, clasificación de texto y corrección gramatical interactiva.
• La clase estándar de 7B a 8B: Modelos como Qwen 2.5 7B y Mistral 7B representan el equilibrio idóneo para la productividad cotidiana. Ocupando entre 4,5 GB y 5,5 GB en Q4_K_M, alcanzan entre 35 y 40 tok/s en M4 Pro y hasta 75 tok/s en M4 Max. Gestionan resúmenes complejos, redacción y contexto conversacional multiturno sin comprometer la memoria del sistema.
• Herramientas avanzadas de 14B para código y razonamiento: Qwen 2.5 Coder 14B y DeepSeek-R1-Distill-Qwen-14B constituyen el punto óptimo para desarrolladores. Requiriendo entre 9,0 GB y 10,5 GB de memoria, generan a 22-25 tok/s en M4 Pro y 45-48 tok/s en M4 Max. Su precisión en generación de software y resolución matemática iguala a servicios cloud comerciales con total privacidad.
• Arquitecturas de razonamiento profundo de 32B: Qwen 2.5 32B y DeepSeek-R1-Distill-Qwen-32B ocupan unos 19,5 GB en cuantización de 4 bits. Al ejecutarse en equipos de 48 GB (M4 Pro) o 64 GB (M4 Max), alcanzan de 10 a 12 tok/s en M4 Pro y de 22 a 26 tok/s en M4 Max. Proporcionan razonamiento de vanguardia para auditoría de código y análisis contractual exhaustivo.
• Modelos de frontera de 70B: Llama 3.3 70B requiere cerca de 42 GB de memoria en 4 bits. Operando en sistemas M4 Max de 64 GB o 128 GB a velocidades de 10 a 12 tok/s, entrega capacidades equivalentes a modelos comerciales de referencia en un formato 100 % autónomo y sin conexión.

Más allá de la velocidad de generación token a token, la tasa de prefill es fundamental al trabajar con contextos amplios. Gracias al elevado número de núcleos de GPU en el M4 Max (hasta 40 núcleos), la tasa de ingesta supera los 600 tokens por segundo. Incluso al cargar documentos PDF extensos o archivos de código voluminosos, la primera palabra de la respuesta aparece en menos de dos segundos.

Para evaluar runtimes nativos en Swift frente a wrappers basados en Electron o demonios CLI, revisa nuestra guía sobre la mejor app de IA local para Mac.

Arquitectura del runtime: Swift y MLX nativos frente a Electron y demonios en C++

La potencia del hardware solo se traduce en productividad si la capa de software está bien optimizada. En macOS, la ejecución de IA local se divide en tres paradigmas fundamentales:

• Swift nativo y Apple MLX: El framework Apple MLX ha sido concebido desde cero para exprimir la memoria unificada de Apple Silicon y Metal Performance Shaders Graph. Al compilar los grafos de cálculo directamente en Swift, MLX realiza evaluaciones de tensores con cero copias intermedias. El runtime opera bajo el App Sandbox de macOS con un consumo en reposo inferior a 60 MB de RAM. Al concluir la respuesta, los buffers temporales se liberan de inmediato.
• Motores CLI en C++ (Ollama y llama.cpp): Desarrollados sobre núcleos de bajo nivel en C++ y Metal, herramientas como llama.cpp proporcionan un soporte sobresaliente para modelos en formato GGUF. Sin embargo, suelen funcionar como demonios en segundo plano escuchando en puertos locales. Aunque eficientes, mantienen contextos de Metal activos e hilos en reposo que pueden dificultar la entrada del portátil en estados de suspensión profunda.
• Aplicaciones de escritorio basadas en Electron: Diversos entornos gráficos integran motores en C++ dentro de un navegador Chromium y un runtime de Node.js. Esta arquitectura introduce una penalización inmediata de entre 800 MB y 1,5 GB de memoria RAM solo para dibujar la interfaz gráfica. Asimismo, serializar flujos de tokens a través de canales de comunicación entre procesos (IPC) añade latencia y acelera el consumo de batería.

Para quienes priorizan la autonomía en movilidad, inicios instantáneos y la seguridad del sistema operativo, las aplicaciones nativas en Swift representan la arquitectura más eficiente. Garantizan que cada megabyte de memoria unificada se dedique a los pesos del modelo y la caché KV, en lugar de a motores de renderizado web.

Para evaluar la alternativa de un nodo de sobremesa permanente accesible por red local, revisa el análisis de LLM local en Mac mini.

Rendimiento de batería, consumo energético y ajustes de producción

El MacBook Pro está pensado como estación de trabajo móvil, por lo que el comportamiento en batería resulta crucial. Apple Silicon mantiene sus frecuencias de reloj íntegras cuando se desconecta de la corriente alterna, pero el consumo en vatios define la autonomía operativa.

Bajo inferencia continua con un modelo de 14B en un M4 Pro, el consumo del silicio oscila entre 24W y 34W. En un M4 Max ejecutando modelos de 32B o 70B, la demanda puede situarse entre 45W y 65W. Considerando la batería de 72,4 vatios-hora en el modelo de 14 pulgadas y de 100 vatios-hora en el de 16 pulgadas, una sesión continua de decodificación ofrece entre 2,5 y 3,5 horas de trabajo ininterrumpido. En un flujo conversacional habitual —con peticiones espaciadas—, el MacBook Pro supera holgadamente la jornada laboral completa sin recarga.

Para exprimir al máximo tu MacBook Pro en flujos de IA local, ten en cuenta estas tres recomendaciones de ingeniería:

• Prevenir la suspensión de pantalla en procesos por lotes: Al procesar indexaciones documentales extensas o razonamientos que requieran varios minutos, las políticas de ahorro de energía de macOS pueden suspender el cómputo de la GPU. Emplea la utilidad de terminal caffeinate -d o aserciones de energía en tu software para mantener el procesamiento activo hasta completar la tarea.
• Cuantizar la caché de clave y valor (KV Cache): A medida que el contexto crece hasta 16.000 o 32.768 tokens, una caché KV sin comprimir en precisión FP16 puede consumir entre 4 GB y 8 GB de RAM al margen del modelo. Habilitar cuantización FP8 o INT4 en la caché reduce esta huella a la mitad con un impacto imperceptible en la perplejidad.
• Supervisar la memoria cableada: Revisa el estado de la memoria mediante el Monitor de Actividad o comandos de terminal (vm_stat y sysctl iogpu.wired_mem_limit). Verificar que la suma del modelo y la caché KV se mantiene bajo el límite de memoria cableada evita que macOS recurra al archivo de intercambio en disco, garantizando una latencia uniforme y fluida en cada interacción.

Si quieres trabajar con modelos que requieren más memoria, conoce Lapis para Mac y sus opciones de inferencia local.