Qwen3.5言語モデルの重みにNES CPUをコンパイル
新しいプロジェクトでは、Nintendo Entertainment System(NES)の6502 CPUを標準的なQwen3.5モデルのパラメータに直接コンパイルし、学習なしでゲームを実行できるようにしました。
英語の原文から自動翻訳されました。
開発者のDavid Breunig氏は、Nintendo Entertainment Systemの6502 CPUを標準的なQwen3.5言語モデルの重みに直接コンパイルするプロジェクト「nesformer」を公開しました。2026年10月下旬に発表されたこの取り組みは、大規模言語モデルがデータから挙動を学習するのではなく、内部状態をマシンメモリとして扱うことでバイナリコードを実行できることを示しています。
何が起きたか
本プロジェクトは、CHIP-8やRISC-Vなどのより単純なアーキテクチャをQwen3.5-4Bにコンパイルした先行研究「Qwenputer」に基づいています。nesformerはこれをさらに発展させ、NESの中核であるMOS 6502プロセッサを対象としました。Breunig氏は、ゲームプレイ映像やアセンブリコードでモデルを訓練する代わりに、コンパイラを使用してチェックポイント内のすべての重みを計算しました。結果として得られるモデルは、Qwen3_5ForCausalLM.from_pretrainedで読み込める標準的なHugging Faceチェックポイントであり、初期化にカスタムコードは不要です。
リポジトリには、ユーザーがNES ROMを実行できるコマンドラインインターフェースが含まれています。実行されると、モデルはCPUの実行ログを表すトークンストリームを生成します。グラフィックス用のPicture Processing Unit(PPU)やコントローラー入力などの周辺ハードウェアは、別のホストプログラムが処理します。このシステムはThwaiteやFull GameなどのテストROMを正常に実行し、従来のエミュレーターと一致するフレームパーフェクトな出力を生み出します。また、ユーザーがROMファイルを提供すれば、*Super Mario Bros.*もサポートされています。
仕組み
中核となるメカニズムは、Qwen3.5モデル内のGated DeltaNetアーキテクチャに依存しています。この設定では、モデルの内部状態マトリクスがコンピュータのランダムアクセスメモリ(RAM)として機能します。128x128の状態マトリクスの各行がメモリセルとして動作します。ワンホットキーとクエリを使用することで、モデルは特定の行を上書きしてデータを書き込んだり、それらを読み返して値を取得したりできます。これにより、2 KBのワークRAM、32 KBのプログラムROM、およびCPUレジスタがすべてモデルの重みと状態内に存在できるようになります。
コンパイルプロセスでは、6502の論理ゲートとオペコードをモデルの層にマッピングします。回路は7つのGated DeltaNet層にまたがっています。最初の層はプログラムカウンターのアンカーとフラグの保存を担当し、後続の層は命令フェッチ、アドレスデコーディング、算術演算を処理します。最後の層は実行トレースにおける次のトークンを予測します。重みは回路設計から数学的に計算されるため、スパース(疎)になります。4億6,660万パラメータのうち非ゼロなのは930万のみであり、チェックポイントはわずか3.3 MBに圧縮されます。
ホストプログラムはCPU以外のすべてを管理します。vblank時に非マスク可能割り込み(NMI)のためのトークンを注入し、CPUがI/Oレジスタから読み取る際にデータを提供します。速度を管理するため、ホストはCPUがvblankを待機しているアイドルループを検出し、冗長な反復をスキップしてクロックを次のイベントまで直接進めます。この最適化によりトークン数は大幅に削減されますが、システムは依然として実ハードウェアよりも約150〜290倍遅く動作します。
主要な詳細
- モデルはQwen3.5-4Bアーキテクチャを使用し、7つのGated DeltaNet層と768の隠れサイズを持っています。
- 4億6,660万パラメータのうち非ゼロなのは930万のみで、その結果、3.3 MBの圧縮チェックポイントとなります。
- システムはNROMカートリッジ(iNES mapper 0)をサポートしていますが、MMC1やMMC3などのバンクスイッチングマッパーはまだサポートされていません。
- 実行速度は、stock transformers使用時は毎秒10トークン、numbaコンパイルエンジン使用時は毎秒1,650トークンの範囲です。
- ホストプログラムはPPUレンダリングとコントローラー入力を処理し、必要なトークンをモデルのコンテキストに注入します。
- 非公式オペコードやRAMへのジャンプは、回路が公式の6502命令のみを実装しているため、エミュレーションを停止させます。
なぜ重要なのか
AIエンジニアや研究者にとって、nesformerはトランスフォーマーの内部構造を決定論的計算のために再利用する方法の具体的な例を提供します。これは、複雑なタスクを実行するために大規模モデルが膨大なデータセットで訓練されなければならないという前提を覆します。ロジックを直接重みにコンパイルすることで、開発者は特定の挙動を保証するモデルを作成でき、より検証可能で透明性の高いAIシステムへの道を開きます。このアプローチは、モデルの「思考」部分を「状態」管理から分離し、注意機構がどのようにメモリアクセスを模倣できるかを明確にします。
エミュレーションに興味のあるソフトウェア開発者にとって、このプロジェクトは精度とパフォーマンスのトレードオフを浮き彫りにします。モデルはサポートされているゲームに対してビットパーフェクトな結果を生み出しますが、従来のエミュレーションと比較すると計算オーバーヘッドは非常に大きいです。しかし、標準的なLLMチェックポイント内で実行可能なコードを実行できる能力は、外部インタープリターや仮想マシンを必要とせずにレガシーソフトウェアロジックを最新のAIパイプラインに統合するための新たな道を切り開きます。
できること
torch>=2.6やtransformers>=5.22など、stockライブラリでチェックポイントを実行するために必要な依存関係をインストールしてください。- CLIで
--showフラグを使用すると、ターミナルが24ビットカラーをサポートしている場合、ゲームフレームを直接レンダリングできます。 checkコマンドを実行して、モデルの出力を参照CPU実装と比較し、正確性を検証してください。- Donkey KongやExcitebikeなど、独自のNROM
.nesファイルを提供して、異なるゲームとの互換性をテストしてください。 --buttonsスクリプトオプションを試して、特定のゲームシーケンスのテスト用にコントローラー入力を自動化してください。nesformer/spec.pyファイルを探索し、トークンファミリーと各CPU命令のエンコード方法を理解してください。



