Tech Teardown 036｜Nesformer：NESをQwenの重みにコンパイル

技術分解：ホットトピックの発表 × 技術的判断 × 実用的な提案。

---

背景/現象

2026年10月30日、GitHub上にNesformerというプロジェクトが登場しました。その自己紹介は非常に率直で、「An NES CPU compiled into the weights of a stock Qwen3.5 model.」つまり、作者はゲームAIを訓練したり、従来のシミュレーターを作成したりすることなく、ニンテンドーエンターテイメントシステムのCPUをQwen3.5の重みに組み込んだということです。このモデルは微調整を行わず、すべてのパラメータはコンパイラによって直接計算されます。

この出来事はすぐに技術界の注目を集めました。なぜなら、これにより「大規模モデルの重みがコンピュータとして機能するか」という問題が極端な形で問われたからです。過去には、LLMをチャットツールと見なし、重みを訓練された統計的な規則の集合体と見なしていました。Nesformerのやり方は、重みが単なる言語の統計的容器ではなく、完全なゲーム機CPUを直接コーディングできるものであると宣言するに等しいです。

その上流にはDivyansh AgrawalのQwenputerがあります。後者はCHIP-8やRISC-V CPUをQwen3.5-4Bに組み込んでおり、このアプローチが実行可能であることを証明しました。Nesformerは対象をより複雑なNES、つまり80年代に世界中で人気だった红白机の美版に変えました。CHIP-8からRISC-V、そしてNESへと複雑さが段階的に高まる中、概念実証の意義も明らかになっています。

NES自体のハードウェアは複雑ではありません：1.79MHzのRicoh 2A03プロセッサ（MOS 6502互換）、2KBのメモリ、PPUが画像出力を担当し、APUが音声を担当します。しかし、このようなシステムをLLMの重みに組み込むには、CPU命令セット、メモリアドレス、I/Oマッピング間の完全なマッピングが必要です。作者dbreunigがNESを選んだのは、その古典的なゲームが実演できるからであり、また十分に複雑で、「重み即ちコンピュータ」という命題の境界を真に試すことができるからです。

このプロジェクトはHacker NewsでShow HN形式で公開された後、すぐに多くの議論を集めました。創造性に驚く人もいれば、実用性に疑問を持つ人もいました。しかし、立場に関わらず、ほとんどの人が同意しています：少なくともエンジニアリングの面では、SFのように聞こえるものを実行可能なコードに変えたのです。

技術原理/アーキテクチャ

Nesformerの核心的なアプローチは、CPU、RAM、ROMをすべて大規模モデルの状態にマッピングすることです。選択された基本モデルはQwen3.5-4Bで、実際の構造は大幅にカットされています：7層のGated DeltaNetのみが保持され、HuggingFaceのキャッシュ要件を満たすために1層の全ゼロattention層が追加されています。総パラメータ数は466.6M bf16ですが、非ゼロパラメータはわずか9.3Mで、圧縮後のweights zipはわずか3.3MBです。

重要なトリックは、Gated DeltaNetの状態行列にあります。著者は状態行列の各行を一つのアドレス可能なメモリユニットとして扱い、gate=1を設定して減衰しないようにし、write strength=1で完全にカバーするようにします。そして、one-hotキーを使用して正確に位置づけます。これにより、各書き込みが特定の行を正確にカバーし、CPUレジスタ、RAM、ROMの動作をシミュレートできます。

具体的には、モデルの重みにはNES 6502 CPUの全151の公式opcode、すべてのアドレスパターン、フラグビット、スタック、およびBRK/NMIのエントリアがコードされています。2KBのワークRAM、32KBのPRG-ROM（2つに分けて、1つは命令を取り出し、もう1つはデータを読み出す）、256バイトのOAM DMAもモデルに組み込まれています。レンダリング層のPPU、コントローラー入力、APUレジスタの書き込み、およびvblank NMIの注入は、外部のhost.pyが担当します。

言い換えれば、Nesformerは「NESゲームを実行する」ことを2つの部分に分けています。モデル内部はCPUの実行とメモリ状態の更新を担当し、モデル外部はトークンストリームを画面ピクセルとユーザー入力に変換します。この分担により、重みが計算タスクを実際に担い、hostは結果を可視化するだけにします。

従来のシミュレータが循環処理でopcodeを解釈するのに対し、Nesformerの方法はCPU状態マシン全体を行列乗算に展開することです。各フローアッププロパゲーションは1つのCPUサイクルに対応し、トークンの流れはデータがレジスタとメモリ間で移動することを意味します。DeltaNetの再帰的状態は、「前回の状態 + 現在の入力 → 次の状態」という離散時間システムを表現するのに適しており、これがCPUをコンパイルする代わりに訓練する理由です。

語彙表の規模も注目に値します：263,808個のトークン。この大きな語彙表は言語の多様性のためではなく、CPUアドレス、データバス、制御信号を離散的なトークンにコードしたためです。1つのトークンを入力すると、モデルは現在の状態と命令に基づいて次の状態更新を行います。この設計により、モデルのフローアッププロセスはCPUのクロックサイクルと一対一の対応関係を形成しています。

重要データ/ケース

性能面では、Nesformerはまだ実用的とは言えません。その速度は実際のNESの約150倍から290倍遅いです。numbaで最速にコンパイルしたフローアップパスを使用し、ジャンプブロックの最適化を組み合わせると、単一コアで約1,650個のトークン/秒の速度になります。一方、stock transformersパスを使用すると10個のトークン/秒にしかなりません。実際のNESがフレーム全体を実行するには約700,000個のトークン/秒が必要であり、その差は明らかです。

検証データに関して、著者はSuper Mario Bros.やDonkey Kongを含むいくつかのNROMマッパー0ゲームを検証しました。より厳格な一貫性テストによると、Thwaite 600では1,916,527個のトークンが使用され、シミュレーション時間は10.0秒で、そのうち300フレームが通常の6502エミュレータのフレームごとの状態と一致していました。Doug Fraker Full Game 420では2,645,885個のトークンが使用され、同様にフレームごとに一致していました。nestestの一貫性チューニングキットは4,586個のトークンでHALT状態に達しました。これらのデータは、モデルが論理的なレベルで6502 CPUの動作を実際に再現していることを示しています。

しかし、これらのデータはすべてREADMEから得られたものであり、私はローカルで再検証を行っていません。実行フレームレートはハードウェアやnumbaのバージョンにも影響されます。読者が実際に再現したい場合は、約1GBの解凍後のbf16ウェイトをダウンロードし、shasumでweights/SHA256SUMSをチェックする必要があります。構築環境にはPython 3.11以上、さらにnumpy、scipy、numba、pillowが必要です。実行コマンドはpython -m nesformer run ROMで、--frames、--buttons、および--showなどのオプションパラメータをサポートしています。

圧縮率の観点から見ると、Nesformerのパラメータ分布も興味深いです。466.6Mのbf16パラメータのうち、9.3Mのみが非ゼロであり、希薄度は98％を超えています。圧縮後のウェイトパッケージはわずか3.3MBで、多くのNES ROM自体よりも小さいです。これは、コンパイルによって生成されたウェイトが非常に少ない有効な情報で複雑な確定的計算を表現できることを示し、少なくとも理論的なレベルで「パラメータが大きいほど良い」という固定観念に挑戦しています。

影響/意義

Nesformerの最大の意義は、「ウェイト即ちコンピュータ」という隠喩を実行可能な工学的事実に変えた点です。過去には、LLMが算術を行うことができるか、プログラムを実行できるかについて議論が行われていましたが、ほとんどがpromptのレベルに留まっていました。Nesformerは、適切なアーキテクチャ設計があれば、大規模モデルの状態空間を一般的な計算と記憶構造に直接コーディングでき、何のトレーニングも不要で、すべてコンパイラによって生成されることを証明しました。

この事実は、モデルアーキテクチャ研究に二つの示唆を与えます。第一に、Gated DeltaNetの状態行列のプログラマビリティが検証されました。gate、write strength、keyの分布を適切に制御すれば、状態行をアドレス可能なメモリに変えることができます。第二に、新しい圧縮アプローチが提示されました。466.6Mのbf16パラメータのうち、9.3Mのみが非ゼロであり、圧縮後はわずか3.3MBになります。これは、希薄化とコンパイリング型生成が、特定のタスクに対してトップダウントレーニングよりも適している可能性を示しています。

より広い視点から見ると、NesformerとQwenputerは、「LLMのウェイト内で仮想マシンを実行する」という話題をさらに複雑なものに押し上げました。CHIP-8やRISC-Vは教育用デモンストレーションに近く、NESはCPU、メモリ、I/O、レンダリングの調整を含む、より完全なシステムです。将来的には、このようなアプローチがモデル内により複雑な確定的計算モジュールを組み込むために使用される可能性があります。

このプロジェクトは「モデル」と「プログラム」の境界を曖昧にしています。従来のソフトウェアエンジニアリングでは、プログラムとメモリは別々ですが、Nesformerはそれらを同じ重みグループに統合しました。この方向で開発が続けば、将来的には、LLMの重みに言語理解、推論能力、そして固定されたビジネスルールエンジンが同時に含まれ、配備時には単一のファイルが必要になるようなアプリケーションが出現するかもしれません。

端末側の配備においては、このような高度に希薄なコンパイル重みも魅力的です。将来的にスマートフォンやIoTデバイスが非常に確定的なプロトコルスタックや状態機械を実行する必要がある場合、モデル重みにそれをコンパイルすることで、個別にランタイムを維持するよりも軽快になります。もちろん、推論効率と維持可能性の間のバランスを見つける必要があります。

議論/リスク

まずは性能のボトルネックです。実際のNESに比べて150から290倍遅いということは、現時点では概念验证としてのみ使用でき、実際のプレイ体験にはまだ遠いということを意味します。将来的に量化、コンパイル最適化、専用ハードウェアアクセラレーションを通じて、トークンのスループットを千単位から実際のホストの十万単位以上に向上させるには、まだ数桁の改善が必要です。

次に維持可能性と拡張性です。CPUを重みにコンパイルすることは、どんなバグ修正や機能拡張もコンパイラを再実行することを意味し、従来のシミュレーターのように数行のコードを変更するのではありません。MMC3やMMC5のようなより複雑なゲームに対しては、重みのサイズが大幅に増大する可能性があり、現在の方案が拡張可能かどうかは未知数です。

第三に評価基準の限界です。リポジトリのREADMEにあるすべての性能数値と一貫性テストは、著者自身が実行したものであり、現在独立した第三者による再現はありません。さらに、Mapper 0のゲームのみを実行できるため、カバー範囲は限られています。読者がこれらの数値を引用する際には、「著者自らが述べた」という制限を加える必要があります。

最後に、より深い問題があります：汎用計算をLLMの重みにコンパイルすることで、本当にエンジニアリング上の利点が生まれるのでしょうか？単に互換性のためにというだけであれば、従来のシミュレーターの方が明らかに速く、デバッグも容易です。Nesformerの価値は、既存の方案を置き換えることではなく、境界を探求することにあります。

また、このような確定的計算をニューラルネットワーク重みにコンパイルする方法は、解釈可能性に関する懸念も引き起こしています。従来のシミュレーターの各行のコードは明確なハードウェア動作に対応していますが、重み内の計算は高度に分散化されています。システムにエラーが発生した場合、特定し修正するのは従来のソフトウェアよりもはるかに困難です。

結論/展望

Nesformerは、高純度の技術展示です。何の重みも訓練していない代わりに、NESのCPUをQwen3.5の7層Gated DeltaNetにコンパイルし、6502 CPU、RAM、ROM、OAMの動作を希薄なパラメータで再現しました。Super Mario Bros.やDonkey Kongを実行できますが、速度は実際のホストよりも2桁遅いです。

短期的には、このプロジェクトはモデルアーキテクチャ、コンパイラ、レトロゲームシミュレーションの3つの分野の注目を集めるでしょう。それは再現可能なベンチマークを提供し、研究者が「状態行列即ちメモリ」の上限を直接テストできるようにします。中期的には、このようなコンパイル方法がより複雑なMapperやより効率的な推論パスに拡張されれば、端末側デバイスで一つのモデル重みが複数の確定的機能を同時に実行するシナリオが実現されるかもしれません。長期的には、大モデルの重み空間はチャット、要約、推論よりもはるかに広く、適切なコンパイル方法を見つければ、任意の計算構造にプログラムできることを思い出させてくれます。

将来興味深い研究の方向性として「ハイブリッドウェイト」があります。言語理解や推論の部分は従来の訓練で得られるものを使用し、確定的なルール、プロトコル解析、状態機械などのモジュールはコンパイル方式で組み込まれます。これにより、ニューラネルズの柔軟性を保ちつつ、検証可能な確定的な行動を実現できます。Nesformerはこの方法が成功することを証明しており、次はそれを玩具プロジェクトから実際のエンジニアリング応用へと発展させることができるかどうかです。もう一つの解決すべき問題はコンパイラの汎用性です。現在、NES向けに多くの手作業によるマッピングが行われていますが、これをより汎用的な「任意の有限状態機械をウェイトにコンパイルする」ツールチェーンに抽象化できれば、この方向性の最終的な価値が決まります。

このプロジェクトはMITライセンスを採用しており、コードとビルド手順は公開されています。この「ウェイト即ちコンピュータ」というアプローチに興味がある場合は、直接リポジトリをクローンし、READMEの手順に従って実行してください。全速力でゲームを実行できなくても、930万個の非ゼロパラメータを使ってNESを再現する方法を見るだけでも、考える価値があります。

署名：永亮