Qwen NES Emulator、Nintendo CPUロジックを約1GBの重みにコンパイル
Qwen NES emulatorプロジェクトのnesformerは、リポジトリによればNintendo CPUを933MBのコンパイル済みモデル重みに収めている。デモにはSuper Mario Bros.が含まれるが、画面描画とコントローラー処理は依然として外部ソフトウェアが担う。この違いは重要だ。これはチャットボットがNintendoゲームを学習した例ではなく、モデルアーキテクチャ内で行われるプログラム化された計算実験である。
開発者のDrew BreunigはHacker Newsを通じてこのプロジェクトを共有し、見出しでは約1GBのQwen重みで動作するNintendoと説明された。リポジトリの主張は、より限定的で、かつ興味深い。コンパイラがプロセッサロジックを構築し、生成トークンがその実行を先へ進める。公開結果には独立した再現が必要だが、プロジェクトはコードと明示的な検証手順を提供している。
比較対象となるのは、Divyansh Agrawalが以前に行った、Qwenのアーキテクチャにプロセッサを埋め込む実験Qwenputerである。両プロジェクトは、AIシステムを構築する開発者に問いを投げかける。どの処理をモデル計算の内部に置き、どの処理を従来型ソフトウェアに委ねるべきか。Nesformerは身近なゲームを通じてこの問いを可視化する一方、大きな速度制約と互換性制約も文書化している。
Qwen NES emulatorはCPUを動かし、ホストがコンソールを完成させる
Nesformerの中心的な主張は、完全なコンソールのすべての構成要素ではなく、Nintendo CPUとそのメモリに関するものだ。 この境界が、成果と限界の両方を定義している。
プロジェクトによると、NESの6502プロセッサコアを、保存済みモデルパラメータ群であるQwen互換モデルチェックポイントの内部に配置している。また、作業メモリとカートリッジのプログラムデータは、モデル内で変化する内部状態に配置される。
パラメータと状態の違いは重要である。パラメータは機械の振る舞いを定め、状態はゲーム実行中に変化する情報を保持する。すべてを「重み」と呼ぶと、異なる役割が印象的な見出しの中に圧縮されてしまう。
compiled CPU designによると、モデルはプロセッサの実行記録を表す、離散的な出力記号であるトークンを生成する。これらの記号は通常の会話文ではなく、処理内容を記述する。
ホストプログラムは、周辺のコンソール動作を提供する。グラフィックスを描画し、コントローラー入力を処理し、表示タイミングに関連するイベントを供給する。入出力は実行記録を通じて境界をまたぐ。
この構成により、Nintendoシステム全体をモデル内に置かずとも、モデルは大きな役割を果たす。動く画面だけでは、この分担は見えない。リポジトリのアーキテクチャ説明によって、その分担を検査できるようになっている。
プロセッサ実装は、プロセッサにどの操作を行うか指示するエンコード済み命令である公式オペコード151種すべてをカバーする。算術、分岐、プロセッサフラグ、スタック動作を含む。
文書化されたメモリ構成には、実行中のゲームが変更できる2KBの作業RAMが含まれる。また、保存済みプログラムデータである32KBのカートリッジプログラムROMも含まれる。
カートリッジプログラムは実行開始時に状態へ読み込まれる。そのためプロジェクトは、対応ゲームであれば、タイトルごとにプロセッサを再構築せずとも同じコンパイル済み重みを共有できるとしている。
これは、デモごとに別々のアニメーションを用意することとは重要な違いである。意図されている成果物は、制限された互換性範囲を持つ再利用可能なプロセッサ実装だ。
公開されたSuper Mario Bros.の例は、見覚えのある場面を提示する。バンドルされたテストゲームは、ファイルとライセンス情報がプロジェクトに付属しているため、検証のより有用な出発点となる。
コントローラー操作は、いつボタンを押すかを指定するスクリプトに従わせることができる。文書化されたMarioのシーケンスでは、ゲームを開始し、右へ移動し、予定された間隔でジャンプする。
これは、AIエージェントがMarioの遊び方を学習した証拠ではない。コンパイルされたプロセッサロジックが、指定された入力を受け取りながらゲームの命令を実行できるという主張である。
ここでのNintendoの役割は、ハードウェアの対象とゲームの参照先である。リポジトリは、Nintendo製品やQwenとの発表済みパートナーシップではなく、独立した実験を提示している。
したがってこの公開が変えるのは、開発者が検査できる対象である。公開実装は、モデルパラメータ、プロセッサの振る舞い、可視のゲーム出力を接続する。その意義は、この検査可能なつながりにある。
コンパイル済みロジックは、このデモがAIについて語る内容を変える
重要な仕組みは意図的な構築にある。nesformerのコンパイル済み重みは、モデルにプロセッサ動作を発見させることなく、その振る舞いをエンコードする。
通常、学習では例と最適化プロセスを使ってパラメータを調整する。コンパイルは、指定された設計を別の実行可能な表現へ変換する。Nesformerのリポジトリによれば、そのコンパイラはパラメータを直接計算する。
このため、プロジェクトは事前学習済みチャットボットにプロセッサを模倣させることとは異なる。コンパイラが規則を供給し、モデルアーキテクチャがそれを実行する数学的機構を供給する。
この結果を、会話型Qwenモデルが密かにNintendoハードウェアを理解している証拠と読むべきではない。またこのデモは、通常の言語生成がソフトウェアの正確な代替手段になったことを示すものでもない。
むしろこれは、同じアーキテクチャ上の構成要素が、意図的に指定されたデジタル機械を支えられるかを探るものだ。これは表現と実行に関する問いであり、より広範な意味合いにはなお実験が必要である。
主要な構成要素は、変化する内部メモリ行列を維持するモデル機構であるGated DeltaNetだ。Nesformerはこの状態を用いて、連続して生成されるトークン間で機械情報を保存する。
その設計では、これらの行列内の行にメモリ位置を割り当てる。慎重に構築された読み取りと更新により、プロセッサレジスタ、作業メモリ、カートリッジデータをそれらの位置に配置できる。
プロセッサが直接使用する小規模な保存場所であるレジスタは、命令が変更するまで正確な値を保持しなければならない。おおまかな想起では実行が壊れる。
コンパイラは命令デコードと算術演算もモデル層へマッピングする。次の出力を生成する計算であるフォワードパスが、エンコード済み機械を実行記録に沿って進める。
プロジェクトは、ほとんどの命令に必要なトークンは1つだと報告している。一部はより長い記録を必要とし、文書化されたゲームコードの平均は1命令あたり1.1〜1.3トークンの範囲となる。
この関係は、よく知られたモデル性能指標を従来型の計算ワークロードと結び付ける。トークン列は後からプロセッサ実行を説明するだけでなく、その実行を担うため、トークンをより速く生成することが重要になる。
Qwenputerは直接的な技術的基盤を提供した。2026年10月22日に公開されたAgrawalのin-model computingの解説は、プロセッサロジックのコンパイルと、内部状態をメモリとして使う方法を説明している。
したがってQwenputer vs nesformerの比較は、連続性から始まる。Nesformerは先行するコンパイラとメモリ技法を再利用し、NESプロセッサを対象にしつつ、コンソール固有のホスト動作と接続している。
両者の周辺設計は異なる。Agrawalは、計算機構を追加しながらQwen本来の言語重みを維持することを説明している。Nesformerは、異なる層構成を持つ、より小規模でプロセッサに焦点を絞ったチェックポイントを公開している。
この違いは、サイズに関する誤解を防ぐ。Nesformerのダウンロードは、完全な会話型Qwenモデルに完全なNintendoを加えたものが、見出しにあるサイズへ収まることを示すものではない。
それが示すのは、より限定的な命題である。選択されたQwenアーキテクチャの構成要素は、コンパイル済みプロセッサ設計を収容できる。これが汎用AI製品の内部で有用になるかは、未解決のエンジニアリング上の問いである。
実用性の基準は依然として従来型の実行にある
Nesformerはアーキテクチャ上の代替案を生み出すが、公開された性能を見る限り、ゲーム実行における実用的な標準は従来型ソフトウェアのままだ。
当面の比較対象は、通常のエミュレータコードで命令を実行することと、モデル操作を通じてその実行を表現することの間にある。可視の結果だけでは、どちらの経路が有用かは決まらない。
別の機械の振る舞いを再現するソフトウェアであるエミュレータは、ここですでに明確な役割を持つ。互換プログラムを正確に実行し、許容できる速度で出力を届けなければならない。
Nesformerは別の目的を加える。モデル互換のパラメータ表現を通じてプロセッサを実行することだ。この目的があるため、従来型の実行がより効率的な場合でも、この実験には意味がある。
リポジトリは、単一のプロセッサコア上でデフォルトの最適化エンジンが毎秒約1,650トークンを処理すると報告している。より単純な数値エンジンでは約210としている。
標準のTransformers経路は、報告によれば毎秒約10トークンに達する。Transformersは、公開されたチェックポイントを読み込み、実行するために使われるモデル実行ソフトウェアライブラリだ。
これらの数値は異なる実行経路を表す。標準モデル性能についての単一の主張にまとめたり、特定されていないハードウェア間の統制比較として扱ったりすべきではない。
デフォルトエンジンは、パラメータがゼロであるブロックをスキップする。チェックポイントのパラメータの大半がゼロであるため、その構造は専用実行に特に適しており、これは重要である。
リポジトリは、メモリ書き込みも入出力書き込みも行わない反復アイドルループをスキップすることも説明している。これらのループは、次の関連する表示イベントを待機する。
この最適化は不要な作業を減らすが、速度数値を説明する際には含める必要がある。ホストは、可視の振る舞いを変えない計算の反復を避けるのに役立つ。
こうした最適化を行っても、プロジェクトは元のコンソールより150〜290倍遅い動作を報告している。600フレームの推定時間は約25分だ。
これら600フレームは、文書化された例におけるNES時間の10秒を表す。したがってこのデモが扱うのは、通常のゲームプレイを応答性高く置き換えることではなく、最終的に実行できることだ。
このことは、モデル重み内部での計算を支持する側に実用上の負担を課す。追加の実行作業と統合の複雑さを正当化する利点を特定しなければならない。
潜在的な利点には、仮定ではなく測定が必要である。モデルの計算内部に処理を保持することはアーキテクチャ上の特性であり、レイテンシ、信頼性、使いやすさを自動的に改善するものではない。
直近の圧力は、既存のエミュレータ事業ではなく、研究上の主張と評価設計にかかる。Nesformerは、従来型エミュレータが置き換えられる証拠を示していない。
同様の機構を検討する開発者は、完全な経路を比較すべきだ。状態の読み込み、実行の前進、入力の処理、出力の読み取りのすべてが、ユーザーが体験する結果に影響する。
Qwenputer vs nesformerの比較は、この精密さの必要性を強調する。異なるプロセッサ対象、周辺構成要素、実行エンジンがあるため、チェックポイントサイズや見出し上のスループットに基づく単純な順位付けはできない。
現時点では、従来型の経路が実用的な代替手段と参照動作の両方を提供する。Nesformerが注目に値するのは、既存の方法を置き換えるべきだと立証することなく、別の経路を検査可能にしているためである。
Marioのアニメーションよりも、テストの方が多くを語る
最も強い根拠は、参照動作に対するプロジェクトの多層的な比較にある。ただし、公表された結果は依然として作者による報告である。
ゲームのアニメーションは、何らかの認識可能なものが表示されたことを示す。しかし、命令が正しく実行されたか、参照システムから修正が提供されたか、各フレームをどのソフトウェアが生成したかまでは明らかにしない。
Nesformerのドキュメントは、これらの問いを分けて扱っている。参照プロセッサ、コンパイル済み回路、保存済みチェックポイント、そしてより長い実行シーケンスに対する検証を説明している。
この区別は、期待結果として用いられる従来の実装である参照CPUから始まる。参照実装に欠陥があれば、出力が一致しても意味は薄くなる可能性がある。
リポジトリは、その参照実装を、期待される実行記録を持つプロセッサ適合性テストであるnestestと比較したと報告している。対応範囲内で3,348件の命令が一致したとしている。
また、ゲームコードの570万命令にわたり、別のプロセッサエミュレータであるpy65とも比較したと報告している。これは参照実装に対する追加の検証となる。
コンパイル済み回路にも、独自の比較が行われている。ドキュメントは、nestestと2本のゲームの起動シーケンスから得た283,610地点において一致したと報告している。
これらの結果は、指定された回路の動作を扱う。しかし、それだけで保存済みモデルがすべての実行エンジンを通じて完全に同一の結果を生成することまでは立証しない。
そのためリポジトリは、nestestとFull Gameの2,651地点を対象とする、別個のstock Transformers検証を報告している。そのサンプルでは不一致がなかったとしている。
stock checkpoint checker は、この比較の仕組みを示している。モデルを読み込み、マシン状態を初期化し、予測出力を与えられた参照シーケンスと照合する。
この手法はteacher forcingを使用し、各比較ステップにおいて既知の直前の出力を入力する。局所的な予測は検証できるが、同等に長い中断のない自律実行までは立証しない。
一方、自由実行ではシステム自身の出力を次の入力として与える。エラーは後続の状態を変え得るため、持続的なシーケンスでの一致は別の検証上の問いに答える。
プロジェクトは、自由実行のThwaiteで1,916,527トークンと600フレームを対象にしたと報告している。保存された300フレームすべてが参照出力と一致したとしている。
Full Gameについては、2,645,885トークンと420フレームを報告している。ドキュメントでは、保存された210フレームすべてが一致したとしている。
これらの件数は、普遍的な保証ではなく、具体的な証拠に関する主張である。特定のゲーム、入力シーケンス、実行経路、長さに関するものだ。
processor verification tests では、参照実装、回路、実行エンジン、アイドルループ最適化に対する自動比較が公開されている。公開されているため、対象を絞った再現が可能になる。
ただし、テストを読むことと実行することは異なる。この分析では公開実装とドキュメントを調査したが、チェックポイントを独自に実行したり、報告された性能を再現したりはしていない。
この区別は、伝聞の中でも維持されるべきだ。このプロジェクトは裏付けのないソーシャル上の主張より多くの証拠を提供しているが、公開コードと作者報告の一致は独立した検証と同義ではない。
Qwen NES emulatorにとって、次に信頼性を高めるために必要なのは、実行エンジンを明確に特定したうえでの、より広範な再現だ。より大きなアニメーションよりも、文書化された一致トレースの方が信頼を高める。
1GBという見出しは、スパース保存と欠けているハードウェアの両方を隠している
チェックポイントサイズは報告されたファイル容量としては事実だが、完全なコンソールや総実行時メモリを示すものではない。
リポジトリには、16ビットを各値に使用する数値形式であるbfloat16で保存された4億6,660万パラメータが記載されている。その結果としてパラメータ容量は933 MBとされている。
ドキュメントによると、非ゼロのパラメータは930万個にすぎない。プロジェクトは、この規則性により重みを3.3 MBのアーカイブへ圧縮できるとしている。
これらは異なる量である。アーカイブのダウンロード容量、展開されたパラメータファイル、実行中プロセスが消費するメモリは、それぞれ異なる運用上の問いに答える。
記事の約1GBという説明は、展開された重みに関するものだ。完全なアプリケーションに必要なメモリがそれだけだという主張に変えてはならない。
スパース構造は性能の解釈も変える。ゼロブロックを回避する専用エンジンは、完全なパラメータ配置を処理する実装とは異なる処理を行っている。
これはチェックポイントに関する主張を無効にするものではない。互換性、保存容量、実行効率には、単一の圧縮された見出しではなく、別々の測定が必要だという意味である。
ハードウェアの境界にも、もう一つの留保がある。グラフィックス動作を担うNESコンポーネントである画像処理ユニットは、ホストソフトウェア側に残されている。
コンソールの音響ハードウェアである音声処理ユニットも、重みの外にある。リポジトリによれば、現行実装は音を出力しない。
グラフィックスの忠実度にも限界がある。ホストは画像の横方向の行である走査線を描画するが、行の途中で起きる効果は再現しない。
ドキュメントは、特定のスプライト状態条件について近似的な動作も説明している。スプライトとは、キャラクターやその他の移動オブジェクトに使われる、個別に制御される画像要素である。
カートリッジ対応は、プログラムバンク切り替えのない単純な基板構成であるNROMに限定されている。バンク切り替えは、プロセッサがより大きなカートリッジプログラムのどの部分にアクセスできるかを変更する。
Nesformerの文書化された設計は固定プログラムテーブルを使用する。より複雑なカートリッジをサポートするには、互換性リストに新しいタイトルを追加するだけでなく、追加の状態とアドレス選択ロジックが必要になる。
実行上の制約はカートリッジ形式にとどまらない。未対応の非公式命令はシステムを停止させ、コードは作業用RAMではなくカートリッジメモリから実行されなければならない。
プロジェクトは、ハードウェアイベントにプロセッサを応答させる信号である割り込み動作が欠けていることも挙げている。一部の対応イベントは機能するが、文書化された対応範囲は不完全だ。
こうした制限が、「動作する」という言葉の意味を形作る。システムは定義された範囲内で特定のゲームを正しく実行できても、より広いライブラリには適さない場合がある。
また、報告されたテストをすべてのNintendoソフトウェアへ一般化することも妨げる。対応命令での一致は、実装が明示的に省いているハードウェア動作を補うものではない。
したがってnesformerのコンパイル済み重みは、部分的なコンソール実装へ接続されたプロセッサ成果物として評価するのが最適である。この説明なら、互換性に関する主張を拡大することなく、プロジェクトの異例な貢献を保てる。
開発者にとって有用な懐疑的な問いは具体的だ。観測された動作のうち、コンパイル済みプロセッサロジックに由来するものはどれで、ホスト側の仮定に由来するものはどれか。リポジトリはレビュアーに出発点となる地図を提供している。
次に必要なのは、独立した再現、より広い互換性、完全なシステム速度だ
次に有用な証拠は、信頼性、対応範囲、測定された実用性の順に拡大すべきだ。 これらのシグナルは、さらなる注目の波よりも多くを伝える。
まず、公開されたトレース比較の独立した再現に注目したい。信頼できる報告では、チェックポイント、ゲーム入力、実行エンジン、比較手法を特定すべきである。
stock Transformersの動作を再現できれば、その成果物が公称のモデルインターフェースを通じて機能するという主張が強まる。より長い自由実行比較は、短い参照入力サンプルを超えた持続的な一致を検証する。
不一致が出た場合、即座に退けるのではなく診断が必要だ。数値的挙動、状態初期化、エンジンの違い、未対応機能は、異なる含意を持つ別個の原因候補である。
次に、適合性テストで裏付けられた互換性の改善に注目したい。実装がメモリ動作を文書化し、代表的なプログラムを検証するなら、カートリッジ対応の追加は意味を持つ。
サウンドと、より正確なグラフィックスのタイミングは別個の欠落を補う。レビュアーは、より多くのハードウェアを重みに移すことと、ホストの従来実装を改善することを区別すべきだ。
どちらの変更もアプリケーションを改善し得るが、computing-inside-weightsという主張の範囲を広げるのは前者だけである。明確な境界があれば、将来の比較も解釈可能に保てる。
第三に、指定ハードウェア上での完全な性能測定に注目したい。有用な報告は、起動、実行、ホスト側の処理、要求されたゲームシーケンスの生成に必要な時間を対象とするだろう。
選択された計算だけに限定された高速化は、より狭い主張を強める。対応ゲーム全体で完全な実行が高速化すれば、実用的な進歩を示すより強い証拠になる。
Breunigのdeveloper discussion は、プロジェクトの意義について別の視点を提供している。AI支援開発を説明する中で、彼は既存の参照資料、以前のコンパイラ、適合性テストに言及している。
支持的なコメント投稿者は、こうした参照検証の価値を強調した。懐疑的な参加者は、通常のコードを直接実行するのではなく、コードをモデル演算へ変換する効率に疑問を呈した。
どちらの反応も、エンジニアリング上の問いを解決するものではない。両者を合わせると、プロジェクトの当面の価値が見えてくる。すなわち、可視的な出力、明示的な境界、他の開発者が確認できる動作を備えた実験である。
エンジニアにとっては、仕様、参照実装、テスト証拠を含むsearchable knowledge baseを維持する価値も浮き彫りになる。こうした資料は、実装だけでなくレビューも支援する。
Qwen NES emulatorを評価する際は、アニメーションではなく検証経路から始めよう。チェックポイントが計算するものとホストが提供するものを比較し、その後に報告された実行トレースを調べる。ファイルサイズ、実行時メモリ、完全なアプリケーション速度は分けて考えるべきだ。プロジェクトを追うなら、公表結果を確立済みと見なす前に、独立した一致実行を探してほしい。次に、互換性がテスト済みのプロセッサおよびカートリッジ動作によって拡大するのか、それとも主に周辺ソフトウェアの変更によるのかを見守ろう。こうした区別により、開発者は実験を評価しつつ、その関連性について健全な判断を下せる。あなたの評価を最も変える次の結果はどれだろうか。独立した再現、より広いハードウェア対応、それとも完全な実行時間の測定可能な短縮か。
