Mi laptop de 2.5 años ahora escribe Space Invaders en JavaScript (GLM-4.5 Air)

• En una MacBook Pro M2 de 2.5 años, se usó el modelo GLM-4.5 Air de 3 bits para generar de una sola vez el código del juego Space Invaders
• Este modelo es el más reciente modelo open weight de alto rendimiento publicado por la china Z.ai bajo licencia MIT, y muestra un desempeño sobresaliente en benchmarks de programación
• Gracias a la versión quantized de 44 GB y 3 bits, puede ejecutarse incluso en una PC con 64 GB de RAM
• Usando la librería ml-explore/mlx-lm con el commit más reciente, se pudo correr el modelo en local con una velocidad relativamente rápida y un funcionamiento estable
• Los grandes modelos de lenguaje recientes especializados en programación local están mostrando una capacidad de generación de código muy alta y avanzan rápidamente

---

Experiencia generando JavaScript de Space Invaders con GLM-4.5 Air y MLX

29 de julio de 2025

La familia de modelos GLM-4.5 presentada ayer es el más reciente modelo open weight de alto rendimiento publicado por la china Z.ai bajo licencia MIT
Se considera que muestra un alto rendimiento en benchmarks de programación, incluso frente a modelos ya establecidos como Claude Sonnet 4

Incluso el modelo más pequeño, GLM-4.5 Air, tiene 106 mil millones de parámetros en total y un tamaño aproximado de 206 GB
Ivan Fioravanti publicó una versión cuantizada a 3 bits y reducida a 44 GB para que pueda ejecutarse con MLX incluso en una laptop con 64 GB de memoria
Al probarlo directamente, incluso este modelo pequeño mostró un desempeño muy potente

Prompt de entrada:

Se ingresó un prompt pidiendo escribir una página con Space Invaders implementado en HTML y JavaScript

El modelo tardó un poco en generar la respuesta, y este resultado se produjo con éxito
Aunque se trata de un ejemplo básico, resulta impresionante que una laptop de 2.5 años (MacBook Pro M2 con 64 GB) haya generado directamente, al primer intento, un código pulido que funciona

Cómo ejecutar el modelo

• Hay que usar la rama main de la librería más reciente mlx-lm y el commit específico con soporte para glm4_moe
• Después de levantar el entorno de Python con uv, se carga el modelo con el siguiente código

from mlx_lm import load, generate
model, tokenizer = load("mlx-community/GLM-4.5-Air-3bit")

• Los pesos del modelo de 44 GB se almacenan en la carpeta ~/.cache/huggingface/hub/models--mlx-community--GLM-4.5-Air-3bit

• La generación se ejecuta introduciendo el prompt de la siguiente manera

prompt = "Write an HTML and JavaScript page implementing space invaders"
messages = [{"role": "user", "content": prompt}]
prompt = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True
)
response = generate(
    model, tokenizer,
    prompt=prompt,
    verbose=True,
    max_tokens=8192
)

• Durante el proceso de generación, primero organiza y muestra los requisitos del problema y la información del diseño del juego
• Después genera a buena velocidad código HTML, CSS y JavaScript que realmente funciona

Estadísticas de generación

• Prompt: 14 tokens, generación a 14.095 tokens por segundo

• Cuerpo: 4193 tokens, generación a 25.564 tokens por segundo

• Uso máximo de memoria: 47.687 GB

• El historial completo de la conversación está en el enlace a gist

• El código fuente generado puede verse en el ejemplo de GitHub

• También es posible hacer una prueba de ejecución directamente en el navegador

Prueba con el benchmark Pelican

• También se evaluó la capacidad de generación de imágenes SVG del mismo modelo con el benchmark pelican riding a bicycle
• Con el prompt Generate an SVG of a pelican riding a bicycle, logró generar con éxito código SVG creativo
• El modelo consume hasta unos 48 GB de RAM al devolver el resultado
• Fue necesario cerrar algunas aplicaciones de la laptop para asegurar memoria suficiente
• La velocidad también fue satisfactoria

Avance de los modelos locales para programación

• En 2025, la mayoría de los grandes modelos de lenguaje se están enfocando en reforzar el rendimiento de generación de código
• Como resultado, están mostrando una alta capacidad de generación de código realmente utilizable incluso en hardware local
• Se están acercando a un nivel que habría sido difícil de imaginar en los primeros intentos con LLaMA hace dos años
• En la misma laptop que se usa actualmente, ya es posible beneficiarse de modelos open source de alto rendimiento que siguen apareciendo, como GLM-4.5 Air, Mistral 3.2 Small, Gemma 3 y Qwen 3
• Con el lanzamiento, en los últimos seis meses, de varios modelos de lenguaje de alta calidad especializados en programación y ejecutables en local, el entorno de desarrollo está mejorando

[GN⁺]

Comentarios de Hacker News

• Cuando conocí LLaMA por primera vez hace 2 años, ni me imaginaba que modelos como GLM 4.5 Air que vemos ahora (Gemma 3, Qwen 3, Mistral 3.2 Small, etc.) podrían correr en la laptop que usaba en ese momento. Tanto la calidad como la velocidad de lanzamiento de los modelos abiertos han superado por mucho mis expectativas. Como referencia, cuando salió ChatGPT en diciembre de 2022, los mejores modelos abiertos que existían eran GPT-J (unos 6~7B) y GPT-neoX (¿algo así como 22B?). De hecho, operé un servicio para usuarios con gpt-j durante casi un mes, y la calidad era pésima; no seguía instrucciones para nada, así que apenas funcionaba si le metías prompts como si fueran historias o varios ejemplos. Después se “filtró” LLama (yo creo que fue una filtración intencional) y la historia cambió. En la época de L1 aparecieron muchas optimizaciones como cuantización y fine-tuning, y con L2 el fine-tuning realmente se comercializó (la mayoría de los fine-tunes eran mejores que el original de Meta). Tras la demostración de LoRA de Alpaca, empezaron a salir en masa modelos muy potentes como Mistral, Mixtral, L3, Gemma, Qwen, DeepSeek, glm, Granite y otros. Según algunos análisis, los modelos abiertos van con un retraso de unos 6 meses respecto a los modelos publicados por los laboratorios SotA (y eso considerando que se asume que los laboratorios no publican sus mejores modelos, sino que los usan internamente para cosas como curar datos para el siguiente entrenamiento). Una diferencia de 6 meses es una locura. Yo pensaba que llegar a nivel GPT-3.5 tomaría unos 2 años, y jamás imaginé que viviríamos en una época donde pudiéramos correr estos modelos localmente e incluso afinarlos nosotros mismos

  • Durante bastante tiempo seguí preguntando cómo se hace el fine-tuning de LLM o LoRA (ajuste fino eficiente en parámetros), o cómo se usa. Nunca recibí respuestas realmente útiles y las búsquedas web están llenas de puro contenido SEO/publicitario. Sé desde hace 2 años cómo crear y usar SD LoRA, y lo manejo bien. Pero con LLM LoRA, todo se siente como si fuera un secreto oculto

  • No creo que Zuck (Mark Zuckerberg) lo haya filtrado personalmente en sitios como 4chan

  • Me pregunto si GLM 4.5 es mejor que Qwen3 coder

• Sigue sorprendiéndome que se pueda generar este tipo de código en una MacBook Pro M2 de 64GB comprada hace 2.5 años. En especial porque salió código que funcionó a la primera, sin correcciones. Creo que estamos subestimando demasiado el potencial increíble que tiene el hardware actual. Me preocupa que ideas como la “bitter lesson” (que la magia depende del cómputo) o la forma de pensar de “frontera de cómputo eficiente” terminen alejando a gente brillante de explorar enfoques innovadores. Viendo que los modelos actuales todavía conservan rendimiento incluso después de reducir muchísimo la precisión de los pesos tras el entrenamiento, hasta me hace pensar si en realidad no estaremos yendo por el lado más ineficiente

  • ¿No era que el punto central de la bitter lesson era que hace falta una gran cantidad de datos? Incluso el modelo del ejemplo fue entrenado en un corpus gigantesco de algo como 22 billones de tokens

• Me pregunto si realmente entendió el resultado de esa implementación, o si solo vio que corría. Siento que un LLM también podría dar respuestas más o menos correctas a preguntas típicas de entrevista. Cuando colegas presentan cambios de datos, hicieron una app de visualización JSON con un LLM, pero ya existía un visor JSON que funcionaba bien, así que me queda la duda de por qué hacer otro. En el trabajo, me da la impresión de que la gente usa LLM sobre todo para reforzar presentaciones y casi nunca para herramientas de uso real. Otro colega necesitaba una macro para modificar en masa contenido de materiales didácticos, pero para crearla primero armó una rúbrica para prompts del LLM y luego resumió los requisitos de la macro en diapositivas para volver a pasárselos al LLM. Como el sistema se volvió demasiado complejo, no creo que realmente le haya ahorrado tiempo. El resultado sí fue curioso, pero muchas veces termina siendo algo inútil para cualquier otra persona

  • Yo sí revisé el código por encima para entender qué hacía, pero si solo confirmo que funciona, no lo analizo más. Cuando uso un LLM para escribir código de producción, reviso todo línea por línea. Solo hago commit del código cuando lo entiendo por completo, al punto de poder explicárselo a otra persona. Hay un texto donde se detalla muy bien cómo se han usado los LLM para escribir código en la práctica
    https://simonwillison.net/2025/Mar/11/using-llms-for-code/

  • El propio LLM es justamente la solución

  • En realidad, el código desechable es justo un área donde la IA brilla de verdad. Feliz de que se encargue de boilerplate absurdo para sistemas de build, código de animación y cosas así (pensando en el esfuerzo que 3Blue1Brown ha puesto en animaciones, si la IA puede ayudar con eso, la recomiendo totalmente). Que alguien que no sabe programar pueda хотя sea hacer un prototipo y pasárselo a un desarrollador profesional tiene muchísimo valor. Ni siquiera hace falta entender los detalles del código resultante; basta con decidir si pasa o no pasa, así que la utilidad práctica es enorme. Pero los problemas que valen “cientos de millones” son distintos: corregir bugs reales en servicios o agregar funcionalidades, y ahí la IA se topa con límites. Por otro lado, el código desechable solía ser una herramienta de crecimiento para desarrolladores junior, y que ahora eso se lo lleve la IA sí da para pensarlo

• Supongo que en los datos de entrenamiento de ese modelo debe haber una enorme cantidad de versiones de Space Invaders escritas en distintos lenguajes

  • La prueba real sería ver si el modelo responde a pedidos de implementación detallados tipo “modifica la función para que la nave dispare hacia abajo, haz que aparezca por la izquierda/derecha, agrega modo de 2 jugadores”, etc.

  • Probablemente parte de esos datos sean casos donde el propio modelo copió juegos que ya estaban en el dataset y los convirtió en datos sintéticos. Cuando veo código frontend en React generado por LLM, siento que todos salen parecidísimos

  • Esta discusión ya quedó zanjada desde hace 3 años. Desde gpt3, todo el código utilizable ya está dentro de los datos de entrenamiento, y en solo 2 años pasamos de “ahora el código parece correcto, pero en realidad todo está mal” a “te genera una app full-stack funcional en 0-shot”. La clave del salto no es simplemente el dataset, sino el post-training, el aprendizaje por refuerzo (RL), el contexto largo, el comportamiento agéntico y demás. Los modelos tempranos tenían el límite de 2/4k tokens, pero ahora el panorama cambió por completo. Hablar solo de datos sin esa perspectiva es perder totalmente el punto

  • Me parece interesante la similitud visual con el juego breakout

  • También es muy probable que comentarios como este terminen siendo, a su vez, comentarios sintéticos similares sin análisis real, metidos innumerables veces en los datos de entrenamiento

• Tengo una Mac M4 con 128GB de RAM, y ahora mismo estoy descargando GLM-4.5-Air-q5-hi-mlx (80GB) con LM Studio. Voy a compartir los resultados pronto

• Creo que mostrar que un LLM puede correr localmente en una laptop tiene mucho significado. Antes esto era casi imposible con modelos pequeños, así que es un hito realmente importante. Pero en un dominio especial y acotado como Space Invaders, quizá sería más eficiente simplemente buscar y descargar una implementación existente en GitHub o donde sea. En casos así, el set de entrenamiento en sí es extremadamente pequeño y el espacio vectorial del modelo necesariamente tiene un alcance limitado, así que es muy probable que el código resultante sea casi igual al original o prácticamente un copy-paste. Además, hay que esperar a que el modelo teclee, así que el valor agregado es muy bajo. Me parece más sensato pedirle al LLM algo como “encuéntrame un código existente de Space Invaders escrito en lenguaje X en GitHub”. Da risa que cuando le encargas a ChatGPT ordenar este tipo de código, el LLM parece inducido a repetir la idea de que “casi no hay sobreajuste y el modelo no memoriza”; yo personalmente no creo mucho en ninguna de las dos cosas

  • No pude reproducir ese mensaje de advertencia en ChatGPT. En realidad, este tipo de inserción de advertencias tiene mucha fuerza política (sea de forma directa o ligeramente reformulada), y eso me parece muy interesante

• Lo probé con Claude Sonnet 4 y no funcionó bien. Así que GLM-4.5 Air cuantizado a 3bit salió adelante. Historial del chat relacionado: https://claude.ai/share/dc9eccbf-b34a-4e2b-af86-ec2dd83687ea Claude Opus 4 también funciona, pero queda muy por detrás del GLM-4.5 que publicó Simon: https://claude.ai/share/5ddc0e94-3429-4c35-ad3f-2c9a2499fb5d

• Al principio leí mal el título como “mi hijo de 2.5 años ahora hace Space Invaders en JavaScript (GLM-4.5 Air)”. Pero en unos años quizá de verdad sea posible

• Esta discusión trae una pregunta de ciencia ficción interesante. Si el binario de una inteligencia artificial futura cayera por un agujero de gusano en el hardware de consumo actual, ¿podría ejecutarse esa superinteligencia, o al menos un agente débil? ¿O podría autoarrancarse en otro hardware mediante red o persuasión?

  • Esa ha sido exactamente la premisa base de toda mi investigación en ML hasta ahora. Si cambias “agujero de gusano” por “programación genética/neuroevolución y similares”, es lo mismo. El software de optimización extrema de la demoscene fue lo que me llevó por este camino. La pregunta que sigo haciéndome hoy es: “¿cuál sería la complejidad de Kolmogórov de un binario que ofrezca exactamente todas las capacidades de los LLM de la generación actual?”. Si ese tamaño (complejidad) pudiera ejecutarse en mi desktop de hoy, ¿qué imagen tendríamos? Mi PC corre juegos AAA a 400fps, así que no creo que la diferencia con un LLM escupiendo texto utf-8 a 100b/s pueda ser realmente tan grande

  • Esa es la parte que de verdad me parece fascinante. ¿Cuántas capacidades ocultas hay y cómo podríamos explotarlas aún más al límite? ¿Y qué pasa incluso con hardware exótico o nuevo? Nosotros trabajamos introduciendo abstracciones sobre todo por las limitaciones del cerebro humano. Eso nos obliga a enfocarnos en áreas estrechas, pero las abstracciones tienen un costo grande y me intriga el potencial de eliminar ese límite

• Me pregunto si existe algún sitio que resuma el hardware mínimo/recomendado para correr LLM locales (algo como documentos de “requisitos del sistema”, como en los juegos)

  • LM Studio (además de otras herramientas) hace muy fácil elegir un modelo que se ajuste al rendimiento de tu hardware

  • Además de las otras respuestas, una buena regla práctica es que la mayoría de los modelos locales dan su mejor rendimiento con cuantización q4 (necesitas en memoria algo más de la mitad del tamaño en cantidad de parámetros del modelo). Por ejemplo, para un modelo 14B serían unos 8GB, y sumando capacidad de contexto, unos 10GB de VRAM sería una cifra razonable para un 14B. Si en q4 te sobran recursos, usas un modelo con más parámetros; si no te alcanza, bajas a una cuantización más pequeña

  • Aquí también hay material de referencia
    https://www.reddit.com/r/LocalLLaMA/

  • Me parece que este sitio es muy útil
    https://apxml.com/tools/vram-calculator

  • Si tienes una cuenta de HuggingFace, puedes registrar la información del hardware que tienes y comprobar de inmediato si podrás ejecutar cada modelo o no