IA local en Mac: lo que cabe en 16 GB sin mentirte

Un MacBook de 16 GB no es una workstation. Es un teléfono con delirios de grandeza. Y aun así, una parte significativa de la “IA local” es genuinamente útil en él — si dejas de fingir que vas a correr modelos frontier sin conexión.

Este es el mapa que tengo a mano. Nada es teórico; todo es lo que de verdad uso en mi propia máquina.

Lo que 16 GB te dan en realidad

De esos 16 GB, macOS, Chrome y Slack se zampan alegremente 6–8 GB antes de que abras una terminal. Así que tu “presupuesto de modelo” útil ronda los 8 GB de memoria. A partir de ahí, la máquina empieza a hacer swap, y Apple Silicon hace swap silenciosamente hasta que deja de hacerlo.

Ese presupuesto se traduce en:

• Hasta ~7 B de parámetros con cuantización de 4 bits (Q4_K_M GGUF, MLX 4-bit). Cómodo. Ágil.
• 8 B a 4 bits si cierras todo lo demás. Posible. Algo tenso.
• 13 B a 4 bits solo si cierras de verdad todo. No es el daily driver.
• Cualquier cosa ≥ 30 B: API. Siempre. Deja de engañarte.

Dos stacks que conviene conocer

Ollama es el primero que recomiendo instalar. Es brew install ollama, después ollama run llama3.1:8b. Elige la cuantización por ti, gestiona el almacenamiento de modelos, expone una API en localhost y nunca te pide pensar en CUDA. El coste: es algo más lento que el óptimo por plataforma, porque abstrae el sustrato. Para el 90 % de los casos “quiero un modelo local que me redacte esto”, está bien.

MLX es el framework de machine-learning de Apple. Es más rápido en Apple Silicon que cualquier otra cosa, porque habla Metal nativamente y usa la memoria unificada como debería usarse. El coste: más setup, menos modelos, más aristas. Merece la pena cuando el modelo es tu cuello de botella (cargas reales de inferencia, fine-tuning de modelos pequeños en local) — sobra cuando el cuello eres tú.

Por defecto, Ollama; tira de MLX cuando la métrica sea el vatímetro.

Tres flujos que sí funcionan en 16 GB

1. Redactar y reescribir. Un modelo local 7B es excelente para “haz que este párrafo suene menos corporativo” o “resume estas 800 líneas de changelog en release notes”. La calidad es suficiente; la latencia es humana; nada sale de la máquina.
2. Recuperación local sobre tu propio código/notas. Un modelo 7B + un embedder pequeño (nomic-embed-text o bge-small) corriendo en local es suficiente para “dado mi carpeta de notas, ¿qué escribí sobre X?”. Combínalo con un mini CLI propio; no te molestes con una vector DB, SQLite + similitud coseno basta a esta escala.
3. Routing por privacidad. Usa un modelo local como primer modelo. Si el usuario pide “reescribe este párrafo”, lo resuelve el local. Si pide “diseña esta base de datos”, se enruta a Claude. El local es un router y una frontera de privacidad, no un sustituto.

Tres flujos que silenciosamente no funcionan

1. “Agente local que hace mi trabajo”. Un 7B no es Claude. El bucle de agente se desmorona porque el tool-use del modelo es mediocre y la ventana de contexto pequeña. No persigas esto. Usa un modelo hospedado con ventana larga.
2. Resúmenes de documentos muy largos. Un 8B local con 32k de contexto técnicamente corre, pero la calidad cae rápido pasados los 8k tokens. Para PDFs de 200 páginas, hospedado.
3. Generación de imagen/vídeo (más allá de SDXL básico). Posible, pero el ratio resultado-por-vatio es tan peor que un endpoint hospedado que deja de ser hobby y se convierte en estufa.

---

La lectura honesta: 16 GB son suficientes para que la IA local sea una capa tranquila, privada y rápida de tu día — y un mal sustituto de un modelo frontier. Úsala para lo que hace bien (drafts, routing, recuperación), paga por el resto y deja de leer benchmarks de modelos de 70B que no puedes correr.