Cómo correr modelos de IA locales en un Mac M4 con 24 GB sin depender de la nube

Ejecutar modelos de inteligencia artificial de forma local en una laptop ya no es una rareza experimental, pero sigue siendo un ejercicio de equilibrio entre memoria, velocidad y expectativas. La experiencia de un desarrollador con un MacBook Pro M4 de 24 GB muestra que hoy es posible trabajar sin conexión, con herramientas reales de programación y ventanas de contexto amplias, aunque todavía lejos del desempeño de los modelos más avanzados del mercado.
***

• Un desarrollador encontró en Qwen 3.5-9B cuantizado a 4 bits el mejor equilibrio entre velocidad, memoria y uso de herramientas en un Mac M4 con 24 GB.
• La configuración alcanzó cerca de 40 tokens por segundo, con modo thinking activado y contexto de 128K en LM Studio.
• La experiencia revela ventajas claras de la IA local, como privacidad, costo operativo bajo y uso sin internet, pero también límites importantes frente a modelos SOTA.

La posibilidad de ejecutar modelos de inteligencia artificial de forma local en equipos personales se ha convertido en una alternativa atractiva para desarrolladores, investigadores y usuarios que buscan privacidad, independencia y control. Sin embargo, llevar esa promesa a la práctica todavía implica navegar un terreno lleno de concesiones técnicas, desde la memoria disponible hasta la selección de herramientas y parámetros de inferencia.

En ese contexto, una publicación de jola.dev detalla la experiencia de ejecutar modelos locales en un MacBook Pro con chip M4 y 24 GB de memoria. La autora explica que, tras varias pruebas intermitentes, finalmente encontró una configuración que considera razonablemente funcional para tareas básicas, investigación y planificación, aunque muy distante del rendimiento de los modelos de frontera.

El punto central de su experiencia no es presentar una solución perfecta, sino mostrar qué combinación concreta sí pudo ofrecer resultados utilizables en un entorno real de trabajo. Su conclusión es que correr un modelo local en una laptop moderna puede ser sorprendentemente útil, siempre que el usuario acepte sus limitaciones y mantenga expectativas realistas.

La autora parte de un problema que hoy es común en la IA de consumo: no basta con descargar un modelo. Primero hay que decidir cómo ejecutarlo, y cada opción tiene restricciones distintas. Entre las alternativas que evaluó figuran Ollama, llama.cpp y LM Studio, cada una con sus propias rarezas, configuraciones y catálogos de modelos compatibles.

Elegir el modelo correcto sigue siendo la parte más difícil

Más allá del software de ejecución, la publicación enfatiza que el reto principal es escoger un modelo que quepa en memoria y, al mismo tiempo, deje suficiente margen para seguir usando aplicaciones cotidianas. En este caso, el objetivo no era dedicar toda la máquina a la IA, sino mantener un flujo de trabajo normal con aplicaciones adicionales, incluso varias basadas en Electron.

A eso se suma otra exigencia relevante: contar con una ventana de contexto amplia. La autora buscaba al menos 64K, pero idealmente 128K o más. En la práctica, esto reduce todavía más el número de modelos viables para una laptop con 24 GB de memoria, sobre todo cuando también se quiere habilitar razonamiento y uso de herramientas.

Durante sus pruebas recientes evaluó Qwen 3.6 Q3, GPT-OSS 20B, Devstral Small 24B y Gemma 4B. Según explica, algunos de ellos técnicamente cabían en memoria, pero en la práctica eran inutilizables. Gemma 4B sí funcionaba bien, aunque mostraba dificultades marcadas cuando debía interactuar con herramientas.

Además del modelo, la experiencia local exige afinar numerosos parámetros. Algunos son familiares, como temperature, mientras otros resultan bastante más especializados, como K Cache Quantization Type. La autora subraya que incluso cuando las plataformas ofrecen configuraciones recomendadas, las opciones correctas pueden cambiar según el tipo de uso, por ejemplo si se activa o no el modo thinking.

Qwen 3.5-9B en cuantización 4 bits fue el mejor equilibrio

La combinación que mejor resultado dio fue Qwen 3.5-9B en cuantización 4 bits, identificado como qwen3.5-9b@q4_k_s. Ejecutado en LM Studio, este modelo logró lo que la autora describe como un desempeño razonable: cerca de 40 tokens por segundo, modo thinking activado, uso exitoso de herramientas y una ventana de contexto de 128K.

Su juicio, no obstante, sigue siendo medido. Frente a un modelo SOTA, aclara que este sistema se distrae con mayor facilidad, a veces cae en bucles y puede malinterpretar solicitudes. Aun así, le parece notable que un modelo con esas capacidades pueda ejecutarse en un MacBook Pro de 24 GB dejando espacio para otras tareas.

Para trabajo de programación y modo thinking, la configuración recomendada incluyó temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0 y repetition_penalty=1.0. Además, para habilitar thinking en LM Studio fue necesario editar la plantilla del prompt y añadir la línea {%- set enable_thinking = true %}.

La autora usó ese modelo tanto a través de Pi como de OpenCode. Sobre Pi, comenta que se siente más ágil, pero también más demandante en términos de personalización. Aunque valora la idea de que el sistema construya su propio harness, considera que puede empujar al usuario a invertir demasiado tiempo ajustando configuración en vez de avanzar en proyectos reales.

Las configuraciones prácticas con Pi y OpenCode

En su explicación, la autora también comparte configuraciones concretas para facilitar la replicación del entorno. En Pi, el archivo ~/.pi/agent/models.json apuntó a LM Studio mediante http://localhost:1234/v1, usando la API de completions compatible con OpenAI y declarando el modelo qwen3.5-9b@q4_k_s con razonamiento activo.

Para ese mismo entorno, añadió la compatibilidad thinkingFormat: qwen-chat-template. También menciona un ajuste adicional en ~/.pi/agent/settings.json para ocultar el bloque de thinking mediante hideThinkingBlock: true, con el fin de evitar distracciones durante el uso diario.

En OpenCode, la configuración se realizó en ~/.config/opencode/opencode.json. Allí se definió LM Studio como proveedor local, con base en http://127.0.0.1:1234/v1, y se especificó que el modelo permitía herramientas, contexto de 131072 tokens y un máximo de 32768 tokens de salida.

Estos detalles son relevantes porque muestran que la IA local útil no depende solo del hardware. También exige una capa de integración estable entre el modelo, la interfaz de inferencia y la herramienta que lo orquesta para programación o automatización. En este caso, la experiencia positiva vino de una combinación muy específica y afinada.

Lo que sí puede hacer y lo que todavía falla

Uno de los puntos más interesantes del texto es la comparación franca entre este modelo local y los sistemas más avanzados del mercado. La autora afirma que Qwen 3.5-9B Q4 no puede resolver de manera independiente problemas complejos durante largos periodos de tiempo, como sí logran los modelos SOTA en ciertos flujos de trabajo.

Por eso, considera poco sensato pedirle que construya una aplicación completa de una sola vez. En su experiencia, ese enfoque solo lleva a frustración. Lo que sí funciona es un flujo interactivo y guiado, donde el usuario da instrucciones claras, supervisa avances y participa activamente en el proceso de razonamiento y planificación.

Lejos de ver eso como un defecto absoluto, la autora señala un efecto interesante. Con modelos SOTA, dice, es demasiado fácil delegar por completo el esfuerzo cognitivo. En cambio, con un modelo local más limitado, el usuario debe pensar más, especificar mejor y mantener el control del proyecto, mientras el sistema actúa como asistente de investigación, memoria técnica y apoyo para comandos o detalles de lenguajes.

Su conclusión en este punto es clara: no se trata de un aumento de productividad de diez veces, como a veces prometen las grandes compañías de IA. Pero sí puede aportar valor concreto, sobre todo para quienes prefieren una interacción más deliberada con la tecnología y menos dependencia de servicios remotos.

Dos ejemplos simples revelan fortalezas y debilidades

Como prueba práctica, la autora describe primero una tarea en Elixir relacionada con el linter credo. Tras actualizar la herramienta a la última versión, aparecieron advertencias en su código. Le pidió entonces a Qwen ejecutar mix credo –strict y sugerir una solución sin editar archivos.

El modelo identificó cuatro advertencias en archivos de prueba. Todas estaban relacionadas con el uso de length/1 para verificar si listas no estaban vacías. La recomendación fue reemplazar expresiones como length(list) > 0 por comparaciones del tipo list != [], una práctica más idiomática en Elixir y más eficiente al evitar calcular la longitud completa.

Cuando la autora le pidió aplicar los cambios, Qwen realizó cuatro ediciones en paralelo y de forma limpia. Aunque reconoce que era una tarea simple que ella misma podía resolver rápidamente, valora la conveniencia de no tener que alternar entre terminal y editor para localizar líneas y hacer correcciones menores.

El segundo ejemplo fue menos favorable. Tras varias actualizaciones de dependencias, recibió un pull request de Dependabot con conflictos de Git que no se resolvían automáticamente. Después de descargarlo y hacer rebase, pidió al modelo revisar el conflicto, que consistía básicamente en conservar la versión más nueva de cada dependencia.

Qwen entendió correctamente la situación y propuso tres opciones, incluyendo la recomendada: mantener sentry 13.0.1 desde HEAD y tailwind 0.4.1 desde la otra rama. Sin embargo, al solicitarle ejecutar el cambio, el sistema no editó el archivo en conflicto y en su lugar intentó hacer git add mix.lock && git rebase –continue con los marcadores de conflicto todavía presentes.

El modelo tampoco anticipó que git rebase –continue abriría un editor. Como resultado, OpenCode quedó bloqueado. La autora admite que eso pudo ser un fallo puntual, pero el ejemplo ilustra un límite importante: entender el conflicto no siempre implica completar correctamente la acción dentro del flujo de herramientas.

Privacidad, costo y sostenibilidad como argumentos a favor

En su cierre, la autora resalta que los modelos locales traen concesiones serias, pero también ventajas muy concretas. La primera es evidente: no requieren conexión a internet. Eso abre escenarios de uso en viajes, aviones o ambientes con conectividad limitada, además de reducir la exposición de datos a infraestructuras externas.

El segundo punto es económico. Si el usuario ya pensaba comprar un computador de todos modos, el costo operativo se reduce esencialmente a la electricidad consumida. No hay suscripciones mensuales obligatorias, un factor que puede resultar atractivo para desarrolladores independientes y usuarios intensivos.

También menciona un ángulo ambiental. Reconoce que el entrenamiento de estos modelos sigue teniendo un costo ecológico importante. Sin embargo, sostiene que las compañías de modelos abiertos no están en la parte más alta de la lista en cuanto a impacto, y que usar hardware propio implica una menor dependencia de grandes centros de datos.

Finalmente, hay una motivación menos cuantificable pero importante: experimentar con modelos locales es divertido. Después del fuerte impacto social de los LLM, la autora considera que explorar esta tecnología de forma autónoma y más sostenible puede ser una vía positiva para relacionarse con ella, incluso cuando el sistema todavía se equivoca o falla en momentos críticos.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín