Tech Teardown 036 | Nesformer : une NES dans les poids de Qwen

Tech Teardown : Publication de sujets d’actualité × Jugement technique × Conseils pratiques.

---

Contexte/Phénomène

Le 30 octobre 2026, un projet appelé Nesformer a été publié sur GitHub. Sa présentation était très directe : « Un CPU de NES compilé dans les poids d’un modèle Qwen3.5 standard. » En d’autres termes, l’auteur n’a pas entraîné un AI pour jeux, ni écrit de simulateur traditionnel, mais a intégré le CPU du système d’arcade Nintendo Entertainment System dans les poids de Qwen3.5. Le modèle est entièrement non affiné, tous les paramètres étant calculés directement par le compilateur.

Cet événement a rapidement attiré l’attention du monde technique, car il a poussé la question de savoir si « les poids d’un grand modèle LLM peuvent être considérés comme un ordinateur » à l’extrême. Autrefois, nous considérions les LLM comme des outils de conversation, et les poids comme une série de règles statistiques entraînées. La méthode de Nesformer était en quelque sorte une déclaration : les poids ne sont pas seulement des conteneurs statistiques de langage, ils peuvent également être directement codés dans un CPU complet d’ordinateur de jeux.

Son origine réside dans Qwenputer de Divyansh Agrawal. Ce dernier avait déjà intégré les CPU CHIP-8 et RISC-V dans Qwen3.5-4B, prouvant la faisabilité de cette approche. Nesformer a remplacé l’objet par un NES plus complexe, c’est-à-dire le jeu d’arcade rouge et blanc populaires dans le monde entier dans les années 80. De CHIP-8 à RISC-V, puis au NES, la complexité augmente progressivement, et la signification de la vérification de concept devient de plus en plus évidente.

Le hardware du NES n’est pas complexe : un processeur Ricoh 2A03 à 1,79 MHz (compatible avec MOS 6502), 2 KB de mémoire, le PPU est responsable de l’affichage graphique, et l’APU est responsable du son. Mais pour intégrer un tel système dans les poids d’un LLM, il est nécessaire de créer une correspondance complète entre la famille d’instructions du CPU, l’adressage de la mémoire et le mapping des I/O. L’auteur dbreunig a choisi le NES parce qu’il dispose de jeux classiques pour illustrer son concept, mais aussi parce qu’il est suffisamment complexe pour tester réellement les limites de l’idée que « les poids sont un ordinateur ».

Ce projet, publié sur Hacker News sous forme de Show HN, a rapidement suscité de nombreux discussions. Certains ont été émerveillés par son originalité, d’autres ont remis en question sa valeur pratique. Mais quelles que soient les positions, la plupart des gens sont d’accord : au moins sur le plan technique, il a transformé une idée qui semblait de science-fiction en code fonctionnel.

Principe technique/Architecture

L’idée fondamentale de Nesformer est d’intégrer l’CPU, la RAM et la ROM dans les états du grand modèle. Le modèle de base choisi est Qwen3.5-4B, dont la structure a été considérablement réduite : seules 7 couches Gated DeltaNet sont conservées, plus une couche d’attention vide pour répondre aux exigences de cache de HuggingFace. Le nombre total de paramètres est de 466,6 M bf16, mais seulement 9,3 M de paramètres non nuls, et les poids comprimés ne mesurent que 3,3 MB.

Le truc clé réside dans la matrice d’état de Gated DeltaNet. L’auteur considère chaque ligne de la matrice d’état comme une unité de mémoire adressable, en définissant gate=1 pour éviter toute dégradation et write strength=1 pour assurer une couverture complète. Ensuite, des clés one-hot permettent une localisation précise. Ainsi, chaque écriture couvre précisément une ligne, simulant le fonctionnement des registres CPU, de la RAM et de la ROM.

Plus précisément, les poids du modèle编码entrent tous les 151 opcodes officiels du CPU NES 6502, tous les modes d’adressage, les bits de marque, la pile, ainsi que les entrées BRK/NMI. 2 KB de RAM de travail, 32 KB de PRG-ROM (stockés en deux copies, l’une pour lire les instructions, l’autre pour lire les données), et 256 octets d’OAM DMA sont intégrés dans le modèle. Les écritures des registres PPU au niveau de la rendu, des entrées du contrôleur, des registres APU et l’injection de NMI vblank sont gérées par une host.py externe.

En d’autres termes, Nesformer divise la « exécution de jeux NES » en deux parties : l’intérieur du modèle est responsable de l’exécution CPU et de l’actualisation des états de la mémoire, tandis que l’extérieur du modèle traduit le flux de tokens en pixels d’écran et en entrées utilisateur. Cette division permet aux poids de remplir réellement les tâches de calcul, tandis que l’host se charge simplement de visualiser les résultats.

Contrairement aux simulateurs traditionnels qui interprètent les opcodes par itération, Nesformer transforme l’ensemble du mécanisme d’état CPU en une multiplication matricielle. Chaque propagation vers l’avant correspond à une période de CPU, et le flux des tokens correspond au transfert des données entre les registres et la mémoire. Les états récurrents de DeltaNet sont naturellement adaptés pour exprimer des systèmes temporels discrets tels que « état précédent + entrée actuelle → état suivant », c’est aussi pourquoi il peut intégrer le CPU plutôt que de l’apprendre.

L’ampleur du vocabulaire est également notable : 263,808 tokens. Un tel vocabulaire n’est pas destiné à la diversité linguistique, mais à encoder les adresses CPU, les bus de données et les signaux de contrôle en tokens discrets. En entrant un token, le modèle peut déterminer la prochaine mise à jour d’état en fonction de l’état actuel et des instructions. Cette conception crée une correspondance directe entre le processus de propagation vers l’avant du modèle et les périodes de cloche du CPU.

Données clés/Cas pratiques

En termes de performance, Nesformer est encore loin d’être pratique. Sa vitesse est environ 150 à 290 fois plus lente que celle d’un véritable NES. Avec la compilation la plus rapide par numba et l’optimisation des blocs de saut zéro, un noyau peut atteindre environ 1,650 tokens par seconde ; tandis que le chemin des transformateurs stock ne permet que 10 tokens par seconde. Un véritable NES nécessite environ 700,000 tokens par seconde pour fonctionner en full frame, la différence est évidente.

En ce qui concerne la vérification des données, l’auteur a testé plusieurs jeux NROM mapper 0, notamment Super Mario Bros. et Donkey Kong. Des tests de cohérence plus rigoureux ont montré que le Thwaite 600 a utilisé 1,916,527 tokens pour 10,0 secondes de simulation, dont 300 frames sont cohérents avec la simulation traditionnelle du simulateur 6502 ; Doug Fraker Full Game 420 a utilisé 2,645,885 tokens, également cohérents à chaque frame ; le kit de test de cohérence nestest a atteint l’état HALT après 4,586 tokens. Ces données montrent que le modèle reproduit effectivement le comportement du CPU 6502 au niveau logique.

Cependant, tous ces données proviennent du README, je n’ai pas effectué de tests locaux, et la fréquence de fonctionnement dépend également du matériel et de la version de numba. Si les lecteurs souhaitent reproduire le système, ils doivent d’abord télécharger environ 1GB des poids bf16 décompressés et vérifier les poids avec shasum/SHA-256SUMS. L’environnement de construction nécessite Python 3.11 ou supérieur, ainsi que numpy, scipy, numba et pillow. La commande d’exécution est python -m nesformer run ROM, avec des paramètres optionnels tels que --frames, --buttons et --show.

Du point de vue de la compression, la distribution des paramètres de Nesformer est également intéressante. Sur 466,6M de paramètres bf16, seulement 9,3M sont non nuls, avec une rareté supérieure à 98 %. Après compression, le poids entier ne mesure que 3,3 MB, plus petit que beaucoup de ROM NES eux-mêmes. Cela montre que les poids générés par la compilation peuvent exprimer des calculs déterministes complexes avec très peu d’informations efficaces, remettant en question l’idée que plus les paramètres sont grands, mieux c’est, au moins sur le plan théorique.

Impact/Signification

La plus grande signification de Nesformer est qu’il transforme la métaphore « les poids, c’est le calculateur » en un fait de conception opérationnel. Autrefois, on discutait de savoir si les LLM pouvaient effectuer des calculs arithmétiques ou exécuter des programmes, mais cela se limitait généralement au niveau des prompts. Nesformer prouve que, tant que la conception de l’architecture est correcte, l’espace de states d’un grand modèle peut être directement codé en structures de calcul et de stockage universelles, sans nécessiter de training, et tout est généré par le compilateur.

Cela offre deux implications pour la recherche sur les architectures de modèles. Premièrement, cela vérifie la programmabilité de la matrice d’états Gated DeltaNet. En contrôlant bien la distribution des gates, de la force d’écriture et des clés, on peut transformer les états en mémoire adressable. Deuxièmement, cela suggère une nouvelle approche de compression : sur 466,6M de paramètres bf16, seulement 9,3M sont non nuls, et après compression, le poids ne mesure que 3,3 MB, ce qui indique que la rareté et la génération compilée peuvent être plus adaptées pour certaines tâches spécifiques que le training end-to-end.

Du point de vue plus macroscopique, Nesformer et Qwenputer ensemble ont porté le sujet « exécuter des machines virtuelles dans les poids d’un LLM » à un niveau de complexité plus élevé. CHIP-8 et RISC-V ressemblent davantage à des démonstrations didactiques, tandis que NES implique la coordination entre CPU, mémoire, I/O et rendu, constituant un système plus complet. À l’avenir, une approche similaire pourrait être utilisée pour intégrer des modules de calcul déterministe plus complexes dans les modèles.

Ce projet brouille également les frontières entre « modèles » et « programmes ». Dans l’ingénierie logicielle traditionnelle, les programmes et la mémoire sont séparés ; Nesformer les combine dans le même groupe de poids. Si cette tendance se poursuit, il pourrait y avoir à l’avenir des applications où un LLM contiendrait en même temps la capacité de compréhension du langage, la capacité de raisonnement et un moteur de règles commerciales fixes, nécessitant une seule fichier pour le déploiement.

Pour le déploiement côté client, ces poids compilés à haute densité sont également attrayants. Si à l’avenir les téléphones ou les appareils IoT doivent exécuter un stack de protocole ou un moteur d’état très certain, compiler cela dans les poids du modèle pourrait être plus pratique que de maintenir séparément un moteur d’exécution. Bien sûr, il faut encore trouver un équilibre entre l’efficacité du raisonnement et la manière dont le système peut être maintenu.

Controverses/Risques

Premièrement, il y a le problème de la performance. Elle est 150 à 290 fois plus lente que la NES réelle, ce qui signifie qu’elle ne peut actuellement servir qu’à des tests de concept, restant loin de l’expérience de jeu réelle. Même si à l’avenir, grâce à la quantification, aux optimisations de compilation ou à l’accélération par hardware spécialisé, il est possible d’augmenter le débit des tokens de quelques milliers à plus de centaines de milliers sur une machine réelle, cela nécessitera encore une amélioration d’ordre numérique.

Deuxièmement, il y a la maintenance et l’évolutivité. Compiler le CPU dans les poids signifie que toute correction de bogue ou extension de fonctionnalités doit être exécutée à nouveau par le compilateur, contrairement aux simulateurs traditionnels qui modifient quelques lignes de code. Pour des jeux plus complexes comme MMC3 et MMC5, la taille des poids pourrait augmenter considérablement, et il reste incertain si le solution actuelle peut évoluer.

Troisièmement, il y a les limites de l’évaluation. Toutes les données de performance et les tests de cohérence mentionnés dans le README du repository ont été effectués par l’auteur lui-même, sans aucune réplication par un tiers indépendant. De plus, il ne peut fonctionner que sur des jeux avec un mapper 0, ce qui limite sa portée. Les lecteurs doivent mentionner « auto-déclaration de l’auteur » lorsqu’ils citent ces données.

Enfin, il y a une question plus profonde : compilera-t-on vraiment des calculs certains dans les poids des LLM pour obtenir des avantages ingénieriels ? Si c’est juste pour la compatibilité, les simulateurs traditionnels sont clairement plus rapides et plus faciles à débuguer. La valeur de Nesformer réside davantage dans l’exploration des limites que dans la remplacement des solutions existantes.

De plus, cette méthode de compilation des calculs certains dans les poids des réseaux neuronaux soulève des préoccupations concernant l’interprétabilité. Chaque ligne de code d’un simulateur traditionnel correspond à un comportement hardware clair, tandis que les calculs dans les poids sont hautement distribués. Une fois qu’un problème survient dans le système, la localisation et la correction seront beaucoup plus difficiles que dans les logiciels traditionnels.

Conclusion/Projet futur

Nesformer est une présentation technique de haute qualité. Il ne modélise aucun poids, mais compile le CPU d’une NES dans la structure Gated DeltaNet de 7 couches de Qwen3.5, reproduisant ainsi le comportement du CPU 6502, de la RAM, de la ROM et de l’OAM avec des paramètres dispersés. Il peut exécuter Super Mario Bros. et Donkey Kong, mais à deux ordres de grandeur de la vitesse d’une machine réelle.

À court terme, ce projet attirera l’attention dans trois directions : les architectures de modèles, les compilateurs et la simulation de jeux retro. Il fournit un étalon reproductible, permettant aux chercheurs de tester directement les limites du concept « matrice d’état comme mémoire ». À moyen terme, si ces méthodes de compilation peuvent s’étendre à des mappers plus complexes et à des voies de raisonnement plus efficaces, il est possible de réaliser des poids de modèle qui portent simultanément plusieurs fonctions certaines sur des appareils côté client. À long terme, cela nous rappelle que l’espace des poids des grands modèles est bien plus vaste que celui des conversations, des résumés ou des raisonnements ; il peut être programmé avec n’importe quelle structure de calcul, tant que nous trouvons la bonne méthode de compilation.

Un autre domaine de recherche intéressant à l’avenir est le « poids mixte » : la partie de compréhension et de raisonnement du langage reste entraînée traditionnellement, tandis que les modules tels que les règles déterministes, l’analyse des protocoles et les machines d’état sont intégrés par compilation. Cela permet de préserver la flexibilité des réseaux neuronaux tout en obtenant un comportement déterministe vérifiable. Nesformer a déjà prouvé que cette approche est viable, il reste à voir si elle peut être développée d’un projet amusant vers une application industrielle réelle. Un autre problème à résoudre est la généralité du compilateur : il effectue actuellement de nombreuses mappages manuels pour NES, mais peut-il être abstraite en un outil plus général « permettant de compiler n’importe quel mécanisme à états finis dans le poids », ce qui déterminera la valeur finale de cette direction.

Ce projet utilise la licence MIT, et le code ainsi que les instructions de construction sont publiés. Si vous êtes intéressé par cette approche où « le poids est le ordinateur », vous pouvez simplement cloner le répertoire et exécuter le projet selon les étapes indiquées dans le README. Même si vous ne pouvez pas exécuter le jeu à pleine vitesse, regarder comment il reproduit un NES avec 9,3 millions de paramètres non nuls est suffisamment intéressant pour être exploré.

Signé Yongliang