LFM3-VL-2B vs WeVisOne-VL-4B : ce que 2,5× plus de paramètres apporte réellement

Le propre tableau de benchmarks de Tencent plaide contre l’achat évident. WeVisOne-VL-4B, le plus grand des deux modèles de perception publiés par l’équipe WeChat Vision le 22 octobre 2026, est moins performant en matte alpha guidé par boîte que son propre frère de 2 B : 7,3 de différence absolue moyenne sur P3M-500-NP, contre 6,6 pour le 2B, une valeur plus faible étant meilleure. Toutefois, le modèle auquel la plupart des acheteurs le compareront réellement n’est pas son frère, mais LFM3-VL-2B — le modèle de vision embarqué de 1,92 B de Liquid AI, dont les poids sont apparus le 19 octobre et qui a été annoncé avec le reste de la famille LFM3 le 27 octobre.

Mettez ces deux-là côte à côte, et la question intéressante n’est pas de savoir lequel est le plus intelligent. C’est ce que vous apportent deux fois et demie plus de paramètres, et ce que cela coûte. La réponse courte, d’après les propres tableaux des fournisseurs : ils apportent une détection dense, une précision de désignation et un bien meilleur taux de refus de répondre lorsque l’objet n’est pas là. Ils n’apportent pas un généraliste, ils n’apportent pas la vidéo, et ils n’apportent pas un modèle que l’on peut mettre sur un téléphone. Tout ce qui suit provient des deux tableaux publiés, avec les coutures bien visibles — aucun banc d’essai indépendant n’a reproduit les chiffres de l’un ou l’autre modèle.

Ce que chacun est réellement

LFM3-VL-2B est un modèle dense de 1,92 Md de paramètres : un socle linguistique de 1,73 Md, un encodeur visuel interne de 164 M et un projecteur de 25 M. Le socle repose sur la pile tri-hybride de Liquid — 24 couches réparties en 13 convolutions courtes à porte, 5 couches d’attention à fenêtre glissante avec une fenêtre de 256 tokens, et 6 couches d’attention globale. Il accepte du texte, des images et de la vidéo en résolution native, échantillonne la vidéo à 2 images par seconde, dispose d’un contexte de 128K tokens, couvre 16 langues et propose un mode réflexion facultatif qui produit une passe de raisonnement avant la réponse. Sa sortie est de la prose.

WeVisOne-VL-4B repose sur une base Qwen3-VL et porte le nom 4B, bien que les métadonnées Hugging Face l'arrondissent à 5B et que les articles de tiers situent le décompte réel près de 4,83B. Il ne répond pas tant en prose qu'il n'émet de la géométrie : des boîtes et des points sous forme de tokens de coordonnées normalisés de 0 à 1000, un marqueur OBJ (id de token 152678) après chaque boîte prédite, et la chaîne littérale None lorsque la cible est absente. Les masques et les alpha mattes nécessitent un second artefact, mask_decoder.pt, un décodeur de pixels de 9,6M de paramètres qui prend l'état caché de chaque token OBJ et la boîte prédite, et renvoie un alpha pleine résolution au stride 1. Il fonctionne en un seul tour et uniquement sur image, et génère directement une sortie structurée, sans chaîne de pensée.

Le contraste en une seule passe :

• Taille — LFM3-VL-2B 1,92 B dense contre WeVisOne-VL-4B environ 4,83 B, plus un décodeur de 9,6 M indispensable pour les masques

• Entrée — texte, image et vidéo à 2 fps vs texte et une seule image

• Sortie — prose et passe de raisonnement vs tokens de coordonnées, boîtes, masques, caches, ou un None explicite

• Contexte — 128K tokens contre aucune limite d’inférence publiée sur la fiche ; l’article décrit un entraînement à 4,096 et 8,192 tokens

• Couverture linguistique — 16 langues mentionnées contre aucune mention

• Licence — LFM Open License v1.0, gratuite pour un usage commercial en dessous de 10 M$ de chiffre d'affaires annuel, contre Apache 2.0 pour le code écrit par Tencent

• Exécution — GGUF/llama.cpp, MLX 4 bits, ONNX et BF16 vs BF16 via Transformers, vLLM ou SGLang

La mise à niveau est inégale, et l’article montre où.

WeVisOne-VL-2B et WeVisOne-VL-4B partagent la même architecture à deux échelles, sont entraînés sur les mêmes ~100 M images environ selon le même programme en trois étapes, et évalués sur le même tableau. La comparaison entre ces deux modèles frères constitue donc la preuve la plus nette dont on dispose sur ce que font les paramètres supplémentaires — et elle ne va pas dans une seule direction.

Là où le 4B l'emporte clairement, selon les chiffres de Tencent :

• Détection Dense200 — F1 moyen de 71,3 contre 61,4, le gain individuel le plus important

• LVIS — 55,3 vs 53,3, une modeste amélioration de 2 points

• Détection référentielle RefCOCOg — 81,8 en test vs 78,2

• Segmentation référentielle RefCOCO — 84,5 cIoU sur testA contre 82,9

• ReasonSeg — 71,2 cIoU sur val contre 60,9, un bond de 10 points en segmentation raisonnée

• Pointage PointBench — 71,9 vs 62,9

• Matting référentiel WeRefMat — 9,8 d’écart absolu moyen sur le sous-ensemble référentiel contre 15,8, soit une réduction de l’erreur de 38 %

Là où ce n'est pas le cas :

• P3M-500-NP matage du boîtier — 7,3 contre 6,6 pour la 2B, moins bien

• Détourage de boîtes PPM-100 — 6,1 contre 5,3, pire

• Ref-ZOM cIoU — 72,2 en test contre 73,4, le 2B repasse devant

Le schéma est lisible même si la cause n’est pas publiée : le {{1}}4B{{/1}} prend l’avantage sur les tâches difficiles et conditionnées par le langage — segmentation par référence, segmentation par raisonnement, matting par référence sur des scènes réelles — et n’apporte rien en retour sur les ensembles de matting plus faciles pilotés par boîte, où les deux modèles sont déjà proches du plafond et où le {{2}}décodeur 9,6 M{{/2}} pourrait faire l’essentiel du travail. Deux des trois benchmarks de matting pilotés par boîte évoluent dans le mauvais sens. Si le {{3}}matting alpha{{/3}} sur une boîte fournie est votre seule tâche, le {{4}}4B{{/4}} n’est pas une mise à niveau ; c’est une façon plus coûteuse d’obtenir la même réponse, légèrement moins bonne.

Objets absents : mieux, mais toujours pas résolu

La colonne la plus utile de l'article est celle que presque aucune fiche de modèle de vision ne publie. RefCOCOg-Rej est une variante dans laquelle chaque expression est modifiée de sorte que aucun objet correspondant n'existe dans l'image. Un modèle incapable de dire « non » inventera une boîte, et chaque recadrage, comptage et masque en aval héritera de cette fabrication.

WeVisOne-VL-4B rejette correctement dans 67,4 % des cas, contre 50,2 % pour le 2B. Il s’agit d’une amélioration réelle et importante — un gain de 17 points qui fait passer le mode de défaillance d’un pipeline du pile ou face à deux fois sur trois. Cela signifie aussi que le 4B renvoie encore une boîte de détection confiante pour environ une requête sur trois portant sur un objet absent. Sur WeRef-Bench, le benchmark interne de Tencent, le taux de rejet atteint 96,4 %, mais ce benchmark compte 2 880 requêtes en anglais et en chinois créées par le laboratoire lui-même ; il mesure donc une distribution plus favorable que celle du benchmark public. Le résumé honnête est que le modèle dispose d’un comportement d’abstention exploitable et qu’il n’a pas résolu le problème ; si votre application ne peut pas tolérer une région hallucinée, il faut ajouter un seuil ou un contrôle supplémentaire par-dessus, quel que soit le modèle choisi.

Le nombre qui semble comparable et qui ne l'est pas

Il est tentant de placer le 90,5 RefCOCO-avg de LFM3-VL-2B à côté du 81,8 RefCOCOg de WeVisOne-VL-4B et d’annoncer une victoire de 8,7 points pour le modèle plus petit. Ne le faites pas. Ce sont des découpages différents et des métriques différentes : Liquid rapporte une moyenne sur la famille RefCOCO, Tencent rapporte le F1 test RefCOCOg pour la détection référentielle. Les soustraire produit un nombre sans référent.

Le même piège se retrouve dans l’OCR. LFM3-VL-2B obtient 86,3 sur OCRBench v1, un composite de reconnaissance de texte, de repérage et de raisonnement ; WeVisOne-VL-4B obtient une moyenne F1 de 52,0 sur TotalText, un benchmark de localisation de texte en scène. L’un est un examen général, l’autre une tâche de prédiction dense. Ce n’est pas la même compétence mesurée deux fois.

Ainsi, les deux tableaux fournisseurs ne se recoupent pas sur un seul chiffre comparable à l’identique. Ce qui peut être comparé honnêtement, ce sont les capacités et le coût, et c’est pourquoi le reste de cette comparaison porte sur l’adéquation plutôt que sur le classement. Quiconque désigne un vainqueur à partir de ces deux tableaux l’invente.

La mémoire est le vrai prix

Aucun des deux modèles n’a de prix publié par token au 28 octobre 2026. La fiche de Liquid renvoie à l’accès API et Playground via sa console, mais aucune grille tarifaire n’a été publiée pour LFM3-VL-2B ; les outils de suivi tiers qui répertorient les tarifs des modèles texte de Liquid ne couvrent pas le modèle vision. Tencent n’a aucun point de terminaison hébergé. La comparaison est donc une comparaison d’auto-hébergement, et la facture est libellée en mémoire.

• LFM3-VL-2B — environ 3,84 Go en BF16 par calcul à partir du nombre de paramètres, avec des versions 4 bits MLX, GGUF et ONNX publiées en parallèle

• WeVisOne-VL-4B — environ 9,7 Go en BF16 selon des estimations de tiers, environ 19 Go en F32, plus le fichier mask_decoder.pt requis

Cet écart de 2,5× ne tient pas simplement à un GPU plus gros. C’est une autre catégorie d’appareil. La fiche de la LFM3-VL-2B indique explicitement que le modèle est conçu pour fonctionner sur l’appareil — les questions sur la vidéo, les documents, les graphiques et les écrans d’applications, la recherche d’objets, le raisonnement spatial pour les robots — et les versions MLX 4 bits et GGUF sont ce qui permet de tenir cette promesse : un ordinateur portable, un téléphone, un châssis de robot. Les chemins documentés de WeVisOne-VL-4B sont Transformers, vLLM et SGLang en BF16, sans version quantifiée officielle ni environnement d’exécution embarqué. Il lui faut un GPU de serveur.

Il vaut mieux vérifier la prise en charge par le framework par rapport à votre propre configuration plutôt que dans le tableau. La vidéo à 2 fps est une capacité du modèle dans LFM3-VL-2B, mais savoir si un runtime donné accepte une grille vidéo est une question distincte, et la fiche du modèle, les portages et les PR en amont ne se sont pas toujours accordés sur ce point. Testez la combinaison exacte que vous comptez livrer.

OrcaRouter n'héberge aucun des deux modèles. Cela a été vérifié dans le catalogue le 28 octobre 2026, et non supposé — ni la gamme LFM3 de Liquid ni WeVisOne de Tencent n'apparaissent dans la liste des modèles — donc rien ici ne doit être interprété comme une voie d'accès à l'un ou l'autre. Ce que le catalogue de modèles OrcaRouter propose, en revanche, c'est Qwen3-VL-8B, en variantes instruct et thinking, ce qui constitue l'option pragmatique si votre besoin réel est un modèle de vision hébergé avec un prix publié aujourd'hui plutôt qu'un checkpoint auto-hébergé. Une seule clé donne accès à tout cela au prix catalogue du fournisseur, sans marge, et si vous prototypez avec un modèle open-weight non éprouvé, le faire passer par un routeur avec basculement est préférable à câbler un chemin de production vers un checkpoint qui n'a pas encore fait l'objet d'une évaluation indépendante.

Lequel choisir

• Choisissez WeVisOne-VL-4B lorsque le livrable est de la géométrie — masques, mattes alpha, boîtes denses, comptages, pointage — sur des images fixes, lorsque les requêtes sont conditionnées par le langage plutôt que par des boîtes, et lorsque vous avez un GPU à consacrer

• Choisissez WeVisOne-VL-2B plutôt que le 4B lorsque votre tâche est le détourage avec invite de boîte sur des scènes ordinaires ; d’après les chiffres publiés, le plus petit modèle y est meilleur et consomme moins de la moitié de la mémoire

• Choisissez LFM3-VL-2B lorsque l’entrée inclut une vidéo, lorsque le document est long, lorsque la réponse doit être une phrase plutôt qu’un polygone, ou lorsque l’appareil n’est pas un serveur

• Ne choisissez ni l’un ni l’autre si vous avez besoin cette semaine d’un point de terminaison hébergé avec un tarif publié par token — aucun des deux fournisseurs n’en propose, et aucun benchmarking, aussi poussé soit-il, ne comble cet écart.

Choisissez les deux uniquement si vous acceptez deux schémas de sortie et deux chemins d’intégration ; la bande de paramètres commune « environ 2B à 5B » masque deux produits différents.

Qu’est-ce qui changerait cela ?

Trois choses. Un banc de test indépendant qui exécute les deux modèles sur les mêmes images avec les mêmes prompts — d’ici là, tout ce qui précède est un tableau fournisseur lu attentivement, ce qui vaut mieux qu’un tableau fournisseur lu négligemment, mais ne constitue pas une preuve de qualité. Une build quantifiée de WeVisOne, ou un runtime embarqué, ce qui ferait passer l’argument mémoire de décisif à négociable. Et un prix par token publié par l’une ou l’autre des parties, qui remplacerait une arithmétique en gigaoctets par un chiffre sur lequel on peut établir un budget.

Le moins probable des trois est celui qui compterait le plus pour cette association spécifique : la prise en charge de la vidéo dans le décodeur de pixels de WeVisOne. Actuellement, le généraliste 2B accepte une vidéo et l’instrument 4B ne le peut pas, et aucun nombre de paramètres ne corrige une modalité qui n’a jamais été entraînée.