LM Studio y Qwen: cómo los LLMs locales manejan la codificación en MacBook M4 Pro

Los modelos de lenguaje locales ya pueden usarse para escribir y editar código sin enviar el código fuente a la nube, pero la comodidad de tal trabajo aún depende mucho de la tarea y del hardware disponible. 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 con pesos abiertos ya entrega resultados tangibles en modo chat, pero en modo de agentes completos rápidamente se topa con limitaciones de memoria, calor y tiempo de ejecución. El punto de partida aquí es simple: los modelos en nube son convenientes, pero tienen limitaciones, dependencia de la red, y la principal desventaja para muchos desarrolladores — datos, código y prompts se envían a servidores remotos.

La ejecución local promete privacidad y control total, pero requiere entender cómo un modelo consume RAM y VRAM, cuánta memoria queda para el contexto y cómo difieren formatos como GGUF y MLX. Las pruebas se realizaron en un MacBook Pro con chip M4 Pro y 48 GB de memoria unificada, donde CPU y GPU comparten un pool de memoria común. Esto ayuda a acomodar modelos más grandes, pero simultáneamente significa que el modelo compite por recursos con IDE, Docker y decenas de pestañas del navegador.

Una parte separada del análisis se enfoca en elegir un modelo para el hardware. El autor sugiere no solo mirar el tamaño en miles de millones de parámetros, sino también la especialización, cuantización, soporte para function calling y tipo de arquitectura. Para programación, utilizó Qwen3-Coder 30B A3B Instruct en variantes MLX y GGUF, y también lo comparó con Qwen3-Coder Next, Qwen3.

5, Nvidia Nemotron-3 Nano y Gemma 4 26B A4B. El artículo explica bien el significado práctico de las abreviaturas: por ejemplo, A3B indica un enfoque MoE, donde solo parte de los parámetros de un modelo grande se activan, lo que hace que la velocidad sea más cercana a los modelos pequeños mientras que la calidad se acerca a la de los modelos más grandes. LM Studio fue elegido como el runtime: a través de él, los modelos se descargan fácilmente, se configura un servidor local, se habilita CORS y se pueden conectar agentes como Claude Code, Open Code, Kilo Code y Aider.

El pronóstico de rendimiento para Qwen3-Coder prometía alrededor de 150 tokens por segundo, pero la medición real en LM Studio resultó estar más cerca de 82 tokens por segundo, lo que inmediatamente trae la conversación de la teoría a la práctica. La parte más interesante comienza con las mediciones. En modo chat regular, los modelos locales ya no se ven como un juguete sino como un compromiso funcional.

Qwen3-Coder 30B A3B Instruct en MLX 4bit se ajustó aproximadamente en 2 minutos 9 segundos para todo el escenario de tres etapas y alcanzó una puntuación final de 8,5 de 10. Gemma 4 26B A4B en GGUF mostró uno de los mejores equilibrios: alrededor de 2 minutos 23 segundos y una puntuación final de 10 de 10. Los modelos más pensantes dieron mejores resultados pero al costo del tiempo: Qwen3.

5 35B A3B alcanzó 10 de 10 en aproximadamente 5 minutos 43 segundos, mientras que Qwen3.5 27B se extendió casi hasta media hora. La conclusión de esta parte es sobria: los modelos locales ya a veces igualan a los modelos en nube en velocidad de respuesta, especialmente sin modo de pensamiento, pero en el mismo tiempo frecuentemente se quedan atrás en calidad.

Mientras tanto, los modelos MoE recientes se ven notablemente más prácticos que las variantes densas. En modo agente, el panorama cambia dramáticamente. El contexto crece, el número de llamadas aumenta, y los segundos se convierten en minutos o incluso decenas de minutos.

Aider con el mismo Qwen3-Coder MLX 4bit completó el escenario en 2 minutos 50 segundos con una puntuación de 9,5, Open Code en 7 minutos 33 segundos con una puntuación de 9, pero Kilo Code con el mismo modelo tardó 15 minutos 5 segundos y solo alcanzó 6 puntos. Con el más pesado Qwen3.5 35B A3B, Kilo Code tardó 57 minutos 3 segundos, aunque la calidad final mejoró a 9 de 10.

Claude Code con Gemma 4 26B completó el experimento con una puntuación máxima de 10 de 10, pero gastó un total de 21 minutos 14 segundos, y la combinación Claude Code con Qwen3-Coder realmente se bloqueó debido a memoria insuficiente para el contexto. En paralelo, la laptop sufrió notablemente: la GPU se calentó a alrededor de 100 grados, los ventiladores casi no se detuvieron, y swap en algunos escenarios se hinchó hasta 20 GB. Ante esto, los agentes en nube se veían trivialmente más convenientes: por ejemplo, Kilo Code con Qwen3.

5 Plus dio 9 de 10 en 6 minutos 53 segundos, y Claude Opus 4.6 — 10 de 10 en 12 minutos 15 segundos, aunque con costo. La conclusión es simple: los LLMs locales ahora pueden considerarse seriamente para chat privado, tareas únicas de refactorización y escenarios simples donde el control de datos importa más que la velocidad absoluta.

Pero si necesita modo agente constante en una laptop de trabajo, especialmente junto a IDE, navegador y Docker, la pila local sigue siendo un compromiso. El escenario más razonable de esta experiencia es usar modelos MoE recientes, usar agentes más simples como Aider u Open Code, y cuando sea posible, ejecutar el modelo local en una máquina separada como Mac mini.