Les modèles de diffusion sont des moteurs de jeu en temps réel
(gamengen.github.io)- GameNGen génère les transitions d’écran du jeu classique DOOM uniquement avec un modèle neuronal, permettant une interaction en temps réel sans moteur traditionnel distinct
- Il fonctionne à plus de 20 fps sur un seul TPU et vise à maintenir la qualité visuelle et la réactivité même sur de longues trajectoires de jeu
- La prédiction de l’image suivante atteint un PSNR de 29,4, et les évaluateurs humains ne distinguent les courts clips du vrai jeu et de la simulation qu’à un niveau à peine supérieur au hasard
- L’entraînement repose sur des journaux d’actions et d’observations produits par un agent RL, le modèle de diffusion générant l’image suivante à partir des images passées et des séquences d’actions
- Pour réduire la dérive autorégressive qui s’accumule pendant l’inférence, du bruit gaussien est ajouté aux images de contexte pendant l’entraînement, ce qui joue un rôle important dans la stabilité visuelle sur la durée
Une simulation de DOOM exécutée uniquement par un réseau neuronal
- GameNGen est un moteur de jeu basé sur un modèle neuronal qui permet une interaction en temps réel le long de longues trajectoires dans des environnements complexes
- La démo montre le résultat de la simulation d’un enregistrement en temps réel de personnes jouant à DOOM uniquement avec le modèle neuronal GameNGen
- Les performances et la qualité visent à rendre la simulation difficile à distinguer d’une vraie partie
- DOOM est simulé de manière interactive à plus de 20 fps sur un seul TPU
- La prédiction de l’image suivante atteint un PSNR de 29,4
- Ce PSNR est d’un niveau comparable à celui d’une compression JPEG avec perte
- Les évaluateurs humains ne distinguent les courts clips de jeu et de simulation qu’à un niveau légèrement supérieur à une estimation aléatoire
- Les ressources associées sont disponibles dans le Paper et sur Arxiv
Données d’entraînement et composition du modèle génératif
- La collecte de données se fait en entraînant un agent RL automatique, plutôt qu’en rassemblant à grande échelle des parties jouées par des humains
- Les actions et observations issues des épisodes d’entraînement de l’agent sont enregistrées
- Ces journaux d’actions et d’observations deviennent les données d’entraînement du modèle génératif
- Le modèle génératif réutilise Stable Diffusion v1.4, un petit modèle de diffusion
- Il génère l’image suivante en la conditionnant sur une séquence d’actions précédentes et d’images d’observation
- Pour réduire la dérive qui apparaît lors de l’inférence autorégressive, du bruit gaussien est ajouté pendant l’entraînement aux images de contexte encodées
- Cette injection de bruit amène le modèle à corriger les informations échantillonnées depuis les images précédentes, ce qui est important pour maintenir la stabilité visuelle sur de longues durées
- L’autoencodeur préentraîné de Stable Diffusion v1.4 compresse des patchs de 8x8 pixels en 4 canaux latents
- Dans la prédiction d’images de jeu, de petits détails et surtout la barre HUD en bas présentent des artefacts visibles
- Pour améliorer la qualité d’image, seul le décodeur de l’autoencodeur latent est entraîné avec une perte MSE sur les pixels de l’image cible
1 commentaires
Commentaires Hacker News
Je suis surpris de voir que les modèles de diffusion semblent intégrer plus de cause, effet et séquentialité que je ne le pensais
Le fait que Google ait utilisé SD 1.4 comme cœur du modèle de diffusion rappelle aussi utilement que les modèles ouverts sont précieux, même pour un géant monopolistique du cloud
Ce qui m’a marqué dans le résumé, c’est 1) qu’ils ont fait jouer un agent à Doom pour obtenir, en pratique, des données d’entraînement infinies, 2) qu’ils ont ajouté du bruit gaussien aux frames d’origine puis récompensé le système pour “corriger” les frames suivantes, et que cela a été essentiel à un “rendu” stable sur la durée
Ce dernier point est particulièrement intéressant, car il donne l’intuition qu’on apprend au modèle la correction d’erreurs et la stabilité
Je me demande aussi s’il serait facile de considérer ce modèle comme un “modèle de fondation Doom”, puis de le fine-tuner dans un style photoréaliste ou ray tracing afin d’obtenir un rendu plus agréable
Le joueur revient très peu sur ses pas, et quand le personnage se retourne effectivement pour revoir la même chose, beaucoup d’éléments ont changé. La salle avec le mur gris et le panneau triangulaire est particulièrement frappante
Cela correspond au comportement attendu d’un modèle de diffusion. Entraîné sur des milliards de frames de gameplay, il produit bien une frame “suivante” plausible à partir des quelques frames précédentes, mais ne comprend pas vraiment en profondeur les contraintes logiques du jeu, comme le fait de mémoriser la structure du niveau
Les poids peuvent encoder en partie des notions comme cause et effet, mais le modèle ne rend qu’une frame à la fois. À l’origine, c’est un modèle texte-image, pas un modèle texte-vidéo
À la place du texte, l’état précédent et les frames précédentes servent d’entrée pour prédire la frame suivante
Le bruit est ajouté à la frame précédente avant de l’envoyer au modèle SD ; ce n’est pas l’agent d’apprentissage par renforcement qui l’a “corrigé”
L’objectif de débruitage est largement utilisé en machine learning et, intuitivement, il force le modèle prédictif à exploiter le contexte, comme les frames ou les mots voisins
Ici, il aide à empêcher que les petites erreurs dues à l’aléa du modèle de diffusion génératif s’accumulent et provoquent une dérive autorégressive. La figure 4 montre cette dérive lorsque le joueur reste immobile
C’est du type “on peut imaginer ce qui aurait pu se passer ensuite”
J’ai envie d’appeler ça la compression vidéo la plus inefficace du monde
Ce que je voudrais vraiment voir, c’est une vraie capacité de prédiction, autrement dit de l’imagination. Cela n’apparaissait pas clairement dans l’abstract
Le modèle a été entraîné sur les ensembles de cartes classiques ; que ferait-il si on lui donnait quelques frames de gameplay d’une carte inconnue ? Jusqu’où serait-il capable d’imaginer la suite ?
Cet article a quatre coauteurs. Ils ont sans doute reçu pas mal de ressources, mais ils ont tout de même dû les partager au sein du pool alloué à la division de recherche
Même chez Google, Gemini n’existe qu’en quelques versions
Le simple fait que ça fonctionne est incroyablement stupéfiant, et le fait d’atteindre en plus un rendu à 20 fps est impressionnant
Comme il fallait encoder l’image précédente et l’action pour les injecter dans le modèle à chaque étape, ça ressemble à un mélange entre un modèle de diffusion et un réseau de neurones récurrent
De façon abstraite, on a l’impression que le modèle rêve d’un jeu auquel il a beaucoup joué, et que les entrées en temps réel modifient l’état de ce rêve
On en vient à se demander si les humains ne sont pas eux aussi des machines de prédiction de l’instant suivant, avec simplement un peu plus de mémoire embarquée
En inversant le raisonnement, si l’on considère l’image suivante comme une hypothèse attendue résultant de l’image actuelle, il est plus facile de comparer cette « hypothèse » aux sensations réelles, et de traiter l’écart, que de traiter l’ensemble des entrées sensorielles
Comme Richard Dawkins l’a dit dans un podcast récent[1], les gènes sont d’excellentes machines de prédiction, puisque la survie dépend de la prédiction. Quand on pense à la quantité de ressources consacrées à la vision, la capacité à générer des prédictions visuelles paraît cohérente
Dans ce cas, que nous apprend l’aphantasie ?
[1] https://podcasts.apple.com/dk/podcast/into-the-impossible-wi...
Le podcast de Lex Fridman « Counterintuitive Ideas About How the Brain Works »[2] vaut le détour. Elle y explique notamment que le cerveau fonctionne le plus efficacement par prédiction continue plutôt que par réaction
Elle est aussi excellente vulgarisatrice scientifique, ce qui donne envie de continuer à l’écouter
[1] https://en.wikipedia.org/wiki/Lisa_Feldman_Barrett
[2] https://www.youtube.com/watch?v=NbdRIVCBqNI&t=1443s
La comparaison avec un GPU grand public haut de gamme comme une 3090 n’est pas claire, mais les TFLOPS INT8 semblent similaires. Le TPU a moins de mémoire (16 Go contre 24 Go), et je ne connais pas bien les autres caractéristiques
Malgré tout, quelque chose ne colle pas. SD met généralement au moins quelques secondes, même sur une 3090, pour produire un résultat de bonne qualité ; ici, c’est presque un ordre de grandeur plus rapide. On dirait que, pour cette tâche, le TPU écrase le GPU
Il semble générer des images en basse résolution (320x240), mais ça paraît quand même beaucoup trop rapide
On dirait qu’on part de l’IA pour remonter à l’envers, en faisant entrer toute la cognition dans le cadre d’un « prédicteur de quelque chose qui vient ensuite »
Au fond, c’est une répétition du débat sur les perroquets stochastiques
Après avoir lu ce fil, je pense qu’il vaut la peine de préciser que cet article ne décrit pas un système qui prend des entrées utilisateur en temps réel pour les refléter dans la sortie
Cela dit, la formulation du résumé m’a semblé suggérer fortement que c’était le cas
Le modèle est entraîné sur un vaste jeu de données où un agent joue à DOOM, et fournit des échantillons vidéo destinés à l’évaluation par les utilisateurs, mais il ne s’agit pas d’un système où l’utilisateur envoie des entrées dans la simulation en temps réel pour « jouer à DOOM » à environ 20 FPS
Dans l’article, des formulations comme « des questions clés demeurent, par exemple comment créer efficacement le jeu au départ, et comment exploiter au mieux les entrées humaines », ou « l’objectif final est de permettre à des joueurs humains d’interagir avec la simulation » donnent des indices
Surtout, il manque une section décrivant du gameplay utilisateur en temps réel
La vidéo en haut de https://gamengen.github.io/ commence aussi par « ce sont des enregistrements en temps réel de personnes en train de jouer au jeu »
À en croire ces affirmations, il semble qu’à la fin du projet ils aient construit un système jouable que l’on pouvait mettre devant des humains. Mais ce n’était peut-être pas encore le cas au moment où le brouillon a été mis sur arXiv
Il est écrit que « A est un ensemble de frappes clavier et de mouvements de souris… », et que « …pour conditionner sur les actions, nous apprenons un embedding A_emb pour chaque action »
Autrement dit, le processus de diffusion de ce modèle n’est pas conditionné par des mots, mais par un embedding d’action A issu des actions de l’utilisateur
Ensuite, il encode en représentation latente une frame de départ bruitée, puis la concatène comme second conditionnement à la représentation latente bruitée
Au final, c’est un modèle de diffusion entraîné uniquement sur des images de Doom, conditionné par la frame Doom actuelle et par les actions de l’utilisateur pour produire les frames suivantes
Donc l’utilisateur est bel et bien en train de jouer
Cela dit, que ce soit possible n’est pas vraiment surprenant. C’est en quelque sorte un enregistrement neuronal du jeu, mais c’est une démo technique impressionnante
On y lit : « lorsque l’on joue au modèle manuellement, certaines zones sont très faciles pour les deux, certaines zones sont très difficiles pour les deux, et dans certaines zones l’agent fait beaucoup mieux »
Peut-être que je manque d’imagination, mais je ne vois pas d’autre interprétation raisonnable de « jouer au modèle manuellement »
https://www.youtube.com/watch?v=udPY5rQVoW0
« Playing a Neural Network's version of GTA V: GAN Theft Auto »
« Figure 1: a human player is playing DOOM on GameNGen at 20 FPS. »
La phrase du résumé est ambiguë, ce qui a créé beaucoup de confusion ici, mais l’article est clair sur ce point
C’est assez décevant de voir une information erronée comme celle-ci être autant recommandée sur un forum rempli de spécialistes techniques
La quête consistant à faire tourner Doom sur tout continue
Techniquement, n’est-ce pas le plus grand anti-Doom possible, c’est-à-dire le Doom aux exigences matérielles les plus élevées ?
C’est amusant de se dire que, si l’on place les spécifications matérielles sur un axe linéaire, Doom se trouve désormais aux deux extrémités
Autrement dit, ce n’est pas un portage qui l’exécute sans l’environnement matériel et logiciel d’origine de Doom : c’est en quelque sorte faire tourner Doom sans Doom lui-même
L’étape suivante de l’anti-Doom serait un modèle qui génère un modèle générant la sortie de Doom
Configuration requise de Doom :
4 Mo de RAM, 12 Mo d’espace disque
Stable Diffusion v1 utilise un UNet de 860 M et CLIP ViT-L/14 (540 M), avec une taille de checkpoint de 4,27 Go, et 7,7 Go pour l’EMA complète
Il tourne sur TPU-v5e ; les performances maximales par puce sont de 197 TFLOPs en bf16, 393 TFLOPs en Int8 ; la capacité et la bande passante HBM2 sont de 16 Go et 819 Go/s, et la bande passante d’interconnexion entre puces est de 1600 Gbit/s
Compte tenu de la vitesse, c’est assez impressionnant, mais il y a énormément de marge d’amélioration. Vu la capacité, il devrait pouvoir le mémoriser des centaines de fois, et pourtant il semble ne pas avoir complètement appris le jeu par cœur
Il y a donc clairement beaucoup de possibilités d’optimisation. Cela dit, ici l’objectif est la mémorisation, donc on ne sait pas quel impact ces techniques auraient sur les technologies existantes
Ce qui est intéressant, c’est que cela signifie qu’en « jouant » suffisamment longtemps, en automatisant et en utilisant beaucoup plus de stockage et de calcul, on peut décortiquer un jeu
Je serais curieux de comparer le coût et le temps avec l’embauche d’un ingénieur pour faire du reverse engineering de Doom. La quantité de connaissances préalables autorisées est aussi ambiguë. Vu le modèle préentraîné et l’environnement ViZDoom, je me demande si le code source de Doom était dans T5, et quel checkpoint ViT a été utilisé
J’aimerais vraiment voir le checkpoint de ce modèle. Si des gens le désassemblent, ils trouveront sûrement des choses vraiment intéressantes
https://www.reddit.com/r/gaming/comments/a4yi5t/original_doo...
https://huggingface.co/CompVis/stable-diffusion-v-1-4-origin...
https://cloud.google.com/tpu/docs/v5e
https://github.com/Farama-Foundation/ViZDoom
https://zdoom.org/index
Par rapport au jeu original, le coût de calcul est absurde, et il est vrai qu’il manque des éléments de base comme le précalcul ou le stockage
Mais on peut considérer que ces aspects seront résolus à la marge de cette découverte, qu’ils s’amélioreront naturellement avec le temps, ou qu’ils deviendront moins importants comme goulots d’étranglement
La vraie percée, c’est la capacité à modéliser de telles séquences d’images sensibles au contexte sans les encoder explicitement. C’est vrai du point de vue du jeu pur, mais aussi de celui de la simulation en général
L’enjeu plus large, c’est de pouvoir générer un jeu à partir de vidéos du monde réel
Si vous avez besoin d’un simulateur de vol parfait, il suffit de fixer une GoPro dans le cockpit de chaque avion de ligne pendant un an
Lire les commentaires morts sur ce genre d’article est toujours amusant. J’aime voir à quel point ils soulignent que c’est inutile
Certaines personnes devraient apprendre à fabriquer des choses juste pour le plaisir de les fabriquer
Est-ce utile ? Pas vraiment, en fait. Est-ce intéressant ? Certainement
Tout n’a pas besoin d’être créé pour le profit. Ni pour rendre le monde meilleur
Parfois, le but peut être d’apprendre, de relever un défi, de vérifier ce qui est possible
Le temps passé à s’amuser n’est jamais perdu. Sur leur lit de mort, certains regretteront peut-être de ne pas s’être davantage amusés
Dire « c’est vraiment incroyable » implique qu’on pense que, dans un avenir proche, tous les logiciels pourront être remplacés par des modèles d’IA pour créer n’importe quelle expérience de jeu vidéo imaginable
En réalité, c’est la forme de Doom la plus inefficace et la moins fiable jamais créée. Elle utilise littéralement des millions de fois plus de calcul que les premiers PC x86 qui pouvaient rendre Doom et y jouer en temps réel
Bien sûr, c’est un tour de force amusant
C’est aussi en partie inévitable. Le coût de la vie ne cesse d’augmenter, et la romantisation des entrepreneurs comme des rock stars mène à cette mentalité du hustle
Mais je me souviens de l’époque où l’on voyait des articles sur la possibilité de la « radio sur Internet ». Au lieu d’émettre des ondes dans l’air comme avant, que des milliers de radios pouvaient capter, un serveur envoyait d’énormes quantités de paquets à des milliers d’endpoints via une immense longueur de fil de cuivre
Le fait que les endpoints renvoient même des paquets ACK au pauvre serveur pour maintenir la connexion semblait être un gaspillage de puissance de calcul, de câbles et d’énergie
Et pourtant, aujourd’hui, nous regardons des films Netflix en rafale sur ces mêmes fils de cuivre
Je ne dis pas que les jeux seront remplacés par des modèles de diffusion qui rêvent l’image suivante en fonction des entrées utilisateur, mais une variante de cela pourrait devenir de la création artistique interactive ou une nouvelle forme de divertissement
C’est impressionnant, mais difficile d’être d’accord. Un modèle de diffusion n’est pas un moteur de jeu
Un moteur de jeu est un composant qui fait avancer le jeu le long de l’axe du temps. C’est donc comparable à un moteur de voiture, et c’est de là que vient le nom
Un moteur n’a pas besoin d’une voiture complète ni d’une route sur laquelle rouler pour faire son travail
Ce qui est présenté ci-dessus ressemble plutôt à une reproduction interactive et dynamique de ce qui se passe quand on place une voiture sur une route donnée, et il faut faire un million d’essais avec un véhicule en état de marche
Si c’était un moteur, il devrait aussi fonctionner hors route
Plutôt que de dire au présent « il faut une voiture en état de marche sur une route pour faire le travail », il serait plus juste de dire au passé « il a fallu cela pour l’entraîner à faire ce travail »
On ne voit pas non plus clairement pourquoi un moteur de jeu qui utilise des concepts tirés de la manière dont d’autres moteurs fonctionnent cesserait d’être un moteur de jeu
Si l’on parle des modèles de diffusion en général, tout comme ils ne génèrent généralement pas uniquement des images exactement identiques à celles de l’entraînement, mais peuvent interpoler ou appliquer des concepts individuels pour produire de nouvelles sorties, il ne semble pas y avoir de raison de supposer que cette approche ne puisse pas fonctionner en dehors de la « piste d’essai » apprise
Dans un certain sens, c’est un moteur de jeu simulé entraîné sur des données issues d’un véritable moteur de jeu
Mais si un moteur de jeu simulé fonctionnel peut « faire avancer le jeu », alors je considère qu’il devient lui-même un moteur de jeu. La manière d’y parvenir n’a pas d’importance
D’un côté, des humains ont créé le contenu ; de l’autre, le système imite du contenu de jeu existant, mais le joueur s’en moque
On peut imaginer que ce type de « moteur de jeu génératif » puisse aussi sortir des sentiers battus. En extrapolant ce qui se passerait lorsqu’on arrive dans un lieu jamais vu
La capacité d’extrapolation de ce type de modèle pourrait même être meilleure que celle des moteurs de jeu traditionnels. Dans un moteur de jeu classique, si l’on traverse accidentellement un mur, l’écran devient vide, alors que ce modèle peut inventer la suite au fur et à mesure
Les conditions textuelles du modèle SD ayant été supprimées, elles n’entrent pas en jeu ici, mais on peut imaginer que, dans un avenir proche, de nouveaux jeux intéressants pourront être créés uniquement à partir de prompts textuels
Il a fallu utiliser de l’apprentissage par renforcement pour apprendre à quoi ressemble DOOM et comment il fonctionne, mais cela ne signifie pas forcément qu’il y ait un problème de l’œuf et de la poule
C’est un peu comme un LLM qui peut écrire de nouvelles histoires même s’il n’a été entraîné que sur des textes existants
L’un des plus grands défis de cette approche sera sans doute les jeux en monde ouvert, où le nombre d’états possibles est pratiquement infini
L’article indique aussi qu’ils ont eu du mal à faire en sorte que l’agent d’apprentissage par renforcement explore complètement tous les recoins de DOOM
Factorio ou Dwarf Fortress ne seront probablement pas simulés de sitôt. Sans doute
Peut-être même plus petite que le code source lui-même. Quelqu’un du domaine pourra sans doute me corriger
À ce stade, on « rendrait » en fait le jeu en interpolant le code source dans l’espace latent. On aurait en quelque sorte tout un ordinateur dans l’espace latent, avec moteur, assets, textures et moteur de rendu logiciel
Avec un ordinateur suffisamment puissant, on peut aussi imaginer une interpolation dans l’espace latent entre des jeux comme Factorio et TF2. Et l’on pourrait ajuster cet espace latent en le conditionnant sur les aspects de gameplay désirés
Ce futur arrive très vite pour certaines parties du pipeline, comme la dernière étape du rendu. Par exemple, DLSS est déjà commercialisé
Un jour, les revenus de Nvidia reviendront peut-être au jeu vidéo quand tout le monde sera rivé au métavers neuronal
Le choix de DOOM est vraiment excellent
Toute l’énergie serait consacrée aux mécaniques de jeu, et non à la qualité visuelle
On peut espérer que cette approche réduise mieux les incohérences visuelles, comme un monstre rouge qui devient un allié bleu quand on détourne la tête puis qu’on regarde à nouveau
Vous pouvez commencer par un jeu de plateforme relativement simple comme Mario
Vers la page 300, alors que vous n’aurez encore décrit qu’environ la moitié, vous comprendrez pourquoi c’est surtout un vœu pieux
Une seule personne pourra peut-être dialoguer avec un modèle pour créer quelque chose du niveau des titres AAA actuels
Pensez au boom des jeux 2D à défilement horizontal sur Steam, mais avec des jeux 3D immersifs photoréalistes, une physique ultra-réaliste (écoulement de l’eau, propagation du feu, tornades), et des possibilités complètes de transformation et de construction
Le modèle serait préentraîné sur des vidéos du monde réel, et le jeu ne serait qu’un « style » ajustant légèrement les distributions a priori sur l’apparence, le cadre et l’histoire
Si le jeu doit déjà être créé, en quoi le modèle de diffusion est-il un moteur de jeu ? Il faut un jeu pour entraîner le modèle. N’est-ce pas un problème de l’œuf et de la poule ?
On peut créer une version non temps réel d’un moteur de jeu, puis utiliser un réseau de neurones comme approximation temps réel
On peut aussi ajouter par montage des éléments comme un HUD à des vidéos filmées dans le monde réel, et entraîner le réseau de neurones à simuler la réalité plutôt que Doom
Cet article a utilisé 900 millions de frames, ce qui, à 30 fps, doit représenter environ un an de vidéo. Les besoins d’entraînement pourraient aussi diminuer grâce à des améliorations algorithmiques
Un an de vidéo, en réalité, ce n’est pas tant que ça. Par exemple, en recrutant 500 personnes, en leur mettant des GoPro, des accéléromètres et des gyroscopes sur la tête et sur des lanceurs de paintball, puis en les faisant jouer au paintball pendant un week-end, on pourrait obtenir un an de vidéo
D’autres modèles, par-dessus, se contenteraient de fine-tuner les détails pour personnaliser les jeux
Les modèles de diffusion ne peuvent pas être des moteurs de jeu. Un moteur de jeu doit pouvoir créer de nouveaux jeux et modifier en temps réel les règles de jeux existants
Il doit même pouvoir modifier des règles qui ne sont pas visibles à l’écran
Ces outils sont intéressants, mais comme pour tout le battage autour de l’IA, il faut une clause de non-responsabilité
Cet outil n’a pas créé un jeu ; il s’est contenté d’échantillonner un jeu créé par des humains pour générer des frames et l’apparence de mécaniques de jeu
« simplement » généré ? Je comprends que, mécaniquement, cela puisse être simple, mais le fait d’avoir compressé une distribution conditionnelle aussi riche ne me semble pas du tout simple
En l’entraînant sur plusieurs jeux et en intégrant beaucoup plus d’informations sur chacun, il pourrait devenir possible de saisir un prompt décrivant un jeu et d’y jouer
On obtiendrait alors de vrais avantages tout en corrigeant les problèmes de cohérence