Realtime-Venus : le 9B full-duplex d’Ant Group livré sans lancement

Le 12 septembre 2026, un rapport technique a été mis en ligne sur arXiv décrivant Realtime-Venus, un système d’interaction en duplex intégral construit à partir de deux modèles 9B entraînés séparément — Realtime-Venus-Omni pour l’interaction audio-visuelle et Realtime-Venus-Audio pour l’interaction vocale — attribué à l’équipe Venus d’Ant Group en collaboration avec l’université Tsinghua. En quelques jours, un dépôt Apache-2.0 sous inclusionAI/Realtime-Venus sur Hugging Face contenait les deux checkpoints sous forme de safetensors BF16 téléchargeables, aux côtés d’une page de projet et d’un dépôt GitHub compagnon. Ce qui n’est pas apparu est la partie qui mérite l’attention : aucun post de lancement, aucune page produit, aucune API, aucune grille tarifaire, et rien sur les propres plateformes d’Ant Group annonçant que tout cela existe. C’est une sortie qui a tout livré sauf l’annonce, ce qui fait que séparer les faits établis des affirmations est tout le travail.

Qu'y a-t-il réellement sur le disque

Le dépôt n'est pas un stub. Il contient deux répertoires de modèles, chacun avec des poids safetensors fragmentés, une configuration, et le code personnalisé Hugging Face Transformers que la fiche vous invite à charger avec trust_remote_code=True. Il y a un fichier requirements, un dossier assets contenant les ressources token-to-waveform et une voix de référence, ainsi qu'une licence Apache-2.0 à la racine. La fiche documente l'installation pour Python 3.10 avec CUDA et FFmpeg, ainsi qu'un miroir ModelScope et un chemin de téléchargement Hugging Face. Les poids sont réels, le code est là, et rien ne vous empêche de le télécharger dès aujourd'hui.

Deux absences sont aussi instructives que le contenu. La première, c'est que le dépôt indique clairement qu'il n'est déployé par aucun fournisseur d'inférence — pas de point de terminaison hébergé, pas d'option serverless, aucune plateforme tierce ne le prend en charge. La seconde, c'est que les téléchargements ne sont pas du tout suivis, ce qui signifie qu'aucun signal public ne permet de savoir combien de personnes l'ont récupéré. Sur Hugging Face, un modèle peut sembler adopté ou ignoré ; celui-ci est illisible de cette façon.

Les deux points de contrôle, et ce qui les sépare

Tous deux sont des 9B, tous deux partagent un backbone de streaming, et la différence entre eux réside dans ce qu’ils peuvent percevoir.

• Realtime-Venus-Omni — le point de contrôle audiovisuel. Un encodeur visuel SigLIP2 pour les trames en continu, un encodeur audio Whisper-Medium et un socle linguistique Qwen3-8B. Accepte des vidéos ou des images, de l’audio et du texte ; renvoie du texte et, éventuellement, une forme d’onde vocale.

• Realtime-Venus-Audio — le même réseau principal, avec la vision désactivée au chargement. Entrée audio et texte, sortie texte et parole. Il existe pour le cas où la caméra n’est pas pertinente et où vous voulez l’empreinte mémoire plus réduite et le chemin plus simple.

• Spécification partagée — contexte de 40 960 tokens des deux côtés, poids BF16 des deux côtés, parole générée sous forme de tokens S3 discrets décodés par un décodeur de flow matching en continu plutôt que par un modèle de synthèse vocale distinct greffé à la fin.

• Filiation — la fiche modèle indique que le checkpoint Omni est adapté de MiniCPM-o 4.5, le modèle omni-modal 9B qu'OpenBMB a publié en open source plus tôt en 2026. Ce n'est pas une note de bas de page. Cela signifie que la contribution d'Ant Group réside dans le post-entraînement, le runtime et la conception de la délégation superposés au socle de streaming de quelqu'un d'autre, ce qui est une affirmation différente et plus spécifique que « un nouveau modèle omni 9B ».

La seule idée véritablement nouvelle : la délégation en tant qu'événement de flux de première classe

Tout système full-duplex en 2026 doit résoudre la même contradiction. Le contrôle de la conversation fonctionne à une granularité allant de la milliseconde à la seconde. Les appels d’outils, la récupération et le raisonnement complexe prennent de quelques secondes à plusieurs dizaines de secondes. Un modèle qui s’arrête pour réfléchir cesse d’être full-duplex ; un modèle qui ne s’arrête jamais ne peut pas utiliser d’outil.

Realtime-Venus répond avec un moteur d'exécution à double boucle. La boucle d'interaction fonctionne par segments fixes d'une seconde, ingérant en continu des caractéristiques audio et vidéo, mettant à jour l'état de la conversation et décidant d'écouter ou de parler, tout en diffusant en continu du texte et de la parole alignée. Elle ne se met pas en pause lorsque des tâches d'arrière-plan sont en cours. La seconde boucle est un ordonnanceur que l'article appelle Realtime-Venus-Harness : lorsque le frontend détermine qu'une tâche dépasse ce qu'il peut faire en ligne, il émet une délégation asynchrone via des marqueurs privés intégrés dans sa propre séquence cachée, et le Harness exécute la tâche en arrière-plan et réintègre le résultat dans le dialogue en cours.

Le détail qui fait que ce n’est pas qu’un schéma, c’est ce que l’article appelle la capture causale de tâche — la tâche déléguée est exécutée sur un instantané isolé de l’état de la conversation, de sorte qu’une tâche d’arrière-plan de longue durée ne puisse pas être corrompue par la conversation qui avance pendant son exécution. C’est le mode de défaillance qui fait échouer en pratique la plupart des conceptions « déléguer et continuer à parler », et c’est la chose la plus intéressante du rapport.

Le harnais n'est pas dans les poids. Il réside dans le dépôt GitHub en tant que composant séparé, ce qui signifie que la partie qui rend l'architecture distinctive est celle que vous devez assembler et à laquelle vous devez faire confiance vous-même.

Les chiffres, et exactement à qui ils appartiennent

Chacun des chiffres ci-dessous provient du rapport technique et de la fiche modèle. Aucun n’a été reproduit par qui que ce soit en dehors des auteurs, aucun tiers n’a publié d’évaluation, et il n’existe aucune entrée de classement permettant de les vérifier. Considérez-les comme les mesures des auteurs eux-mêmes.

• Benchmarks vidéo, Realtime-Venus-Omni — meilleur score sur six des huit benchmarks utilisés par le rapport, notamment StreamingBench 70.2, OVO-Bench 64.7 et Daily-Omni 81.3.

• Benchmarks audio, Realtime-Venus-Audio — MMAU 78,0, MMAU-Pro 63,2, Llama Questions 83,8, Speech CMMLU 67,8, et un score VoiceBench AlpacaEval de 4,81 que le rapport décrit comme égalant le meilleur chiffre de comparaison.

• Full-Duplex-Bench v1.5 — réponse à 75 % des interruptions de l’utilisateur, avec des taux de continuation de 97 % en présence de canaux de retour, de 88 % en présence de paroles adressées à autrui et de 86 % en présence de paroles d’arrière-plan. Le rapport indique que cela dépasse Gemini 3.1 Live et GPT-4o sur les trois métriques de continuation.

Le chiffre de Daily-Omni est celui sur lequel il vaut la peine de s'arrêter. MiniCPM-o 4.5, le modèle dont ce checkpoint est une adaptation, annonce 80,2 sur le même benchmark. Realtime-Venus-Omni annonce 81,3. Si les deux chiffres tiennent, l'amélioration issue d'un vaste effort de post-entraînement et d'exécution représente environ un point sur un benchmark où le modèle de base était déjà solide — un résultat réaliste pour ce type de travail, et une histoire bien moins spectaculaire que le titre « meilleur sur six des huit ».

Ce qui n'est pas établi

La liste des questions ouvertes est plus longue que celle des questions réglées, et c’est là l’état honnête d’un modèle âgé de six jours.

• Aucune évaluation indépendante n'existe. Ni un classement d'arène, ni une reproduction par un tiers, ni un seul groupe extérieur ayant publié un chiffre.

• Aucun chiffre de latence en millisecondes. Le rapport décrit une cadence d'interaction d'une seconde et la fiche documente des appels de streaming par seconde, mais aucun temps jusqu'au premier son n'est publié, alors que c'est la métrique sur laquelle cette catégorie est réellement achetée.

• Ni API ni prix, et aucune déclaration indiquant que l'un ou l'autre est à venir. On ne sait vraiment pas s'il s'agit d'un produit en attente ou d'un artefact de recherche qui restera un simple téléchargement.

• Aucune intention déclarée de la part du fournisseur. L’absence d’annonce ne prouve pas une stratégie de lancement discret ; elle est aussi compatible avec un dépôt publié pour un article et rien de plus.

• Aucune preuve issue de la production pour le harnais. C'est le composant porteur de l'architecture et le moins documenté.

Pourquoi la voie tranquille continue de se produire

C'est la deuxième fois cette année que les travaux d'Ant Group sur les modèles se font connaître du public par un dépôt plutôt que par un lancement. UI-Venus-2-9B, l'agent GUI du laboratoire, est apparu sur Hugging Face fin août 2026, sans article, sans page de projet et sans annonce — et a depuis été suivi d'un rapport. Realtime-Venus est arrivé dans l'ordre inverse : rapport d'abord, dépôt en parallèle, annonce toujours retenue.

Ce schéma n'est pas propre à Ant Group. Les laboratoires chinois en particulier livrent au monde des artefacts de recherche et des déploiements grand public tout en reportant à plus tard l'annonce destinée aux développeurs, voire en l'omettant. Pour quiconque suit le domaine, c'est peu pratique, car le signal habituel — un billet de lancement, une grille tarifaire, un site de documentation — est précisément ce qui manque. L'artefact est désormais l'annonce, et le lire attentivement est le seul moyen de savoir ce qui a été livré.

Si vous vouliez l'exécuter

La carte est inhabituellement pratique pour une version aussi récente. Le chargement est standard : AutoModel.from_pretrained sur le répertoire de checkpoints local avec le code distant approuvé, l’attention SDPA et bfloat16. Le streaming full-duplex est activé par un seul appel qui bascule le modèle en mode duplex, après quoi la boucle documentée consiste en une seconde de streaming_prefill suivie de streaming_generate, répétée. La mémoire longue vidéo est activée avec un paramètre de minutes de mémoire réglé sur quarante et est décrite comme sans entraînement, ce qui est notable pour une capacité qui nécessite généralement un fine-tuning. Deux mises en garde sont documentées plutôt que découvertes : un plafond d’images qui tronque silencieusement les vidéos longues à moins qu’une constante ne soit augmentée avant l’importation des utilitaires, et une exigence de police CJK pour les sous-titres non latins rendus dans une vidéo duplex.

Ce que la carte ne vous apporte pas, c’est un plancher matériel. Un modèle 9B en BF16 représente environ dix-huit gigaoctets de poids avant toute mémoire d’activation, ce qui place l’inférence duplex en temps réel sur un GPU sérieux et hors de portée du déploiement sur ordinateur portable pour lequel la famille MiniCPM-o dont il est issu a été en partie conçue.

Il y a ici une couture qui mérite d'être nommée, car c'est là qu'un routeur trouve réellement sa place. Realtime-Venus délègue son travail difficile — la récupération, le raisonnement complexe, les appels à des API métier — à un modèle en arrière-plan. Ce segment délégué est de l'inférence de texte ordinaire, et c'est lui qui détermine si votre front-end conversationnel est utile ou simplement fluide. OrcaRouter ne contient rien de Realtime-Venus ; la couche duplex ici est un téléchargement auto-hébergé et nous ne la servons pas. Le raisonnement qu'il délègue est la partie que nous couvrons : près de 200 modèles derrière une seule clé, au prix catalogue du fournisseur, sans marge, un basculement automatique lorsqu'un amont passe un mauvais moment, un DSL de routage qui compose plusieurs modèles en un seul appel, et la fusion de modèles pour les cas où le jugement d'un seul modèle ne suffit pas. Le marqueur de délégation relève de la décision du front-end ; quel modèle y répond est un choix de configuration, et garder ce choix en dehors des poids est ce qui vous permet de le modifier sans réentraîner quoi que ce soit.

Qu'est-ce qui réglerait ça ?

Trois choses feraient passer Realtime-Venus d’un article avec des poids à un modèle que tout le monde peut évaluer. Un groupe indépendant reproduisant les chiffres de continuation de Full-Duplex-Bench, car 97 % dans les backchannels est un chiffre extraordinaire et les chiffres extraordinaires ont besoin d’un second lecteur. Un chiffre de latence publié, car les systèmes full-duplex vivent ou meurent sur le time-to-first-audio et celui-ci n’a pas annoncé d’objectif. Et une documentation pour le harness, car la conception de délégation asynchrone est la seule partie de cette version qui soit véritablement nouvelle, et pour l’instant c’est la partie dont on peut lire la description mais qu’il n’est pas facile d’adopter.

Jusque-là, la description exacte est restreinte et peu enthousiasmante, et c’est précisément pourquoi elle vaut la peine d’être couchée par écrit : une véritable version Apache-2.0 de deux checkpoints full-duplex 9B, construite sur un socle ouvert, avec de solides benchmarks auto-déclarés, aucune vérification indépendante, aucune API et aucune annonce. Tout ce qui se trouve au-dessus de cette ligne relève de l’inférence.