nesformer: la NES que corre dentro de Qwen3.5

Qué es nesformer y por qué es un hito técnico

nesformer es un proyecto de código abierto que compila la CPU 6502 de la Nintendo Entertainment System —el núcleo de su chip 2A03—, sus 2 KB de RAM de trabajo y la ROM de programa de un cartucho dentro de los pesos de un modelo Qwen3.5 estándar. La diferencia con cualquier otro experimento de este tipo es una sola frase: nadie entrenó esos pesos. Un compilador calculó cada uno de ellos.

El resultado es un checkpoint de 466,6 millones de parámetros en bf16 (933 MB), del cual solo 9,3 millones son distintos de cero, por lo que el archivo de pesos comprimido pesa apenas 3,3 MB. Cuando ejecutas un juego, el modelo predice el log de ejecución de la CPU token a token. Un pequeño programa anfitrión hace el resto de la consola: dibuja la imagen, lee el mando y dispara la interrupción de vblank.

Para un founder, esto importa por una razón muy concreta: demuestra que lógica determinista se puede compilar dentro de las redes neuronales en lugar de entrenarse. No es un modelo que "aprendió" a emular una consola. Es un modelo que contiene una consola, escrita como circuito.

Cómo funciona: la memoria del modelo es la RAM de la consola

El truco central viene de Qwenputer, el proyecto de Divyansh Agrawal que compiló primero un CHIP-8 y después una CPU RISC-V dentro de Qwen3.5-4B. nesformer reutiliza su compilador y su idea clave: el estado Gated DeltaNet del modelo es la memoria de la máquina.

Cada cabeza DeltaNet mantiene una matriz de estado de 128 × 128 que la regla delta actualiza en cada token. Con la compuerta abierta y una clave one-hot, una actualización sobrescribe exactamente una fila de esa matriz; con una consulta one-hot, esa fila se lee de vuelta. Así, cada fila es una celda de memoria, y el cartucho, la RAM y los registros viven todos en filas.

El reparto de responsabilidades entre modelo y anfitrión es lo que hace que el experimento sea elegante:

• Dentro del modelo (pesos + estado DeltaNet): el núcleo 6502 completo con sus 151 opcodes oficiales, todos los modos de direccionamiento, flags, pila, entradas BRK y NMI; los 2 KB de RAM; 32 KB de PRG-ROM almacenados dos veces (una copia para búsqueda de instrucciones y otra para lecturas de datos); y las lecturas de OAM DMA.
• En el anfitrión: la PPU con su renderizador por scanline y la paleta, los mandos, los registros del APU (escritos pero ignorados), el timing del NMI y las respuestas a lecturas de I/O.

El anfitrión nunca ve los registros ni la RAM de la CPU salvo a través del trace. La arquitectura del checkpoint es un Qwen3_5ForCausalLM con las formas de cabeza DeltaNet de Qwen3.5-4B (16 cabezas de clave, 32 de valor, dimensión 128) y ancho de MLP de 9.216. Lleva 7 capas Gated DeltaNet más una capa de atención con todos los pesos en cero que el caché de Hugging Face necesita. El tamaño oculto es 768 y el vocabulario, 263.808 tokens. Se carga con Qwen3_5ForCausalLM.from_pretrained y no requiere código personalizado.

¿Qué tan rápido corre y qué tan lejos está de una consola real?

Aquí está la letra chica que ningún titular cuenta. El motor por defecto calcula el forward pass de Qwen3.5 desde model.safetensors, compilado con numba y saltando los bloques en cero: corre a unos 1.650 tokens por segundo en un solo núcleo de CPU. El motor numpy hace unos 210, y transformers estándar unos 10.

Una NES real necesitaría alrededor de 700.000 tokens por segundo. En total, nesformer corre entre 150 y 290 veces más lento que la consola original. En la práctica: cada frame tarda entre 1 y 6 segundos, así que 600 frames —10 segundos de tiempo de NES— toman unos 25 minutos.

Hay una optimización interesante para quien trabaje con cargas repetitivas: los juegos pasan la mayor parte de cada frame esperando el vblank. Cuando el anfitrión detecta que el cuerpo de un bucle se repite exactamente, sin escrituras de RAM ni de I/O, adelanta el reloj hasta justo antes del siguiente evento de la PPU. Eso recorta el conteo de tokens entre 2,6 y 4,2 veces.

Qué límites tiene hoy

El proyecto es honesto sobre su alcance, y esos límites son la mejor guía de qué NO esperar todavía:

• Solo cartuchos NROM (iNES mapper 0). La CPU solo puede direccionar 32 KB de ROM de programa a la vez. Los juegos más grandes usan un chip de bank switching (un mapper como MMC1 o MMC3) que intercambia qué parte de la ROM ve la CPU. Las lecturas de ROM ocurren dentro del modelo, desde una tabla fija de 32 KB, así que todavía no puede seguir un cambio de banco.
• Solo opcodes oficiales. Un opcode no oficial emite HALT.
• El código debe correr desde la ROM del cartucho. Un salto a la RAM emite HALT.
• Sin IRQs (frame IRQ del APU, DMC). BRK y NMI sí funcionan.
• La PPU y el APU no están en los pesos. La PPU renderiza una scanline a la vez, así que los efectos a mitad de scanline no se reproducen; el sprite-0 hit y el desbordamiento de sprites son aproximados, y no hay sonido.

La validación, en cambio, es de las más rigurosas que se ven en proyectos así. La CPU de referencia coincide con el log dorado de nestest en 3.348 instrucciones y con el emulador py65 en 5,7 millones de instrucciones de código de juego. El circuito exacto predice cada token de referencia, y los pesos corriendo libres generan traces idénticos a la CPU de referencia: 1.916.527 tokens en la corrida de Thwaite (600 frames) y 2.645.885 tokens en Full Game (420 frames), con todos los frames guardados coincidiendo.

¿Qué significa esto para tu startup?

La lección no es "vas a emular tu producto dentro de un LLM". La lección es más útil y más incómoda: cuando el problema está bien especificado, un modelo puede generar una solución verificable. El propio autor lo describe como un desafío sorprendentemente bien estructurado, apoyado en tres cosas que cualquier equipo puede replicar.

Primero, materiales de referencia de calidad. Existe una comunidad de emulación de clásicos con décadas de trabajo, y dentro de ella hay tests de conformidad con más de 3.000 instrucciones doradas. Sin ese corpus, el proyecto no habría tenido contra qué validarse.

Segundo, tests de conformidad como contrato. nesformer no dice "parece que funciona": compara su CPU de referencia contra un log dorado y contra otro emulador, y luego compara los pesos libres contra esa referencia. Si tu producto tiene lógica crítica —facturación, impuestos, precios, permisos—, ese patrón es directamente trasladable: define el oráculo, escribe el test y recién después deja que un modelo genere código.

Tercero, medir el costo antes de enamorarse de la idea. La brecha de 150 a 290 veces más lentitud no es un detalle: es la diferencia entre un demo y un producto. Antes de meter un modelo en un camino crítico, calcula tokens por segundo contra el throughput que tu caso de uso realmente necesita.

Dos acciones concretas que puedes tomar esta semana:

• Clona el repo y corre el check de un ROM de prueba. Ver de cerca cómo se compara un modelo contra una referencia determinista te da un criterio mucho más fino para juzgar cualquier propuesta de "IA que reemplaza software".
• Adopta el patrón de tests de conformidad en tu equipo. Si estás evaluando generar código con modelos, el proyecto muestra el estándar: especificación clara, corpus de referencia y una comparación automática que falla al primer desvío.

Conclusión

nesformer es, a la vez, una proeza de ingeniería y un recordatorio de proporciones. Compilar una consola de 8 bits dentro de 9,3 millones de parámetros activos demuestra que los pesos de un transformer pueden alojar lógica determinista, no solo patrones estadísticos. Pero también deja claro el precio: una máquina que en silicio corre a 1,79 MHz necesita cientos de miles de tokens por segundo para hacer lo mismo, y hoy consigue una fracción de eso.

Para el ecosistema emprendedor hispanohablante, el valor está menos en la emulación y más en el método: especificaciones claras, tests de conformidad y medición honesta del costo. Eso es lo que convierte un experimento llamativo en una decisión de producto defendible.

Fuentes

• nesformer (repositorio original)
• Qwenputer, el compilador base de Divyansh Agrawal