LFM2.5-VL-3B-DSpark: Drafter Liquid AI o 279,5 mln parametrów został wydany sześć dni, zanim ktokolwiek go ogłosił

Istnieje wersja tej historii, w której LFM2.5-VL-3B-DSpark jest nowym modelem. Nie jest. To model szkicowy do dekodowania spekulatywnego o 279,5 mln parametrów, który istnieje dokładnie w jednym celu — przyspieszania dekodowania własnego modelu wizyjno-językowego Liquid AI, LFM2.5-VL-3B — i samodzielnie nie potrafi wygenerować użytecznej odpowiedzi. Powód, dla którego mimo wszystko warto o nim czytać, to chronologia: wagi pojawiły się na Hugging Face 18 września 2026 r. bez żadnego ogłoszenia, przeleżały tam sześć dni i dopiero 24 września doczekały się wpisu na blogu dostawcy. Radar wychwycił to repozytorium w tej luce.

Ta luka jest zarazem granicą tego, co można teraz poznać. Wszystko w repozytorium — zestawienie parametrów, rozmiar bloku, integracje z frameworkami, licencja — jest plikiem na dysku, który ty lub ja możemy otworzyć. Każda wartość przyspieszenia jest mierzona przez dostawcę, na podstawie własnego zestawu testów porównawczych Liquid, a nikt spoza firmy nie opublikował reprodukcji. Ten tekst celowo trzyma te dwa stosy osobno.

Co faktycznie zawiera repozytorium

Otwórz kartę modelu, a charakter tego rozwiązania jest jednoznaczny. LFM2.5-VL-3B-DSpark to model roboczy, którego model docelowy jest zapisany w jego metadanych: base_model: LiquidAI/LFM2.5-VL-3B. Nie wskazuje się go na inny model i nie udostępnia się go samodzielnie.

• Łączna liczba parametrów draftu — 279,5 mln, BF16, z czego 193,0 mln to 4-warstwowy stos dekodera, 65,5 mln to głowica Markowa, 21,0 mln to projekcja stanu ukrytego, a 6,4 tys. to normalizacje oraz głowica pewności

• Szkielet — 4 pełne warstwy uwagi, rozmiar ukryty 2 048, rozmiar pośredni 6 144 z SiLU/SwiGLU, uwaga z grupowanymi zapytaniami z 32 głowicami uwagi i 8 głowicami klucz-wartość, wymiar głowicy 64

• Dodatkowe głowy — głowa Markowa o randze 256 oraz głowa pewności, i to właśnie one odróżniają draftowanie DSpark od zwykłego równoległego draftującego

• Rozmiar bloku — 9 podczas trenowania; 8 lub 9 podczas wnioskowania w zależności od sprzętu, a konkretnie 8 na Apple silicon

• Słownictwo — 128 000, powiązane z tekstem docelowym, a nie przenoszone przez wersję roboczą

• Waga w stosie wdrożeniowym — Liquid twierdzi, że model szkicujący zwiększa liczbę parametrów wdrożonych o 8,9%

8,9% to liczba, której warto się trzymać. Argument za tą klasą modeli nigdy nie brzmi „szybsza inferencja jest darmowa”; brzmi „szybsza inferencja kosztuje około jedną dziesiątą pamięci zajmowanej przez model”. Przy 279,5 mln dodatkowych parametrów dodanych do modelu docelowego o 3,1 mld parametrów jest to mniejszy podatek, niż sugerowałby sam rozmiar draftera, ponieważ embedding i głowica LM są powiązane z modelem docelowym, a nie duplikowane.

DSpark to technika DeepSeek, a dopiero potem model Liquid

Nazewnictwo może wprowadzać zamieszanie, więc warto być precyzyjnym. DSpark nie jest wynalazkiem Liquid AI ani rodziną modeli. To framework dekodowania spekulatywnego z odrębnego nurtu badawczego, opisany w artykule z lipca 2026 r. jako dekodowanie spekulatywne z harmonogramowaniem na podstawie pewności i generacją półautoregresyjną. Jego trzy idee to: równoległy backbone, który szkicuje cały blok w jednym przebiegu w przód; lekki moduł sekwencyjny, który przywraca pewną zależność między sąsiednimi tokenami szkicu, aby akceptacja nie załamywała się na końcu bloku; oraz weryfikator, który skraca okno weryfikacji dla danego żądania, gdy pewność samego szkicu sugeruje, że końcówka zostanie odrzucona.

To, co zrobił Liquid, to zastosowanie tego przepisu do modeli wizyjno-językowych i wypuszczenie checkpointu. Karta otwarcie przyznaje, że to przeniesienie jest mniej dramatyczne, niż się wydaje: z punktu widzenia modelu draftującego modalność nie ma znaczenia, ponieważ zanim tokeny dotrą do warstw ukrytych, wycinek obrazu i token tekstowy to po prostu tensory. Dlatego technika opracowana dla modeli tekstowych przenosi się do VLM bez konieczności wymyślania jej od nowa — i dlatego modelu draftującego nie można sprzedawać jako nowej możliwości.

Liquid zdążył już wypuścić tekstowe drafters DSpark — modele towarzyszące 2.6B, 8B-A1B i 1.2B-Instruct ukazały się w sierpniu 2026, a eksporty GGUF pojawiły się 19 sierpnia. Drafter wizyjny to ten sam pomysł rozszerzony na gałąź multimodalną i czwarty lub piąty wpis w linii, a nie debiut.

Liczby przyspieszenia i kto je zmierzył

Wszystkie poniższe liczby pochodzą od samego Liquid, zostały zebrane w infrastrukturze benchmarkowej Liquid i żadna z nich nie ma niezależnego odtworzenia. Traktuj je jako górną granicę deklarowaną przez dostawcę, a nie oczekiwany wynik. Karta oddziela przyspieszenie dekodowania od przyspieszenia end-to-end, co ma większe znaczenie niż sam nagłówek.

• Najlepsze przyspieszenie dekodowania — 3,13× na COCO, zmierzone za pomocą MLX-VLM na Apple M5 Max przy rozmiarze bloku 8, FP16, rozmiarze partii 1, temperaturze 0

• Najlepsze przyspieszenie dekodowania GPU — 2,66× na COCO, SGLang na pojedynczym H100 80GB, BF16, rozmiar bloku 9

• Najlepsze przyspieszenie dekodowania llama.cpp — 2,14× na COCO, Apple M3 Ultra, rozmiar bloku 8

• Zakres dekodowania H100 w sześciu zadaniach wizyjnych — od 2,04× do 2,66×, a w trybie end-to-end od 1,64× do 2,27×

• M5 Max zakres dekodowania — od 2,30× do 3,13×, end-to-end od 1,56× do 2,62×

• Zakres dekodowania M3 Ultra — od 1,57× do 2,14×, całościowo od 1,30× do 1,77×

• Akceptacja wersji roboczej — około 3,2 do 4,5 tokena akceptowanych na jeden przebieg weryfikacji docelowej, we wszystkich trzech stosach

Wzorzec w tych zakresach jest uczciwą częścią. Zyski end-to-end są konsekwentnie mniejszą połową każdej pary, ponieważ model draftujący przyspiesza dekodowanie i nic więcej. Zauważ też, że ten sam model draftujący przy tym samym rozmiarze bloku osiąga 3,13× na jednym stosie, a 1,57× na innym — współczynnik akceptacji jest właściwością modelu draftującego i obciążenia, ale zysk w czasie rzeczywistym jest właściwością sprzętu i narzutu środowiska uruchomieniowego. Twierdzenie „2,66× szybciej” bez dołączonego stosu nie jest twierdzeniem, na podstawie którego można działać.

Dwa punkty dotyczące poprawności z karty zasługują na jasne przedstawienie, ponieważ to właśnie one sprawiają, że drafter jest w ogóle akceptowalny w środowisku produkcyjnym. W przypadku dekodowania zachłannego dekodowanie spekulatywne jest dokładne: model docelowy weryfikuje każdy zaproponowany token, więc tekst jest tym, co model docelowy wygenerowałby samodzielnie. Przy dopasowanych ustawieniach próbkowania w niezerowej temperaturze zachowuje rozkład wyjściowy modelu docelowego. Sformułowanie Liquid — zyskujesz przyspieszenie, a nie inny model — jest trafne na tyle, na ile sięga, a karta uczciwie przyznaje, że podnoszenie temperatury obniża współczynnik akceptacji, a zatem osłabia korzyść w postaci przepustowości.

Co przyznaje własny post Liquid

Wpis na blogu z 24 września jest bardziej przydatny niż karta modelu z jednego powodu: nazywa ten limit. Wnioskowanie wizualno-językowe ponosi koszt prefill, którego nie ponosi wnioskowanie tekstowe — obraz musi przejść przez enkoder wizyjny, a rdzeń językowy musi następnie przetworzyć setki tokenów wizualnych, które ten enkoder generuje. Na urządzeniu ten prefill dominuje nad opóźnieniem end-to-end. Dekodowanie spekulacyjne przyspiesza wyłącznie dekodowanie. Kodowanie wizyjne i prefill pozostają nietknięte. Liquid przywołuje prawo Amdahla przeciwko własnemu produktowi i wskazuje, że tam, gdzie prefill stanowi dużą część czasu zegarowego, duże przyspieszenie dekodowania daje jedynie umiarkowaną poprawę end-to-end.

To rzeczywiste ograniczenie przy podejmowaniu decyzji zakupowej i wyjaśnia, dlaczego czas do pierwszego tokenu nie znajduje się na liście rzeczy, które ten drafter poprawia. Sugeruje to również, że obciążenia, które odnoszą największe korzyści, to te, które generują długie wyniki na podstawie niewielkiego obrazu — podpis, długa transkrypcja OCR, wielotura rozmowa z jednym obrazem przenoszonym dalej — a nie te, które odpowiadają na krótkie pytanie dotyczące dużego obrazu.

Wpis dodaje jeszcze dwa ograniczenia zakresu. Wszystkie wartości liczbowe opierają się na przetwarzaniu 16-bitowym zarówno w enkoderze wizyjnym, jak i w rdzeniu językowym, a przyspieszanie modeli skwantyzowanych jest poza zakresem tego wydania. Biorąc pod uwagę, że cały sens 3B edge VLM polega na działaniu w kilku gigabajtach, „przyspieszenia są mierzone przy FP16” to istotne zastrzeżenie dla każdego, kto planował połączyć go z eksportem 4-bitowym. Liquid zauważa również, że model szkicujący był trenowany w całości na sprzęcie AMD.

Uruchamianie tego.

Wsparcie od pierwszego dnia jest realne i obejmuje trzy środowiska uruchomieniowe, czyli więcej, niż dostaje większość drafterów. SGLang na NVIDIA wymaga wersji v0.5.19 lub nowszej i prowadzi draftera przez --speculative-algorithm DSPARK ze ścieżką draftu i rozmiarem bloku 9. MLX-VLM na Apple silicon wymaga wersji v0.7.2 lub nowszej i wykrywa draftera, gdy zostanie on przekazany z --draft-model; jest jeden haczyk — dekodowanie DSpark w MLX-VLM używa obecnie próbkowania zachłannego, więc temperaturę trzeba ustawić na 0. Dla llama.cpp istnieje osobne repozytorium GGUF, z pojedynczym eksportem F16 o rozmiarze około 567 MB, a karta wyraźnie zaznacza, że kwantyzowanego draftera łączy się z kwantyzowanym targetem, a nie z oryginalnym checkpointem safetensors.

Miejscem, w którym warstwa routingu ma tu sens, nie jest ten model — OrcaRouter nie obsługuje routingu dla LFM2.5-VL-3B-DSpark ani LFM2.5-VL-3B, a jest to samodzielnie hostowana para z drafterem, którą pobierasz i serwujesz na własnym sprzęcie. Jest nim natomiast reszta stosu wokół niego. Ta sama aplikacja, która uruchamia mały otwarty model wizyjny na urządzeniu, zwykle ma ścieżkę awaryjną dla zapytań, których mały model nie jest w stanie obsłużyć, a skierowanie tej ścieżki na pojedynczy endpoint obejmujący ponad 200 modeli — rozliczany według ceny katalogowej każdego dostawcy, bez doliczania marży, z automatycznym przełączaniem awaryjnym, gdy dostawca zacznie działać gorzej — to mniejsza integracja niż zawarcie drugiej umowy z dostawcą. Drafter usprawnia jedną nogę tej architektury; to router sprawia, że druga noga nie staje się osobnym projektem.

Co jeszcze nie jest znane

W momencie pisania tego tekstu repozytorium ma 37 pobrań i 6 polubień. Nie ma żadnego wpisu dotyczącego tego modelu szkicującego w żadnym publicznym agregatorze benchmarków, żadnej reprodukcji przez strony trzecie któregokolwiek z zakresów przyspieszenia ani niezależnego pomiaru współczynnika akceptacji na sprzęcie, którego Liquid nie testował. Na karcie nie ma też żadnych benchmarków jakości z oczywistych powodów — model szkicujący z założenia zachowuje wynik wyjściowy, więc liczby dotyczące jakości należą do LFM2.5-VL-3B, a karta wskazuje benchmarki tego modelu, zamiast wymyślać własne.

Jeden szczegół w metadanych to drobny sygnał, jak nowy jest to model: model nosi znacznik biblioteki SGLang oraz flagę algorytmu SGLang, która istnieje specjalnie po to, by go wywołać. Wsparcie frameworka musiało zostać dodane przed ogłoszeniem, co jest zgodne z sześciodniową luką między repozytorium a wpisem na blogu.

A więc: autentyczny, użyteczny, wąsko zakrojony kawałek inżynierii, ogłoszony tydzień po wypuszczeniu, którego cała propozycja wartości opiera się na zmierzonej przez dostawcę liczbie na sprzęcie, którego możesz nie mieć. Jeśli obsługujesz LFM2.5-VL-3B na H100 lub Macu z serii M, a twoje obciążenie jest zdominowane przez dekodowanie, koszt pamięci wynosi 8,9%, a potencjalna wada jest bliska zeru, ponieważ wynik jest dowodliwie zgodny z docelowym. Jeśli twoje opóźnienie jest zdominowane przez etap prefill albo liczyłeś na eksport 4-bitowy, sam post Liquid mówi ci, że to nie pomoże. Reprodukcja, kiedy się pojawi, jest tym, na co warto czekać.

OrcaRouter umieszcza ponad 200 modeli za jednym kluczem w cenie katalogowej dostawcy, z 0% narzutu, a ścieżkę zapasową wyraża jako warstwę routingu, a nie kod aplikacji. Drafter tak czy inaczej jest hostowany samodzielnie – to router sprawia, że etap, do którego przekazuje dalej Twój mały model, nie zamienia się w drugi projekt.