Compilation d'un CPU NES dans les poids d'un modèle de langage Qwen3.5

Le développeur David Breunig a publié nesformer, un projet qui compile directement le CPU 6502 de la Nintendo Entertainment System dans les poids d'un modèle de langage Qwen3.5 standard. Publiée fin octobre 2026, cette réalisation démontre qu'un grand modèle de langage peut exécuter du code binaire en traitant son état interne comme une mémoire machine, plutôt qu'en apprenant des comportements à partir de données.

Ce qui s'est passé

Le projet s'appuie sur des travaux antérieurs appelés Qwenputer, qui avaient compilé des architectures plus simples comme CHIP-8 et RISC-V dans Qwen3.5-4B. Nesformer va plus loin en ciblant le processeur MOS 6502, le cœur de la NES. Au lieu d'entraîner le modèle sur des séquences de jeu ou du code assembleur, Breunig a utilisé un compilateur pour calculer chaque poids individuellement dans le checkpoint. Le modèle résultant est un checkpoint Hugging Face standard qui se charge avec Qwen3_5ForCausalLM.from_pretrained et ne nécessite aucun code personnalisé pour l'initialisation.

Le dépôt inclut une interface en ligne de commande permettant aux utilisateurs d'exécuter des ROMs NES. Lors de l'exécution, le modèle génère un flux de tokens représentant le journal d'exécution du CPU. Un programme hôte séparé gère le matériel périphérique, tel que l'unité de traitement graphique (PPU) pour les graphismes et les entrées du contrôleur. Le système exécute avec succès des ROMs de test comme Thwaite et Full Game, produisant une sortie parfaite image par image qui correspond aux émulateurs traditionnels. Il prend également en charge Super Mario Bros., à condition que l'utilisateur fournisse le fichier ROM.

Comment cela fonctionne

Le mécanisme central repose sur l'architecture Gated DeltaNet au sein du modèle Qwen3.5. Dans cette configuration, la matrice d'état interne du modèle fonctionne comme la mémoire vive (RAM) de l'ordinateur. Chaque ligne de la matrice d'état 128x128 agit comme une cellule mémoire. En utilisant des clés et requêtes one-hot, le modèle peut écraser des lignes spécifiques pour écrire des données ou les relire pour récupérer des valeurs. Cela permet aux 2 Ko de RAM de travail, aux 32 Ko de ROM de programme et aux registres du CPU de résider entièrement dans les poids et l'état du modèle.

Le processus de compilation mappe les portes logiques et les codes opérationnels (opcodes) du 6502 dans les couches du modèle. Le circuit couvre sept couches Gated DeltaNet. La première couche ancre le compteur de programme et stocke les indicateurs (flags), tandis que les couches suivantes gèrent la récupération des instructions, le décodage des adresses et les opérations arithmétiques. La dernière couche prédit le prochain token dans la trace d'exécution. Parce que les poids sont calculés mathématiquement à partir de la conception du circuit, ils sont épars : sur 466,6 millions de paramètres, seuls 9,3 millions sont non nuls, ce qui permet au checkpoint de se compresser à seulement 3,3 Mo.

Le programme hôte gère tout ce qui se trouve hors du CPU. Il injecte des tokens pour les interruptions non masquables (NMI) lors du vblank et fournit les données d'entrée lorsque le CPU lit depuis les registres d'E/S. Pour gérer la vitesse, l'hôte détecte les boucles d'inactivité où le CPU attend le vblank et saute les itérations redondantes, avançant l'horloge directement jusqu'à l'événement suivant. Cette optimisation réduit considérablement le nombre de tokens, bien que le système tourne encore environ 150 à 290 fois plus lentement que le matériel réel.

Détails clés

• Le modèle utilise l'architecture Qwen3.5-4B avec 7 couches Gated DeltaNet et une taille cachée de 768.
• Seuls 9,3 millions des 466,6 millions de paramètres sont non nuls, résultant en un checkpoint compressé de 3,3 Mo.
• Le système prend en charge les cartouches NROM (mapper iNES 0) mais ne supporte pas encore les mappers à commutation de banque comme MMC1 ou MMC3.
• La vitesse d'exécution varie de 10 tokens par seconde avec transformers standard à 1 650 tokens par seconde avec un moteur compilé via numba.
• Le programme hôte gère le rendu PPU et les entrées du contrôleur, injectant les tokens nécessaires dans le contexte du modèle.
• Les opcodes non officiels et les sauts vers la RAM provoquent l'arrêt de l'émulation, car le circuit n'implémente que les instructions officielles du 6502.

Pourquoi c'est important

Pour les ingénieurs et chercheurs en IA, nesformer offre un exemple concret de la manière dont les internes des transformeurs peuvent être réutilisés pour le calcul déterministe. Il remet en question l'hypothèse selon laquelle les grands modèles doivent être entraînés sur d'immenses jeux de données pour effectuer des tâches complexes. En compilant la logique directement dans les poids, les développeurs peuvent créer des modèles garantissant des comportements spécifiques, ouvrant la voie à des systèmes d'IA plus vérifiables et transparents. Cette approche sépare la partie « réflexion » du modèle de la gestion de l'« état », clarifiant comment les mécanismes d'attention peuvent imiter l'accès mémoire.

Pour les développeurs logiciels intéressés par l'émulation, ce projet met en évidence les compromis entre précision et performance. Bien que le modèle produise des résultats bit-perfect pour les jeux pris en charge, la surcharge computationnelle est immense comparée à l'émulation traditionnelle. Cependant, la capacité d'exécuter du code exécutable à l'intérieur d'un checkpoint LLM standard ouvre de nouvelles avenues pour intégrer la logique de logiciels hérités dans les pipelines d'IA modernes sans nécessiter d'interpréteurs externes ni de machines virtuelles.

Ce que vous pouvez faire

• Installez les dépendances requises, y compris torch>=2.6 et transformers>=5.22, pour exécuter le checkpoint avec les bibliothèques standard.
• Utilisez le flag --show dans la CLI pour rendre les images de jeu directement dans votre terminal si celui-ci prend en charge la couleur 24 bits.
• Exécutez la commande check pour comparer la sortie du modèle avec une implémentation CPU de référence et vérifier la correction.
• Fournissez vos propres fichiers .nes NROM, tels que Donkey Kong ou Excitebike, pour tester la compatibilité avec différents jeux.
• Expérimentez avec l'option de script --buttons pour automatiser les entrées du contrôleur afin de tester des séquences de jeu spécifiques.
• Explorez le fichier nesformer/spec.py pour comprendre les familles de tokens et la façon dont chaque instruction CPU est encodée.