Empieza con la memoria unificada de Apple, no con nombres de GPU
En macOS, el número de hardware más importante suele ser la memoria unificada. Apple Silicon comparte memoria entre CPU, GPU, sistema, apps y el runtime de inferencia local, así que un Mac de 16GB, 32GB, 64GB o 128GB no entrega toda esa memoria a los pesos del modelo. macOS, el navegador, las herramientas de desarrollo y el backend de inferencia también necesitan espacio. Esto es distinto de un escritorio Windows o Linux con una GPU discreta, donde la VRAM es un conjunto separado.
Para recomendaciones de Local LLM, esto significa que los usuarios de Mac no deberían comparar su cantidad de memoria directamente con la VRAM de un PC. Un Mac de 32GB puede ser muy capaz, pero aún necesita margen de memoria para KV cache y apps activas. Un Mac de 64GB o 128GB abre la puerta a modelos más grandes, mayor cuantización y contextos más largos, aunque el mejor resultado sigue dependiendo del caso de uso. Carga de código, escritura, RAG, roleplay y cargas de trabajo de visión pueden preferir modelos diferentes.
Elige la herramienta de macOS que encaje con tu flujo de trabajo
Ollama es un punto de partida sencillo cuando quieres un flujo de trabajo local de línea de comandos o una API local que otras apps puedan llamar. LM Studio es más amigable para usuarios que quieren un navegador gráfico de modelos, interfaz de chat, modo de servidor local y soporte para Apple Silicon en una sola app de escritorio. llama.cpp es más técnica, pero sigue siendo uno de los motores principales detrás de muchos flujos de inferencia local basados en GGUF e incluye rutas de optimización para Apple Silicon mediante Metal y frameworks relacionados.
No hay una única mejor herramienta para todos los usuarios de Mac. Si el objetivo es chat casual, LM Studio puede ser el camino más rápido. Si el objetivo es conectar un modelo local con otra app, Ollama o el modo servidor de LM Studio pueden encajar. Si el objetivo es probar archivos GGUF exactos, ajustes de contexto o flags de runtime de bajo nivel, llama.cpp ofrece más control. La recomendación de modelo debería dirigir primero a los usuarios hacia un modelo ejecutable y luego permitirles elegir la interfaz que prefieran.
MLX, Metal y GGUF son piezas diferentes de la pila
Los usuarios de Mac suelen ver MLX, Metal, GGUF y llama.cpp tratados juntos, pero no son lo mismo. Metal es el framework de GPU de Apple. MLX es un framework de machine learning orientado a Apple que algunas herramientas usan para modelos de Apple Silicon. GGUF es un formato de archivo de modelo usado comúnmente por inferencia de estilo llama.cpp. Un modelo puede ser atractivo en Hugging Face, pero aun así ser más fácil o más difícil de ejecutar según el formato y el runtime que elija el usuario.
Por eso Local LLM no debería limitarse a decir “este modelo es bueno”. Debería mostrar si la variante del modelo es práctica para uso local, cuánta memoria necesita y si la cuantización seleccionada deja suficiente margen. Un usuario de Mac con 16GB de memoria unificada puede preferir un modelo Q4 o Q5 más pequeño. Un Mac de 64GB puede considerar modelos más grandes, pero el contexto largo y las apps en segundo plano siguen afectando la estabilidad.
Niveles de memoria para Local LLMs en macOS
Con 8GB de memoria unificada, el uso de Local LLM debe ser muy conservador. Los modelos pequeños pueden funcionar para experimentar, pero el sistema tiene poco margen. Con 16GB, los modelos pequeños y algunos modelos cuantizados de clase 7B se vuelven más realistas. Con 24GB o 32GB, el chat local cotidiano, la asistencia de código y la resumición se vuelven más cómodos. Con 64GB o 128GB, los modelos más grandes, una mejor cuantización y contextos más largos se vuelven prácticos, aunque no automáticos.
La clave es evitar tratar el modelo más grande como el mejor modelo. Un modelo de código 14B que cabe con margen puede sentirse mejor que un modelo más grande que presiona constantemente la memoria. Un modelo pequeño de escritura puede ser suficiente para borradores. Un modelo de visión necesita componentes adicionales de procesamiento de imágenes. Local LLM debería filtrar primero por hardware, luego por caso de uso y después por preferencia de calidad.
Un flujo de configuración seguro en macOS
Un flujo de configuración seguro es simple: comprueba la memoria unificada, elige una herramienta local, empieza con un modelo que claramente quepa, prueba prompts cortos y luego aumenta el contexto o la calidad solo después de que la base sea estable. No empieces con el modelo más grande de una tabla de clasificación. No asumas que un modelo mostrado en un Mac de 128GB será cómodo en un MacBook Air de 16GB. Mantén suficiente memoria libre para el resto del sistema.
Para desarrolladores, los servidores de modelos locales normalmente deberían permanecer vinculados a localhost salvo que exista una razón deliberada para exponerlos en una red. Para usuarios normales, el camino más útil es elegir un modelo mediante Local LLM, abrir la página de Hugging Face para inspeccionar archivos y términos de licencia, y cargar el modelo en una herramienta que soporte el formato. Eso reduce descargas desperdiciadas y facilita la resolución de problemas.
FAQ
¿Puede un MacBook ejecutar un LLM local? Sí, especialmente los Mac con Apple Silicon, pero el tamaño del modelo y la cuantización deben ajustarse a la memoria unificada. 8GB es limitado, 16GB es nivel de entrada y 32GB o más es más cómodo.
¿La memoria unificada de Apple es lo mismo que VRAM? No. La comparten la CPU, GPU, macOS, apps y el runtime de inferencia. Puede ser potente, pero no está toda disponible para los pesos del modelo.
¿Debería usar Ollama o LM Studio en Mac? Ollama es cómodo para flujos de línea de comandos y API. LM Studio es cómodo para un navegador gráfico de modelos e interfaz de chat. llama.cpp es mejor para control avanzado.
¿Cómo debería elegir un modelo? Introduce la memoria de tu Mac, caso de uso y preferencia de calidad en Local LLM. La herramienta puede filtrar variantes de modelos actuales antes de que descargues archivos grandes.