WeVisOne-VL-2B vs LFM2.5-VL-3B: Een maskermaker tegen een schermlezer

Geef beide modellen dezelfde foto en dezelfde zin — "de hond links" — en er komen twee verschillende dingen terug. LFM2.5-VL-3B antwoordt met een locatie en, als je erom vraagt, een beschrijving: een box, een punt of een korte zin over wat het heeft gevonden. WeVisOne-VL-2B antwoordt ook met een box, en dan zet een kleine decoder die box om in een alpha-matte met zachte randen die je op een nieuwe achtergrond kunt samenstellen zonder halo rond de vacht. Het ene model is gebouwd om een interface te lezen en te antwoorden. Het andere is gebouwd om je pixels te geven.

Dat verschil is de hele vergelijking, en het doorstaat elke benchmarktabel die een van beide leveranciers heeft gepubliceerd. Het verklaart ook waarom de twee modellen zelden tegenover elkaar worden geëvalueerd: de modelkaart van Liquid AI noemt WeVisOne niet, het paper van Tencent noemt Liquid niet, en geen enkele derde partij heeft ze naast elkaar laten draaien. Wat volgt is wat elke release daadwerkelijk heeft vastgelegd, welke van hun cijfers naast elkaar kunnen worden gezet en welke niet.

Twee releases, twee heel verschillende hoeveelheden bewijs

LFM2.5-VL-3B werd op 11 augustus 2026 gepubliceerd door Liquid AI — eerst de gewichten, de aankondiging de volgende dag — en het kwam met een numerieke benchmarktabel, een bij naam genoemde baseline voor elke rij en een snelheidssectie gemeten op bij naam genoemde hardware. Het is een dense model met 3,12 miljard parameters: een LFM2.5-2.6B-taalbackbone gecombineerd met een SigLIP2 NaFlex 400M-visie-encoder, een context van 32.768 tokens, een vocabulaire van 128.000 tokens en zestien bij naam genoemde talen. De licentie is Liquid's eigen LFM Open License v1.0, die gratis is voor commercieel gebruik onder een omzetdrempel in plaats van onvoorwaardelijk gratis.

WeVisOne-VL-2B werd op 22 oktober 2026 gepubliceerd door het WeChat Vision-team van Tencent, en de modelkaart bevat helemaal geen benchmarktabel — geen scores, geen contextlengte, geen doorvoercijfers, geen hardwarevereisten. De cijfers bestaan wel, maar staan in het bijbehorende paper, dat zeven taaktabellen rapporteert over wat de auteurs beschrijven als meer dan dertig benchmarks. De twee releases zijn dus niet alleen verschillende modellen; het zijn verschillende soorten documenten. Liquid publiceerde een productspecificatie. Tencent publiceerde een onderzoeksresultaat en liet het specificatieblad grotendeels leeg.

Die asymmetrie is van belang wanneer je een vergelijking zoals deze leest. De cijfers van Liquid zijn samengesteld om tegen zijn eigen baselines te worden gelezen. Die van Tencent zijn samengesteld om een academische tabel te winnen. Geen van beide leveranciers koos zijn cijfers met het andere model in gedachten, en dat is precies waarom de cijfers niet overeenkomen.

Het getal dat vergelijkbaar lijkt, maar het niet is

Beide modellen publiceren een RefCOCO-score, en ze naast elkaar zetten levert een ogenschijnlijk nette kop op: LFM2.5-VL-3B op 87,9 tegenover WeVisOne-VL-2B op 79,7. Die vergelijking is zinloos, en het is de moeite waard om te bekijken waarom, omdat dezelfde fout op dit moment in spreadsheets wordt gemaakt.

• Liquid rapporteert RefCOCO precision@1 gemiddeld over de splits. Dat is een detectiestatistiek: overlapte de best gerangschikte voorspelde box voldoende met de ground-truth box om als correct te tellen.

• Tencent's 79,7 staat op een segmentatietabel, en het artikel stelt duidelijk dat de cijfers voor de RefCOCO-familie daar cumulatieve IoU zijn — totale intersectie gedeeld door totale unie over de hele evaluatieset.

• Tencents verwijzende detectietabel vermeldt RefCOCO helemaal niet. Die vermeldt RefCOCOg, waar de 2B een gemiddelde F1 van 77,1 scoort.

Dus de 87,9 en de 79,7 meten drie verschillende dingen bij twee verschillende taken. Een box die nauwelijks overlapt met een doel kan goed scoren op precision@1 en slecht op cIoU; een masker dat een groot object goed bedekt, kan hoog scoren op cIoU terwijl zijn bounding box slordig is. Er is geen rekenkundige manier om die met elkaar te verzoenen.

Dezelfde valkuil zit in OCR. Liquid publiceert OCRBench v1 met 84,2 en OCRBench v2 Engels met 47,5 — transcriptiebenchmarks. Tencent publiceert OCR als localisatie-F1 bij een IoU-drempel van 0,5: 62,1 op SROIE, 42,6 op ICDAR2015, 42,5 op TotalText, 30,5 op HierText. Die meten of het model de tekst heeft gevonden en omkaderd, niet of het die correct heeft gelezen. Het citeren van "84,2 versus 62,1" zou een leestest met een aanwijstest vergelijken.

Wat is eigenlijk een eerlijke vergelijking?

Haal de scores weg, en de twee modellen sluiten op elkaar aan op dimensies waarvoor geen harness nodig is:

• Grootte — ongeveer 3,12 miljard dense parameters voor LFM2.5-VL-3B versus ongeveer 2 miljard voor WeVisOne-VL-2B, plus een decoder van 9,5 miljoen parameters die apart moet worden gedownload en vereist is voor dense outputs.

• Basis — Liquids eigen LFM2.5-2.6B hybride backbone vs Qwen3-VL.

• Context — 32.768 tokens gepubliceerd op de kaart versus helemaal geen gepubliceerde contextlengte. De trainingsfasen van de WeVisOne-paper draaiden op 4.096 en 8.192 tokens, en bij inferentie wordt elke afbeelding beperkt tot 1.960 visuele tokens, maar niets daarvan is een deploymentvenster.

• Uitvoertypen — boxen, punten en tekst versus boxen, punten, binaire maskers en continue alfa-mattes.

• Redeneervermogen — LFM2.5-VL-3B is bewust niet-redenerend en antwoordt direct om de latentie laag te houden; WeVisOne is ook niet-redenerend, maar om een andere reden: het genereert gestructureerde output zonder chain-of-thought voor inferentie-efficiëntie. Geen van beide modellen ‘denkt’ voordat het antwoordt, en geen van beide leveranciers pretendeert anders.

• Tool calling — ondersteund en gebenchmarkt op LFM (ToolSandbox 59,5, BFCL v4 32,5) versus niet als capaciteit vermeld op WeVisOne.

• Talen — zestien genoemd op de LFM-kaart versus niet vermeld op de WeVisOne-kaart.

• Licentie — LFM Open License v1.0, met een omzetdrempel, versus Apache 2.0 voor door Tencent geschreven code.

• Gequantiseerde builds — GGUF-, ONNX- en MLX-exports aangeboden door Liquid versus geen aangekondigd door Tencent.

• Onafhankelijke evaluatie — geen van beide modellen heeft op het moment van schrijven een vermelding op Artificial Analysis. Alle cijfers in dit artikel, van beide leveranciers, zijn door de leveranciers gerapporteerd.

De deploymentkloof is groter dan de parameterkloof.

LFM2.5-VL-3B is ontwikkeld om op een telefoon te draaien, en de kaart bewijst dat met cijfers: minder dan 3,3 GB geheugen, 20 tokens per seconde op een Galaxy S26 Ultra, 228 tokens per seconde op een Apple M5 Max, 116 op een AMD Ryzen AI Max+ 395, en ongeveer 11.000 outputtokens per seconde bij hoge gelijktijdigheid op één H100. Het wordt geleverd in indelingen die consumentenruntimes daadwerkelijk kunnen laden.

WeVisOne-VL-2B publiceert niets daarvan. Wat het wél publiceert, impliceert een andere rekening. De laatste fase van de decoder produceert een alpha matte op volledige resolutie met stride 1, wat betekent dat de dichte output de grootte van de invoerafbeelding heeft in plaats van een vector met vaste grootte — een kostenpost die schaalt met de resolutie, niet met het aantal parameters. Voor een 2B-model op een moderne GPU is dat beheersbaar. Voor een telefoon is het allesbehalve vanzelfsprekend beheersbaar, en Tencent heeft niet beweerd dat dat wel zo is.

De praktische consequentie is dat deze twee modellen niet om dezelfde deploymentplek concurreren. Het ene is een component die je in een app zou kunnen meeleveren. Het andere is een component die je op een server of op een werkstation zou draaien, naast al het andere dat masking nodig heeft.

Kies op basis van het type output, niet op basis van de score

Als de taak het lezen van een scherm is — een checkoutflow parsen, de knop met het label "Continue" vinden, een tabel extraheren uit een gefotografeerd document — dan is LFM2.5-VL-3B de voor de hand liggende kandidaat. Het scoort 80,7 op ScreenSpot-v2, 91,1 op DocVQA, 81,3 op ChartQA, en een ToolSandbox-score die suggereert dat het kan handelen op basis van wat het ziet in plaats van het alleen te beschrijven. Het heeft ook een gemiddelde van 69,4 over 28 benchmarks dat Liquid publiceert tegenover met naam genoemde zustermodellen, wat je tenminste vertelt hoe de leverancier denkt dat zijn eigen omgeving eruitziet.

Als de taak erin bestaat een object te isoleren — een uitsnede van een product, een persoon tegen een drukke achtergrond, een voorgrond met losse haren of een transparante rand — levert LFM2.5-VL-3B die output niet, en geen enkele prompt zal daar verandering in brengen. WeVisOne-VL-2B doet dat wel, en de marge op de matting-tabellen is groot: 6,6 gemiddelde absolute afwijking tegenover 15,4 voor SAM2-Matting op P3M-500-NP, 15,8 tegenover 23,0 voor een Qwen3-VL-8B plus SAM2-pijplijn op de met taal gepromptde WeRefMat-split.

Er is nog een geval waarin WeVisOne een claim heeft die het vermelden waard is: afwezigheid. Tencent rapporteert een afwijzingspercentage van 50,2 op RefCOCOg voor queries waarvan het doel niet in de afbeelding staat, tegenover 0,5 en 0,6 voor twee gespecialiseerde grounding-modellen in dezelfde tabel. Als je pipeline duizenden crops verwerkt en de meeste daarvan bevatten niets waar je om geeft, dan bespaart een model dat betrouwbaar "niet aanwezig" zegt je een downstream-classifier. De kaart van LFM2.5-VL-3B vermeldt geen vergelijkbaar afwijzingscijfer, dus er is niets om ernaast te zetten — een gat in het bewijs, geen verlies.

Niets hiervan is een reden om de ene te kiezen en de andere met pensioen te sturen, en het is de moeite waard om eerlijk te zijn over waar een router past. OrcaRouter serveert geen van beide modellen; geen van beide staat in onze catalogus, en geen van beide wordt gehost op een locatie die we specifiek voor WeVisOne kunnen verifiëren. Wat we wél bieden is de omliggende stack: als je pipeline een gehost visionmodel gebruikt voor de leeshelft en een zelfgehost model voor de maskeerhelft, lopen de gehoste aanroepen via één API-sleutel tegen de lijstprijs van de provider, zonder opslag, verplaatst failover ze naar een andere provider wanneer er één verslechtert, en met de routing-DSL kun je beide helften achter één endpoint plaatsen zodat je applicatie nooit te weten komt welke heeft geantwoord.

Wat zou het echt beslechten?

Eén onafhankelijke testopstelling, uitgevoerd door iemand die geen van beide leveranciers is, op dezelfde afbeeldingen, die voor beide modellen zowel een detectiestatistiek als een segmentatiestatistiek rapporteert. Die bestaat niet. Totdat die er is, is de verdedigbare positie de saaie: deze modellen beantwoorden verschillende vragen, hun gepubliceerde cijfers zijn gemeten met verschillende instrumenten, en de keuze tussen hen wordt bepaald door wat je stroomafwaartse code verwacht te ontvangen — een zin, of een masker.

Als je maar één ding uit deze vergelijking meeneemt, laat het dan de vorm van het bewijs zijn. Liquid AI gaf je een tabel die je kunt falsificeren. Tencent gaf je een paper die je kunt lezen en een kaart die je eerlijk vertelt wat het model niet zal doen. Geen van beide gaf je een getal dat met het andere kan worden vergeleken, en elk artikel dat 87.9 naast 79.7 drukt zonder dat voorbehoud, verkoopt je een rangorde die niet bestaat.