LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Nie wybierasz jednego — podłączasz go

Wyszukiwanie, które sprowadza tu ludzi, to porównanie, ale szczera odpowiedź brzmi: LFM2.5-VL-3B-DSpark i LFM2.5-VL-3B nie są dwiema rzeczami, między którymi można wybierać. Drugi to model wizyjno-językowy o 3,1 mld parametrów, który można pobrać i uruchomić jako usługę. Pierwszy to model szkicujący o 279,5 mln parametrów, który istnieje tylko po to, by stać przed drugim i przyspieszać jego dekodowanie. Wyciągnij model szkicujący ze stosu, a nie wygeneruje on niczego; nie można go benchmarkować samodzielnie, ponieważ „samodzielnie” nie jest konfiguracją, którą obsługuje. Prawdziwe porównanie to LFM2.5-VL-3B działający samodzielnie kontra ten sam model działający z dołączonym modelem szkicującym.

Czytaj to w ten sposób, a decyzja sprowadza się do jednego pytania: czy dodatkowa pamięć i dodatkowa złożoność wykonania dają ci na tyle duży zysk w zakresie opóźnień, by miał on znaczenie dla twojego obciążenia? Własne liczby Liquid AI mówią „tak” w przypadku zadań o dużym udziale dekodowania i wyraźnie mówią „nie”, gdy dominuje prefill. Żadna z tych stron nie została odtworzona poza firmą.

Dwa punkty kontrolne, obok siebie

To, co je różni, to cała historia, więc warto postawić oba repozytoria obok siebie, zanim zacznie się spór o szybkość.

• Rola — LFM2.5-VL-3B generuje tekst i odpowiada na pytania dotyczące obrazów; LFM2.5-VL-3B-DSpark proponuje tokeny do zweryfikowania przez niego i sam nie generuje niczego użytecznego

• Parametry — 3,1 mld dla modelu docelowego, 279,5 mln w BF16 dla modelu szkicującego, co według Liquid oznacza wzrost liczby wdrożonych parametrów o 8,9%

• Architektura — celem jest model hybrydowy zbudowany na szkielecie LFM2.5-2.6B z enkoderem wizyjnym SigLIP2 NaFlex; drafter to 4 pełne warstwy uwagi o rozmiarze ukrytym 2048 z uwagą z grupowaniem zapytań oraz głową Markowa i głową pewności

• Okno kontekstowe — 32 768 tokenów dla modelu docelowego; model szkicujący nie ma własnego kontekstu i dziedziczy kontekst modelu docelowego

• Koder wizyjny — SigLIP2 NaFlex 400M po stronie modelu docelowego; model szkicujący nie ma go wcale i nigdy nie widzi obrazu bezpośrednio

• Słownik — 128 000, a embedding i głowa LM modelu szkicującego są powiązane z modelem docelowym, a nie powielone, dlatego koszt pamięciowy jest mniejszy, niż sugerowałoby 279,5 mln parametrów

• Licencja — oba są udostępniane na licencji LFM1.0 firmy Liquid, która na Hugging Face jest oznaczona jako „inna”, a nie jako licencja OSI, więc przed wdrożeniem komercyjnym należy zapoznać się z warunkami

• Formaty — model docelowy jest dostarczany jako kwantyzacje safetensors, GGUF, ONNX i MLX; model szkicujący jest dostarczany jako safetensors oraz pojedynczy GGUF F16 o rozmiarze około 567 MB

Jedna pozycja na tej liście zasługuje na podkreślenie, ponieważ stanowi mechaniczny powód, dla którego to zestawienie w ogóle działa: model szkicujący nie jest małym modelem wizyjnym. Nie ma kodera wizji i nigdy nie dotyka obrazu. Zanim tokeny dotrą do warstw ukrytych, na podstawie których szkicuje, fragment obrazu i token tekstowy są już tylko tensorami, więc modalność jest niewidoczna dla obliczeń szkicujących. To właśnie pozwoliło Liquid przenieść technikę opracowaną dla modeli tekstowych na VLM bez przeprojektowywania jej.

Co zmienia projektant, a co pozostawia bez zmian

Model docelowy się nie zmienia. To nie marketing — to własność poprawności dekodowania spekulatywnego. W przypadku dekodowania zachłannego każdy token szkicu jest weryfikowany przez model docelowy, więc wynik jest dokładnie tym, co model docelowy wytworzyłby samodzielnie. Przy dopasowanych ustawieniach próbkowania przy niezerowej temperaturze rozkład wyjściowy odpowiada rozkładowi modelu docelowego. Model szkicujący wymienia pamięć na czas i nie ingeruje w nic innego.

Co oznacza, że każda liczba jakościowa, jaką można znaleźć dla LFM2.5-VL-3B, obowiązuje bez zmian w konfiguracji sparowanej. W ocenie samego Liquid model docelowy uzyskuje 80,7 w ScreenSpot-v2, 61,5 w BLINK, 58,3 w MuirBench, 73,1 w MME, 63,3 w MMStar, 81,3 w ChartQA i 88,7 w POPE — wszystkie raportowane przez dostawcę, żadna nie została niezależnie odtworzona i wszystkie są równie prawdziwe niezależnie od tego, czy model szkicujący jest podłączony. Nie ma tu żadnego kompromisu między jakością a szybkością do rozważenia, a każda strona porównawcza, która taki przedstawia, błędnie odczytała ten model.

To, co się zmienia, to koszt tokenu w czasie zegarowym. Liquid mierzy przyspieszenia dekodowania od 2,04× do 2,66× na pojedynczym H100 w BF16 za pośrednictwem SGLang przy rozmiarze bloku 9, od 2,30× do 3,13× na Apple M5 Max za pośrednictwem MLX-VLM przy rozmiarze bloku 8 oraz od 1,57× do 2,14× na M3 Ultra za pośrednictwem llama.cpp. W ujęciu end-to-end te same przebiegi osiągają odpowiednio 1,64×–2,27×, 1,56×–2,62× i 1,30×–1,77×. Te pary to cały argument: dekodowanie poprawia się mniej więcej dwa razy bardziej niż end-to-end, a różnica to ta część obciążenia, której drafter nie może dotknąć.

Problem prefill, przedstawiony przez dostawcę

Najbardziej użytecznym zdaniem w samym ogłoszeniu Liquid jest to, które sprzeciwia się nieograniczonej interpretacji jego nagłówka. Wnioskowanie wizyjno-językowe ponosi koszt prefill, którego nie ponosi wnioskowanie tekstowe: obraz przechodzi przez enkoder wizyjny, a następnie szkielet językowy przetwarza setki tokenów wizualnych emitowanych przez ten enkoder. Na urządzeniu brzegowym ten prefill stanowi dużą część opóźnienia end-to-end. Dekodowanie spekulacyjne przyspiesza tylko decode — kodowanie wizyjne i prefill pozostają bez zmian. Tam, gdzie dominuje prefill, 3× przyspieszenie dekodowania przekłada się na znacznie mniejszą korzyść end-to-end.

To prawo Amdahla zastosowane przez dostawcę do jego własnego produktu i powinno wpływać na to, kto czyta tę stronę. Długa transkrypcja pojedynczej zeskanowanej strony, podpis, wieloturażowa rozmowa przenosząca jeden obraz dalej — zdominowane przez dekodowanie, i tu drafter uzasadnia swoje 279,5 mln parametrów. Krótkie pytanie o duży obraz w wysokiej rozdzielczości — zdominowane przez prefill — i tu już nie. Umieść ten sam model docelowy na serwerze przy wysokiej współbieżności, a obraz znów się zmieni: Liquid mierzy granicę przepustowości i interaktywności, a nie pojedynczą liczbę, i podaje, że DSpark zachowuje przewagę na każdym testowanym poziomie współbieżności, choć różnica maleje wraz ze wzrostem współbieżności.

Dwie mniejsze uwagi dotyczące zakresu z tego samego źródła. Wszystkie pomiary wykorzystują przetwarzanie 16-bitowe zarówno dla kodera wizji, jak i szkieletu językowego, a akceleracja modeli skwantyzowanych wykracza poza zakres tego wydania. Jeśli Twój plan zakładał połączenie 4-bitowego eksportu docelowego z modelem draftującym, ponieważ cała zaleta VLM 3B polega na zmieszczeniu się w kilku gigabajtach, to nie taką kombinację zmierzono.

Ile tak naprawdę kosztuje cię dołączenie tego

Pamięć to widoczny koszt, a karta go kwantyfikuje: 8,9% więcej parametrów we wdrożonym stosie. Złożoność wykonania jest tym niewidocznym. SGLang wymaga wersji v0.5.19 lub nowszej oraz linii uruchomieniowej zawierającej --speculative-algorithm DSPARK, ścieżkę modelu wersji roboczej i rozmiar bloku; przykład z samej karty wyłącza także pamięć podręczną radix i przypina statyczny ułamek pamięci, a to decyzje dotyczące serwowania, które teraz musisz przemyśleć. MLX-VLM wymaga wersji v0.7.2 lub nowszej i przyjmuje model wersji roboczej przez --draft-model, ale dekodowanie DSpark używa tam obecnie próbkowania zachłannego, więc temperaturę trzeba wymusić na 0 — realne ograniczenie, jeśli Twoja aplikacja polega na różnorodności próbkowania. llama.cpp działa poprzez model wersji roboczej GGUF w parze z modelem docelowym GGUF, a nie z oryginalnym checkpointem safetensors.

Jest jeszcze jeden koszt, który ujawnia się w produkcji, a nie w benchmarku: model szkicujący i model docelowy muszą być wdrażane razem. Rozbieżność wersji między nimi to tryb awarii, który nie występuje we wdrożeniu z jednym modelem, a niezależne wdrażanie któregokolwiek z nich jest teraz problemem dwóch artefaktów.

To samodzielnie hostowana para. OrcaRouter nie kieruje ruchu do LFM2.5-VL-3B ani jego draftera — oba pobierasz i hostujesz samodzielnie — więc kwestia routingu dotyczy wszystkiego, do czego mały model przekazuje obsługę. Większość wdrożeń, które łączą brzegowy VLM 3B z drafterem, wciąż ma zapytania, na które mały model nie powinien odpowiadać, a wysyłanie ich do pojedynczego punktu końcowego obejmującego ponad 200 modeli w cenie katalogowej każdego dostawcy, z automatycznym przełączaniem awaryjnym, jeśli dostawca zacznie działać gorzej, to jedna integracja zamiast jednej na dostawcę. Oznacza to również, że gdy dostawca obniży cenę, Twoja stawka odzwierciedla to tego samego dnia, a nie dopiero przy kolejnym odnowieniu umowy.

Który pobrać?

Jeśli Twoje obciążenie jest zdominowane przez dekodowanie, a Twój sprzęt należy do trzech przetestowanych przez Liquid, dołącz model szkicujący — wada jest ograniczona, ponieważ dane wyjściowe dowodliwie pochodzą z modelu docelowego, a koszt pamięci wynosi poniżej jednej dziesiątej modelu. Jeśli Twoje opóźnienie jest zdominowane przez prefill, używasz skwantyzowanego modelu docelowego albo polegasz na próbkowaniu innym niż zachłanne w środowisku uruchomieniowym, które nie zniosło tego ograniczenia, uruchom sam LFM2.5-VL-3B. Jest szybki sam w sobie: 228 tokenów na sekundę na M5 Max, 116 na AMD Ryzen AI Max+ 395 i 20 na Galaxy S26 Ultra, wszystkie dane producenta, w około 3 GB pamięci.

Nikt nie może jeszcze powiedzieć, czy liczby Liquid utrzymają się na twoim sprzęcie. W chwili pisania drafter miał 37 pobrań na Hugging Face i brak niezależnego odtworzenia jakiejkolwiek liczby z jego tabel. Rozwiązanie inżynierskie jest solidne, a argument o poprawności to dowód, a nie twierdzenie, ale wielkość jest pomiarem — a pomiary z jednego laboratorium na jednym zestawie maszyn to dokładnie taki rodzaj liczb, które warto zweryfikować samodzielnie, zanim umieścisz je w planie przepustowości.

OrcaRouter zapewnia dostęp do ponad 200 modeli przez jeden klucz, a cena listowa każdego dostawcy jest przekazywana bezpośrednio przy 0% marży i automatycznym przełączaniu awaryjnym między dostawcami. cena listowa dostawcy przekazywana bezpośrednio przy 0% marży To zestawienie na tej stronie i tak działa w trybie self-hosted — router obsługuje wszystko, co mały model przekazuje dalej, a to oznacza, że obniżka ceny u dostawcy pojawi się w Twojej stawce tego samego dnia.