Um Transformer de 21B de Parâmetros Executa o Renderizador de Doom Sem Treinamento

Cursor Horizon agora tem um ponto de referência técnico incomum: um transformer de 21 bilhões de parâmetros que renderiza Doom sem passar por treinamento. O desenvolvedor Rob Porter compilou o algoritmo de renderização do jogo diretamente nos pesos do transformer. O resultado desafia a premissa de que todo transformer grande aprendeu seu comportamento a partir de dados.

Este modelo não prevê como um quadro de Doom deveria parecer. Ele executa um processo de renderização traduzido, um token gerado por vez. Um prompt fornece a geometria da cena e o estado da câmera. A saída contém cálculos intermediários e comandos de desenho que um pequeno programa host converte em pixels.

Essa distinção separa o projeto de experimentos generativos de Doom treinados com vídeos de jogabilidade. Ela também cria a tensão central por trás desta história do Cursor Horizon. A inferência de transformers se tornou um alvo estranho para software convencional, mas o programa resultante é drasticamente mais lento que o jogo original.

Os artefatos públicos tornam a alegação excepcionalmente verificável. Porter lançou o compilador, o grafo do renderizador, os checkpoints, o prompt, as ferramentas de decodificação e uma implementação de referência. No entanto, a maior parte dos resultados de desempenho e precisão ainda vem dos próprios testes do projeto, e não de replicação independente.

O Renderizador de Doom Se Tornou um Checkpoint de Transformer Padrão

A mudança importante não é que um modelo de IA produziu uma imagem de Doom. É que código de renderização comum se tornou os pesos do modelo.

Porter publicou o projeto em 13 de agosto de 2026, seguido por uma publicação detalhada para a comunidade. Seu texto técnico descreve um compilador chamado torchwright. Ele transforma grafos de computação nos pesos de atenção e feed-forward de um transformer apenas com decodificador.

Não há ciclo de otimização, corpus de treinamento, atualização por gradiente ou aproximação aprendida da jogabilidade de Doom. O compilador calcula os pesos do checkpoint a partir de um grafo escrito em Python. Esses pesos codificam as operações de que o renderizador precisa durante a execução.

O artefato gerado usa a arquitetura padrão Phi3ForCausalLM. Isso importa porque o Hugging Face Transformers já sabe como carregá-lo e executá-lo. Os usuários não precisam de código de modelo personalizado nem da configuração potencialmente sensível trust_remote_code=True.

O checkpoint principal contém 38 camadas de transformer e aproximadamente 21 bilhões de parâmetros. Seus fragmentos de pesos fp32 ocupam 85,87 GB. Uma versão menor, de 80 por 50, usa 70 camadas e 34,09 GB de fragmentos fp32.

O checkpoint maior recebe um prompt de 3.614 tokens que representa a cena. Em seguida, ele gera 53.747 tokens antes de concluir o quadro. A sequência combinada chega a 57.361 tokens.

Apenas parte dessa saída pinta pixels diretamente. Os tokens restantes representam operações do renderizador, valores calculados, fluxo de controle e estado temporário. Eles funcionam mais como um rastreamento de execução do que como linguagem natural.

O checkpoint publicado inclui a configuração do modelo, o tokenizador, o prompt, a paleta e os utilitários de decodificação. Seu tokenizador usa palavras legíveis para operações e valores. Essa escolha torna partes do rastreamento de execução compreensíveis sem decodificar IDs de token arbitrários.

O programa host executa uma tarefa deliberadamente limitada. Ele mantém uma posição de cursor, seleciona cores da paleta de Doom e pinta as sequências de pixels solicitadas. Ele não calcula visibilidade, geometria, ordenação de paredes, coordenadas de textura ou oclusão.

Cinco comandos de saída controlam o desenho. Dois comandos definem as coordenadas do cursor. Dois escolhem se o cursor avança horizontal ou verticalmente. O quinto pinta uma sequência de pixels com uma cor e largura especificadas.

Esse limite é central para a credibilidade do projeto. Um modelo que simplesmente pedisse a um software externo para renderizar Doom seria menos interessante. Aqui, o checkpoint supostamente realiza o trabalho de renderização dependente da visualização, enquanto o host aplica mecanicamente suas instruções de desenho.

O checkpoint não é o jogo Doom completo. Ele não implementa jogabilidade, inimigos, sprites gerais, som ou controle do jogador. Ele implementa uma versão restrita do renderizador para cenas que usam uma biblioteca fixa de texturas.

A saída completa usa a resolução de exibição de 320 por 200 do Doom no modo de baixa definição. O renderizador calcula 160 colunas e exibe cada uma em dois pixels. Nove texturas de parede e seis texturas de piso ou teto são compiladas no modelo.

A posição do jogador, a direção de visão, a geometria do mapa, as informações dos setores e a árvore de particionamento espacial binária chegam pelo prompt. Uma árvore de particionamento espacial binária, ou árvore BSP, divide o mapa para ordenar a visibilidade com eficiência.

Essas entradas podem mudar sem reconstruir o checkpoint, desde que a cena permaneça dentro dos limites de textura e configuração compilados. Adicionar uma textura não suportada exige recompilação.

É por isso que o enquadramento do Cursor Horizon merece atenção. O projeto trata um checkpoint de transformer como um formato de pacote executável, e não como um repositório de conhecimento aprendido. Seus parâmetros são material de programa gerado por um compilador.

Por Que o Cursor Horizon Desafia o Modelo de Treinamento Primeiro

Torwright transforma a arquitetura de transformer em uma base de computação determinística, embora não ofereça substituição prática para processadores convencionais.

A maioria dos grandes modelos de linguagem adquire comportamento por meio de treinamento. Engenheiros escolhem uma arquitetura, expõem-na a dados, medem erros e ajustam os pesos por descida de gradiente. O modelo final contém padrões aprendidos com esses exemplos.

Torwright inverte esse fluxo de trabalho. Um desenvolvedor define um grafo de computação, e o compilador constrói pesos que executam suas operações. O transformer concluído ainda prevê um token após o outro, mas o processo de previsão segue um programa projetado.

A distinção se assemelha à diferença entre aprender multiplicação com exemplos e executar um circuito de multiplicação. Ambos podem produzir a mesma resposta. Suas origens internas, limites de confiabilidade e modos de falha diferem.

O compilador torchwright de código aberto oferece suporte a operações lineares, buscas baseadas em atenção, comparações, seleção e multiplicação. Ele agenda nós do grafo entre camadas de transformer e armazena valores calculados no fluxo residual.

Um fluxo residual é o vetor em evolução que passa pelas camadas de um transformer. Torchwright atribui partes desse vetor a valores do programa. Quando um valor deixa de ser necessário, outra operação o cancela e reutiliza seu espaço.

A atenção realiza mais do que associação semântica nessa configuração. Ela recupera valores de tokens anteriores ao combinar campos estruturados. Esses campos podem representar um identificador de nó, profundidade da árvore, tipo de operação ou coordenada de tela.

As camadas feed-forward implementam operações não lineares. Torchwright oferece bibliotecas de operações construídas a partir de ativações ReLU ou SwiGLU. O compilador converte cada operação do grafo em linhas específicas de pesos feed-forward ou cabeças de atenção.

Essa abordagem tem precedentes acadêmicos. RASP introduziu uma linguagem de programação cujas primitivas são mapeadas para operações de transformer. A pesquisa Tracr da DeepMind compilou programas RASP em pesos de transformer para experimentos de interpretabilidade.

Torwright estende essa direção para grafos regulares de computação em Python e um formato de saída Phi-3 padrão. O alvo é significativo porque o software de inferência existente pode carregar o resultado sem compreender sua origem incomum.

Essa compatibilidade cria uma possibilidade provocativa. Um checkpoint padrão pode conter comportamento estatístico aprendido, lógica compilada deliberadamente ou uma mistura de ambos. Sua estrutura de arquivo, por si só, não revelaria qual caminho produziu seus pesos.

Para desenvolvedores, isso muda como artefatos de modelo podem ser interpretados. A contagem de parâmetros normalmente atua como um sinal aproximado de capacidade aprendida e custo de inferência. Aqui, 21 bilhões de parâmetros refletem principalmente um alvo de compilação extremamente ineficiente.

O número não significa que o checkpoint possua amplo conhecimento linguístico. Ele não consegue responder a perguntas gerais nem improvisar cenas de Doom fora do renderizador suportado. Seus pesos implementam um programa restrito, e não um modelo linguístico aberto.

Portanto, Cursor Horizon captura um problema de fronteira mais amplo. O ecossistema de transformers agora fornece carregadores, aceleradores, fragmentação, ferramentas de implantação e classes de modelo padronizadas. Um compilador pode explorar essa infraestrutura para software que nunca foi treinado.

Isso não torna transformers preferíveis a CPUs. Mostra que sua maquinaria de execução é geral o suficiente para hospedar algoritmos construídos explicitamente. Generalidade, eficiência e utilidade continuam sendo questões separadas.

A contribuição mais forte do projeto é conceitual, e não comercial. Ele torna visível a distinção entre arquitetura e treinamento. Um transformer é uma estrutura matemática. Um LLM é uma aplicação familiar construída ao treinar essa estrutura com linguagem.

O modelo de Porter remove o processo de aprendizado enquanto preserva o comportamento de inferência familiar. Ele aceita tokens, aplica camadas de atenção e feed-forward, seleciona o próximo token e repete. O ciclo parece comum mesmo quando a computação em seu interior não é.

Essa propriedade também oferece um ambiente de pesquisa controlado. Como cada peso vem de operações conhecidas do grafo, os pesquisadores podem rastrear por que um valor aparece. Isso difere fortemente da interpretação de um modelo cujas características internas emergiram do treinamento.

No entanto, o checkpoint de Doom é muito maior do que os modelos típicos de teste de interpretabilidade. Sua escala demonstra que construções compiladas podem alcançar a infraestrutura de modelos moderna. Ela também torna a inspeção e a reprodução independente dispendiosas.

O Transformer Executa Doom Um Token de Cada Vez

O renderizador funciona convertendo o estado mutável de execução de Doom em um histórico de tokens apenas para acréscimo, que a atenção pode pesquisar.

O renderizador de Doom percorre uma árvore BSP de regiões próximas para regiões distantes. Ele projeta paredes em colunas da tela, acompanha quais áreas já estão cobertas e ignora geometria oculta por superfícies mais próximas.

O código convencional atualiza variáveis e estruturas de dados na memória. A geração autorregressiva não pode modificar tokens anteriores. Cada novo token entra em uma sequência apenas para acréscimo que permanece disponível para passagens posteriores pelo transformer.

O renderizador compilado resolve essa incompatibilidade representando cada mudança de estado como mais um token. Operações posteriores usam atenção para encontrar o registro relevante mais recente ou combinar vários registros anteriores.

Uma travessia recursiva de árvore normalmente depende de uma pilha de chamadas. Em vez disso, o modelo emite registros de trilha durante a descida. Quando alcança uma folha, a atenção recupera a trilha apropriada e determina onde a execução deve continuar.

A cobertura de paredes exige outra estratégia. Doom armazena intervalos horizontais cobertos em uma estrutura mutável chamada solidsegs. Esses intervalos ajudam a evitar o desenho de paredes já ocultas por geometria mais próxima.

O transformer não pode mesclar nem sobrescrever registros de intervalos anteriores. Ele acrescenta cada novo intervalo coberto. As operações subsequentes consultam o histórico acumulado para descobrir se uma coluna está coberta e onde o intervalo coberto termina.

Pisos e tetos seguem um padrão relacionado. A passagem pelas paredes registra seus limites visíveis para cada coluna da tela. Uma passagem posterior recupera esses registros e emite sequências horizontais de desenho.

A sequência de tokens resultante desempenha várias funções. Ela é um fluxo de instruções, memória de trabalho, pilha de chamadas, registro de estado e protocolo de saída. A atenção fornece o mecanismo de consulta que conecta essas funções.

Cálculos longos também são divididos entre tokens gerados. Uma camada de transformer só pode executar uma quantidade limitada de trabalho sequencial antes de encaminhar seu fluxo residual. Cadeias de dependência mais longas exigiriam mais camadas.

O renderizador às vezes emite um resultado intermediário e o consome durante uma etapa posterior de decodificação. Essa estratégia usa mais tokens para reduzir a profundidade necessária em cada etapa.

A projeção de paredes ilustra essa troca. O modelo calcula ângulos do mundo, converte-os em ângulos relativos à câmera e então projeta os pontos finais na tela. Tokens de ângulo intermediários separam essas etapas dependentes.

Esse design mantém o modelo principal em 38 camadas. Ele também contribui para os 53.747 tokens de rollout necessários para um quadro. Cada transferência intermediária extra acrescenta outra passagem completa pelo modelo.

O código-fonte do renderizador expõe esse pipeline. Os módulos lidam com entradas da cena, travessia, projeção, rasterização, texturas e o protocolo de saída. Um renderizador Python separado atua como referência de correção.

O modelo gera tokens de forma gulosa, ou seja, seleciona o próximo token com maior pontuação sem amostragem. A aleatoriedade seria inadequada porque o checkpoint foi projetado para executar lógica determinística.

A palavra-chave Cursor Horizon se torna útil aqui como metáfora para o limite de estado do modelo. Seu cursor de saída avança por uma imagem renderizada, enquanto seu horizonte de atenção alcança o histórico de execução anterior.

Ainda assim, o mecanismo é mais literal do que poético. Cada nova operação pode inspecionar fatos anteriores da cena e registros gerados. Nada no processo exige a flexibilidade semântica associada a modelos conversacionais.

O prompt funciona como memória somente de leitura. Ele contém fatos do mapa independentes da visualização, além da posição e direção do jogador. A parte gerada funciona como memória de trabalho somente para acréscimos para cálculos dependentes da visualização.

Posteriormente, o host interpreta tokens de desenho usando a paleta de 256 cores de Doom. Ele move um cursor de software e pinta as sequências solicitadas. A demonstração mínima de Porter implementa essa parte em 43 linhas de Python.

Esse pequeno host não prova que todo cálculo de renderização esteja dentro do checkpoint. No entanto, o código público torna o limite verificável. Revisores podem inspecionar a construção do prompt, os módulos do grafo, a decodificação da saída e a comparação de referência.

O projeto relata verificações pixel a pixel contra seu renderizador Python. Para o quadro principal, mediu cobertura completa de pixels, 99,9% de concordância dentro das opções de cores permitidas e 96,7% de concordância exata.

Esses números diferem ligeiramente dos 97% arredondados usados no artigo original. O arquivo de fatos canônicos do repositório atribui as medições mais recentes a uma renderização de produção de 9 de agosto.

O checkpoint de menor resolução teria alcançado cobertura completa, concordância total de cores dentro das opções e 93,9% de concordância exata. Seu quadro continha 3.964 pixels comparados.

Estas são medições relatadas pelo projeto. Testes independentes ainda não estabeleceram se os mesmos resultados se mantêm em diferentes ambientes, prompts ou variações de cena.

O Resultado Real São 35 Quadros por Dia

O projeto é bem-sucedido como demonstração de compilador justamente porque falha de forma tão dramática como renderizador prático de Doom.

O Doom original tinha como alvo 35 quadros por segundo em hardware do início dos anos 1990. O checkpoint completo de Porter produz aproximadamente 0,0004 quadros por segundo em um acelerador Nvidia B200.

A decodificação gulosa levou 2.383,5 segundos durante a execução de produção relatada. O carregamento do modelo e outras sobrecargas elevaram o tempo de ponta a ponta para 2.528,1 segundos, ou 42,1 minutos.

Isso resulta em cerca de 35 quadros por dia, supondo operação contínua e tempos semelhantes. A comparação se tornou a piada mais memorável do projeto. Ela também expõe o custo central de compilar software comum em inferência autorregressiva.

Cada token emitido exige outra passagem por um modelo de 21 bilhões de parâmetros. Desenhar um quadro envolve dezenas de milhares dessas passagens. A arquitetura serializa operações que o hardware convencional executa por meio de instruções compactas e pipelines paralelos.

A execução no B200 teria reservado 151 GiB de memória no pico. Só o checkpoint ocupa quase 80 GiB quando medido em gibibytes binários. Não é um programa que a maioria dos leitores possa testar em uma GPU de desktop.

O checkpoint para consumidores reduz a resolução para 80 por 50 pixels. Ele produz um rollout de 7.007 tokens e supostamente decodifica em 338,3 segundos em uma A100 com 80 GB de memória.

Seu checkpoint de 34,09 GB também pode ser distribuído entre duas GPUs de consumo de 32 GB por meio de mapeamento automático de dispositivos. Essa versão torna a reprodução mais acessível, embora continue extravagante para um quadro minúsculo.

A precisão cria outra limitação. Os modelos publicados usam pesos fp32. Implantações convencionais de LLMs frequentemente reduzem memória e computação com formatos de menor precisão ou quantização.

A quantização é arriscada aqui porque erros numéricos não apenas suavizam probabilidades linguísticas. Eles podem corromper o estado do programa, comparações, consultas semelhantes a endereços e cancelamentos dentro do fluxo residual.

A documentação do compilador de Torwright reconhece que algumas construções não lineares usam aproximações lineares por partes. Seus testes medem limites de erro para operações individuais e comparam nós de grafos compilados com avaliação direta.

Essas salvaguardas fornecem evidências, não certeza matemática para cada execução completa. Limites de erro por operação não se compõem automaticamente em cadeias longas. Por isso, o compilador depende de sondagens mais amplas do grafo e comparações de saída.

A discussão pública do projeto no Reddit levantou essa preocupação diretamente. Porter disse que esperava que uma quantização descuidada produzisse saída corrompida, em vez de uma imagem de menor fidelidade. Ele também observou que não havia testado esse cenário.

Outra limitação diz respeito à generalidade. O checkpoint oferece suporte a uma região selecionada, resolução fixa e às texturas necessárias ao redor da área inicial de E1M1. Ele não reproduz o renderizador inteiro em todo o conteúdo de Doom.

Sprites continuam sem implementação. A arma e a barra de status são fixadas no estado inicial com a pistola. O modelo renderiza uma cena, não um loop de jogo interativo com sistemas normais de gameplay.

O prompt do mapa do projeto também passa por preparação antes da inferência. O código do lado do host recorta o nível para uma região fixa no espaço do mundo e codifica fatos estáticos como tokens. O repositório descreve esse limite como comparável ao carregamento de um nível.

Críticos podem perguntar, de forma razoável, se isso ainda conta como Doom rodando dentro de um transformer. A resposta mais defensável é mais restrita: a lógica de renderização dependente da visualização roda dentro de um checkpoint compilado para uma cena limitada de Doom.

Seria impreciso afirmar que o próprio Doom se tornou um LLM. O checkpoint não tem habilidade linguística aprendida e não implementa o jogo completo. “Renderizador hospedado em transformer” é a descrição mais clara.

O ângulo do Cursor Horizon deve preservar essa distinção. O projeto amplia o que um arquivo de modelo padrão pode representar, mas não mostra uma nova rota competitiva para computação gráfica.

Ele também não recebeu verificação independente ampla. O repositório fornece código, pesos, prompts, medições e ferramentas de comparação. Reproduzir o resultado principal ainda exige hardware caro e capacidade substancial de download.

A reação da comunidade reflete ambos os lados. Desenvolvedores elogiaram a ideia do compilador e riram de seu desempenho. Outros perguntaram se saídas paralelas, arquiteturas alternativas ou sistemas de difusão renderizariam quadros com mais eficiência.

Essas sugestões deixam de lado parte da restrição deliberada do projeto. Porter queria um modelo padrão de geração de texto que classes comuns do Hugging Face pudessem carregar. Essa escolha vinculou o renderizador a um loop ineficiente de um token por etapa.

Mudar a arquitetura poderia melhorar a velocidade, mas enfraqueceria a demonstração. O projeto é interessante porque aceita as limitações de um transformer causal convencional e ainda conclui o processo de renderização.

O Que o Cursor Horizon Deve Acompanhar Em Seguida

O próximo teste não é outra captura de tela impressionante. É saber se terceiros conseguem reproduzir, comprimir e generalizar a execução compilada.

O primeiro sinal é a reprodução independente. Um terceiro deve executar o checkpoint de baixa resolução lançado, comparar sua saída com o renderizador de referência e publicar detalhes de hardware e software.

Uma replicação bem-sucedida reforçaria a alegação de que um checkpoint padrão executa o grafo documentado. Uma saída divergente exporia sensibilidade a versões de transformers, kernels numéricos, posicionamento de dispositivos ou comportamento de ponto flutuante.

O segundo sinal é a execução com menor precisão. Uma compilação bf16, fp16 ou quantizada validada reduziria a barreira de hardware do projeto. Ela também testaria se torchwright consegue gerenciar cancelamento residual e comparações sob precisão reduzida.

O sucesso tornaria transformers compilados mais fáceis de estudar e distribuir. O fracasso deixaria claro que o comportamento numérico exato continua sendo uma grande restrição para esse modelo de programação.

O terceiro sinal é um suporte mais amplo a cenas. O mesmo checkpoint deveria renderizar múltiplas posições, direções e regiões compatíveis do mapa sem recompilação. Comparações publicadas deveriam cobrir mais do que a visualização principal de E1M1.

Esse teste separaria uma implementação de renderizador geral de um caminho de demonstração altamente otimizado. Ele também mostraria como o mecanismo de estado somente para acréscimos se comporta à medida que a geometria e as contagens de tokens variam.

O paralelismo continua sendo uma questão importante no longo prazo. O design atual de Porter usa um token gerado para cada etapa de computação limitada. Um sistema que emitisse várias operações seguras por passagem poderia reduzir a enorme carga de decodificação.

No entanto, essa mudança deve preservar a alegação central do projeto. Mover cálculos de geometria ou decisões de visibilidade para o código do host melhoraria o desempenho ao realocar o renderizador, não ao aprimorar a execução de transformers compilados.

Exemplos futuros de torchwright podem se mostrar mais informativos do que quadros mais rápidos de Doom. Analisadores determinísticos, validadores de protocolo, calculadoras e módulos algorítmicos transparentes se encaixam melhor nos pontos fortes do compilador do que gráficos em tempo real.

A lógica compilada também poderia ser combinada com componentes treinados. Um modelo aprendido poderia lidar com linguagem ambígua enquanto uma sub-rede construída impõe um cálculo ou protocolo. Essa possibilidade continua especulativa e tecnicamente difícil.

Pesquisadores de segurança também devem acompanhar formatos de checkpoint padrão. Scanners de modelos existentes frequentemente se concentram em código serializado, carregamento inseguro ou arquivos suspeitos. Pesos construídos diretamente introduzem comportamento sem enviar código executável convencional.

Isso não torna torchwright malicioso. Seu código-fonte e sua intenção são excepcionalmente abertos. A lição mais ampla é que “sem código personalizado” não significa “sem comportamento programado”.

Desenvolvedores também devem resistir a tratar a contagem de parâmetros como uma pontuação de inteligência. Este checkpoint tem 21 bilhões de parâmetros porque seu compilador mapeia um renderizador para uma arquitetura desajeitada. O tamanho, por si só, revela pouco sobre conhecimento aprendido ou raciocínio útil.

Para os leitores do Cursor Horizon, a conclusão prática é um modelo mental mais preciso de transformers. O treinamento é uma forma de definir seus pesos. A compilação é outra, mesmo quando o resultado é absurdamente ineficiente.

O projeto é mais valioso como um argumento executável. Ele mostra que uma infraestrutura de modelos conhecida pode transportar programas determinísticos, não apenas memórias estatísticas. Também mostra por que computadores convencionais continuam excepcionalmente bons em computação convencional.

Tente ler o rastro de execução, inspecionar o grafo do compilador ou reproduzir o checkpoint menor. Em seguida, faça a pergunta que importa para além de Doom: quais algoritmos ganham algo com a execução nativa em transformadores e quais se tornam apenas curiosidades dispendiosas?