WeVisOne-VL-4B vs UI-Venus-2-9B : l’un renvoie un masque, l’autre renvoie un clic

Confiez la même capture d’écran d’une page de paiement à WeVisOne-VL-4B et à UI-Venus-2-9B, et vous obtenez deux types de réponse différents. Le premier vous donne de la géométrie : une boîte autour de l’icône du panier, un masque de segmentation autour du champ de réduction, un masque alpha qui détoure la photo du produit de son arrière-plan. Le second vous donne un geste : les coordonnées du prochain appui, ainsi que le raisonnement qui l’a produit. L’équipe WeChat Vision de Tencent a publié WeVisOne-VL-4B sur Hugging Face sans annonce et a daté son article technique du 23 octobre 2026 ; UI-Venus-2-9B d’inclusionAI est téléchargeable depuis le 26 août 2026. Ils sont classés sous la même étiquette de modalité et ne sont pas interchangeables.

Cela fait donc de cette comparaison un exercice dont le problème central est inhabituel : les deux modèles n’ont aucun benchmark en commun. Aucun score n’apparaît sur les deux fiches. Aucun n’a été évalué de manière indépendante, aucun n’est déployé par un fournisseur d’inférence, et aucun n’a de prix publié. Ce qui peut être comparé honnêtement, c’est ce que chacun produit, la manière dont chacun a été entraîné à refuser, ce qu’ils coûtent à exécuter et sous quelle licence vous diffuserez — c’est donc ce que fait cet article, et il signale les chiffres rapportés par les fournisseurs comme tels chaque fois qu’un tel chiffre apparaît.

Les deux modèles ne répondent pas à la même question.

WeVisOne-VL-4B est un modèle de perception. Il repose sur un backbone Qwen3-VL et ajoute un décodeur de pixels obligatoire de 9,6 millions de paramètres — mask_decoder.pt, fourni comme second artefact — qui transforme les prédictions de boîtes du modèle de langage en masques d’instance, puis en mattes alpha de pas 1. Les coordonnées sont émises sous forme de jetons dédiés allant de <0> à <1000>, normalisés par rapport à l’image, et un jeton spécial <OBJ> (id 152,678) ferme chaque boîte dans les tâches denses. La liste des tâches de l’article est une liste de géométrie : détection à vocabulaire ouvert, localisation référentielle, comptage, pointage, localisation OCR, segmentation référentielle et alpha matting promptable.

UI-Venus-2-9B est un agent. Il est initialisé à partir de Qwen3.5-9B et entraîné sur une interaction uniquement à partir de captures d’écran, sur cinq familles de tâches — ancrage, CAPTCHA, mobile, web et ordinateur — via un entraînement intermédiaire, un apprentissage par renforcement hors ligne au niveau des étapes et une distillation on-policy multi-enseignants. Sa sortie est une action dans une boucle fermée observer–raisonner–agir, et sa recette vLLM associe --max-model-len 262144 à --reasoning-parser qwen3, car il émet des jetons de raisonnement avant chaque action.

Mettez les caractéristiques côte à côte et la différence est immédiate :

• Ce qui en ressort — des boîtes, des points, des masques et des alpha mattes de WeVisOne-VL-4B ; une action ainsi que sa trace de raisonnement de UI-Venus-2-9B.

• Backbone — Qwen3-VL pour WeVisOne-VL-4B ; Qwen3.5-9B pour UI-Venus-2-9B. Des générations différentes, des familles différentes de stack textuel.

• Taille — 5 B de paramètres indiqués dans le dépôt malgré un nom « 4B », ainsi qu’un décodeur distinct de 9,6 M de paramètres ; 9 B denses pour UI-Venus-2-9B répartis sur quatre fragments BF16, environ 18,8 Go.

• Format des poids — safetensors F32 sur la carte WeVisOne-VL-4B, ce qui est inhabituel à cette taille et rend le téléchargement plus volumineux que ne le suggère le nombre de paramètres ; BF16 pour UI-Venus-2-9B.

• Licence — Apache 2.0 pour WeVisOne-VL-4B ; « en attente de confirmation finale » pour UI-Venus-2-9B.

La conséquence pratique est que vous ne pouvez pas remplacer l’un par l’autre, et tout article qui vous désigne un gagnant répond à une question que vous ne vous posez pas. Un modèle de perception qui renvoie un masque parfait ne peut toujours pas cliquer. Un agent qui clique parfaitement ne peut toujours pas vous fournir le matte que vous vouliez pour le shooting produit.

Là où ils se recoupent véritablement : les deux équipes ont appris à leur modèle à dire non.

C’est la seule décision de conception prise par les deux versions, et c’est la chose la plus intéressante dans cette association. Les modèles de localisation à vocabulaire ouvert échouent d’une manière précise et coûteuse : demandez l’extincteur dans une pièce qui n’en contient aucun, et un modèle qui répond toujours encadrera le radiateur avec assurance. En aval, cela se traduit par un objet halluciné dans votre pipeline d’actifs ou par un appui mal ciblé dans votre boucle d’automatisation.

WeVisOne-VL-4B le gère en renvoyant None, et l'article rapporte le taux de rejet comme une métrique à part entière, aux côtés de l'exactitude. Sur RefCOCOg, le modèle 4B atteint un taux de rejet de 67,4, alors que sa base Qwen3-VL-4B se situe à 18,8. Sur WeRef-Bench, interne à WeChat, il rapporte un rejet de 96,4 contre 61,9 pour le modèle de base, et sur Ref-ZOM, 86,0 contre 0,3 pour UniPixel-7B. Il s'agit de chiffres auto-déclarés provenant d'un article publié aujourd'hui, et les benchmarks de rejet sont en grande partie ceux des auteurs — considérez la direction comme crédible et l'écart exact comme non vérifié.

UI-Venus-2-9B aborde le même problème du côté de l'agent, en héritant de la gamme UI-Venus un grounding conscient du refus : le modèle est entraîné à refuser lorsque l'élément demandé n'est pas à l'écran plutôt qu'à deviner un emplacement plausible. Ses chiffres de grounding — ScreenSpot-Pro 73.0, VenusBench-GD 77.1, OSWorld-G-R 78.5 — sont déclarés par le fournisseur, et la fiche précise explicitement que cela n'élimine pas le risque d'actions nuisibles et recommande une confirmation humaine ainsi que des garde-fous au niveau applicatif. Son tableau de sécurité montre l'effet qu'il revendique : un taux de réussite des attaques de 11.3 % sur OSHarm contre 25.3 % pour la base Qwen3.5-9B, et de 48.8 % sur OSBlind contre 79.4 %.

Ainsi, les deux modèles ont été construits par des équipes qui avaient vu un localiseur mentir, et tous deux ont choisi l’abstention plutôt que la couverture. Si le mode de défaillance de votre application est « confiant mais faux », cette priorité commune compte davantage que le nombre de paramètres.

Les chiffres que la fiche de modèle de Tencent ne montre pas

Toutes les analyses publiées à ce jour sur WeVisOne-VL-4B disent la même chose, à juste titre : la fiche du modèle ne publie aucun benchmark. L’article technique, lui, en publie, et il est paru le 23 octobre 2026, ce qui en fait la partie de l’histoire qui n’a pas encore circulé. Tout cela est auto-déclaré par les auteurs, rien n’a été reproduit indépendamment, et le modèle a un jour — lisez donc ces éléments comme des affirmations ayant une forme, et non comme des résultats établis.

Par rapport à sa propre base Qwen3-VL-4B, les écarts sont suffisamment importants pour rester intéressants même après une forte décote :

• Détection, F1 moyenne zéro-shot COCO — 57,1 pour WeVisOne-VL-4B contre 48,7 pour Qwen3-VL-4B, et 55,3 contre 44,0 sur LVIS.

• Détection, F1 moyenne Dense200 — 71,3 contre 15,2. Ce n'est pas une coquille dans le tableau de l'article ; c'est dans les scènes denses de petits objets que le modèle de base s'effondre.

• Détection référentielle, RefCOCOg val — 80,8 vs 74,1, avec un taux de rejet de 67,4 vs 18,8.

• Comptage, correspondance exacte sur PixMo-Count val — 93,7 vs 69,6 ; sur MixCount val, 42,0 vs 3,5.

• Pointage, PointBench F1 — 71,9 vs 57,1.

• Localisation OCR, F1 moyen sur SROIE — 68,1 contre 40,4, et devant les 58,6 de PP-OCRv5.

• Segmentation référentielle, gIoU sur ReasonSeg val — 71,2, contre 65,0 pour LISA-13B.

• Matting guidé par prompt, MAD sur prompt de boîte AM-2K — 5,0 contre 12,1 pour SAM2-Matting ; sur les prompts référentiels WeRefMat, 9,8 contre 51,9.

Le résultat de matting est celui sur lequel il vaut la peine de s’arrêter, car c’est la capacité qu’aucun autre produit de cette gamme de prix n’offre via un prompt. Demander à un modèle vision-langage « la personne, sous forme de matte alpha » et obtenir une sortie stride-1 qui bat un pipeline de matting SAM2 sur MAD, c’est un produit différent d’une tête de détection à laquelle on a attaché un masque. C’est aussi là que l’article est le moins flatteur pour son propre 4B : sur les prompts de boîtes P3M-500-NP, le modèle 2B obtient 6,6 MAD contre 7,3 pour le 4B, donc la variante plus grande n’est pas uniformément meilleure, et les auteurs l’écrivent.

Ce que mesurent les chiffres d’UI-Venus-2-9B, et pourquoi ils ne seront pas transférables

Placez les deux suites de benchmarks côte à côte et l’incomparabilité cesse d’être un simple détail technique. Les résultats phares d’UI-Venus-2-9B sont tous des taux de réussite en fin d’état dans un environnement : AndroidWorld 80,2, OSWorld-Verified 70,8, WebVoyager 90,8, Online-Mind2Web 74,0, MobileWorld 65,8 avec le budget d’étapes par défaut de la fiche et 75,2 à 100 étapes. Ces chiffres mesurent si une tâche a été menée à terme, ce qui intègre la perception, la planification, la mémoire et la reprise sur erreur en une seule valeur.

Ce qui se rapproche le plus d’un axe commun est le grounding GUI. UI-Venus-2-9B obtient 73,0 sur ScreenSpot-Pro, un benchmark consistant à localiser de petits éléments d’interface dans des captures d’écran haute résolution — et WeVisOne-VL-4B ne rapporte pas ce résultat. WeVisOne-VL-4B publie des résultats de localisation OCR et de pointage dense, et UI-Venus-2-9B ne rapporte pas ces résultats. La position honnête est donc que le nombre le plus utile pour cette comparaison n’existe pas encore : exécuter WeVisOne-VL-4B sur ScreenSpot-Pro vous dirait si un spécialiste de la perception de 5B surpasse un agent de 9B pour trouver un bouton, et tant que personne ne l’aura exécuté, quiconque classe ces deux modèles selon leur grounding ne fait que deviner.

La suite propre à l’agent expose elle aussi sa faiblesse au grand jour. Sur OSWorld 2.0, le modèle 9B obtient 7,5 en partiel et 0,0 en binaire ; son homologue 27B atteint 13,2 en partiel et 2,8 en binaire. Le travail de bureau à long horizon n’est pas résolu à cette taille, et la fiche le dit.

Leur serving représente un écart plus important que l’écart au benchmark.

Pour une équipe qui décide quoi exécuter la semaine prochaine, la différence opérationnelle comptera davantage que n’importe quel score. UI-Venus-2-9B est un modèle unique que vous démarrez avec une seule commande vLLM, exposant un point de terminaison compatible OpenAI avec un parallélisme tensoriel de 1. WeVisOne-VL-4B nécessite son package d’inférence depuis GitHub ainsi que l’artefact décodeur séparé, et il est appelé via son propre wrapper WeVisOneVL(...) avec un argument de tâche — predict(image, task="matting", query="person", temperature=0.0). La fiche documente les parcours Transformers, vLLM et SGLang, mais le décodeur de pixels n’est pas facultatif : le modèle de langage seul ne peut pas produire de masque.

La mémoire est plus proche que ne le laissent penser les nombres de paramètres. En bf16, le backbone de 5B représente environ 10 Go avant le décodeur, contre environ 18,8 Go pour les quatre shards de UI-Venus-2-9B. Les deux tiennent sur une seule carte de 24 Go pour les poids ; ce qui diffère, c'est la place restante pour le contexte.

Et côté contexte, les deux configurations concordent d’une manière qu’il est facile de surinterpréter. La configuration de WeVisOne-VL-4B fournit un max_position_embeddings de 262 144 — le même plafond que UI-Venus-2-9B offre avec sa longueur maximale de modèle de 262 144. Mais elles l’utilisent à des fins différentes : l’agent traite le contexte long comme une mémoire épisodique, en conservant l’historique des captures d’écran d’une tâche, tandis que les évaluations publiées du modèle de perception tournent à 1 960 tokens visuels par image. Une fenêtre de 256K sur un modèle à tour unique et uniquement image est un plafond, pas une capacité démontrée, et la fiche indique que les grilles vidéo sont rejetées d’emblée par le décodeur de pixels.

Licence : l’une d’entre elles est réglée et l’autre ne l’est pas

WeVisOne-VL-4B est sous licence Apache 2.0, avec du code rédigé par Tencent sous les mêmes conditions. Vous pouvez le lire, le forker, l’intégrer dans un produit sans avoir à en parler à un avocat.

La fiche de UI-Venus-2-9B indique que la licence des poids du modèle est en attente de confirmation finale et sera ajoutée avant la sortie publique, et que la déclaration Apache-2.0 antérieure n’a délibérément pas été reprise parce que les documents amont contiennent des déclarations de licence contradictoires. Cette phrase figure sur la fiche depuis août et n’a pas changé. Elle ne vous empêche pas d’évaluer le modèle et ne bloque pas l’utilisation interne dans la plupart des organisations — mais elle signifie qu’un produit externe construit sur ces poids repose sur une question non résolue, et aucun score de benchmark ne corrige cela. Si vous choisissez entre ces deux modèles pour quelque chose que vous comptez livrer, la colonne licence tranche plus vite que la colonne précision.

Combien coûte chacun, sachant qu’aucun des deux n’a de prix

Il n’existe pas de prix par token fixé par le fournisseur pour l’un ou l’autre modèle. La page de WeVisOne-VL-4B indique qu’il n’est déployé par aucun fournisseur d’inférence ; UI-Venus-2-9B n’a ni point de terminaison de première partie ni grille tarifaire publiée par inclusionAI, donc ce qu’un hébergeur tiers facture pour ce modèle est le chiffre de cet hébergeur, pas celui de l’équipe. Pour les deux, le coût correspond à des heures GPU sur du matériel que vous louez ou possédez, ce qui signifie que la comparaison n’est pas « prix d’entrée vs prix de sortie » mais « de combien de cartes GPU ai-je besoin et combien d’images par seconde cela traite-t-il ».

Aucun des deux articles ne publie le débit ni la latence, donc ce second chiffre reste inconnu pour les deux. Ce que l’on peut savoir, c’est la structure : UI-Venus-2-9B paie une passe avant de 9B plus des tokens de raisonnement à chaque étape d’un épisode, et un épisode d’agent compte de nombreuses étapes. WeVisOne-VL-4B paie une passe de 5B plus un passage avant du décodeur par image, et une image correspond à un appel. Si votre charge de travail représente cent mille photos de produits, l’économie du modèle de perception est par image et prévisible ; s’il s’agit d’une tâche de navigateur, le coût de l’agent évolue avec le nombre d’actions que la tâche nécessite, et c’est précisément le chiffre que vous ne pouvez pas prévoir à partir de la fiche.

C’est aussi là qu’une couche de routage justifie sa place plutôt que de rester un slogan. Aucun des deux modèles n’est disponible sur OrcaRouter aujourd’hui, et cet article ne prétendra pas le contraire — WeVisOne-VL-4B n’a aucun fournisseur d’inférence, et UI-Venus-2-9B est servi par un hébergement tiers plutôt que depuis notre propre catalogue. Ce qu’OrcaRouter offre pour les modèles qu’il sert, c’est un point de terminaison unique compatible avec OpenAI pour plus de 200 d’entre eux, avec 0 % de marge, le prix catalogue du fournisseur étant répercuté tel quel, afin qu’une baisse de prix d’un fournisseur vous parvienne le jour même plutôt qu’à la prochaine renégociation de contrat. Pour une architecture qui appelle un modèle de perception puis un modèle d’agent en séquence, le DSL de routage est l’endroit où cette composition prend forme — deux appels de modèle, un seul endroit pour remplacer l’une ou l’autre branche — et le basculement automatique est ce qui maintient une boucle d’agent en vie lorsque le modèle qui la sous-tend se dégrade en cours d’épisode. Dès que l’un de ces deux modèles est disponible chez un fournisseur, c’est le moyen le moins coûteux de découvrir s’il a sa place dans votre stack.

Lequel choisir

La décision est une description de poste, pas un classement.

• Choisissez WeVisOne-VL-4B si la sortie dont vous avez besoin est de la géométrie — des boîtes englobantes pour un pipeline d’annotation, des masques pour un outil d’édition, des mattes alpha pour l’imagerie produit, le comptage d’objets dans une image aérienne dense, ou de l’OCR avec les coordonnées associées. Aucun autre modèle de la classe ouverte des 5B ne renvoie de matte à partir d’une invite textuelle, et les chiffres de matting de l’article face à un pipeline SAM2 constituent l’argument le plus fort de cette publication.

• Choisissez UI-Venus-2-9B si la sortie dont vous avez besoin est une tâche accomplie — un formulaire rempli, une application parcourue, un CAPTCHA résolu, un workflow de bureau piloté à partir de captures d'écran. Il se déploie en une seule commande vLLM avec un point de terminaison compatible OpenAI, ce qui représente une journée de travail plutôt qu'une semaine, et ses résultats sur AndroidWorld et WebVoyager sont les chiffres à comparer avec votre propre environnement.

• Ne choisissez encore ni l’un ni l’autre si vous avez besoin de preuves indépendantes, d’un prix publié ou d’une licence définitive pour un produit commercialisé. Ces trois éléments manquent pour la licence d’UI-Venus-2-9B et pour les benchmarks des deux modèles.

• Envisagez les deux si vous construisez un agent qui doit manipuler des images plutôt que simplement parcourir des écrans en cliquant. La composition est la plus intéressante : UI-Venus-2-9B décide où agir, WeVisOne-VL-4B produit l’artefact précis au pixel près que l’action visait. Cela coûte deux appels de modèle par étape et permet d’obtenir une précision qu’aucun des deux modèles n’a seul.

Qu’est-ce qui changerait cette réponse ?

Quatre choses, par ordre de l’impact qu’elles auraient.

Une exécution de ScreenSpot-Pro avec WeVisOne-VL-4B. C’est le seul benchmark sur lequel les deux camps pourraient raisonnablement se mesurer, et il trancherait la question de savoir si un spécialiste de la perception deux fois plus petit surpasse en localisation un agent d’interface utilisateur conçu spécialement. N’importe qui disposant d’un GPU et d’un après-midi peut le produire, et personne ne l’a fait.

Une évaluation indépendante de l’un ou l’autre modèle. Chaque chiffre de cet article remonte à une fiche de modèle ou à un article rédigé par l’équipe qui a construit la chose. C’est normal le jour de la sortie, et cela reste une absence.

Une licence définitive pour UI-Venus-2-9B. La mention « Confirmation finale en attente » figure sur la fiche depuis huit semaines. Si elle aboutit à des conditions permissives, l’agent devient nettement plus facile à recommander pour un usage commercial ; dans le cas contraire, cela répond à la question dans l’autre sens.

Un point de terminaison de première partie pour l’un ou l’autre. Aucun des deux fournisseurs ne sert son propre modèle aujourd’hui, ce qui limite l’audience aux équipes prêtes à exploiter une pile de service, et, du côté de WeVisOne-VL-4B, aux équipes prêtes à piloter un package d’inférence personnalisé. Un tarif publié par le fournisseur ferait passer la comparaison des coûts de l’arithmétique à une ligne budgétaire.

En attendant, le résumé honnête est le suivant : Tencent a livré une boîte à outils de perception qui fait ce qu’aucun petit modèle ouvert n’avait fait auparavant, assez discrètement pour que ses propres tableaux de benchmarks n’aient pas encore été lus, et Ant Group a livré, un mois et demi plus tôt, un agent plus facile à exécuter et plus difficile à obtenir sous licence. Ce ne sont pas des rivaux. L’erreur serait d’en choisir un parce que l’autre a obtenu un meilleur score sur un benchmark qu’ils ne partagent pas.