LFM3-Omni-2B vs MiniCPM-V 4.7 1B: Kiedy mniejszy model czyta lepiej

Na papierze to nie jest wyrównana walka. LFM3-Omni-2B ma 2,17 miliarda parametrów; MiniCPM-V 4.7 1B jest reklamowany jako model 1B. Większy model powinien wygrywać w benchmarkach wizyjnych. Tak się nie dzieje. MiniCPM uzyskuje 86,1 w OCRBench wobec 80,6, 69,5 w MMStar wobec 55,67, 56,9 w MMMU wobec 42,44 i 74,3 w MathVista wobec 62,5. Każdy benchmark wizyjny wspólny dla obu kart sprzyja modelowi z mniejszą nazwą, zwykle z dużą przewagą, a MiniCPM ma także osiem razy większe okno kontekstu. Fuzja kosztuje więcej za wywołanie niż skierowanie do pojedynczego modelu. Jest rozliczana według cennika dostawcy bez doliczanej marży.

Wyjaśniają to trzy rzeczy i żadna z nich nie jest wadą któregoś z modeli. MiniCPM-V 4.7 1B to specjalista, który cały swój budżet parametrów przeznaczył na widzenie. LFM3-Omni-2B to generalista, który swój budżet przeznaczył na widzenie, słyszenie i mówienie. A najważniejsza liczba MiniCPM — 86,1 w OCRBench — została zmierzona przy ustawieniu 4× tokenów wizualnych, które wymienia moc obliczeniową na szczegółowość w sposób, na jaki limit 2 048 tokenów na obraz nie pozwala. Zrozumienie tego kompromisu to cała decyzja.

Dlaczego mniejszy model czyta się lepiej

MiniCPM-V 4.7 1B opiera się na jednej idei: kompresować tokeny wizualne na wczesnym etapie i pozwolić użytkownikowi wybrać siłę tej kompresji. Model stosuje 4× lub 16× kompresję tokenów wewnątrz enkodera wizyjnego, zanim model językowy cokolwiek zobaczy. Przy 16× jest tani i szybki, dzięki czemu nadaje się do generowania podpisów i opisywania scen. Przy 4× zachowuje czterokrotnie więcej tokenów, czego wymagają OCR dokumentów i odczyt gęstych wykresów. Kluczowe wyniki OpenBMB podawane są dla ustawienia 4×.

LFM3-Omni-2B przyjmuje przeciwne podejście. Przetwarza obrazy w natywnej rozdzielczości, ale ogranicza budżet wizualny do 2048 tokenów na obraz, a ten limit jest współdzielony z enkoderem audio, ścieżką wideo i dekoderem mowy w gęstej sieci o 2,17B parametrów. Pułap 2048 tokenów to rozsądny wybór dla modelu, który musi zmieścić się w telefonie wraz z trzema innymi modalnościami. To twardy limit ilości szczegółów strony, jakie mogą dotrzeć do modelu językowego, a DocVQA 92,47 sugeruje, że model wyciska z niego wiele — ale OCRBench 80,6 mówi, że to za mało, by pokonać specjalistę, który może zużyć 4× więcej tokenów na tej samej stronie.

Istnieje drugi, cichszy czynnik. Okno kontekstu MiniCPM wynosi 262 144 tokeny. LFM3-Omni-2B — 32 768. W przypadku pojedynczego zrzutu ekranu żaden z nich nie ma znaczenia. W przypadku 40-stronicowego pliku PDF, długiego wideo lub wieloturowej rozmowy o dokumencie różnica nie jest wierszem w benchmarku — chodzi o to, czy zadanie jest w ogóle wykonalne.

Specyfikacja, bez marketingowego zaokrąglania

Jeden numer wymaga poprawienia przed jakimkolwiek porównaniem. MiniCPM-V 4.7 1B jest nazywany modelem 1B, a liczba jego parametrów w części gęstej wynosi około 1,3 do 1,55 miliarda, w zależności od tego, jak liczyć wieżę wizyjną. Pasek boczny Hugging Face zaokrągla ją do „2B params”, przez co model 1B wygląda w katalogu jak model 2B. Rozmiar pliku jest uczciwym wyznacznikiem: około 3,1 GB w BF16, w porównaniu z 4,3 GB dla LFM3-Omni-2B.

• Parametry — 2,17 mld gęstych parametrów dla LFM3-Omni-2B w porównaniu z około 1,3 do 1,55 mld gęstych parametrów dla MiniCPM-V 4.7 1B.

• Dane wejściowe — tekst, obraz, wideo z dźwiękiem, dźwięk 16 kHz vs tekst, obraz, wiele obrazów i wideo.

• Dane wyjściowe — tekst i mowa 24 kHz kontra sam tekst.

• Kontekst — 32,768 tokenów vs 262,144 tokenów.

• Tokeny wizualne — ograniczone do 2 048 na obraz w porównaniu z przełączalną kompresją 4× lub 16× wewnątrz enkodera.

• Licencja — LFM Open License v1.0 a Apache-2.0.

• Wydanie — 27 października 2026 vs 12 października 2026.

• Rozmiar — około 4,3 GB BF16 w porównaniu z około 3,1 GB BF16, około 5 GB VRAM do obsługi.

Każdy wiersz wspólny dla obu kart

To porównanie jest nietypowo przejrzyste jak na tabelę międzylaboratoryjną, ponieważ obaj dostawcy raportują te same cztery zbiory danych wizyjnych, a oba są modelami nierozumującymi ocenianymi w trybie instruct. To nadal dwie ewaluacje dostawców i żadna z nich nie została niezależnie odtworzona.

• OCRBench — 80,6 dla LFM3-Omni-2B (806 z 1000) wobec 86,1 dla MiniCPM-V 4.7 1B. Różnica 5,5 punktu w rozpoznawaniu tekstu w dokumentach.

• MMStar — 55,67 wobec 69,5. Różnica 13,8 punktu, największa w zestawie.

• Walidacja MMMU — 42,44 vs 56,9. Różnica 14,5 punktu w rozumowaniu multimodalnym na poziomie uniwersyteckim.

• MathVista mini — 62,50 vs 74,3. 11,8-punktowa luka w matematyce wizualnej.

Cztery wiersze, cztery porażki, różnice od pięciu do piętnastu punktów. Nie ma wiersza, w którym wygrywa model omni, co jest czystszym wynikiem niż ten, który dało porównanie LFM3 z LFM2.5, i trudniejszym do racjonalnego wytłumaczenia. Najbardziej zasadna interpretacja jest taka, że wyspecjalizowany model 1,4B z kontekstem 256K i budżetem 4× tokenów jest po prostu lepszym czytelnikiem niż ogólny model 2,17B z kontekstem 32K i limitem obrazu wynoszącym 2048 tokenów. W tej skali zdolności przeznaczone na jedną modalność biją zdolności rozdzielone między cztery.

Dwa zastrzeżenia trzeba wymienić jednym tchem, ponieważ żadna z kart nie podaje ich z własnej inicjatywy. Wynik 86,1 modelu MiniCPM zmierzono przy 4× kompresji, a ten sam model w domyślnym ustawieniu 16× uzyskałby niższy wynik i działałby taniej — karta nie publikuje tej liczby. Karta modelu OpenBMB nie zawiera natomiast żadnej tabeli benchmarków; dane pojawiają się jako tekst i obrazy wykresów na stronie produktu, co jest słabszą formą publikacji niż tabela z uwagą metodyczną. Oba zestawy liczb to twierdzenia dostawcy. Kierunek tej różnicy jest wystarczająco spójny, że prawdopodobnie przetrwa niezależne testy; dokładna wielkość prawdopodobnie nie.

Kontekst to wiersz, który decyduje o rzeczywistych obciążeniach.

Kontekst 32K jest hojny dla pojedynczego obrazu, a ciasny dla dokumentu. Przy około 2048 tokenach wizualnych na obraz LFM3-Omni-2B może pomieścić w swoim oknie około tuzina pełnych obrazów, zanim historia rozmowy zacznie konkurować o miejsce. 262 144 tokeny w MiniCPM-V 4.7 1B to nie skromna poprawa; to inna klasa obciążenia. Długie pliki PDF, wielostronicowe formularze, godzinne podsumowania wideo i pętle agenta, które utrzymują zrzuty ekranu w kontekście, są wykonalne przy 256K, a wszystkie ograniczone przy 32K.

To najrzadziej omawiana i najbardziej doniosła różnica między tymi dwoma modelami. Tabele benchmarków nagradzają dokładność pojedynczego obrazu; produkcyjne potoki dokumentowe zawodzą na czternastej stronie. Jeśli Twój przypadek użycia obejmuje więcej niż kilka obrazów na rozmowę, okno 32K jest surowszym ograniczeniem niż którakolwiek z czterech powyższych różnic benchmarkowych.

Czego MiniCPM nie potrafi

To nie słyszy. Nie ma ścieżki wejścia audio, wyjścia mowy ani obsługi ścieżki dźwiękowej wideo. Jeśli aplikacja polega na tym, że osoba rozmawia z urządzeniem o tym, co widzi kamera, MiniCPM-V 4.7 1B jest jednym elementem potoku, który wymaga co najmniej dwóch dodatkowych modeli — systemu ASR i systemu TTS — oraz kleju do przenoszenia tekstu między nimi.

LFM3-Omni-2B sprowadza ten potok do jednego checkpointu o rozmiarze 4,3 GB. Jego wyniki w audio są przeciętne na tle wyspecjalizowanych modeli mowy — współczynnik błędów słów w ASR dla angielskiego 6,36, VoiceBench 64,73 — ale występują w tym samym przejściu w przód co ścieżka wizyjna, co oznacza, że model może odpowiedzieć na pytanie głosowe dotyczące obrazu, zanim powstanie jakikolwiek transkrypt. Dla narzędzia terenowego obsługiwanego bez rąk lub kiosku to jest ta funkcja. Dla potoku dokumentowego to zbędny balast w budżecie parametrów.

W OrcaRouterfuzja modeli jest innym sposobem uzyskania obu zachowań: panel, w którym specjalista ds. dokumentów i model omni odpowiadają na ten sam prompt, a odpowiedź jest składana z obu. To możliwość produktu, a nie twierdzenie o tych dwóch checkpointach — żadnego z nich nie ma dziś w naszym katalogu — ale to architektoniczna odpowiedź na zestawienie, w którym każdy model jest wyraźnie lepszy w innej połowie zadania. Fuzja kosztuje więcej za wywołanie niż routing do jednego modelu i opłaca się dokładnie wtedy, gdy błędna odpowiedź kosztuje więcej niż tokeny.

Decyzja

Jeśli zadaniem jest odczytywanie — OCR, faktury, formularze, wykresy, zrzuty ekranu, długie pliki PDF, gęste interfejsy UI — MiniCPM-V 4.7 1B jest lepszym modelem pod każdym publikowanym względem: ma ośmiokrotnie większy kontekst, jest objęty licencją Apache-2.0 zamiast niestandardowej licencji z progiem przychodowym i zajmuje mniej miejsca na dysku. To nie jest wyrównana rywalizacja, a fakt, że nazywa się go modelem 1B, nie powinien tego przesłaniać.

Jeśli zadaniem jest rozmowa z urządzeniem wyposażonym w kamerę i mikrofon, LFM3-Omni-2B jest jedynym z dwóch, który może w niej uczestniczyć. Czyta słabiej, ma mniejszy kontekst i jest udostępniany na surowszych warunkach, ale nic z tego nie ma znaczenia, jeśli alternatywa wymaga trzech modeli i potoku.

Jest jeszcze trzeci przypadek wart nazwania: produkt, który potrzebuje obu, gdzie ścieżka dokumentów i ścieżka głosu są osobnymi funkcjami. Wtedy właściwą architekturą nie jest jeden model, lecz dwa, kierowane według typu żądania — reader do dokumentów, model omni do głosu — a jedyne pytanie brzmi, czy chcesz uruchamiać oba, czy pozwolić, by decydował pojedynczy endpoint. To pytanie, do którego nieustannie dochodzi ta seria porównań, i jest to właściwe pytanie. Modele są wystarczająco bliskie pod względem rozmiaru, że uruchamianie obu jest realną opcją; są wystarczająco odległe pod względem możliwości, że uruchamianie tylko jednego jest kompromisem, niezależnie od tego, który wybierzesz.

To, co zmieniłoby werdykt, to niezależna ocena któregokolwiek z modeli, a konkretnie taka, która testuje MiniCPM przy domyślnej kompresji 16×, a nie przy ustawieniu 4× stosowanym w jego sztandarowych wynikach. Ta jedna liczba mogłaby zniwelować większość różnicy — albo ją powiększyć. Dopóki ktoś jej nie opublikuje, tabele dostawców są tym, co mamy, i wskazują jeden kierunek.