LFM3-VL-2B vs WeVisOne-VL-2B: Drie dagen na elkaar, tegenovergestelde weddenschappen

LFM3-VL-2B verscheen op 19 oktober 2026 op Hugging Face. WeVisOne-VL-2B verscheen op 22 oktober. Twee modellen, beide rond twee miljard parameters, beide open-weight, beide van gerenommeerde labs, binnen 72 uur na elkaar gepubliceerd. Je zou verwachten dat ze bijna inwisselbaar zijn. Ze liggen dichter bij tegengestelde gokken op wat "visie" betekent: het ene beantwoordt vragen over wat het ziet, het andere geeft de precieze vorm terug van wat het ziet.

Dat onderscheid is makkelijk te missen op een specspecificatie, omdat beide kaarten "boxes" vermelden en beide kaarten OCR vermelden. Het verschil zit in het uitvoerformaat en de trainingsdoelstelling, en dat bepaalt of je een van beide modellen in een pipeline kunt inzetten zonder een parsinglaag. Het bepaalt ook welk van de twee nog bestaansrecht heeft nadat de general-purpose modellen beter worden.

Twee definities van zien

LFM3-VL-2B is het generalistische model van Liquid AI. Het verwerkt tekst, afbeeldingen en video met 2 fps, genereert tekst, ondersteunt stapsgewijs denken, heeft een contextvenster van 128K en ondersteunt 16 talen. De architectuur is een dense model van 1,92B — een taalbackbone van 1,73B, een eigen vision-encoder van 164M en een projector van 25M — met gepubliceerde builds voor BF16, GGUF, MLX 4-bit en ONNX. In Liquid's bericht over de familie wordt het gepositioneerd als een model dat "kan kijken, redeneren en de fysieke wereld begrijpen", en de videoroute is echt nieuw voor de familie.

WeVisOne-VL-2B is het WeChat Vision-model van Tencent. Het is gebouwd op een Qwen3-VL-backbone met ongeveer 2,4B parameters onder Apache 2.0, en het doel is uniforme perceptie: open-vocabulary-detectie, referring-lokalisatie, tellen, aanwijzen, OCR-lokalisatie, referring-segmentatie en promptable alpha matting. Het retourneert genormaliseerde coördinaten via speciale tokens, plus maskers via een aparte pixeldecoder met 9,6M parameters die samen met het taalmodel moet worden geladen.

Het ene model is een lezer. Het andere is een meetinstrument. De overlap in hun benchmarktabellen is reëel, maar het is de overlap van twee verschillende producten die dezelfde scène meten.

Het uitvoerformaat is het product.

WeVisOne-VL-2B codeert coördinaten als tokens van <0> tot <1000>, markeert elk exemplaar met een <OBJ>-token en retourneert None wanneer het gevraagde doel ontbreekt. Dat laatste detail is wat praktijkmensen opvalt: de kaart meldt een afwijzingspercentage van 50,2 op RefCOCOg, tegenover ongeveer 0,5 voor Rex-Omni en LocateAnything. Het is getraind om "niet hier" te zeggen in plaats van een box te hallucineren.

De pixeldecoder is niet optioneel. Segmentatie en alpha matting vereisen mask_decoder.pt, een module met 9,6M parameters die wordt geactiveerd door het objecttoken. Als je alleen het taalmodel laadt, krijg je coördinaten maar geen maskers. De GitHub-repository bevat het inferentiepakket dat de twee met elkaar verbindt, en het model is qua opzet single-turn en uitsluitend voor afbeeldingen — de pixeldecoder weigert videorasters.

LFM3-VL-2B heeft geen gelijkwaardig contract. Het zal een regio beschrijven, objecten tellen of in proza over een scène redeneren, en zijn grounding-rij (RefCOCO-avg 90.5) suggereert dat het bekwaam is in localisatie. Maar de uitvoer is tekst. Voor een pipeline die een masker nodig heeft, is het verschil tussen 90.5 en een parseerbare polygoon het verschil tussen een demo en een product.

Grounding-getallen die je niet kunt aftrekken

De twee kaarten rapporteren beide resultaten uit de RefCOCO-familie, en dat zijn niet dezelfde meting. LFM3-VL-2B rapporteert RefCOCO-avg 90,5, wat het gemiddelde is over de splits voor verwijzende uitdrukkingen. WeVisOne-VL-2B rapporteert RefCOCOg 77,1 gemiddelde F1 voor verwijzende detectie en RefCOCO testA 82,9 cIoU voor verwijzende segmentatie. RefCOCOg is een andere split met langere, meer conversationele uitdrukkingen; cIoU is een andere metriek dan F1.

77,1 aftrekken van 90,5 levert een getal op dat niets betekent. De eerlijke lezing is dat beide modellen sterk zijn in het lokaliseren op basis van verwijzingen op hun eigen harnesses, dat geen van beide harnesses onafhankelijk is gereproduceerd, en dat de definities van de metrics voldoende verschillen dat de rangschikking onbeslist is. Dezelfde voorzichtigheid geldt voor OCR: LFM3-VL-2B rapporteert 86,3 op OCRBench v1, terwijl WeVisOne-VL-2B 30,5 rapporteert op OCR HierText, wat een andere benchmark op een moeilijkere dataset is.

Waar de vergelijking zuiver is, begunstigt die de specialist op eigen terrein: WeVisOne-VL-2B rapporteert COCO-detectie-F1 55,2, LVIS 53,3 en Dense200 61,4, tegenover een model dat helemaal geen detectie-F1 publiceert. Dat is geen automatische overwinning. Het is een herinnering eraan dat de generalist niet is getraind om op die manier te worden gescoord.

De matte afwerking is de slotgracht

Promptbare alpha matting is de functie die noch LFM3-VL-2B noch de meeste modellen in zijn grootteklasse bieden. WeVisOne-VL-2B rapporteert een gemiddeld absoluut verschil van 6,6 op P3M-500-NP voor mattes met zachte randen — de semi-transparante grens rond haar, glas en bont die een binair segmentatiemasker verandert in een harde snede. De kaart is openhartig over de beperkingen: fijne alfagrenzen degraderen bij occlusie, lage resolutie en transparantie. Maar voor productuitsnedes, compositing en achtergrondvervanging is een matte de output die de pipeline daadwerkelijk nodig heeft.

Dit is het sterkste argument voor het bestaan van het model. Een 2B-generalist kan een afbeelding beschrijven; hij kan je geen zacht alfakanaal geven. Tencent bouwde een klein model rond een pixeldecoder omdat die output duur is om van een groot algemeen model te krijgen, en het 4B-zusje bestaat voor teams die bij dezelfde taak meer nauwkeurigheid nodig hebben.

Video en denken zijn de andere verdedigingsgracht.

Het onderscheidende punt van LFM3-VL-2B werkt juist de andere kant op. Het accepteert video aan 2 fps en rapporteert Video-MME 62,8 zonder ondertitels, MVBench 69,4 en MMMB 85,2. WeVisOne-VL-2B is single-turn en alleen voor afbeeldingen; de pixeldecoder ervan weigert videorasters. Als je invoer een clip is, is de vergelijking al voorbij voordat de benchmarktabel begint.

De denkmodus voegt een tweede kloof toe. LFM3-VL-2B rapporteert MathVista 84,2 met denkmodus tegenover 68,5 zonder, en MMMU 55,7 tegenover 48,6. WeVisOne-VL-2B heeft om efficiëntieredenen bewust geen chain-of-thought. Dat is een legitieme technische keuze voor een perceptiecomponent en een harde beperking voor een model waarmee je over een grafiek wilt redeneren.

Geheugen, licentie en de toegangsprijs

• Parameters — LFM3-VL-2B 1,92B dense versus WeVisOne-VL-2B ongeveer 2,4B, plus een pixeldecoder van 9,6M.

• Geheugen — ongeveer 3,84 GB BF16 volgens berekening voor LFM3-VL-2B, met een 4-bit MLX-build; ruwweg 9,1 GB aan gewichten in F32 en naar schatting 4,9 GB in BF16 voor WeVisOne-VL-2B, volgens implementatienotities van derden in plaats van de kaart.

• Invoer — tekst, afbeelding en video met 2 fps versus alleen afbeelding en tekst, één beurt.

• Uitvoer — proza, optioneel met redenering versus tekst, genormaliseerde coördinaten, maskers en alfa-mattes.

• Context — 128K versus niet vermeld als een venster op documentniveau; de pixeldecoder is de beperkende factor.

• Licentie — LFM Open License v1.0, commercieel gebruik onder $10M jaarlijkse omzet versus Apache 2.0 bij elke omvang.

• Gepubliceerd — repository 19 oktober 2026, familieaankondiging 27 oktober vs repository 22 oktober 2026.

De licentiekwestie is het omgekeerde van het gebruikelijke verhaal. Het model van Tencent is het model met de permissieve licentie; dat van Liquid is het model met een omzetplafond. Voor een bedrijf dat een commercieel perceptieproduct bouwt, neemt Apache 2.0 een due-diligencepunt weg dat door de LFM-licentie wordt gecreëerd. Dat maakt de modellen niet uitwisselbaar, maar het betekent wel dat het kleinere, algemenere model de grotere juridische beperking met zich meebrengt.

Geen van beide modellen heeft een gehoste prijs.

Beide modelkaarten publiceren gewichten en geen van beide publiceert een API-tarief per token. Hugging Face vermeldt geen inferentieprovider voor LFM3-VL-2B; de kaart van WeVisOne-VL-2B heeft evenmin een gehost endpoint, hoewel er community-ports bestaan voor LiteRT, Core AI, GGUF en Android. Dit is de huidige vorm van de 2B-visietier: de gewichten zijn gratis, het serveren is aan jou, en de werkelijke kosten zijn de GPU en het integratiewerk.

Als je die tier liever huurt dan bezit, routeert OrcaRouter gehoste visionmodellen — waaronder Qwen3-VL-8B — via één API met de lijstprijs van de provider doorgegeven tegen 0% opslag, en model fusion als je wilt dat een perceptiemodel en een redeneermodel als panel antwoorden. Wij leveren in deze vergelijking geen van beide checkpoints, en niets hier impliceert dat we dat wel doen. Het relevante punt is dat het huren van een iets groter gehost model een legitieme derde optie is wanneer geen van beide open-weightmodellen met een endpoint wordt geleverd.

Hoe te kiezen

• Kies WeVisOne-VL-2B als de output geometrie is: boxes, maskers, alpha mattes, aantallen of een signaal 'niet aanwezig'. Kies het als Apache 2.0 niet onderhandelbaar is, of als je een cut-out-, compositing- of roboticaperceptiepipeline bouwt.

• Kies LFM3-VL-2B als de invoer video bevat, als je moet redeneren over een grafiek of een formulier, of als je wilt dat één klein model algemene vragen beantwoordt in plaats van vormen te meten.

• Neem beide alleen als je bereid bent twee pijplijnen te draaien. Ze delen één parameterklasse en vrijwel niets anders, en de integratiekosten van doen alsof dat niet zo is, zijn hoger dan de kosten van het tweede model.

Het gat van drie dagen tussen hun repositories is toeval. Het verschil in wat ze teruggeven is dat niet. Twee labs keken naar hetzelfde budget van 2 miljard en gaven het uit aan verschillende outputs, en de juiste vraag is niet welke beter is — maar welke output je volgende pijplijnstap daadwerkelijk kan consumeren.