WeVisOne-VL-2B vs UI-Venus-2-9B : l’écart de taille que le nom dissimule

Neuf milliards de paramètres, ce n’est pas ce que dit la confrontation. Écrite comme la plupart des gens l’écrivent — WeVisOne-VL-2B vs UI-Venus 2.9B —, l’affiche se lit comme celle de deux petits modèles de vision d’un poids à peu près équivalent, un combat équitable entre un nouveau checkpoint 2B de l’équipe WeChat Vision de Tencent et quelque chose d’un peu plus gros chez inclusionAI d’Ant Group. La seconde moitié de cette hypothèse est fausse. UI-Venus-2-9B est UI-Venus 2 avec 9 milliards de paramètres, initialisé à partir de Qwen3.5-9B ; le « 2 » désigne la génération, pas la taille. WeVisOne-VL-2B, mis en ligne sur Hugging Face le 22 octobre 2026, compte 2 milliards de paramètres sur un socle Qwen3-VL. La vraie comparaison porte donc sur un modèle quatre fois et demie plus petit, sur une génération de socle plus ancienne, qui renvoie un tout autre type de réponse.

Il est également arrivé sans lancement. Il existe un dépôt Hugging Face, un dépôt GitHub ne contenant qu’un unique commit initial, un article sur arXiv et une page de projet de recherche — et aucune annonce du fournisseur, aucun billet de blog et aucune page de tarifs qui les relient entre eux. Cela détermine ce que cet article peut honnêtement faire. Les poids, l’architecture, le texte de la licence et les tableaux de l’article sont vérifiables aujourd’hui. L’évaluation indépendante, le débit, la latence et le prix ne le sont pas, car aucun d’entre eux n’existe encore. La fiche modèle de Tencent ne publie aucun chiffre de benchmark ; chaque score attribué ci-dessous à WeVisOne-VL-2B provient des sept tableaux de tâches de ses propres auteurs et est présenté comme tel. UI-Venus-2-9B est plus ancien et mieux documenté, mais ses chiffres sont exactement tels qu’autodéclarés.

Ce que les deux noms décrivent réellement

WeVisOne-VL-2B est un modèle de perception. Donnez-lui une image et une phrase, et il renvoie de la géométrie : une boîte englobante, un point, un décompte, un masque binaire ou un matte alpha continu. Son côté langage émet les coordonnées sous forme de jetons dédiés allant de <0> à <1000>, normalisés par rapport à l’image, et referme chaque boîte dans les tâches denses avec un jeton spécial <OBJ> à l’identifiant 152 678. Ces jetons ne sont que des marqueurs tant que mask_decoder.pt ne lit pas l’état caché qui les sous-tend — un artefact requis de 9 511 460 paramètres, livré comme second fichier, que la fiche décrit comme « un composant central requis, pas un ajout facultatif ». Sans lui, vous obtenez des boîtes. Avec lui, vous obtenez des masques et des mattes alpha au pas 1.

UI-Venus-2-9B est un agent. Confiez-lui une capture d'écran et une tâche, et il renvoie un geste : le prochain appui, clic ou frappe de touche, ainsi que les jetons de raisonnement qui l'ont produit, dans une boucle fermée observer–raisonner–agir. Il a été entraîné sur une interaction par capture d'écran uniquement, couvrant le grounding, les CAPTCHA, le mobile, le web et l'usage de l'ordinateur, et sa recette vLLM publiée associe une longueur maximale de modèle de 262 144 au parseur de raisonnement Qwen3, car la trace de raisonnement précède chaque action.

Mettez les deux côte à côte et l’écart est immédiat :

• Ce qui est renvoyé — boîtes, points, décomptes, segments OCR, masques et mattes alpha de WeVisOne-VL-2B ; une action d’écran ainsi que sa trace de raisonnement de UI-Venus-2-9B.

• Paramètres — 2B pour WeVisOne-VL-2B plus le décodeur séparé de 9,5 M ; 9B dense pour UI-Venus-2-9B, soit environ 4,5 fois les poids.

• Backbone — Qwen3-VL pour WeVisOne-VL-2B, 28 couches de texte avec une dimension cachée de 2 048 ; Qwen3.5-9B pour UI-Venus-2-9B. Des générations différentes, des empilements de texte différents.

• Poids sur disque — bfloat16 dans les deux cas, mais environ 4 Go pour le 2B contre quatre fragments BF16 totalisant environ 18,8 Go pour le 9B.

• Plafond de contexte — 262 144 positions pour chacun, d'après la configuration de WeVisOne-VL-2B et la commande de service de UI-Venus-2-9B. Aucun des deux fournisseurs ne démontre l'utilisation d'une capacité comparable.

• Preuves publiées — sept tableaux de tâches dans l’article de Tencent et aucun sur la fiche du modèle ; une longue liste de benchmarks de fournisseurs sur la fiche d’inclusionAI et aucun tableau dans l’article.

• Licence — Apache 2.0 pour le code écrit par Tencent ; « en attente de confirmation finale » pour les poids de UI-Venus-2-9B.

La conséquence pratique, c’est que vous ne pouvez pas substituer l’un à l’autre, et tout article qui vous désigne un gagnant répond à une question que vous n’avez pas posée. Un modèle de perception qui renvoie un masque parfait ne peut toujours pas appuyer sur un bouton. Un agent qui navigue parfaitement dans une application ne peut toujours pas vous fournir le détourage que vous vouliez pour une photo produit.

L'argument en faveur du modèle plus petit est plus solide que ne le suggère la comparaison entre 2B et 9B.

L’instinct, en voyant un 2B à côté d’un 9B, est que le petit modèle est le compromis budgétaire. Sur le travail pour lequel il a été entraîné, l’article de Tencent soutient le contraire, et l’un de ses propres résultats plaide contre sa propre version plus grande. Tous les chiffres ici sont ceux des auteurs, exécutés par les auteurs, reproduits par personne.

• Détection zero-shot — F1 moyen de 55,2 sur COCO, 53,3 sur LVIS, 61,4 sur Dense200 et 40,4 sur VisDrone. La référence Qwen3-VL-2B obtient 45,2, 40,8, 10,0 et 23,1 dans le même tableau. L'écart sur Dense200 est celui qu'il faut remarquer : six fois le modèle de base sur des scènes encombrées.

• Comptage — 90,9 et 88,1 en correspondance exacte sur les deux sous-ensembles de PixMo-Count, mais 27,5 et 26,9 sur CLOC, 29,5 et 32,4 sur KubriCount, et 47,9 sur CountQA. Le comptage n’est pas une compétence unique, et cet écart est l’élément le plus honnête de l’article.

• Localisation OCR — F1 moyen de 30,5 sur HierText, 42,6 sur ICDAR2015, 42,5 sur TotalText et 62,1 sur SROIE, à un seuil d'IoU de 0,5. Il s'agit de scores de localisation accompagnés de coordonnées, et non de précision de transcription ; ils ne sont donc pas comparables au chiffre OCRBench généralement cité pour les VLM grand public.

• Segmentation référente — 79,7 d'IoU cumulé sur la validation RefCOCO, 73,1 sur RefCOCO+, 74,4 sur RefCOCOg et 60,9 de gIoU sur ReasonSeg.

• Matting avec prompt — 6,6 de différence absolue moyenne sur P3M-500-NP avec un prompt de type boîte, contre 15,4 pour SAM2-Matting ; 5,7 contre 12,1 sur AM-2K ; 15,8 contre 23,0 pour un pipeline Qwen3-VL-8B plus SAM2-Matting sur la partition référentielle WeRefMat plus difficile. Plus la valeur est basse, mieux c’est dans tous les cas.

Le résultat de détourage est là où l’argument de taille s’inverse. Sur ce même test avec prompt de boîte P3M-500-NP, le 2B obtient 6,6 et son frère 4B de Tencent obtient 7,3. Le plus petit modèle est le meilleur détourage des deux, Tencent n’explique pas pourquoi, et l’article le publie quand même. Si votre travail consiste à découper des objets dans des images, la variante la moins chère de la famille n’est pas une régression — c’est actuellement le choix le mieux mesuré.

Ce que l’article ne montre pas mérite tout autant d’être connu. Il n’y a, dans aucun des sept tableaux, de MMMU, de MMBench, de DocVQA ni de benchmark de description d’images, et la section sur les limites reconnaît que des données d’entraînement généralistes limitées « peuvent compromettre les capacités générales par rapport au modèle de base ». Le fine-tuning qui a rendu ce modèle performant en perception en a peut-être fait un assistant général moins bon, et rien dans les tests de la version publiée ne le vérifie. Il n’y a pas non plus de sortie de chaîne de pensée, de mémoire multi-tours ni de prise en charge de la vidéo — le décodeur de pixels rejette catégoriquement les grilles vidéo.

Le seul benchmark qui permettrait de trancher cette question n’existe pas

Placez les deux suites d’évaluation côte à côte, et l’incomparabilité cesse d’être un détail technique. Les résultats phares d’UI-Venus-2-9B sont des taux de réussite à l’état final 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. Ils mesurent si une tâche a été achevée, en regroupant la perception, la planification, la mémoire et la récupération après erreur dans un seul nombre.

Ce qui s’approche le plus d’un axe commun est le GUI grounding — localiser un petit élément d’interface dans une capture d’écran haute résolution. UI-Venus-2-9B obtient 73,0 sur ScreenSpot-Pro. WeVisOne-VL-2B ne rapporte aucun résultat sur ScreenSpot-Pro, aucun résultat sur ScreenSpot-V2 et aucun benchmark GUI de quelque nature que ce soit, sur sa fiche, dans son article ou sur sa page projet. Dans l’autre sens, WeVisOne-VL-2B rapporte la localisation OCR et le pointage dense, et UI-Venus-2-9B ne rapporte ni l’un ni l’autre.

Il y a une subtilité qui rend l’appariement mis en avant encore plus étrange. inclusionAI propose déjà un modèle 2B construit sur Qwen3-VL — UI-Venus-1.5-2B — et sa fiche indique 57,7 sur ScreenSpot-Pro, contre 68,4 pour son homologue 8B et 69,6 pour le 30B-A3B. C’est le véritable équivalent de taille comparable à WeVisOne-VL-2B, sur la même famille de backbones, mesuré sur le seul benchmark qui compte pour les deux gammes. Ce n’est simplement pas le modèle nommé dans cette confrontation.

Donc, la position honnête est étroite. Aucun chiffre publié ne compare WeVisOne-VL-2B à UI-Venus-2-9B sur quelque tâche que ce soit, et personne n’a exécuté le modèle de perception 2B sur un jeu de données d’ancrage GUI. Exécuter WeVisOne-VL-2B sur ScreenSpot-Pro est la mesure manquante la plus utile de cette comparaison : cela vous dirait si un spécialiste de la perception 2B repère les éléments d’interface mieux ou moins bien qu’un agent 9B, et tant que personne ne l’exécute, quiconque classe ces deux modèles sur la capacité à trouver des éléments extrapole à partir de l’architecture.

Ce que chacun fait lorsque l’objet n’est pas là

Le comportement face aux objets absents est le point où les modèles de perception échouent silencieusement. Demandez l’extincteur dans une pièce qui n’en contient aucun, et un modèle qui répond toujours délimitera avec assurance le radiateur — et dans un pipeline automatisé, cela devient un objet halluciné dans une bibliothèque d’actifs, ou un appui mal dirigé dans une boucle d’agent.

WeVisOne-VL-2B répond None à la place, et l’article rapporte le rejet comme une métrique à part entière, à côté de l’exactitude. Sur RefCOCOg, il rapporte un taux de rejet de 50,2 pour les requêtes portant sur des objets absents, contre 0,5 pour Rex-Omni-3B et 0,6 pour LocateAnything-3B dans le même tableau. C’est un objectif de conception différent de celui de maximiser le rappel, et c’est le chiffre qui rend un petit modèle utilisable comme composant : une branche géométrique qui déclare « non présent » peut être injectée sans risque dans un planificateur, tandis qu’une branche qui invente une boîte le corrompt silencieusement.

UI-Venus-2-9B aborde le même problème du côté de l'action, en héritant d'un ancrage conscient du refus de la gamme UI-Venus — il est entraîné à refuser lorsque l'élément demandé n'est pas à l'écran plutôt qu'à deviner une coordonnée plausible. Son tableau de sécurité montre l'effet annoncé : 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 %. La fiche précise également que cela n'élimine pas le risque d'actions nuisibles et recommande une confirmation humaine ainsi que des garde-fous au niveau applicatif. Les deux équipes ont choisi l'abstention plutôt que la couverture ; ce choix n'a été mesuré de manière indépendante pour aucune des deux.

Faire tourner un 2B à côté d’un 9B

La relation honnête entre ces deux modèles n’est pas une rivalité mais une séquence. L’un renvoie de la géométrie, l’autre agit dessus. Si vous construisez un système d’automatisation d’écran, une architecture plausible place WeVisOne-VL-2B devant comme l’élément qui signale quoi se trouve où — boîtes, spans OCR, masques — et UI-Venus-2-9B derrière comme l’élément qui décide quoi faire. C’est une composition, pas une compétition, et c’est le seul cadrage dans lequel cet appariement a un sens opérationnel.

La mémoire rend cette composition peu coûteuse sur une seule machine. En bfloat16, le backbone 2B représente environ 4 Go de poids avant le décodeur, et le 9B environ 18,8 Go répartis sur quatre shards. Les deux tiennent sur une seule carte de 24 Go en laissant de la place pour le contexte ; le 2B seul tient sur une carte de 8 Go, ce qui est le fait le plus intéressant. Les plafonds de contexte concordent à 262 144 positions, mais ils ne signifient pas la même chose : l’agent utilise le contexte long comme mémoire d’épisode, en conservant un historique de captures d’écran, tandis que les évaluations publiées du modèle de perception tournent à environ 1 960 tokens visuels par image. Une fenêtre de 256K sur un modèle monotour et uniquement image est un plafond, pas une capacité démontrée.

C’est sur le coût que les profils divergent. Aucun des deux fournisseurs ne publie de prix par token ; dans les deux cas, le coût réel se mesure en heures de GPU sur du matériel que vous louez ou possédez. Un agent paie une passe avant de 9B plus des tokens de raisonnement à chaque étape, et un épisode compte de nombreuses étapes — un chiffre impossible à prévoir à partir de la fiche technique. Un modèle de perception paie une passe de 2B plus une passe avant du décodeur par image, et une image correspond à un appel. Cent mille photos de produits relèvent d’une arithmétique prévisible par image ; une tâche dans un navigateur, non.

C’est aussi là qu’une couche de routage mérite sa place au lieu de n’être qu’un slogan. Aucun des deux modèles n’est sur OrcaRouter aujourd’hui — vérification faite dans le catalogue en ligne des 209 modèles, et la fiche de WeVisOne-VL-2B indique qu’il n’est déployé par aucun fournisseur d’inférence. Pour les modèles que nous servons effectivement, les propriétés utiles sont un point de terminaison unique compatible OpenAI, 0 % de marge avec le prix catalogue du fournisseur répercuté sans modification, un DSL de routage qui compose plusieurs appels de modèles derrière une seule interface, et un basculement automatique en cas de défaillance. Pour une architecture à deux branches comme celle ci-dessus, c’est dans le DSL que réside la composition et que chaque branche peut être remplacée sans réécrire l’appelant. Le jour où l’un ou l’autre de ces deux modèles est proposé par un fournisseur, c’est le moyen le moins coûteux de découvrir s’il a sa place dans votre stack.

Licence, prix et ce que personne n'a confirmé

La fiche de WeVisOne-VL-2B accorde Apache 2.0 pour « le code rédigé par Tencent dans ce dépôt », ce qui est la réponse permissive que la plupart des équipes souhaitent. Un détail complique les choses : l’API GitHub indique que la licence du dépôt est « Other », sans identifiant SPDX. Ces affirmations ne sont pas nécessairement contradictoires — les composants tiers conservent leurs propres conditions — mais cela signifie qu’il vaut la peine de lire le fichier de licence avant d’utiliser cela dans un produit, plutôt que de prendre le badge pour argent comptant.

La fiche de UI-Venus-2-9B est celle qui reste non résolue. Elle indique que la licence des poids du modèle est en attente de confirmation finale et sera ajoutée avant la publication publique, et que la déclaration Apache-2.0 antérieure n’a délibérément pas été reprise parce que les documents en amont contiennent des déclarations de licence contradictoires. Cette phrase figure sur la fiche depuis août et n’a pas changé. Elle n’empêche ni l’évaluation ni la plupart des usages internes, mais un produit externe construit sur ces poids repose sur une question ouverte, et aucun score de benchmark ne la résout.

Aucun des deux modèles n'a de prix fixé par son fournisseur. WeVisOne-VL-2B n'a ni fournisseur d'inférence ni grille tarifaire. UI-Venus-2-9B n'a pas de point de terminaison propriétaire et aucune tarification publiée par inclusionAI ; dès lors, le tarif facturé par un hébergeur tiers est celui de cet hébergeur, pas celui de l'équipe.

Lequel choisir

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

• Choisissez WeVisOne-VL-2B si la réponse dont vous avez besoin est d’ordre géométrique — des boîtes vers un pipeline d’annotation, des masques pour un outil d’édition, des mattes alpha pour l’imagerie produit, des comptages dans une image dense, ou de l’OCR avec coordonnées associées — et surtout si vous en avez besoin sur du matériel modeste. C’est le seul modèle ici qui renvoie un matte à partir d’un prompt texte, il surpasse son propre grand frère en matting, et sa licence est celle qui est établie.

• Choisissez UI-Venus-2-9B si la réponse dont vous avez besoin est une tâche accomplie : un formulaire rempli, une application parcourue, un CAPTCHA résolu, un workflow de bureau exécuté. Vous achetez une boucle d'agent, et vous devez partir du principe que la licence n'est pas réglée et que le travail de bureau sur long horizon n'est pas résolu à cette taille — les chiffres OSWorld 2.0 de la fiche elle-même sont de 7,5 en partiel et 0,0 en binaire.

• Choisissez plutôt UI-Venus-1.5-2B si ce que vous vouliez réellement était un petit grounder GUI. Il s’agit du modèle 2B basé sur Qwen3-VL de la gamme inclusionAI, il affiche 57,7 sur ScreenSpot-Pro, et c’est le comparateur de taille équivalente que le nom de cette confrontation implique mais ne nomme pas.

• Exécutez les deux en séquence si vous créez une automatisation d’écran qui doit voir précisément puis agir — d’abord le volet géométrie, ensuite le volet agent, sur un seul GPU.

• Attendez : si c’est un chiffre de GUI grounding pour WeVisOne-VL-2B qui détermine votre décision. Il n’existe pas encore, et le deviner à partir du nombre de paramètres n’est pas une méthode.

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

Quatre choses, par ordre d’utilité. Une exécution de ScreenSpot-Pro ou ScreenSpot-V2 avec WeVisOne-VL-2B transformerait la lacune centrale de cet article en comparaison, et étant donné que le modèle a un jour et est sous Apache 2.0, c’est un week-end de travail pour quiconque dispose d’un GPU et du harnais d’évaluation. Une résolution de licence sur UI-Venus-2-9B supprimerait le seul obstacle qu’aucun chiffre de précision ne saurait contester. Une fiche de l’un ou l’autre modèle chez un fournisseur d’inférence remplacerait l’arithmétique des heures-GPU par un prix réel. Et une comparaison 4B-to-2B qui explique pourquoi le modèle plus petit fait mieux dirait aux acheteurs si la nomenclature de la famille signifie quoi que ce soit.

D’ici là, la bonne façon de considérer ces deux-là n’est pas comme des rivaux sur un classement, mais comme des instruments différents : l’un qui mesure l’image et l’autre qui agit sur l’écran. Le nom de ce duel suggère que vous choisissez entre des petits modèles presque équivalents. Vous choisissez entre un spécialiste de 2B et un agent de 9B, et la seule chose qu’ils partagent vraiment, c’est l’habitude de dire non.