nesformer: Qwen 3.5の重みの中でNintendo Entertainment Systemを動かす

LLMの重みによるNESエミュレーション

nesformerは、完全なNintendo Entertainment System (NES) の6502 CPU、2 KBのワークRAM、およびカートリッジROMを、標準的な Qwen3_5ForCausalLM モデルの重みにコンパイルする技術的な実装です。このプロジェクトはモデルを学習させるのではなく、コンパイラを使用してマシンの状態を表す特定の重み値を計算します。ゲームが実行されると、モデルはCPUの実行トレースをトークンごとに予測し、ホストプログラムがディスプレイ、コントローラー、vblank割り込みなどの周辺機器を管理します。

このプロジェクトは、以前にCHIP-8およびRISC-Vコアでこの手法を実証したQwenputerアーキテクチャに基づいています。中心となる革新は、モデルのGated DeltaNet状態をマシンのメモリとして使用することであり、状態行列内の特定の行がレジスタ、RAM、ROMのメモリセルとして機能します。

技術アーキテクチャ

nesformerのチェックポイントは標準的なHugging Faceフォルダーであり、読み込みにカスタムモデルコードを必要としません。システムは以下の構造的な分割に依存しています。

• モデル内部 (重み + DeltaNet状態): 151個の公式オペコード、アドレッシングモード、フラグ、スタック、および2 KBのワークRAMを含む6502コア。カートリッジのPRG-ROMは、命令フェッチ用とデータ読み取り用に2回保存されます。
• ホスト内部 (host.py): PPU（スキャンラインレンダラー）、コントローラー入力処理、APUレジスタ書き込み、およびNMIタイミング。ホストはI/Oブリッジとして機能し、NMIおよびデータ読み取りトークンをモデルのストリームに注入します。

各Gated DeltaNetヘッドは128 × 128の状態行列を保持します。ゲートを開いたままにし、ワンホットキーを使用することで、システムは特定の行を上書きまたは読み戻すことができ、トランスフォーマーの再帰的な状態内に永続的なメモリ空間を効果的に作成します。

パフォーマンスと制限事項

機能はしていますが、nesformerはネイティブハードウェアよりも大幅に遅く、実際のNESの約150〜290倍の低速で動作します。リアルタイムパフォーマンスには毎秒約700,000トークンが必要ですが、現在の実装ではNumbaコンパイルエンジンを使用して単一のCPUコアで毎秒約1,650トークンを達成しています。

主な制限事項は以下の通りです。

• NROMのみサポート: 現在はiNESマッパー0（32 KB PRG-ROM）に制限されています。バンク切り替えマッパーはまだサポートされていません。
• 命令セット: 公式の6502オペコードのみが実装されており、非公式のオペコードは HALT をトリガーします。
• ハードウェアの忠実度: PPUとAPUは重み内でシミュレートされていないため、オーディオはなく、スキャンライン中間のPPU効果もキャプチャされません。

コミュニティの洞察と議論

このプロジェクトは、コンピューティング基盤としてのLLMの効率性に関する議論を巻き起こしました。コメント投稿者は、決定論的なアセンブリコードの効率性と、トランスフォーマーベースのエミュレーションの計算負荷の高い性質との間の著しい対照を指摘しました。

"私はこうしたハックが大好きですが、効率性の観点から見ると、アセンブリコードでコードゴルフをする私の脳にとっては恐ろしいものです。また、AIと比較して決定論的なプログラムがいかに効率的であるかを改めて認識させてくれます。" — jacquesm

他の人々は、LLMの能力に対するより広範な影響を指摘し、これがLLMが外部のツール呼び出しループに頼るのではなく、内部でVMやツールをホストする普遍的なコンピューティング媒体として機能できることを証明していると示唆しました。

"原則として、LLMの重みの中に小さなVMをコンパイルすることができます... 現在の「外部」ツール呼び出しを伴う低速な自己回帰トークン生成をLLMが行う代わりに、Web検索以外のすべてを、行列演算だけでLLM内部で文字通り実行できるのです。" — armcat

パフォーマンスのオーバーヘッドにもかかわらず、このプロジェクトはGated DeltaNetアーキテクチャの厳格なストレステストとして機能し、決定論的で状態を持つ実行環境としてLLMを使用する可能性を強調しています。