Ein Transformer mit 21 Milliarden Parametern führt Dooms Renderer ohne Training aus

Cursor Horizon hat nun einen ungewöhnlichen technischen Referenzpunkt: einen Transformer mit 21 Milliarden Parametern, der Doom rendert, ohne trainiert worden zu sein. Entwickler Rob Porter kompilierte den Rendering-Algorithmus des Spiels direkt in Transformer-Gewichte. Das Ergebnis stellt die Annahme infrage, dass jeder große Transformer sein Verhalten aus Daten gelernt hat.

Dieses Modell sagt nicht voraus, wie ein Doom-Frame aussehen sollte. Es führt einen übersetzten Rendering-Prozess aus – jeweils ein generiertes Token nach dem anderen. Ein Prompt liefert Szenengeometrie und Kamerazustand. Die Ausgabe enthält Zwischenberechnungen und Zeichenbefehle, die ein kleines Hostprogramm in Pixel umwandelt.

Dieser Unterschied grenzt das Projekt von generativen Doom-Experimenten ab, die mit Gameplay-Videos trainiert wurden. Er erzeugt auch die zentrale Spannung dieser Cursor-Horizon-Geschichte. Transformer-Inferenz ist zu einem seltsamen Ziel für konventionelle Software geworden, doch das resultierende Programm ist drastisch langsamer als das Originalspiel.

Die öffentlichen Artefakte machen die Behauptung ungewöhnlich gut überprüfbar. Porter veröffentlichte Compiler, Renderer-Graph, Checkpoints, Prompt, Dekodierungswerkzeuge und eine Referenzimplementierung. Die meisten Leistungs- und Genauigkeitsergebnisse stammen jedoch weiterhin aus den eigenen Tests des Projekts und nicht aus unabhängigen Replikationen.

Dooms Renderer wurde zu einem Standard-Transformer-Checkpoint

Die wichtige Veränderung besteht nicht darin, dass ein KI-Modell ein Doom-Bild erzeugt hat. Sie besteht darin, dass gewöhnlicher Rendering-Code zu den Gewichten des Modells wurde.

Porter veröffentlichte das Projekt am 13. August 2026, gefolgt von einem ausführlichen Community-Beitrag. Seine technische Ausarbeitung beschreibt einen Compiler namens torchwright. Er wandelt Berechnungsgraphen in die Attention- und Feed-Forward-Gewichte eines Decoder-only-Transformers um.

Es gibt keine Optimierungsschleife, keinen Trainingskorpus, keine Gradientenaktualisierung und keine gelernte Annäherung an Doom-Gameplay. Der Compiler berechnet die Gewichte des Checkpoints aus einem in Python geschriebenen Graphen. Diese Gewichte kodieren die Operationen, die der Renderer während der Ausführung benötigt.

Das erzeugte Artefakt verwendet die Standardarchitektur Phi3ForCausalLM. Das ist relevant, weil Hugging Face Transformers es bereits laden und ausführen kann. Nutzer benötigen keinen benutzerdefinierten Modellcode und auch nicht die potenziell sensible Einstellung trust_remote_code=True.

Der Flaggschiff-Checkpoint enthält 38 Transformer-Schichten und ungefähr 21 Milliarden Parameter. Seine fp32-Gewichts-Shards belegen 85,87 GB. Eine kleinere 80-mal-50-Version verwendet 70 Schichten und 34,09 GB fp32-Shards.

Der größere Checkpoint erhält einen Prompt mit 3.614 Tokens, der die Szene repräsentiert. Anschließend generiert er 53.747 Tokens, bevor der Frame fertig ist. Die kombinierte Sequenz erreicht 57.361 Tokens.

Nur ein Teil dieser Ausgabe zeichnet direkt Pixel. Die übrigen Tokens repräsentieren Renderer-Operationen, berechnete Werte, Kontrollfluss und temporären Zustand. Sie funktionieren eher wie ein Ausführungsprotokoll als wie natürliche Sprache.

Der veröffentlichte Checkpoint enthält Modellkonfiguration, Tokenizer, Prompt, Palette und Dekodierungswerkzeuge. Sein Tokenizer verwendet lesbare Wörter für Operationen und Werte. Dadurch sind Teile des Ausführungsprotokolls verständlich, ohne beliebige Token-IDs dekodieren zu müssen.

Das Hostprogramm übernimmt bewusst nur eine eng begrenzte Aufgabe. Es speichert eine Cursorposition, wählt Farben aus Dooms Palette und zeichnet angeforderte Pixelreihen. Es berechnet weder Sichtbarkeit, Geometrie, Wandreihenfolge, Texturkoordinaten noch Verdeckung.

Fünf Ausgabebefehle steuern das Zeichnen. Zwei Befehle setzen die Koordinaten des Cursors. Zwei legen fest, ob sich der Cursor horizontal oder vertikal bewegt. Der fünfte zeichnet eine Pixelreihe mit einer festgelegten Farbe und Breite.

Diese Grenze ist zentral für die Glaubwürdigkeit des Projekts. Ein Modell, das externe Software lediglich auffordern würde, Doom zu rendern, wäre weniger interessant. Hier übernimmt der Checkpoint Berichten zufolge die blickwinkelabhängige Rendering-Arbeit, während der Host seine Zeichenanweisungen mechanisch umsetzt.

Der Checkpoint ist nicht das vollständige Doom-Spiel. Er implementiert weder Gameplay, Gegner, allgemeine Sprites, Sound noch Spielersteuerung. Er implementiert eine eingeschränkte Version des Renderers für Szenen mit einer festen Texturbibliothek.

Die vollständige Ausgabe nutzt Dooms Displayauflösung von 320 mal 200 im Low-Detail-Modus. Der Renderer berechnet 160 Spalten und zeigt jede über zwei Pixel hinweg an. Neun Wandtexturen und sechs Boden- oder Deckentexturen sind in das Modell kompiliert.

Spielerposition, Blickrichtung, Karten-Geometrie, Sektorinformationen und der Binary-Space-Partitioning-Baum gelangen über den Prompt hinein. Ein Binary-Space-Partitioning-Baum, kurz BSP-Baum, unterteilt die Karte für eine effiziente Sichtbarkeitsreihenfolge.

Diese Eingaben können sich ändern, ohne den Checkpoint neu zu erstellen, sofern die Szene innerhalb der kompilierten Textur- und Konfigurationsgrenzen bleibt. Das Hinzufügen einer nicht unterstützten Textur erfordert eine Neukompilierung.

Deshalb verdient die Cursor-Horizon-Einordnung Aufmerksamkeit. Das Projekt behandelt einen Transformer-Checkpoint als ausführbares Paketformat und nicht als Speicher für gelerntes Wissen. Seine Parameter sind von einem Compiler erzeugtes Programmmaterial.

Warum Cursor Horizon das Trainings-zuerst-Modell infrage stellt

Torwright verwandelt Transformer-Architektur in ein deterministisches Rechensubstrat, bietet jedoch keinen praktischen Ersatz für konventionelle Prozessoren.

Die meisten großen Sprachmodelle erwerben ihr Verhalten durch Training. Ingenieure wählen eine Architektur, setzen sie Daten aus, messen Fehler und passen Gewichte mittels Gradientenabstieg an. Das finale Modell enthält Muster, die aus diesen Beispielen gelernt wurden.

Torwright kehrt diesen Arbeitsablauf um. Ein Entwickler definiert einen Berechnungsgraphen, und der Compiler konstruiert Gewichte, die dessen Operationen ausführen. Der fertige Transformer sagt weiterhin ein Token nach dem anderen voraus, doch der Vorhersageprozess folgt einem entworfenen Programm.

Der Unterschied ähnelt dem zwischen dem Erlernen der Multiplikation anhand von Beispielen und dem Ausführen einer Multiplikationsschaltung. Beide können dieselbe Antwort liefern. Ihre internen Ursprünge, Zuverlässigkeitsgrenzen und Fehlermodi unterscheiden sich.

Der Open-Source-torchwright-Compiler unterstützt lineare Operationen, Attention-basierte Lookups, Vergleiche, Auswahl und Multiplikation. Er plant Graphknoten über Transformer-Schichten hinweg und speichert berechnete Werte im Residual Stream.

Ein Residual Stream ist der sich entwickelnde Vektor, der durch die Schichten eines Transformers gereicht wird. Torchwright weist Teilen dieses Vektors Programmwerte zu. Sobald ein Wert nicht mehr benötigt wird, hebt eine andere Operation ihn auf und verwendet seinen Platz erneut.

Attention übernimmt in dieser Anordnung mehr als semantische Assoziation. Sie ruft Werte aus früheren Tokens ab, indem sie strukturierte Felder abgleicht. Diese Felder können eine Knotenkennung, Baumtiefe, Operationsart oder Bildschirmkoordinate repräsentieren.

Die Feed-Forward-Schichten implementieren nichtlineare Operationen. Torchwright bietet Operationsbibliotheken, die auf ReLU- oder SwiGLU-Aktivierungen basieren. Der Compiler wandelt jede Graphoperation in spezifische Zeilen von Feed-Forward-Gewichten oder Attention-Heads um.

Dieser Ansatz hat akademische Vorläufer. RASP führte eine Programmiersprache ein, deren Primitive auf Transformer-Operationen abgebildet werden. DeepMinds Tracr-Forschung kompilierte RASP-Programme für Interpretierbarkeitsexperimente in Transformer-Gewichte.

Torwright erweitert diese Richtung auf reguläre Python-Berechnungsgraphen und ein Standardausgabeformat für Phi-3. Das Ziel ist bedeutsam, weil vorhandene Inferenzsoftware das Ergebnis laden kann, ohne seinen ungewöhnlichen Ursprung zu verstehen.

Diese Kompatibilität eröffnet eine provokante Möglichkeit. Ein Standard-Checkpoint könnte gelerntes statistisches Verhalten, absichtlich kompilierte Logik oder eine Mischung aus beidem enthalten. Seine Dateistruktur allein würde nicht verraten, auf welchem Weg seine Gewichte entstanden sind.

Für Entwickler verändert das die Interpretation von Modellartefakten. Die Parameterzahl dient normalerweise als grobes Signal für gelernte Kapazität und Inferenzkosten. Hier spiegeln 21 Milliarden Parameter vor allem ein extrem ineffizientes Kompilierungsziel wider.

Die Zahl bedeutet nicht, dass der Checkpoint über breites Sprachwissen verfügt. Er kann keine allgemeinen Fragen beantworten oder Doom-Szenen außerhalb seines unterstützten Renderers improvisieren. Seine Gewichte implementieren ein eingeschränktes Programm und kein offenes Sprachmodell.

Cursor Horizon erfasst damit ein breiteres Grenzproblem. Das Transformer-Ökosystem liefert inzwischen Loader, Beschleuniger, Sharding, Deployment-Werkzeuge und standardisierte Modellklassen. Ein Compiler kann diese Infrastruktur für Software nutzen, die nie trainiert wurde.

Das macht Transformer nicht CPUs überlegen. Es zeigt, dass ihre Ausführungsmechanik allgemein genug ist, um explizit konstruierte Algorithmen zu beherbergen. Allgemeingültigkeit, Effizienz und Nutzen bleiben getrennte Fragen.

Der stärkste Beitrag des Projekts ist eher konzeptionell als kommerziell. Es macht den Unterschied zwischen Architektur und Training sichtbar. Ein Transformer ist eine mathematische Struktur. Ein LLM ist eine vertraute Anwendung, die durch Training dieser Struktur auf Sprache entsteht.

Porters Modell entfernt den Lernprozess, behält jedoch das vertraute Inferenzverhalten bei. Es nimmt Tokens an, wendet Attention- und Feed-Forward-Schichten an, wählt ein nächstes Token und wiederholt den Vorgang. Die Schleife wirkt gewöhnlich, selbst wenn die Berechnung in ihr es nicht ist.

Diese Eigenschaft bietet auch eine kontrollierte Forschungsumgebung. Da jedes Gewicht aus bekannten Graphoperationen stammt, können Forscher nachvollziehen, warum ein Wert erscheint. Das unterscheidet sich deutlich von der Interpretation eines Modells, dessen interne Merkmale durch Training entstanden sind.

Der Doom-Checkpoint ist jedoch weitaus größer als typische Interpretierbarkeitstestmodelle. Seine Größe zeigt, dass kompilierte Konstruktionen moderne Modellinfrastruktur erreichen können. Sie macht Inspektion und unabhängige Reproduktion aber auch teuer.

Der Transformer führt Doom Token für Token aus

Der Renderer funktioniert, indem er Dooms veränderlichen Ausführungszustand in eine nur anhängbare Token-Historie umwandelt, die Attention durchsuchen kann.

Dooms Renderer durchläuft einen BSP-Baum von nahen zu fernen Regionen. Er projiziert Wände auf Bildschirmspalten, verfolgt bereits abgedeckte Bereiche und überspringt Geometrie, die hinter näheren Oberflächen verborgen ist.

Konventioneller Code aktualisiert Variablen und Datenstrukturen im Speicher. Autoregressive Generierung kann frühere Tokens nicht verändern. Jedes neue Token wird einer nur anhängbaren Sequenz hinzugefügt, die für spätere Transformer-Durchläufe verfügbar bleibt.

Der kompilierte Renderer löst diesen Unterschied, indem er jede Zustandsänderung als weiteres Token darstellt. Spätere Operationen verwenden Attention, um den neuesten relevanten Eintrag zu finden oder mehrere frühere Einträge zu kombinieren.

Eine rekursive Baumdurchquerung stützt sich normalerweise auf einen Call Stack. Das Modell gibt stattdessen während des Abstiegs Breadcrumb-Datensätze aus. Wenn es ein Blatt erreicht, ruft Attention den passenden Breadcrumb ab und bestimmt, wo die Ausführung fortgesetzt werden soll.

Die Abdeckung durch Wände erfordert eine weitere Strategie. Doom speichert abgedeckte horizontale Bereiche in einer veränderlichen Struktur namens solidsegs. Diese Bereiche helfen ihm dabei, bereits hinter näherer Geometrie verborgene Wände nicht zu zeichnen.

Der Transformer kann frühere Bereichseinträge nicht zusammenführen oder überschreiben. Er hängt jeden neu abgedeckten Bereich an. Nachfolgende Operationen fragen die angesammelte Historie ab, um festzustellen, ob eine Spalte abgedeckt ist und wo das abgedeckte Intervall endet.

Böden und Decken folgen einem verwandten Muster. Der Wanddurchlauf zeichnet ihre sichtbaren Grenzen für jede Bildschirmspalte auf. Ein späterer Durchlauf ruft diese Datensätze ab und gibt horizontale Zeichenreihen aus.

Die Ergebnisfolge von Tokens erfüllt mehrere Rollen. Sie ist Befehlsstrom, Arbeitsspeicher, Aufrufstack, Zustandsprotokoll und Ausgabeprotokoll. Attention liefert den Suchmechanismus, der diese Rollen verbindet.

Auch lange Berechnungen werden auf erzeugte Tokens verteilt. Eine Transformer-Schicht kann nur eine begrenzte Menge sequenzieller Arbeit leisten, bevor sie ihren Residual Stream weitergibt. Längere Abhängigkeitsketten würden mehr Schichten erfordern.

Der Renderer gibt manchmal ein Zwischenergebnis aus und verarbeitet es bei einem späteren Decodierungsschritt. Diese Strategie verbraucht mehr Tokens, reduziert jedoch die für jeden Schritt benötigte Tiefe.

Die Wandprojektion veranschaulicht den Zielkonflikt. Das Modell berechnet Weltwinkel, wandelt sie in kamerarelative Winkel um und projiziert anschließend Endpunkte auf den Bildschirm. Zwischenliegende Winkel-Tokens trennen diese abhängigen Stufen.

Dieses Design hält das Flaggschiffmodell bei 38 Schichten. Es trägt außerdem zu dem für ein Bild erforderlichen Rollout von 53.747 Tokens bei. Jede zusätzliche Zwischenübergabe fügt einen weiteren vollständigen Modelldurchlauf hinzu.

Der Renderer-Quellcode legt diese Pipeline offen. Module verarbeiten Szeneneingaben, Traversierung, Projektion, Rasterisierung, Texturen und das Ausgabeprotokoll. Ein separater Python-Renderer dient als Referenz für die Korrektheit.

Das Modell erzeugt Tokens greedy, wählt also ohne Sampling jeweils das nächsthöchstbewertete Token. Zufälligkeit wäre ungeeignet, weil der Checkpoint deterministische Logik ausführen soll.

Das Cursor-Horizon-Schlagwort wird hier als Metapher für die Zustandsgrenze des Modells nützlich. Sein Ausgabecursor bewegt sich über ein gerendertes Bild, während sein Attention-Horizont durch den Ausführungsverlauf zurückreicht.

Der Mechanismus ist jedoch wörtlicher als poetisch. Jede neue Operation kann vorhergehende Szenenfakten und erzeugte Datensätze prüfen. Nichts im Prozess erfordert die semantische Flexibilität, die mit Konversationsmodellen verbunden wird.

Der Prompt fungiert als schreibgeschützter Speicher. Er enthält ansichtsunabhängige Kartenfakten sowie Position und Blickrichtung des Spielers. Der generierte Teil dient als ausschließlich erweiterbarer Arbeitsspeicher für ansichtsabhängige Berechnungen.

Der Host interpretiert die Zeichnungs-Tokens später anhand von Dooms 256-Farben-Palette. Er bewegt einen Softwarecursor und zeichnet angeforderte Folgen. Porters minimale Demonstration implementiert diese Seite in 43 Zeilen Python.

Dieser kleine Host beweist nicht, dass jede Rendering-Berechnung im Checkpoint liegt. Der öffentliche Quellcode macht die Grenze jedoch überprüfbar. Prüfer können Prompt-Erstellung, Graphmodule, Ausgabedecodierung und den Referenzvergleich untersuchen.

Das Projekt berichtet über Pixel-für-Pixel-Prüfungen gegen seinen Python-Renderer. Für das Flaggschiffbild wurden vollständige Pixelabdeckung, 99,9 Prozent Übereinstimmung innerhalb der zulässigen Farboptionen und 96,7 Prozent exakte Übereinstimmung gemessen.

Diese Werte weichen leicht von den im ursprünglichen Artikel gerundeten 97 Prozent ab. Die kanonische Fakten-Datei des Repositorys schreibt die jüngsten Messungen einem Produktions-Render vom 9. August zu.

Der Checkpoint mit niedrigerer Auflösung erreichte Berichten zufolge vollständige Abdeckung, vollständige Farbübereinstimmung innerhalb der Optionen und 93,9 Prozent exakte Übereinstimmung. Sein Bild enthielt 3.964 verglichene Pixel.

Dabei handelt es sich um vom Projekt berichtete Messwerte. Unabhängige Tests haben noch nicht festgestellt, ob dieselben Ergebnisse über verschiedene Umgebungen, Prompts oder Szenenvariationen hinweg gelten.

Das eigentliche Ergebnis sind 35 Bilder pro Tag

Das Projekt gelingt als Compiler-Demonstration gerade deshalb, weil es als praktischer Doom-Renderer so dramatisch scheitert.

Das ursprüngliche Doom zielte auf 35 Bilder pro Sekunde auf Hardware der frühen 1990er Jahre. Porters vollständiger Checkpoint erzeugt auf einem Nvidia-B200-Beschleuniger ungefähr 0,0004 Bilder pro Sekunde.

Das greedy Decoding dauerte im berichteten Produktionslauf 2.383,5 Sekunden. Das Laden des Modells und weiterer Overhead erhöhten die End-to-End-Zeit auf 2.528,1 Sekunden beziehungsweise 42,1 Minuten.

Das ergibt bei kontinuierlichem Betrieb und ähnlicher Laufzeit ungefähr 35 Bilder pro Tag. Der Vergleich wurde zum einprägsamsten Witz des Projekts. Er legt zugleich die Kernkosten offen, gewöhnliche Software in autoregressive Inferenz zu kompilieren.

Jedes ausgegebene Token erfordert einen weiteren Durchlauf durch ein Modell mit 21 Milliarden Parametern. Das Zeichnen eines Bildes umfasst Zehntausende solcher Durchläufe. Die Architektur serialisiert Operationen, die herkömmliche Hardware mit kompakten Befehlen und parallelen Pipelines ausführt.

Der B200-Lauf reservierte Berichten zufolge auf seinem Höhepunkt 151 GiB Speicher. Allein der Checkpoint belegt, in binären Gibibytes gemessen, fast 80 GiB. Dies ist kein Programm, das die meisten Leser auf einer Desktop-GPU testen können.

Der Consumer-Checkpoint senkt die Auflösung auf 80 mal 50 Pixel. Er erzeugt einen Rollout mit 7.007 Tokens und decodiert Berichten zufolge auf einer A100 mit 80 GB Speicher in 338,3 Sekunden.

Sein 34,09-GB-Checkpoint kann zudem mittels automatischem Device Mapping auf zwei Consumer-GPUs mit jeweils 32 GB verteilt werden. Diese Version macht eine Replikation erreichbarer, bleibt für ein winziges Bild jedoch extravagant.

Präzision schafft eine weitere Einschränkung. Die veröffentlichten Modelle verwenden fp32-Gewichte. Herkömmliche LLM-Deployments senken Speicher- und Rechenaufwand häufig durch Formate mit geringerer Präzision oder Quantisierung.

Quantisierung ist hier riskant, weil numerische Fehler nicht bloß Sprachwahrscheinlichkeiten abschwächen. Sie können Programmzustände, Vergleiche, adressähnliche Nachschlagevorgänge und Auslöschung im Residual Stream beschädigen.

Die Compiler-Dokumentation von Torwright räumt ein, dass einige nichtlineare Konstruktionen stückweise lineare Approximationen verwenden. Ihre Tests messen Fehlergrenzen einzelner Operationen und vergleichen kompilierte Graphknoten mit direkter Auswertung.

Diese Schutzmaßnahmen liefern Evidenz, aber keine mathematische Gewissheit für jede vollständige Ausführung. Fehlergrenzen pro Operation summieren sich nicht automatisch über lange Ketten hinweg. Der Compiler stützt sich daher auf umfassendere Graphsonden und Ausgabe-Vergleiche.

Die öffentliche Reddit-Diskussion des Projekts sprach diese Sorge direkt an. Porter sagte, er erwarte bei unvorsichtiger Quantisierung beschädigte Ausgabe statt eines Bilds geringerer Qualität. Er merkte außerdem an, dieses Szenario nicht getestet zu haben.

Eine weitere Einschränkung betrifft die Allgemeingültigkeit. Der Checkpoint unterstützt einen ausgewählten Bereich, eine feste Auflösung und die Texturen, die rund um den Startbereich von E1M1 benötigt werden. Er reproduziert nicht den gesamten Renderer für alle Doom-Inhalte.

Sprites sind weiterhin nicht implementiert. Waffe und Statusleiste sind auf den Pistol-Startzustand festgelegt. Das Modell rendert eine Szene, nicht eine interaktive Spielschleife mit normalen Gameplay-Systemen.

Auch der Karten-Prompt des Projekts wird vor der Inferenz vorbereitet. Host-seitiger Code beschneidet das Level auf einen festen Bereich im Weltraum und kodiert statische Fakten als Tokens. Das Repository beschreibt diese Grenze als vergleichbar mit dem Laden eines Levels.

Kritiker können berechtigterweise fragen, ob dies noch als Doom in einem Transformer zählt. Die überzeugendste Antwort ist enger gefasst: Ansichtsabhängige Rendering-Logik läuft innerhalb eines kompilierten Checkpoints für eine eingeschränkte Doom-Szene.

Es wäre ungenau zu behaupten, Doom selbst sei zu einem LLM geworden. Der Checkpoint besitzt keine erlernte Sprachfähigkeit und implementiert nicht das vollständige Spiel. „Transformer-gehosteter Renderer“ ist die treffendere Beschreibung.

Der Cursor-Horizon-Aspekt sollte diese Unterscheidung bewahren. Das Projekt erweitert, was eine Standard-Modelldatei darstellen kann, zeigt jedoch keinen konkurrenzfähigen neuen Weg für Grafikberechnung.

Zudem hat es noch keine breite unabhängige Verifikation erhalten. Das Repository stellt Code, Gewichte, Prompts, Messwerte und Vergleichswerkzeuge bereit. Die Reproduktion des Flaggschiffergebnisses erfordert weiterhin teure Hardware und erhebliche Download-Kapazität.

Die Reaktionen der Community spiegeln beide Seiten wider. Entwickler lobten die Compiler-Idee und lachten über ihre Leistung. Andere fragten, ob parallele Ausgaben, alternative Architekturen oder Diffusionssysteme Bilder effizienter rendern würden.

Diese Vorschläge übersehen einen Teil der absichtlichen Einschränkung des Projekts. Porter wollte ein Standard-Textgenerierungsmodell, das gewöhnliche Hugging-Face-Klassen laden können. Diese Wahl band den Renderer an eine ineffiziente Schleife mit einem Token pro Schritt.

Eine Änderung der Architektur könnte die Geschwindigkeit verbessern und zugleich die Demonstration abschwächen. Das Projekt ist interessant, weil es die Beschränkungen eines gewöhnlichen kausalen Transformers akzeptiert und den Rendering-Prozess dennoch abschließt.

Worauf Cursor Horizon als Nächstes achten sollte

Der nächste Test ist kein weiteres beeindruckendes Screenshot. Er besteht darin, ob Außenstehende die kompilierte Ausführung reproduzieren, komprimieren und verallgemeinern können.

Das erste Signal ist unabhängige Reproduktion. Eine dritte Partei sollte den veröffentlichten Checkpoint mit niedriger Auflösung ausführen, dessen Ausgabe mit dem Referenz-Renderer vergleichen und Hardware- sowie Softwaredetails veröffentlichen.

Eine erfolgreiche Replikation würde die Behauptung stärken, dass ein Standard-Checkpoint den dokumentierten Graphen ausführt. Abweichende Ausgabe würde Empfindlichkeit gegenüber Transformer-Versionen, numerischen Kerneln, Geräteplatzierung oder Gleitkommaverhalten offenlegen.

Das zweite Signal ist Ausführung mit geringerer Präzision. Ein validierter bf16-, fp16- oder quantisierter Build würde die Hardwarehürde des Projekts senken. Er würde außerdem prüfen, ob torchwright die Auslöschung im Residual Stream und Vergleiche bei verringerter Präzision bewältigen kann.

Erfolg würde kompilierte Transformer leichter untersuchbar und verbreitbar machen. Ein Fehlschlag würde verdeutlichen, dass exaktes numerisches Verhalten für dieses Programmiermodell eine wesentliche Einschränkung bleibt.

Das dritte Signal ist breitere Szenenunterstützung. Derselbe Checkpoint sollte mehrere Positionen, Blickrichtungen und kompatible Kartenbereiche ohne Neukompilierung rendern. Veröffentlichte Vergleiche sollten mehr als die Flaggschiffansicht von E1M1 abdecken.

Dieser Test würde eine allgemeine Renderer-Implementierung von einem hochoptimierten Demonstrationspfad trennen. Er würde außerdem zeigen, wie sich der ausschließlich erweiterbare Zustandsmechanismus verhält, wenn Geometrie und Token-Zahlen variieren.

Parallelität bleibt eine wichtige langfristige Frage. Porters aktuelles Design verwendet für jeden begrenzten Berechnungsschritt ein erzeugtes Token. Ein System, das mehrere sichere Operationen pro Durchlauf ausgibt, könnte die enorme Decodierungslast senken.

Diese Änderung muss jedoch die zentrale Behauptung des Projekts bewahren. Geometrieberechnungen oder Sichtbarkeitsentscheidungen in Host-Code zu verlagern, würde die Leistung verbessern, indem der Renderer verlagert wird – nicht indem die kompilierte Transformer-Ausführung verbessert wird.

Künftige torchwright-Beispiele könnten aufschlussreicher sein als schnellere Doom-Bilder. Deterministische Parser, Protokollvalidatoren, Rechner und transparente algorithmische Module passen besser zu den Stärken des Compilers als Echtzeitgrafik.

Kompilierte Logik könnte auch mit trainierten Komponenten kombiniert werden. Ein erlerntes Modell könnte mehrdeutige Sprache verarbeiten, während ein konstruiertes Subnetzwerk eine Berechnung oder ein Protokoll erzwingt. Diese Möglichkeit bleibt spekulativ und technisch schwierig.

Auch Sicherheitsforscher sollten Standard-Checkpoint-Formate beobachten. Bestehende Modellscanner konzentrieren sich häufig auf serialisierten Code, unsicheres Laden oder verdächtige Dateien. Direkt konstruierte Gewichte führen Verhalten ein, ohne herkömmlichen ausführbaren Code mitzuliefern.

Das macht torchwright nicht bösartig. Quellcode und Absicht sind ungewöhnlich offen. Die umfassendere Lehre lautet: „Kein benutzerdefinierter Code“ bedeutet nicht „kein programmiertes Verhalten“.

Entwickler sollten außerdem der Versuchung widerstehen, die Parameterzahl als Intelligenzbewertung zu behandeln. Dieser Checkpoint hat 21 Milliarden Parameter, weil sein Compiler einen Renderer auf eine umständliche Architektur abbildet. Größe allein verrät wenig über erlerntes Wissen oder nützliches Denken.

Für Cursor-Horizon-Leser lautet die praktische Erkenntnis: Transformer sollten mit einem präziseren mentalen Modell betrachtet werden. Training ist eine Möglichkeit, ihre Gewichte festzulegen. Kompilierung ist eine andere, selbst wenn das Ergebnis enorm ineffizient ist.

Der größte Wert des Projekts liegt in seinem Charakter als ausführbares Argument. Es zeigt, dass vertraute Modellinfrastruktur deterministische Programme tragen kann, nicht nur statistische Erinnerungen. Zugleich zeigt es, warum herkömmliche Computer bei herkömmlicher Berechnung weiterhin außergewöhnlich gut sind.

Versuchen Sie, den Ausführungs-Trace zu lesen, den Compiler-Graphen zu prüfen oder den kleineren Checkpoint zu reproduzieren. Stellen Sie dann die Frage, die über Doom hinaus von Bedeutung ist: Welche Algorithmen profitieren von transformer-nativer Ausführung – und welche werden lediglich zu kostspieligen Kuriositäten?