WeVisOne-VL-4B vs MiniCPM-V 4.7 1B : deux paris opposés sur la fonction d’un token visuel

MiniCPM-V 4.7 1B obtient 86,1 sur OCRBench. WeVisOne-VL-4B obtient 52,0 sur TotalText. Placez ces deux chiffres côte à côte et le modèle 1B semble battre le modèle 4B de trente-quatre points en lecture de texte — ce qui serait un résultat remarquable, et constitue aussi une erreur de catégorie. OCRBench mesure si un modèle peut transcrire les caractères d’une image. TotalText, tel que Tencent le rapporte, mesure le F1 pour la localisation de chaque instance de texte sur des seuils d’IoU allant de 0,5 à 0,95. L’un relève de la reconnaissance, l’autre de la géométrie. MiniCPM-V 4.7 1B et WeVisOne-VL-4B sont sortis à neuf jours d’intervalle en octobre 2026, tous deux de laboratoires chinois, tous deux sous Apache 2.0, et ils ont des conceptions fondamentalement opposées quant à la fonction des tokens visuels : l’un les compresse jusqu’à les éliminer, l’autre les consacre à la précision.

Ce désaccord, c’est toute la comparaison. Tout le reste — nombres de paramètres, mémoire, lignes de benchmarks — en découle.

Compression contre précision

MiniCPM-V 4.7 1B hérite d’un schéma de compression précoce intra-ViT de LLaVA-UHD v4 et l’expose sous forme de bascule d’exécution entre une compression de jetons visuels de 4× et de 16×. L’objectif est de faire tenir plus d’image, et plus de vidéo, dans un budget fixe : la fiche modèle annonce un contexte de 262 144 jetons, 128 images vidéo par défaut et un schéma de tuilage 448×448 avec un nombre de tranches configurable. Compresser tôt, garder la séquence courte, et un modèle 1B peut regarder une longue vidéo sur un téléphone.

WeVisOne-VL-4B fait le choix opposé. Son évaluation s’exécute à hauteur de 1 960 jetons visuels par image, et son décodeur de pixels opère sur les caractéristiques ViT avant fusion, en conservant délibérément le détail haute résolution que la compression précoce élimine. C’est pourquoi il peut produire un masque alpha en pleine résolution avec un pas de 1, et pourquoi il ne peut pas du tout traiter une grille vidéo : le décodeur la rejette. La précision coûte des jetons, et les jetons coûtent de la latence.

Aucun des deux paris n’est faux. Ce sont des réponses à des questions différentes. MiniCPM demande « combien puis-je voir d’un coup sur un téléphone ? » WeVisOne demande « avec quelle exactitude puis-je décrire où se trouve une chose ? »

L'histoire de la taille est plus étrange que 1B contre 4B

• Paramètres — WeVisOne-VL-4B dense de 4,83B contre MiniCPM-V 4.7 1B nommé 1B, bien que les métadonnées de son dépôt indiquent 2B en BF16

• Format des poids — safetensors F32 à environ 19 Go contre BF16 à environ 3,1 Go, ou 0,67 Go en Q4_K_M plus un projecteur vision de 0,90–1,11 Go

• Contexte — non publié pour WeVisOne-VL-4B, contre 262 144 tokens sur le papier pour MiniCPM-V 4.7 1B

• Vidéo — rejetée par le décodeur de pixels vs 128 images par défaut

• Entrée multimodale — une seule image par tour vs image et vidéo

• Quantisation — aucune version fournie par le fournisseur vs variantes int4, AWQ, GPTQ, GGUF et FP8

• Environnements d’exécution sur l’appareil — aucun vs iOS, Android, HarmonyOS, ainsi que llama.cpp et Ollama

• Licence — Apache 2.0 pour le code rédigé par Tencent vs Apache 2.0

C’est la ligne consacrée à la mémoire qui recadre la comparaison. Un modèle 1B en quatre bits tient dans moins d’un gigaoctet avant le projecteur de vision ; un modèle 4,83B en F32 en requiert environ dix-neuf. Ce ne sont pas des concurrents pour le même emplacement. L’un est un composant que vous embarquez dans une application ; l’autre est un service que vous exécutez sur un GPU.

Lire les lignes du benchmark sans se faire d’illusions

Les deux fournisseurs ont publié des tableaux, et ces deux tableaux sont auto-sélectionnés. MiniCPM-V 4.7 1B annonce 86,1 sur OCRBench, 74,3 sur MathVista, 48,8 sur CharXiv Reasoning, 53,4 sur LongVideoBench et 54,55 sur MotionBench. WeVisOne-VL-4B annonce un F1 moyen de 55,3 sur LVIS, 81,8 sur RefCOCOg test, 89,6 sur PixMo-Count test, un F1 moyen de 52,0 sur TotalText, un gIoU de 71,2 sur ReasonSeg val et un MAD de 7,3 sur P3M-500-NP. Aucun benchmark n’apparaît dans les deux listes. Il n’existe aucun moyen défendable de désigner un vainqueur à partir de ces documents, et tout article qui prétend le faire invente un résultat.

La lecture équitable est plus étroite et reste utile. MiniCPM-V 4.7 1B est exceptionnellement fort en raisonnement sur les images pour sa taille — un 74,3 sur MathVista de la part d’un modèle qui tient dans un téléphone est le chiffre dont ses auteurs sont les plus fiers, et il est rapporté par le fournisseur et non reproduit. WeVisOne-VL-4B est exceptionnellement fort pour produire de la géométrie — masques, mattes, boîtes, et un taux de refus mesuré de 96,4 % sur WeRef-Bench lorsque l’objet n’est pas présent. La fiche de MiniCPM ne publie aucune métrique de rejet, et celle de WeVisOne ne publie aucun benchmark de raisonnement. Chaque modèle est silencieux exactement là où l’autre est bruyant.

Ce que chacun ne peut pas faire

WeVisOne-VL-4B ne peut pas regarder une vidéo, ne peut pas tenir une conversation multi-tours sur une image et ne peut pas fonctionner sur un téléphone. Il n'a publié aucun chiffre de tokens par seconde ni aucune version quantifiée, ce qui signifie que quiconque le déploie s'engage sur un GPU et doit évaluer lui-même son débit. Le code de fine-tuning reste une case non cochée sur la liste TODO du projet.

MiniCPM-V 4.7 1B ne peut pas renvoyer de masque ni d’alpha matte. Il vous indiquera qu’une personne se trouve dans l’image et approximativement où ; il ne vous fournira pas un détourage à bords doux. Il présente également les risques habituels d’une toute nouvelle famille de modèles : un nouveau model_type dans Transformers, une exigence de version minimale de 5.18.0, et des premiers signalements de problèmes de décodage vidéo dans certaines combinaisons de CUDA et torchcodec. Son contexte de 262K est un chiffre sur le papier — il n’a pas été démontré que le post-entraînement l’exploite pleinement.

Le coût d'un second appel

En pratique, ces deux modèles ne sont pas interchangeables, et l’architecture intéressante utilise les deux : un petit modèle peu coûteux pour décrire l’image et raisonner à son sujet, et un modèle de perception pour renvoyer la géométrie. On passe ainsi d’un appel d’inférence à deux, et c’est là que le coût cesse d’être un détail.

L’apport d’OrcaRouter à cette configuration est le plus ennuyeux, mais c’est celui qui compte — une seule clé pour plus de 200 modèles, avec le prix catalogue du fournisseur répercuté avec une marge de 0 % et un basculement automatique lorsqu’un point de terminaison amont se dégrade. Une baisse de prix d’un fournisseur côté généraliste arrive de notre côté le jour même, car il n’y a pas de couche de marge à mettre à jour. Ni WeVisOne-VL-4B ni MiniCPM-V 4.7 1B ne figurent dans ce catalogue aujourd’hui, donc la moitié « perception » du pipeline reste quelque chose que vous hébergez. Ce que vous évitez, c’est un second contrat et un second jeu d’identifiants pour la moitié qui l’est.

Comment vous exécuteriez l’un ou l’autre

WeVisOne-VL-4B est l'installation la plus exigeante. La fiche du modèle documente Transformers, vLLM, SGLang et Docker Model Runner, mais mask_decoder.pt est un composant obligatoire : si vous chargez le checkpoint sans le package d'inférence du projet, vous obtenez des boîtes et du texte, mais pas de masques. Le décodage est glouton, avec jusqu'à 1 960 tokens visuels par image, et aucun chiffre de débit n'est publié ; la première chose que vous ferez donc sur votre propre matériel sera de le mesurer.

MiniCPM-V 4.7 1B est le plus simple. Il nécessite Transformers 5.18.0 ou une version plus récente, et l’écosystème est arrivé avec — les builds llama.cpp, Ollama, SGLang et vLLM, ainsi que les quantifications int4, AWQ, GPTQ et FP8, et un modèle draft DSpark séparé de 213 M de paramètres pour le décodage spéculatif. Si votre cible est un téléphone, une machine Intel ou une carte Rockchip, c’est le chemin tout tracé.

Quel pari prendre

Si la contrainte est l’appareil, prenez MiniCPM-V 4.7 1B. Rien dans WeVisOne-VL-4B n’est conçu pour un téléphone, et la quantification, la prise en charge de l’exécution et le traitement vidéo du côté MiniCPM sont le fruit d’un laboratoire qui a livré plusieurs générations de modèles embarqués.

Si la contrainte, c’est la sortie — il vous faut des masques, des mattes, des boîtes denses pour petits objets, ou une réponse fiable « absent » — prenez WeVisOne-VL-4B et prévoyez le budget nécessaire pour le GPU. Sachez que vous travaillez à partir d’un article vieux de deux jours, sans évaluation indépendante, et que les chiffres de matting sont ceux de Tencent.

Si vous avez besoin des deux, il vous faut deux modèles. C’est la conclusion honnête, et c’est celle que confirment les propres tableaux de benchmarks des deux fournisseurs : ils ont optimisé des choses différentes et aucun n’a cherché à surpasser l’autre.