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 full-duplex 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 associé. Ce qui n'est pas apparu, c'est la partie qui mérite l'attention : aucun billet 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 publication qui a tout livré sauf l'annonce, ce qui fait de la séparation entre les faits établis et les affirmations tout le travail.

Que y a-t-il réellement sur le disque ?

Le dépôt n'est pas un simple squelette. Il contient deux répertoires de modèles, chacun avec des poids safetensors fragmentés, un fichier de configuration, et le code personnalisé Hugging Face Transformers que la fiche vous invite à charger avec trust_remote_code=True. On y trouve 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 bien réels, le code est présent, 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 suivis du tout, ce qui signifie qu'il n'existe aucun signal public indiquant combien de personnes l'ont récupéré. Sur Hugging Face, un modèle peut sembler adopté ou ignoré ; celui-ci est illisible de ce point de vue.

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

Tous deux sont des modèles 9B, tous deux partagent une colonne vertébrale de streaming, et ce qui les distingue, c'est ce qu'ils sont capables de percevoir.

• Realtime-Venus-Omni — le checkpoint audio-visuel. Un encodeur visuel SigLIP2 pour les frames en streaming, un encodeur audio Whisper-Medium et un backbone de langage Qwen3-8B. Accepte de la vidéo ou des images, de l'audio et du texte ; renvoie du texte et, éventuellement, une forme d'onde vocale.

• Realtime-Venus-Audio — la même ossature, avec la vision désactivée au chargement. Audio et texte en entrée, texte et parole en sortie. Il existe pour le cas où la caméra n’est pas pertinente et où vous voulez une empreinte mémoire plus faible et un chemin plus simple.

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

• Filiation — la fiche de modèle indique que le checkpoint Omni est adapté de MiniCPM-o 4.5, le modèle omni-modal 9B qu’OpenBMB a rendu 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 est le post-entraînement, le runtime et la conception de la délégation superposés au backbone de streaming d’un tiers, 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 comme événement de flux de première classe

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

Realtime-Venus répond avec un runtime à double boucle. La boucle d'interaction s'exécute par tranches 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 du texte et de la parole alignée. Elle ne s'interrompt pas 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 estime 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 le fait que la conversation continue d’avancer pendant son exécution. C’est le mode de défaillance qui fait que la plupart des conceptions « déléguer et continuer à parler » s’effondrent en pratique, et c’est l’élément le plus intéressant du rapport.

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

Les chiffres, et exactement à qui ils appartiennent

Chaque donnée ci-dessous provient du rapport technique et de la fiche modèle. Aucune n’a été reproduite 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 à laquelle la confronter. 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 dans 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 % sous backchannels, de 88 % sous paroles adressées à autrui et de 86 % sous paroles en 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 à partir duquel ce checkpoint a été adapté, rapporte 80,2 sur le même benchmark. Realtime-Venus-Omni rapporte 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à performant — ce qui est un résultat réaliste pour ce type de travail et une histoire bien moins spectaculaire que le titre « meilleur sur six des huit ».

Qu'est-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 vieux de six jours.

• Il n’existe aucune évaluation indépendante. Pas un classement d’arène, pas une reproduction par un tiers, pas 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 chiffre de délai avant le premier son n'est publié, alors que c'est la métrique sur laquelle cette catégorie est réellement achetée.

• Aucune API, aucun prix, et aucune déclaration indiquant que l'un ou l'autre est à venir. On ne sait véritablement 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 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 de production pour le harnais. C'est le composant porteur de l'architecture et le moins documenté.

Pourquoi l'itinéraire silencieux ne cesse de se produire

C'est la deuxième fois cette année que le travail d'Ant Group sur les modèles arrive jusqu'au public via 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 : d'abord le rapport, le dépôt en parallèle, l'annonce toujours pas faite.

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 laissant l'annonce destinée aux développeurs pour plus tard, ou en l'omettant. Pour quiconque suit le domaine, c'est gênant, car le signal habituel — un article de lancement, une grille tarifaire, un site de documentation — est exactement la partie 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 souhaitiez l'exécuter

La carte est étonnamment pratique pour une version aussi récente. Le chargement est standard : AutoModel.from_pretrained sur le répertoire de point de contrôle local avec le code distant approuvé, l'attention SDPA et le format bfloat16. Le streaming full-duplex est lancé 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 à l'aide d'un paramètre memory-minutes défini sur quarante et est décrite comme sans entraînement, ce qui est notable pour une capacité qui nécessite habituellement un affinage. Deux mises en garde sont documentées plutôt que découvertes : un plafond de frames qui tronque silencieusement les longues vidéos à 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 la vidéo duplex.

Ce que la carte ne vous donne pas, c'est un seuil matériel. Un modèle 9B en BF16 représente environ dix-huit gigaoctets de poids avant toute mémoire d'activation, ce qui réserve l'inférence duplex en temps réel à un GPU sérieux et la rend inaccessible au 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 jointure 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 — récupération, raisonnement complexe, appels aux 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 le segment qui décide si votre interface conversationnelle 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'elle 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 service 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 frontend ; 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 changer sans rien réentraîner.

Qu'est-ce qui réglerait la question ?

Trois choses feraient passer Realtime-Venus du statut d’article accompagné de poids à celui de modèle que n’importe qui peut évaluer. Un groupe indépendant qui reproduit les chiffres de continuation de Full-Duplex-Bench, car 97 % avec backchannels est un chiffre extraordinaire, et les chiffres extraordinaires exigent un second lecteur. Un chiffre de latence publié, car les systèmes full-duplex vivent ou meurent selon le délai avant le premier son, et celui-ci n’a annoncé aucun objectif. Et une documentation pour le harnais, car la conception de délégation asynchrone est la seule partie de cette version qui soit réellement nouvelle, et c’est aujourd’hui la partie dont on peut lire la description mais qu’il n’est pas facile d’adopter.

Jusque-là, la description exacte est étroite et peu enthousiasmante, et c’est précisément pourquoi elle mérite d’être consignée : une véritable release Apache-2.0 de deux checkpoints full-duplex 9B, construits sur un backbone 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.