Herramientas de LLMs locales en macOS en 2026: Ollama frente a LM Studio
Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Las herramientas de LLMs locales en macOS cubren cuatro necesidades distintas: ejecutar una API, explorar modelos, controlar los ajustes de inferencia y experimentar directamente en Apple Silicon. Tanto Ollama como LM Studio ofrecen ahora APIs locales, por lo que la elección ya no es «API frente a GUI». Compara cuánto control sobre el ciclo de vida, los modelos y el runtime necesita cada flujo de trabajo.
Una configuración práctica utiliza Ollama para un servicio gestionado pequeño, o LM Studio cuando quieres reunir en un mismo producto la exploración de modelos, los SDKs, los structured outputs y un daemon headless. Elige llama.cpp cuando necesites control directo sobre la ejecución de GGUF. Elige MLX-LM para experimentar con Python de forma nativa en Apple y hacer fine-tuning.
Última revisión: 10/08/2026. Criterios de selección: interfaz, formato de artefactos, control del runtime, automatización, margen de memoria y exposición de red.
Tabla de recomendaciones
| Herramienta | Destaca en | Úsala cuando | Principal contrapartida |
|---|---|---|---|
| Ollama | Servicio local gestionado y ciclo de vida de modelos | Quieres disponer rápidamente de un endpoint pequeño y scriptable | Menos control de bajo nivel que llama.cpp. |
| LM Studio | Descubrimiento de modelos, SDKs, daemon y servidores locales | Quieres un único entorno de desarrollo de escritorio y headless | Su abstracción sigue ocultando algunos detalles del runtime. |
| llama.cpp | Inferencia con GGUF, cuantización, flags del servidor y control de Metal | Necesitas controlar el contexto, el batch, la cuantización y el comportamiento del runtime | Requiere más configuración y más flags. |
| MLX-LM | Generación y fine-tuning nativos en Apple Silicon | Quieres experimentar a nivel de Python en Macs con chips de la serie M | Ecosistema de serving más pequeño que el de Ollama o llama.cpp. |
¿Cuál deberías instalar primero?
Instala primero Ollama si estás desarrollando software. Muchas aplicaciones saben comunicarse con él y su API local basta para prototipos, pruebas y pequeñas herramientas internas. Es el camino más corto entre «necesito un modelo local» y «mi aplicación puede llamar a un modelo local».
Instala primero LM Studio si estás eligiendo un modelo o quieres sus SDKs de Python y TypeScript, APIs locales, structured outputs, tool use y daemon headless. Permite pasar de la comparación interactiva a un servicio basado en scripts sin cambiar de producto.
Instala primero llama.cpp si te importa entender los mecanismos de la inferencia. La longitud de contexto, la cuantización, los flags de Metal, el procesamiento del prompt, los tamaños de batch y el comportamiento del servidor son más fáciles de inspeccionar cuando trabajas más cerca del runtime.
Usa MLX-LM cuando quieras hacer algo más que servir un modelo conversacional. Encaja con experimentos de modelos nativos en Apple Silicon, conversión, fine-tuning y flujos de trabajo en Python en los que la memoria unificada forma parte del diseño.
Matriz de flujos de trabajo
| Flujo de trabajo | Opción predeterminada | Motivo |
|---|---|---|
| API local para una aplicación | Ollama | Buena ergonomía para desarrolladores y amplio soporte de integración. |
| Comparación manual de modelos | LM Studio | La GUI agiliza la comparación de prompts y modelos. |
| Depuración del rendimiento | llama.cpp | Puedes ver y controlar los parámetros del runtime. |
| Serving de modelos GGUF cuantizados | llama.cpp u Ollama | Usa llama.cpp para tener control y Ollama por comodidad. |
| Experimentos con modelos en Apple Silicon | MLX-LM | Herramientas de modelos nativas para Macs con chips de la serie M. |
| Demo para perfiles no técnicos | LM Studio | Es fácil mostrarlo y ajustarlo de forma interactiva. |
| Configuración de ingeniería reproducible | Ollama más una lista de modelos fijada | Es más fácil crear scripts que en un flujo basado solo en una GUI. |
Notas sobre el hardware
La memoria unificada es la verdadera limitación de Apple Silicon. Un modelo que cabe en un MacBook Pro de 64 GB puede resultar inutilizable en un MacBook Air de 8 GB. La cuantización ayuda, pero la longitud de contexto puede dominar silenciosamente el consumo de memoria. Haz benchmark con la forma real de los prompts en lugar de fijarte únicamente en el nombre del modelo.
Para herramientas locales pequeñas, un modelo de la clase 7B u 8B suele ser más útil que un modelo grande sobrecargado. En coding, el contexto largo y la integración con herramientas pueden importar más que la posición en un benchmark general. En QA sobre documentos, la calidad de la recuperación suele pesar más que la elección del modelo local.
Qué no debes hacer
No conviertas la configuración de un LLM local en un proyecto de benchmarks permanente, salvo que el rendimiento sea el producto. Empieza con Ollama o LM Studio. Comprueba que la inferencia local aporta valor. Después, pasa a llama.cpp o MLX cuando tengas un motivo concreto.
No compares modelos únicamente en una interfaz de chat si la carga real consiste en extracción estructurada, edición de código o síntesis de respuestas con RAG. Escribe un pequeño script de evaluación con prompts representativos.
Lecturas recomendadas
- LLMs locales en macOS explica la configuración práctica.
- Variantes de LLMs con pesos abiertos explica GGUF, GPTQ, AWQ, los modelos base y los modelos instruct.
- Configuración de un MacBook para ingeniería de AI cubre la configuración general de la estación de trabajo.