El estado del LLM local en 2026¶
9 minutos de lectura · 3 mayo 2026
A finales de 2024 escribí que ejecutar un LLM en local era "técnicamente posible, prácticamente miserable". Año y medio después, la frase se ha quedado obsoleta por la mitad. Sigue siendo técnicamente posible. Ya no es miserable.
Un Mac mini M4 Pro con 64 GB corre hoy modelos que en 2023 requerían un cluster.
Lo que sigue es lo que probé personalmente entre febrero y abril de 2026. Sin afiliaciones, sin sponsors.
Lo que ha cambiado de verdad¶
Tres cosas, en orden de impacto:
- Cuantización 4-bit deja de doler. Los modelos de 30-70B parámetros corren con calidad indistinguible del FP16 para el 90% de las tareas que les pido (resumir, refactor, draft de texto). El otro 10% son tareas de razonamiento largo donde sí se nota.
- Memoria unificada en Apple Silicon escala. 96 GB en un M3 Max te dan más VRAM efectiva que cualquier consumer GPU. La latencia ya no es el bottleneck.
- Runtime maduro.
llama.cpp,ollamaylmstudiose han estabilizado en formato (GGUF) y API. Cambiar de modelo esollama pull qwen2.5:32by nada más.
Mi setup ahora mismo¶
| Pieza | Qué uso | Por qué |
|---|---|---|
| Hardware | Mac Studio M3 Ultra, 192 GB | Memoria unificada absurda; ruido cero |
| Runtime | Ollama | Tres comandos, vida tranquila |
| Modelo daily | qwen2.5-coder:32b-q4 |
Mejor coding model open en mi prueba |
| Modelo razonamiento | deepseek-r1:70b-q4 |
Chain-of-thought serio, 25 tok/s |
| Cliente | mods (CLI) + Continue (VS Code) |
Sin GUI pesada |
Lo que no uso:
- Web UI tipo open-webui. Añade fricción para el caso CLI/IDE.
- Modelos de 405B+. Mi caso de uso no justifica el coste.
- Embeddings locales (de momento). El RAG sigue siendo más barato en cloud.
Para qué sirve hoy y para qué no¶
Sirve sin discusión:
- Refactor mecánico de código (renombrar, extraer función, traducir entre lenguajes).
- Primer draft de tests sobre función existente.
- Resumir documentos largos que no quiero subir a un servicio.
- Brainstorming en off-line (avión, sitio sin conexión).
- Editar textos en español sin enviar a un tercero.
No sirve todavía, en mi experiencia:
- Tareas que requieren contexto del repositorio entero. Sin tooling tipo Cursor / Claude Projects local, sigue siendo torpe.
- Razonamiento de varios pasos sobre código complejo. R1 ayuda, pero no llega.
- Generación creativa larga (>2000 palabras coherentes).
El argumento real para tenerlo¶
No es el coste. Por mi volumen, una suscripción cloud sale más barata que la electricidad y el hardware.
Es privacidad y disponibilidad. Hay cosas que no quiero mandar a un tercero: contratos, conversaciones con cliente, código bajo NDA. Tenerlo local resuelve el problema sin pensarlo. Y cuando vuelo o cuando una API se cae, sigo trabajando.
Lo que viene¶
Lo que veo en el horizonte 2026:
- Modelos de 7B con calidad de 70B del año pasado. La compresión semántica avanza más rápido que el hardware.
- MoE local viable. Mixtral y Qwen MoE empiezan a correr decentemente en consumer.
- Tooling estandarizado. Algo tipo MCP (Model Context Protocol) generalizado para que el LLM local hable con tu sistema de notas, tu editor y tu shell sin pegamento custom.
Si las tres se cumplen, en 2027 el LLM local deja de ser una opción técnica y pasa a ser la opción por defecto. No para todos los casos. Para más casos.
Próxima entrada
Mi configuración exacta de Continue + Ollama para que el code completion local no sea una experiencia frustrante. En la siguiente entrega.
¿Comentarios o correcciones? info@encodigo.es.