WeVisOne-VL de Tencent : un seul modèle de vision pour détecter, compter, lire et détourer

WeVisOne-VL est un modèle de vision open source publié par l'équipe WeChat Vision de Tencent. Il regroupe dans un même réseau la détection d'objets, le comptage, le pointage, la lecture de texte (OCR), la segmentation par description et le détourage alpha (matting). Il existe en deux tailles nominales, 2B et 4B, et repose sur Qwen3-VL. Selon le rapport technique, il dépasse sur plusieurs tests des modèles de 3B à 13B, mais ces chiffres sont ceux des auteurs et aucune reproduction indépendante n'est documentée à ce jour.

Cet article reprend ce que disent les sources primaires, chiffres à l'appui, et sépare ce qui est annoncé de ce qui est vérifié. Il corrige aussi deux erreurs qui circulent sur le nom et sur la base du modèle, détaille la licence, le matériel, les limites publiées, et propose une méthode en six étapes pour juger WeVisOne-VL sur vos propres images.

En bref

• Nom et origine : WeVisOne-VL, pour « WeChat Vision All-in-One », est publié par Tencent (équipe WeChat Vision). Niveau de preuve : confirmé par le dépôt GitHub et les fiches Hugging Face.
• Base : le modèle est construit sur Qwen3-VL, et non sur Qwen 2-VL. Niveau de preuve : confirmé par les fiches 2B et 4B.
• Tâches : détection ouverte, localisation par référence, comptage, pointage, OCR, segmentation référentielle et matting, via un jeton spécial <OBJ> relié à un décodeur de pixels d'environ 9,6 millions de paramètres. Niveau de preuve : confirmé par les fiches.
• Résultats : plus de 30 benchmarks revendiqués par les auteurs. Niveau de preuve : annoncé par Tencent, non reproduit de manière indépendante.
• Licence : Apache-2.0 affichée sur les fiches Hugging Face, avec une nuance sur les composants tiers et sur les poids.
• Matériel : aucune exigence officielle de mémoire GPU. Les estimations circulant viennent de calculs de tiers, non mesurés.
• Limites : image unique, un seul tour, pas de vidéo, matting fin sensible aux conditions difficiles. Niveau de preuve : publié par les auteurs.

Comment nous avons vérifié

Nous avons lu le dépôt GitHub de Tencent, les fiches Hugging Face des versions 2B et 4B et la page arXiv du rapport technique, le tout vérifié le 30 octobre 2026. Les chiffres de benchmarks proviennent d'une lecture partielle de la version HTML du rapport : environ 100 000 caractères sur 162 073 ont été exploités, par l'intermédiaire d'un modèle de résumé. Nous les présentons donc comme « selon le rapport technique » et vous invitons à vous reporter au document.

Nous n'avons pas exécuté le modèle : aucun résultat de ce texte ne vient d'un test maison. Les informations sur le matériel et l'installation viennent en partie de sources secondaires (articles de blogs spécialisés), signalées comme telles. Ce qui n'a pas pu être vérifié est écrit comme tel.

WeVisOne-VL ou « Huiyi-VL » : de quel modèle parle-t-on ?

Le nom « Huiyi-VL » est parfois écrit à tort pour désigner ce modèle. Il ne correspond à rien de publié : une recherche sous cette forme ne donne aucun résultat. Le nom officiel est WeVisOne-VL, sigle de « WeChat Vision All-in-One », tel qu'il figure sur le dépôt github.com/Tencent/WeVisOne-VL et sur les pages Hugging Face de Tencent. Nous ne connaissons pas l'origine de la confusion et aucune source ne l'explique.

Seconde correction : la base. Certaines présentations évoquent Qwen 2-VL. Les fiches Hugging Face des versions 2B et 4B indiquent que le modèle est construit sur Qwen3-VL, et le README précise que l'encodeur visuel (un ViT multi-niveaux) est celui de Qwen3-VL. Si vous cherchez une comparaison avec la famille d'origine, c'est donc Qwen3-VL qu'il faut regarder.

Qu'est-ce que WeVisOne-VL ?

WeVisOne-VL est un modèle vision-langage : il reçoit une image et une consigne en texte, et répond en texte ou en produisant des masques de pixels. Tencent le propose en deux versions, WeVisOne-VL 2B et WeVisOne-VL 4B. Ces tailles sont nominales : les nombres exacts de paramètres ne sont pas publiés par Tencent. La fiche Hugging Face de la version 4B affiche « 5B params », qui est un arrondi de la plateforme, et un blog tiers avance 4,83 milliards de paramètres en précision F32, une valeur à vérifier.

Le rapport est signé de huit auteurs (Tianming Liang, Junyi Pan, Yuxi Li, Canmiao Fu, Zhipeng Huang, Chong Sun, Chen Li et Jing Lyu). La première version a été déposée sur arXiv le 22 octobre 2026, suivie d'une deuxième le 24 octobre 2026. Le dépôt Hugging Face aurait été créé le 22 octobre selon un blog tiers ; le README et les fiches ne donnent pas de date absolue.

La sortie est restée discrète. D'après ce même blog tiers, il n'y a eu ni article de blog de Tencent, ni communiqué, ni point d'accès hébergé. C'est une interprétation de cette source, que nous rapportons telle quelle. Concrètement, vous obtenez des poids, du code et des démos, mais pas d'API prête à l'emploi.

Quelles tâches couvre-t-il ?

Les fiches Hugging Face énumèrent plusieurs capacités : la détection ouverte (trouver des objets décrits par du texte, sans liste de classes figée), la localisation par référence (trouver « le mug à gauche de l'ordinateur »), le comptage, le pointage, l'OCR avec localisation du texte, la segmentation référentielle et le matting alpha sur invite. Une présentation parle de six tâches, alors que les fiches énumèrent sept intitulés ; nous reprenons ici la liste complète.

Le modèle répond « None » lorsque la cible demandée n'est pas dans l'image. Ce comportement paraît anodin, mais il conditionne la fiabilité en usage réel : nous y revenons plus bas.

Comment un seul modèle fait toutes ces tâches : le jeton <OBJ> et le décodeur de pixels

Un modèle vision-langage classique sait décrire une image ou répondre à une question, mais il produit du texte, pas des contours précis. Pour obtenir des masques, on branche d'ordinaire un second modèle spécialisé, comme SAM. WeVisOne-VL prend un autre chemin : il intègre un décodeur de pixels de 9 609 764 paramètres, soit environ 9,6 millions, dont les poids sont dans un fichier mask_decoder.pt distribué avec le modèle. Selon le README, ce décodeur produit les masques et les mattes sans recourir à SAM.

Le lien entre le texte et les pixels passe par un jeton spécial, <OBJ>. Quand le modèle « décide » qu'il doit désigner un objet, il émet ce jeton dans sa réponse. L'information associée à ce jeton est ensuite transmise au décodeur, qui produit le masque ou la transparence de l'objet. Le langage reste donc le point d'entrée unique, et la sortie pixel est une « extension » de la réponse.

L'intérêt de cette architecture est d'éviter un assemblage de modèles : une seule consigne, un seul passage, un seul jeu de poids à déployer. Le revers est que le décodeur est très petit au regard de l'ensemble, et que la qualité du résultat dépend de la capacité du modèle de langage à bien formuler la désignation. Cette dépendance pourrait être liée à la sensibilité à la formulation de la consigne que les auteurs signalent parmi les limites, sans qu'ils l'affirment.

À titre de comparaison avec d'autres approches de modèles ouverts compacts, vous pouvez lire notre article sur Carbon-X et l'ADN d'un modèle open source, qui aborde la question de la filiation entre modèles.

Schéma de la rédaction, d'après les fiches Hugging Face et le dépôt GitHub.

Détection et comptage : que disent les chiffres ?

Les métriques ci-dessous sont des F1 moyens sur des seuils d'IoU de 0,5 à 0,95, sauf mention contraire. L'IoU (intersection sur union) mesure le recouvrement entre la boîte prédite et la boîte de référence ; moyenner sur 0,5 à 0,95 est plus exigeant que de ne regarder que le seuil de 0,5. Tous les chiffres sont ceux des auteurs, selon le rapport technique.

Détection

Deux lectures s'imposent. Sur LVIS, qui compte de très nombreuses catégories, la 4B devance de 4,6 points LocateAnything-3B (55,3 contre 50,7). Sur COCO, en revanche, GroundingDINO-T, un détecteur spécialisé, obtient 56,6 et devance la version 2B (55,2), même si la 4B le dépasse (57,1). Autrement dit, un généraliste de cette taille égale à peine un spécialiste établi sur un benchmark classique.

Rejet des objets absents

Sur WeRef-Bench, la version 4B atteint 96,4 % de rejet correct des objets absents, contre 73,0 % pour le modèle comparé. Cela signifie que, lorsqu'on lui demande un objet qui n'est pas dans l'image, le modèle répond « None » au lieu d'inventer une boîte. C'est un point important en pratique : un détecteur qui « trouve » toujours quelque chose génère des fausses alertes. Mais WeRef-Bench a été créé par les auteurs, et ce score est donc à prendre avec la prudence due à un test conçu par ceux qui le passent.

Comptage et pointage

Le comptage sur PixMo-Count est le résultat le plus lisible : 89,6 % pour la 4B contre 82,8 % pour le modèle de comparaison. Les valeurs sur CountQA (57,1) et MixCount (40,4) sont plus basses, mais nous ne disposons pas du détail de leurs métriques : ne les comparez pas directement à PixMo-Count. Les extraits exploités ne donnent pas de comparaison sur ces deux jeux.

Chiffres du rapport technique de Tencent, non reproduits par un tiers.

OCR : lire et localiser le texte

Dans le rapport, l'OCR est évalué comme une double tâche : localiser le texte dans l'image et le transcrire. C'est plus exigeant qu'une simple lecture, et c'est aussi pourquoi les chiffres ne sont pas directement comparables à ceux d'un moteur d'OCR évalué uniquement sur la reconnaissance.

Sur SROIE, un jeu de tickets et de reçus, la version 4B passe devant PP-OCRv5 (68,1 contre 58,6). Sur HierText, la version 2B (30,5) est à égalité avec PP-OCRv5, tandis que la 4B monte à 39,0. Ces résultats suggèrent un OCR compétitif pour un modèle généraliste, sans permettre de conclure sur vos documents : les tickets de caisse en français, les factures scannées de travers ou les écritures manuscrites ne sont pas couverts par ces chiffres.

Segmentation référentielle et ReasonSeg

La segmentation référentielle consiste à produire le masque exact de l'objet décrit par une phrase. ReasonSeg pousse l'exercice : la consigne demande un petit raisonnement (« l'objet qui sert à couper le papier »), et le modèle doit déduire la cible avant de la segmenter. Le score est le gIoU, une moyenne de recouvrement par image.

Sur ReasonSeg (validation), la version 4B devance LISA-13B, un modèle nettement plus gros, et la 2B (60,9) se situe au niveau d'UniPixel-7B (60,5). Sur RefCOCO testA, l'écart avec les concurrents est plus mince : 84,5 contre 83,0 et 82,0. Un point d'écart sur ce type de benchmark est à interpréter avec précaution, car les variations liées à la configuration d'évaluation peuvent en représenter une bonne part.

Le fait qu'un modèle de 4 milliards de paramètres nominaux dépasse un 13B sur ReasonSeg est un résultat marquant du rapport, mais il reste un score sur un seul jeu de test, publié par les auteurs.

Détourage alpha (matting) : où WeVisOne-VL se démarque

Le matting alpha ne se contente pas de dire « pixel dans l'objet » ou « pixel hors de l'objet » : il estime une opacité entre 0 et 1 pour chaque pixel, ce qui permet de gérer les cheveux, les poils, les bords flous ou les verres. C'est ce dont on a besoin pour détourer proprement une personne ou un produit sur un fond quelconque.

La métrique citée est la MAD, erreur absolue moyenne entre l'alpha prédit et l'alpha de référence, exprimée ici en multipliée par 1 000. Plus elle est basse, meilleur est le résultat. Une valeur de 6,6 signifie donc une erreur moyenne d'environ 0,0066 sur l'échelle d'opacité de 0 à 1.

Sur P3M-500-NP, les deux versions réduisent l'erreur de plus de moitié par rapport à SAM2-Matting. Le matting référentiel, où il faut d'abord identifier la cible à partir d'une phrase puis la détourer, donne 9,8 contre 22,4 pour une chaîne associant Qwen3.5-9B et SAM2-Matting. WeRefMat semble, comme WeRef-Bench, être un jeu de test maison, ce que nous n'avons pas pu confirmer.

Nuance utile : la version 2B fait mieux que la 4B sur certains tests de matting (6,6 contre 7,3 sur P3M-500-NP). Passer à la plus grande taille n'améliore donc pas mécaniquement toutes les tâches. D'après un blog tiers, l'étape d'apprentissage par renforcement du modèle ne comporte pas de récompense fondée sur le masque ou l'alpha, ce qui pourrait expliquer que la progression de 2B à 4B ne se retrouve pas partout ; il s'agit d'une analyse extérieure, non confirmée par les auteurs.

Que valent ces benchmarks ?

Trois réserves doivent accompagner chaque chiffre de cet article.

Ce sont les chiffres des auteurs. Le rapport revendique plus de 30 benchmarks. Aucune reproduction indépendante n'est documentée, et des blogs tiers relaient surtout les résultats du rapport. Les protocoles précis (prompts, post-traitements, version des jeux de test) ne sont pas tous détaillés dans les extraits que nous avons lus.

Les modèles comparés ne sont pas ceux de la pointe. La comparaison porte surtout sur des modèles de 3B à 13B. Elle montre que WeVisOne-VL est compétitif dans sa catégorie, pas qu'il bat les plus gros modèles du moment. Et sur COCO, le spécialiste GroundingDINO-T devance la version 2B, ce qui rappelle que les spécialistes restent forts sur leurs terrains.

Certains jeux de test sont maison. WeRef-Bench (rejet des objets absents, 96,4 %) a été créé par les auteurs, et WeRefMat (matting référentiel) paraît l'être aussi, sans confirmation de notre part. Ces jeux sont utiles pour illustrer un comportement, mais un modèle entraîné par les concepteurs du test peut avoir un avantage de familiarité avec le format. Les auteurs reconnaissent par ailleurs que leurs prompts de benchmark sont plus clairs que ceux d'un usage réel.

Enfin, l'évaluation est faite en décodage glouton, avec au plus 1 960 jetons visuels par image. Si vous utilisez des images plus grandes ou d'autres réglages, vos résultats peuvent différer.

Cette prudence rejoint celle de notre synthèse sur les modèles IA spécialisés face aux géants : un score de benchmark décrit un test, pas un produit.

Licence : que couvre Apache 2.0 ?

Les fiches Hugging Face des versions 2B et 4B affichent la licence Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, moyennant la conservation des mentions de licence et de copyright. Elle comporte aussi une clause relative aux brevets.

La situation est toutefois plus nuancée que l'étiquette. Le dépôt GitHub indique que l'Apache-2.0 s'applique au code écrit par Tencent, et que les composants tiers conservent leur propre licence. Le README ne précise pas la licence des poids : c'est la fiche Hugging Face qui affiche Apache-2.0. Le modèle étant bâti sur Qwen3-VL, il est prudent de vérifier les conditions applicables à cette base avant toute intégration commerciale.

Pour une PME, la démarche raisonnable consiste à archiver les licences telles qu'affichées à la date de téléchargement, à lister les composants tiers que vous embarquez (encodeur, jeux de données éventuels) et à demander un avis juridique si le produit est diffusé à des clients. La question de la licence des modèles ouverts revient régulièrement : nous l'abordons aussi dans notre article sur Fibo 2.0 de Bria et la licence.

Matériel et installation : de quoi avez-vous besoin ?

Tencent ne publie aucune exigence officielle de mémoire GPU. Les estimations qui circulent, environ 4,9 Go pour la version 2B et 9,7 Go pour la 4B en bf16, viennent d'un blog tiers (aicybr), qui les présente comme un calcul de l'auteur, non mesuré. Elles correspondent apparemment au stockage des poids et ne tiennent sans doute pas compte de l'activation, du cache ni de la taille des images. Prévoyez une marge et mesurez sur votre propre machine.

Les informations d'installation du dépôt sont les suivantes :

• Python 3.10 ;
• deux backends possibles, transformers ou vllm ;
• des appareils pris en charge en mode automatique, cuda, npu ou cpu ;
• un exemple SGLang sous Docker, avec les options --gpus all --shm-size 32g.

Un point pratique, rapporté par une source secondaire : le chargement standard avec Transformers ne fournit pas les masques. Il faut passer par le paquet wevisone_vl pour obtenir les sorties pixel. La documentation illustre l'usage par un appel de la forme predict(image, task="matting", query=...).

Pour essayer sans rien installer, le README annonce des démos Hugging Face Spaces pour les versions 2B et 4B. Les poids sont disponibles sur Hugging Face (2B) et Hugging Face (4B), le code sur GitHub et une page projet est disponible sur tencent.github.io/WeVisOne-VL. Aucune API hébergée n'est proposée. La liste de tâches du README comporte encore des cases non cochées, notamment le code de fine-tuning : si vous comptiez adapter le modèle à votre domaine, ce n'est pas encore documenté.

Quelles sont les limites publiées ?

Les auteurs détaillent eux-mêmes plusieurs limites, ce qui est à leur crédit :

• Alpha fin : la qualité du détourage est sensible à la résolution, aux occlusions fortes, à la transparence complexe et à la formulation de la consigne.
• Pas de raisonnement en chaîne : le modèle ne déroule pas de raisonnement explicite avant de répondre.
• Image unique, un seul tour : pas de dialogue suivi sur plusieurs images.
• Pas de vidéo : le décodeur rejette les grilles vidéo ; il traite des images uniquement. À la question « WeVisOne-VL gère-t-il la vidéo ? », la réponse documentée est donc non.
• Capacités générales : les données généralistes d'entraînement sont limitées, ce qui peut affaiblir les capacités générales du modèle.
• Écart avec le réel : les prompts de benchmark sont plus clairs que ceux d'utilisateurs réels.

Ces limites déterminent les usages raisonnables. Un flux de caméra à analyser en continu, une conversation longue sur plusieurs documents ou un détourage de tulle en contre-jour sont, à ce jour, des cas que la documentation ne couvre pas.

Cas d'usage réalistes et cas non démontrés

Le rapport cite comme applications possibles la création de contenu, l'inspection industrielle, la conduite autonome, l'intelligence incarnée (les robots et agents physiques) et la production de légendes ancrées pour entraîner d'autres modèles vision-langage. Les mots « logistique » et « robotique » n'y figurent pas tels quels, et aucun déploiement réel n'est documenté. Il s'agit de pistes, pas de références clients.

Pour des idées de pipelines d'édition et de génération d'images qui peuvent s'appuyer sur ce type de segmentation, notre article sur Fibo 2.0 et l'édition d'image multi-références donne un autre exemple de modèle ouvert orienté image. Pour un modèle ouvert dans un autre domaine visuel, la 3D, voyez Hi3D 1.0 : licence, GPU et limites.

Remplace-t-il YOLO, SAM ou PaddleOCR ?

La réponse mesurée est : pas sur la base de ce qui est publié. Les chiffres montrent qu'un modèle unifié peut égaler ou dépasser des spécialistes sur certains tests, mais rien n'établit qu'il les remplace en production.

Un détecteur de type YOLO est conçu pour la vitesse, sur des classes connues, avec des déploiements très légers. WeVisOne-VL est un modèle vision-langage : son intérêt est la flexibilité (décrire en langage naturel ce que l'on cherche), pas la latence minimale. Aucune mesure de vitesse n'est donnée dans nos sources, et c'est un critère décisif pour la vidéo ou le temps réel, que le modèle ne prend de toute façon pas en charge.

SAM et ses dérivés sont des outils éprouvés de segmentation interactive. WeVisOne-VL s'en passe grâce à son décodeur intégré, et le rapport le compare favorablement en matting. Mais ses comparaisons portent surtout sur des modèles de 3B à 13B. Pour PaddleOCR, l'avantage affiché sur SROIE ne dit rien de la robustesse sur un parc de documents réels, ni du coût d'inférence par page.

Une approche raisonnable pour une équipe : garder la chaîne actuelle en production, et utiliser WeVisOne-VL comme candidat sur un sous-ensemble de cas où la souplesse compte (consignes variables, objets rares, comptage à la demande, détourage guidé par texte). Si le gain est net sur vos images, l'unification peut simplifier l'architecture ; sinon, elle n'a pas d'intérêt.

Évaluer WeVisOne-VL sur vos propres images : méthode en 6 étapes

Nous n'avons pas appliqué cette méthode : elle est proposée pour que vous puissiez trancher par vous-même, à coût limité.

1. Constituer un échantillon représentatif. Réunissez quelques dizaines d'images tirées de votre activité réelle, en incluant volontairement des cas difficiles (mauvaise lumière, occlusions, textes inclinés). Évitez les images « propres » choisies pour plaire.
2. Définir la vérité terrain. Pour chaque tâche visée (détection, comptage, OCR, détourage), notez le résultat attendu : boîtes, nombre exact, transcription, masque. Un échantillon annoté à la main vaut mieux que mille images sans référence.
3. Essayer d'abord les démos. Passez les images dans les Spaces 2B et 4B annoncés par le README, avec différentes formulations de consigne. La sensibilité à la formulation étant une limite publiée, notez les variantes qui changent le résultat.
4. Choisir les mesures. Reprenez des métriques simples et comparables : F1 de détection à un seuil d'IoU fixé, taux d'erreur de comptage, taux d'erreur sur les caractères pour l'OCR, MAD pour l'alpha. Fixez-les avant de regarder les résultats.
5. Comparer à votre outil actuel. Passez le même échantillon dans votre chaîne existante (YOLO, SAM, PaddleOCR ou autre), dans les mêmes conditions, et incluez des images sans l'objet cherché pour mesurer le comportement « None » face aux fausses alertes.
6. Mesurer le coût réel. Relevez la mémoire GPU consommée, le temps par image et la stabilité sur plusieurs exécutions, en 2B comme en 4B. Décidez ensuite avec un critère chiffré : gain de qualité, temps, coût d'exploitation.

Ce qui est annoncé, ce qui est vérifié, ce qui manque

Ce qu'il faut retenir

• Le nom correct est WeVisOne-VL, pour WeChat Vision All-in-One, et sa base est Qwen3-VL, pas Qwen 2-VL.
• Un jeton <OBJ> et un décodeur d'environ 9,6 millions de paramètres lui permettent de produire boîtes, points, masques et mattes sans passer par SAM.
• Les chiffres (LVIS, PixMo-Count, SROIE, ReasonSeg, matting) sont ceux des auteurs, contre des modèles de 3B à 13B ; GroundingDINO-T devance même le 2B sur COCO.
• La licence affichée est Apache-2.0, avec des nuances sur les composants tiers et les poids ; aucune exigence matérielle officielle n'est publiée.
• Image unique, pas de vidéo, matting fin sensible : testez sur vos propres images avant de remplacer une chaîne existante.

Pour aller plus loin

• Fibo 2.0 de Bria : édition d'image multi-références et licence
• Hi3D 1.0 : open source, licence, GPU et limites
• Modèles IA spécialisés contre géants, octobre 2026
• Carbon-X sur Hugging Face : l'ADN d'un modèle open source
• Dessa de Block : IA vocale speech-to-speech
• SKY-001 de Skyfall AI : modèle du monde pour la CAO et le BIM
• GPT-Rosalind : essaim d'agents, OpenAI, Atlas, CRISPR

Sources

• Dépôt GitHub Tencent/WeVisOne-VL : README, installation, licence du code, limites.
• Fiche Hugging Face WeVisOne-VL-2B : poids, licence affichée, tâches.
• Fiche Hugging Face WeVisOne-VL-4B : poids de la version 4B.
• Page projet : présentation du modèle.
• Rapport technique sur arXiv (résumé) : dates de dépôt, auteurs.
• Rapport technique sur arXiv (version HTML) : benchmarks, applications citées, limites.
• Orcarouter : analyse de la sortie de WeVisOne-VL-4B : source secondaire, sortie discrète, paquet wevisone_vl, nombre de paramètres.
• Aicybr : guide de déploiement : source secondaire, estimations de VRAM non mesurées.