Realtime-Venus vs SeedRealtime : deux façons opposées d'être indisponible

Realtime-Venus et SeedRealtime sont les deux moitiés d’une même histoire de 2026, et ils échouent à des tests opposés. SeedRealtime est le modèle duplex intégral audio-visuel natif de ByteDance, activé gratuitement dans l’application Doubao le 5 août 2026, atteignant un public que son créateur décrit comme se comptant en centaines de millions — sans API, sans identifiant de modèle, sans prix et sans objectif de latence. Realtime-Venus est une paire de checkpoints 9B de la Venus Team d’Ant Group et de l’Université Tsinghua, publiés le 12 septembre 2026 sous Apache-2.0 avec un rapport technique et sans annonce, résidant dans un dépôt que tout ingénieur peut télécharger et que presque aucun ne peut réalistement déployer. L’un, vous ne pouvez pas l’appeler. L’autre, vous pouvez le télécharger puis découvrir que vous n’avez rien sur quoi l’appeler. Les deux sont véritablement à la frontière de la même capacité, et ni l’un ni l’autre ne dispose d’un benchmark que quiconque en dehors de ses propres auteurs a reproduit.

Deux variantes de « vous ne pouvez pas l'avoir »

Il convient d'être précis, car l'expression « non disponible » masque une véritable différence.

SeedRealtime est indisponible de la même manière qu’un produit grand public peut l’être : il existe, il fonctionne, il a des utilisateurs, et la porte est tout simplement fermée aux développeurs. Il n’y a pas d’API, pas de grille tarifaire, pas de portail de documentation, et aucun calendrier annoncé pour en proposer une. La voie de commercialisation de ByteDance a été l’application, et l’application a suffi. Ce que vous obtenez en tant que développeur, c’est une démo que vous pouvez découvrir sans pouvoir l’intégrer.

Realtime-Venus est indisponible de la manière dont un artefact de recherche est indisponible : les poids sont publics, la licence est permissive, le code est là, et personne ne l’exécute. Le dépôt n’est déployé par aucun fournisseur d’inférence, et les téléchargements ne sont pas du tout suivis, il n’existe donc aucun signal public d’adoption, dans un sens comme dans l’autre. Il est disponible dans le sens qui compte pour un chercheur et indisponible dans le sens qui compte pour un chef de produit.

Pris ensemble, ils posent la question sur laquelle toute cette catégorie est actuellement bloquée : les modèles qui fonctionnent sont derrière des applications grand public, et les modèles que vous pouvez exécuter ne sont en production nulle part.

Les deux sont au niveau qui distingue réellement 2026

Une manière utile d’appréhender le domaine du temps réel consiste à distinguer trois niveaux. Le premier est la voix semi-duplex avec la vision greffée dessus — des assistants en mode tour par tour, capables de voir mais qui prennent encore la parole chacun à son tour. Le deuxième est l’audio full-duplex, qui écoute et parle en même temps sans caméra : le Seeduplex propre à ByteDance, GPT-Live d’OpenAI, Grok Voice Think Fast 2.0 de xAI. Le troisième est l’audiovisuel full-duplex, où la perception et l’expression couvrent en continu la vidéo et l’audio.

SeedRealtime est le premier modèle du troisième palier à atteindre un déploiement commercial à grande échelle. Realtime-Venus est un nouveau venu à poids ouverts au même palier — vidéo via un encodeur SigLIP2, audio via Whisper-Medium, un socle Qwen3-8B, et une boucle d'interaction d'une seconde qui ne cesse jamais de percevoir. Sa fiche de modèle indique qu'il est adapté de MiniCPM-o 4.5, le modèle omni-modal d'OpenBMB sorti plus tôt en 2026, ce qui place la contribution d'Ant Group au niveau du post-entraînement et du runtime plutôt que de l'architecture de base.

Ce qu’ils ont en commun, et ce qui les place un cran au-dessus des systèmes uniquement audio, c’est qu’aucun des deux ne s’arrête pour regarder. La perception visuelle continue pendant la prise de parole est une capacité véritablement différente de la description d’une seule image, et les deux modèles ont été conçus autour de cette capacité.

Ce que valent les chiffres de chacun

Aucun des deux modèles ne dispose d'un benchmark tiers. Les preuves ne sont cependant pas équivalentes, et la différence compte.

• SeedRealtime ne publie absolument aucun benchmark. Ce que ByteDance propose, c’est l’affirmation selon laquelle les problèmes de rythme de dialogue — couper la parole à l’utilisateur, répondre en retard, être déclenché par le bruit d’un inconnu — diminuent environ de moitié par rapport à un système en cascade, d’après des évaluations humaines de bout en bout. Les données sous-jacentes ne sont pas publiées.

• Les chiffres du prédécesseur ont la même allure. Seeduplex, le modèle audio uniquement que ByteDance a déployé dans Doubao en avril 2026, aurait permis de diviser par deux les taux de fausses réponses et de fausses interruptions, de réduire la latence de point de terminaison d’environ 250 millisecondes, de diminuer les réponses prématurées de 40 % et d’augmenter la satisfaction des appels de 8,34 points lors d’un test A/B à grande échelle. Tous les chiffres sont rapportés par le fournisseur.

• Realtime-Venus publie un tableau. Son rapport revendique les meilleurs scores sur six des huit benchmarks vidéo, notamment StreamingBench 70.2, OVO-Bench 64.7 et Daily-Omni 81.3, et arrive en tête sur MMAU 78.0, MMAU-Pro 63.2, Llama Questions 83.8 et Speech CMMLU 67.8 pour le checkpoint audio.

• Ni l’un ni l’autre n’a été reproduit. Un tableau publié que personne n’a vérifié et un test A/B non publié que personne ne peut vérifier sont deux types distincts d’éléments non vérifiés. Aucun des deux ne constitue une preuve sur laquelle fonder une décision d’approvisionnement.

La seule comparaison qui vaille la peine d'être faite dans les chiffres de Realtime-Venus est celle avec son propre modèle de base. MiniCPM-o 4.5 affiche 80,2 sur Daily-Omni ; Realtime-Venus-Omni affiche 81,3. Un gain d'un point par rapport au modèle dont il a été adapté, sur un benchmark que ce modèle maîtrisait déjà, est un résultat plausible pour un effort de post-entraînement et d'exécution — et une affirmation bien plus modeste que ne le laisse paraître, lue isolément, la formule « meilleur sur six des huit ».

Le problème de l’alternance des tours de parole, là où réside le full-duplex

Le full-duplex n'est pas une caractéristique de latence. C'est un ensemble de comportements : savoir quand une pause signifie « je réfléchis » plutôt que « j'ai fini », distinguer la conversation d'un tiers de celle de la personne qui vous parle, et rester silencieux pendant un backchannel au lieu de prendre « mm-hm » pour une interruption.

L'approche de SeedRealtime consiste à modéliser nativement l'état conversationnel et à supprimer entièrement le détecteur externe d'activité vocale, de sorte que la gestion des tours de parole soit un comportement appris à l'intérieur du réseau plutôt qu'un seuil appliqué à un flux audio. C'est le même engagement architectural que prend Realtime-Venus, et les deux se positionnent contre les systèmes en cascade qui nécessitent un composant distinct pour décider qui parle.

Là où les preuves diffèrent, c'est que l'affirmation de SeedRealtime porte sur un déploiement à grande échelle — des centaines de millions d'utilisateurs, de vraies salles, du vrai bruit — tandis que celle de Realtime-Venus porte sur un benchmark. Les résultats du Full-Duplex-Bench v1.5 pour Realtime-Venus-Audio — 75 % de réponse aux interruptions, 97 % de continuation sous backchannels, 88 % sous other-directed speech et 86 % sous background speech, dépassant Gemini 3.1 Live et GPT-4o sur la continuation — sont les chiffres les plus directement pertinents que l'un ou l'autre modèle ait publiés pour ce problème. Ils sont aussi entièrement auto-déclarés, et 97 % de continuation sous backchannels est un chiffre frappant qui mérite une seconde lecture avant que quiconque ne le cite comme un fait.

Là où chacun laisse un constructeur

L'écart pratique ne réside pas dans la qualité, mais dans la forme de l'offre.

• SeedRealtime — vous pouvez l’expérimenter gratuitement dans Doubao et ne jamais l’intégrer. Il n’existe aucun chemin de « c’est impressionnant » à « c’est dans mon produit ».

• Realtime-Venus — vous pouvez le télécharger, l'affiner, l'exécuter en environnement isolé et inspecter chaque couche. Le coût : deux checkpoints 9B en BF16, soit environ dix-huit gigaoctets de poids chacun, plus une boucle de streaming continue à la seconde, ce qui signifie un nœud GPU facturé, que quelqu'un l'appelle ou non.

• Aucun des deux ne propose d’option hébergée. Aucun des deux ne peut être testé avec une clé et un après-midi.

Ce dernier point explique pourquoi les deux modèles sont plus utiles associés qu’opposés. À eux deux, ils démontrent que les deux moitiés du problème sont résolues — la capacité fonctionne, et les poids peuvent être publiés — tout en montrant que personne ne les a encore réunis en quelque chose qu’un développeur peut réellement appeler.

Il existe une solution de contournement à laquelle beaucoup d'équipes auront recours, et il vaut la peine d'être clair sur ce qu'elle couvre et ne couvre pas. Si vous ne pouvez pas obtenir la couche vocale, vous pouvez tout de même construire la partie qui réfléchit. Realtime-Venus délègue son travail coûteux — récupération, raisonnement difficile, appels d'API métier — à un harnais d'arrière-plan via des marqueurs de délégation asynchrones, et cette branche déléguée est une inférence textuelle ordinaire. OrcaRouter ne prend en charge ni Realtime-Venus ni SeedRealtime ; les deux couches duplex sont en dehors de ce que nous servons, et nous n'hébergeons ni l'une ni l'autre. Près de 200 modèles de texte derrière une seule clé, au prix catalogue du fournisseur et sans majoration constituent la moitié de l'architecture que nous couvrons, avec un basculement automatique pour qu'une tâche d'arrière-plan n'échoue pas parce qu'un service en amont a passé une mauvaise après-midi, un DSL de routage pour composer plusieurs modèles en un seul appel, et une fusion de modèles lorsque le jugement d'un seul modèle ne suffit pas. Ce n'est pas la partie difficile de ces systèmes. C'est la partie que l'on peut réellement acheter.

Qu'est-ce qui changerait cette comparaison

Trois développements permettraient de trancher, et aucun ne s'est encore produit. Un benchmark indépendant de Realtime-Venus, car un tableau sans second lecteur est une affirmation et non un résultat. Une API pour SeedRealtime, car le modèle qui dispose des preuves de déploiement les plus solides est actuellement celui que personne ne peut utiliser. Et un chiffre de latence publié par l'un ou l'autre — le temps jusqu'au premier audio est la métrique sur laquelle cette catégorie s'achète, et à l'heure où ces lignes sont écrites, aucun des deux modèles n'en a annoncé.

D'ici là, le résumé honnête est que SeedRealtime est la preuve que le duplex intégral audio-visuel fonctionne à l'échelle grand public et que Realtime-Venus est la preuve que les poids peuvent être ouverts, et aucun de ces faits ne rapproche un développeur de la livraison d'un produit. Ce n'est une critique ni de l'un ni de l'autre laboratoire. C'est la description d'une catégorie qui a résolu le problème de la recherche, mais pas encore celui de la distribution.