Un Transformer de 21 milliards de paramètres exécute le moteur de rendu de Doom sans entraînement

Cursor Horizon dispose désormais d’un étonnant point de référence technique : un transformer de 21 milliards de paramètres qui affiche Doom sans avoir été entraîné. Le développeur Rob Porter a compilé l’algorithme de rendu du jeu directement dans les poids du transformer. Le résultat remet en question l’idée selon laquelle tout grand transformer aurait appris son comportement à partir de données.

Ce modèle ne prédit pas à quoi une image de Doom devrait ressembler. Il exécute un processus de rendu traduit, un token généré à la fois. Une invite fournit la géométrie de la scène et l’état de la caméra. La sortie contient des calculs intermédiaires et des commandes de dessin qu’un petit programme hôte convertit en pixels.

Cette distinction sépare le projet des expérimentations génératives autour de Doom entraînées sur des vidéos de gameplay. Elle crée aussi la tension centrale de cette histoire Cursor Horizon. L’inférence des transformers est devenue une cible étrange pour les logiciels conventionnels, alors que le programme obtenu est drastiquement plus lent que le jeu d’origine.

Les artefacts publics rendent cette affirmation inhabituellement vérifiable. Porter a publié le compilateur, le graphe du moteur de rendu, les checkpoints, l’invite, les outils de décodage et une implémentation de référence. Toutefois, la plupart des résultats de performance et de précision proviennent encore des propres tests du projet, plutôt que de reproductions indépendantes.

Le moteur de rendu de Doom est devenu un checkpoint de transformer standard

Le changement important n’est pas qu’un modèle d’IA ait produit une image de Doom. C’est que du code de rendu ordinaire est devenu les poids du modèle.

Porter a publié le projet le 13 août 2026, puis un article détaillé destiné à la communauté. Son analyse technique décrit un compilateur appelé torchwright. Il transforme des graphes de calcul en poids d’attention et de feed-forward d’un transformer décodeur seul.

Il n’y a ni boucle d’optimisation, ni corpus d’entraînement, ni mise à jour par gradient, ni approximation apprise du gameplay de Doom. Le compilateur calcule les poids du checkpoint à partir d’un graphe écrit en Python. Ces poids encodent les opérations dont le moteur de rendu a besoin lors de l’exécution.

L’artefact généré utilise l’architecture standard Phi3ForCausalLM. C’est important, car Hugging Face Transformers sait déjà le charger et l’exécuter. Les utilisateurs n’ont pas besoin de code de modèle personnalisé ni du paramètre potentiellement sensible trust_remote_code=True.

Le checkpoint phare contient 38 couches de transformer et environ 21 milliards de paramètres. Ses fragments de poids fp32 occupent 85,87 Go. Une version plus petite de 80 par 50 utilise 70 couches et 34,09 Go de fragments fp32.

Le plus grand checkpoint reçoit une invite de 3 614 tokens représentant la scène. Il génère ensuite 53 747 tokens avant de terminer l’image. La séquence combinée atteint 57 361 tokens.

Seule une partie de cette sortie peint directement des pixels. Les tokens restants représentent des opérations de rendu, des valeurs calculées, du flux de contrôle et de l’état temporaire. Ils fonctionnent davantage comme une trace d’exécution que comme du langage naturel.

Le checkpoint publié comprend la configuration du modèle, le tokenizer, l’invite, la palette et les utilitaires de décodage. Son tokenizer utilise des mots lisibles pour les opérations et les valeurs. Ce choix rend certaines parties de la trace d’exécution compréhensibles sans devoir décoder des identifiants de tokens arbitraires.

Le programme hôte effectue volontairement une tâche étroite. Il mémorise la position d’un curseur, sélectionne des couleurs dans la palette de Doom et peint les segments de pixels demandés. Il ne calcule ni la visibilité, ni la géométrie, ni l’ordre des murs, ni les coordonnées de texture, ni l’occlusion.

Cinq commandes de sortie contrôlent le dessin. Deux commandes définissent les coordonnées du curseur. Deux autres choisissent si le curseur avance horizontalement ou verticalement. La cinquième peint un segment de pixels avec une couleur et une largeur spécifiées.

Cette frontière est essentielle à la crédibilité du projet. Un modèle qui se contenterait de demander à un logiciel externe de rendre Doom serait moins intéressant. Ici, le checkpoint effectuerait le travail de rendu dépendant du point de vue, tandis que l’hôte applique mécaniquement ses instructions de dessin.

Le checkpoint n’est pas le jeu Doom complet. Il n’implémente ni le gameplay, ni les ennemis, ni les sprites généraux, ni le son, ni le contrôle du joueur. Il implémente une version restreinte du moteur de rendu pour des scènes utilisant une bibliothèque de textures fixe.

La sortie complète utilise la résolution d’affichage 320 par 200 de Doom en mode faible détail. Le moteur de rendu calcule 160 colonnes et affiche chacune sur deux pixels. Neuf textures de mur et six textures de sol ou de plafond sont compilées dans le modèle.

La position du joueur, la direction du regard, la géométrie de la carte, les informations de secteur et l’arbre de partitionnement binaire de l’espace arrivent via l’invite. Un arbre de partitionnement binaire de l’espace, ou arbre BSP, divise la carte pour optimiser l’ordonnancement de la visibilité.

Ces entrées peuvent changer sans reconstruire le checkpoint, à condition que la scène reste dans les limites des textures et de la configuration compilées. L’ajout d’une texture non prise en charge exige une recompilation.

C’est pourquoi l’angle Cursor Horizon mérite l’attention. Le projet traite un checkpoint de transformer comme un format de paquet exécutable, et non comme une réserve de connaissances apprises. Ses paramètres sont du matériau de programme généré par un compilateur.

Pourquoi Cursor Horizon remet en cause le modèle fondé d’abord sur l’entraînement

Torwright transforme l’architecture des transformers en substrat de calcul déterministe, sans offrir pour autant un remplacement pratique aux processeurs conventionnels.

La plupart des grands modèles de langage acquièrent leur comportement par entraînement. Les ingénieurs choisissent une architecture, l’exposent à des données, mesurent les erreurs et ajustent les poids par descente de gradient. Le modèle final contient des motifs appris à partir de ces exemples.

Torwright inverse ce flux de travail. Un développeur définit un graphe de calcul, et le compilateur construit des poids qui exécutent ses opérations. Le transformer fini prédit toujours un token après l’autre, mais le processus de prédiction suit un programme conçu à l’avance.

La distinction ressemble à la différence entre apprendre la multiplication à partir d’exemples et exécuter un circuit de multiplication. Les deux peuvent produire la même réponse. Leurs origines internes, leurs limites de fiabilité et leurs modes de défaillance diffèrent.

Le compilateur torchwright open source prend en charge les opérations linéaires, les recherches fondées sur l’attention, les comparaisons, la sélection et la multiplication. Il planifie les nœuds du graphe entre les couches du transformer et stocke les valeurs calculées dans le flux résiduel.

Un flux résiduel est le vecteur évolutif transmis à travers les couches d’un transformer. Torchwright attribue des portions de ce vecteur aux valeurs du programme. Lorsqu’une valeur n’est plus nécessaire, une autre opération l’annule et réutilise son espace.

Dans cette configuration, l’attention fait davantage que de l’association sémantique. Elle récupère des valeurs depuis des tokens antérieurs en faisant correspondre des champs structurés. Ces champs peuvent représenter un identifiant de nœud, la profondeur d’un arbre, le type d’opération ou une coordonnée d’écran.

Les couches feed-forward implémentent les opérations non linéaires. Torchwright propose des bibliothèques d’opérations construites à partir d’activations ReLU ou SwiGLU. Le compilateur convertit chaque opération du graphe en lignes précises de poids feed-forward ou en têtes d’attention.

Cette approche possède des prédécesseurs académiques. RASP a introduit un langage de programmation dont les primitives correspondent à des opérations de transformer. La recherche Tracr de DeepMind a compilé des programmes RASP dans des poids de transformer pour des expériences d’interprétabilité.

Torwright prolonge cette direction vers des graphes de calcul Python ordinaires et un format de sortie Phi-3 standard. La cible est significative, car les logiciels d’inférence existants peuvent charger le résultat sans comprendre son origine inhabituelle.

Cette compatibilité ouvre une possibilité provocante. Un checkpoint standard peut contenir un comportement statistique appris, une logique compilée délibérément ou un mélange des deux. Sa seule structure de fichier ne révélerait pas le procédé ayant produit ses poids.

Pour les développeurs, cela modifie l’interprétation possible des artefacts de modèle. Le nombre de paramètres sert généralement de signal approximatif pour la capacité apprise et le coût d’inférence. Ici, 21 milliards de paramètres reflètent principalement une cible de compilation extrêmement inefficace.

Ce nombre ne signifie pas que le checkpoint possède une connaissance linguistique générale. Il ne peut pas répondre à des questions générales ni improviser des scènes de Doom en dehors de son moteur de rendu pris en charge. Ses poids implémentent un programme contraint plutôt qu’un modèle linguistique ouvert.

Cursor Horizon illustre donc un problème plus large de délimitation. L’écosystème des transformers fournit désormais des chargeurs, des accélérateurs, du partitionnement, des outils de déploiement et des classes de modèles standardisées. Un compilateur peut exploiter cette infrastructure pour des logiciels qui n’ont jamais été entraînés.

Cela ne rend pas les transformers préférables aux CPU. Cela montre que leur mécanisme d’exécution est suffisamment général pour héberger des algorithmes explicitement construits. Généralité, efficacité et utilité restent des questions distinctes.

La contribution la plus forte du projet est conceptuelle plutôt que commerciale. Il rend visible la distinction entre architecture et entraînement. Un transformer est une structure mathématique. Un LLM est une application familière construite en entraînant cette structure sur le langage.

Le modèle de Porter élimine le processus d’apprentissage tout en préservant un comportement d’inférence familier. Il accepte des tokens, applique des couches d’attention et de feed-forward, sélectionne le token suivant, puis recommence. La boucle paraît ordinaire même lorsque le calcul interne ne l’est pas.

Cette propriété offre aussi un environnement de recherche contrôlé. Puisque chaque poids provient d’opérations de graphe connues, les chercheurs peuvent retracer pourquoi une valeur apparaît. Cela contraste fortement avec l’interprétation d’un modèle dont les caractéristiques internes ont émergé de l’entraînement.

Toutefois, le checkpoint Doom est bien plus volumineux que les modèles de test d’interprétabilité typiques. Son échelle démontre que des constructions compilées peuvent atteindre l’infrastructure moderne des modèles. Elle rend également l’inspection et la reproduction indépendante coûteuses.

Le Transformer exécute Doom un token à la fois

Le moteur de rendu fonctionne en convertissant l’état d’exécution mutable de Doom en un historique de tokens ajoutés en continu, que l’attention peut parcourir.

Le moteur de rendu de Doom parcourt un arbre BSP des régions proches vers les régions lointaines. Il projette les murs sur les colonnes de l’écran, suit les zones déjà couvertes et ignore la géométrie cachée derrière des surfaces plus proches.

Le code conventionnel met à jour des variables et des structures de données en mémoire. La génération autorégressive ne peut pas modifier les tokens antérieurs. Chaque nouveau token rejoint une séquence à laquelle on ne fait qu’ajouter, et qui reste disponible pour les passages ultérieurs du transformer.

Le moteur de rendu compilé résout cette incompatibilité en représentant chaque changement d’état par un token supplémentaire. Les opérations ultérieures utilisent l’attention pour trouver l’enregistrement pertinent le plus récent ou combiner plusieurs enregistrements antérieurs.

Un parcours récursif d’arbre s’appuie normalement sur une pile d’appels. Le modèle émet à la place des enregistrements de fil d’Ariane pendant la descente. Lorsqu’il atteint une feuille, l’attention récupère le fil d’Ariane approprié et détermine où l’exécution doit reprendre.

La couverture des murs exige une autre stratégie. Doom stocke les plages horizontales couvertes dans une structure mutable appelée solidsegs. Ces plages l’aident à éviter de dessiner des murs déjà masqués par une géométrie plus proche.

Le transformer ne peut ni fusionner ni écraser les enregistrements de plages antérieurs. Il ajoute chaque plage nouvellement couverte. Les opérations suivantes interrogent l’historique accumulé pour déterminer si une colonne est couverte et où se termine l’intervalle couvert.

Les sols et les plafonds suivent un schéma similaire. Le passage des murs enregistre leurs limites visibles pour chaque colonne de l’écran. Un passage ultérieur récupère ces enregistrements et émet des segments de dessin horizontaux.

Le résultat est une séquence de jetons qui remplit plusieurs fonctions. C’est à la fois un flux d’instructions, une mémoire de travail, une pile d’appels, un journal d’état et un protocole de sortie. L’attention fournit le mécanisme de recherche qui relie ces fonctions.

Les longs calculs sont eux aussi répartis sur les jetons générés. Une couche de transformeur ne peut effectuer qu’une quantité limitée de travail séquentiel avant de transmettre son flux résiduel à la suivante. Des chaînes de dépendances plus longues nécessiteraient davantage de couches.

Le moteur de rendu émet parfois un résultat intermédiaire puis le consomme lors d’une étape de décodage ultérieure. Cette stratégie utilise davantage de jetons afin de réduire la profondeur nécessaire à chaque étape.

La projection murale illustre ce compromis. Le modèle calcule les angles du monde, les convertit en angles relatifs à la caméra, puis projette les extrémités sur l’écran. Des jetons d’angle intermédiaires séparent ces étapes dépendantes.

Cette conception maintient le modèle phare à 38 couches. Elle contribue aussi aux 53 747 jetons de rollout requis pour une image. Chaque transfert intermédiaire supplémentaire ajoute un passage complet supplémentaire dans le modèle.

Le code source du moteur de rendu expose cette chaîne de traitement. Des modules gèrent les entrées de scène, le parcours, la projection, la rastérisation, les textures et le protocole de sortie. Un moteur de rendu Python distinct sert de référence de correction.

Le modèle génère les jetons de façon gloutonne, ce qui signifie qu’il sélectionne le jeton suivant ayant le meilleur score, sans échantillonnage. Le hasard serait inapproprié, car le checkpoint est destiné à exécuter une logique déterministe.

Le mot-clé Cursor Horizon devient ici utile comme métaphore de la frontière d’état du modèle. Son curseur de sortie progresse sur une image rendue, tandis que son horizon d’attention remonte dans l’historique d’exécution.

Pourtant, le mécanisme est plus littéral que poétique. Chaque nouvelle opération peut examiner les faits de scène précédents et les enregistrements générés. Rien dans le processus n’exige la souplesse sémantique associée aux modèles conversationnels.

Le prompt fait office de mémoire en lecture seule. Il contient des faits de carte indépendants du point de vue, ainsi que la position et la direction du joueur. La partie générée sert de mémoire de travail en ajout seul pour les calculs dépendants du point de vue.

L’hôte interprète ensuite les jetons de dessin à l’aide de la palette 256 couleurs de Doom. Il déplace un curseur logiciel et peint les segments demandés. La démonstration minimale de Porter implémente cette partie en 43 lignes de Python.

Ce petit hôte ne prouve pas que chaque calcul de rendu se trouve dans le checkpoint. Toutefois, le code source public rend la frontière vérifiable. Les examinateurs peuvent inspecter la construction du prompt, les modules du graphe, le décodage de sortie et la comparaison de référence.

Le projet indique effectuer des vérifications pixel par pixel contre son moteur Python. Pour l’image phare, il a mesuré une couverture complète des pixels, 99,9 % de concordance parmi les options de couleur autorisées, et 96,7 % de concordance exacte.

Ces chiffres diffèrent légèrement des 97 % arrondis employés dans l’article d’origine. Le fichier de faits canonique du dépôt attribue les dernières mesures à un rendu de production du 9 août.

Le checkpoint à plus basse résolution aurait atteint une couverture complète, une concordance complète des couleurs parmi les options disponibles et 93,9 % de concordance exacte. Son image comptait 3 964 pixels comparés.

Il s’agit de mesures rapportées par le projet. Des tests indépendants n’ont pas encore établi si les mêmes résultats se maintiennent selon les environnements, les prompts ou les variations de scène.

Le véritable résultat est de 35 images par jour

Le projet réussit comme démonstration de compilateur précisément parce qu’il échoue si spectaculairement comme moteur de rendu Doom pratique.

Le Doom original visait 35 images par seconde sur le matériel du début des années 1990. Le checkpoint complet de Porter produit environ 0,0004 image par seconde sur un accélérateur Nvidia B200.

Le décodage glouton a pris 2 383,5 secondes lors de l’exécution de production rapportée. Le chargement du modèle et les autres surcoûts ont porté le temps de bout en bout à 2 528,1 secondes, soit 42,1 minutes.

Cela représente environ 35 images par jour, en supposant un fonctionnement continu et des temps similaires. La comparaison est devenue la blague la plus mémorable du projet. Elle révèle aussi le coût fondamental de la compilation de logiciels ordinaires en inférence autorégressive.

Chaque jeton émis exige un nouveau passage dans un modèle de 21 milliards de paramètres. Dessiner une image implique des dizaines de milliers de ces passages. L’architecture sérialise des opérations que le matériel conventionnel réalise au moyen d’instructions compactes et de pipelines parallèles.

L’exécution sur B200 aurait réservé 151 Gio de mémoire au pic. Le checkpoint seul occupe près de 80 Gio lorsqu’il est mesuré en gibioctets binaires. Ce n’est pas un programme que la plupart des lecteurs peuvent tester sur un GPU de bureau.

Le checkpoint destiné aux consommateurs réduit la résolution à 80 par 50 pixels. Il produit un rollout de 7 007 jetons et se décoderait en 338,3 secondes sur un A100 disposant de 80 Go de mémoire.

Son checkpoint de 34,09 Go peut également être réparti sur deux GPU grand public de 32 Go grâce au mappage automatique des appareils. Cette version rend la reproduction plus accessible, même si elle reste extravagante pour une si petite image.

La précision crée une autre limite. Les modèles publiés utilisent des poids fp32. Les déploiements LLM conventionnels réduisent souvent la mémoire et le calcul via des formats de moindre précision ou la quantification.

La quantification est risquée ici, car les erreurs numériques ne font pas que dégrader les probabilités du langage. Elles peuvent corrompre l’état du programme, les comparaisons, les recherches de type adresse et les annulations au sein du flux résiduel.

La documentation du compilateur Torwright reconnaît que certaines constructions non linéaires utilisent des approximations linéaires par morceaux. Ses tests mesurent les bornes d’erreur des opérations individuelles et comparent les nœuds de graphe compilés avec une évaluation directe.

Ces garde-fous apportent des éléments de preuve, mais pas une certitude mathématique pour chaque exécution complète. Les bornes d’erreur par opération ne se composent pas automatiquement sur de longues chaînes. Le compilateur s’appuie donc sur des sondes de graphe plus larges et des comparaisons de sortie.

La discussion publique du projet sur Reddit a soulevé cette inquiétude directement. Porter a déclaré s’attendre à ce qu’une quantification négligente produise une sortie corrompue plutôt qu’une image de fidélité moindre. Il a aussi indiqué ne pas avoir testé ce scénario.

Une autre limite concerne la généralité. Le checkpoint prend en charge une région sélectionnée, une résolution fixe et les textures nécessaires autour de la zone d’ouverture d’E1M1. Il ne reproduit pas l’ensemble du moteur de rendu pour tout le contenu de Doom.

Les sprites restent non implémentés. L’arme et la barre d’état sont figées dans l’état de départ avec le pistolet. Le modèle rend une scène, et non une boucle de jeu interactive dotée des systèmes de gameplay habituels.

Le prompt de carte du projet subit aussi une préparation avant l’inférence. Le code côté hôte recadre le niveau dans une région fixe de l’espace monde et encode les faits statiques sous forme de jetons. Le dépôt décrit cette frontière comme comparable au chargement d’un niveau.

Les critiques peuvent raisonnablement se demander si cela compte encore comme Doom exécuté dans un transformeur. La réponse la plus défendable est plus étroite : la logique de rendu dépendante du point de vue s’exécute dans un checkpoint compilé pour une scène Doom contrainte.

Il serait inexact d’affirmer que Doom lui-même est devenu un LLM. Le checkpoint ne possède aucune capacité linguistique apprise et n’implémente pas le jeu complet. « Moteur de rendu hébergé par un transformeur » est une description plus juste.

L’angle Cursor Horizon devrait préserver cette distinction. Le projet élargit ce qu’un fichier de modèle standard peut représenter, mais il ne démontre pas une nouvelle voie compétitive pour le calcul graphique.

Il n’a pas non plus reçu de vérification indépendante à grande échelle. Le dépôt fournit le code, les poids, les prompts, les mesures et les outils de comparaison. Reproduire le résultat phare nécessite toujours du matériel coûteux et une capacité de téléchargement importante.

La réaction de la communauté reflète les deux aspects. Des développeurs ont salué l’idée du compilateur et ri de ses performances. D’autres ont demandé si des sorties parallèles, des architectures alternatives ou des systèmes de diffusion rendraient les images plus efficacement.

Ces suggestions manquent une partie de la contrainte délibérée du projet. Porter voulait un modèle standard de génération de texte que les classes ordinaires de Hugging Face puissent charger. Ce choix a lié le moteur de rendu à une boucle inefficace d’un jeton par étape.

Modifier l’architecture pourrait améliorer la vitesse tout en affaiblissant la démonstration. Le projet est intéressant parce qu’il accepte les limites d’un transformeur causal classique et achève malgré tout le processus de rendu.

Ce que Cursor Horizon devrait surveiller ensuite

Le prochain test n’est pas une autre capture d’écran impressionnante. Il s’agit de savoir si des tiers peuvent reproduire, compresser et généraliser l’exécution compilée.

Le premier signal est la reproduction indépendante. Un tiers devrait exécuter le checkpoint basse résolution publié, comparer sa sortie au moteur de rendu de référence et publier les détails matériels et logiciels.

Une réplication réussie renforcerait l’affirmation selon laquelle un checkpoint standard exécute le graphe documenté. Une sortie divergente révélerait une sensibilité aux versions des transformeurs, aux noyaux numériques, au placement des appareils ou au comportement en virgule flottante.

Le deuxième signal est l’exécution à plus faible précision. Une version validée en bf16, fp16 ou quantifiée réduirait la barrière matérielle du projet. Elle testerait également la capacité de torchwright à gérer les annulations résiduelles et les comparaisons avec une précision réduite.

Une réussite rendrait les transformeurs compilés plus faciles à étudier et à distribuer. Un échec clarifierait que le comportement numérique exact demeure une contrainte majeure pour ce modèle de programmation.

Le troisième signal est une prise en charge plus étendue des scènes. Le même checkpoint devrait rendre plusieurs positions, directions et régions de carte compatibles sans recompilation. Les comparaisons publiées devraient couvrir davantage que la vue phare d’E1M1.

Ce test distinguerait une implémentation de moteur de rendu général d’un parcours de démonstration hautement optimisé. Il montrerait aussi comment le mécanisme d’état en ajout seul se comporte lorsque la géométrie et le nombre de jetons varient.

Le parallélisme reste une question importante à plus long terme. La conception actuelle de Porter utilise un jeton généré pour chaque étape de calcul bornée. Un système qui émettrait plusieurs opérations sûres par passage pourrait réduire l’énorme charge de décodage.

Toutefois, ce changement doit préserver l’affirmation centrale du projet. Déplacer les calculs géométriques ou les décisions de visibilité dans le code hôte améliorerait les performances en relocalisant le moteur de rendu, et non en améliorant l’exécution d’un transformeur compilé.

De futurs exemples torchwright pourraient s’avérer plus instructifs que des images Doom plus rapides. Les analyseurs déterministes, validateurs de protocoles, calculateurs et modules algorithmiques transparents correspondent mieux aux forces du compilateur que les graphismes en temps réel.

La logique compilée pourrait aussi être associée à des composants entraînés. Un modèle appris pourrait traiter un langage ambigu tandis qu’un sous-réseau construit imposerait un calcul ou un protocole. Cette possibilité demeure spéculative et techniquement difficile.

Les chercheurs en sécurité devraient également surveiller les formats de checkpoint standards. Les scanners de modèles existants se concentrent souvent sur le code sérialisé, le chargement non sécurisé ou les fichiers suspects. Des poids construits directement introduisent un comportement sans fournir de code exécutable conventionnel.

Cela ne rend pas torchwright malveillant. Son code source et son intention sont exceptionnellement ouverts. La leçon plus large est que « sans code personnalisé » ne signifie pas « sans comportement programmé ».

Les développeurs devraient aussi éviter de considérer le nombre de paramètres comme un indicateur d’intelligence. Ce checkpoint comporte 21 milliards de paramètres parce que son compilateur traduit un moteur de rendu dans une architecture encombrante. La taille seule révèle peu de choses sur les connaissances apprises ou le raisonnement utile.

Pour les lecteurs de Cursor Horizon, l’enseignement pratique est un modèle mental plus précis des transformeurs. L’entraînement est une façon de définir leurs poids. La compilation en est une autre, même lorsque le résultat est outrageusement inefficace.

Le projet est surtout précieux comme argument exécutable. Il montre qu’une infrastructure de modèle familière peut porter des programmes déterministes, et pas seulement des mémoires statistiques. Il montre aussi pourquoi les ordinateurs conventionnels restent exceptionnellement efficaces pour le calcul conventionnel.

Essayez de lire la trace d’exécution, d’inspecter le graphe du compilateur ou de reproduire le point de contrôle plus réduit. Puis posez la question qui compte au-delà de Doom : quels algorithmes tirent réellement parti d’une exécution native aux transformateurs, et lesquels ne deviennent que de coûteuses curiosités ?