开发者将 Doom 渲染算法编译进 Transformer 权重，无需训练即可运行

一位独立开发者近日发布了一项颇为「逆向」的项目：没有用任何训练过程，而是通过自研编译器 torchwright，把经典 FPS 游戏 Doom 的实际渲染算法逐行编译成了 Transformer 模型的权重，使整个游戏可以在标准的 Hugging Face Transformers 推理流程中「跑」起来。项目代码与权重已开源，80x50 分辨率的版本对普通玩家更友好，320x200 分辨率版本则完整还原了原版画面。

项目核心思路：用 LLM 容器装编译产物

作者明确强调，整个流程「没有训练」。torchwright 编译器读取 Doom 的渲染算法代码，按 Phi3ForCausalLM 架构对应的张量形状，生成每一层的权重数值。推理时，prompt 携带关卡几何、玩家位置与视角方向，模型依次输出绘图指令，由一个仅 43 行的宿主程序将指令转换为像素。

由于使用的是标准的 Phi3ForCausalLM 架构，加载方式与普通 HF 模型一致：

• 加载方式：transformers 库原生加载，trust_remote_code=False
• 推理本质：每生成一段 token 流就是一条绘图指令
• 渲染实现：宿主程序解释 token 流、写帧缓冲

换言之，Transformer 在这里扮演的是「代码载体」的角色，而非学习得到的智能。

两个 checkpoint 与硬件门槛

作者在 Hugging Face 发布了两个版本的权重：

• 320x200（原版分辨率）：参数量 21B，权重文件 85.87 GB；单帧 prompt 长度为 3,614 个 token，需要生成 53,747 个 token，在 B200 上耗时接近 40 分钟。
• 80x50（缩放版）：相同 prompt 格式与贴图资源，权重文件 34 GB，更适合本地试用。

硬件需求方面，作者建议 80x50 版本至少配备 80GB 显存，理论上 64GB 也能运行但未经实测。所有权重目前仅支持 fp32 精度，量化支持尚在探索中。

局限与作者说明

作者本人也给出了几条坦诚的限制声明：

• 未做本地实测：所有验证均使用云端 B200 与 A100-80。
• 仅支持 fp32：编译器目前固定生成 fp32 权重，尚未尝试 int8/int4 等量化方案。
• 每帧生成成本极高：320x200 版本单帧近 40 分钟，并不具备实时游戏意义。

因此，这更像是一项「概念验证」式的技术演示，而非真正意义上的游戏引擎替代方案。它展示的是：把任意确定性算法编译进大模型权重这一思路是可行的，但离实用仍相距甚远。

资源链接

• 项目源码：github.com/physicsrob/torchwright_doom
• 80x50 权重：huggingface.co/physicsrob/torchwright-doom-e1m1-80x50
• 320x200 权重：huggingface.co/physicsrob/torchwright-doom-e1m1
• 技术博文：ood.dev/posts/doom/

该项目最初发布于 Reddit r/LocalLLaMA 板块，提交者为 /u/notforrob。对于关注 LLM 架构极限玩法与开源社区创意的读者，这是一个值得一看的实验性案例。