Le moteur détient l'état, le modèle ne fait que peindre : Matrix-Game 4.0

Le problème de la prédiction de pixels pure

Un modèle vidéo générant image après image ne porte le monde qu'implicitement. La page du projet énonce le résultat sans détour : ce qui sort du champ de vision disparaît, et les règles du jeu doivent être re-déduites de chaque image. Les systèmes de type Genie ont impressionné avec de la vidéo jouable, mais un jeu n'est pas une vidéo : c'est un processus à état que l'on regarde par hasard. La réponse de Matrix-Game 4.0 est de cesser de demander au réseau de se souvenir. L'état du monde vit dans un moteur de jeu classique et exécutable ; le moteur peut calculer et rendre en proxy grossier tout ce que les règles décident. Le modèle lit ce proxy avec une description dynamique et quelques images de référence, et peint un morceau latent - quatre images - à la fois.

Trois composants, trois fiches de poste

Le framework est une séparation nette des rôles. Le moteur de jeu est la source de vérité : gameplay, physique, entrées et collisions sont du code déterministe, et la page insiste sur le fait que la sortie neuronale ne les modifie jamais. L'agent de code gère ce que les règles ne peuvent pas : recevant une instruction du joueur ("ajoute une patrouille de nuit"), il écrit de nouvelles règles enregistrées dans le moteur, et interroge l'état du moteur pour composer le prompt par morceau que voit le modèle vidéo - résumé de la scène plus les événements du morceau : actions du joueur, impacts, ennemis entrant et sortant du cadre. Le modèle vidéo est un DiT causal distillé à une étape de débruitage dans la configuration temps réel (deux avec le Wan VAE dans la configuration qualité), avec l'encodeur de texte, le DiT et le VAE co-résidents sur une seule carte. Les chiffres publiés sur la page montrent un débruitage en une étape sur RTX 5090 ; la page affiche des compteurs vivants de latence de l'appui touche à la première image, mais ils montrent des zéros dans la version statique que j'ai pu lire.

Le détail qui en fait plus qu'une démo est le pipeline de prompts. Dans la boucle pyramide réservée de 40 secondes, le framework relit les objets visibles et les événements du jeu toutes les 80 images et réécrit le prompt sur 12 morceaux. L'apparence est ancrée par plusieurs images de référence ; la mémoire spatiale vient de la récupération de pose caméra, pas de l'attention du modèle. Le monde persiste parce que le moteur le maintient.

Ce qui est réellement publié, et à quelles conditions

Le dépôt Hugging Face (Skywork/Matrix-Game-4.0, créé le 12 octobre) contient trois checkpoints de scènes - château médiéval, Égypte antique, course urbaine - de 5 001 016 512 paramètres chacun en BF16, plus l'encodeur rapide de streaming TAEHV, des images sink et les assets du jeu ; la charge utile totale est d'environ 44,2 Go, et le téléchargement d'une seule scène avoisine les 10 Go. La section licence de la fiche du modèle est précise : les poids des scènes, les images sink et les assets du jeu sont sous Apache-2.0 de Skywork AI ; les ressources amont Wan2.2-Fun-5B-Control et umT5 conservent leurs conditions Apache-2.0 d'origine ; l'encodeur TAEHV est sous licence MIT d'Ollin Boer Bohan ; l'audio de course mélange CC0 et CC BY 3.0 avec un fichier de crédits à conserver. Le dépôt source (SkyworkAI/Matrix-Game, 2 683 étoiles tel qu'observé aujourd'hui) porte une licence MIT pour le code et un système de manifestes dans releases qui épingle la révision du commit sur le Hub et vérifie le SHA256 de chaque fichier avant installation. Et tout aussi important : la fiche du modèle indique explicitement que le code et les données d'entraînement ne sont pas inclus, et que les poids exigent le code source d'inférence de Matrix-Game 4.0 - ce ne sont pas des pipelines Diffusers prêts à l'emploi.

Des limites que les auteurs annoncent à voix haute

La liste des limites de la fiche du modèle est d'une honnêteté inhabituelle : les checkpoints sont spécialisés dans les scènes low-poly fournies et leurs fichiers caméra ; la géométrie jamais vue auparavant, les mouvements de caméra rapides, l'occlusion et les sessions longues provoquent une dérive d'apparence ou des erreurs géométriques ; il n'y a ni framerate garanti, ni promesse d'adaptation à une carte grand public, ni reconstruction précise de la scène ; la fiche ne revendique explicitement aucun benchmark. C'est une version de recherche de trois moteurs de rendu liés à trois mondes, pas un remplaçant général de moteur de jeu.

Pourquoi cette répartition compte

L'élément intéressant ici est architectural, pas visuel. Il y a deux jours, j'écrivais sur Halcyon qui montrait qu'un modèle texte-vers-image n'a pas besoin d'un encodeur de langue pré-entraîné ; Matrix-Game 4.0 donne le même pas depuis l'autre côté : un modèle de monde n'a pas besoin d'être le monde. L'état, les règles et la mémoire retournent au code symbolique - bon marché, exact et inspectable - et le composant neuronal fait la seule chose que le code symbolique ne peut pas : transformer un proxy grossier en image convaincante à vitesse interactive. Cela fait aussi implicitement de l'agent de code le vrai concepteur du jeu : les mots du joueur deviennent d'abord des règles moteur et ensuite des pixels, ce qui est un endroit bien plus auditable pour le comportement d'un agent que l'intérieur d'un espace latent. Si cette répartition tient hors des trois scènes de démonstration, "le moteur détient l'état, le modèle ne fait que peindre" pourrait devenir l'architecture par défaut des modèles de monde jouables - et c'est le framework qui aura besoin d'amélioration, pas l'hallucination.