WeVisOne-VL-4B vs LFM2.5-VL-3B : un spécialiste du détourage face à un as de la vitesse sur l’edge

Liquid AI publie une mesure de vitesse pour LFM2.5-VL-3B, et Tencent n’en publie aucune pour WeVisOne-VL-4B. C’est cette asymétrie, plus que n’importe quelle ligne de benchmark, qui définit le duel. LFM2.5-VL-3B est un modèle edge de 3,1 milliards de paramètres, optimisé pour répondre en une seule passe : 228 tokens par seconde sur un Apple M5 Max, 20 tokens par seconde sur un Galaxy S26 Ultra, moins de 3,3 Go de mémoire, seize langues. WeVisOne-VL-4B est un modèle de perception de 4,83 milliards de paramètres qui dépensera jusqu’à 1 960 tokens visuels et un décodeur de 9,6 M de paramètres pour vous fournir un masque alpha en pleine résolution. L’un est conçu pour être assez rapide pour s’intégrer à l’interface d’un téléphone ; l’autre est conçu pour produire des pixels. Ils ne se recoupent que sur le mot « vision » et presque nulle part ailleurs.

Cela fait de cette comparaison une comparaison qui vaut la peine d’être menée avec soin, car la version évidente — mettre les tableaux de référence côte à côte, déclarer un gagnant — serait erronée d’une manière précise et instructive.

Les tableaux de référence ne communiquent pas entre eux.

Les deux modèles publient des résultats sur les expressions référentielles, et ces deux résultats semblent comparables. Ils ne le sont pas. LFM2.5-VL-3B rapporte un P@1 moyen RefCOCO de 87,9. WeVisOne-VL-4B rapporte un F1 moyen de 81,8 sur le test RefCOCOg. Découpage de jeu de données différent, métrique différente, modèle de défaillance différent : P@1 demande si la boîte classée en tête est correcte, tandis que le F1 moyen fait la moyenne de la précision et du rappel sur des seuils IoU de 0,5 à 0,95. Un modèle peut gagner sur l’un et perdre largement sur l’autre sans que l’un ou l’autre résultat soit surprenant.

Le même piège se retrouve dans toutes les autres lignes. Le 80,7 de Liquid sur ScreenSpot-v2 mesure l’ancrage des éléments d’interface ; Tencent n’a aucun chiffre ScreenSpot. Le taux de rejet de 96,4 % de Tencent sur WeRef-Bench mesure si le modèle refuse de répondre lorsque l’objet n’est pas présent ; Liquid ne publie aucune métrique de rejet. Aucun des deux fournisseurs n’a évalué le modèle de l’autre, donc aucune ligne de l’un ou l’autre tableau n’est une comparaison directe.

Ce qui peut être dit honnêtement est indicatif. LFM2.5-VL-3B est un solide généraliste pour sa taille — une moyenne de 69,4 sur 28 benchmarks de vision selon le décompte de Liquid, à 0,7 point de Qwen3.5-4B — et son bond sur ScreenSpot-v2, de presque zéro dans la génération précédente à 80,7, constitue la plus forte amélioration unique de son tableau. WeVisOne-VL-4B ne rivalise pas sur cet axe. Ses arguments les plus forts portent sur la détection dense de petits objets, le rejet et la sortie au niveau du pixel, trois domaines que LFM2.5-VL-3B n'aborde pas.

Ce que chaque modèle est physiquement

• Paramètres — WeVisOne-VL-4B 4,83 B dense (point de contrôle F32) vs LFM2.5-VL-3B 3,12 B dense (BF16)

• Branche vision — un backbone Qwen3-VL accompagné d’un décodeur de 9,6 M de pixels, contre une base textuelle hybride convolution-attention LFM2.5-2.6B accompagnée d’un encodeur SigLIP2 NaFlex 400M

• Mémoire — environ 19 Go sur disque pour le checkpoint F32 4B, contre moins de 3,3 Go d’empreinte totale pour le 3B

• Contexte — aucune valeur publiée pour WeVisOne-VL-4B par rapport à 32 768 jetons pour LFM2.5-VL-3B

• Langues — non précisé pour WeVisOne-VL-4B contre 16 pour LFM2.5-VL-3B, avec un vocabulaire de 128K conçu pour les écritures non latines

• Types de sortie — boîtes, points, masques et mattes alpha, par rapport à des boîtes et du texte uniquement

• Licence — Apache 2.0 pour le code rédigé par Tencent vs la LFM Open License v1.0

• Vitesse — non publiée vs 228 tok/s sur un M5 Max, 116 tok/s sur un Ryzen AI Max+ 395, 20 tok/s sur un Galaxy S26 Ultra

L'écart de capacités qui tranche réellement la question

LFM2.5-VL-3B peut vous indiquer où se trouve une personne dans une image. WeVisOne-VL-4B peut vous indiquer où se trouve une personne, renvoyer un masque binaire pour cette instance et renvoyer un matte alpha continu avec des bords doux — cheveux, poils, tissus transparents, flou de mouvement — en pleine résolution. C’est une différence catégorielle, pas une différence de qualité. Si votre produit doit composer un sujet sur un nouvel arrière-plan, détourer la photo d’un produit ou piloter le remplacement d’arrière-plan d’un appel vidéo, LFM2.5-VL-3B n’a rien à vous offrir et aucun travail d’ingénierie de prompt n’y changera quoi que ce soit.

Faites la comparaison dans l’autre sens et vous obtenez le même résultat. Si votre produit doit trouver un bouton sur l’écran d’un téléphone en 40 millisecondes, WeVisOne-VL-4B n’est absolument pas adapté : c’est un modèle de 4,83 Md sans chiffre de latence publié, sans versions quantifiées pour l’edge et avec un décodeur qui suppose une seule image par tour. Liquid propose des versions GGUF, MLX, ONNX et natives, ainsi qu’un contexte de 32 K et des benchmarks d’appel d’outils. Tencent propose un package d’inférence pour la recherche et un service vLLM/SGLang.

Le rejet est la rubrique sous-estimée.

Une capacité du tableau de Tencent mérite de retenir l’attention même si vous ne touchez jamais au détourage. Sur WeRef-Bench, WeVisOne-VL-4B rejette correctement 96,4 % des requêtes portant sur des objets qui ne figurent pas dans l’image, contre 73,0 % pour le meilleur modèle de référence listé par les auteurs ; sur PR-Bench, le taux de rejet est de 52,6 % contre 10,8 % pour Qwen3-VL-4B. Le modèle renvoie None plutôt que d’inventer une boîte. Un détecteur qui hallucine est pire qu’aucun détecteur, car la défaillance est silencieuse et le code en aval lui fait confiance.

La documentation de LFM2.5-VL-3B ne rapporte aucun chiffre de rejet, il n’y a donc rien à comparer — et c’est précisément là tout l’enjeu. L’absence de preuve n’est pas un échec, mais si vous construisez un agent qui décide s’il faut cliquer sur quelque chose, la présence d’un taux de rejet mesuré est une véritable raison d’examiner d’abord le modèle de Tencent.

Les licences sont le différenciateur discret

C'est ici que les deux divergent d'une manière qui compte pour quiconque commercialise son produit. Les poids de WeVisOne-VL-4B sont sous Apache 2.0 pour le code écrit par Tencent, les composants tiers conservant leurs propres conditions. LFM2.5-VL-3B est distribué sous LFM Open License v1.0, gratuite pour un usage commercial en dessous d'un seuil de chiffre d'affaires et nécessitant un accord commercial au-delà. Si vous êtes une petite équipe, la différence est théorique. Si ce n'est pas le cas, l'une de ces options implique une revue juridique et l'autre, une simple ligne dans un fichier de dépendances.

Aucune des deux licences ne vous accorde un service hébergé. WeVisOne-VL-4B n’a aucune API ; LFM2.5-VL-3B est une publication de poids, et tout hébergement par un tiers relève d’un accord distinct. Le dire clairement compte plus qu’avant, car un modèle sans point de terminaison est un engagement à posséder la pile d’inférence.

Là où OrcaRouter est pertinent, et là où il ne l'est pas

Aucun de ces deux modèles ne figure aujourd’hui au catalogue d’OrcaRouter, donc rien ici ne permet de les appeler. Ce que la plateforme propose, c’est tout ce qui entoure la décision. La plupart des équipes qui évaluent un VLM edge de 3B ne remplacent pas un modèle par un autre : elles ajoutent un second modèle à côté du modèle généraliste déjà en production, et le coût opérationnel d’un second contrat fournisseur, d’une seconde clé et d’un second mode de défaillance tue généralement l’expérience avant même que le modèle ne le fasse.

Router les deux intentions via un seul point de terminaison, avec plus de 200 modèles derrière une seule clé, à 0 % de marge sur le prix catalogue du fournisseur, signifie que le modèle de perception peut être une décision de routage plutôt qu’un projet d’intégration. Si le modèle en périphérie n’est pas disponible, le basculement automatique envoie la requête ailleurs au lieu de renvoyer une erreur 503. C’est la partie qu’OrcaRouter résout réellement ici ; les poids et le GPU restent les vôtres.

Lequel choisir

Choisissez LFM2.5-VL-3B si la tâche est limitée par la latence et de nature textuelle : compréhension d’écran, agents d’interface utilisateur, OCR de documents avec mise en page, traduction embarquée, appel d’outils. Il est plus rapide que presque tout ce qui existe à sa taille, il tient dans le budget mémoire d’un téléphone, et Liquid a publié suffisamment de chiffres pour que vous puissiez vérifier les affirmations par rapport à votre propre charge de travail.

Choisissez WeVisOne-VL-4B si la tâche se joue au niveau des pixels. Segmentation, matting, détection dense de petits objets, ou tout pipeline où « le modèle a dit non » doit être une réponse fiable. Acceptez d’être un early adopter : aucun benchmark indépendant n’existe, aucun endpoint hébergé n’existe, le code de fine-tuning est encore sur la liste des TODO, et l’article date de deux jours.

La seule chose à ne pas faire est de trancher entre eux à partir d’un seul score de benchmark. Personne ne les a comparés les uns aux autres, sur les mêmes données.