Doom at 35 FPD: what 21 billion compiled weights actually buy you

A transformer checkpoint can be a compiler target, not a learned model. Run inference on a compiled graph, and the model executes the computation baked into its weights — no training, no fine-tuning, no trust_remote_code. That is the mechanism u/physicsrob's torchwright project demonstrates with Doom's E1M1 level.

The project ported Doom's renderer into a 21B-parameter Hugging Face checkpoint. Instead of training a model to imitate Doom frames, the author wrote a compiler that converts a computation graph into transformer weights and then translated Doom's original rendering algorithm into a compatible graph. The 43-line host program on the ood.dev write-up loads a standard checkpoint, generates tokens, and converts the output into pixel commands. DeepMind's 2023 Tracr paper did the same trick for small RASP programs built for interpretability. torchwright is the public, no-training cousin, pointed at arbitrary graphs and scaled to 21B parameters.

So what does 35 frames per day on a B200 buy you? One E1M1 frame is a 3,614-token scene prompt plus 53,747 generated tokens — just over 40 minutes on a B200. The original Doom hit 35 FPS on a 486 in 1993. That order-of-magnitude drop in frames per unit time is the joke, and the point: you gave up the cheap path on purpose. The frame you get back is the literal, deterministic output of a compiled graph baked into the weights, fully verifiable against the open releases — the Hugging Face model card, the GitHub repository, and the ood.dev walkthrough — by anyone with a B200 and about 40 minutes to spare.