WeVisOne-VL-2B vs LFM2.5-VL-3B : Un fabricant de masques contre un lecteur d’écran

Donnez aux deux modèles la même photographie et la même phrase — « le chien à gauche » — et vous obtenez deux résultats différents. LFM2.5-VL-3B répond par un emplacement et, si vous le demandez, par une description : une boîte, un point ou une courte phrase sur ce qu’il a trouvé. WeVisOne-VL-2B répond aussi par une boîte, puis un petit décodeur transforme cette boîte en un masque alpha aux bords adoucis que vous pourriez incruster sur un nouvel arrière-plan sans halo autour de la fourrure. Un modèle a été conçu pour lire une interface et répondre. L’autre a été conçu pour vous fournir des pixels.

Cette différence constitue toute la comparaison, et elle tient bon face à tous les tableaux de benchmarks publiés par l’un ou l’autre fournisseur. Cela explique aussi pourquoi les deux modèles sont rarement évalués l’un contre l’autre : la fiche de Liquid AI ne mentionne pas WeVisOne, l’article de Tencent ne mentionne pas Liquid, et aucun tiers ne les a exécutés côte à côte. Ce qui suit présente ce que chaque publication a réellement consigné, lesquels de leurs chiffres peuvent être mis côte à côte, et lesquels ne le peuvent pas.

Deux versions, deux quantités de preuves très différentes

LFM2.5-VL-3B a été publié par Liquid AI le 11 août 2026 — les poids d'abord, l'annonce le lendemain — et il est arrivé avec un tableau de benchmarks chiffrés, une référence nommée pour chaque ligne et une section vitesse mesurée sur du matériel nommé. C'est un modèle dense de 3,12 milliards de paramètres : un socle linguistique LFM2.5-2.6B associé à un encodeur visuel SigLIP2 NaFlex 400M, un contexte de 32 768 jetons, un vocabulaire de 128 000 jetons et seize langues nommées. Sa licence est la LFM Open License v1.0 de Liquid, qui est gratuite pour un usage commercial sous un seuil de chiffre d'affaires plutôt que libre sans condition.

WeVisOne-VL-2B a été publié par l’équipe WeChat Vision de Tencent le 22 octobre 2026, et sa fiche modèle ne contient aucun tableau de benchmarks — aucun score, aucune longueur de contexte, aucun chiffre de débit, aucune exigence matérielle. Les chiffres existent, mais ils se trouvent dans l’article qui l’accompagne, lequel présente sept tableaux de tâches sur ce que les auteurs décrivent comme plus de trente benchmarks. Ainsi, les deux publications ne sont pas simplement des modèles différents ; ce sont des types de documents différents. Liquid a publié une fiche produit. Tencent a publié un résultat de recherche et a laissé la fiche technique essentiellement vide.

Cette asymétrie compte lorsque vous lisez une comparaison comme celle-ci. Les chiffres de Liquid ont été assemblés pour être lus par rapport à ses propres bases de référence. Ceux de Tencent ont été assemblés pour gagner dans un tableau académique. Aucun des deux fournisseurs n’a choisi ses chiffres en pensant à l’autre modèle, et c’est précisément pour cela que les chiffres ne concordent pas.

Le chiffre qui semble comparable et qui ne l’est pas

Les deux modèles publient un score RefCOCO, et les placer côte à côte produit un titre d’apparence impeccable : LFM2.5-VL-3B à 87,9 contre WeVisOne-VL-2B à 79,7. Cette comparaison n’a aucun sens, et il vaut la peine d’expliquer pourquoi, car la même erreur est commise dans des tableurs en ce moment.

• Liquid rapporte RefCOCO precision@1 moyennée sur les splits. Il s'agit d'une statistique de détection : la boîte prédite classée en première position chevauchait-elle suffisamment la boîte de vérité terrain pour être comptée comme correcte.

• Le 79,7 de Tencent figure dans un segmentation tableau, et l'article indique clairement que les chiffres de la famille RefCOCO qui y figurent sont des IoU cumulés — intersection totale sur union totale sur l'ensemble du jeu d'évaluation.

• Le tableau de Tencent pour la détection référentielle ne rapporte pas du tout RefCOCO. Il rapporte RefCOCOg, où le 2B obtient un F1 moyen de 77,1.

Ainsi, le 87,9 et le 79,7 mesurent trois choses différentes sur deux tâches différentes. Une boîte qui ne recouvre qu’à peine une cible peut obtenir un bon score en precision@1 et un mauvais score en cIoU ; un masque qui recouvre bien un grand objet peut obtenir un score élevé en cIoU alors que sa boîte englobante est imprécise. Aucun calcul arithmétique ne permet de les réconcilier.

Le même piège se retrouve dans l’OCR. Liquid publie OCRBench v1 à 84,2 et OCRBench v2 anglais à 47,5 — des benchmarks de transcription. Tencent publie l’OCR sous forme de F1 de localisation à un seuil IoU de 0,5 : 62,1 sur SROIE, 42,6 sur ICDAR2015, 42,5 sur TotalText, 30,5 sur HierText. Ces mesures indiquent si le modèle a trouvé et encadré le texte, pas s’il l’a lu correctement. Citer « 84,2 contre 62,1 » reviendrait à comparer un test de lecture à un test de pointage.

Qu’est-ce qu’une comparaison réellement équitable ?

Retirez les scores, et les deux modèles s’alignent sur des dimensions qui n’ont pas besoin de harnais :

• Taille — environ 3,12 Md de paramètres denses pour LFM2.5-VL-3B contre environ 2 Md pour WeVisOne-VL-2B, plus un décodeur de 9,5 M de paramètres qui doit être téléchargé séparément et est requis pour les sorties denses.

• Base — le backbone hybride LFM2.5-2.6B propre à Liquid vs Qwen3-VL.

• Contexte — 32 768 tokens annoncés sur la fiche, contre aucune longueur de contexte publiée. Les phases d'entraînement de l'article WeVisOne tournaient à 4 096 et 8 192 tokens, et l'inférence plafonne chaque image à 1 960 tokens visuels, mais rien de tout cela ne constitue une fenêtre de déploiement.

• Types de sortie — boîtes, points et texte vs boîtes, points, masques binaires et mattes alpha continus.

• Raisonnement — LFM2.5-VL-3B est délibérément non-raisonneur, répondant directement afin de limiter la latence ; WeVisOne est également non-raisonneur, mais pour une raison différente, générant une sortie structurée sans chaîne de raisonnement pour des raisons d'efficacité d'inférence. Aucun des deux modèles ne « réfléchit » avant de répondre, et aucun des deux fournisseurs ne prétend le contraire.

• Appel d’outils — {{1}}pris en charge et évalué sur LFM (ToolSandbox 59,5, BFCL v4 32,5){{/1}} contre {{2}}une capacité non déclarée sur WeVisOne{{/2}}.

• Langues — seize langues nommées sur la carte LFM, contre aucune mention sur la carte WeVisOne.

• Licence — LFM Open License v1.0, avec un seuil de revenus, contre Apache 2.0 pour le code écrit par Tencent.

• Versions quantifiées — exports GGUF, ONNX et MLX proposés par Liquid, contre aucun annoncé par Tencent.

• Évaluation indépendante — aucun des deux modèles ne figure sur Artificial Analysis à l’heure où nous écrivons ces lignes. Tous les chiffres de cet article, provenant des deux fournisseurs, sont déclarés par les fournisseurs.

L'écart de déploiement est plus large que l'écart de paramètres.

LFM2.5-VL-3B a été conçu pour tourner sur un téléphone, et la fiche technique le prouve chiffres à l'appui : moins de 3,3 Go de mémoire, 20 tokens par seconde sur un Galaxy S26 Ultra, 228 tokens par seconde sur un Apple M5 Max, 116 sur un AMD Ryzen AI Max+ 395, et environ 11 000 tokens de sortie par seconde en cas de forte concurrence sur un seul H100. Il est distribué dans des formats que les environnements d'exécution grand public peuvent réellement charger.

WeVisOne-VL-2B ne publie rien de tout cela. Ce qu'il publie implique une autre facture. La dernière étape du décodeur produit un masque alpha pleine résolution avec un pas de 1, ce qui signifie que la sortie dense a la taille de l'image d'entrée plutôt qu'un vecteur de taille fixe — un coût qui évolue avec la résolution, et non avec le nombre de paramètres. Pour un modèle 2B sur un GPU moderne, c'est gérable. Pour un téléphone, ce n'est pas manifestement gérable du tout, et Tencent ne prétend pas le contraire.

La conséquence pratique est que ces deux modèles ne sont pas en concurrence pour le même emplacement de déploiement. L’un est un composant que vous pourriez embarquer dans une application. L’autre est un composant que vous exécuteriez sur un serveur, ou sur une station de travail, à côté de tout autre élément nécessitant un masquage.

Choisissez en fonction du type de sortie, et non du score

Si la tâche consiste à lire un écran — analyser un parcours de paiement, trouver le bouton intitulé « Continue », extraire un tableau d’un document photographié —, LFM2.5-VL-3B est le candidat évident. Il obtient 80,7 à ScreenSpot-v2, 91,1 à DocVQA, 81,3 à ChartQA, et un score ToolSandbox qui suggère qu’il peut agir sur ce qu’il voit plutôt que simplement le décrire. Il affiche aussi une moyenne de 69,4 sur 28 benchmarks que Liquid publie face à des modèles homologues nommés, ce qui vous donne au moins une idée de ce que le fournisseur pense que son propre voisinage ressemble.

Si la tâche consiste à isoler un objet — un détourage de produit, une personne sur un arrière-plan chargé, un premier plan avec des cheveux rebelles ou un bord transparent —, LFM2.5-VL-3B ne produit pas ce résultat, et aucun prompting ne l'y fera parvenir. WeVisOne-VL-2B y parvient, et l'écart dans les tableaux de matting est important : 6,6 de différence absolue moyenne contre 15,4 pour SAM2-Matting sur P3M-500-NP, 15,8 contre 23,0 pour un pipeline Qwen3-VL-8B plus SAM2 sur le split WeRefMat à prompts linguistiques.

Il y a un autre cas où WeVisOne avance une affirmation qui mérite d’être notée : l’absence. Tencent rapporte un taux de rejet de 50,2 % sur RefCOCOg pour les requêtes dont la cible n’est pas dans l’image, contre 0,5 et 0,6 pour deux modèles de grounding spécialisés dans le même tableau. Si votre pipeline traite des milliers de recadrages et que la plupart ne contiennent rien qui vous intéresse, un modèle qui dit de manière fiable « absent » vous évite un classifieur en aval. La fiche de LFM2.5-VL-3B ne rapporte pas de chiffre de rejet comparable, il n’y a donc rien à mettre en regard — une lacune dans les preuves, pas une perte.

Rien de tout cela ne justifie d’en choisir un et de mettre l’autre au rebut, et il vaut la peine d’être honnête sur la place d’un routeur. OrcaRouter ne sert ni l’un ni l’autre des modèles ; aucun des deux ne figure dans notre catalogue, et aucun n’est hébergé à un endroit que nous puissions vérifier, en particulier pour WeVisOne. Ce que nous proposons, c’est la pile qui l’entoure : si votre pipeline utilise un modèle de vision hébergé pour la partie lecture et un modèle auto-hébergé pour la partie masquage, les appels hébergés passent par une clé API unique au prix catalogue du fournisseur, sans marge, le basculement automatique les déplace vers un autre fournisseur lorsque l’un se dégrade, et le DSL de routage vous permet de placer les deux moitiés derrière un point de terminaison unique afin que votre application ne sache jamais lequel a répondu.

Qu’est-ce qui réglerait vraiment la question ?

Un banc d’essai indépendant, exécuté par quelqu’un qui n’est ni l’un ni l’autre des fournisseurs, sur les mêmes images, rapportant à la fois une statistique de détection et une statistique de segmentation pour les deux modèles. Cela n’existe pas. Tant que ce n’est pas le cas, la position défendable est la plus banale : ces modèles répondent à des questions différentes, leurs chiffres publiés sont mesurés avec des instruments différents, et le choix entre eux se décide en fonction de ce que votre code en aval s’attend à recevoir — une phrase, ou un masque.

Si vous ne devez retenir qu’une chose de cette comparaison, retenez la forme des preuves. Liquid AI vous a fourni un tableau que vous pouvez réfuter. Tencent vous a fourni un article que vous pouvez lire et une fiche qui vous indique, sans détour, ce que le modèle ne fera pas. Aucun des deux ne vous a donné un chiffre que l’on puisse comparer à celui de l’autre, et tout article qui affiche 87,9 à côté de 79,7 sans cet avertissement vous vend un classement qui n’existe pas.