PLANA

Actualidad de
inteligencia artificial

La IA, en claro.

Han metido el procesador de una Nintendo en los pesos de Qwen: así funciona NESformer

Drew Breunig ha compilado una CPU de NES y su memoria en un checkpoint compatible con Qwen3.5. Las demos enseñan el resultado calculado, no la velocidad real de ejecución.

Fotograma de Full Game calculado por NESformer
Drew Breunig / Doug Fraker

Un juego de una consola de los ochenta funcionando a través de los pesos de una arquitectura de IA. Esa es la curiosidad que Drew Breunig publicó el 30 de octubre con NESformer: una implementación del procesador de la Nintendo Entertainment System dentro de un archivo compatible con Qwen3.5. El proyecto muestra partidas y permite comprobar su salida frente a un emulador convencional.

La documentación original explica una diferencia decisiva: nadie entrenó esos pesos con horas de partidas. Un compilador calculó los valores necesarios para ejecutar las instrucciones del procesador. El resultado aprovecha la forma de un modelo de lenguaje para hacer un trabajo de computación muy concreto.

Lo que hay dentro de los pesos

NESformer representa el núcleo 6502 del procesador de la NES, sus registros, los 2 KB de memoria de trabajo y el código del cartucho. En cada paso produce un token que describe una parte de la ejecución. La secuencia de esos tokens permite seguir lo que está haciendo la máquina.

Un programa externo conserva otras tareas de la consola: dibujar la pantalla, leer los controles y gestionar parte de la sincronización. Por eso es más preciso hablar del procesador y la memoria dentro del modelo que afirmar que toda la Nintendo, con sonido y gráficos incluidos, se ha convertido en una IA.

La técnica utiliza el estado de las capas Gated DeltaNet como memoria. Breunig parte de Qwenputer, de Divyansh Agrawal, que ya había llevado una CPU CHIP-8 y otra RISC-V a la arquitectura Qwen3.5. NESformer reutiliza su compilador para construir esta nueva máquina.

Escenario del juego de prueba Full Game en la demostración de NESformer
Drew Breunig / Doug Fraker · Licencia

Un archivo de modelo que contiene un programa calculado

El checkpoint emplea el formato Qwen3_5ForCausalLM y puede cargarse con herramientas habituales de Hugging Face. Eso no significa que mantenga las capacidades conversacionales del modelo original. Su contenido se ha diseñado para ejecutar el circuito del procesador, no para responder preguntas generales.

El autor documenta unos 466,6 millones de parámetros en formato bf16, que ocupan aproximadamente 933 MB. Solo 9,3 millones son distintos de cero; esa gran cantidad de ceros permite que el archivo distribuido se comprima hasta unos 3,3 MB. El tamaño comprimido y la memoria que necesita al abrirse son, por tanto, cifras diferentes.

Es una forma llamativa de mostrar qué puede contener un archivo de pesos. Los números pueden ser el resultado de aprender patrones con datos o, como aquí, de traducir un programa en operaciones exactas. Que ambos utilicen una arquitectura compatible no convierte ambas cosas en el mismo tipo de aprendizaje.

Los juegos funcionan, pero cada fotograma cuesta segundos

La demostración pública incluye Super Mario Bros. y juegos de prueba. Para ilustrar esta noticia utilizamos el material del juego independiente Full Game, de Doug Fraker, incluido entre los recursos con licencia propia del repositorio. No hemos descargado una ROM comercial para ejecutar otra partida.

Las animaciones muestran el resultado ya calculado. No reflejan el tiempo real que tarda el sistema en producir cada imagen. Según el autor, un fotograma requiere entre uno y seis segundos, y ejecutar diez segundos de tiempo de consola puede llevar unos veinticinco minutos. Su estimación global sitúa el proyecto entre 150 y 290 veces por debajo de la velocidad de una NES real.

Tampoco reproduce toda la biblioteca de la consola. Actualmente admite cartuchos NROM, el tipo más sencillo, con límites de memoria concretos. Los juegos que utilizan otros circuitos para cambiar bancos de memoria necesitan un soporte que no está implementado. El sonido también queda fuera.

Cómo comprobaron que no era una animación inventada

El repositorio describe varias comprobaciones, más útiles que limitarse a mirar si un personaje se mueve. La CPU de referencia se compara con un registro de miles de instrucciones conocidas; después se contrasta el circuito y, finalmente, los tokens que generan los pesos.

En los programas de prueba incluidos, el autor informa de coincidencias exactas entre las trazas y los fotogramas de NESformer y los de una CPU de referencia. Esos resultados se refieren a pruebas específicas. No equivalen a afirmar que cualquier juego comercial funciona sin errores ni a una evaluación independiente realizada por PLANA.

El proyecto distribuye herramientas para volver a hacer esas comparaciones y documenta las limitaciones que todavía tiene. Esa posibilidad permite examinar la afirmación central con un criterio concreto: que la misma entrada produzca la misma secuencia de ejecución y la misma pantalla.

Una curiosidad sobre IA y emulación, no un atajo para jugar

NESformer resulta interesante por la combinación de ideas: reutilizar una arquitectura de modelo, compilar operaciones exactas en sus pesos y comprobar el resultado con herramientas de emulación. Su velocidad deja claro que el objetivo no es sustituir al emulador que ya utiliza un jugador.

El código se publica con licencia MIT y cada juego conserva sus propias condiciones. La propuesta para quien quiera explorarlo es seguir el procesador paso a paso y entender cómo una estructura pensada para generar tokens puede alojar un programa determinista. El salto sorprendente está en esa construcción, no en que Qwen haya aprendido a ser una Nintendo mirando partidas.

Fuentes y licencias de los juegos de prueba.

Presentación del proyecto en Hacker News.

La IA, en claro. Cada viernes en tu correo.

Tres noticias con contexto y un proyecto para descubrir. Apúntate gratis a PLANA semanal.

La conversación continúa en Instagram ↗