WeVisOne-VL-4B vs LFM2.5-VL-3B: En matting-specialist mot en edge-speedster

Liquid AI publicerar en hastighetssiffra för LFM2.5-VL-3B och Tencent publicerar ingen för WeVisOne-VL-4B. Den asymmetrin, mer än någon benchmarkrad, är duellen. LFM2.5-VL-3B är en edge-modell med 3.1B parametrar som är trimmad att svara i ett pass: 228 tokens per sekund på en Apple M5 Max, 20 tokens per sekund på en Galaxy S26 Ultra, under 3.3 GB minne, sexton språk. WeVisOne-VL-4B är en perceptionsmodell med 4.83B parametrar som gör av med upp till 1,960 visuella tokens och en avkodare med 9.6M parametrar för att ge dig en alpha-matte i full upplösning. Den ena är byggd för att vara tillräckligt snabb för att rymmas i ett mobilgränssnitt; den andra är byggd för att mata ut pixlar. De överlappar på ordet "vision" och nästan ingen annanstans.

Det gör detta till en jämförelse som är värd att göra noggrant, eftersom den uppenbara varianten av den – att ställa benchmarktabellerna sida vid sida och utropa en vinnare – skulle vara fel på ett specifikt och lärorikt sätt.

Benchmark-tabellerna talar inte med varandra

Båda modellerna publicerar siffror för refererande uttryck och båda siffrorna ser jämförbara ut. De är inte det. LFM2.5-VL-3B rapporterar RefCOCO-avg P@1 på 87,9. WeVisOne-VL-4B rapporterar RefCOCOg test F1 mean på 81,8. Olika datasetuppdelning, olika mått, olika felmodell: P@1 frågar om den topprankade boxen är rätt, F1 mean medelvärdesberäknar precision och recall över IoU-trösklar från 0,5 till 0,95. En modell kan vinna på det ena och förlora på det andra med stor marginal utan att något av resultaten är förvånande.

Samma fälla finns i alla andra rader. Liquids 80,7 på ScreenSpot-v2 mäter grundning av UI-element; Tencent har ingen ScreenSpot-siffra. Tencents avvisningsfrekvens på 96,4 % i WeRef-Bench mäter huruvida modellen vägrar svara när objektet inte finns där; Liquid publicerar inte någon avvisningsmetrik alls. Ingen av leverantörerna utvärderade den andras modell, så ingen rad i någon av tabellerna är en direkt jämförelse.

Det som ärligt kan sägas är riktningsvisande. LFM2.5-VL-3B är en stark generalist för sin storlek – 69,4 i genomsnitt över 28 visionsbenchmarkar enligt Liquids egen räkning, inom 0,7 poäng från Qwen3.5-4B – och dess hopp för ScreenSpot-v2 från nära noll i föregående generation till 80,7 är den enskilt största förbättringen i dess tabell. WeVisOne-VL-4B konkurrerar inte på den axeln. Dess starkaste anspråk gäller tät detektering av små objekt, avvisning och utdata på pixelnivå – inget av detta försöker LFM2.5-VL-3B sig på.

Vad varje modell fysiskt sett är

• Parametrar — WeVisOne-VL-4B 4,83B dense (F32-checkpoint) mot LFM2.5-VL-3B 3,12B dense (BF16)

• Visionsväg — en Qwen3-VL-stomme plus en pixelavkodare med 9,6 M pixlar, mot en hybridtextbas med faltnings- och uppmärksamhetsmekanismer, LFM2.5-2.6B, plus en SigLIP2 NaFlex 400M-kodare

• Minne – cirka 19 GB på disk för F32 4B-kontrollpunkten jämfört med under 3,3 GB totalt utrymmesbehov för 3B

• Kontext – ingen publicerad siffra för WeVisOne-VL-4B jämfört med 32,768 tokens för LFM2.5-VL-3B

• Språk — inte angivet för WeVisOne-VL-4B jämfört med 16 för LFM2.5-VL-3B, med ett 128K-vokabulär byggt för icke-latinska skriftsystem

• Utdatatyper – boxar, punkter, masker och alfamattor kontra endast boxar och text

• Licens — Apache 2.0 för kod skapad av Tencent kontra LFM Open License v1.0

• Hastighet – opublicerad jämfört med 228 tok/s på en M5 Max, 116 tok/s på en Ryzen AI Max+ 395, 20 tok/s på en Galaxy S26 Ultra

Kapacitetsgapet som faktiskt avgör det

LFM2.5-VL-3B kan berätta var en person finns i en bild. WeVisOne-VL-4B kan berätta var en person finns, returnera en binär mask för den instansen och returnera en kontinuerlig alfamatte med mjuka kanter – hår, päls, genomskinligt tyg, rörelseoskärpa – i full upplösning. Det är en kategorisk skillnad, inte en kvalitetsskillnad. Om din produkt behöver kompositera ett motiv mot en ny bakgrund, klippa ut ett produktfoto eller driva bakgrundsersättningen i ett videosamtal har LFM2.5-VL-3B inget att erbjuda dig, och ingen mängd prompt engineering ändrar på det.

Kör jämförelsen åt andra hållet och samma sak händer. Om din produkt behöver hitta en knapp på en telefonskärm på 40 millisekunder är WeVisOne-VL-4B helt fel form: det är en modell på 4,83B utan publicerad latenssiffra, utan kvantiserade edge-byggen och med en avkodare som antar en bild per tur. Liquid levererar GGUF-, MLX-, ONNX- och native-byggen, plus ett 32K-kontext och benchmarks för verktygsanrop. Tencent levererar ett forskningsinferenspaket och vLLM/SGLang-serving.

Avvisande är den underskattade kolumnen

En förmåga i Tencent-tabellen förtjänar uppmärksamhet även om du aldrig sysslar med matting. På WeRef-Bench avvisar WeVisOne-VL-4B korrekt 96,4 % av frågorna om objekt som inte finns i bilden, jämfört med 73,0 % för den bästa baslinjen som författarna listar; på PR-Bench är avvisningsfrekvensen 52,6 % jämfört med 10,8 % för Qwen3-VL-4B. Modellen returnerar None i stället för att hitta på en box. En detektor som hallucinerar är sämre än ingen detektor, eftersom felet är tyst och nedströmskod litar på det.

LFM2.5-VL-3B:s dokumentation redovisar ingen avvisningssiffra, så det finns inget att jämföra med – vilket i sig är poängen. Frånvaro av bevis är inte ett misslyckande, men om du bygger en agent som avgör om den ska klicka på något, är förekomsten av en uppmätt avvisningsfrekvens ett genuint skäl att titta på Tencent-modellen först.

Licensiering är den tysta särskiljaren

Det är här de två skiljer sig på ett sätt som spelar roll för alla som levererar kommersiellt. Vikterna för WeVisOne-VL-4B är Apache 2.0 för kod som Tencent har skrivit, medan tredjepartskomponenter behåller sina egna villkor. LFM2.5-VL-3B levereras under LFM Open License v1.0, som är gratis för kommersiell användning under en intäktsgräns och kräver ett kommersiellt avtal över den. Om du är ett litet team är skillnaden akademisk. Om du inte är det är det ena en juridisk granskning och det andra en rad i en beroendefil.

Ingen av licenserna ger dig en hostad tjänst. WeVisOne-VL-4B har inget API överhuvudtaget; LFM2.5-VL-3B är en viktrelease, och all hostning hos tredje part är en separat överenskommelse. Att säga det rakt ut är viktigare än det brukade vara, eftersom en modell utan slutpunkt är ett åtagande att äga inferensstacken.

Var OrcaRouter passar in, och var det inte passar

Ingen av dessa modeller finns i OrcaRouters katalog i dag, så inget här är en väg till att anropa dem. Det plattformen däremot erbjuder är beslutet runt omkring. De flesta team som utvärderar en 3B edge-VLM ersätter inte en modell med en annan – de lägger till en andra vid sidan av den generalistmodell som redan är i produktion, och den operativa kostnaden för ett andra leverantörsavtal, en andra nyckel och ett andra felmod brukar ta död på experimentet innan modellen hinner göra det.

Dirigera båda avsikterna genom en enda slutpunkt, med fler än 200 modeller bakom en enda nyckel till 0 % påslag över leverantörens listpris, innebär att perceptionsmodellen kan vara ett routingbeslut snarare än ett integrationsprojekt. Om edge-modellen inte är tillgänglig skickar automatisk failover begäran någon annanstans i stället för att returnera en 503. Det är den delen OrcaRouter faktiskt löser här; vikterna och GPU:n är fortfarande dina.

Vilken ska man välja?

Välj LFM2.5-VL-3B om jobbet är latensbegränsat och textbaserat: skärmförståelse, UI-agenter, dokument-OCR med layout, översättning på enheten, verktygsanrop. Den är snabbare än nästan allt i sin storlek, den ryms inom en mobiltelefons minnesbudget, och Liquid har publicerat tillräckligt många siffror för att du ska kunna rimlighetskontrollera påståendena mot din egen arbetsbelastning.

Välj WeVisOne-VL-4B om jobbet slutar i pixlar. Segmentering, matting, tät detektion av små objekt, eller vilken pipeline som helst där "modellen sa nej" måste vara ett tillförlitligt svar. Acceptera att du är en tidig användare: ingen oberoende benchmarkkörning finns, ingen hostad endpoint finns, finjusteringskoden finns fortfarande på att-göra-listan, och artikeln är två dagar gammal.

Det enda man inte ska göra är att välja mellan dem utifrån ett enda benchmarkresultat. Ingen har mätt dem mot varandra på samma data.