21BパラメータのTransformerが、学習なしでDoomのレンダラーを実行

Cursor Horizonには今、少し変わった技術的な参照点がある。学習を一切行わずにDoomをレンダリングする、210億パラメータのTransformerだ。開発者のRob Porterは、ゲームのレンダリングアルゴリズムをTransformerの重みに直接コンパイルした。この成果は、大規模Transformerはすべてデータから振る舞いを学んだものだという前提に疑問を投げかける。

このモデルはDoomのフレームがどのように見えるべきかを予測するわけではない。翻訳されたレンダリング処理を、1トークンずつ実行する。プロンプトにはシーンのジオメトリとカメラの状態を与える。出力には中間計算と描画コマンドが含まれ、小さなホストプログラムがそれらをピクセルへ変換する。

この違いにより、本プロジェクトはゲームプレイ動画で学習した生成型Doom実験と区別される。また、Cursor Horizonをめぐるこの話の中心的な緊張も生み出している。Transformer推論は従来型ソフトウェアにとって奇妙な実行対象となった一方、完成したプログラムは元のゲームより著しく遅い。

公開された成果物により、この主張は異例なほど検証しやすい。Porterはコンパイラ、レンダラーグラフ、チェックポイント、プロンプト、デコードツール、参照実装を公開した。ただし、性能と精度に関する結果の大半は、独立した再現実験ではなくプロジェクト自身のテストによるものだ。

Doomのレンダラーが標準的なTransformerチェックポイントになった

重要なのは、AIモデルがDoomの画像を生成したことではない。通常のレンダリングコードがモデルの重みになったことだ。

Porterは2026年8月13日にこのプロジェクトを公開し、その後に詳細なコミュニティ投稿を行った。彼の技術解説では、torchwrightというコンパイラが紹介されている。これは計算グラフを、デコーダー専用Transformerのattentionおよびfeed-forwardの重みに変換する。

最適化ループ、学習コーパス、勾配更新、Doomのゲームプレイに対する学習済み近似は存在しない。コンパイラはPythonで記述したグラフからチェックポイントの重みを計算する。これらの重みは、レンダラーが実行中に必要とする演算をエンコードしている。

生成された成果物は標準的なPhi3ForCausalLMアーキテクチャを使う。これは重要だ。Hugging Face Transformersがすでに読み込みと実行を行えるためである。ユーザーはカスタムモデルコードも、機密性を伴いうるtrust_remote_code=True設定も必要としない。

主力チェックポイントは38層のTransformerで構成され、およそ210億パラメータを持つ。fp32の重みシャードは85.87 GBを占める。より小さい80×50版は70層で、fp32シャードは34.09 GBとなる。

大きい方のチェックポイントは、シーンを表す3,614トークンのプロンプトを受け取る。その後、フレームを完成させるまでに53,747トークンを生成する。合計シーケンス長は57,361トークンに達する。

この出力のうち、ピクセルを直接描く部分は一部にすぎない。残りのトークンはレンダラーの操作、計算値、制御フロー、一時的な状態を表す。自然言語というより、実行トレースに近い働きをする。

公開されたチェックポイントには、モデル構成、トークナイザー、プロンプト、パレット、デコード用ユーティリティが含まれる。そのトークナイザーは、操作と値に人間が読める単語を使う。この選択により、任意のトークンIDをデコードしなくても実行トレースの一部を理解できる。

ホストプログラムが担う仕事は意図的に限定されている。カーソル位置を記憶し、Doomのパレットから色を選び、要求されたピクセル列を描画する。可視性、ジオメトリ、壁の順序、テクスチャ座標、オクルージョンは計算しない。

描画は5つの出力コマンドで制御される。2つはカーソル座標を設定する。2つはカーソルを水平方向と垂直方向のどちらへ進めるかを選ぶ。5つ目は指定した色と幅でピクセル列を描く。

この境界は、プロジェクトの信頼性にとって中心的だ。単に外部ソフトウェアへDoomのレンダリングを依頼するモデルでは、面白さが薄れる。ここでは、チェックポイントが視点に依存するレンダリング処理を担い、ホストはその描画指示を機械的に適用すると報告されている。

このチェックポイントはDoomのゲーム全体ではない。ゲームプレイ、敵、汎用スプライト、サウンド、プレイヤー操作は実装しない。固定テクスチャライブラリを使うシーン向けの、制限されたレンダラー版を実装する。

完全な出力は、低詳細モードでDoomの320×200表示解像度を使う。レンダラーは160列を計算し、それぞれを2ピクセル幅で表示する。9種類の壁テクスチャと、6種類の床または天井テクスチャがモデルにコンパイルされている。

プレイヤー位置、視線方向、マップのジオメトリ、セクター情報、バイナリ空間分割木はプロンプトを通じて入力される。バイナリ空間分割木、すなわちBSP木は、効率的な可視順序付けのためにマップを分割する。

シーンがコンパイル済みのテクスチャおよび設定の制限内に収まる限り、これらの入力はチェックポイントを再構築せずに変更できる。未対応のテクスチャを追加するには再コンパイルが必要だ。

これが、Cursor Horizonという枠組みが注目に値する理由だ。このプロジェクトはTransformerのチェックポイントを、学習済み知識の保管庫ではなく実行可能なパッケージ形式として扱う。そのパラメータは、コンパイラが生成したプログラム素材である。

Cursor Horizonが「学習優先」モデルに異議を唱える理由

TorwrightはTransformerアーキテクチャを決定論的な計算基盤へ変えるが、従来のプロセッサを実用的に置き換えるものではない。

大半の大規模言語モデルは、学習を通じて振る舞いを獲得する。エンジニアはアーキテクチャを選び、データに触れさせ、誤差を測定し、勾配降下法によって重みを調整する。最終的なモデルには、これらの事例から学習したパターンが含まれる。

Torwrightはこのワークフローを逆転させる。開発者が計算グラフを定義すると、コンパイラがその操作を実行する重みを構築する。完成したTransformerは依然として1トークンずつ予測するが、その予測過程は設計されたプログラムに従う。

この違いは、事例から掛け算を学ぶことと、乗算回路を実行することの違いに似ている。どちらも同じ答えを出せる。その内部的な起源、信頼性の限界、失敗モードは異なる。

オープンソースのtorchwrightコンパイラは、線形演算、attentionベースの検索、比較、選択、乗算をサポートする。グラフノードをTransformer層にまたがってスケジューリングし、計算値をresidual streamに格納する。

residual streamとは、Transformerの層を通過する際に変化していくベクトルだ。Torchwrightはそのベクトルの一部をプログラム値へ割り当てる。値が不要になると、別の操作がそれを打ち消して、その空間を再利用する。

この構成においてattentionは、意味的な関連付け以上の役割を果たす。構造化フィールドを照合し、先行トークンから値を取得する。これらのフィールドはノード識別子、木の深さ、操作種別、画面座標を表現できる。

feed-forward層は非線形演算を実装する。TorchwrightはReLUまたはSwiGLU活性化から構成された操作ライブラリを提供する。コンパイラは各グラフ操作を、特定のfeed-forward重みの行またはattention headへ変換する。

このアプローチには学術的な先行例がある。RASPは、そのプリミティブがTransformer操作に対応するプログラミング言語を導入した。DeepMindのTracr研究は、解釈可能性実験のためにRASPプログラムをTransformerの重みにコンパイルした。

Torwrightはこの方向性を、通常のPython計算グラフと標準のPhi-3出力形式へ拡張する。既存の推論ソフトウェアが、この異例な起源を理解せずとも結果を読み込めるため、その対象は重要である。

この互換性は挑発的な可能性を生む。標準的なチェックポイントには、学習済みの統計的振る舞い、意図的にコンパイルされたロジック、あるいはその両方の混合が含まれているかもしれない。ファイル構造だけでは、どの経路で重みが生成されたかは分からない。

開発者にとって、これはモデル成果物の解釈を変える。パラメータ数は通常、学習済み能力と推論コストの大まかな指標となる。だがここでは、210億パラメータという数は主に、きわめて非効率なコンパイル対象を反映している。

この数字は、チェックポイントが幅広い言語知識を持つことを意味しない。一般的な質問に答えることも、対応レンダラーの範囲外でDoomのシーンを即興生成することもできない。その重みは、オープンエンドな言語モデルではなく、制約されたプログラムを実装している。

したがってCursor Horizonは、より広い境界の問題を捉えている。Transformerエコシステムは現在、ローダー、アクセラレータ、シャーディング、デプロイツール、標準化されたモデルクラスを提供している。コンパイラはこのインフラを、学習されたことのないソフトウェアに活用できる。

だからといって、TransformerがCPUより望ましいということにはならない。その実行機構が、明示的に構築されたアルゴリズムをホストできるほど汎用的であることを示している。汎用性、効率性、有用性は依然として別の問題だ。

このプロジェクトの最も強い貢献は、商業的というより概念的なものだ。アーキテクチャと学習の違いを可視化する。Transformerは数学的構造である。LLMは、その構造を言語で学習させて構築する、よく知られた応用の一つだ。

Porterのモデルは、馴染み深い推論の振る舞いを保ちながら学習過程を取り除く。トークンを受け取り、attentionとfeed-forward層を適用し、次のトークンを選択して繰り返す。内部の計算が通常とは異なっていても、このループは普通に見える。

この性質は、制御された研究環境も提供する。すべての重みが既知のグラフ操作から生成されるため、研究者は値が現れる理由を追跡できる。これは、内部特徴が学習から創発したモデルを解釈することとは大きく異なる。

ただし、Doomチェックポイントは一般的な解釈可能性テストモデルよりはるかに大きい。その規模は、コンパイルされた構成が現代的なモデルインフラに到達できることを実証する。同時に、検査と独立再現のコストも高くする。

TransformerはDoomを1トークンずつ実行する

このレンダラーは、Doomの可変な実行状態をattentionが検索できる追記専用のトークン履歴へ変換することで動作する。

Doomのレンダラーは、近い領域から遠い領域へとBSP木をたどる。壁を画面の列へ投影し、すでに覆われた領域を追跡し、より近い表面の背後に隠れたジオメトリをスキップする。

従来のコードは、メモリ内の変数やデータ構造を更新する。自己回帰生成では、先行するトークンを変更できない。新しいトークンはすべて、後続のTransformerパスから参照可能な追記専用シーケンスに加わる。

コンパイルされたレンダラーは、各状態変更を別のトークンとして表すことで、この不一致を解消する。後続の操作はattentionを使って、最新の関連レコードを見つけるか、複数の先行レコードを組み合わせる。

再帰的な木探索は通常、コールスタックに依存する。モデルは代わりに、下降時にパンくず記録を出力する。葉に到達すると、attentionが適切なパンくずを取得し、実行をどこから再開すべきかを判断する。

壁の被覆には別の戦略が必要となる。Doomは、より近いジオメトリによってすでに隠された壁の描画を避けるため、solidsegsと呼ばれる可変構造に覆われた水平範囲を保存する。

Transformerは先行する範囲レコードをマージまたは上書きできない。新たに覆われた範囲をすべて追記する。後続の操作は蓄積された履歴を照会し、ある列が覆われているか、また覆われた区間がどこで終わるかを見つける。

床と天井も関連したパターンに従う。壁のパスは各画面列について可視境界を記録する。後続のパスがそれらのレコードを取得し、水平方向の描画列を出力する。

結果として得られるトークン列は、命令ストリーム、作業記憶、コールスタック、状態ログ、出力プロトコルという複数の役割を担う。Attentionは、これらの役割をつなぐ参照機構を提供する。

長い計算も、生成されるトークンにまたがって分割される。transformerの各層が残差ストリームを次の層へ渡すまでに実行できる逐次処理量には上限がある。より長い依存関係の連鎖には、より多くの層が必要になる。

rendererは、途中結果を出力し、後続のデコード手順でそれを利用することがある。この戦略では、各ステップに必要な深さを抑える代わりに、より多くのトークンを消費する。

壁面投影は、このトレードオフを示している。モデルはワールド座標上の角度を計算し、カメラ相対の角度へ変換した後、端点を画面上へ投影する。中間の角度トークンが、依存関係を持つこれらの段階を分離する。

この設計により、主力モデルは38層に抑えられている。同時に、1フレームに必要な53,747トークンのロールアウトにもつながっている。中間的な受け渡しを1つ追加するたびに、モデル全体をもう一度通す必要がある。

renderer source は、このパイプラインを公開している。モジュールはシーン入力、トラバーサル、投影、ラスタライズ、テクスチャ、出力プロトコルを処理する。別途用意されたPython rendererが、正しさの参照実装として機能する。

モデルは貪欲にトークンを生成する。つまり、サンプリングを行わず、最もスコアの高い次のトークンを選択する。checkpointは決定論的なロジックを実行する目的で設計されているため、ランダム性は不適切だ。

Cursor Horizonというキーワードは、モデルの状態境界を表す比喩としてここで有用になる。出力カーソルはレンダリング画像を横切って進み、Attentionのhorizonは実行履歴をさかのぼって到達する。

しかし、この仕組みは詩的な比喩というより文字どおりのものだ。新たな操作はそれぞれ、先行するシーン情報と生成済みの記録を参照できる。このプロセスには、会話モデルに結び付けられる意味的な柔軟性は一切必要ない。

promptは読み取り専用メモリとして機能する。視点に依存しないマップ情報に加え、プレイヤーの位置と向きが含まれる。生成部分は、視点依存の計算のための追記専用作業記憶として機能する。

hostは後から、Doomの256色パレットを用いて描画トークンを解釈する。ソフトウェアカーソルを移動し、要求された連続区間を塗りつぶす。Porterによる最小デモでは、その側を43行のPythonで実装している。

この小さなhostだけでは、すべてのレンダリング計算がcheckpoint内に収まっていることの証明にはならない。しかし、公開されたsourceによって境界は検証可能になっている。レビュー担当者は、promptの構築、graph modules、出力デコード、参照実装との比較を調べられる。

プロジェクトは、Python rendererとのピクセル単位の照合を報告している。主力フレームでは、全ピクセルをカバーし、許容されるカラー選択肢の範囲内で99.9パーセントの一致、完全一致で96.7パーセントを測定した。

これらの数値は、元の記事で用いられた丸め後の97パーセントとわずかに異なる。repositoryのcanonical facts fileによれば、最新の測定値は8月9日のproduction renderに由来する。

低解像度checkpointは、完全なカバレッジ、選択肢内カラーの完全一致、完全一致93.9パーセントを達成したと報告されている。そのフレームには、比較対象となる3,964ピクセルが含まれていた。

これらはプロジェクト側が報告した測定値だ。同じ結果が環境、prompt、シーンの変化をまたいで成立するかどうかは、まだ独立した試験では確認されていない。

真の成果は1日35フレーム

このプロジェクトがcompilerのデモとして成功しているのは、実用的なDoom rendererとしては劇的に失敗しているからこそだ。

オリジナルのDoomは、1990年代初頭のハードウェア上で毎秒35フレームを目標としていた。Porterのフルcheckpointは、Nvidia B200 accelerator上でおよそ毎秒0.0004フレームを生成する。

報告されたproduction runでは、貪欲デコードに2,383.5秒を要した。モデルの読み込みやその他のオーバーヘッドを含めると、エンドツーエンドの時間は2,528.1秒、つまり42.1分に達した。

継続稼働と同程度の所要時間を前提とすれば、これは1日あたりおよそ35フレームに相当する。この比較は、このプロジェクトで最も印象に残るジョークとなった。同時に、普通のソフトウェアを自己回帰推論へコンパイルする際の中核的なコストも浮き彫りにしている。

出力される各トークンには、210億パラメータのモデルをもう一度通す必要がある。1フレームの描画には、こうしたパスが数万回関与する。このarchitectureは、従来のハードウェアならコンパクトな命令と並列pipelineで処理する操作を直列化してしまう。

B200でのrunは、ピーク時に151 GiBのメモリを確保したと報告されている。checkpointだけでも、バイナリのgibibyte単位ではほぼ80 GiBを占める。これは多くの読者がデスクトップGPUで試せるようなプログラムではない。

consumer checkpointは解像度を80×50ピクセルまで下げている。7,007トークンのロールアウトを生成し、80 GBのメモリを搭載したA100 1基で338.3秒でデコードできると報告されている。

34.09 GBのcheckpointは、自動device mappingを介して32 GBのconsumer GPU 2基に分散することもできる。このバージョンは再現をより現実的にするが、小さな1フレームのためとしては依然として過剰だ。

精度も別の制約となる。公開されたモデルはfp32 weightsを使用している。従来のLLM deploymentでは、低精度formatやquantizationによってメモリ使用量と計算量を削減することが多い。

ここでのquantizationは危険だ。数値誤差は言語確率をわずかに鈍らせるだけではない。プログラム状態、比較、アドレスのような参照、残差ストリーム内の相殺を壊す可能性がある。

Torwrightのcompiler documentationでは、一部の非線形構成が区分線形近似を使用することを認めている。そのtestsは個々の操作に対する誤差境界を測定し、コンパイル済みgraph nodesと直接評価を比較する。

こうした安全策は、あらゆる完全な実行についての数学的確実性ではなく、証拠を提供するものだ。操作ごとの誤差境界が、長い連鎖をまたいで自動的に合成されるわけではない。そのためcompilerは、より広範なgraph probesと出力比較に依存している。

このプロジェクトの公開Reddit discussionでは、この懸念が直接提起された。Porterは、不用意なquantizationでは低忠実度の画像ではなく、破損した出力が生じると予想していると述べた。また、そのシナリオは試していないとも指摘した。

別の制約は汎用性に関わる。このcheckpointは、選択された領域、固定解像度、E1M1の開始エリア周辺で必要となるテクスチャをサポートする。Doomの全コンテンツにわたるrenderer全体を再現するものではない。

spritesは未実装のままだ。武器とstatus barはpistol-start stateに固定されている。モデルがrenderするのはシーンであり、通常のgameplay systemsを備えたインタラクティブなgame loopではない。

プロジェクトのmap promptも、inference前に準備を受ける。host-side codeはlevelを固定のworld-space regionへ切り出し、静的な情報をトークンとしてエンコードする。repositoryはこの境界を、levelの読み込みに相当するものとして説明している。

批評家が、これでもtransformer内でDoomが動作していると言えるのかと問うのはもっともだ。最も妥当な答えはより限定的である。制約されたDoom sceneについて、視点依存のrendering logicがコンパイル済みcheckpoint内で実行される。

DoomそのものがLLMになったと主張するのは不正確だ。checkpointには学習済みの言語能力がなく、完全なgameも実装していない。「Transformer-hosted renderer」のほうが、より適切な表現である。

Cursor Horizonの観点でも、その区別は保たれるべきだ。このプロジェクトは標準的なmodel fileが表現できるものを拡張しているが、graphics computingの競争力ある新しい経路を示したわけではない。

また、幅広い独立検証もまだ受けていない。repositoryはcode、weights、prompts、measurements、比較toolsを提供している。それでも主力結果を再現するには、高価なhardwareと相当なdownload capacityが必要になる。

コミュニティの反応には両面が表れている。developersはcompilerのアイデアを称賛し、その性能を笑いの種にした。一方で、並列出力、代替architecture、diffusion systemsならより効率的にフレームをrenderできるのではないか、と問う声もあった。

そうした提案は、このプロジェクトの意図的な制約の一部を見落としている。Porterが求めたのは、通常のHugging Face classesで読み込める標準的なtext-generation modelだった。その選択によりrendererは、非効率な1トークンずつのloopに縛られた。

architectureを変えれば速度は改善するかもしれないが、デモとしての主張は弱まる。このプロジェクトが興味深いのは、vanilla causal transformerの制約を受け入れながら、それでもrendering processを完遂している点にある。

Cursor Horizonが次に注目すべきこと

次の検証は、もう1枚の印象的なscreenshotではない。外部の人々がコンパイル済みの実行を再現、圧縮、汎用化できるかどうかだ。

最初のシグナルは独立再現だ。第三者が公開済みの低解像度checkpointを実行し、その出力をreference rendererと比較し、hardwareとsoftwareの詳細を公開すべきである。

再現に成功すれば、標準的なcheckpointが文書化されたgraphを実行するという主張が強化される。出力が異なれば、transformer versions、numerical kernels、device placement、浮動小数点の挙動への感度が明らかになる。

2つ目のシグナルは低精度実行だ。検証済みのbf16、fp16、またはquantized buildがあれば、プロジェクトのhardware barrierは下がる。また、精度を落とした環境でtorchwrightが残差の相殺と比較を管理できるかも検証できる。

成功すれば、コンパイル済みtransformersは研究・配布しやすくなる。失敗すれば、このprogramming modelでは正確な数値挙動が依然として大きな制約であることが明確になる。

3つ目のシグナルは、より広いscene supportだ。同じcheckpointが再コンパイルなしに、複数の位置、方向、互換性のあるmap regionsをrenderできるべきである。公開される比較は、主力のE1M1 viewだけにとどまるべきではない。

この試験によって、汎用的なrenderer implementationと、高度に最適化されたdemo pathを切り分けられる。また、geometryとtoken countsが変化する中で、append-only state mechanismがどのように振る舞うかも示される。

parallelismは、長期的に見てなお重要な問いである。Porterの現行designは、各々の限定された計算stepに対して1つの生成トークンを使う。1回のpassで複数の安全な操作を出力するsystemなら、膨大なdecoding burdenを削減できる可能性がある。

ただし、その変更でもプロジェクトの中心的な主張は維持されなければならない。geometry calculationsやvisibility decisionsをhost codeへ移せば、rendererの性能は向上するが、それはコンパイル済みtransformer executionを改善するのではなく、rendererを移設することになる。

将来のtorchwright examplesは、より速いDoom framesより多くを教えてくれるかもしれない。決定論的なparsers、protocol validators、calculators、透明性の高いalgorithmic modulesは、real-time graphicsよりもcompilerの強みに適している。

コンパイル済みlogicは、学習済みcomponentsと組み合わせることもできる。学習済みmodelが曖昧な言語を処理し、構築されたsubnetworkが計算やprotocolを強制する、といった形だ。この可能性は依然として推測の域を出ず、技術的にも難しい。

security researchersは、標準的なcheckpoint formatsにも目を向けるべきだ。既存のmodel scannersは、多くの場合serialized code、unsafe loading、疑わしいfilesに注目している。直接構築されたweightsは、従来型のexecutable codeを同梱せずに振る舞いを導入する。

だからといってtorchwrightが悪意あるものというわけではない。そのsourceと意図はきわめて公開性が高い。より広い教訓は、「custom codeがない」ことは「プログラムされた振る舞いがない」ことを意味しない、という点だ。

developersは、parameter countを知能の尺度として扱うことも避けるべきだ。このcheckpointが210億parametersを持つのは、そのcompilerがrendererを扱いにくいarchitectureへ写像しているためである。規模だけでは、学習済みの知識や有用なreasoningについてほとんど何も分からない。

Cursor Horizonの読者にとって実用的な要点は、transformersについて、より鋭いメンタルモデルを得ることだ。trainingはweightsを設定する1つの方法である。結果が途方もなく非効率であっても、compilationもまた別の方法になりうる。

このプロジェクトが最も価値を持つのは、実行可能な論証としてだ。馴染みあるmodel infrastructureが、統計的な記憶だけでなく、決定論的なprogramsも保持できることを示している。同時に、従来のcomputersが従来型のcomputationにおいて依然として並外れて優れている理由も示している。

実行トレースを読み、コンパイラグラフを調べるか、より小さなチェックポイントを再現してみてください。そしてDoomを超えて重要な問いを投げかけましょう。トランスフォーマー・ネイティブな実行によって何かを得るアルゴリズムはどれで、単に高価な好奇の対象となるだけのものはどれでしょうか？