LFM3-VL-2B vs WeVisOne-VL-4B: Vad 2,5× parametrarna faktiskt ger

Tencents egen benchmarktabell talar emot det uppenbara köpet. WeVisOne-VL-4B, det större av de två perceptionsmodellerna som WeChat Vision-teamet publicerade den 22 oktober 2026, är sämre på box-promptad alpha matting än sitt eget 2B-syskon: 7,3 i genomsnittlig absolut avvikelse på P3M-500-NP mot 2B:ans 6,6, där lägre är bättre. Den modell som de flesta köpare faktiskt kommer att jämföra den med är dock inte dess syskon utan LFM3-VL-2B — Liquid AIs 1,92B stora visionsmodell för enheter, vars vikter publicerades den 19 oktober och som tillkännagavs tillsammans med resten av LFM3-familjen den 27 oktober.

Ställ de två sida vid sida och den intressanta frågan är inte vilken som är smartare. Det är vad två och en halv gånger parametrarna ger dig, och vad de kostar. Det korta svaret, från leverantörernas egna tabeller: de ger tät detektering, referensnoggrannhet och en mycket bättre andel vägran att svara när objektet inte finns där. De ger dig inte en generalist, de ger dig inte video, och de ger dig inte en modell som du kan lägga på en telefon. Allt nedan kommer från de två publicerade tabellerna med sömmarna synliga – inget oberoende testramverk har reproducerat någon av modellernas siffror.

Vad var och en faktiskt är

LFM3-VL-2B har 1,92B densa parametrar: en språkryggrad på 1,73B, en egenutvecklad vision-encoder på 164M och en projektor på 25M. Ryggraden är Liquid's tri-hybridstack – 24 lager uppdelade i 13 gated short-konvolutioner, 5 sliding-window-attentionslager med ett fönster på 256 token och 6 globala attentionslager. Den tar text, bilder och video i native upplösning, samplar video med 2 bildrutor per sekund, har en kontext på 128K token, täcker 16 språk och har ett valfritt tänkläge som ger en resonemangsomgång före svaret. Dess utdata är prosa.

WeVisOne-VL-4B är byggd på en Qwen3-VL-stomme och har fått namnet 4B, även om Hugging Face-metadata avrundar det till 5B och tredjepartsartiklar anger det faktiska antalet till nära 4,83B. Den svarar inte så mycket i prosa som den avger geometri: boxar och punkter som normaliserade koordinattoken från 0 till 1000, en OBJ-markör (token-id 152678) efter varje förutsagd box, och den bokstavliga strängen None när målet saknas. Masker och alfamattor kräver en andra artefakt, mask_decoder.pt, en pixeldekoder med 9,6M parametrar som tar det dolda tillståndet för varje OBJ-token och den förutsagda boxen och returnerar alfakanal i full upplösning med stride 1. Den är single-turn och enbart bildbaserad, och den genererar strukturerad utdata direkt, utan kedjetänkande.

Kontrasten i ett svep:

• Storlek — LFM3-VL-2B 1,92B dense jämfört med WeVisOne-VL-4B cirka 4,83B, plus en dekoder på 9,6M som är obligatorisk för masker

• Indata – text, bild och video med 2 fps jämfört med text och en enda bild

• Utdata — prosa och en tankegenomgång kontra koordinattoken, boxar, masker, mattor eller ett explicit None

• Kontext — 128K token jämfört med ingen publicerad inferensgräns på modellkortet; rapporten beskriver träning vid 4 096 och 8 192 token

• Språktäckning — 16 språk angivna kontra inga angivna

• Licens — LFM Open License v1.0, gratis för kommersiellt bruk under 10 miljoner USD i årlig intäkt jämfört med Apache 2.0 för kod skriven av Tencent

• Körmiljö — GGUF/llama.cpp, MLX 4-bit, ONNX och BF16 mot BF16 via Transformers, vLLM eller SGLang

Uppgraderingen är ojämn, och artikeln visar var

WeVisOne-VL-2B och WeVisOne-VL-4B är samma arkitektur i två skalor, tränade på samma cirka 100 miljoner bilder genom samma trestegsutbildningsplan och utvärderade på samma tabell. Det gör syskonjämförelsen till det tydligaste beviset som finns för vad de extra parametrarna gör – och den pekar inte i en enda riktning.

Där 4B tydligt vinner, enligt Tencents siffror:

• Dense200-detektering – 71,3 genomsnittlig F1 mot 61,4, den enskilt största förbättringen

• LVIS — 55,3 mot 53,3, en blygsam förbättring på 2 punkter

• RefCOCOg-referensdetektering — 81,8 test mot 78,2

• RefCOCO-refererande segmentering – 84,5 cIoU på testA mot 82,9

• ReasonSeg — 71,2 cIoU på val mot 60,9, ett hopp på 10 poäng inom resonemangssegmentering

• PointBench pekning — 71,9 vs 62,9

• WeRefMat refererande matting — 9,8 genomsnittlig absolut skillnad på referring-uppdelningen jämfört med 15,8, en minskning av felet med 38 %

Där det inte gör det:

• P3M-500-NP boxmattning — 7,3 jämfört med 2B:s 6,6, sämre

• PPM-100 boxmattning — 6,1 mot 5,3, sämre

• Ref-ZOM cIoU — 72,2 i test jämfört med 73,4; 2B ligger återigen före

Mönstret är tydligt även om orsaken inte är publicerad: 4B drar ifrån på uppgifter som är svåra och språkberoende – referring segmentation, reasoning segmentation, referring matting på verkliga scener – och ger inget tillbaka på de enklare box-promptade matting-seten, där båda modellerna redan ligger nära taket och 9,6M-dekodern kan göra det mesta av arbetet. Två av tre box-promptade matting-benchmarks går åt fel håll. Om alpha matting på en angiven box är din enda uppgift är 4B ingen uppgradering; det är ett dyrare sätt att få samma svar, något sämre.

Frånvarande objekt: bättre, fortfarande inte löst

Den mest användbara kolumnen i artikeln är den som nästan inget modellkort för visionsmodeller publicerar. RefCOCOg-Rej är en variant där varje uttryck ändras så att inget matchande objekt finns i bilden. En modell som inte kan säga "nej" kommer att hitta på en box, och varje nedströms beskärning, räkning och mask ärver den fabriceringen.

WeVisOne-VL-4B avvisar korrekt 67,4 % av gångerna, jämfört med 50,2 % för 2B. Det är en verklig och stor förbättring – en ökning med 17 procentenheter som förändrar en pipelines felläge från slantsingling till två av tre. Det innebär också att 4B fortfarande returnerar en självsäker box för ungefär en av tre frågor om ett frånvarande objekt. På Tencents egna interna WeRef-Bench ligger avvisningsfrekvensen på 96,4 %, men det riktmärket består av 2 880 engelska och kinesiska frågor som labbet självt har byggt, så det mäter en vänligare fördelning än den offentliga. Den ärliga sammanfattningen är att modellen har ett användbart avståendebeteende och inte har löst problemet; om din applikation inte kan tolerera en hallucinerad region krävs en tröskel eller en andra kontroll ovanpå, oavsett vilken modell du väljer.

Siffran som ser jämförbar ut men inte är det

Det är frestande att ställa LFM3-VL-2B:s 90,5 RefCOCO-avg bredvid WeVisOne-VL-4B:s 81,8 RefCOCOg och utropa en 8,7-poängsvinst för den mindre modellen. Gör inte det. Det är olika splits och olika mått: Liquid rapporterar ett genomsnitt över RefCOCO-familjen, Tencent rapporterar RefCOCOg test-F1 för referensdetektion. Att subtrahera dem ger ett tal utan referent.

Samma fälla finns i OCR. LFM3-VL-2B får 86,3 på OCRBench v1, ett sammansatt mått på textigenkänning, spotting och resonemang; WeVisOne-VL-4B får 52,0 i genomsnittlig F1 på TotalText, ett benchmark för lokalisering av text i scener. Det ena är ett brett prov, det andra en tät prediktionsuppgift. De är inte samma färdighet mätt två gånger.

Så de två leverantörstabellerna möts inte i en enda jämförbar siffra. Det som ärligt kan jämföras är förmågor och kostnad, vilket är anledningen till att resten av den här jämförelsen handlar om lämplighet snarare än rangordning. Den som publicerar en vinnare utifrån dessa två tabeller hittar på en.

Minne är det verkliga priset

Ingen av modellerna har ett publicerat pris per token den 28 oktober 2026. Liquids kort länkar till API- och Playground-åtkomst via konsolen, men ingen prislista publicerades för LFM3-VL-2B; de tredjepartsverktyg som listar Liquids priser för textmodeller täcker inte visionsmodellen. Tencent har ingen hostad slutpunkt alls. Jämförelsen blir därför en jämförelse av egen drift, och kostnaden mäts i minne.

• LFM3-VL-2B — cirka 3,84 GB i BF16 beräknat utifrån parameterantalet, med 4-bitars MLX-, GGUF- och ONNX-byggen publicerade tillsammans med den

• WeVisOne-VL-4B — cirka 9,7 GB i BF16 enligt tredjepartsuppskattningar, ungefär 19 GB i F32, plus den obligatoriska mask_decoder.pt

Den där 2,5×-skillnaden är inte bara en större GPU. Det är en annan klass av enhet. LFM3-VL-2B-kortet anger uttryckligen att modellen är byggd för arbete på enheten – frågor om video, dokument, diagram och appskärmar, att hitta objekt, spatialt resonemang för robotar – och MLX 4-bit- och GGUF-byggena är hur det löftet hålls: en laptop, en telefon, ett robotchassi. WeVisOne-VL-4B:s dokumenterade vägar är Transformers, vLLM och SGLang på BF16, utan något officiellt kvantiserat bygge och ingen runtime på enheten. Den vill ha en server-GPU.

Det är värt att kontrollera ramverksstödet mot din egen väg i stället för tabellen. Video vid 2 fps är en modellförmåga i LFM3-VL-2B, men huruvida en given runtime accepterar ett video grid är en separat fråga, och modellkortet, portningarna och upstream-PR:erna har inte alltid varit överens om det. Testa den exakta kombination du avser att skeppa.

OrcaRouter har ingen av modellerna. Det är verifierat mot katalogen den 28 oktober 2026, inte antaget – varken Liquids LFM3-serie eller Tencent WeVisOne förekommer i modellistan – så inget här bör läsas som en väg till någon av dem. Vad OrcaRouter-modellkatalogen däremot innehåller är Qwen3-VL-8B, i instruct- och thinking-varianter, vilket är det pragmatiska alternativet om ditt faktiska krav är en hostad visionmodell med ett publicerat pris idag snarare än en självhostad checkpoint. En och samma nyckel når allt detta till leverantörens listpris utan påslag, och om du prototypar mot en obeprövad open-weight-modell går det bättre att köra den genom en router med failover än att koppla en produktionsväg till en checkpoint som ännu inte har utvärderats oberoende.

Vilken ska man välja?

• Välj WeVisOne-VL-4B när det som ska levereras är geometri – masker, alfamattor, täta boxar, antal, pekningar – på stillbilder, när frågorna är språkligt betingade snarare än box-promptade, och när du har en GPU över

• Välj WeVisOne-VL-2B i stället för 4B när din uppgift är box-promptad matting på vanliga scener; enligt de publicerade siffrorna är den mindre modellen bättre på det och använder mindre än hälften så mycket minne

• Välj LFM3-VL-2B när indata innehåller video, när dokumentet är långt, när svaret behöver vara en mening snarare än en polygon, eller när enheten inte är en server

• Välj ingen av dem om du behöver en hostad slutpunkt med ett publicerat pris per token den här veckan – ingen av leverantörerna erbjuder en sådan, och ingen mängd benchmarking stänger det gapet

• Välj båda endast om du accepterar två utdatascheman och två integrationsvägar; det gemensamma parameterintervallet "cirka 2B till 5B" döljer två olika produkter

Vad skulle förändra detta

Tre saker. En oberoende testrigg som kör båda modellerna på samma bilder med samma promptar – fram till dess är allt ovanstående en leverantörstabell läst noggrant, vilket är bättre än en leverantörstabell läst slarvigt men inte är bevis på kvalitet. Ett kvantiserat WeVisOne-bygge, eller en körtid på enheten, vilket skulle flytta minnesargumentet från avgörande till förhandlingsbart. Och ett publicerat pris per token från endera sidan, vilket skulle ersätta aritmetik om gigabyte med en siffra som någon kan budgetera mot.

Den minst sannolika av de tre är den som skulle spela störst roll för just den här specifika kombinationen: videostöd i WeVisOne:s pixelavkodare. Just nu tar 2B-generalistern emot video medan 4B-instrumentet inte kan, och inget parameterantal åtgärdar en modalitet som aldrig har tränats.