LLMs locales en macOS: Ollama, LM Studio, MLX y llama.cpp

Viacheslav Dubrov

2025-05-10 · Actualizado 2026-08-10 · 7 min · Ingeniería de modelos · Herramientas de desarrollo

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Los ingenieros que ejecutan modelos locales en un Mac con Apple Silicon deben dimensionar la carga de trabajo completa, no limitarse a elegir un modelo que se pueda descargar. Apple Silicon puede ejecutar prompts cotidianos sin una API remota porque la CPU y la GPU comparten un pool de memoria unificada, pero los pesos del modelo compiten por él con el KV cache, el espacio de trabajo del runtime y macOS.

Cuando el modelo, el contexto y el margen de memoria previstos caben, elige la interfaz de control que encaje con el flujo de trabajo: Ollama para un servicio local gestionado, LM Studio para inspección desde el escritorio, llama.cpp para ejecutar GGUF directamente o MLX-LM para Python nativo de Apple. Así mantendrás separadas las pruebas de calidad del modelo y la elección de la herramienta, y obtendrás un benchmark justo y consciente del uso de memoria para el stack que vayas a ejecutar.

TL;DR. Usa Ollama para un servicio local gestionado, LM Studio para explorar modelos desde el escritorio y acceder a sus APIs locales, llama.cpp para controlar directamente la ejecución de GGUF y MLX-LM para experimentar con Python nativo de Apple. Ninguna opción es universalmente más rápida. Haz un benchmark con el modelo, la cuantización, el contexto y la carga de trabajo exactos, dejando margen de memoria.

Consulta la tabla de decisión resumida en Herramientas para LLMs locales en macOS en 2026.

Empieza por un presupuesto de memoria

El tamaño bruto de los pesos cuantizados es solo el primer término:

peak memory ≈ model weights
            + KV cache
            + runtime workspace
            + multimodal components
            + application and OS memory

La longitud del contexto, el tipo de datos de la caché, las solicitudes en paralelo y la arquitectura del modelo cambian el resultado. Un modelo nominal de 7B u 8B a cuatro bits puede seguir funcionando con dificultad en un Mac de 8 GB, porque el sistema operativo no puede entregar toda la memoria instalada al runtime.

Usa Monitor de Actividad o las métricas del propio runtime durante las pruebas. Apple define la presión de memoria mediante la memoria libre, la tasa de swap, la memoria cableada y los archivos en caché. Deja suficiente margen para evitar un uso sostenido de swap; un modelo que carga, pero provoca presión de memoria en el sistema, no es una buena opción para uso interactivo.

También debes separar la inferencia local del funcionamiento sin conexión. Los prompts pueden permanecer en el equipo mientras la aplicación sigue accediendo a la red para descargar modelos, instalar actualizaciones o utilizar funciones opcionales. Ollama documenta por separado la ejecución local, las descargas de modelos y las funciones opcionales en la FAQ. Trata el funcionamiento sin conexión como un requisito del flujo de trabajo que debes verificar para cada aplicación: descarga primero los artefactos, desconecta la red y prueba el flujo completo.

Las cuatro herramientas resuelven problemas distintos del flujo de trabajo

Esta es una tabla de responsabilidades, no una clasificación de velocidad. Varias herramientas pueden usar kernels o formatos relacionados, y el rendimiento cambia según la compatibilidad del modelo y la versión.

Ollama: servicio local gestionado

Ollama gestiona las descargas de modelos, las plantillas, el ciclo de vida de los procesos y una API en localhost. Resulta útil cuando el código de la aplicación debe dirigirse a un servicio local estable en lugar de gestionar sus propios flags de inferencia.

MODEL=llama3.2
ollama pull "$MODEL"
ollama run "$MODEL" "Explain unified memory."

curl http://localhost:11434/api/chat \
    -H 'Content-Type: application/json' \
    -d '{
      "model": "'"$MODEL"'",
      "messages": [{"role": "user", "content": "Explain unified memory."}],
      "stream": false
    }'

Inspecciona el manifest del modelo y la configuración del contexto, en lugar de asumir que un nombre corto de la biblioteca identifica un checkpoint inmutable. Fija o registra el artefacto exacto para las evaluaciones.

Ollama sacrifica parte de la visibilidad de bajo nivel a cambio de simplificar la gestión del ciclo de vida. Pasa a llama.cpp u otro runtime cuando necesites controlar directamente un archivo GGUF, una plantilla de chat, la configuración de la caché o una función nueva del backend.

LM Studio: exploración desde el escritorio y APIs locales

LM Studio resulta útil cuando el descubrimiento de modelos, la configuración de carga, la inspección del chat y la evaluación humana en paralelo forman parte del mismo flujo de trabajo. Ahora ofrece SDKs nativos de Python y TypeScript, endpoints compatibles con OpenAI, structured output, tool use y un daemon headless, por lo que ya no es solo una GUI de escritorio.

El SDK de Python actual se conecta a un modelo que ya hayas descargado:

import lmstudio as lms

MODEL_KEY = "ibm/granite-4-micro"

with lms.Client() as client:
    model = client.llm.model(MODEL_KEY)
    response = model.respond("Write one sentence about local inference.")
    print(response)

Inicia la API local desde la pestaña Developer o con:

lms server start

LM Studio puede servir modelos en localhost o en una red local y admite tokens de API en sus ajustes de autenticación de la API. Mantenlo en loopback salvo que el acceso remoto sea deliberado. Si lo expones en una LAN, exige la opción de API-token documentada, aplica una regla de firewall en el host y revisa el acceso a herramientas e integraciones.

llama.cpp: ejecución directa de GGUF

llama.cpp es la opción de referencia cuando el artefacto es GGUF y quieres observar directamente los límites del runtime. Admite Apple Metal, además de CPU y otros backends de hardware.

brew install llama.cpp

# Download through the Hugging Face integration and select a quantization.
MODEL_REPO=ggml-org/gemma-3-1b-it-GGUF
QUANT=Q4_K_M
llama-cli -hf "$MODEL_REPO:$QUANT"

# Or start an OpenAI-compatible local server.
llama-server -hf "$MODEL_REPO:$QUANT"

La ruta actual -hf del repositorio puede descargar un proyector multimodal compatible cuando está disponible. La compatibilidad de modelos, las plantillas y los flags de la CLI cambian con rapidez; fija una build conocida y conserva el comando de lanzamiento junto con el registro de evaluación.

Elige llama.cpp cuando el objetivo sea el control directo, no porque «de bajo nivel» signifique automáticamente más rápido. Una herramienta gestionada puede escoger buenos valores predeterminados; los flags directos también pueden empeorar el rendimiento.

MLX-LM: desarrollo en Python nativo de Apple

MLX-LM se basa en el framework de arrays MLX de Apple. Admite generación, chat, conversión, cuantización y fine-tuning eficiente en parámetros para modelos compatibles.

MODEL=mlx-community/Llama-3.2-3B-Instruct-4bit
uv add mlx-lm
uv run mlx_lm.generate \
    --model "$MODEL" \
    --prompt "Explain Metal acceleration in one paragraph."

Python expone directamente el modelo y el tokenizer:

from mlx_lm import generate, load

MODEL = "mlx-community/Llama-3.2-3B-Instruct-4bit"

model, tokenizer = load(MODEL)
messages = [{"role": "user", "content": "Give one local-LLM benchmark rule."}]
prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)
print(generate(model, tokenizer, prompt=prompt, max_tokens=80))

El servidor HTTP de MLX-LM está documentado como un servidor de desarrollo con comprobaciones de seguridad básicas, no como un servicio de producción. Úsalo para experimentar localmente o coloca delante un límite de aplicación revisado.

Un benchmark justo requiere menos tiempo que una mala descarga

Prueba la misma familia de checkpoints y una cuantización comparable cuando los formatos lo permitan. Usa un conjunto pequeño de prompts que incluya:

• un prompt interactivo corto
• un prompt largo cercano al contexto previsto
• structured output o tool calls si la aplicación los necesita
• una longitud de generación representativa
• una solicitud repetida para distinguir la carga en frío de la inferencia en caliente

Registra:

No compares el modelo de 4 bits de una herramienta con el modelo en precisión completa de otra y atribuyas la diferencia al runtime.

Lista de comprobación de seguridad y privacidad

1. Vincula las APIs a loopback salvo que necesites acceso desde la red.
2. Si necesitas acceso desde una LAN, usa un firewall en el host y la autenticación documentada por la herramienta o un reverse proxy autenticado delante del servicio. La compatibilidad con API tokens depende de la herramienta: LM Studio documenta los tokens de API, mientras que la ruta de exposición documentada por Ollama utiliza el binding del host y el proxy.
3. Trata los archivos de modelos como artefactos de terceros; registra el origen, la revisión, la licencia y el hash.
4. Evita ejecutar código personalizado de modelos que no hayas revisado.
5. Confirma si las funciones opcionales de documentos, herramientas, actualizaciones o analítica realizan llamadas de red.
6. No asumas que la generación local hace seguros los documentos recuperados, los logs o los efectos secundarios de las herramientas.

Conclusiones clave

1. Elige primero el límite del flujo de trabajo: servicio gestionado, desarrollo de escritorio y headless, control directo de GGUF o Python nativo de Apple.
2. Tanto Ollama como LM Studio exponen APIs locales. Compara el control del ciclo de vida, los SDKs, el structured output, las herramientas y la visibilidad del runtime.
3. Los pesos del modelo son solo una parte del presupuesto de memoria. Incluye el KV cache, el espacio de trabajo, los componentes multimodales, la aplicación y el margen necesario para macOS.
4. La inferencia local no es automáticamente offline ni privada. Verifica las llamadas de red, el binding, la autenticación, los artefactos, los logs y los efectos secundarios de las herramientas.
5. Haz un benchmark con la misma tarea, familia de checkpoints, contexto y cuantización comparable antes de atribuir un resultado al runtime.

Referencias

• Documentación y código fuente de Ollama
• Documentación para desarrolladores de LM Studio y SDK de Python
• Documentación y código fuente de llama.cpp
• Documentación y código fuente de MLX-LM
• Documentación de Apple MLX