Qwen NES Emulator 將 Nintendo CPU 邏輯編譯至約 1GB 權重之中

根據其儲存庫，Qwen NES emulator 專案 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 emulator 運行 CPU，而主機程式補完整部主機

Nesformer 的核心主張關乎 Nintendo CPU 及其記憶體，而非完整主機的每一個組件。 這條界線定義了它的成就和局限。

該專案表示，它將 NES 的 6502 處理器核心置於 Qwen 相容模型 checkpoint 內；checkpoint 是已儲存的一組模型參數。它亦將工作記憶體及卡匣程式資料置於模型持續變化的內部狀態之中。

參數與狀態之間的分別很重要。參數決定機器的行為；狀態則儲存遊戲運行時會改變的資訊。把一切都稱為「權重」，會把這些不同職責壓縮成一個吸引人的標題。

根據已編譯 CPU 設計，模型會生成 token，即離散輸出符號，用以代表處理器的執行紀錄。這些符號描述的是操作，而非一般對話文字。

主機程式提供主機周邊行為：它繪製圖像、處理控制器輸入，並提供與顯示時序相關的事件。輸入和輸出會經由執行紀錄跨越這條界線。

這種安排讓模型承擔重要角色，同時不把整個 Nintendo 系統都置於其中。僅看流動的畫面，會掩蓋這種分工。儲存庫的架構說明讓外界可以檢視這項分工。

處理器實作涵蓋全部 151 個官方 opcode，即告訴處理器應執行哪種操作的編碼指令。它包括算術、分支、處理器旗標及堆疊行為。

文件記錄的記憶體配置包括 2 KB 工作 RAM，即運行中的遊戲可改變的記憶體；亦包括 32 KB 卡匣程式 ROM，即儲存的程式資料。

卡匣程式會在執行開始時載入狀態。因此，該專案稱，在毋須為每個遊戲重新建構處理器下，支援的遊戲可以共用同一組已編譯權重。

這與為每個示範製作獨立動畫有實質差別。目標產物是可重用的處理器實作，但其相容性範圍有限。

已發表的 Super Mario Bros. 範例提供了易於辨認的畫面。隨附的測試遊戲則提供了更有用的驗證起點，因為其檔案及授權資訊均隨專案提供。

控制器動作可跟隨腳本，指定何時按下按鈕。文件記載的 Mario 序列會啟動遊戲、向右移動，並在預定間隔跳躍。

這並非 AI agent 學會玩 Mario 的證據。其主張是，已編譯的處理器邏輯可在接收預設輸入的同時執行遊戲指令。

Nintendo 在此的角色是硬件目標及遊戲參考。儲存庫將其呈現為一項獨立實驗，而非 Nintendo 產品，亦非與 Qwen 公布的合作關係。

因此，這次發佈改變了開發者可檢視的內容：公開實作把模型參數、處理器行為及可見遊戲輸出連接起來。其重要性建基於這種可供檢視的連結。

已編譯邏輯改變了這項示範對 AI 的意義

重要機制是刻意建構：nesformer 的已編譯權重在毋須訓練模型自行發現的情況下，編碼處理器行為。

訓練通常透過範例及最佳化過程調整參數。編譯則是把指定設計轉換成另一種可執行表示法。Nesformer 的儲存庫表示，其編譯器直接計算參數。

這令專案有別於要求預訓練聊天機械人模仿處理器。編譯器提供規則，而模型架構則提供執行這些規則的數學機制。

結果不應被解讀為對話式 Qwen 模型暗中理解 Nintendo 硬件的證據。這項示範亦不能證明一般語言生成已成為軟件的精確替代品。

相反，它探索相同的架構組件能否支援一部刻意指定的數碼機器。這是關於表示法與執行的問題，較廣泛的影響仍須實驗驗證。

關鍵組件是 Gated DeltaNet，一種維持可變內部記憶體矩陣的模型機制。Nesformer 利用該狀態，在連續生成的 token 之間儲存機器資訊。

其設計將記憶體位置分配至這些矩陣中的列。經過精心建構的讀取與更新，可讓處理器暫存器、工作記憶體及卡匣資料佔據這些位置。

暫存器是供處理器直接使用的小型儲存位置，必須保留精確數值，直至指令將其改變。近似回憶會破壞執行過程。

編譯器亦將指令解碼及算術映射至模型層。一次 forward pass，即產生下一個輸出的計算，會沿着執行紀錄推進已編碼的機器。

該專案報告，大多數指令只需一個 token；有些則需要更長的紀錄，而文件所載遊戲程式碼平均每條指令需 1.1 至 1.3 個 token。

這種關係將熟悉的模型效能指標與傳統運算工作負載連接起來。更快生成 token 很重要，因為 token 序列承載着處理器執行，而非僅在事後描述它。

Qwenputer 提供了直接的技術基礎。Agrawal 於 2026 年 10 月 22 日發表的模型內運算文章，說明如何編譯處理器邏輯，並以內部狀態作為記憶體。

因此，Qwenputer vs nesformer 的比較始於延續性。Nesformer 重用較早的編譯器及記憶體技術，然後以 NES 處理器為目標，並把它連接至主機專屬的主機程式行為。

兩者周邊設計不同。Agrawal 描述在保留 Qwen 原有語言權重的同時加入運算機制；Nesformer 則發佈較小、以處理器為重點的 checkpoint，採用不同的層次配置。

這個區別避免了對大小作出誤導性結論。Nesformer 的下載檔案並不能證明完整對話式 Qwen 模型加上完整 Nintendo，可裝入標題所述的體積。

它證明的是一個更有限的命題：經挑選的 Qwen 架構組件可以承載已編譯的處理器設計。這能否在通用 AI 產品中變得實用，仍是開放的工程問題。

傳統執行方式仍是衡量實用性的基準

Nesformer 創造了一種架構上的替代方案，但其已發表效能顯示，若要運行遊戲，傳統軟件仍是實際標準。

眼前的比較是：在普通模擬器程式碼中執行指令，與透過模型操作表達其執行。可見結果並不能判定哪條路徑更實用。

模擬器，即重現另一部機器行為的軟件，在此已有明確任務：它必須準確運行相容程式，並以可接受速度輸出結果。

Nesformer 加入另一個目標：透過與模型相容的參數表示法執行處理器。即使傳統執行方式仍較有效率，這個目標亦解釋了實驗的意義。

儲存庫報告，其預設最佳化引擎在單一處理器核心上每秒約可處理 1,650 個 token；較簡單的數值引擎則約為 210 個。

其原生 Transformers 路徑據報每秒約達 10 個 token。Transformers 是用於載入及執行已發表 checkpoint 的模型運行軟件函式庫。

這些數字描述不同的執行路徑。不應將其合併為對原生模型效能的單一主張，也不應視為未指明硬件之間的受控比較。

預設引擎會略過參數為零的區塊。這一點很重要，因為 checkpoint 中大部分參數均為零，令其結構特別適合專門執行。

儲存庫亦描述略過不作任何記憶體或輸入輸出寫入的重複閒置迴圈。這些迴圈會等待下一個相關顯示事件。

該最佳化減少不必要的工作，但任何對速度數字的說明都應包括這一點。主機程式有助避免重複不會改變可見行為的計算。

即使採用這些最佳化，該專案仍報告其運行速度比原始主機慢 150 至 290 倍。其對 600 幀的估算約為 25 分鐘。

在已記錄的範例中，這 600 幀代表 10 秒 NES 時間。因此，示範所關乎的是最終能否執行，而不是取代一般遊戲玩法的即時回應體驗。

這將實際舉證責任放在主張於模型權重內運算的人身上。他們必須找出足以證明額外執行工作及整合複雜度合理的好處。

潛在好處需要量度，而非假設。將操作保留在模型運算之內是一項架構特性；它不會自動改善延遲、可靠性或可用性。

當前壓力落在研究主張及評估設計，而非現有模擬器業務。Nesformer 沒有提供傳統模擬器面臨被取代的證據。

考慮採用類似機制的開發者，應比較完整路徑。載入狀態、推進執行、處理輸入及讀取輸出，都會影響使用者實際體驗到的結果。

Qwenputer vs 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，即在每個比較步驟中餵入已知的前一個輸出。它測試局部預測，但無法證實同樣長度、不間斷的自主執行。

Free-running 執行則會將系統本身的輸出餵回系統。錯誤可能改變後續狀態，因此在持續序列中的一致性回答的是另一個驗證問題。

項目報告稱，free-running Thwaite 執行涵蓋 1,916,527 個 token 及 600 幀，並稱所有 300 個已儲存畫面均與參考輸出相符。

至於 Full Game，報告稱涵蓋 2,645,885 個 token 及 420 幀。其文件稱，全部 210 個已儲存畫面均相符。

這些數字是具體的證據主張，而非普遍保證。它們涉及特定遊戲、輸入序列、執行路徑及長度。

processor verification tests 公開了對參考實作、電路、執行引擎及 idle-loop 最佳化的自動化比較。其可用性令針對性的重現成為可能。

然而，閱讀測試與實際執行測試不同。本分析檢視了已公開的實作及文件；並未獨立執行 checkpoint，亦未重現所報告的效能。

這個區分應在轉述時保留。項目提供的證據多於未經支持的社交媒體說法，但公開程式碼及作者報告的一致性，並不等同獨立驗證。

對於 Qwen NES emulator 而言，下一個可信的進展是以清楚識別的執行引擎進行更廣泛的重現。相比更大型的動畫，一條有文件記錄的相符執行追蹤能帶來更多信心。

1GB 標題同時掩蓋了稀疏儲存與缺失的硬件

checkpoint 大小作為已報告的檔案佔用空間是真實的，但它並不描述完整主機或總執行時記憶體。

儲存庫列出 4.666 億個以 bfloat16 儲存的參數；這是一種每個數值使用 16 位元的數值格式。它給出的參數佔用空間為 933 MB。

根據文件，只有 930 萬個參數非零。項目稱，這種規律性使權重可壓縮為一個 3.3 MB 壓縮檔。

這些是不同的量度。壓縮檔下載大小、展開後的參數檔案，以及執行程序所消耗的記憶體，回答的是不同的實務問題。

文章約 1GB 的描述針對展開後的權重，不應被延伸為完整應用程式只需要如此多記憶體的說法。

稀疏結構亦改變效能的詮釋。會避開零區塊的專用引擎，所做的工作不同於處理完整參數布局的實作。

這並不會否定 checkpoint 的主張，而是表示相容性、儲存及執行效率需要分開量度，而非濃縮成單一標題。

硬件界線亦帶來另一項限定。負責圖像行為的 NES 元件 picture processing unit，仍在 host 軟件中執行。

audio processing unit，即主機的聲音硬件，亦不在權重之內。儲存庫稱，目前實作不會產生聲音。

圖像還原度亦有局限。host 會繪製 scanline，即畫面的水平列，但不會重現於同一列中途出現的效果。

文件亦描述了某些 sprite 狀態條件的近似行為。sprite 是可獨立控制的圖像元素，用於角色及其他移動物件。

卡匣支援僅限於 NROM，這是沒有程式 bank switching 的簡單電路板配置。Bank switching 會改變處理器可存取的大型卡匣程式部分。

Nesformer 文件記錄的設計使用固定程式表。要支援更複雜的卡匣，將需要額外的狀態及位址選擇邏輯，而非只在相容清單加入新遊戲名稱。

執行限制不止於卡匣格式。不受支援的非官方指令會停止系統，而程式碼必須從卡匣記憶體執行，而非工作 RAM。

項目亦列出缺失的 interrupt 行為，即令處理器回應硬件事件的訊號。部分支援事件可運作，但文件記錄的涵蓋範圍並不完整。

這些限制塑造「可運作」的意義。一個系統可以在既定範圍內正確執行特定遊戲，同時仍不適合更廣泛的遊戲庫。

它們亦令已報告測試不能概括至所有 Nintendo 軟件。對受支援指令的一致性，無法補足實作明確省略的硬件行為。

因此，最適合的評價是：nesformer 編譯權重是一個連接至部分主機實作的處理器產物。這個描述保留了項目不尋常的貢獻，同時不擴大其相容性主張。

對開發者而言，有用而帶懷疑精神的問題很具體：哪些觀察到的行為源自編譯後的處理器邏輯，哪些源自 host 假設？儲存庫為審查者提供了一張起步地圖。

接下來是獨立重現、更廣相容性及完整系統速度

下一項有用證據應按次序擴展信心、覆蓋範圍及已量度的實用性。 這些訊號比新一輪關注更具參考價值。

首先，留意是否有人獨立重現已公開的執行追蹤比較。一份可信報告應識別 checkpoint、遊戲輸入、執行引擎及比較方法。

重現 stock Transformers 的行為，將加強該產物能透過所宣稱模型介面運作的主張。更長的 free-running 比較，則可測試超越短篇參考輸出餵入樣本的持續一致性。

出現不相符時，應作診斷，而非立即否定。數值行為、狀態初始化、引擎差異及不受支援功能，都是不同的可能原因，具有不同含義。

第二，留意是否有以相容性測試支持的改善。若實作記錄其記憶體行為並驗證具代表性的程式，額外卡匣支援便具意義。

聲音及更準確的圖像時序會填補不同缺口。審查者應區分把更多硬件移入權重，與改善 host 的傳統實作。

兩者都可改善應用程式，但只有前者會擴展「運算在權重之內」這項主張的範圍。清晰界線將令未來比較保持可詮釋性。

第三，留意特定硬件上的完整效能量度。有用的報告應涵蓋啟動、執行、host 工作，以及產生所需遊戲序列所需時間。

若速度提升僅限於某項選定運算，只會加強較狹窄的主張。跨越受支援遊戲的更快完整執行，才會提供更有力的實際進展證據。

Breunig 的開發者討論為項目意義提供另一個角度。他在描述 AI 輔助開發時，歸功於既有參考材料、較早期的編譯器及相容性測試。

支持者留言強調這些參考檢查的價值。持懷疑態度的參與者則質疑，將程式碼轉換為模型運算，而非直接執行普通程式碼，是否具有效率。

兩種反應都未能解決工程問題，但它們共同指出項目的即時價值：這是一項具有可見輸出、明確界線，以及可供其他開發者檢查行為的實驗。

對工程師而言，這亦突顯維護一個包含規格、參考實作及測試證據的可搜尋知識庫之價值。這類材料同時支援審查及實作。

評估 Qwen NES emulator 時，應先檢視驗證路徑，而非動畫。比較 checkpoint 所計算的內容與 host 所提供的內容，然後檢視已報告的執行追蹤。將檔案大小、執行時記憶體及完整應用程式速度分開看待。如你持續關注項目，在將已公開結果視為既定事實前，先尋找獨立的相符執行結果。然後留意相容性是透過已測試的處理器及卡匣行為擴展，還是主要來自周邊軟件的變動。這些區分讓開發者欣賞這項實驗，同時就其相關性作出穩健決定。下一項哪種結果最會改變你的評估：獨立重現、更廣硬件覆蓋，還是完整執行時間的可量度下降？