LFM3-VL-2B vs WeVisOne-VL-4B: Wat 2,5× de parameters nu eigenlijk oplevert

De eigen benchmarktabel van Tencent spreekt de voor de hand liggende aankoop tegen. WeVisOne-VL-4B, het grotere van de twee perceptiemodellen die het WeChat Vision-team op 22 oktober 2026 publiceerde, presteert slechter bij alpha-matting met boxprompts dan zijn eigen 2B-broertje: 7,3 gemiddelde absolute afwijking op P3M-500-NP tegenover 6,6 voor de 2B, waarbij lager beter is. Het model waarmee de meeste kopers het daadwerkelijk zullen vergelijken, is echter niet zijn broertje, maar LFM3-VL-2B — het 1,92B on-device visiemodel van Liquid AI, waarvan de gewichten op 19 oktober uitkwamen en dat samen met de rest van de LFM3-familie op 27 oktober werd aangekondigd.

Zet die twee naast elkaar en de interessante vraag is niet welke slimmer is. Het is wat tweeënhalf keer zoveel parameters je opleveren, en wat ze kosten. Het korte antwoord, uit de eigen tabellen van de leveranciers: ze leveren dichte detectie op, nauwkeurigheid bij verwijzingen, en een veel betere mate van weigeren te antwoorden wanneer het object er niet is. Ze leveren geen generalist op, ze leveren geen video op, en ze leveren geen model op dat je op een telefoon kunt zetten. Alles hieronder komt uit de twee gepubliceerde tabellen met de naden zichtbaar gelaten — geen enkele onafhankelijke testomgeving heeft de cijfers van een van beide modellen gereproduceerd.

Wat elk ervan eigenlijk is

LFM3-VL-2B is een dense model met 1,92B parameters: een taalbackbone van 1,73B, een eigen vision-encoder van 164M en een projector van 25M. De backbone is Liquid's tri-hybride stack — 24 lagen, verdeeld in 13 gated korte convoluties, 5 sliding-window attention-lagen met een venster van 256 tokens, en 6 globale attention-lagen. Het verwerkt tekst, afbeeldingen en video op native resolutie, bemonstert video aan 2 frames per seconde, heeft een context van 128K tokens, dekt 16 talen en heeft een optionele denkmodus die vóór het antwoord een redeneerpass produceert. De output is proza.

WeVisOne-VL-4B is gebouwd op een Qwen3-VL-backbone en heet 4B, hoewel de Hugging Face-metadata het afrondt naar 5B en artikelen van derden het werkelijke aantal op bijna 4,83B schatten. Het antwoordt niet zozeer in proza, maar geeft veeleer geometrie als uitvoer: boxen en punten als genormaliseerde coördinaattokens van 0 tot 1000, een OBJ-markering (token-id 152678) na elke voorspelde box, en de letterlijke string None wanneer het doel ontbreekt. Maskers en alfa-mattes vereisen een tweede artefact, mask_decoder.pt, een pixeldecoder met 9,6M parameters die de verborgen toestand van elk OBJ-token en de voorspelde box als invoer neemt en alfa op volledige resolutie met stride 1 retourneert. Het is single-turn en alleen voor afbeeldingen, en het genereert direct gestructureerde uitvoer, zonder chain-of-thought.

Het contrast in één keer:

• Grootte — LFM3-VL-2B 1,92B dense versus WeVisOne-VL-4B ongeveer 4,83B, plus een decoder van 9,6M die verplicht is voor maskers

• Input — tekst, afbeelding en video met 2 fps versus tekst en één afbeelding

• Uitvoer — proza en een denkronde versus coördinatentokens, boxes, masks, mattes, of een expliciete None

• Context — 128K tokens versus geen gepubliceerde inferentielimiet op de modelkaart; het artikel beschrijft training op 4.096 en 8.192 tokens

• Taalbereik — 16 talen vermeld vs. geen vermeld

• Licentie — LFM Open License v1.0, gratis voor commercieel gebruik onder $10M jaaromzet, tegenover Apache 2.0 voor door Tencent geschreven code

• Runtime — GGUF/llama.cpp, MLX 4-bit, ONNX en BF16 versus BF16 via Transformers, vLLM of SGLang

De upgrade is ongelijkmatig, en de paper laat zien waar

WeVisOne-VL-2B en WeVisOne-VL-4B zijn dezelfde architectuur op twee schalen, getraind op dezelfde ongeveer 100 miljoen afbeeldingen volgens hetzelfde driedelige curriculum en geëvalueerd op dezelfde tabel. Dat maakt de vergelijking tussen de zustermodellen het zuiverste beschikbare bewijs over wat de extra parameters doen — en het wijst niet één richting uit.

Waar de 4B duidelijk wint, op basis van Tencent's cijfers:

• Dense200-detectie — 71,3 gemiddelde F1 versus 61,4, de grootste individuele winst

• LVIS — 55,3 tegenover 53,3, een bescheiden verbetering van 2 punten

• RefCOCOg-referentiedetectie — 81,8 test vs 78,2

• RefCOCO refererende segmentatie — 84,5 cIoU op testA versus 82,9

• ReasonSeg — 71,2 cIoU op val versus 60,9, een sprong van 10 punten bij redeneersegmentatie

• PointBench-aanwijzen — 71,9 vs 62,9

• WeRefMat referring matting — 9,8 gemiddeld absoluut verschil op de referring-split versus 15,8, een foutreductie van 38%

Waar dat niet het geval is:

• P3M-500-NP doosmat — 7,3 tegen 6,6 van de 2B, slechter

• PPM-100 boxmat — 6,1 vs 5,3, slechter

• Ref-ZOM cIoU — 72,2 test vs 73,4, de 2B weer voorop

Het patroon is leesbaar, ook al is de oorzaak niet gepubliceerd: de 4B loopt voorop bij taken die moeilijk en taalgeconditioneerd zijn — referring segmentation, reasoning segmentation, referring matting op echte scènes — en levert niets in op de makkelijkere box-prompted matting-sets, waar beide modellen al dicht bij het plafond zitten en de 9,6M-decoder misschien het meeste werk doet. Twee van de drie box-prompted matting-benchmarks bewegen de verkeerde kant op. Als alpha matting op een aangeleverde box je enige taak is, is de 4B geen upgrade; het is een duurdere manier om hetzelfde antwoord te krijgen, iets slechter.

Afwezige objecten: beter, nog steeds niet opgelost

De meest nuttige kolom in het artikel is degene die bijna geen enkele modelkaart voor vision-modellen publiceert. RefCOCOg-Rej is een variant waarin elke expressie zodanig is aangepast dat er geen overeenkomend object bestaat in de afbeelding. Een model dat geen "nee" kan zeggen, verzint een box, en elke daaropvolgende uitsnede, telling en masker erft dat verzinsel.

WeVisOne-VL-4B wijst correct af in 67,4% van de gevallen, tegenover 50,2% voor de 2B. Dat is een echte en grote verbetering — een winst van 17 punten die de faalmodus van een pipeline verandert van een muntworp naar twee op de drie. Het betekent ook dat de 4B nog steeds een zelfverzekerde box retourneert voor ongeveer één op de drie queries naar een afwezig object. Op Tencent's eigen interne WeRef-Bench leest het afwijzingspercentage 96,4%, maar die benchmark bestaat uit 2.880 Engelse en Chinese queries die het lab zelf heeft gebouwd, dus meet hij een vriendelijkere distributie dan de publieke. De eerlijke samenvatting is dat het model een bruikbaar abstentiegedrag heeft en het probleem niet heeft opgelost; als je applicatie geen gehallucineerde regio kan tolereren, is hiervoor een drempel of een tweede controle bovenop nodig, welk model je ook kiest.

Het getal dat er vergelijkbaar uitziet, maar dat niet is

Het is verleidelijk om LFM3-VL-2B's 90,5 RefCOCO-avg naast WeVisOne-VL-4B's 81,8 RefCOCOg te zetten en een overwinning van 8,7 punten voor het kleinere model aan te kondigen. Doe dat niet. Dat zijn verschillende splits en verschillende metrieken: Liquid rapporteert een gemiddelde over de RefCOCO-familie, Tencent rapporteert RefCOCOg-test-F1 voor referring detection. Als je ze van elkaar aftrekt, krijg je een getal zonder referent.

Dezelfde valkuil zit in OCR. LFM3-VL-2B scoort 86,3 op OCRBench v1, een samengestelde benchmark voor tekstherkenning, -spotting en redeneren; WeVisOne-VL-4B scoort een gemiddelde F1 van 52,0 op TotalText, een benchmark voor localisatie van scènetekst. Het ene is een brede examentoets, het andere een dense-predictiontaak. Het zijn niet dezelfde vaardigheid, twee keer gemeten.

De twee leverancierstabellen overlappen niet op één enkel vergelijkbaar cijfer. Wat wel eerlijk te vergelijken is, zijn mogelijkheden en kosten, en daarom gaat de rest van deze vergelijking over geschiktheid in plaats van rangorde. Wie uit deze twee tabellen een winnaar publiceert, verzint er een.

Geheugen is de echte prijs

Geen van beide modellen heeft op 28 oktober 2026 een gepubliceerde prijs per token. De kaart van Liquid linkt API- en Playground-toegang via de console, maar voor LFM3-VL-2B is geen tariefkaart gepubliceerd; de externe trackers die de tarieven van Liquid-tekstmodellen vermelden, dekken het visionmodel niet. Tencent heeft helemaal geen gehost endpoint. De vergelijking is dus een selfhostingvergelijking, en de rekening wordt in geheugen uitgedrukt.

• LFM3-VL-2B — ongeveer 3,84 GB bij BF16, berekend op basis van het aantal parameters, met daarnaast gepubliceerde 4-bit MLX-, GGUF- en ONNX-builds

• WeVisOne-VL-4B — volgens schattingen van derden ongeveer 9,7 GB bij BF16, ongeveer 19 GB in F32, plus het vereiste mask_decoder.pt

Dat gat van 2,5× is niet zomaar een grotere GPU. Het is een andere klasse apparaat. De LFM3-VL-2B-kaart zegt expliciet dat het model is gebouwd voor werk op het apparaat zelf — vragen over video, documenten, grafieken en app-schermen, objecten vinden, ruimtelijk redeneren voor robots — en de MLX 4-bit- en GGUF-builds zijn hoe die belofte wordt nagekomen: een laptop, een telefoon, een robotchassis. De gedocumenteerde paden van WeVisOne-VL-4B zijn Transformers, vLLM en SGLang op BF16, zonder officiële gekwantiseerde build en zonder runtime op het apparaat. Het vraagt om een server-GPU.

Het is de moeite waard om frameworkondersteuning aan je eigen pad te toetsen in plaats van aan de tabel. Video met 2 fps is een modelcapaciteit in LFM3-VL-2B, maar of een gegeven runtime een videogrid accepteert, is een aparte vraag, en de modelkaart, de ports en de upstream-PR's zijn het daar niet altijd over eens geweest. Test de exacte combinatie die je van plan bent te leveren.

OrcaRouter host geen van beide modellen. Dat is op 28 oktober 2026 geverifieerd aan de hand van de catalogus, niet aangenomen — noch Liquid's LFM3-lijn noch Tencent's WeVisOne staat in de modellenlijst — dus niets hier mag worden opgevat als een route naar een van beide. Wat de OrcaRouter-modelcatalogus wel bevat, is Qwen3-VL-8B, in instruct- en thinking-varianten, wat de pragmatische optie is als je werkelijke vereiste een gehost visionmodel met een vandaag gepubliceerde prijs is in plaats van een zelf gehost checkpoint. Eén sleutel geeft toegang tot alles tegen de lijstprijs van de provider, zonder marge, en als je prototypet tegen een onbewezen open-weight model, dan is het draaien via een router met failover beter dan een productiepad te koppelen aan een checkpoint dat nog geen onafhankelijke evaluatie heeft gehad.

Welke moet je kiezen?

• Kies WeVisOne-VL-4B wanneer de oplevering geometrie is — masks, alpha mattes, dichte boxes, aantallen, pointing — op stilstaande beelden, wanneer de queries taalgeconditioneerd zijn in plaats van box-geprompt, en wanneer je een GPU over hebt

• Kies WeVisOne-VL-2B in plaats van de 4B wanneer je taak box-prompted matting op gewone scènes is; volgens de gepubliceerde cijfers is het kleinere model daar beter in en kost het minder dan de helft van het geheugen

• Kies LFM3-VL-2B wanneer de invoer video bevat, wanneer het document lang is, wanneer het antwoord een zin moet zijn in plaats van een polygoon, of wanneer het apparaat geen server is

• Kies geen van beide als je deze week een gehoste endpoint met een gepubliceerde prijs per token nodig hebt — geen van beide leveranciers biedt die aan, en geen enkele hoeveelheid benchmarking dicht die kloof

• Kies beide alleen als je twee uitvoerschema's en twee integratiepaden accepteert; de gedeelde parameterband "ongeveer 2B tot 5B" verbergt twee verschillende producten

Wat zou dit veranderen

Drie dingen. Een onafhankelijk testharnas dat beide modellen op dezelfde afbeeldingen met dezelfde prompts draait — tot die tijd is alles hierboven een leverancierstabel die zorgvuldig is gelezen, wat beter is dan een leverancierstabel die slordig is gelezen, maar nog geen bewijs van kwaliteit. Een gequantiseerde WeVisOne-build, of een on-device runtime, wat het geheugenargument van beslissend naar bespreekbaar zou verschuiven. En een gepubliceerde prijs per token van een van beide kanten, wat rekenwerk over gigabytes zou vervangen door een getal waar iemand een budget op kan baseren.

De minst waarschijnlijke van de drie is degene die voor deze specifieke combinatie het meest van belang zou zijn: ondersteuning voor video in WeVisOne's pixeldecoder. Op dit moment accepteert de 2B-generalist een video en kan het 4B-instrument dat niet, en geen enkel aantal parameters verhelpt een modaliteit die nooit is getraind.