Un transformador de 21B parámetros ejecuta el renderizador de Doom sin entrenamiento

Cursor Horizon tiene ahora un referente técnico inusual: un transformador de 21.000 millones de parámetros que renderiza Doom sin haber pasado por entrenamiento. El desarrollador Rob Porter compiló directamente el algoritmo de renderizado del juego en los pesos del transformador. El resultado cuestiona la idea de que todo gran transformador haya aprendido su comportamiento a partir de datos.

Este modelo no predice cómo debería verse un fotograma de Doom. Ejecuta un proceso de renderizado traducido, un token generado a la vez. Un prompt proporciona la geometría de la escena y el estado de la cámara. La salida contiene cálculos intermedios y comandos de dibujo que un pequeño programa anfitrión convierte en píxeles.

Esa distinción separa el proyecto de los experimentos generativos de Doom entrenados con vídeos de partidas. También crea la tensión central de esta historia sobre Cursor Horizon. La inferencia de transformadores se ha convertido en un extraño objetivo para el software convencional, aunque el programa resultante es drásticamente más lento que el juego original.

Los artefactos públicos hacen que la afirmación sea inusualmente verificable. Porter publicó el compilador, el grafo del renderizador, los checkpoints, el prompt, las herramientas de decodificación y una implementación de referencia. Sin embargo, la mayoría de los resultados de rendimiento y precisión aún proceden de las propias pruebas del proyecto, en lugar de replicaciones independientes.

El renderizador de Doom se convirtió en un checkpoint estándar de transformador

El cambio importante no es que un modelo de IA produjera una imagen de Doom. Es que código de renderizado convencional se convirtió en los pesos del modelo.

Porter publicó el proyecto el 13 de agosto de 2026, seguido de una detallada publicación para la comunidad. Su análisis técnico describe un compilador llamado torchwright. Convierte grafos de computación en los pesos de atención y feed-forward de un transformador de solo decodificador.

No hay bucle de optimización, corpus de entrenamiento, actualización por gradiente ni aproximación aprendida de la jugabilidad de Doom. El compilador calcula los pesos del checkpoint a partir de un grafo escrito en Python. Esos pesos codifican las operaciones que el renderizador necesita durante la ejecución.

El artefacto generado utiliza la arquitectura estándar Phi3ForCausalLM. Esto importa porque Hugging Face Transformers ya sabe cómo cargarlo y ejecutarlo. Los usuarios no necesitan código de modelo personalizado ni la configuración potencialmente sensible trust_remote_code=True.

El checkpoint principal contiene 38 capas de transformador y aproximadamente 21.000 millones de parámetros. Sus fragmentos de pesos fp32 ocupan 85,87 GB. Una versión más pequeña de 80 por 50 utiliza 70 capas y 34,09 GB de fragmentos fp32.

El checkpoint más grande recibe un prompt de 3.614 tokens que representa la escena. Después genera 53.747 tokens antes de completar el fotograma. La secuencia combinada alcanza los 57.361 tokens.

Solo una parte de esa salida pinta píxeles directamente. Los tokens restantes representan operaciones del renderizador, valores calculados, flujo de control y estado temporal. Funcionan más como un rastro de ejecución que como lenguaje natural.

El checkpoint publicado incluye la configuración del modelo, el tokenizador, el prompt, la paleta y las utilidades de decodificación. Su tokenizador utiliza palabras legibles para las operaciones y los valores. Esta elección hace que partes del rastro de ejecución sean comprensibles sin decodificar identificadores de token arbitrarios.

El programa anfitrión realiza una tarea deliberadamente limitada. Recuerda una posición de cursor, selecciona colores de la paleta de Doom y pinta las tiradas de píxeles solicitadas. No calcula visibilidad, geometría, orden de paredes, coordenadas de textura ni oclusión.

Cinco comandos de salida controlan el dibujo. Dos comandos establecen las coordenadas del cursor. Dos eligen si el cursor avanza horizontal o verticalmente. El quinto pinta una tirada de píxeles con un color y una anchura especificados.

Ese límite es fundamental para la credibilidad del proyecto. Un modelo que simplemente pidiera a software externo renderizar Doom sería menos interesante. Aquí, según se informa, el checkpoint realiza el trabajo de renderizado dependiente de la vista, mientras el anfitrión aplica mecánicamente sus instrucciones de dibujo.

El checkpoint no es el juego completo de Doom. No implementa la jugabilidad, los enemigos, los sprites generales, el sonido ni el control del jugador. Implementa una versión restringida del renderizador para escenas que usan una biblioteca de texturas fija.

La salida completa utiliza la resolución de pantalla de 320 por 200 de Doom en modo de bajo detalle. El renderizador calcula 160 columnas y muestra cada una en dos píxeles. Nueve texturas de pared y seis texturas de suelo o techo están compiladas en el modelo.

La posición del jugador, la dirección de visión, la geometría del mapa, la información de sectores y el árbol de partición espacial binaria llegan mediante el prompt. Un árbol de partición espacial binaria, o árbol BSP, divide el mapa para ordenar eficazmente la visibilidad.

Estas entradas pueden cambiar sin reconstruir el checkpoint, siempre que la escena se mantenga dentro de los límites compilados de texturas y configuración. Añadir una textura no compatible exige recompilar.

Por eso el enfoque de Cursor Horizon merece atención. El proyecto trata un checkpoint de transformador como un formato de paquete ejecutable, no como un almacén de conocimiento aprendido. Sus parámetros son material de programa generado por un compilador.

Por qué Cursor Horizon cuestiona el modelo de entrenamiento primero

Torwright convierte la arquitectura de transformadores en un sustrato computacional determinista, aunque no ofrece un reemplazo práctico para los procesadores convencionales.

La mayoría de los grandes modelos de lenguaje adquieren comportamiento mediante entrenamiento. Los ingenieros seleccionan una arquitectura, la exponen a datos, miden errores y ajustan los pesos mediante descenso de gradiente. El modelo final contiene patrones aprendidos de esos ejemplos.

Torwright invierte ese flujo de trabajo. Un desarrollador define un grafo de computación y el compilador construye pesos que ejecutan sus operaciones. El transformador terminado sigue prediciendo un token tras otro, pero el proceso de predicción sigue un programa diseñado.

La distinción se parece a la diferencia entre aprender multiplicación a partir de ejemplos y ejecutar un circuito de multiplicación. Ambos pueden producir la misma respuesta. Sus orígenes internos, límites de fiabilidad y modos de fallo difieren.

El compilador torchwright de código abierto admite operaciones lineales, búsquedas basadas en atención, comparaciones, selección y multiplicación. Programa los nodos del grafo a través de las capas del transformador y almacena los valores calculados en el flujo residual.

Un flujo residual es el vector evolutivo que pasa por las capas de un transformador. Torchwright asigna porciones de ese vector a valores del programa. Cuando un valor deja de ser necesario, otra operación lo cancela y reutiliza su espacio.

La atención realiza más que asociación semántica en esta disposición. Recupera valores de tokens anteriores mediante la coincidencia de campos estructurados. Esos campos pueden representar un identificador de nodo, profundidad de árbol, tipo de operación o coordenada de pantalla.

Las capas feed-forward implementan operaciones no lineales. Torchwright ofrece bibliotecas de operaciones construidas con activaciones ReLU o SwiGLU. El compilador convierte cada operación del grafo en filas específicas de pesos feed-forward o cabezales de atención.

Este enfoque tiene precedentes académicos. RASP introdujo un lenguaje de programación cuyas primitivas se asignan a operaciones de transformadores. La investigación Tracr de DeepMind compiló programas RASP en pesos de transformadores para experimentos de interpretabilidad.

Torwright extiende esa dirección hacia grafos de computación regulares de Python y un formato de salida Phi-3 estándar. El objetivo es importante porque el software de inferencia existente puede cargar el resultado sin comprender su inusual origen.

Esa compatibilidad crea una posibilidad provocadora. Un checkpoint estándar podría contener comportamiento estadístico aprendido, lógica compilada deliberadamente o una mezcla de ambos. Su estructura de archivo por sí sola no revelaría qué camino produjo sus pesos.

Para los desarrolladores, esto cambia cómo pueden interpretarse los artefactos de modelo. El número de parámetros suele actuar como una señal aproximada de capacidad aprendida y coste de inferencia. Aquí, 21.000 millones de parámetros reflejan principalmente un objetivo de compilación extremadamente ineficiente.

La cifra no significa que el checkpoint posea conocimiento lingüístico amplio. No puede responder preguntas generales ni improvisar escenas de Doom fuera de su renderizador compatible. Sus pesos implementan un programa restringido, en lugar de un modelo lingüístico abierto.

Cursor Horizon captura así un problema de límites más amplio. El ecosistema de transformadores ofrece ahora cargadores, aceleradores, fragmentación, herramientas de despliegue y clases de modelo estandarizadas. Un compilador puede aprovechar esa infraestructura para software que nunca fue entrenado.

Eso no hace que los transformadores sean preferibles a las CPU. Demuestra que su maquinaria de ejecución es lo suficientemente general como para alojar algoritmos construidos explícitamente. Generalidad, eficiencia y utilidad siguen siendo cuestiones separadas.

La contribución más sólida del proyecto es conceptual, más que comercial. Hace visible la distinción entre arquitectura y entrenamiento. Un transformador es una estructura matemática. Un LLM es una aplicación conocida construida al entrenar esa estructura con lenguaje.

El modelo de Porter elimina el proceso de aprendizaje al tiempo que conserva el comportamiento de inferencia familiar. Acepta tokens, aplica capas de atención y feed-forward, selecciona un siguiente token y repite. El bucle parece ordinario incluso cuando el cálculo en su interior no lo es.

Esta propiedad también ofrece un entorno de investigación controlado. Puesto que cada peso procede de operaciones de grafo conocidas, los investigadores pueden rastrear por qué aparece un valor. Esto difiere marcadamente de interpretar un modelo cuyas características internas surgieron del entrenamiento.

Sin embargo, el checkpoint de Doom es mucho mayor que los modelos de prueba de interpretabilidad típicos. Su escala demuestra que las construcciones compiladas pueden alcanzar la infraestructura de modelos moderna. También hace que la inspección y la reproducción independiente sean costosas.

El transformador ejecuta Doom un token a la vez

El renderizador funciona al convertir el estado de ejecución mutable de Doom en un historial de tokens de solo anexado que la atención puede buscar.

El renderizador de Doom recorre un árbol BSP desde las regiones cercanas hasta las lejanas. Proyecta paredes sobre columnas de pantalla, rastrea qué áreas ya están cubiertas y omite la geometría oculta tras superficies más cercanas.

El código convencional actualiza variables y estructuras de datos en memoria. La generación autorregresiva no puede modificar tokens anteriores. Cada token nuevo se une a una secuencia de solo anexado que permanece disponible para pases posteriores del transformador.

El renderizador compilado resuelve esta incompatibilidad representando cada cambio de estado como otro token. Las operaciones posteriores usan atención para encontrar el registro relevante más reciente o combinar múltiples registros anteriores.

Un recorrido recursivo de árbol normalmente depende de una pila de llamadas. En su lugar, el modelo emite registros de migas de pan durante el descenso. Cuando llega a una hoja, la atención recupera la miga de pan apropiada y determina dónde debe reanudarse la ejecución.

La cobertura de paredes requiere otra estrategia. Doom almacena rangos horizontales cubiertos en una estructura mutable llamada solidsegs. Esos rangos le ayudan a evitar dibujar paredes que ya están ocultas por geometría más cercana.

El transformador no puede fusionar ni sobrescribir registros de rango anteriores. Añade cada rango recién cubierto. Las operaciones posteriores consultan el historial acumulado para determinar si una columna está cubierta y dónde termina el intervalo cubierto.

Los suelos y techos siguen un patrón relacionado. El pase de paredes registra sus límites visibles para cada columna de pantalla. Un pase posterior recupera esos registros y emite tiradas de dibujo horizontales.

El resultado es una secuencia de tokens que cumple varias funciones. Es un flujo de instrucciones, memoria de trabajo, pila de llamadas, registro de estado y protocolo de salida. La atención proporciona el mecanismo de búsqueda que conecta esas funciones.

Los cálculos largos también se dividen entre tokens generados. Una capa de transformer solo puede realizar una cantidad limitada de trabajo secuencial antes de transmitir su flujo residual. Las cadenas de dependencias más largas requerirían más capas.

El renderizador a veces emite un resultado intermedio y lo consume durante un paso de decodificación posterior. Esa estrategia emplea más tokens para reducir la profundidad necesaria en cada paso.

La proyección de paredes ilustra esta compensación. El modelo calcula ángulos globales, los convierte en ángulos relativos a la cámara y luego proyecta los extremos en la pantalla. Los tokens de ángulos intermedios separan esas etapas dependientes.

Este diseño mantiene el modelo insignia en 38 capas. También contribuye al rollout de 53.747 tokens necesario para un solo fotograma. Cada traspaso intermedio adicional añade otra pasada completa por el modelo.

El código fuente del renderizador expone esta canalización. Los módulos gestionan las entradas de escena, el recorrido, la proyección, la rasterización, las texturas y el protocolo de salida. Un renderizador independiente en Python actúa como referencia de corrección.

El modelo genera tokens de forma voraz, es decir, selecciona el siguiente token con mayor puntuación sin muestreo. La aleatoriedad sería inapropiada porque el checkpoint está diseñado para ejecutar lógica determinista.

La palabra clave Cursor Horizon resulta útil aquí como metáfora del límite de estado del modelo. Su cursor de salida avanza por una imagen renderizada, mientras que su horizonte de atención se extiende hacia atrás a través del historial de ejecución.

Sin embargo, el mecanismo es más literal que poético. Cada nueva operación puede inspeccionar hechos previos de la escena y registros generados. Nada en el proceso exige la flexibilidad semántica asociada a los modelos conversacionales.

El prompt actúa como memoria de solo lectura. Contiene hechos del mapa independientes de la vista, además de la posición y dirección del jugador. La parte generada funciona como memoria de trabajo de solo anexado para cálculos dependientes de la vista.

Posteriormente, el host interpreta los tokens de dibujo mediante la paleta de 256 colores de Doom. Mueve un cursor de software y pinta las secuencias solicitadas. La demostración mínima de Porter implementa esa parte en 43 líneas de Python.

Ese pequeño host no demuestra que cada cálculo de renderizado resida dentro del checkpoint. Sin embargo, el código público hace que el límite sea comprobable. Los revisores pueden inspeccionar la construcción del prompt, los módulos del grafo, la decodificación de salida y la comparación de referencia.

El proyecto informa de comprobaciones píxel por píxel frente a su renderizador en Python. Para el fotograma insignia, midió cobertura completa de píxeles, un 99,9 por ciento de coincidencia dentro de las opciones de color permitidas y un 96,7 por ciento de coincidencia exacta.

Estas cifras difieren ligeramente del 97 por ciento redondeado utilizado en el artículo original. El archivo de hechos canónicos del repositorio atribuye las mediciones más recientes a un renderizado de producción del 9 de agosto.

Según se informa, el checkpoint de menor resolución alcanzó cobertura completa, coincidencia completa de color dentro de las opciones y un 93,9 por ciento de coincidencia exacta. Su fotograma contenía 3.964 píxeles comparados.

Estas son mediciones comunicadas por el proyecto. Las pruebas independientes aún no han establecido si los mismos resultados se mantienen en distintos entornos, prompts o variaciones de escena.

El Resultado Real Son 35 Fotogramas al Día

El proyecto tiene éxito como demostración de compilador precisamente porque fracasa de forma tan rotunda como renderizador práctico de Doom.

El Doom original apuntaba a 35 fotogramas por segundo en hardware de principios de los años noventa. El checkpoint completo de Porter produce aproximadamente 0,0004 fotogramas por segundo en un acelerador Nvidia B200.

La decodificación voraz tardó 2.383,5 segundos durante la ejecución de producción comunicada. La carga del modelo y otros costes generales elevaron el tiempo de extremo a extremo a 2.528,1 segundos, o 42,1 minutos.

Eso equivale a unos 35 fotogramas al día, suponiendo operación continua y tiempos similares. La comparación se convirtió en la broma más memorable del proyecto. También expone el coste central de compilar software convencional en inferencia autorregresiva.

Cada token emitido requiere otra pasada por un modelo de 21.000 millones de parámetros. Dibujar un fotograma implica decenas de miles de esas pasadas. La arquitectura serializa operaciones que el hardware convencional realiza mediante instrucciones compactas y canalizaciones paralelas.

Según se informa, la ejecución en B200 reservó 151 GiB de memoria en su pico. Solo el checkpoint ocupa casi 80 GiB al medirse en gibibytes binarios. No es un programa que la mayoría de los lectores pueda probar en una GPU de escritorio.

El checkpoint para consumidores reduce la resolución a 80 por 50 píxeles. Produce un rollout de 7.007 tokens y, según se informa, decodifica en 338,3 segundos en una A100 con 80 GB de memoria.

Su checkpoint de 34,09 GB también puede distribuirse entre dos GPU de consumo de 32 GB mediante asignación automática de dispositivos. Esa versión hace más viable la reproducción, aunque sigue siendo extravagante para un fotograma diminuto.

La precisión introduce otra limitación. Los modelos publicados usan pesos fp32. Los despliegues convencionales de LLM suelen reducir memoria y cómputo mediante formatos de menor precisión o cuantización.

La cuantización es arriesgada en este caso porque los errores numéricos no se limitan a suavizar probabilidades lingüísticas. Pueden corromper el estado del programa, las comparaciones, las búsquedas similares a direcciones y la cancelación dentro del flujo residual.

La documentación del compilador de torchwright reconoce que algunas construcciones no lineales usan aproximaciones lineales por tramos. Sus pruebas miden límites de error para operaciones individuales y comparan nodos de grafos compilados con evaluación directa.

Estas salvaguardas aportan evidencia, no certeza matemática para cada ejecución completa. Los límites de error por operación no se combinan automáticamente a lo largo de cadenas extensas. Por ello, el compilador se apoya en sondeos más amplios del grafo y comparaciones de salida.

La discusión pública del proyecto en Reddit planteó directamente esta preocupación. Porter dijo que esperaba que una cuantización descuidada produjera una salida corrupta, en lugar de una imagen de menor fidelidad. También señaló que no había probado ese escenario.

Otra limitación se refiere a la generalidad. El checkpoint admite una región seleccionada, una resolución fija y las texturas necesarias alrededor del área inicial de E1M1. No reproduce todo el renderizador para todo el contenido de Doom.

Los sprites siguen sin implementarse. El arma y la barra de estado están fijadas al estado inicial con pistola. El modelo renderiza una escena, no un bucle de juego interactivo con sistemas normales de jugabilidad.

El prompt del mapa del proyecto también se prepara antes de la inferencia. El código del host recorta el nivel a una región fija del espacio global y codifica los hechos estáticos como tokens. El repositorio describe ese límite como comparable a cargar un nivel.

Los críticos pueden preguntarse razonablemente si esto sigue contando como Doom ejecutándose dentro de un transformer. La respuesta más defendible es más limitada: la lógica de renderizado dependiente de la vista se ejecuta dentro de un checkpoint compilado para una escena restringida de Doom.

Sería inexacto afirmar que Doom en sí se ha convertido en un LLM. El checkpoint no tiene capacidad lingüística aprendida y no implementa el juego completo. «Renderizador alojado en un transformer» es una descripción más precisa.

El enfoque de Cursor Horizon debería preservar esa distinción. El proyecto amplía lo que puede representar un archivo de modelo estándar, pero no muestra una nueva vía competitiva para la computación gráfica.

Tampoco ha recibido una verificación independiente amplia. El repositorio proporciona código, pesos, prompts, mediciones y herramientas de comparación. Reproducir el resultado insignia todavía requiere hardware costoso y una capacidad de descarga considerable.

La reacción de la comunidad refleja ambas caras. Los desarrolladores elogiaron la idea del compilador y se rieron de su rendimiento. Otros preguntaron si las salidas paralelas, arquitecturas alternativas o sistemas de difusión renderizarían fotogramas con mayor eficiencia.

Esas sugerencias pasan por alto parte de la restricción deliberada del proyecto. Porter quería un modelo estándar de generación de texto que las clases habituales de Hugging Face pudieran cargar. Esa elección vinculó el renderizador a un ineficiente bucle de un token por paso.

Cambiar la arquitectura podría mejorar la velocidad, pero debilitaría la demostración. El proyecto resulta interesante porque acepta las limitaciones de un transformer causal convencional y aun así completa el proceso de renderizado.

Qué Debería Vigilar Cursor Horizon a Continuación

La próxima prueba no es otra captura de pantalla impresionante. Es si personas ajenas al proyecto pueden reproducir, comprimir y generalizar la ejecución compilada.

La primera señal es la reproducción independiente. Un tercero debería ejecutar el checkpoint de baja resolución publicado, comparar su salida con el renderizador de referencia y publicar detalles de hardware y software.

Una reproducción exitosa reforzaría la afirmación de que un checkpoint estándar ejecuta el grafo documentado. Una salida divergente revelaría sensibilidad a las versiones de transformer, los kernels numéricos, la ubicación de dispositivos o el comportamiento de coma flotante.

La segunda señal es la ejecución con menor precisión. Una compilación validada en bf16, fp16 o cuantizada reduciría la barrera de hardware del proyecto. También pondría a prueba si torchwright puede gestionar la cancelación residual y las comparaciones con precisión reducida.

El éxito facilitaría el estudio y la distribución de transformers compilados. El fracaso aclararía que el comportamiento numérico exacto sigue siendo una limitación importante de este modelo de programación.

La tercera señal es una compatibilidad más amplia con escenas. El mismo checkpoint debería renderizar múltiples posiciones, direcciones y regiones compatibles del mapa sin recompilación. Las comparaciones publicadas deberían cubrir más que la vista insignia de E1M1.

Esa prueba diferenciaría una implementación de renderizador general de una ruta de demostración altamente optimizada. También mostraría cómo se comporta el mecanismo de estado de solo anexado a medida que varían la geometría y el número de tokens.

El paralelismo sigue siendo una cuestión importante a más largo plazo. El diseño actual de Porter utiliza un token generado para cada paso de cálculo acotado. Un sistema que emitiera varias operaciones seguras por pasada podría reducir la enorme carga de decodificación.

Sin embargo, ese cambio debe preservar la afirmación central del proyecto. Trasladar cálculos de geometría o decisiones de visibilidad al código del host mejoraría el rendimiento reubicando el renderizador, no mejorando la ejecución de transformers compilados.

Los futuros ejemplos de torchwright podrían resultar más informativos que fotogramas de Doom más rápidos. Los analizadores sintácticos deterministas, los validadores de protocolos, las calculadoras y los módulos algorítmicos transparentes encajan mejor con las fortalezas del compilador que los gráficos en tiempo real.

La lógica compilada también podría combinarse con componentes entrenados. Un modelo aprendido podría manejar lenguaje ambiguo mientras una subred construida impone un cálculo o protocolo. Esa posibilidad sigue siendo especulativa y técnicamente difícil.

Los investigadores de seguridad también deberían vigilar los formatos de checkpoint estándar. Los escáneres de modelos existentes suelen centrarse en código serializado, carga insegura o archivos sospechosos. Los pesos construidos directamente introducen comportamiento sin distribuir código ejecutable convencional.

Eso no convierte a torchwright en algo malicioso. Su código fuente e intención son inusualmente abiertos. La lección más amplia es que «sin código personalizado» no significa «sin comportamiento programado».

Los desarrolladores también deberían evitar tratar el número de parámetros como una puntuación de inteligencia. Este checkpoint tiene 21.000 millones de parámetros porque su compilador traduce un renderizador a una arquitectura engorrosa. El tamaño por sí solo revela poco sobre conocimiento aprendido o razonamiento útil.

Para los lectores de Cursor Horizon, la conclusión práctica es un modelo mental más preciso de los transformers. El entrenamiento es una forma de fijar sus pesos. La compilación es otra, incluso cuando el resultado es tremendamente ineficiente.

El proyecto es más valioso como argumento ejecutable. Muestra que la infraestructura de modelos conocida puede transportar programas deterministas, no solo memorias estadísticas. También demuestra por qué los ordenadores convencionales siguen siendo excepcionalmente buenos en la computación convencional.

Intenta leer el rastro de ejecución, inspeccionar el grafo del compilador o reproducir el punto de control más pequeño. Después plantea la pregunta que importa más allá de Doom: ¿qué algoritmos obtienen alguna ventaja de la ejecución nativa de transformadores y cuáles se convierten simplemente en curiosidades costosas?