1
Tamaño y capacidad — ¿qué hardware necesitas?
| Tamaño |
Parámetros |
RAM mínima |
Perfil típico |
Micro
1B–3B |
1 000–3 000 M |
4 GB |
Raspberry Pi, Macs viejos. Útil para tareas muy concretas: clasificar, resumir frases cortas. |
Pequeño
7B |
7 000 M |
8 GB |
El punto dulce para uso doméstico y para bots de conversación ligeros. Corre fluido en Mac M1/M2 con 8 GB. Conversación general, código básico. |
Mediano
13B–14B |
13 000–14 000 M |
16 GB |
Notablemente mejor en razonamiento. Mac M1/M2 con 16 GB, o PC con GPU de 16 GB VRAM. |
Grande
34B–70B |
34 000–70 000 M |
32–64 GB |
Mac Studio / Mac Pro, o servidor con GPU. Calidad cercana a GPT-3.5. Ideal para Mac Mini de gama Pro si tiene 32+ GB. |
Muy grande
+70B |
>70 000 M |
64–128 GB |
Solo para hardware muy potente. No práctico para un solo ordenador en local — ver la comparativa de hardware para clusters. |
* Con cuantización (Q4/Q8) los modelos pesan aproximadamente la mitad y caben en menos RAM con poca pérdida de calidad.
Novedad 2026
MoE (Mixture of Experts) — por qué un modelo "35B" puede ir más rápido que uno de "14B"
Los modelos más recomendados hoy (Qwen3.5, Qwen3.6-35B-A3B, Qwen3-Coder-30B-A3B) usan arquitectura MoE: internamente tienen muchos "expertos" pero solo activan una fracción en cada token. Qwen3.6-35B-A3B tiene 35 000 M de parámetros totales pero solo activa ~3 300 M por token — necesitas la RAM del modelo completo para tenerlo cargado, pero razona a la velocidad de un modelo mucho más pequeño (~130 t/s en hardware capaz, frente a los 20-35 t/s de un modelo denso de tamaño similar). Al mirar la ficha de un modelo MoE fíjate siempre en los dos números: parámetros totales (determina la RAM que necesitas) y parámetros activos (determina la velocidad que obtienes).
2
Familias principales — ¿quién hace qué?
Meta
Llama 3.x
La familia más usada en local. Open source real. Muy buen equilibrio calidad/tamaño. Base de muchos modelos derivados. Tamaños: 8B, 70B, 405B.
Mistral AI
Mistral / Mixtral
Franceses. Muy eficientes: el 7B rinde como un 13B de otras familias. Mixtral fue de los primeros en popularizar la arquitectura MoE (mezcla de expertos), muy rápido en inferencia.
Alibaba
Qwen 3.x
La familia que sustituyó a Qwen 2.5 como referencia en 2026. Excelente en código y español. Qwen3.6-35B-A3B (MoE) es el consenso como mejor generalista para Mac en 2026. Qwen3.8-27B (13 ago 2026, Apache 2.0) es denso y cabe en 24 GB. Qwen3.5 es nativo multimodal — texto, imágenes, documentos y vídeo en una arquitectura unificada. Qwen3-Coder-30B-A3B es la referencia para tareas de código.
Google
Gemma 2
Modelos ligeros de Google (2B, 9B, 27B). Optimizados para hardware consumer. Buenas instrucciones en español.
Microsoft
Phi-3 / Phi-4
Sorprendentemente capaces para su tamaño. El Phi-3 mini (3.8B) compite con modelos de 7B. Ideal para hardware muy limitado.
DeepSeek
DeepSeek R1 / V3
Chinos. Destacan en razonamiento y matemáticas — el patrón "piensa antes de responder" (tipo o1). Versiones destiladas (8B, 14B) corren en local con buenos resultados.
BSC
Salamandra 7B Instruct
Del Barcelona Supercomputing Center. Entrenado en español, catalán, inglés y francés, con énfasis en lenguaje médico y técnico. Buena opción cuando el caso de uso es dictado o redacción de informes en un contexto clínico/técnico en español — para conversación genérica un Qwen3 7B es más ligero y suficiente.
3
Mejores modelos para Apple Silicon (tu caso)
Recomendado — ligero, 7B
Qwen3 7B
~4 GB, vía MLX (Ollama 0.19+ ya lo usa automáticamente). Excelente español conversacional, ~35-65 t/s según hardware. El punto de entrada correcto para un bot de conversación (citas, soporte, recepción) — no necesita terminología especializada.
Recomendado — mejor generalista 2026
Qwen3.6-35B-A3B (MoE)
35B totales / 3.3B activos. Cabe en 32 GB. El consenso como mejor modelo de propósito general para Mac en 2026: calidad de un modelo grande, velocidad de uno pequeño (~130 t/s en hardware capaz).
Denso reciente — 27B
Qwen3.8-27B
Lanzado el 13 de agosto de 2026, licencia Apache 2.0. ~18 GB en 4-bit, mínimo 24 GB de RAM. Buena opción cuando prefieres un modelo denso (sin las particularidades de MoE) en gama media.
Para código
Qwen3-Coder-30B-A3B
MoE, 30B totales / 3.3B activos → muy rápido. SWE-bench Verified ~58.7% (Claude Sonnet 4.6: ~65%, brecha del 10%). Para tareas de desarrollo bien definidas la diferencia práctica es poco perceptible; para sesiones largas con contexto complejo, un modelo cloud como Sonnet sigue rindiendo más.
Si tienes 48+ GB
Llama 3.3 70B (Q4)
Con cuantización Q4 cabe en ~38 GB de RAM unificada. Calidad equivalente a GPT-4o mini. La opción de máxima calidad densa cuando no quieres depender de MoE.
Multimodal
Qwen3.5 / Qwen2-VL
Qwen3.5 es nativo multimodal (texto, imagen, documentos, vídeo en una sola arquitectura). Qwen2-VL 7B sigue siendo una alternativa ligera y capaz en local. Base razonable para un modelo especializado en imagen clínica (radiografías, fotos intraorales).
4
Herramientas para instalarlos
Ollama
Lo más sencillo. Un comando y corre. ollama run qwen3:7b. Desde la versión 0.19 (marzo 2026) usa MLX automáticamente en Apple Silicon — mejoras de hasta un 93% en velocidad, sin configurar nada a mano. Expone una API local compatible con OpenAI en localhost:11434/v1, ideal para integrarlo en microservicios Python.
LM Studio
Interfaz gráfica. Descarga modelos desde HuggingFace, los prueba, y expone una API local. Perfecto para explorar sin tocar la terminal.
MLX (Apple)
Framework de Apple optimizado para Silicon. Es lo que Ollama usa por debajo desde la 0.19. Máximo rendimiento en Mac; usarlo de forma nativa (sin Ollama) da más control pero es más técnico.
💡 Patrón de desarrollo recomendado: programa contra la API de Anthropic (LLM_BASE_URL=https://api.anthropic.com) y, cuando el hardware local esté listo, cambia una sola variable de entorno a http://localhost:11434/v1 — Ollama expone una API compatible con OpenAI, así que el código de la aplicación no cambia. Conviene escribir los prompts con instrucciones explícitas desde el principio: un modelo cloud grande adivina bien intenciones vagas, un modelo local de 7B necesita más precisión.
5
Arquitectura de producción — LLM + base de datos
Regla crítica
El LLM y el servidor de base de datos, nunca en el mismo host
En Apple Silicon, CPU y GPU comparten el mismo pool de memoria unificada y el mismo bus interno. Un servidor de base de datos (acceso secuencial, CPU-bound — por ejemplo FileMaker Server) y un LLM (throughput intensivo, GPU-bound) compiten por ese mismo ancho de banda: ambos se ralentizan, y no hay forma de aislarlos dentro de un solo equipo. En producción, la solución es siempre dos hosts en la misma red local — uno para la base de datos, otro para el LLM — que se comunican entre sí por LAN.
| Conversaciones simultáneas en un nodo | Velocidad aprox. | Tiempo de respuesta |
|---|
| 1 | ~130 t/s | ~2 s |
| 2 | ~65 t/s | ~4 s |
| 3 | ~43 t/s | ~6 s |
| 4 | ~32 t/s | ~8 s |
* Ejemplo real con un modelo de 7B en un nodo Apple Silicon de gama Pro atendiendo un chat tipo WhatsApp. Un solo proceso de modelo atiende las peticiones en serie: más conversaciones a la vez reparten el mismo ancho de banda. Para atender varios clientes o servicios en paralelo sin esta degradación, la solución es añadir nodos independientes (uno por servicio o grupo de usuarios) detrás de un balanceador (por ejemplo Nginx) — no un modelo más grande en el mismo nodo, y desde luego no un cluster: un cluster reparte un único modelo grande entre varias máquinas para que quepa en memoria, pero sigue atendiendo una petición cada vez.
⚠️ No confundir ambos escenarios: Thunderbolt 5 con RDMA solo hace falta para el cluster (varias máquinas compartiendo memoria para alojar un único modelo enorme). Los nodos independientes de un balanceador no necesitan ningún cable especial entre sí — se conectan por Ethernet/LAN normal, cada uno con su propio modelo cargado, y el balanceador reparte el tráfico. Si tu modelo cabe en un solo equipo (como un 7B para un bot de conversación), escalar tráfico es tan simple como añadir otro equipo igual a la misma red.
A muy alta concurrencia (decenas de peticiones simultáneas en un mismo nodo), la memoria compartida de Apple Silicon deja de ser la mejor opción: GPUs dedicadas con memoria separada (por ejemplo NVIDIA RTX en servidores Linux) escalan mejor porque cada dominio de memoria tiene su propio ancho de banda dedicado. Para uso personal, de un solo usuario, o de pequeños grupos — el caso típico de una clínica o una pyme — Apple Silicon sigue siendo la opción más eficiente, silenciosa y sencilla de mantener.
