Tencent publie le rapport et le benchmark Hy-Nomas avec des comparaisons à Genie 4

Tencent Hunyuan a publié son rapport Hy-Nomas et mis à disposition un jeu de données d’évaluation, tout en recréant séparément des exemples de Genie 4 dans des vidéos comparatives. Cette publication fournit aux chercheurs des ressources pour tester un modèle de monde interactif, un système qui génère des environnements visuels évolutifs en réponse aux commandes des utilisateurs. Ces ressources établissent une base de recherche, mais les extraits de comparaison ne démontrent pas une parité de performances avec le dernier modèle de Google.

Cette distinction est importante, car l’article de Tencent évalue Genie 3, aux côtés d’autres systèmes concurrents, et non Genie 4. Ses résultats publiés reconnaissent également une faiblesse : Hy-Nomas est derrière Genie 3 en matière de cohérence spatiale à long terme. L’annonce est donc plus utile que ne le laisse penser un simple concours de vidéos séduisantes.

Pour les développeurs, la question immédiate porte sur ce qu’ils peuvent examiner, reproduire et adapter. Tencent a rendu cette étude plus concrète grâce à la publication de ressources de recherche. Déterminer si le système obtenu convient à une application créative, à un prototype interactif ou à un projet de recherche exige toutefois des preuves allant au-delà de démonstrations sélectionnées.

Le rapport Hy-Nomas apporte des éléments à une publication existante

Le nouveau rapport documente la conception et l’évaluation du modèle, tandis que le dépôt montre que le code et la démo étaient disponibles auparavant.

La chronologie de publication de Tencent distingue plusieurs événements qu’une annonce unique peut facilement confondre. Le dépôt officiel date la première publication du code et de la démo interactive au 21 octobre 2026. Il répertorie le rapport arXiv le 27 octobre et les vidéos de comparaison avec Genie 4 le 29 octobre.

Cette séquence modifie la manière dont les lecteurs doivent interpréter l’actualité. Il s’agit d’une extension d’une publication existante, avec de la documentation technique et une nouvelle présentation concurrentielle. Ce n’est pas une preuve que chaque composant est devenu disponible pour la première fois simultanément.

L’historique des publications décrit également le code d’entraînement et d’inférence, l’accès au modèle et les intégrations communautaires. L’inférence consiste à exécuter un modèle entraîné afin de produire des résultats. Ces ressources rendent la publication pertinente pour les développeurs qui souhaitent étudier les détails d’implémentation plutôt que juger des extraits finalisés.

Une publication de recherche s’adresse à plusieurs publics aux besoins différents. Un chercheur veut disposer de suffisamment d’informations pour reproduire une expérience. Un développeur veut comprendre les exigences de déploiement et les interfaces. Un professionnel de la création veut savoir si une interaction produit un résultat utile.

Une vidéo d’annonce peut servir ce dernier public sans satisfaire les autres. À l’inverse, un article détaillé peut soutenir une expérience sans démontrer qu’un produit est pratique au quotidien. Les ressources de Tencent doivent donc être évaluées selon la question à laquelle chaque élément peut répondre.

La disponibilité du rapport importe, car elle rend le raisonnement de l’équipe vérifiable. Les lecteurs peuvent examiner comment les auteurs définissent l’interaction, ce que mesure leur évaluation et où s’arrêtent leurs conclusions. Cela ouvre la voie à la critique comme à l’adoption.

Le calendrier place également cette publication aux côtés d’une nouvelle annonce concurrente. Genie 4 de Google est arrivé la même semaine, donnant aux exemples recréés par Tencent un point de référence immédiat. La comparaison attire l’attention, mais le dossier de recherche sous-jacent mérite une lecture distincte.

Le rapport Hy-Nomas doit être considéré comme une description du système et des expériences des auteurs. Il ne valide pas automatiquement toutes les impressions créées par les séquences promotionnelles. La reproductibilité commence lorsqu’une autre équipe peut relier la méthode écrite aux résultats réels dans des conditions documentées.

Pour les lecteurs découvrant le projet par les réseaux sociaux, c’est le changement central. Il existe désormais une base d’étude plus substantielle que la seule ressemblance visuelle. La suite utile consiste à examiner ce que le benchmark publié demande à un modèle de faire.

Hy-Nomas-Bench fait passer la question de l’apparence à l’interaction

Une collection de tests partagée permet aux chercheurs d’examiner le comportement au fil de commandes successives, plutôt que de comparer des moments forts isolés.

Le benchmark interactif de Tencent décrit 280 cas répartis en quatre tâches : interaction textuelle à plusieurs tours, navigation de caméra, contrôles intercalés et mémoire spatiale. L’interaction à plusieurs tours consiste à émettre des instructions successives dans une même scène évolutive. La mémoire spatiale concerne la capacité à conserver la cohérence d’objets et de configurations observés auparavant lorsqu’ils sont revisités.

La collection inclut des prompts, des séquences d’interaction et des trajectoires de caméra de référence. Une trajectoire de caméra précise comment le point de vue se déplace dans une scène. Ces entrées fournissent une base pour reproduire un test, même si la documentation du jeu de données distingue les entrées d’évaluation de la notation.

Cette séparation mérite de l’attention. Télécharger un benchmark ne produit pas à lui seul un classement fiable. Il faut générer des résultats, appliquer des critères d’évaluation, enregistrer les exclusions et expliquer comment les différentes interfaces des modèles ont été prises en compte.

Prenons une tâche créative hypothétique dans laquelle un personnage transporte un objet à travers une pièce. La première commande établit le personnage et l’objet. Une instruction ultérieure modifie l’action, puis un mouvement de caméra révèle une autre partie de la pièce.

Un système utile doit relier ces moments. Il doit préserver le personnage concerné, conserver la position modifiée de l’objet et répondre au nouveau point de vue. Une fin visuellement séduisante n’explique pas si ces transitions sont restées cohérentes.

C’est pourquoi les tests d’interaction comptent pour le développement de produits. Une application reçoit des commandes au fil du temps, souvent après que les utilisateurs ont réagi à des résultats précédents. Son utilité dépend de sa capacité à gérer cette séquence, y compris les demandes qui interrompent ou révisent un plan initial.

Le benchmark crée également une base plus claire pour les désaccords. Les chercheurs peuvent identifier le cas où un modèle échoue et décrire cet échec. C’est plus exploitable que de débattre de la collection de vidéos promotionnelles qui paraît la meilleure.

La pression s’exerce en partie sur Tencent lui-même. Une fois qu’une collection de tests est publique, des équipes externes peuvent contester l’interprétation publiée. Elles peuvent examiner si l’avantage apparent résiste à des procédures d’évaluation différentes ou se concentre dans certains scénarios.

Les autres développeurs de modèles font face à un choix connexe. Ils peuvent participer à des évaluations comparables, expliquer pourquoi la tâche ne convient pas à leurs systèmes ou proposer des alternatives. Chaque réponse peut améliorer la compréhension si elle explicite les hypothèses sous-jacentes.

La portée du benchmark exige toutefois de la retenue. Une collection axée sur l’interaction ne tranche pas toutes les questions de qualité visuelle, de son, d’utilisabilité ou de fiabilité applicative. Un résultat utile répond à la question mesurée, avec ses conditions associées.

Pour un acheteur, cela signifie qu’il faut éviter une étiquette globale unique telle que « meilleur modèle de monde ». Les différentes applications imposent des exigences différentes au système. Les éléments pertinents dépendent de la priorité accordée à la navigation, au suivi des instructions, à la continuité ou à un autre comportement.

La valeur pratique de cette publication est donc de fournir un point de départ commun pour l’étude. Son importance à long terme dépendra de la publication, par des utilisateurs indépendants, de suffisamment de détails pour rendre leurs conclusions comparables.

Le modèle sépare le contexte durable des commandes temporaires

L’approche technique de Tencent répond à un problème d’interaction précis : une action doit prendre fin tandis que ses conséquences restent intégrées à la scène.

Selon le rapport Hy-Nomas, le système utilise une architecture de diffusion de 8 milliards de paramètres, un réseau neuronal qui génère du contenu visuel par débruitage. Il produit des segments successifs à partir des instructions actuelles et de l’historique conservé. Tencent décrit une attention sensible aux actions qui limite les instructions d’action aux fenêtres temporelles prévues tout en préservant le contexte descriptif.

L’article décrit aussi un Prompt Enhancer, un composant vision-langage qui transforme les demandes et l’historique observé en conditions structurées pour le segment suivant. Son évaluation utilise des comparaisons humaines avec Genie 3, LingBot-World v2 et Happy Oyster. Tencent fait état d’avantages en matière d’interaction, mais reconnaît que Hy-Nomas est derrière Genie 3 pour la cohérence spatiale à long terme.

Ces résultats suggèrent une interprétation plus précise qu’une supériorité globale. Les auteurs présentent un système conçu autour d’une interaction flexible, tout en identifiant la mémoire comme un domaine encore inachevé. Ces deux éléments doivent figurer dans tout compte rendu de la publication.

La distinction entre une action et sa conséquence apparaît facilement dans une scène illustrative. Supposons qu’un utilisateur demande à un personnage d’ouvrir une porte. Ensuite, le personnage devrait cesser de l’ouvrir, tandis que le nouvel état de la porte doit rester pertinent.

Répéter l’ancienne commande peut créer un comportement indésirable. Oublier sa conséquence peut produire une autre erreur de continuité. Un système interactif doit conserver suffisamment d’historique pour distinguer ces résultats lorsque la demande suivante arrive.

C’est un angle utile pour lire l’architecture. La conception cible une source concrète de confusion dans la génération séquentielle. La question de savoir si elle résout ce problème de manière fiable reste empirique, en particulier lorsque plusieurs actions et changements de point de vue s’accumulent.

Le Prompt Enhancer influence également la manière dont les chercheurs doivent interpréter l’expérience. La courte instruction d’un utilisateur et le conditionnement détaillé du générateur sont des étapes différentes du système. La performance concerne l’ensemble du flux de travail testé.

Pour les créateurs d’applications, cela soulève une question de diagnostic. Lorsqu’un résultat échoue, le système a-t-il mal interprété la demande, généré la mauvaise action ou perdu un état antérieur ? Ces possibilités appellent des remèdes différents.

Une interface qui dissimule chaque étape intermédiaire peut rendre cette enquête difficile. Un flux de recherche gagne à conserver la demande originale, son interprétation structurée et le segment obtenu. Ensemble, ils aident à expliquer où le comportement a divergé de l’intention.

La fiche de modèle de Tencent documente séparément une configuration à faible consommation mémoire pour une seule NVIDIA GeForce RTX 4090. Elle utilise des composants à précision réduite et le déchargement vers le CPU, qui transfère les composants inactifs dans la mémoire système. La fiche décrit également une sortie de 720 par 1280 à 24 images par seconde dans une configuration distillée.

Ces spécifications établissent des options de déploiement, et non une garantie de réactivité vérifiée indépendamment. La fréquence de lecture vidéo et la vitesse de génération répondent à des questions différentes. Un développeur doit encore mesurer le temps d’attente des utilisateurs après l’envoi d’une commande.

Cela compte, car l’interaction modifie la notion de performance acceptable. Un flux de rendu hors ligne peut tolérer une attente qui interromprait l’exploration. Le même modèle peut donc convenir à une application tout en paraissant peu pratique dans une autre.

La contribution technique devient particulièrement utile lorsqu’elle est reliée à de telles exigences concrètes. L’architecture explique le mécanisme visé. Des expériences répétées et documentées déterminent comment ce mécanisme se comporte dans l’environnement qu’un développeur prévoit réellement d’utiliser.

Les comparaisons avec Genie 4 établissent un point de référence, pas un classement

Les exemples recréés par Tencent et son benchmark publié relèvent de formes de preuve différentes.

Le dépôt officiel décrit les vidéos du 29 octobre comme des exemples de Genie 4 recréés avec Hy-Nomas. Cette formulation identifie une comparaison qualitative. Elle ne décrit pas la participation de Genie 4 au protocole d’évaluation de l’article.

L’annonce de Google concernant les capacités de Genie 4, publiée le 27 octobre, décrit une interaction en temps réel et un audio natif, notamment des sons d’ambiance et des dialogues. Google indique que l’accès débute par un aperçu de recherche destiné à des testeurs de confiance, avant un déploiement plus large. Il s’agit des affirmations et des plans de lancement de Google, plutôt que de conclusions indépendantes sur les performances comparatives.

Les entreprises présentent donc des types de preuves différents concernant l’accès et les capacités. Tencent fournit des artefacts publiés permettant une investigation directe. Google décrit un système expérimental dont la disponibilité initiale est contrôlée.

Pour les développeurs, l’accès possède en lui-même une valeur pratique. Un modèle disponible peut être examiné selon les contraintes propres à une équipe. Un aperçu restreint crée une dépendance à l’admission et aux conditions du service hébergé.

Cela ne fait pas de l’accès un substitut à la qualité. Un système peut être plus facile à obtenir tout en étant moins performant sur une tâche importante. À l’inverse, une démonstration plus convaincante peut rester difficile à évaluer lorsque les chercheurs ne peuvent pas exécuter leurs propres cas.

La pression concurrentielle concerne ici la capacité à étayer les affirmations. La publication de Tencent invite à l’expérimentation externe, rendant son comportement plus ouvert à l’examen. L’annonce de Google fournit une référence récente en matière de capacités, mais la structure de son aperçu limite les personnes pouvant la tester directement.

Les comparaisons sélectionnées peuvent aider à identifier les questions qui méritent d’être étudiées. Elles peuvent montrer qu’un type de scène ou d’interaction semble à la portée d’un système. Elles ne peuvent pas révéler la distribution complète des résultats sans informations sur les tentatives, la sélection et les échecs.

Une séquence d’apparence similaire laisse également plusieurs possibilités non résolues. Les systèmes peuvent nécessiter des instructions, une préparation ou un temps de génération différents. Ils peuvent diverger lorsque la scène se poursuit au-delà de l’extrait retenu.

Ces incertitudes n’invalident pas les vidéos. Elles définissent ce qu’un spectateur peut raisonnablement en conclure. Les séquences constituent des preuves de résultats présentés, avec des informations limitées sur leur représentativité.

Une comparaison équitable doit correspondre à la décision à prendre. Si la question porte sur le suivi des instructions, les évaluateurs ont besoin de commandes comparables et d’une définition claire de la réussite. Si elle porte sur la facilité d’utilisation, le temps d’attente et la récupération après des erreurs deviennent pertinents.

Si la question porte sur le son, une comparaison visuelle ne peut pas la trancher. Si elle porte sur la conservation de l’agencement d’une pièce, l’évaluateur a besoin d’une interaction qui revient à la vue précédente. Le test doit exposer le comportement revendiqué.

C’est aussi pourquoi les résultats de l’article concernant Genie 3 doivent conserver leur identité d’origine. Un résultat face à un modèle antérieur ne peut pas être réétiqueté comme une preuve contre son successeur. Les vidéos ultérieures ne mettent pas à jour le benchmark par implication.

Pour l’instant, la conclusion défendable est que Tencent a fourni un package de recherche et une comparaison visuelle opportune. Un classement plus large nécessite une évaluation conçue pour les systèmes et les capacités effectivement comparés.

La reproductibilité dépend de la communication des cas délicats

Les matériaux ouverts créent la possibilité de vérification ; une reproduction indépendante exige des décisions transparentes sur les paramètres, la sélection et les échecs.

La question sceptique la plus forte est de savoir si des équipes externes peuvent obtenir un comportement comparable sans s’appuyer sur une préparation non divulguée. Cette question s’applique même lorsque le modèle, le code et les entrées d’évaluation sont disponibles.

Une reproduction peut différer pour des raisons compréhensibles. Les changements logiciels, les limites matérielles et l’interprétation des prompts peuvent affecter une expérience. La réponse doit être de documenter ces différences et d’en évaluer l’importance.

Les informations de version sont particulièrement utiles lorsqu’un projet évolue rapidement. Un résultat renvoie aux artefacts utilisés au moment des tests. Sans ce lien, les lecteurs ultérieurs peuvent avoir du mal à déterminer s’ils comparent des systèmes équivalents.

La gestion des prompts mérite le même soin. Une courte demande utilisateur et une instruction structurée plus développée peuvent imposer des exigences différentes à un modèle. Un évaluateur doit expliquer quelle représentation de l’entrée chaque système a reçue et pourquoi.

La sélection est une autre source d’ambiguïté. Un résultat publié doit préciser s’il représente une première tentative, une exécution répétée ou une sortie choisie parmi plusieurs alternatives. Autrement, les lecteurs ne peuvent pas estimer l’effort nécessaire pour produire l’exemple.

Les échecs apportent également des informations que les séquences réussies omettent. Un système peut gérer une instruction initiale, mais perdre la continuité après un changement de point de vue. Un autre peut préserver l’environnement tout en répondant mal à une action demandée.

Ces schémas comptent, car les applications ont besoin d’une récupération prévisible. Un développeur peut parfois redéfinir une interaction autour d’une limitation connue. Un schéma d’échec inexpliqué est plus difficile à intégrer.

La faiblesse de mémoire reconnue par l’article constitue donc une information utile. Elle attire l’attention sur un comportement qui mérite d’être testé avant toute adoption. Les chercheurs devraient examiner où cette limitation apparaît et à quel point elle affecte leurs tâches prévues.

La mémoire nécessite également une interprétation spécifique à la tâche. Un cinéaste explorant des compositions alternatives peut accepter certaines variations de l’environnement. Une application qui repose sur le retour à un lieu inchangé impose une exigence plus stricte.

La même prudence s’applique aux usages potentiels de simulation. Une séquence d’apparence plausible ne constitue pas une preuve suffisante qu’un système prédit correctement un processus physique. Toute application exigeant cette précision doit être validée par rapport à des observations externes appropriées.

Il s’agit de limites analytiques, plutôt que d’affirmations selon lesquelles Hy-Nomas aurait échoué dans un déploiement particulier. Les matériaux de recherche publics n’établissent pas tous les cas d’usage possibles. Les équipes applicatives restent responsables de définir le comportement dont elles ont besoin et de le tester directement.

L’évaluation humaine introduit un autre ensemble de décisions. Les évaluateurs ont besoin de définitions cohérentes de la réussite et d’un processus de traitement des résultats ambigus. Les lecteurs bénéficient d’une évaluation qui explique comment les désaccords ont été résolus.

Un score agrégé unique peut masquer ces distinctions. L’exécution des instructions, la réponse au point de vue et la continuité de la scène peuvent échouer indépendamment. Les communiquer séparément fournit aux développeurs davantage d’informations sur l’adéquation probable.

Pour les équipes organisant des expériences, une base de connaissances consultable peut relier les documents techniques aux observations de test. L’objectif est la traçabilité : chaque conclusion doit remonter à la configuration, à l’entrée et à la sortie qui l’étayent.

Cette discipline rend la critique plus productive. Au lieu d’affirmer qu’un modèle se souvient ou oublie, les évaluateurs peuvent décrire les circonstances. Au lieu de considérer une vidéo sélectionnée comme typique, ils peuvent indiquer la fréquence d’apparition d’un comportement similaire.

Le rapport Hy-Nomas fournit de la matière à cette discussion. L’étape suivante appartient en partie aux chercheurs et aux développeurs extérieurs à Tencent, dont les résultats peuvent renforcer, nuancer ou contester l’interprétation de l’équipe.

Surveillez les résultats indépendants, les protocoles de comparaison et les déploiements utilisables

Les prochaines preuves significatives viendront d’expériences répétées, de comparaisons explicitement harmonisées et d’applications qui exposent leurs conditions de fonctionnement.

Le premier signal à surveiller est une reproduction indépendante utilisant des versions, des entrées et des décisions d’évaluation documentées. Une publication utile relierait ses conclusions aux cas testés et divulguerait les exclusions. Elle expliquerait également les écarts substantiels par rapport à la procédure de Tencent.

Un accord avec les conclusions publiées renforcerait la confiance dans cette publication en tant que référence de recherche. Des résultats divergents seraient informatifs si les auteurs identifient des causes probables. Un classement inexpliqué apporterait beaucoup moins.

Une attention particulière doit être accordée à la distinction signalée entre les atouts d’interaction et les limites de mémoire spatiale. Des résultats externes préservant ce schéma soutiendraient le compte rendu plus nuancé de l’article. Des schémas différents suggéreraient que les choix d’implémentation ou d’évaluation méritent un examen plus attentif.

Le deuxième signal est une comparaison directe avec Genie 4 assortie d’un protocole explicite. Une telle évaluation doit identifier les conditions d’accès et les capacités qui peuvent réellement être harmonisées. Des thèmes visuels communs ne suffisent pas.

Une comparaison utile divulguerait les prompts, la séquence d’interaction, le processus de sélection des sorties et les mesures temporelles pertinentes. Elle devrait également distinguer le comportement visuel de l’audio et des autres capacités qui ne relèvent pas d’un test donné.

Si une comparaison transparente conclut à des performances similaires sur des tâches communes, l’implication concurrentielle devient plus concrète. Si des différences importantes apparaissent, les développeurs disposent d’une meilleure base pour choisir une approche. Dans les deux cas, cela vaut mieux que d’interpréter une ressemblance promotionnelle comme un classement.

Le troisième signal est un déploiement qui reste utile au-delà d’une courte démonstration. Les preuves pertinentes comprennent la réactivité, la continuité, la récupération après des commandes échouées et les ressources nécessaires pour maintenir l’expérience.

Pour une application créative, cela pourrait signifier une session documentée montrant comment les utilisateurs révisent une scène et se remettent de résultats indésirables. Pour la recherche, cela pourrait signifier un environnement de test reproductible qui conserve suffisamment d’informations pour permettre l’examen par d’autres personnes.

Ces exemples décrivent des preuves qu’il vaut la peine de rechercher, et non des déploiements déjà établis par cette publication. Les affirmations d’adoption doivent rester liées à un usage observable. Les annonces d’intégration constituent des pistes encourageantes, mais leur valeur pratique dépend de ce que les utilisateurs peuvent accomplir.

Une démo dans le navigateur peut aider les lecteurs à se faire une première impression. Elle ne garantit pas qu’un déploiement local se comportera de manière identique, ni que les conditions d’accès resteront constantes. La disponibilité et le temps d’attente doivent être vérifiés lorsqu’une personne essaie réellement le service.

Au cours des prochains mois, la discussion la plus utile reliera ces signaux. Les tests indépendants expliquent le comportement. Les comparaisons harmonisées établissent les forces relatives. Les applications documentées montrent si ces forces comptent hors du cadre d’évaluation.

Pour l’instant, considérez le rapport Hy-Nomas comme le point de départ d’une enquête délimitée. Choisissez un flux de travail qui compte pour vous, puis identifiez les commandes, les exigences de continuité et le temps d’attente qu’il peut tolérer. Conservez les entrées d’origine et les sorties complètes, y compris les échecs. Comparez ces observations aux affirmations publiées avant de tirer une conclusion plus large. Si vous explorez la démo, poursuivez au-delà de la scène d’ouverture attrayante et revenez à un élément que le système a déjà montré. Si vous exécutez le modèle publié, consignez la configuration avec vos conclusions. La question utile est précise : ce système préserve-t-il le comportement dont votre application a besoin lorsque l’instruction suivante arrive ?