L’émulateur NES de Qwen compile la logique CPU de Nintendo dans environ 1 Go de poids

Le projet d’émulateur NES de Qwen, nesformer, intègre un processeur Nintendo dans 933 Mo de poids de modèle compilés, selon son dépôt. Ses démonstrations incluent Super Mario Bros., mais un logiciel externe continue de dessiner l’écran et de gérer les contrôleurs. Cette distinction est importante : il s’agit d’une expérience d’informatique programmée au sein d’une architecture de modèle, et non d’un chatbot ayant appris les jeux Nintendo.

Le développeur Drew Breunig a présenté le projet sur Hacker News, où le titre décrivait une Nintendo fonctionnelle dans environ 1 Go de poids Qwen. Le dépôt avance une affirmation plus restreinte, mais plus intéressante. Un compilateur construit la logique du processeur, et des jetons générés font progresser son exécution. Les résultats publiés nécessitent une reproduction indépendante, mais le projet fournit du code et des chemins de vérification explicites.

Le point de référence est Qwenputer, l’expérience antérieure de Divyansh Agrawal qui intègre un processeur dans l’architecture de Qwen. Les deux projets posent une question aux développeurs qui construisent des systèmes d’IA : quelles opérations doivent relever du calcul du modèle, et lesquelles doivent rester dans les logiciels conventionnels ? Nesformer rend cette question visible à travers des jeux familiers, tout en documentant d’importantes limites de vitesse et de compatibilité.

L’émulateur NES de Qwen exécute un CPU, tandis qu’un hôte complète la console

L’affirmation centrale de nesformer concerne le CPU Nintendo et sa mémoire, plutôt que l’ensemble des composants d’une console complète. Cette frontière définit à la fois la réussite et les limites du projet.

Le projet indique placer le cœur de processeur 6502 de la NES dans un point de contrôle de modèle compatible avec Qwen, une collection sauvegardée de paramètres de modèle. Il place également la mémoire de travail et les données de programme des cartouches dans l’état interne évolutif du modèle.

La distinction entre paramètres et état importe. Les paramètres définissent le comportement de la machine ; l’état conserve les informations qui changent pendant l’exécution du jeu. Qualifier l’ensemble de « poids » condense ces responsabilités différentes dans un titre accrocheur.

Selon la conception du CPU compilé, le modèle génère des jetons, des symboles de sortie discrets, qui représentent le registre d’exécution du processeur. Ces symboles décrivent des opérations plutôt qu’un texte conversationnel ordinaire.

Un programme hôte fournit le comportement environnant de la console. Il affiche les graphismes, traite les entrées du contrôleur et fournit les événements associés au rythme de l’affichage. Les entrées et sorties franchissent cette frontière via le registre d’exécution.

Cette disposition confère au modèle un rôle important sans placer l’ensemble du système Nintendo en son sein. Un écran en mouvement dissimulerait à lui seul cette répartition. La description de l’architecture du dépôt rend cette répartition vérifiable.

L’implémentation du processeur couvre les 151 opcodes officiels, les instructions encodées qui indiquent au processeur l’opération à effectuer. Elle inclut l’arithmétique, les branchements, les indicateurs du processeur et le comportement de la pile.

L’organisation de la mémoire documentée comprend 2 Ko de RAM de travail, une mémoire que le jeu en cours d’exécution peut modifier. Elle comprend également 32 Ko de ROM de programme de cartouche, les données de programme stockées.

Le programme de la cartouche est chargé dans l’état au début de l’exécution. Le projet affirme donc que les jeux pris en charge peuvent partager les mêmes poids compilés sans reconstruire le processeur pour chaque titre.

Il s’agit d’une différence importante par rapport à la préparation d’une animation distincte pour chaque démonstration. L’artefact visé est une implémentation réutilisable de processeur avec une plage de compatibilité restreinte.

L’exemple publié de Super Mario Bros. fournit une scène reconnaissable. Les jeux de test inclus constituent un point de départ plus utile pour la vérification, car leurs fichiers et informations de licence accompagnent le projet.

Les actions du contrôleur peuvent suivre un script précisant à quel moment appuyer sur les boutons. La séquence Mario documentée lance le jeu, se déplace vers la droite et saute à intervalles programmés.

Ce n’est pas la preuve qu’un agent IA a appris à jouer à Mario. C’est l’affirmation qu’une logique de processeur compilée peut exécuter les instructions du jeu tout en recevant des entrées prescrites.

Le rôle de Nintendo est ici celui de cible matérielle et de référence de jeu. Le dépôt présente une expérience indépendante, et non un produit Nintendo ou un partenariat annoncé avec Qwen.

La publication modifie donc ce que les développeurs peuvent inspecter : une implémentation publique relie paramètres de modèle, comportement du processeur et sortie de jeu visible. Son importance repose sur cette connexion vérifiable.

La logique compilée change ce que la démonstration dit de l’IA

Le mécanisme important est une construction délibérée : les poids compilés de nesformer encodent le comportement du processeur sans entraîner un modèle à le découvrir.

L’entraînement ajuste normalement les paramètres à l’aide d’exemples et d’un processus d’optimisation. La compilation traduit une conception spécifiée dans une autre représentation exécutable. Le dépôt de nesformer indique que son compilateur calcule directement les paramètres.

Cela distingue le projet d’une demande faite à un chatbot préentraîné d’imiter un processeur. Le compilateur fournit les règles, et l’architecture du modèle fournit les mécanismes mathématiques qui les exécutent.

Le résultat ne doit pas être interprété comme la preuve qu’un modèle conversationnel Qwen comprend secrètement le matériel Nintendo. La démonstration n’établit pas non plus que la génération de langage ordinaire est devenue un substitut exact au logiciel.

Elle explore plutôt la possibilité que les mêmes briques architecturales prennent en charge une machine numérique délibérément spécifiée. Il s’agit d’une question de représentation et d’exécution, dont les implications plus larges nécessitent encore des expériences.

Le composant clé est Gated DeltaNet, un mécanisme de modèle qui maintient une matrice de mémoire interne évolutive. Nesformer utilise cet état pour stocker des informations machine à travers des jetons générés successifs.

Sa conception affecte les emplacements mémoire à des lignes de ces matrices. Des lectures et mises à jour soigneusement construites permettent aux registres du processeur, à la mémoire de travail et aux données de cartouche d’occuper ces emplacements.

Un registre, un petit emplacement de stockage utilisé directement par le processeur, doit conserver une valeur exacte jusqu’à ce qu’une instruction la modifie. Un rappel approximatif corromprait l’exécution.

Le compilateur transcrit également le décodage des instructions et l’arithmétique dans les couches du modèle. Un passage avant, le calcul qui produit la sortie suivante, fait progresser la machine encodée dans son registre d’exécution.

Le projet indique que la plupart des instructions nécessitent un seul jeton. Certaines requièrent des registres plus longs, et la moyenne documentée pour le code de jeu varie de 1,1 à 1,3 jeton par instruction.

Cette relation relie une mesure familière de performance des modèles à une charge de travail informatique conventionnelle. Générer des jetons plus rapidement importe, car la séquence de jetons porte l’exécution du processeur, au lieu de simplement la décrire après coup.

Qwenputer a fourni la base technique immédiate. Le récit d’Agrawal sur l’informatique au sein du modèle, publié le 22 octobre 2026, décrit la compilation de la logique d’un processeur et l’utilisation de l’état interne comme mémoire.

La comparaison entre Qwenputer et nesformer commence donc par une continuité. Nesformer réutilise le compilateur et la technique de mémoire antérieurs, puis cible le processeur de la NES et le relie à un comportement hôte propre à la console.

Leurs conceptions environnantes diffèrent. Agrawal décrit la conservation des poids linguistiques originaux de Qwen tout en ajoutant une mécanique de calcul. Nesformer publie un point de contrôle plus petit, centré sur le processeur, avec une organisation de couches différente.

Cette distinction évite une conclusion trompeuse sur la taille. Le téléchargement de nesformer n’établit pas qu’un modèle conversationnel Qwen complet, plus une Nintendo complète, tient dans l’empreinte annoncée.

Il établit une proposition plus circonscrite : certains composants architecturaux de Qwen peuvent héberger une conception de processeur compilée. La question de savoir si cela deviendra utile dans des produits d’IA généralistes reste ouverte sur le plan de l’ingénierie.

L’exécution conventionnelle reste la référence en matière d’utilité

Nesformer crée une alternative architecturale, mais ses performances publiées font du logiciel conventionnel la norme pratique pour exécuter des jeux.

La comparaison immédiate oppose l’exécution d’instructions dans du code d’émulateur ordinaire à l’expression de leur exécution par des opérations de modèle. Un résultat visible ne permet pas de trancher quelle voie est utile.

Un émulateur, un logiciel qui reproduit le comportement d’une autre machine, a déjà une mission claire ici. Il doit exécuter avec précision des programmes compatibles et fournir leurs sorties à une vitesse acceptable.

Nesformer ajoute un autre objectif : exécuter le processeur via une représentation de paramètres compatible avec le modèle. Cet objectif explique l’expérience, même lorsque l’exécution conventionnelle reste plus efficace.

Le dépôt indique environ 1 650 jetons par seconde pour son moteur optimisé par défaut sur un seul cœur de processeur. Il indique environ 210 pour son moteur numérique plus simple.

Son chemin Transformers standard atteindrait environ 10 jetons par seconde. Transformers est la bibliothèque logicielle d’exécution de modèles utilisée pour charger et exécuter le point de contrôle publié.

Ces chiffres décrivent différents chemins d’exécution. Ils ne doivent pas être fusionnés en une seule affirmation sur les performances d’un modèle standard, ni être traités comme une comparaison contrôlée sur du matériel non précisé.

Le moteur par défaut ignore les blocs dont les paramètres sont nuls. Cela compte, car la plupart des paramètres du point de contrôle sont nuls, ce qui rend sa structure particulièrement adaptée à une exécution spécialisée.

Le dépôt décrit également l’omission de boucles d’inactivité répétées lorsqu’elles n’effectuent aucune écriture mémoire ou entrée-sortie. Ces boucles attendent le prochain événement d’affichage pertinent.

Cette optimisation réduit le travail inutile, mais elle doit figurer dans toute explication des chiffres de vitesse. L’hôte aide à éviter de répéter des calculs qui ne modifieraient pas le comportement visible.

Même avec ces optimisations, le projet indique une exécution 150 à 290 fois plus lente que la console d’origine. Son estimation pour 600 images est d’environ 25 minutes.

Ces 600 images représentent 10 secondes de temps NES dans l’exemple documenté. La démonstration concerne donc une exécution à terme, et non un remplacement réactif pour jouer normalement.

Cela fait peser la charge pratique sur les partisans de l’informatique au sein des poids de modèle. Ils doivent identifier des bénéfices qui justifient le travail d’exécution supplémentaire et la complexité d’intégration.

Les bénéfices potentiels nécessitent des mesures plutôt que des suppositions. Conserver une opération dans le calcul d’un modèle est une propriété architecturale ; cela n’améliore pas automatiquement la latence, la fiabilité ou l’utilisabilité.

La pression immédiate s’exerce sur les affirmations de recherche et la conception des évaluations, plutôt que sur les entreprises d’émulateurs existantes. Nesformer ne fournit aucun élément indiquant que les émulateurs conventionnels risquent d’être remplacés.

Un développeur envisageant une mécanique similaire devrait comparer les parcours complets. Le chargement de l’état, l’avancement de l’exécution, la gestion des entrées et la lecture des sorties influencent tous le résultat perçu par l’utilisateur.

La comparaison entre Qwenputer et nesformer renforce ce besoin de précision. Des cibles de processeur, composants environnants et moteurs d’exécution différents empêchent les classements simples fondés sur la taille du point de contrôle ou le débit mis en avant.

Pour l’instant, la voie conventionnelle fournit à la fois l’alternative pratique et le comportement de référence. Nesformer mérite l’attention en rendant une autre voie inspectable, sans établir qu’elle devrait remplacer l’existante.

Les tests sont plus instructifs que l’animation de Mario

L’élément de preuve le plus solide est la comparaison par couches du projet avec le comportement de référence, bien que les résultats publiés restent rapportés par les auteurs.

Une animation de jeu établit qu’un élément reconnaissable est apparu. Elle ne révèle pas si les instructions se sont exécutées correctement, si un système de référence a fourni des corrections, ni quel logiciel a produit chaque image.

La documentation de Nesformer distingue ces questions. Elle décrit des vérifications pour le processeur de référence, le circuit compilé, le checkpoint sauvegardé et des séquences d’exécution plus longues.

La distinction commence avec le CPU de référence, l’implémentation conventionnelle utilisée comme résultat attendu. Une référence défaillante pourrait rendre des sorties correspondantes moins significatives.

Le dépôt indique avoir comparé cette référence à nestest, un test de conformité de processeur comportant des enregistrements d’exécution attendus. Il affirme que la référence correspond à 3 348 instructions dans le périmètre pris en charge.

Il signale également une comparaison avec py65, un autre émulateur de processeur, sur 5,7 millions d’instructions de code de jeu. Cela fournit une vérification supplémentaire de l’implémentation de référence.

Le circuit compilé fait ensuite l’objet de ses propres comparaisons. La documentation signale une concordance sur nestest et 283 610 positions issues des séquences de démarrage de deux jeux.

Ces résultats concernent le comportement du circuit spécifié. Ils n’établissent pas à eux seuls qu’un modèle sauvegardé produit des résultats identiques dans tous les moteurs d’exécution.

Le dépôt rapporte donc une vérification séparée de stock Transformers couvrant 2 651 positions de nestest et Full Game. Il ne signale aucune divergence dans cet échantillon.

Le vérificateur de checkpoint stock montre comment cette comparaison fonctionne. Il charge le modèle, initialise l’état de la machine et vérifie les sorties prédites par rapport à une séquence de référence fournie.

Cette méthode utilise le teacher forcing, qui fournit la sortie précédente connue à chaque étape de comparaison. Elle teste des prédictions locales sans établir une exécution autonome ininterrompue d’une longueur équivalente.

L’exécution en mode libre alimente au contraire le système avec ses propres sorties. Une erreur peut modifier l’état ultérieur ; une concordance sur une séquence prolongée répond donc à une question de vérification différente.

Le projet rapporte une exécution libre de Thwaite couvrant 1 916 527 tokens et 600 images. Il indique que les 300 images sauvegardées correspondent toutes à la sortie de référence.

Pour Full Game, il rapporte 2 645 885 tokens et 420 images. Sa documentation indique que les 210 images sauvegardées correspondent toutes.

Ces décomptes constituent des affirmations de preuve spécifiques, plutôt qu’une garantie universelle. Ils concernent des jeux, des séquences d’entrée, des chemins d’exécution et des durées particuliers.

Les tests de vérification du processeur exposent des comparaisons automatisées pour la référence, le circuit, les moteurs d’exécution et l’optimisation de boucle inactive. Leur disponibilité permet une reproduction ciblée.

Toutefois, lire des tests diffère de les exécuter. Cette analyse a examiné l’implémentation et la documentation publiées ; elle n’a pas exécuté indépendamment le checkpoint ni reproduit les performances rapportées.

Cette distinction doit survivre aux reformulations. Le projet fournit davantage d’éléments que ne le ferait une affirmation non étayée sur les réseaux sociaux, mais du code public et une concordance rapportée par les auteurs ne valent pas une validation indépendante.

Pour l’émulateur NES de Qwen, la prochaine avancée crédible est une reproduction plus large avec des moteurs d’exécution clairement identifiés. Une animation plus grande apporterait moins de confiance qu’une trace de concordance documentée.

Le titre de 1 Go masque à la fois le stockage creux et le matériel absent

La taille du checkpoint est réelle en tant qu’empreinte de fichier rapportée, mais elle ne décrit ni une console complète ni la mémoire totale à l’exécution.

Le dépôt répertorie 466,6 millions de paramètres stockés en bfloat16, un format numérique utilisant 16 bits par valeur. Il donne l’empreinte résultante des paramètres comme étant de 933 Mo.

Seuls 9,3 millions de paramètres sont non nuls, selon la documentation. Le projet indique que cette régularité permet de compresser les poids dans une archive de 3,3 Mo.

Il s’agit de quantités différentes. Le téléchargement d’une archive, un fichier de paramètres décompressé et la mémoire consommée par un processus en cours d’exécution répondent à des questions opérationnelles différentes.

La description approximative de 1 Go dans l’article concerne les poids décompressés. Elle ne devrait pas devenir une affirmation selon laquelle l’application complète ne nécessite que cette quantité de mémoire.

La structure creuse modifie également l’interprétation des performances. Un moteur spécialisé qui évite les blocs nuls effectue un travail différent d’une implémentation qui traite la disposition complète des paramètres.

Cela n’invalide pas l’affirmation relative au checkpoint. Cela signifie que la compatibilité, le stockage et l’efficacité d’exécution nécessitent des mesures distinctes plutôt qu’un seul titre condensé.

La frontière matérielle impose une autre réserve. L’unité de traitement d’image, le composant NES responsable du comportement graphique, reste dans le logiciel hôte.

L’unité de traitement audio, le matériel sonore de la console, est également hors des poids. Le dépôt indique que l’implémentation actuelle ne produit aucun son.

La fidélité graphique présente également des limites. L’hôte rend des scanlines, des lignes horizontales de l’image, et ne reproduit pas les effets se produisant en cours de ligne.

La documentation décrit aussi un comportement approximatif pour certaines conditions d’état des sprites. Un sprite est un élément d’image contrôlé séparément, utilisé pour les personnages et d’autres objets mobiles.

La prise en charge des cartouches est limitée à NROM, une disposition de carte simple sans commutation de banque de programme. La commutation de banque modifie la portion d’un programme de cartouche plus vaste à laquelle le processeur peut accéder.

La conception documentée de Nesformer utilise une table de programme fixe. Prendre en charge des cartouches plus complexes exigerait une logique supplémentaire d’état et de sélection d’adresse, plutôt qu’un simple nouveau titre dans une liste de compatibilité.

Les restrictions d’exécution vont au-delà du format de cartouche. Les instructions non officielles non prises en charge arrêtent le système, et le code doit s’exécuter depuis la mémoire de cartouche plutôt que depuis la RAM de travail.

Le projet répertorie également des comportements d’interruption manquants, des signaux qui amènent le processeur à répondre à des événements matériels. Certains événements pris en charge fonctionnent, mais la couverture documentée reste incomplète.

Ces limites façonnent le sens de « fonctionnel ». Un système peut exécuter correctement certains jeux dans un périmètre défini tout en restant inadapté à une bibliothèque plus vaste.

Elles empêchent également de généraliser les tests rapportés à l’ensemble des logiciels Nintendo. La concordance sur les instructions prises en charge ne comble pas les comportements matériels que l’implémentation omet explicitement.

Les poids compilés de nesformer sont donc mieux évalués comme un artefact de processeur connecté à une implémentation partielle de console. Cette description préserve la contribution inhabituelle du projet sans étendre ses affirmations de compatibilité.

Pour les développeurs, la question sceptique utile est concrète : quel comportement observé découle de la logique de processeur compilée, et lequel découle des hypothèses de l’hôte ? Le dépôt fournit aux examinateurs une première carte.

La reproduction indépendante, une compatibilité plus large et la vitesse du système complet viennent ensuite

Les prochaines preuves utiles devraient étendre la confiance, la couverture et la praticité mesurée, dans cet ordre. Ces signaux sont plus instructifs qu’un nouveau cycle d’attention.

Premièrement, surveillez une reproduction indépendante des comparaisons de traces publiées. Un rapport crédible devrait identifier le checkpoint, les entrées de jeu, le moteur d’exécution et la méthode de comparaison.

Reproduire le comportement de stock Transformers renforcerait l’affirmation selon laquelle l’artefact fonctionne via son interface de modèle annoncée. Des comparaisons libres plus longues testeraient une concordance durable au-delà de courts échantillons alimentés par référence.

Une divergence nécessiterait un diagnostic plutôt qu’un rejet immédiat. Le comportement numérique, l’initialisation de l’état, les différences de moteur et les fonctionnalités non prises en charge sont des causes possibles distinctes aux implications différentes.

Deuxièmement, surveillez des améliorations de compatibilité étayées par des tests de conformité. Une prise en charge supplémentaire des cartouches serait significative si l’implémentation documente son comportement mémoire et valide des programmes représentatifs.

Le son et une synchronisation graphique plus précise combleraient des lacunes distinctes. Les examinateurs devraient distinguer le transfert de davantage de matériel dans les poids de l’amélioration de l’implémentation conventionnelle de l’hôte.

L’un ou l’autre changement peut améliorer l’application, mais seul le premier étend le périmètre de l’affirmation selon laquelle le calcul se trouve dans les poids. Des frontières claires permettront de conserver des comparaisons futures interprétables.

Troisièmement, surveillez des mesures complètes de performances sur un matériel spécifié. Un rapport utile couvrirait le démarrage, l’exécution, le travail de l’hôte et le temps nécessaire pour produire la séquence de jeu demandée.

Une hausse de vitesse limitée à un calcul sélectionné renforcerait une affirmation plus étroite. Une exécution complète plus rapide sur les jeux pris en charge fournirait une preuve plus solide de progrès pratique.

La discussion entre développeurs de Breunig apporte une autre perspective sur l’importance du projet. Il attribue à des matériaux de référence existants, à un compilateur antérieur et à des tests de conformité un rôle dans sa description du développement assisté par IA.

Des commentateurs favorables ont souligné la valeur de ces vérifications de référence. Des participants sceptiques ont remis en question l’efficacité de traduire du code en opérations de modèle plutôt que d’exécuter directement du code ordinaire.

Aucune de ces réactions ne résout la question d’ingénierie. Ensemble, elles identifient la valeur immédiate du projet : une expérience avec des sorties visibles, des limites explicites et un comportement que d’autres développeurs peuvent vérifier.

Pour les ingénieurs, cela souligne également l’intérêt de maintenir une base de connaissances consultable contenant des spécifications, des implémentations de référence et des preuves de test. Ce type de matériau soutient la revue aussi bien que l’implémentation.

Commencez par le parcours de vérification plutôt que par l’animation lorsque vous évaluez l’émulateur NES de Qwen. Comparez ce que le checkpoint calcule avec ce que l’hôte fournit, puis examinez les traces d’exécution rapportées. Gardez séparés la taille du fichier, la mémoire d’exécution et la vitesse de l’application complète. Si vous suivez le projet, recherchez des exécutions indépendantes concordantes avant de considérer les résultats publiés comme établis. Observez ensuite si la compatibilité s’étend par un comportement de processeur et de cartouche testé, ou principalement par des changements dans les logiciels environnants. Ces distinctions permettent aux développeurs d’apprécier l’expérience tout en prenant des décisions éclairées quant à sa pertinence. Quel prochain résultat modifierait le plus votre évaluation : une reproduction indépendante, une couverture matérielle plus large ou une réduction mesurée du temps d’exécution complet ?