WeVisOne-VL-4B: Het 4B-visiemodel dat Tencent zonder lanceringsbericht publiceerde

Op P3M-500-NP, een standaardbenchmark voor het extraheren van zachte randen uit een afbeelding, behaalde de beste alpha matte die Tencent kon vinden om mee te vergelijken een gemiddeld absoluut verschil van 15,4. WeVisOne-VL-4B scoort 7,3. Dat is ongeveer de helft van de fout van een speciaal gebouwde matting-pipeline, geproduceerd door een vision-language model met 4 miljard parameters dat met dezelfde gewichten ook detectie, tellen, OCR en segmentatie uitvoert. WeVisOne-VL-4B is de poging van het WeChat Vision-team om een hoop perceptiespecialisten samen te voegen tot één next-token-voorspeller, en het is oprecht interessant werk. Wat het nog niet is, is een product: er is geen Tencent-blogpost, geen persbericht, geen gehoste endpoint en geen enkele aankondiging die deze site kon vinden. De gewichten werden op 22 oktober 2026 op Hugging Face geplaatst en sindsdien is het model stilletjes openbaar beschikbaar geweest.

Dit stuk is een weergave van wat de repositories feitelijk bevatten, en het scheidt twee dingen die gemakkelijk door elkaar kunnen lopen: wat je kunt verifiëren door het model te downloaden, en wat alleen het eigen paper van Tencent beweert. Beide doen ertoe. Slechts één ervan is bewijs.

Wat is er gepubliceerd, en wanneer?

Het dossier is ongewoon overzichtelijk omdat alles van een tijdstempel is voorzien. De Hugging Face-repository tencent/WeVisOne-VL-4B werd op 22 oktober 2026 om 09:48 UTC aangemaakt; de GitHub-repository Tencent/WeVisOne-VL werd vijftig minuten eerder aangemaakt, om 08:58 UTC diezelfde ochtend; de arXiv-paper, 2610.31329, draagt een indieningsdatum van 22 oktober. Een 2B-zustermodel, tencent/WeVisOne-VL-2B, verscheen daarnaast.

Op het moment van schrijven was de 4B-repository de volgende ochtend nogmaals gewijzigd en had ze een paar likes en geen noemenswaardig downloadaantal verzameld. Die tellers zijn een momentopname, geen eindoordeel, maar ze vertellen je wel iets wat het paper niet kan: bijna niemand heeft dit model nog opgehaald. De GitHub-repository had 46 sterren en een handvol forks, en de TODO-lijst in de README is zelf al een statusrapport — het inferencepakket, de cookbooks en de evaluatiepipeline zijn afgevinkt; een Gradio-demo en de fine-tuningcode niet.

Dus de accurate beschrijving is niet 'een lek' en niet 'een lancering'. Het is een officiële open-sourceuitgave met het geraamte van een release — paper, gewichten, code, benchmarkpipeline — en geen enkele marketing. Of er een aankondiging volgt, is onbekend. Iedereen die schrijft dat Tencent dit model 'onthulde' of 'lanceerde', beschrijft een gebeurtenis die niet heeft plaatsgevonden.

Eén ruggengraat, zeven uitvoertypen

De architectuur is minder exotisch dan de benchmarktabel doet vermoeden. WeVisOne-VL-4B is een Qwen3-VL-model — de metagegevens van de repository noemen Qwen3VLForConditionalGeneration als de architectuur en vermelden 4,83 miljard parameters in F32 — afgerond op 5B op de modelkaart — fine-getuned om gestructureerde coördinatentokens in plaats van proza te produceren. Boxen en punten worden gecodeerd als tokens van <0> tot <1000>, genormaliseerd ten opzichte van de afbeelding, en dat is hoe een taalmodel geometrie gaat doen in plaats van beschrijving.

De helft op pixelniveau is het deel dat de moeite waard is om te begrijpen. Na elke voorspelde box genereert het model een speciale token, <OBJ>, waarvan de verborgen toestand naar een afzonderlijke decoder met 9,6 miljoen parameters gaat die wordt meegeleverd als mask_decoder.pt. Die decoder — een visuele feature-adapter, zes deformable cross-attention-blokken en een cascade-head die verfijnt bij stride 4, 2 en 1 — zet de box om in een instancemasker en vervolgens in een alpha matte op volledige resolutie. Het is geen SAM-aanroep. Er is geen tweede model in de lus, geen promptencoder, geen externe segmenter. Het hele pixelpad is 9,6M parameters die aan een taalmodel zijn vastgeschroefd.

Die ontwerpkeuze verklaart het benchmarkprofiel. Omdat maskers en mattes geconditioneerd zijn op dezelfde box die het model zojuist heeft voorspeld, heeft het model geen door een mens aangeleverde box nodig om te segmenteren; het kan gevraagd worden om 'de persoon die de paraplu vasthoudt' en de matte voor precies dat exemplaar teruggeven. De afweging is dat de pixeldecoder nooit leert van een beloning op maskerniveau — de reinforcement-learningfase van het artikel scoort boxen, pointing en OCR-transcriptie, maar gebruikt helemaal geen masker- of alfa-beloning. De dense output wordt uitsluitend met een supervised loss getraind.

De cijfers, en van wie de cijfers zijn.

Elk cijfer hieronder is afkomstig uit Tencent's paper of de README van het project. Geen enkel cijfer is door een derde partij gereproduceerd, en de vergelijkingsset is door de auteurs gekozen. Dat is normaal voor een paper van twee dagen oud, en het is ook precies de situatie waarin een leverancierstabel zichzelf mooier voorstelt, dus beschouw de marges als beweringen rather dan als metingen.

De kop beweert, ten opzichte van de sterkste open baseline die de auteurs voor elke taak noemen:

• Detectie, LVIS F1-gemiddelde — WeVisOne-VL-4B 55,3 vs. 50,7 voor de beste baseline

• Dense-detectie, Dense200 F1-gemiddelde — 71,3 vs 58,7

• Referring, RefCOCOg-test F1-gemiddelde — 81,8 vs 77,6

• Afwijzing, WeRef-Bench — 96,4% van de queries zonder doel correct geweigerd vs 73,0%

• Tellen, PixMo-Count-testnauwkeurigheid — 89,6 vs 82,8

• OCR, TotalText F1-gemiddelde — 52,0 vs 43,3

• Verwijzende segmentatie, ReasonSeg val gIoU — 71,2 vs 65,0

• Boxmat, P3M-500-NP MAD — 7,3 vs 15,4, waarbij lager beter is

De meest informatieve rij staat niet in die lijst. Tegenover Qwen3-VL-4B — dezelfde backbone, ongewijzigd — is het verschil op Dense200 71,3 tegenover 15,2, en op VisDrone 44,7 tegenover 31,0. Een basis visie-taalmodel is nagenoeg nutteloos voor dichte detectie van kleine objecten, en de fine-tuning brengt het naar specialistisch terrein. Dat is een verdedigbaarder bewering dan welke vergelijking met een frontier-model dan ook: de auteurs laten zien dat een 4B-generalist kan worden omgevormd tot een competente localisator zonder groter te worden.

Waar het niet meer werkt

De beperkingen staan op de modelkaart en ze zijn niet cosmetisch. Het model verwerkt één afbeelding per beurt — videorasters worden door de pixeldecodeerder botweg geweigerd, dus dit is geen hulpmiddel voor videosegmentatie en het pretendeert dat ook niet te zijn. Het produceert rechtstreeks gestructureerde uitvoer, zonder chain-of-thought, wat betekent dat er geen manier is om het te vragen na te denken over een dubbelzinnige query voordat het zich op een box vastlegt. De alphakwaliteit gaat achteruit bij fijne grenzen, zware occlusie en echt transparante materialen, en het is gevoelig voor de formulering van de prompt — "the woman's hair" en "her hair" geven niet gegarandeerd dezelfde matte.

Het afwijzingsgedrag is de functie die het vaakst wordt onderschat. Het retourneren van None voor een afwezig doelwit klinkt triviaal, totdat je een detector op een videostream hebt laten draaien en hebt gezien hoe die een voetganger hallucineert op een lege parkeerplaats. Een afwijzingspercentage van 96,4% op WeRef-Bench, tegenover een beste baseline van 73,0%, is het verschil tussen een component die je in een pipeline kunt stoppen en een die je met een tweede model moet afschermen.

Hoe je het daadwerkelijk zou uitvoeren

De modelkaart documenteert vier servingpaden: het eigen inferentiepakket van het project, een Transformers image-text-to-text-pipeline, vLLM en SGLang, plus een Docker Model Runner-one-liner. Decodering is greedy, met een limiet van 1.960 visuele tokens per afbeelding. Met 4,83 miljard parameters in F32 is het checkpoint ongeveer 19 GB op schijf, vóór de decoder met 9,6 miljoen parameters; laden in bfloat16 halveert dat. Je hebt de aangepaste inferentiecode hoe dan ook nodig — mask_decoder.pt is een vereist onderdeel, geen optionele extra, en een standaard Transformers-load geeft je boxes en tekst, maar geen maskers.

Er is geen gehoste API en geen gepubliceerde prijs, dus de eerlijke vaststelling is dat WeVisOne-VL-4B vandaag een self-hostingbeslissing is. Als je eigenlijk de Qwen3-VL-perceptiepipeline deze week in productie wilt, zonder een GPU te provisioneren voor gewichten die gisteren zijn gearriveerd, dan is de Qwen3-VL-8B instruct-build beschikbaar via OrcaRouter — één sleutel voor meer dan 200 modellen, de lijstprijs van de provider doorgegeven tegen 0% markup, en automatische failover als een upstream-endpoint hapert. Dat is de backbone-familie, niet de fine-tune. Het levert je boxes en beschrijvingen; het levert je geen alpha mattes.

Wat te kijken

Drie dingen zouden dit van "interessant paper" naar "model dat je zou moeten evalueren" tillen. Het eerste is een onafhankelijke benchmarkrun — wie de matting-cijfers op een held-outset reproduceert, zou de grootste openstaande vraag beslechten. Het tweede is een gehost endpoint, van Tencent of wie dan ook, dat je zou vertellen of het inferentiepad robuust genoeg is om te dienen. Het derde is de fine-tuningcode die ongecontroleerd op de TODO-lijst van de README staat; zonder die code is het aanpassen van de matting-head aan een specifieke productcatalogus giswerk.

Tot die tijd luidt de eerlijke samenvatting als volgt: Tencent heeft een klein model gepubliceerd dat iets werkelijk ongewoons doet — alpha mattes op volledige resolutie uit een taalmodel, zonder dat SAM eraan te pas komt — en heeft dat gedaan zonder aandacht te vragen. De gewichten zijn Apache 2.0 voor door Tencent geschreven code. De beweringen zijn van de auteurs zelf. Beide feiten zijn controleerbaar, en je moet ze controleren voordat je je plannen erop baseert.