LFM3-VL-2B vs WeVisOne-VL-2B: Tre dagar isär, motsatta satsningar

LFM3-VL-2B dök upp på Hugging Face den 19 oktober 2026. WeVisOne-VL-2B dök upp den 22 oktober. Två modeller, båda runt två miljarder parametrar, båda med öppna vikter, båda från välkända labb, publicerade inom 72 timmar från varandra. Man skulle förvänta sig att de nästan var utbytbara. De är snarare motsatta satsningar på vad "vision" betyder: den ena svarar på frågor om vad den ser, den andra returnerar den exakta formen på det den ser.

Den distinktionen är lätt att missa i ett datablad, eftersom båda korten listar boxar och båda korten listar OCR. Skillnaden ligger i utdataformatet och träningsmålet, och den avgör om du kan lägga in endera modellen i en pipeline utan ett parsningslager. Den avgör också vilken av dem som har en anledning att finnas kvar när de generella modellerna blir bättre.

Två definitioner av seende

LFM3-VL-2B är Liquid AIs generalistmodell. Den tar emot text, bilder och video vid 2 fps, ger text som utdata, stöder steg-för-steg-tänkande, har en kontext på 128K och täcker 16 språk. Arkitekturen är en dens 1,92B-modell – en språkbackbone på 1,73B, en egenutvecklad visionskodare på 164M och en projektor på 25M – med publicerade byggen för BF16, GGUF, MLX 4-bit och ONNX. Liquids familjeinlägg beskriver den som en modell som kan "observera, resonera och förstå den fysiska världen", och videovägen är verkligen ny för familjen.

WeVisOne-VL-2B är Tencents WeChat Vision-modell. Den är byggd på en Qwen3-VL-stomme med cirka 2,4 miljarder parametrar under Apache 2.0, och dess syfte är enhetlig perception: detektion med öppen vokabulär, refererande lokalisering, räkning, pekning, OCR-lokalisering, refererande segmentering och promptbar alpha matting. Den returnerar normaliserade koordinater via dedikerade tokens, samt masker via en separat pixelavkodare med 9,6 miljoner parametrar som måste laddas tillsammans med språkmodellen.

Den ena modellen är en läsare. Den andra är ett mätinstrument. Överlappningen i deras benchmarktabeller är verklig, men det är överlappningen mellan två olika produkter som mäter samma scen.

Utdataformatet är produkten

WeVisOne-VL-2B kodar koordinater som token från <0> till <1000>, markerar varje instans med en <OBJ>-token och returnerar None när det efterfrågade målet saknas. Den sista detaljen är den som utövare lägger märke till: kortet rapporterar en avvisningsfrekvens på 50,2 på RefCOCOg, jämfört med ungefär 0,5 för Rex-Omni och LocateAnything. Den är tränad att säga "inte här" i stället för att hallucinera en ruta.

Pixelavkodaren är inte valfri. Segmentering och alfa-mattning kräver mask_decoder.pt, en modul med 9,6 miljoner parametrar som utlöses av objekt-token. Om du bara laddar språkmodellen får du koordinater men inte masker. GitHub-förrådet levererar inferenspaketet som kopplar ihop de två, och modellen är avsedd för en enda tur och endast bilder – pixelavkodaren avvisar videorutnät.

LFM3-VL-2B har inget motsvarande kontrakt. Den beskriver en region, räknar objekt eller resonerar om en scen i prosa, och dess grounding-rad (RefCOCO-avg 90,5) tyder på att den är kompetent på lokalisering. Men utdata är text. För en pipeline som behöver en mask är skillnaden mellan 90,5 och en parsbar polygon skillnaden mellan en demo och en produkt.

Grundläggande tal du inte kan subtrahera

De två korten rapporterar båda resultat för RefCOCO-familjen, och de är inte samma mätning. LFM3-VL-2B rapporterar RefCOCO-avg 90,5, vilket är ett genomsnitt över delningarna för referensuttryck. WeVisOne-VL-2B rapporterar RefCOCOg 77,1 i medel-F1 för detektion av referensuttryck och RefCOCO testA 82,9 cIoU för segmentering av referensuttryck. RefCOCOg är en annan delning med längre, mer samtalsliknande uttryck; cIoU är ett annat mått än F1.

Att subtrahera 77,1 från 90,5 ger ett tal som inte betyder något. Den ärliga tolkningen är att båda modellerna är starka på refererande lokalisering i sina egna utvärderingsramverk, att inget av ramverken har reproducerats oberoende och att metrikdefinitionerna skiljer sig tillräckligt mycket för att rangordningen inte kan avgöras. Samma försiktighet gäller för OCR: LFM3-VL-2B rapporterar 86,3 för OCRBench v1, medan WeVisOne-VL-2B rapporterar 30,5 för OCR HierText, vilket är ett annat benchmark på en svårare datamängd.

När jämförelsen är rättvis gynnas specialisten på sin hemmaplan: WeVisOne-VL-2B rapporterar COCO-detektions-F1 55,2, LVIS 53,3 och Dense200 61,4, jämfört med en modell som inte publicerar något detektions-F1 alls. Det är inte en seger per automatik. Det är en påminnelse om att generalisten inte tränades för att bedömas på det sättet.

Den matta ytan är vallgraven.

Promptbar alpha matting är den funktion som varken LFM3-VL-2B eller större delen av dess storleksklass erbjuder. WeVisOne-VL-2B rapporterar en genomsnittlig absolut differens på 6,6 på P3M-500-NP för mjuka mattar — den halvtransparenta gränsen runt hår, glas och päls som en binär segmenteringsmask gör om till ett hårt snitt. Kortet är uppriktigt om begränsningarna: fina alfakanter försämras vid ocklusion, låg upplösning och transparens. Men för produkturklipp, compositing och bakgrundsbyte är en matte den utdata som pipelinen faktiskt behöver.

Det här är det starkaste argumentet för att modellen finns. En 2B-generalist kan beskriva en bild; den kan inte ge dig en mjuk alfakanal. Tencent byggde en liten modell kring en pixelavkodare eftersom den typen av utdata är dyr att få från en stor allmänmodell, och syskonmodellen på 4B finns för team som behöver högre noggrannhet i samma uppgift.

Video och tänkande är den andra vallgraven

LFM3-VL-2B:s särskiljande egenskap går åt andra hållet. Den tar emot video med 2 fps och rapporterar Video-MME 62,8 utan undertexter, MVBench 69,4 och MMMB 85,2. WeVisOne-VL-2B är enkelomgångs och endast bildbaserad; dess pixelavkodare avvisar videorutnät. Om din indata är ett klipp är jämförelsen över innan benchmark-tabellen ens börjar.

Tankeläget tillför en andra klyfta. LFM3-VL-2B rapporterar MathVista 84,2 med tankeläge mot 68,5 utan, och MMMU 55,7 mot 48,6. WeVisOne-VL-2B har inget kedjetänkande av design, för effektivitetens skull. Det är ett legitimt ingenjörsval för en perceptionskomponent och en hård begränsning för en modell som man vill ska resonera kring ett diagram.

Minne, licens och priset för inträde

• Parametrar — LFM3-VL-2B 1,92B dense kontra WeVisOne-VL-2B ungefär 2,4B, plus en pixelavkodare på 9,6M.

• Minne — cirka 3,84 GB BF16 enligt beräkning för LFM3-VL-2B, med en 4-bitars MLX-build; ungefär 9,1 GB vikter i F32 och uppskattningsvis 4,9 GB i BF16 för WeVisOne-VL-2B, enligt tredjepartsanteckningar om driftsättning snarare än kortet.

• Indata — text, bild och video vid 2 fps jämfört med endast bild och text, en enda tur.

• Utdata — prosa, eventuellt med resonemang kontra text, normaliserade koordinater, masker och alfamattor.

• Kontext — 128K kontra inte angivet som ett fönster i dokumentstorlek; pixelavkodaren är begränsningen.

• Licens — LFM Open License v1.0, kommersiell användning under 10 MUSD i årlig intäkt jämfört med Apache 2.0 oavsett storlek.

• Publicerad — repositorium 19 oktober 2026, familjemeddelande 27 oktober vs repositorium 22 oktober 2026.

Licensraden är det omvända mot det vanliga. Tencents modell är den med tillåtande licens; Liquids är den med ett intäktstak. För ett företag som bygger en kommersiell perceptionsprodukt tar Apache 2.0 bort en granskningspunkt som LFM-licensen skapar. Det gör inte modellerna utbytbara, men det innebär att den mindre, mer generella modellen bär den större juridiska begränsningen.

Ingen av modellerna har ett hostat pris

Båda korten publicerar vikter och inget av dem publicerar någon API-avgift per token. Hugging Face listar ingen inferensleverantör för LFM3-VL-2B; WeVisOne-VL-2B:s kort har likaså ingen hostad slutpunkt, även om det finns community-portningar för LiteRT, Core AI, GGUF och Android. Detta är den nuvarande formen av 2B-visionsnivån: vikterna är gratis, serveringen är din, och den verkliga kostnaden är GPU:n och integrationsarbetet.

Om du hellre vill hyra den nivån än äga den dirigerar OrcaRouter hostade bildmodeller – bland dem Qwen3-VL-8B – via ett enda API, med leverantörens listpris vidarebefordrat med 0 % påslag, och modellfusion om du vill att en perceptionsmodell och en resonemangsmodell ska svara som en panel. Vi tillhandahåller inte någon av checkpointarna i den här jämförelsen, och inget här antyder att vi gör det. Den relevanta poängen är att hyra en något större hostad modell är ett legitimt tredje alternativ när ingen av modellerna med öppna vikter levereras med en endpoint.

Hur man väljer

• Välj WeVisOne-VL-2B om utdata är geometri: boxar, masker, alfamattor, antal eller en signal om "inte närvarande". Välj den om Apache 2.0 är icke-förhandlingsbart, eller om du bygger en pipeline för utklippning, kompositering eller robotperception.

• Välj LFM3-VL-2B om indata innehåller video, om du behöver resonera kring ett diagram eller ett formulär, eller om du vill ha en liten modell som svarar på allmänna frågor i stället för att mäta former.

• Ta båda endast om du är beredd att köra två pipelines. De delar en parameterklass och nästan ingenting annat, och integrationskostnaden för att låtsas något annat är högre än kostnaden för den andra modellen.

Tre dagars gap mellan deras repon är en tillfällighet. Skillnaden i vad de returnerar är det inte. Två labb tittade på samma 2B-budget och spenderade den på olika utdata, och rätt fråga är inte vilken som är bättre — det är vilken utdata ditt nästa pipeline-steg faktiskt kan konsumera.