Qwen NES 模拟器将 Nintendo CPU 逻辑编译进约 1GB 权重

据其代码仓库介绍，Qwen NES 模拟器项目 nesformer 将一颗 Nintendo CPU 封装进 933 MB 的编译模型权重中。其演示包含 Super Mario Bros.，但屏幕绘制和手柄处理仍由外部软件完成。这一区别至关重要：它是在模型架构内部进行的编程式计算实验，而不是一个学会玩 Nintendo 游戏的聊天机器人。

开发者 Drew Breunig 通过 Hacker News 分享了该项目，标题称约 1GB 的 Qwen 权重中运行着一台可工作的 Nintendo。代码仓库提出的是一个更狭义、也更有趣的主张：编译器构建处理器逻辑，生成的 token 则推动其执行继续进行。公开结果仍需独立复现，但项目提供了代码和明确的验证路径。

其参照对象是 Divyansh Agrawal 此前的实验 Qwenputer，该实验将一颗处理器嵌入 Qwen 架构。两个项目都向构建 AI 系统的开发者提出一个问题：哪些操作应当属于模型内部计算，哪些应留在传统软件中？Nesformer 通过人们熟悉的游戏让这一问题变得可见，同时也记录了显著的速度与兼容性限制。

Qwen NES 模拟器运行 CPU，而宿主程序补全整台主机

Nesformer 的核心主张涉及 Nintendo CPU 及其内存，而非完整游戏主机的全部组件。 这一边界界定了它的成就与局限。

该项目称，它将 NES 的 6502 处理器核心放入一个兼容 Qwen 的模型 checkpoint，即一组已保存的模型参数。同时，它还将工作内存和卡带程序数据放入模型不断变化的内部状态中。

参数与状态的区别很重要。参数规定机器的行为；状态保存游戏运行过程中会变化的信息。将所有内容都称作“权重”，会把这些不同职责压缩成一个吸引人的标题。

根据其编译 CPU 设计，模型会生成 token，即离散的输出符号，用于表示处理器的执行记录。这些符号描述的是操作，而不是普通的对话文本。

宿主程序提供周边的主机行为。它渲染图形、处理手柄输入，并提供与显示时序相关的事件。输入和输出通过执行记录跨越这条边界。

这种安排让模型承担了重要角色，但并未将整个 Nintendo 系统都放入其中。仅凭移动的画面无法看出这种分工。代码仓库中的架构说明使这种划分可供检查。

处理器实现覆盖了全部 151 条官方 opcode，即告诉处理器应执行何种操作的编码指令。它包括算术运算、分支、处理器标志位和栈行为。

文档记录的内存配置包括 2 KB 工作 RAM，即运行中的游戏可以修改的内存；还包括 32 KB 卡带程序 ROM，即存储的程序数据。

卡带程序会在执行开始时加载进状态。因此，项目称，受支持的游戏可以共用同一套编译权重，而不必为每个游戏重新构建处理器。

这与为每场演示单独制作动画有着实质区别。该产物旨在成为一个可复用的处理器实现，但兼容范围受到限制。

公开的 Super Mario Bros. 示例提供了一个易于识别的场景。随项目附带的测试游戏则是更有价值的验证起点，因为项目同时提供了它们的文件和许可信息。

手柄操作可以遵循脚本，指定何时按下按钮。文档中的 Mario 序列会启动游戏、向右移动，并按预定时间间隔跳跃。

这并不能证明 AI 智能体学会了玩 Mario。它所主张的是：编译后的处理器逻辑可以在接收预设输入的同时执行游戏指令。

Nintendo 在这里的角色是硬件目标和游戏参照。该代码仓库展示的是一项独立实验，而非 Nintendo 产品或与 Qwen 已宣布的合作关系。

因此，这一发布改变了开发者可检查的内容：一个公开实现将模型参数、处理器行为与可见的游戏输出连接起来。其意义建立在这种可检查的连接之上。

编译逻辑改变了这场演示对 AI 的含义

关键机制在于有意构建：nesformer 的编译权重编码了处理器行为，而非训练模型自行发现这些行为。

训练通常利用样本和优化过程调整参数。编译则将既定设计转换为另一种可执行表示。Nesformer 的代码仓库称，其编译器直接计算参数。

这使该项目不同于要求预训练聊天机器人模仿处理器。编译器提供规则，模型架构则提供执行这些规则的数学机制。

不应将结果解读为对话式 Qwen 模型暗中理解 Nintendo 硬件的证据。这场演示也不能证明普通语言生成已成为软件的精确替代品。

相反，它探索的是：相同的架构构件能否支持一台经过有意规定的数字机器。这是关于表示与执行的问题，其更广泛的影响仍需实验验证。

核心组件是 Gated DeltaNet，这是一种维持可变内部记忆矩阵的模型机制。Nesformer 利用这一状态，在连续生成的 token 之间存储机器信息。

其设计将内存位置分配给这些矩阵中的行。经过精心构造的读取和更新，使处理器寄存器、工作内存和卡带数据得以占据这些位置。

寄存器，即处理器可直接使用的小型存储位置，必须在指令改变它之前保持精确数值。近似记忆会破坏执行。

编译器还将指令解码和算术运算映射到模型层中。一次前向传播，即产生下一个输出的计算，会沿着执行记录推进编码后的机器。

该项目报告称，大多数指令只需一个 token。有些需要更长的记录，其文档所示游戏代码平均每条指令需要 1.1 至 1.3 个 token。

这种关系将一个熟悉的模型性能指标与传统计算工作负载联系起来。更快地生成 token 很重要，因为 token 序列承载着处理器执行，而不只是事后对其进行描述。

Qwenputer 提供了直接的技术基础。Agrawal 于 2026 年 10 月 22 日发布的模型内计算文章，介绍了如何编译处理器逻辑，并将内部状态用作内存。

因此，Qwenputer 与 nesformer 的比较始于延续性。Nesformer 复用了此前的编译器和内存技术，随后瞄准 NES 处理器，并将其连接至面向主机的特定宿主行为。

两者的外围设计有所不同。Agrawal 描述了保留 Qwen 原有语言权重，同时加入计算机制的做法。Nesformer 则发布了一个规模更小、聚焦处理器的 checkpoint，并采用不同的层级配置。

这一差异避免了对体积产生误导性结论。Nesformer 的下载体积并不能证明：一个完整的对话式 Qwen 模型加上一台完整 Nintendo 主机，可以装进标题所称的体积中。

它证明的是一个更有限的命题：选定的 Qwen 架构组件可以承载经过编译的处理器设计。这是否会在通用 AI 产品中变得实用，仍是一个开放的工程问题。

传统执行仍是衡量实用性的标杆

Nesformer 提供了一种架构替代方案，但其公开性能表明，传统软件依然是运行游戏的实用标准。

最直接的比较，是在常规模拟器代码中执行指令，还是通过模型操作表达这些指令的执行。可见的结果并不能决定哪条路线更实用。

模拟器，即复现另一台机器行为的软件，在这里已有明确任务：它必须准确运行兼容程序，并以可接受的速度提供输出。

Nesformer 增加了另一个目标：通过兼容模型的参数表示来执行处理器。这一目标解释了实验的价值，即便传统执行仍然更高效。

代码仓库报告称，其默认优化引擎在单个处理器核心上的速度约为每秒 1,650 个 token；较为简单的数值引擎约为每秒 210 个 token。

其原生 Transformers 路径据称达到约每秒 10 个 token。Transformers 是用于加载和执行公开 checkpoint 的模型运行软件库。

这些数字描述了不同的执行路径。它们不应被合并成关于原生模型性能的单一结论，也不应被视为在未说明硬件上进行的受控比较。

默认引擎会跳过参数为零的区块。这很重要，因为 checkpoint 中大多数参数为零，使其结构格外适合专用执行。

代码仓库还描述了如何跳过不执行内存或输入输出写入操作的重复空闲循环。这些循环等待下一个相关的显示事件。

这种优化减少了不必要的工作，但在解释速度数据时不能忽略它。宿主程序有助于避免重复那些不会改变可见行为的计算。

即便采用这些优化，项目仍报告其运行速度比原始主机慢 150 至 290 倍。其对 600 帧的估算约为 25 分钟。

在文档示例中，这 600 帧代表 10 秒的 NES 时间。因此，这场演示关注的是最终能够完成执行，而不是成为正常游玩游戏时的响应式替代方案。

这将实际举证压力放在了模型权重内计算的倡导者身上。他们必须找出足以证明额外执行工作和集成复杂性合理的益处。

潜在益处需要测量，而不能想当然。将操作保留在模型计算内部是一种架构属性；它不会自动改善延迟、可靠性或可用性。

当前压力主要落在研究主张和评估设计上，而不是现有模拟器业务。Nesformer 没有提供证据表明传统模拟器面临替代。

考虑采用类似机制的开发者，应比较完整路径。加载状态、推进执行、处理输入和读取输出，都会影响用户实际体验到的结果。

Qwenputer 与 nesformer 的比较进一步凸显了精确性的必要。不同的处理器目标、外围组件和执行引擎，使得无法仅凭 checkpoint 体积或标题中的吞吐量进行简单排名。

目前，传统路线既提供了实用替代方案，也提供了参照行为。Nesformer 值得关注之处在于，它使另一条路线变得可检查，但并未证明自己应取代既有方案。

测试比 Mario 动画更具信息量

最有力的证据是该项目针对参考行为所做的分层对比，不过已发布的结果仍为作者自行报告。

游戏动画只能证明出现了某种可识别的画面。它并不能说明指令是否被正确执行、参考系统是否提供了修正，或每一帧具体由哪款软件生成。

Nesformer 的文档将这些问题区分开来。它描述了对参考处理器、编译后的电路、保存的 checkpoint 以及更长执行序列的检查。

这种区分始于参考 CPU，即作为预期结果使用的传统实现。如果参考实现本身存在缺陷，输出匹配的意义就会下降。

该仓库报告称，已将该参考实现与 nestest 进行了比对；nestest 是一项附带预期执行记录的处理器一致性测试。报告称，参考实现能够在其支持范围内匹配 3,348 条指令。

它还报告称，已在 570 万条游戏代码指令上与另一款处理器模拟器 py65 进行了比较。这为参考实现提供了额外验证。

随后，编译后的电路也接受了独立比较。文档报告称，其在 nestest 以及两款游戏启动序列的 283,610 个位置上均保持一致。

这些结果验证的是指定电路的行为。但仅凭这些结果，尚无法证明一个保存模型会在所有执行引擎中产生完全相同的结果。

因此，该仓库还报告了一项独立的 stock Transformers 检查，涵盖来自 nestest 和 Full Game 的 2,651 个位置。报告称，该样本中未发现不匹配。

stock checkpoint checker 展示了该比较的工作方式。它加载模型、初始化机器状态，并将预测输出与提供的参考序列进行核对。

该方法采用 teacher forcing，即在每个比较步骤中输入已知的前序输出。它检验局部预测，但无法证明系统可以进行同等长度、不中断的自主运行。

自由运行则会让系统将自身输出继续作为输入。一个错误可能改变后续状态，因此，在持续序列中的一致性回答的是另一类验证问题。

该项目报告称，Thwaite 的自由运行覆盖 1,916,527 个 token 和 600 帧。报告称，保存的全部 300 帧均与参考输出匹配。

对于 Full Game，报告称其覆盖 2,645,885 个 token 和 420 帧。其文档称，保存的全部 210 帧均匹配。

这些计数是针对特定情况提出的证据主张，而非普遍保证。它们涉及特定游戏、输入序列、执行路径和运行长度。

处理器验证测试 展示了针对参考实现、电路、执行引擎以及空闲循环优化的自动化比较。它们的公开使有针对性的复现成为可能。

不过，阅读测试与实际运行测试并不相同。本分析检查了公开的实现和文档；并未独立执行 checkpoint，也未复现报告中的性能。

这种区别不应在转述中消失。该项目提供的证据多于没有支撑的社交媒体说法，但公开代码和作者报告的一致性并不等于独立验证。

对于 Qwen NES emulator，下一步更可信的增量应是借助明确标识的执行引擎进行更广泛的复现。相比一段更大的动画，具备文档记录的匹配轨迹更能增加可信度。

1GB 的标题同时掩盖了稀疏存储和缺失的硬件

checkpoint 大小作为报告中的文件占用是真实的，但它并不描述一台完整主机，也不代表全部运行时内存。

该仓库列出 4.666 亿个以 bfloat16 存储的参数；这是一种每个数值占用 16 位的数值格式。它给出的参数占用空间为 933 MB。

据文档称，只有 930 万个参数为非零值。项目表示，这种规律性使权重可以压缩为一个 3.3 MB 的归档文件。

这些是不同的量。归档下载大小、展开后的参数文件，以及运行进程消耗的内存，回答的是不同的实际运行问题。

文章中约 1GB 的描述针对的是展开后的权重。它不应被延伸为完整应用程序只需要这么多内存的说法。

稀疏结构也改变了性能解读。一个能够跳过零块的专用引擎，所执行的工作不同于处理完整参数布局的实现。

这并不会否定 checkpoint 的说法。它意味着兼容性、存储和执行效率需要分别衡量，而不应浓缩为单一的压缩标题。

硬件边界还带来另一项限定。负责图形行为的 NES 组件 picture processing unit 仍由宿主软件实现。

audio processing unit，即主机的声音硬件，同样不包含在权重中。该仓库表示，当前实现不会产生声音。

图形保真度也存在限制。宿主会渲染 scanline，即画面的水平行，但不会复现发生在单行中途的效果。

文档还描述了某些 sprite 状态条件下的近似行为。sprite 是独立控制的图像元素，用于角色及其他移动对象。

卡带支持仅限于 NROM，这是一种不具备程序 bank switching 的简单板卡布局。bank switching 会改变处理器能够访问的大型卡带程序区域。

Nesformer 文档所述的设计采用固定程序表。要支持更复杂的卡带，需要增加状态和地址选择逻辑，而不只是将新游戏名称加入兼容列表。

执行限制不止于卡带格式。不受支持的非官方指令会使系统停止，而且代码必须从卡带内存执行，而非工作 RAM。

该项目还列出了缺失的中断行为，即促使处理器响应硬件事件的信号。部分受支持的事件可以正常工作，但文档所述的覆盖范围并不完整。

这些限制塑造了“可运行”的含义。一个系统可以在既定范围内正确运行特定游戏，同时仍不适合更广泛的游戏库。

它们也阻止人们将已报告的测试泛化到所有 Nintendo 软件。对受支持指令的一致性，并不能补足实现明确省略的硬件行为。

因此，nesformer 的编译权重最好被视为一个连接到部分主机实现的处理器产物。这样的描述既保留了项目的独特贡献，也不会扩大其兼容性主张。

对开发者而言，一个有用的怀疑性问题非常具体：哪些观察到的行为来自编译后的处理器逻辑，哪些来自宿主假设？该仓库为审阅者提供了一张起始地图。

接下来是独立复现、更广泛的兼容性和全系统速度

下一类有价值的证据，应依次扩展可信度、覆盖范围和可衡量的实用性。 这些信号比新一轮关注更具信息价值。

首先，应关注对已发布轨迹比较的独立复现。一份可信报告应明确说明 checkpoint、游戏输入、执行引擎和比较方法。

复现 stock Transformers 行为将加强这样一项主张：该产物可以通过其宣传的模型接口运行。更长的自由运行比较，则会在短暂、由参考输出驱动的样本之外检验持续一致性。

出现不匹配时，需要诊断，而非立即否定。数值行为、状态初始化、引擎差异和不受支持的功能，都是彼此不同、含义也不同的潜在原因。

其次，应关注由一致性测试支持的兼容性改进。如果实现记录了内存行为并验证了代表性程序，额外的卡带支持将具有实际意义。

声音和更准确的图形时序会弥补不同缺口。审阅者应区分：是将更多硬件移入权重，还是改进宿主的传统实现。

两种改变都可能改善应用，但只有前者会扩展“计算发生在权重内部”这一主张的范围。清晰的边界将使未来的比较仍然可解释。

第三，应关注在指定硬件上的完整性能测量。有价值的报告应涵盖启动、执行、宿主工作，以及生成所需游戏序列所花费的时间。

仅限于某项选定计算的速度提升，会强化一项更狭窄的主张。跨受支持游戏实现更快的完整执行，则将为实际进展提供更强证据。

Breunig 的开发者讨论为理解该项目的重要性提供了另一种视角。他在描述 AI 辅助开发时，提到了既有参考材料、早期编译器和一致性测试。

持支持态度的评论者强调了这些参考检查的价值。持怀疑态度的参与者则质疑：相比直接执行普通代码，将代码转换为模型运算是否具有效率。

这两种反应都不能解决工程问题。但它们共同指出了项目当前的价值：这是一个具有可见输出、明确边界和可供其他开发者检查行为的实验。

对于工程师而言，这也凸显了维护包含规范、参考实现和测试证据的可搜索知识库的价值。这类材料既支持审阅，也支持实现。

评估 Qwen NES emulator 时，应从验证路径而非动画开始。比较 checkpoint 计算的内容与宿主提供的内容，然后检查报告中的执行轨迹。将文件大小、运行时内存和完整应用速度分开看待。如果你持续关注该项目，应在将已发布结果视为既定事实前，寻找独立的匹配运行。随后观察兼容性的扩展是否来自经过测试的处理器和卡带行为，还是主要来自周边软件的变化。这些区别能让开发者欣赏这项实验，同时对其相关性作出稳健判断。哪一项后续结果最能改变你的评估：独立复现、更广泛的硬件覆盖，还是完整执行时间的可测量下降？