WeVisOne-VL-4B trouve, compte et détoure des objets avec un seul modèle, et chaque tâche a tourné sur une vraie carte de 16 GB
WeVisOne-VL-4B de Tencent sur notre cloud : boîtes, comptages, OCR et détourages au cheveu près, 1 s par détourage sur RTX 4090, les 7 tâches sur 16 GB.
L'échiquier du dossier d'exemples de Tencent porte seize pièces blanches. WeVisOne-VL-4B, lancé deux fois sur une RTX 4090 avec le même prompt, a répondu 15 en 1,35 seconde et 16 en 3,87 secondes. La réponse rapide a oublié le cavalier en g5. Même modèle, deux façons de le faire tourner, et cet écart est le choix à faire avant de le mettre derrière un produit. Prendre la version rapide et vérifier ses comptages, ou la lente, qui tient aussi sur une carte de 16 GB. Dans les deux cas, un seul modèle ouvert de 4 milliards de paramètres a trouvé des objets nommés, les a comptés, a pointé, a lu du texte et a détouré une personne sur une photo jusqu'aux cheveux. Ses auteurs le présentent comme un tout-en-un. Le servir derrière une API demande un backend sur mesure, et celui que nous avons écrit est en lien à la fin.
Même modèle, même photo, même prompt. Le moteur rapide (à gauche) est ici environ trois fois plus rapide, et il a raté une pièce. Le moteur de référence est à droite.
Un seul modèle 4B fait le travail d'un détecteur, d'un segmenteur et d'un outil de détourage
WeVisOne-VL ("WeChat Vision All-in-One") réunit dans un seul modèle les tâches qui demandent d'habitude une chaîne de trois. Le premier maillon dessine des boîtes autour des choses que vous nommez, par exemple GroundingDINO, auquel les auteurs se comparent. Un deuxième, comme SAM2, transforme chaque boîte en contour. Un troisième fait un détourage doux, celui qui garde les cheveux libres et les bords. Chacun est un téléchargement à part, une mémoire à part et une façon à part de casser.
L'équipe WeChat Vision de Tencent l'a construit sur un modèle ouvert d'Alibaba. D'après la fiche du modèle, il trouve tout ce que vous pouvez nommer, ou une chose décrite comme "the cat on the right". Il compte aussi, pointe, lit du texte avec sa position, dessine des contours et fait des détourages.
Le modèle écrit, un petit découpeur dessine. WeVisOne-VL répond en texte, et une position n'est que du texte en plus. Les auteurs ont ajouté 1 001 mots spéciaux, de <0> à <1000>, chacun une position sur la largeur ou la hauteur de l'image. Une boîte fait quatre de ces mots, un point deux. Pour les contours et les détourages, il étiquette chaque boîte, et un minuscule programme séparé lit ce que le modèle voit de cette étiquette et peint les pixels. Ce découpeur a 9,6 millions de paramètres, environ 500 fois moins que le modèle à côté duquel il travaille. La page du projet explique qu'aucun outil de contour séparé n'est nécessaire, parce que le découpeur réutilise ce que le modèle a vu.
L'équipe l'a entraîné sur environ 100 millions d'images, en utilisant SAM2 seulement pour dessiner les contours d'entraînement, pas à l'exécution. Elle a publié le 4B et un 2B, avec un paquet de code qui fait tourner les deux. Les dépôts Hugging Face ont été créés le 22 octobre 2026, et le commit de publication du code est daté du 23 octobre. Nous l'avons repéré dans la vidéo d'actualité d'AI Search du 25 octobre.
Les auteurs annoncent que le 4B arrive en tête sur plus de 30 benchmarks. Sur leur test de recherche d'objets nommés, il obtient 55,3 sur 100, contre 38,8 pour GroundingDINO. Sur les détourages de portraits, son erreur est moitié moindre que celle d'une installation basée sur SAM2 (7,3 contre 15,4). L'idée qu'il "remplace trois modèles" repose sur ces tableaux, pas sur une comparaison côte à côte que nous aurions faite.
Les poids sur Hugging Face sont sous Apache 2.0, qui autorise l'usage commercial. La fiche du modèle ajoute que "the release is intended for research" et qu'il n'est "not intended to make autonomous high-impact decisions or to identify individuals". Notre lecture : la concession Apache est la licence, les lignes sur l'usage prévu sont des recommandations, et celle sur l'identification des personnes compte si votre produit traite des visages.
Le test : le modèle tient dans environ 10 GB, et l'installation rapide le charge deux fois
L'installation rapide charge le modèle deux fois sur une seule carte. Le fichier publié pèse 19,3 GB parce qu'il stocke chaque nombre en pleine précision. Nous l'avons chargé en demi-précision, la façon habituelle de servir un modèle, ce qui le ramène à environ 10 GB. Le paquet de code peut le faire tourner de deux façons : un moteur rapide conçu pour le service, et le moteur de référence, plus simple. Même quand le moteur rapide écrit la réponse, le paquet garde une seconde copie dans le moteur de référence pour alimenter le découpeur.
Nous avons déployé le 4B via notre plateforme et lui avons envoyé les mêmes 14 requêtes, une image à la fois, dans chaque installation. Elles couvrent sept types de travail : trouver plusieurs choses nommées, compter, trouver une chose décrite (et en refuser une absente), pointer, lire du texte, faire un contour et détourer. Les images sont les exemples des auteurs plus des photos publiques. La plupart des exécutions ont utilisé une RTX 4090 de 24 GB de mémoire, et une vraie RTX 5080 de 16 GB a vérifié si une carte plus petite tient le coup.
Résultats : un détourage en pleine résolution en une seconde environ, et 'rien ici' quand il n'y a rien
Le détourage est le gros titre. Un portrait de 1620 par 1080 tiré des exemples des auteurs est revenu en détourage pleine résolution, et les mèches soulevées par le vent survivent.
Le reste, dans les temps qu'une personne ressent :
| Travail | RTX 4090, rapide | RTX 4090, référence | RTX 5080 16 GB, référence |
|---|---|---|---|
| Détourer une personne, 1620 x 1080 | 1,0 s | 1,1 s | 2,1 s |
| Trouver "the cat on the right" | 0,21 s | 0,55 s | 0,68 s |
| Compter 12 personnes | 0,78 s | 2,7 s | 2,8 s |
| Lire un panneau de rue (mots trouvés) | 3,7 s (29) | 9,1 s (21) | 9,5 s (22) |
| Trouver 5 types d'objets dans une cuisine | 1,9 s | 7,4 s | 8,3 s |
| Pic de mémoire de la carte (GiB) | 23,0 | 12,3 | 12,8 |
Temps sur la carte, d'après nos logs. Mémoire en GiB, l'unité qu'affiche la carte elle-même. Le nombre de mots trouvés sur le panneau varie selon l'installation.
Nous avons demandé "the dog" sur une photo de chats. Le modèle a répondu qu'il n'y en avait pas dans chaque installation testée, sur la seule photo que nous avons essayée, en 0,11 seconde sur le moteur rapide. Un détecteur qui invente un chien quand il n'y en a pas, c'est le bug qui fait qu'une équipe produit cesse de faire confiance à la fonctionnalité.
Sur la photo des auteurs montrant des garçons tenant des micros, il a encadré les deux chanteurs. Les boîtes de la cuisine, le point sur le receveur de baseball, le contour du vélo et les détourages du portrait et du chat étaient justes quand nous les avons vérifiés à l'œil. Nous n'avons pas vérifié le comptage des 12 joueurs de tennis contre une vérité de terrain.
Le moteur rapide est environ trois fois plus rapide sur les objets, et il s'est trompé sur l'échiquier
Sur les tâches d'objets, le moteur rapide est d'une fois et demie à quatre fois plus rapide, environ trois fois sur la plupart. Sur les détourages, le tableau est contrasté. Le contour du vélo était plus lent sur le moteur rapide (1,2 à 1,8 seconde contre 0,9).
Les deux moteurs utilisaient un décodage glouton, donc le raté sur l'échiquier n'est pas du bruit d'échantillonnage. La cause probable est que les calculs de bas niveau diffèrent légèrement entre les deux programmes, et qu'une boîte limite est tombée de l'autre côté. Ils ont aussi divergé sur le panneau de rue (29 mots contre 21) et sur les casseroles suspendues (19 contre 20). Un raté sur 14 requêtes n'est pas un taux. C'est une raison de tester vos propres images sur le moteur que vous allez livrer, comme on fait la balance sur la sono sur laquelle on va vraiment jouer.
Il y a un autre piège de vitesse. Sur le moteur rapide, la toute première requête après un démarrage a pris 14,5 à 15,5 secondes pour une détection qui en prend 1,9 ensuite. Envoyez une requête de chauffe avant le vrai trafic.
Là où il ne convient pas : la fiche du modèle prévient que les bords fins d'un détourage dépendent de la résolution, des parties cachées, de la transparence et de la formulation. Il répond à une question sur une image, et le découpeur refuse la vidéo.
Quel GPU : chaque tâche sur une vraie carte de 16 GB, et les détourages demandent plus de 12 GB
La plus petite carte qui a réussi chaque tâche était une vraie RTX 5080 de 16 GB, avec le moteur de référence. Elle était environ deux fois plus lente que le moteur rapide de la 4090 sur le gros détourage, et jusqu'à environ quatre fois sur les tâches d'objets. La carte de 24 GB de notre exécution principale est un choix de vitesse, pas une exigence.
| Carte | Installation | Résultat |
|---|---|---|
| RTX 4090 24 GB, réelle | 4B, moteur rapide plus copie de référence | 14 sur 14, la plus rapide |
| RTX 5080 16 GB, réelle | 4B, référence seule | 14 sur 14 |
| Environ 12,5 GB, émulée | 4B, référence seule | 13 sur 14 : seul le gros détourage du portrait échoue |
| 12 GB, émulée strictement | 4B, référence seule | Boîtes, comptages, points et texte marchent. Chaque contour et chaque détourage échoue |
Les résultats à 12 GB et 8 GB viennent d'un plafond de mémoire sur la 4090, pas de vraies cartes de ces tailles. Sous 16 GB, c'est le découpeur qui bloque. Il prend environ 0,8 GB d'un coup, quelle que soit la taille de la photo, donc sous le plafond strict il a échoué même sur une photo de 640 pixels. Le modèle 2B sous un plafond de 8 GB a réussi 12 sur 14 : le gros détourage a manqué de mémoire et une réponse de position de texte est revenue mal formée. Il a aussi trouvé 25 boîtes dans la cuisine là où le 4B en a trouvé 32. Ses petits détourages et le contour du vélo ont marché, mais nous n'avons pas comparé leur qualité avec le 4B, donc savoir si le 2B garde des détourages aussi propres n'a pas été testé.
Sur InferenceKey : un endpoint pour sept tâches, qui répond 87 secondes après un démarrage à neuf sur 16 GB
Une RTX 5080 neuve qui n'avait jamais vu le modèle répondait au bout de 87 secondes, téléchargement compris. Sur une 4090 avec le modèle déjà sur le disque, le moteur rapide était prêt en 49 à 82 secondes, le moteur de référence en 14 à 15.
Servir chaque tâche, découpeur compris, demande un backend sur mesure. C'est un petit programme Python que notre plateforme exécute sur votre machine GPU à la place d'un serveur de modèles standard. Un serveur standard ne renverrait que le texte, les boîtes et les points du modèle. Le découpeur vit en dehors, donc le nôtre pilote directement le paquet des auteurs, écrit avec un moteur et peint avec l'autre. Chaque réponse revient sous forme d'image avec les boîtes dessinées et les coordonnées brutes pour votre code, plus, pour les contours et les détourages, un détourage sur fond transparent.
Faites tourner le paquet des auteurs sur une carte de 24 GB et vous tomberez sur ceci. Ses réglages par défaut du moteur rapide réservent de la place pour dix images et dix vidéos par requête. Il ne reste rien pour la mémoire de travail du modèle, et le moteur rapide refuse de démarrer. Notre exemple corrige cela en dimensionnant le moteur rapide pour une image et des requêtes plus courtes. Il choisit aussi le moteur selon la taille de la carte : rapide à partir de 22 GiB, référence en dessous. La version actuelle de l'exemple ne fait que transformer en valeurs par défaut les valeurs que nous avons testées. Cette version précise n'a pas encore tourné sur un GPU. Les précédentes, si, avec les mêmes valeurs réglées à la main. Les autres problèmes sont dans l'annexe.
Faut-il l'utiliser ? Oui pour des fonctions de vision sur une carte de 16 GB, et testez vos comptages
- Vous livrez aujourd'hui de la détection, des contours ou des détourages : un seul modèle 4B sur une seule carte a tout fait dans notre test. Lisez d'abord les lignes de la fiche du modèle sur l'usage prévu.
- Vous avez besoin de comptages justes : utilisez le moteur de référence, ou vérifiez d'abord le moteur rapide sur vos propres images. Sur notre échiquier, c'est le moteur lent qui avait raison.
- Vous avez une carte de 16 GB : chaque tâche a tourné sur une vraie RTX 5080. Sur 12 GB, prévoyez seulement les boîtes et le texte.
- Vous avez besoin de vitesse : une carte de 24 GB avec le moteur rapide donne des détourages en une seconde et des recherches en moins d'une seconde. Nous avons envoyé une requête à la fois et n'avons pas testé plusieurs utilisateurs en même temps. Envoyez d'abord une requête de chauffe.
Lancez python publish.py, puis python main.py, depuis notre exemple du SDK pour WeVisOne-VL-4B pour obtenir les mêmes sept tâches derrière une API sur votre propre worker NVIDIA. Il faut un .env rempli et une carte de 16 GB (24 GB pour le moteur rapide), et il supprime le déploiement en sortant.
Pour les ingénieurs
Modèle et fichiers
tencent/WeVisOne-VL-4B, sha4a7bed92750ac9d8b8a124cede14759036932dc2, créé le 2026-10-22T09:48Z, lastModified 2026-10-23, non restreint, licence apache-2.0.model.safetensors19 322 413 240 octets, tout en F32 (4 830 581 248 paramètres) ;mask_decoder.pt38 534 741 octets, 9 609 764 paramètres.Qwen3VLForConditionalGeneration. LeLICENSEsur HF cite Qwen3-VL-4B-Instruct (Alibaba Cloud, Apache-2.0, modifié par Tencent) comme dépendance.tencent/WeVisOne-VL-2B, sha3dad9ce8bcb6fbe0aea945bf8860bd2cfc3663bf, créé le 2026-10-22T09:47Z :model.safetensors9 767 053 328 octets en F32 (2 441 744 384 paramètres) ;mask_decoder.pt38 141 525 octets, 9 511 460 paramètres ; Apache-2.0.- Code :
Tencent/WeVisOne-VLà40f735b8(2026-10-23T10:35Z ; publication initiale23447828à 08:14Z). Détection de licence de GitHub :NOASSERTION, bien que le README déclare le code de Tencent sous Apache 2.0. Épinglages : torch 2.11.0, transformers 5.12.1, vllm 0.23.0, triton 3.6.0, accelerate 1.14.0. - Démo hébergée : https://huggingface.co/spaces/hugging-apps/wevisone-vl-4b
Comment fonctionne la voie des pixels
- Les coordonnées sont des tokens du vocabulaire
<0>à<1000>(normalisés). Boîte = 4 tokens, point = 2.Nonepour une cible absente. Les tâches denses émettent<OBJ>(token ID 152678) après chaque boîte. - Décodeur de pixels : un Visual Feature Adapter sur les features ViT de Qwen3-VL avant fusion, issues des couches 5, 11, 17 et 23 ; un Box-Guided Query Decoder (6 blocs de cross-attention déformable, initialisés depuis l'état caché de
<OBJ>plus un a priori de boîte encodé en Fourier) ; un Instance-Conditioned Dense Head avecFullCanvasAlphaCascadeHeadqui affine S/4, S/2, S/1 jusqu'à un alpha en pleine résolution. Entrée du décodeur redimensionnée en 1024 x 1024 (cnn_image_size1024). - API du paquet :
WeVisOneVL(model, backend="transformers"|"vllm", dtype="bfloat16", gpu_memory_utilization=0.45, max_model_len=8192, max_pixels=2025*32*32). Avecbackend="vllm", il créevllm.LLMaveclimit_mm_per_promptimage 10 / video 10 et charge quand même le modèle Transformers complet ;decode_masksrepasse la réponse générée en teacher forcing à travers lui pour capturer les états cachés de<OBJ>et les features ViT. D'où deux copies des poids sur la voie vLLM. - Tâches dans
prompts.py:detection,referring,point,count_box,count_point,ocr,ocr_grounding,segmentation,matting, plusvisual_promptetfreeform. - Limites indiquées dans la fiche : bords alpha fins sensibles à la résolution, à l'occlusion, à la transparence et à la formulation du prompt ; pas de chaîne de raisonnement ; perception d'image en un seul tour (les grilles vidéo sont rejetées par le décodeur de pixels). Le paquet autorise 10 images par prompt ; notre backend réduit cela à une.
- Entraînement (page du projet) : SFT en curriculum de trois étapes (90,2M, 40,5M, 41,8M échantillons), puis RL multitâche avec GRPO (178K échantillons), environ 100M d'images. SAM2 étend les boîtes vérifiées en masques dans le moteur de données. À l'inférence, la page du projet dit : "No SAM, no external segmentation backbone: the pixel decoder reuses the VLM's own multi-level ViT features."
Chiffres phares des auteurs pour le 4B face à la meilleure référence ouverte de leurs tableaux (non reproduits par nous) : LVIS F1 55,3 (50,7), Dense200 71,3 (58,7), RefCOCOg 81,8 (77,6), rejet WeRef-Bench 96,4 (73,0), PixMo-Count 89,6 (82,8), PointBench 71,9 (69,9), TotalText 52,0 (43,3), ReasonSeg gIoU 71,2 (65,0), P3M-500-NP MAD 7,3 (15,4), WeRefMat referring MAD 9,8 (22,4). GroundingDINO-T : COCO 56,6, LVIS 38,8 (4B : 57,1, 55,3). Le 2B bat le 4B sur P3M-500-NP (6,6 contre 7,3) et PPM-100.
Notre installation
- GPU sur notre cloud : RTX 4090 24 GB (driver 595.91.07, CUDA 13.2) pour les exécutions principales ; RTX 5080 16 GB (driver 580.178.04, CUDA 13.0) pour la vérification sur carte réelle.
- Un manager InferenceKey local (jamais la production) a amorcé les deux workers. Le workload a tourné comme backend Python sur mesure
wevisone-vl-perception, appelé via/v1/images/generationset le testeur d'images du panneau. - Moteurs (le moteur rapide du récit est vLLM, le moteur de référence est Transformers) : vLLM 0.23.0 pour le texte plus une copie Transformers 5.12.1 qui alimente
mask_decoder.pt, ou Transformers seul. bf16 partout.
Déploiement pas à pas
L'exemple se trouve à https://github.com/inferencekey/inferencekey-sdk/tree/main/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia (commit e54c22cd22f710e981b22504031f57782c0a5a56) : backend.py, requirements.txt, publish.py, main.py, README.md, .env.example.
Il faut : INFERENCEKEY_SDK_TOKEN, INFERENCEKEY_API_KEY, INFERENCEKEY_PROJECT, IK_WORKER_ID (votre worker NVIDIA), et en option INFERENCEKEY_TENANT_ID / INFERENCEKEY_USER_TOKEN pour publish.py. Sur le worker : un driver NVIDIA pour CUDA 13.0 (580 ou plus récent), Python 3.12, 16 GB de VRAM pour chaque tâche, 24 GB pour le moteur vLLM.
git clone https://github.com/inferencekey/inferencekey-sdk.git
cd inferencekey-sdk/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia
cp .env.example .env # fill in tokens, project and worker id
python3 -m venv .venv && . .venv/bin/activate
pip install maturin requests
(cd ../../bindings/python && maturin develop --release)
python publish.py # packages and uploads the custom backend
python main.py # ensure -> wait_until_ready -> 8 requests -> delete
IK_KEEP_ALIVE=1 python main.py # same, but keeps the workload running
main.py déploie le workload WeVisOne-VL-4B avec le slug du backend sur mesure, task_type text2image, ExecutionPolicy.FIXED avec 1 réplique épinglée sur IK_WORKER_ID, ready_timeout_secs 2400, request_timeout_secs 600, et transmet chaque variable WEVIS_* comme env.
Pour l'appeler (l'exemple se rabat sur https://cloud.inferencekey.com quand INFERENCEKEY_BASE_URL n'est pas défini ; .env n'est pas chargé dans votre shell, donc exportez ce dont l'appel a besoin) :
set -a; . ./.env; set +a
export INFERENCEKEY_BASE_URL="${INFERENCEKEY_BASE_URL:-https://cloud.inferencekey.com}"
curl -s "$INFERENCEKEY_BASE_URL/endpoint/$INFERENCEKEY_PROJECT/wevisone-vl-4b/v1/images/generations" \
-H "Authorization: Bearer $INFERENCEKEY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"task": "matting", "query": "person", "image": "https://example.com/photo.jpg"}'
image accepte une URL https, une data URL ou du base64. Le testeur du tableau de bord prend un prompt de la forme task: query image_url, par exemple matting: person https://.../photo.jpg. La réponse contient data[0] (JPEG annoté), data[1] (PNG RGBA détouré, segmentation et matting seulement), predictions (boîtes ou points en pixels par label), count, rejected, masks (mattes PNG en niveaux de gris), timings et vram_peak_gib.
Environnement du backend (version 0.1.3) :
| Variable | Défaut | Signification |
|---|---|---|
WEVIS_ENGINE | auto | vllm à partir de 22 GiB de VRAM totale, sinon transformers |
WEVIS_MODEL | 4B | 4B ou 2B, révisions épinglées |
WEVIS_GPU_MEMORY_UTILIZATION | (9,4 + 1,75) / total, 0.465 sur 24 GB | part de vLLM ; 4,6 GiB de poids pour le 2B |
WEVIS_MAX_MODEL_LEN | 3072 | contexte de vLLM |
WEVIS_MAX_NUM_SEQS | 4 | concurrence de vLLM |
WEVIS_VRAM_LIMIT_GIB | non défini | plafond PyTorch pour émuler une carte plus petite |
WEVIS_MAX_PIXELS | 20253232 | plafond de l'image d'entrée |
Le backend définit aussi PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. La version 0.1.3 fait des valeurs que nous avons testées via env les valeurs par défaut ; la 0.1.3 elle-même n'a pas tourné sur un GPU (les 0.1.0 à 0.1.2 oui, avec des surcharges par env).
Délai de disponibilité
- RTX 4090, premier démarrage (0.1.0) : venv du backend environ 67 s, téléchargement de 18,0 GiB en 14 s, chargement des poids par vLLM 7,0 s (9,37 GiB),
torch.compile36 s, profilage des graphes CUDA 93 s, puis l'échec du cache KV (problème 1). - RTX 4090 à chaud, moteur vLLM : 82 s, 82 s, 49 s ; recyclage à chaud sur un nouveau paquet 58 s.
- RTX 4090 à chaud, moteur Transformers : 14 à 15 s (chargement 12,4 s). 2B : 21 s, premier téléchargement de 9,8 GB compris.
- RTX 5080, machine neuve, moteur Transformers : 87 s (téléchargement 38,0 s, chargement 16,9 s).
Mesures complètes
Temps GPU dans le backend. Les allers-retours ajoutent 0,9 à 2,5 s (téléchargement de l'image sur le worker plus la plateforme). Identifiants d'images COCO entre parenthèses.
| Requête | 4090 vLLM (util 0.465) | 4090 Transformers | 4090 TF, plafond 11,5 GiB | 5080 16 GB TF | 2B TF, plafond 7,2 GiB |
|---|---|---|---|---|---|
| détecter dans une cuisine : person, pot, bottle, bowl, knife (397133) | 33 boîtes ; 14,5-15,5 s au premier appel, 1,93 s à chaud | 32, 7,44 s | 32, 7,62 s | 32, 8,31 s | 25, 5,09 s |
| compter les personnes, tennis (1000) | 12, 0,78 s | 12, 2,68 s | 12, 2,68 s | 12, 2,77 s | 11, 1,97 s |
| désigner : the cat on the right (39769) | 1 boîte, 0,21 s | 0,55 s | 0,57 s | 0,68 s | 0,46 s |
| rejeter : the dog (même photo) | None, 0,11 s | None, 0,36 s | None, 0,34 s | None, 0,47 s | None, 0,29 s |
| pointer : catcher (46252) | 1 point, 0,16 s | 0,38 s | 0,38 s | 0,50 s | 0,30 s |
| OCR panneau de rue (252219) | 29 mots, 3,69 s | 21, 9,13 s | 21, 9,05 s | 22, 9,49 s | 25, 8,91 s |
| segmenter : the blue bicycle (174482, 640x388) | 1,20-1,84 s | 0,89 s | 0,91 s | 1,21 s | 0,78 s |
| détourer : person (seabreeze.jpg des auteurs, 1620x1080) | 0,97-1,11 s | 1,11 s | OOM | 2,05 s | OOM |
| détourer : the cat on the right | 0,38 s | 0,76 s | 0,84 s | 1,13 s | 0,66 s |
| détourer : skier (785) | 0,36 s | 0,65 s | 0,69 s | 0,99 s | 0,58 s |
| désigner : boys holding microphone (boys.jpg des auteurs) | 2 boîtes, 0,53 s | 0,80 s | 0,80 s | 1,18 s | 0,63 s |
| compter : white chess pieces (chess.jpg des auteurs, 16 en réalité) | 15, 1,35 s | 16, 3,87 s | 16, 3,70 s | 16, 4,20 s | 16, 2,78 s |
| OCR avec position : PROCTER (11197) | 1 boîte, 0,20 s | 0,50 s | 0,50 s | 0,60 s | mal formé |
| compter : pots and pans hanging (397133) | 19, 1,11 s | 20, 4,12 s | 20, 4,20 s | 19, 4,11 s | 19, 3,10 s |
| pic de la carte (nvidia-smi) | 23 539 MiB, 23,0 GiB (20 329 au repos) | 12 546 MiB | environ 12,5 GB contexte CUDA compris | 13 148 MiB | 7 242 MiB |
- La détection à 14,5 à 15,5 s est la chauffe : sur le moteur chaud, avec
max_new_tokens512 et 2048, les mêmes 33 boîtes ont pris 1,94 s et 1,93 s. - Le temps de segmentation vLLM se répartit en environ 0,19 s de texte et 1,0 à 1,6 s de masque ; le gros détourage en 0,53 à 0,64 s de texte et 0,44 à 0,48 s de masque.
- Vérifié à l'œil : boîtes de la cuisine, chat, point sur le receveur, détourages du vélo et du portrait justes ; rejet juste dans chaque configuration ; échiquier compté à la main (16), vLLM a raté le cavalier blanc en g5. Non vérifié contre une vérité de terrain : tennis (12), casseroles (19 ou 20) et l'OCR du panneau de rue (29, 21, 22 ou 25 mots selon l'installation).
- Allers-retours du testeur du panneau dans la démo (moteur vLLM) : matting 2 367 ms, comptage de l'échiquier 2 140 ms, désignation 1 087 ms.
Échelle de VRAM, chiffres complets
| GPU ou plafond | Config | Pic | Sortie OK ? | Réelle ou émulée |
|---|---|---|---|---|
| RTX 4090 24 GB | 4B, vLLM util 0.5 + copie Transformers (backend 0.1.1) | OOM sur le détourage 1620x1080 : Tried to allocate 768.00 MiB, 630,44 MiB libres (EngineCore 11,50 GiB + Transformers 11,39 GiB) | non, les 7 autres requêtes de main.py OK | réelle |
| RTX 4090 24 GB | 4B, vLLM util 0.465, max_model_len 3072, max_num_seqs 4 + copie Transformers | 23 539 MiB | oui, 14/14 (échiquier 15 sur 16) | réelle |
| RTX 4090 24 GB | 4B, Transformers seul | 12 546 MiB | oui, 14/14 | réelle |
| RTX 5080 16 GB | 4B, Transformers seul | 13 148 MiB | oui, 14/14 | réelle |
| 12 GB (plafond 11,5 GiB) | 4B, Transformers, WEVIS_VRAM_LIMIT_GIB=11.5 | environ 12,5 GB sur la carte, contexte CUDA compris | non, 13/14 : OOM sur le gros détourage Tried to allocate 768.00 MiB ... 11.27 GiB allowed | émulée, optimiste |
| 12 GB strict (plafond 10,8 GiB) | 4B, Transformers, WEVIS_VRAM_LIMIT_GIB=10.8, WEVIS_MAX_PIXELS=1048576 | 11 026 MiB à l'échec | non : tâches d'objets OK, segmentation d'une image 640x388 en OOM (768 MiB), aucun masque | émulée |
| 8 GB (plafond 7,2 GiB) | 2B, Transformers, WEVIS_MODEL=tencent/WeVisOne-VL-2B | 7 242 MiB | non, 12/14 : OOM sur le gros détourage, OCR avec position <ref>PROCTER</ref><box><368><0><1000></ref></box> ; détection 25 contre 32, tennis 11 contre 12 | émulée |
Les plafonds limitent seulement les allocations de PyTorch ; ils émulent la mémoire, pas le calcul ni la bande passante d'une carte plus petite, et le contexte CUDA se trouve hors du plafond. Pas essayé : de vraies cartes de 12 GB ou 8 GB, fp8 ou int8, le déchargement sur CPU.
Problèmes rencontrés
- Les réglages vLLM des auteurs ne laissent aucun cache KV sur 24 GB.
Encoder cache will be initialized with a budget of 16384 tokens, puisAvailable KV cache memory: -0.87 GiBetValueError: No available memory for the cache blocksà util 0.471. Corrigé dans le backend en enveloppantvllm.LLM:limit_mm_per_promptune image au plafond d'entrée, video 0, taille dansmm_processor_kwargs,max_model_len,max_num_seqs4. - Deux copies des poids sur 24 GB, c'est serré. util 0.5 a fait manquer de mémoire le gros détourage (voir l'échelle). util 0.465 avec
max_model_len4096 a donné0.56 GiB KV cache is needed, which is larger than the available KV cache memory (0.44 GiB); 3072 marche. Corrigé via les valeurs par défaut. - Les résultats de plus de 8 MB sont abandonnés et l'appelant attend un 504. Worker :
job result refused by JetStream for good (code max_payload: ... exceeded by message size of 9145132); client :504 ... inference_timeout. Le worker réencode en base64 le JSON du backend sur la route des images (x1,33). Corrigé dans le backend (superposition en JPEG, détourage en 1280 px, budget de 5,2 MB). Ouvert côté plateforme : le worker sait que le résultat a été refusé, mais le client attend quand même le timeout complet. - Les moteurs ne sont pas d'accord sur certaines réponses. Échiquier 15 contre 16, OCR 29 contre 21 mots, casseroles 19 contre 20. Glouton sur les deux. Ouvert, inhérent aux deux moteurs ; choisissez le moteur selon le cas d'usage.
- La première requête vLLM après un démarrage est lente (14,5 à 15,5 s pour une détection de 1,9 s). Envoyez une requête de chauffe.
- Le packager du SDK n'a pas
image2image.PackagingError: unknown task_type 'image2image'; expected one of ('text2text', 'embedding', 'text2image', ...), alors que le manager l'accepte. Le backend déclaretext2image, qui ne fait que sélectionner la route des images. Ouvert. - Le testeur du tableau de bord n'envoie qu'un prompt (plus des champs de taille, d'étapes et de guidance que ce modèle ignore), donc le backend en extrait
task: query url. - Nos erreurs. L'exécution 3 a échoué parce que
main.pyne transmettait pasWEVIS_MAX_MODEL_LEN(corrigé).
Autres exemples
Tous issus de l'exécution vLLM sur RTX 4090. Ils utilisent des photos COCO val2017 (Flickr, licences Creative Commons variées, certaines non commerciales).
Vidéo de démo
Démo de déploiement narrée, 99,6 s, 1920 x 1080 : le workload sur une RTX 4090, puis un détourage de portrait (aller-retour de 2 367 ms), le comptage de l'échiquier avec le cavalier manquant visible (2 140 ms) et "boys holding microphone" (1 087 ms) depuis le testeur d'images du panneau.
Sources
- Fiches des modèles : https://huggingface.co/tencent/WeVisOne-VL-4B et https://huggingface.co/tencent/WeVisOne-VL-2B (README,
LICENSE,config.json, API HF avec les blobs) - Code : https://github.com/Tencent/WeVisOne-VL à
40f735b8(README,engine.py,prompts.py,requirements.txt,configs/wevisone_vl_v1_decoder.json) - Page du projet : https://tencent.github.io/WeVisOne-VL/
- Où nous l'avons repéré : AI Search, https://www.youtube.com/watch?v=EfyQOAJjx1A (25 octobre 2026, chapitre de 01:01 à 03:10)
- Images de test : les exemples des auteurs (seabreeze, chess, boys) et COCO val2017
- Notre exemple du SDK : https://github.com/inferencekey/inferencekey-sdk/tree/main/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia