NESformer 解析：遊戲跑進權重，CPU、主機與測試各證明了什麼？（2026）

2026 年 10 月 30 日（UTC），Drew Breunig 在 Hacker News 公開了〈Show HN: A working Nintendo in ~1GB of Qwen weights〉，介紹把 NES CPU 編譯進模型權重的 NESformer。畫面上的角色能移動，但最值得追問的是：那一幀畫面，究竟由模型算出了什麼？

先把答案說清楚：這是一個把既定 CPU 規則編譯成神經網路參數的工程實驗。遊戲畫面由模型內的計算與主機程式共同完成；它提供了可檢查的運算紀錄，不能直接當作模型透過訓練學會電腦或自主玩遊戲的證據。

下面先看作者做出了什麼，再把遊戲展示、相容性與效能測試拆開，最後看這件作品對 AI 輔助工程真正有價值的地方。

NESformer 的驚喜：權重成為電路的交付格式

Nobody trained these weights; a compiler computed every one.

中文：這些權重由編譯器逐一計算產生，而非經由訓練得到。

NESformer README

作者沿用 Divyansh Agrawal 的 Qwenputer 編譯器思路，把 NES 的 6502 核心規則安排進 Qwen3.5 相容的模型結構。權重產生程式負責把電路描述轉成模型設定與 safetensors 檔案。這裡的「Qwen 相容」描述架構與載入介面，不代表一般 Qwen 聊天權重原本就具備這份 NES 電路。

Transformers 的 Qwen3.5 文件確認這個家族使用 Gated DeltaNet 與完整注意力的混合結構。NESformer 利用其中可保存狀態的部分存放機器資料；電路與初始狀態程式則把暫存器、工作記憶體與卡匣程式內容安排到指定位置。

用一個直觀比喻：權重像已經接好的電路板，推論狀態像正在變動的記憶體。Gated DeltaNet 原始論文討論閘門控制與定向記憶更新；專案再以特定編碼與參數配置，把它用作可定址儲存。這是特別構造出來的用途，機制背景與 NES 實作是否正確，仍須分開驗證。想先補背景，可以從 LLM 的權重與推論讀起。

一幀遊戲畫面，分別是誰的工作？

The PPU and APU aren’t in the weights.

中文：顯示處理器 PPU 與音效處理器 APU 並未放進權重。

NESformer 的實作限制

這句限制決定了整個故事該怎麼讀。按照目前固定版本的 host.py 與 執行驅動程式，模型產生 CPU 執行的紀錄 token；主機讀取紀錄、處理顯示與控制器，並在需要時注入 I/O 回覆及畫面垂直空白期的 NMI 中斷。主機是模擬系統的一部分。

工作	NESformer 的分工	能從展示讀出什麼
CPU 指令、暫存器與工作 RAM	編譯電路與模型的遞迴狀態	要核對指令與狀態紀錄
卡匣程式資料	啟動時載入模型狀態	換遊戲資料與重新訓練是不同工作
畫面、按鍵與外部事件	主機程式	畫面相同仍需追問共同使用了哪些主機零件

所以「遊戲跑進權重」可以是有意義的工程描述，前提是把範圍落在 CPU 與其狀態；把它擴張成整台遊戲機都由模型完成，就超過實作分工。相反地，因為主機參與便否定 CPU 電路，也會漏掉這個專案真正完成的部分。

上圖保留作者的畫面序列：標題畫面之後，角色與場景有可見變化。它讓「有輸出」變得容易理解；要證明輸出走過哪條計算路徑，仍得繼續讀紀錄與驗證程式。這與只看一張遊戲截圖的證據強度不同。

NESformer 的測試，要分清「餵答案」與「自己往下跑」

專案把參考 CPU、編譯電路、匯出的權重與不同執行引擎分開。公開測試程式包含參考 CPU 對照 nestest 紀錄、電路逐步預測，以及權重自由執行的核對。外部的 nestest 原始測試說明提供獨立的 CPU 行為題目；參考答案不是臨時請同一個 Agent 編出來的。

其中有兩種容易混淆的證據。Teacher forcing 是把既有紀錄一項項餵回去，看下一項預測是否相符；free-running 則讓系統接著自己的輸出往下走。前者能檢查局部計算，後者更能暴露小錯誤累積後的偏離。兩者都有價值，涵蓋的問題不同。

標準 Transformers 核對程式明確沿參考 token 前進，跳過由主機注入的輸入位置，再比較模型預測。自由執行路徑則以引擎上一次的預測繼續執行，並可在與參考序列首次不符時停止。這個差異可以直接從公開程式追查。

作者在 README 回報：參考 CPU 對上 3,348 條 nestest 指令；標準 Transformers、bf16、CPU 路徑核對了 2,651 個預測位置。這些是作者公布的特定範圍結果。它們不能被改寫成「標準 Transformers 已完成所有遊戲的長時間驗收」。

同一份 README 另外列出 Full Game 的長序列：420 幀、約 7 秒遊戲時間，並稱其中保存的 210 張畫面與參考結果一致。這份報告支持作者做了更長的自由執行檢查；不能把該長跑的引擎與範圍，移植到前述短得多的標準框架測試。AlphaLab 本次檢查公開程式與既有成果，未在本機載入完整權重重跑。

還有一個重要的共用零件：模型與參考 CPU 的執行驅動都使用同一套 Host。兩條路產生相同畫面，能幫忙抓 CPU 路徑的差異；若兩邊共用的顯示處理有同一個錯誤，畫面相同仍可能一起錯。這是從測試設計可推得的證據邊界，不是否定作者的比對結果。

速度與相容性：展示成立，離日常模擬器仍有距離

目前的 快速引擎用 Numba 編譯運算，並利用權重中的零值結構減少工作；另一條路徑則實際呼叫標準 Qwen3.5 模型類別。引擎都圍繞這份電路，但執行成本不能視為相同。

作者回報單核心快速引擎約 1,650 tokens／秒，標準 Transformers 約 10 tokens／秒；這是作者環境中的速度陳述，本文沒有重測。再加上主機會略過符合條件的空等迴圈，「生成了多少 token」「經過多少遊戲時間」與「現實等了多久」必須各留一欄。播放一段 GIF，看不到這三個分母。

相容性也有明確邊界。固定版本的 卡匣載入程式只接受 mapper 0，也就是 NROM，對其他 mapper 直接拒絕。作者限制清單另列：採逐掃描線顯示，部分視覺效果近似處理，且沒有聲音。這些是目前實作的具體限制，不能拿成功畫面替整個 NES 遊戲庫背書。

接下來值得追的進展因此很具體：更多卡匣與邊界案例、標準框架更長的自由執行紀錄、對獨立顯示實作的比對，以及完整的硬體和耗時資訊。這些證據會比另一張「畫面已動」的展示更能改變判斷。

兩次提示的故事，真正可借用的是現成規格與考卷

proper reference materials, great specs, conformance tests, and clear direction.

中文：合適的參考資料、清楚的規格、一致性測試，以及明確方向。

Drew Breunig 在發布討論中的總結

Breunig 自述，兩次主要提示讓編碼模型先評估可行性，再製作權重與命令列工具。他也特別指出，既有 Qwenputer 編譯器、長年累積的模擬器知識與一致性測試是關鍵。這個開發過程是作者自述；兩次主要提示的敘述本身，無法量化所有人類介入、迭代與成本。

因此，最可複用的做法不是把自己的需求濃縮成兩句話，而是先找到能判定對錯的外部規格。CPU 指令有相當明確的輸入、狀態與預期結果；這讓 Agent 可以反覆修改，再由既有考卷抓錯。若任務換成「讓產品更好用」，驗收條件就需要另外設計。

這也說明 AI Evals 與 Agent Harness 的角色：前者替成果建立可檢查的標準，後者安排執行、狀態與停止。模型產生更多程式碼，和系統證明更多性質，是兩件需要各自證據的事。

AlphaLab 的判讀：我同意這份構造，對能力外推保留判斷

我同意：可追查的運算，比令人驚豔的畫面更有研究價值

NESformer 把一個抽象主張變成能讀程式、核對紀錄的具體作品。把計算規則編譯成權重，再透過遞迴狀態保存機器資料，拓寬了模型架構能承載什麼的工程想像。即使速度不適合日常玩遊戲，這種可構造、可對照的案例仍然值得研究。

我存疑：成功編出電路，不能直接推成訓練出的通用能力

電路由編譯器決定，與模型從資料學出一套穩健的電腦執行能力，是不同的研究問題。角色照著預設按鍵移動，也不能證明它理解遊戲策略。這份作品支持的是具體構造與限定配置下的驗證；更廣泛的智能主張，需要另外的實驗。

真正值得帶走：把「誰做的、怎麼驗的」一起交付

看到下一個「模型內建 X」展示時，先找三樣東西：哪個狀態真的放進模型、哪些結果由主機提供，以及測試在哪一個邊界停下。再把引擎、輸入、參考答案與完整失敗紀錄放在一起。當這些問題有可追查的回答，展示才開始變成能評估的工程成果。

如果你想看同一條技術脈絡的另一面，Qwenputer 的算術與交接判讀討論的是「CPU 算對，整題是否答對」；NESformer 讓我們再往系統層追一步：CPU 對了，共用的顯示、輸入與相容性又由誰驗？