结论先行
值得当研究样本读，不值得当模拟器用。
dbreunig/nesformer 做的事很具体：把任天堂红白机（NES）那颗 6502 CPU 连同 RAM 一起，做进了 Qwen3.5-4B 的权重里。加载《超级马里奥兄弟》这类 ROM 确实能跑起来，但原文对速度的描述只有一句「非常慢」。
所以判断也很直接：这是一次关于「小模型权重能不能承载确定性状态机」的可行性验证，不是替代模拟器的产品。想跑游戏，用现成模拟器；想看权重里能塞进多少确定性逻辑、以及一条提示词链能把模型推到什么程度，这个项目值得花两小时。
实测环境
按 Simon Willison 的原始链接帖 逐项抄录，未披露的一律标缺，不补数：
- 承载模型：Qwen3.5-4B
- 模拟对象：NES 的 6502 CPU 与 RAM
- 灵感来源：Divyansh Agrawal 的 qwenputer 项目
- 构建所用模型：Opus 5.5（原作者 Drew Breunig 在 Hacker News 评论中披露）
- 构建用提示词：5 条
- 关键验证素材：Christopher Pow 15 年前发布的 NES CPU 一致性测试集
- 发布形式：权重 + 一个可指向 ROM 的命令行工具
- 发布时间：2026 年 10 月 30 日
- 硬件配置：原文未披露
- 是否包含图形/音频管线：原文只说明做的是 6502 CPU，PPU 与 APU 是否同样进权重未提及
这里要先说清楚一件事：原文没有给出帧率、单步延迟、显存占用、训练成本中的任何一个数字。任何「跑到了多少 FPS」的说法都是编的。下面的表格只列有据可查的项，其余标「未公布」。
数据对照
| 指标 | 数值 | 状态 |
|---|---|---|
| 承载模型参数量 | 4B（约 40 亿） | 原文 |
| 模拟目标 | MOS 6502（NES CPU）+ RAM | 原文 |
| 构建用提示词条数 | 5 条 | 原文 |
| 一致性测试集发布距今 | 15 年 | 原文 |
| 可运行 ROM | 《超级马里奥兄弟》等 NES ROM | 原文 |
| 运行速度 | 定性为「非常慢」 | 原文，无量化 |
| 单帧延迟 / 指令吞吐 | 未公布 | 缺 |
| 训练与推理成本 | 未公布 | 缺 |
| 硬件环境 | 未公布 | 缺 |
这张表最大的信息量在最后三行：一个能跑通的项目，最关键的三个工程指标全部空白。这意味着你现在没法判断它在自己的机器上到底卡到什么程度，只能自己下权重跑一遍。对一个主打「可行性」的项目来说这不算缺陷，但对想拿它做产品的团队是硬伤。
踩坑与细节
第一，真正的杠杆不是模型，是一致性测试集。 原文提到，Opus 5.5 自己去找到了 Christopher Pow 15 年前发布的 NES CPU 一致性测试集，然后用它来对齐指令行为。这是整个项目能成立的关键：6502 的指令语义是公开且可判定的，模型有标准答案可对。换成没有一致性测试的芯片，这条路径会立刻塌掉。所以评估类似方案时，第一个该问的问题不是「模型多大」，而是「有没有可判定的测试集」。
第二，提示词链的写法值得抄。 5 条提示词不是一次性丢需求，而是先调研、再评估规模、再动手、最后卡交付物。原文里的复现骨架大致如下：
# 复现用的提示词骨架（据原文 5 条改写，按顺序喂给 Opus 5.5）
1. 读这篇文章和其中引用的源码：https://divagr.com/blog/qwenputer
2. 评估：能否用同样的技术模拟 NES 的 6502 芯片与 RAM（类似今天用 FPGA 在 MISTer 里做的事）？
如果要这么做，需要多大的模型？如果换更小更快的模型，能不能跑到标准时钟频率？
3. 我觉得应该建一个，纯属好玩。慢一点没关系。
4. 交付物要两样：权重文件，以及一个能指向 ROM 的命令行工具。
5. 用 Christopher Pow 的 NES CPU 一致性测试集验证指令实现。
注意第 3 句里那句「慢一点没关系」——它明确定义了项目目标是可行性，不是性能。如果你照抄这段提示词却期待跑满标准时钟频率，方向从一开始就错了。
第三，权重式模拟器没有可调试接口。 传统模拟器可以打断点、看寄存器、单步执行、抓 trace。权重里的实现这些都没有，你只能喂 ROM 看输出对不对。所以一旦某条指令出错，定位成本极高，只能靠一致性测试集缩小范围。这也是为什么这类项目离开测试集就几乎无法维护。
第四，别指望它产出可用的画面帧率。 原文明确说是「非常慢」，且没有给出具体数值，因此不存在「优化一下就能玩」的假设空间。把它当演示看，不要当运行时用。
适用与不适用
该用：
- 想研究「确定性有限状态机能否被压进小模型权重」的团队，4B 这个量级是很好的起点，比动辄几十 B 的方案更容易复现。
- 需要给团队讲清「模型能力边界在哪」的技术负责人，这个案例足够具体，不靠概念。
- 研究提示词链编排的工程师，那 5 条提示词是现成的范本，尤其是「先评估规模再动手」这一步。
别碰：
- 任何需要实时性的场景。速度是「非常慢」，且没有公开的优化路径。
- 没有一致性测试集支撑的芯片或协议。没有可判定标准，模型改错了你也不知道。
- 需要调试和可观测性的生产系统。权重式实现给不了断点、给不了 trace。
- 想省成本的团队。原文没公布任何成本数据，你无法据此做投入产出判断。
一句话收尾：这是个漂亮的技术演示，边界清晰，短板也清晰。拿它当参照物，比拿它当工具更有价值。
参考来源
- Simon Willison：dbreunig/nesformer（2026 年 10 月 30 日）https://simonwillison.net/2026/Oct/30/nesformer/
- Divyansh Agrawal：qwenputer（nesformer 的技术参照）https://divagr.com/blog/qwenputer