LFM3-VL-2B vs WeVisOne-VL-4B: Co tak naprawdę daje 2,5× więcej parametrów

Własna tabela wyników Tencenta przemawia przeciwko oczywistemu zakupowi. WeVisOne-VL-4B, większy z dwóch modeli percepcji opublikowanych przez zespół WeChat Vision 22 października 2026 r., wypada gorzej w matowaniu alfa z monitem ramki niż jego własny model siostrzany 2B: 7,3 średniej różnicy bezwzględnej na P3M-500-NP wobec 6,6 u modelu 2B, gdzie niższa wartość jest lepsza. Modelem, z którym większość kupujących będzie go faktycznie porównywać, nie jest jednak jego model siostrzany, lecz LFM3-VL-2B — model wizyjny Liquid AI o 1,92B do pracy na urządzeniu, którego wagi ukazały się 19 października i który został zapowiedziany wraz z resztą rodziny LFM3 27 października.

Postaw te dwa obok siebie, a interesujące pytanie nie brzmi, który z nich jest mądrzejszy. Brzmi ono: co daje ci dwa i pół razy więcej parametrów i ile cię to kosztuje. Krótka odpowiedź, z tabel samych dostawców: dają gęstą detekcję, dokładność wskazywania i znacznie lepszy odsetek odmów odpowiedzi, gdy obiektu nie ma. Nie dają generalisty, nie dają wideo i nie dają modelu, który można umieścić w telefonie. Wszystko poniżej pochodzi z dwóch opublikowanych tabel z pozostawionymi widocznymi szwami — żaden niezależny zestaw testowy nie odtworzył wyników któregokolwiek z modeli.

Czym każde z nich tak naprawdę jest

LFM3-VL-2B ma 1,92 mld gęstych parametrów: szkielet językowy o 1,73 mld parametrów, własny enkoder wizyjny o 164 mln parametrów i projektor o 25 mln parametrów. Szkielet to trójhybrydowy stos Liquid — 24 warstwy podzielone na 13 bramkowanych krótkich konwolucji, 5 warstw uwagi z przesuwanym oknem 256 tokenów i 6 globalnych warstw uwagi. Przyjmuje tekst, obrazy i wideo w natywnej rozdzielczości, próbkując wideo z szybkością 2 klatek na sekundę, utrzymuje kontekst 128 tys. tokenów, obsługuje 16 języków i ma opcjonalny tryb myślenia, który przed odpowiedzią generuje przebieg rozumowania. Jego wynikiem jest proza.

WeVisOne-VL-4B jest zbudowany na szkielecie Qwen3-VL i nosi nazwę 4B, choć metadane Hugging Face zaokrąglają ją do 5B, a materiały stron trzecich podają faktyczną liczbę parametrów blisko 4,83B. Nie odpowiada tak bardzo prozą, ile emituje geometrię: ramki i punkty jako znormalizowane tokeny współrzędnych od 0 do 1000, znacznik OBJ (identyfikator tokenu 152678) po każdej przewidywanej ramce oraz dosłowny ciąg None, gdy cel jest nieobecny. Maski i maty alfa wymagają drugiego artefaktu, mask_decoder.pt, dekodera pikseli z 9,6 mln parametrów, który pobiera stan ukryty każdego tokenu OBJ i przewidywaną ramkę i zwraca alfę w pełnej rozdzielczości przy kroku 1. Obsługuje tylko jedną turę i wyłącznie obrazy oraz generuje ustrukturyzowane dane wyjściowe bezpośrednio, bez łańcucha myśli.

Kontrast w jednym przebiegu:

• Rozmiar — LFM3-VL-2B 1,92B gęsty vs WeVisOne-VL-4B około 4,83B, plus dekoder 9,6M obowiązkowy dla masek

• Dane wejściowe — tekst, obraz i wideo przy 2 fps vs tekst i pojedynczy obraz

• Wyjście — proza i przebieg rozumowania vs. tokeny współrzędnych, prostokąty, maski, matte lub jawne None

• Okno kontekstu — 128 tys. tokenów w porównaniu z brakiem opublikowanego na karcie limitu wnioskowania; w artykule opisano trening przy 4096 i 8192 tokenach

• Pokrycie językowe — podano 16 języków vs nie podano żadnego

• Licencja — LFM Open License v1.0, bezpłatna do użytku komercyjnego przy rocznych przychodach poniżej 10 mln USD w porównaniu z Apache 2.0 dla kodu autorstwa Tencent

• Środowisko wykonawcze — GGUF/llama.cpp, MLX 4-bit, ONNX i BF16 vs BF16 przez Transformers, vLLM lub SGLang

Modernizacja przebiega nierówno, a artykuł pokazuje, gdzie.

WeVisOne-VL-2B i WeVisOne-VL-4B to ta sama architektura w dwóch skalach, trenowane na tych samych około 100 mln obrazów według tego samego trzyetapowego programu nauczania i oceniane na tej samej tabeli. Dzięki temu porównanie bliźniaczych modeli jest najczystszym dostępnym dowodem na to, co robią dodatkowe parametry — i nie zmierza ono w jednym kierunku.

Tam, gdzie 4B wyraźnie wygrywa, według danych Tencent:

• Detekcja Dense200 — 71,3 średniego F1 w porównaniu z 61,4, największy pojedynczy przyrost

• LVIS — 55,3 vs 53,3, skromna poprawa o 2 punkty

• RefCOCOg — detekcja odniesień — 81,8 w teście vs 78,2

• RefCOCO — segmentacja na podstawie odniesień — 84,5 cIoU na testA vs 82,9

• ReasonSeg — 71,2 cIoU na zbiorze walidacyjnym w porównaniu z 60,9, skok o 10 punktów w segmentacji z rozumowaniem

• PointBench – wskazywanie – 71,9 vs 62,9

• Matting referringowy WeRefMat — 9,8 średniej różnicy bezwzględnej na podziale referring w porównaniu z 15,8, co oznacza 38% redukcji błędu

Tam, gdzie nie:

• Matowanie pudełka P3M-500-NP — 7,3 w porównaniu z 6,6 dla 2B, gorzej

• Matowanie pudełka PPM-100 — 6,1 vs 5,3, gorzej

• Ref-ZOM cIoU — 72,2 w teście vs 73,4, 2B znów na czele

Wzorzec jest czytelny, nawet jeśli przyczyna nie została opublikowana: 4B wysuwa się na prowadzenie w zadaniach trudnych i uwarunkowanych językowo — segmentacji na podstawie odniesienia, segmentacji wymagającej rozumowania, mattingu na podstawie odniesienia w rzeczywistych scenach — a nie daje nic w zamian w łatwiejszych zestawach mattingu z podpowiedzią ramkową, gdzie oba modele są już blisko górnej granicy, a 9.6M dekoder może wykonywać większość pracy. Dwa z trzech benchmarków mattingu z podpowiedzią ramkową zmierzają w złym kierunku. Jeśli alpha matting na podanej ramce to Twoje jedyne zadanie, 4B nie jest ulepszeniem; to droższy sposób uzyskania tej samej odpowiedzi, tylko nieco gorszej.

Brakujące obiekty: lepiej, ale wciąż nierozwiązane

Najbardziej użyteczna kolumna w artykule to ta, której prawie żadna karta modelu wizyjnego nie publikuje. RefCOCOg-Rej to wariant, w którym każde wyrażenie jest zmodyfikowane tak, aby nie istniał żaden pasujący obiekt na obrazie. Model, który nie potrafi powiedzieć „nie”, wymyśli ramkę, a każde późniejsze przycięcie, zliczenie i maska dziedziczą to zmyślenie.

WeVisOne-VL-4B poprawnie odrzuca w 67,4% przypadków, w porównaniu z 50,2% dla modelu 2B. To realna i duża poprawa — wzrost o 17 punktów, który zmienia tryb awarii potoku z rzutu monetą na dwa na trzy. Oznacza to również, że 4B nadal zwraca pewnie wyznaczoną ramkę dla około jednego na trzy zapytania o nieobecny obiekt. W wewnętrznym benchmarku Tencent WeRef-Bench odsetek odrzuceń wynosi 96,4%, ale ten benchmark to 2880 zapytań w języku angielskim i chińskim, które laboratorium zbudowało samodzielnie, więc mierzy on bardziej przyjazny rozkład niż publiczny. Uczciwe podsumowanie jest takie, że model ma użyteczne zachowanie abstynencyjne i nie rozwiązał problemu; jeśli Twoja aplikacja nie może tolerować zhalucinowanego regionu, potrzebny jest próg lub dodatkowa kontrola, niezależnie od tego, który model wybierzesz.

Liczba, która wygląda na porównywalną, ale nią nie jest.

Kuszące jest zestawienie wyniku 90,5 RefCOCO-avg modelu LFM3-VL-2B z wynikiem 81,8 RefCOCOg modelu WeVisOne-VL-4B i ogłoszenie 8,7-punktowego zwycięstwa mniejszego modelu. Nie należy tego robić. To są różne podziały i różne miary: Liquid podaje średnią w rodzinie RefCOCO, Tencent podaje F1 na teście RefCOCOg dla detekcji referencyjnej. Odjęcie ich daje liczbę bez odniesienia.

Ta sama pułapka czyha w OCR. LFM3-VL-2B uzyskuje 86.3 w OCRBench v1, złożonym wskaźniku rozpoznawania tekstu, wykrywania i rozumowania; WeVisOne-VL-4B uzyskuje średnią F1 52.0 w TotalText, benchmarku lokalizacji tekstu w scenie. Jeden to szeroki egzamin, drugi to zadanie gęstej predykcji. To nie ta sama umiejętność mierzona dwa razy.

Zatem obie tabele dostawców nie pokrywają się w zakresie ani jednej porównywalnej liczby. Uczciwie porównać można jedynie funkcje i koszty — dlatego dalsza część tego porównania dotyczy dopasowania, a nie rankingu. Ktokolwiek ogłasza zwycięzcę na podstawie tych dwóch tabel, ten go po prostu wymyśla.

Pamięć to prawdziwa cena

Żaden z modeli nie ma opublikowanej ceny za token na dzień 28 października 2026 r. Karta Liquid zawiera linki do API i dostępu do Playground przez jej konsolę, ale dla LFM3-VL-2B nie opublikowano cennika; zewnętrzne serwisy śledzące, które podają stawki modeli tekstowych Liquid, nie obejmują modelu wizyjnego. Tencent nie ma w ogóle hostowanego endpointu. Porównanie jest więc porównaniem samodzielnego hostowania, a rachunek jest wyrażany w pamięci.

• LFM3-VL-2B — około 3,84 GB w BF16, wyliczone arytmetycznie na podstawie liczby parametrów, wraz z opublikowanymi obok niego 4-bitowymi wersjami MLX, GGUF i ONNX

• WeVisOne-VL-4B — około 9,7 GB w BF16 według szacunków stron trzecich, około 19 GB w F32, plus wymagany plik mask_decoder.pt

Ta różnica 2,5× to nie tylko większy GPU. To inna klasa urządzenia. Karta LFM3-VL-2B wyraźnie mówi, że model jest stworzony do pracy na urządzeniu — pytań o wideo, dokumenty, wykresy i ekrany aplikacji, wyszukiwania obiektów, rozumowania przestrzennego dla robotów — a wersje MLX 4-bit i GGUF pozwalają dotrzymać tej obietnicy: laptop, telefon, podwozie robota. Udokumentowane ścieżki WeVisOne-VL-4B to Transformers, vLLM i SGLang na BF16, bez oficjalnej wersji skwantyzowanej i bez środowiska uruchomieniowego na urządzeniu. Ten model potrzebuje serwerowego GPU.

Warto sprawdzić wsparcie frameworka na własnej ścieżce, a nie w tabeli. Wideo przy 2 fps to możliwość modelu w LFM3-VL-2B, ale to, czy dane środowisko uruchomieniowe akceptuje siatkę wideo, to osobna kwestia, a karta modelu, porty i PR-y upstream nie zawsze były co do tego zgodne. Przetestuj dokładną kombinację, którą zamierzasz wdrożyć.

OrcaRouter nie hostuje żadnego z tych modeli. Zostało to zweryfikowane na podstawie katalogu 28 października 2026 r., a nie założone — ani linia LFM3 firmy Liquid, ani WeVisOne firmy Tencent nie występują na liście modeli — więc niczego tutaj nie należy odczytywać jako drogi do któregokolwiek z nich. To, co katalog modeli OrcaRouter zawiera, to Qwen3-VL-8B, w wariantach instruct i thinking, co jest pragmatyczną opcją, jeśli faktycznym wymaganiem jest hostowany model wizyjny z opublikowaną ceną na dziś, a nie checkpoint hostowany samodzielnie. Jeden klucz daje dostęp do tego wszystkiego w cenie katalogowej dostawcy bez marży, a jeśli prototypujesz z nieudowodnionym modelem o otwartych wagach, uruchamianie go przez router z mechanizmem failover jest lepsze niż podłączanie ścieżki produkcyjnej do checkpointu, który nie przeszedł jeszcze niezależnej oceny.

Który wybrać?

• Wybierz WeVisOne-VL-4B, gdy produktem ma być geometria — maski, maty alfa, gęste ramki ograniczające, zliczenia, wskazywanie — na obrazach statycznych, gdy zapytania są uwarunkowane językowo, a nie oparte na ramkach podpowiedzi, oraz gdy masz wolny GPU.

• Wybierz WeVisOne-VL-2B zamiast 4B, gdy Twoim zadaniem jest matowanie z podpowiedzią w postaci ramki na zwykłych scenach; według opublikowanych liczb mniejszy model radzi sobie w tym lepiej i zużywa mniej niż połowę pamięci

• Wybierz LFM3-VL-2B, gdy dane wejściowe obejmują wideo, gdy dokument jest długi, gdy odpowiedź musi być zdaniem, a nie wielokątem, lub gdy urządzenie nie jest serwerem

• Nie wybieraj żadnego, jeśli w tym tygodniu potrzebujesz hostowanego endpointu z opublikowaną ceną za token — żaden z dostawców go nie oferuje, a żadna ilość benchmarkingu nie zasypie tej luki

• Wybierz oba tylko wtedy, gdy akceptujesz dwa schematy wyjściowe i dwie ścieżki integracji; wspólny przedział parametrów „około od 2B do 5B” maskuje dwa różne produkty

Co by to zmieniło

Trzy rzeczy. Niezależny harness, który uruchamia oba modele na tych samych obrazach z tymi samymi promptami — do tego czasu wszystko powyższe to uważnie odczytana tabela dostawcy, co jest lepsze niż niedbale odczytana tabela dostawcy, ale nie jest dowodem jakości. Kwantyzowana wersja WeVisOne albo środowisko uruchomieniowe na urządzeniu, co przeniosłoby argument o pamięci z rozstrzygającego na możliwy do negocjacji. I opublikowana cena za token od którejkolwiek ze stron, która zastąpiłaby arytmetykę dotyczącą gigabajtów liczbą, względem której ktoś może planować budżet.

Najmniej prawdopodobny z tych trzech jest czynnik, który miałby największe znaczenie dla tego konkretnego zestawienia: obsługa wideo w dekoderze pikseli WeVisOne. Obecnie generalista 2B przyjmuje wideo, a instrument 4B nie może, i żadna liczba parametrów nie naprawi modalności, której nigdy nie trenowano.