LM Studio y Qwen: cómo se defienden los LLM locales programando en un MacBook M4 Pro

Los modelos de lenguaje locales ya se pueden usar para escribir y editar código sin enviar el código fuente a la nube, pero la comodidad depende todavía mucho de la tarea y del margen de hardware. Un experimento en un MacBook Pro con M4 Pro y 48 GB de memoria muestra que la combinación de LM Studio y modelos modernos de pesos abiertos ya da un resultado sólido en modo chat, pero con agentes completos choca enseguida con la memoria, el calor y el tiempo de ejecución. El punto de partida es sencillo: los modelos en la nube son cómodos, pero tienen límites, dependen de la red y, el mayor inconveniente para muchos desarrolladores, los datos, el código y los prompts salen hacia servidores remotos.

La ejecución local promete privacidad y control total, pero exige entender cómo consume el modelo la RAM y la VRAM, cuánta memoria queda para el contexto y en qué se diferencian formatos como GGUF y MLX. Las pruebas se hicieron en un MacBook Pro con chip M4 Pro y 48 GB de memoria unificada, donde la CPU y la GPU comparten un único conjunto de memoria. Eso ayuda a alojar modelos más grandes, pero a la vez significa que el modelo compite por recursos con el IDE, Docker y decenas de pestañas del navegador.

Una parte aparte del análisis trata de elegir el modelo según el hardware. El autor aconseja fijarse no solo en el tamaño en miles de millones de parámetros, sino también en la especialización, la cuantización, el soporte de function calling y el tipo de arquitectura. Para programar tomó Qwen3-Coder 30B A3B Instruct en variantes MLX y GGUF, y la comparó con Qwen3-Coder Next, Qwen3.

5, Nvidia Nemotron-3 Nano y Gemma 4 26B A4B. El artículo explica bien el sentido práctico de las siglas: por ejemplo, A3B indica un enfoque MoE, en el que de un modelo grande solo se activa una parte de los parámetros, de modo que la velocidad se acerca a la de los modelos pequeños y la calidad a la de los grandes. Como entorno de ejecución se eligió LM Studio: permite descargar el modelo, levantar un servidor local, activar CORS y conectar agentes como Claude Code, Open Code, Kilo Code y Aider.

La previsión de rendimiento para Qwen3-Coder prometía unos 150 tokens por segundo, pero la medición real en LM Studio quedó más cerca de 82 tokens por segundo, lo que devuelve de inmediato la conversación de la teoría a la práctica.

Lo más interesante empieza con las mediciones. En modo chat normal, los modelos locales ya no parecen un juguete, sino un compromiso de trabajo. Qwen3-Coder 30B A3B Instruct en MLX 4bit completó todo el escenario de tres etapas en unos 2 minutos 9 segundos y llegó a una nota final de 8,5 sobre 10.

Gemma 4 26B A4B en GGUF mostró uno de los mejores equilibrios: unos 2 minutos 23 segundos y un 10 sobre 10 final. Los modelos que razonan más dieron mejor resultado, pero a costa de tiempo: Qwen3.5 35B A3B llegó a 10 sobre 10 en unos 5 minutos 43 segundos, y Qwen3.

5 27B se alargó casi hasta media hora. La conclusión de esta parte es sobria: en velocidad de respuesta, los modelos locales ya son en algunos casos comparables a los de la nube, sobre todo sin modo de razonamiento, pero en el mismo tiempo suelen quedar por debajo en calidad. En cambio, los MoE recientes parecen claramente más prácticos que las variantes densas.

En modo agente el panorama cambia de golpe. Allí crece el contexto, aumenta el número de llamadas y los segundos se convierten en minutos o incluso decenas de minutos. Aider con la misma Qwen3-Coder MLX 4bit terminó el escenario en 2 minutos 50 segundos con una nota de 9,5, Open Code en 7 minutos 33 segundos con un 9, pero Kilo Code con el mismo modelo tardó 15 minutos 5 segundos y solo llegó a 6 puntos.

Con la más pesada Qwen3.5 35B A3B, Kilo Code ya trabajó 57 minutos 3 segundos, aunque la calidad final subió a 9 sobre 10. Claude Code con Gemma 4 26B terminó el experimento con la nota máxima de 10 sobre 10, pero gastó en total 21 minutos 14 segundos, y la combinación de Claude Code con Qwen3-Coder directamente fallaba por falta de memoria para el contexto.

Al mismo tiempo, el portátil sufría de forma notable: la GPU se calentaba hasta unos 100 grados, los ventiladores casi no se callaban y el swap en algunos escenarios se hinchaba hasta 20 GB. En ese contexto, los agentes en la nube resultaban sencillamente más cómodos: por ejemplo, Kilo Code con Qwen3.5 Plus dio 9 sobre 10 en 6 minutos 53 segundos, y Claude Opus 4.

6, 10 sobre 10 en 12 minutos 15 segundos, aunque ya de pago.

La conclusión es simple: los LLM locales ya pueden considerarse en serio para chat privado, tareas puntuales de refactorización y escenarios simples en los que importa más el control de los datos que la velocidad absoluta. Pero si hace falta un modo agente permanente en un portátil de trabajo, sobre todo junto al IDE, el navegador y Docker, la pila local sigue siendo por ahora un compromiso. El escenario más sensato que deja esta experiencia es usar MoE recientes, agentes más simples como Aider u Open Code y, si es posible, llevar el modelo local a una máquina aparte, como un Mac mini.