LFM2.5-2.6B-DSpark: 328M Drafter, który sprawia, że agent on-device Liquid działa 2,3× szybciej

Nikt spoza Liquid AI nie uruchomił LFM2.5-2.6B-DSpark na własnym sprzęcie i nie opublikował jeszcze żadnych wyników. To uczciwy punkt wyjścia w przypadku tego modelu, ponieważ cała ta sprawa to deklaracja wydajności: to nie jest lepszy model 2.6B, tylko model szkicujący (draft) z 328M parametrów, który stoi przed agencyjnym modelem LFM2.5-2.6B i proponuje tokeny do weryfikacji, dzięki czemu agent działa około dwa razy szybciej, bez zmiany swojego wyniku.

Wydany 20 sierpnia 2026 roku wraz z opisem technicznym na Hugging Face i towarzyszącym wpisem na blogu Liquid, LFM2.5-2.6B-DSpark jest sztandarowym przedstawicielem małej rodziny checkpointów-drafterów do dekodowania spekulatywnego, które Liquid opublikował tego dnia. Wszystkie dane w kolumnie prędkości poniżej pochodzą z pomiarów producenta i nie zostały jeszcze niezależnie potwierdzone; wszystko w repozytorium, formaty i wsparcie frameworków można po prostu sprawdzić.

Czym jest DSpark, jednym tchem

Dekodowanie spekulacyjne to trik polegający na uruchomieniu taniego modelu szkicującego przed właściwym modelem: szkicownik przewiduje następną garść tokenów, a model docelowy sprawdza całą partię w jednym przejściu w przód i zatrzymuje tokeny, z którymi się zgadza. Gdy przewidywania są trafne, przesuwasz kilka tokenów w cenie jednego, więc przepustowość rośnie bez ruszania wag modelu docelowego. DSpark — technika pierwotnie zaproponowana przez badaczy DeepSeek w lipcu 2026 roku i już wdrożona w DeepSeek-V4 — to wersja tego triku dostrojona do małych modeli działających na urządzeniu. Liquid nazywa to dekodowaniem spekulacyjnym z harmonogramem ufności (confidence-scheduled speculative decoding) i składa się ono z trzech ruchomych części: równoległego szkieletu, który produkuje ukryte stany dla wszystkich tokenów szkicowanych w jednym przejściu, lekkiej sekwencyjnej głowy, która modeluje zależności między sąsiednimi tokenami, aby wskaźnik akceptacji nie załamywał się pod koniec bloku, oraz weryfikatora, który przycina mało wiarygodne przyrostki, gdy sprawdzanie ich kosztuje więcej, niż oszczędza.

Ta ostatnia część sprawia, że DSpark różni się od zwykłego szkicownika: nie zawsze przepuszcza całego bloku przez weryfikację. Gdy pewność szkicu wskazuje, że sufiks prawdopodobnie nie zostanie zaakceptowany, skraca blok i oszczędza zmarnowane obliczenia. Blok szkicu ma dziewięć tokenów, więc cel weryfikuje do dziesięciu naraz.

Kreślarz po numerach

{{1}}Punkt kontrolny LFM2.5-2.6B-DSpark{{/1}} to {{2}}model szkicujący o parametrach 0,3B, oparty wyłącznie na mechanizmie uwagi{{/2}}: {{3}}pięć pełnych warstw uwagi (wymiar ukryty 2048, grupowana uwaga zapytań z 32 głowami i 8 głowami klucz-wartość){{/3}}, {{4}}słownik obejmujący 128 tys. tokenów{{/4}}, {{5}}głowa Markowa o randze 256 oraz głowa ufności{{/5}}. Firma Liquid trenowała go przez {{6}}15 epok na mieszance danych instrukcyjnych, konwersacyjnych, kodowych i do wywoływania funkcji — na sprzęcie AMD{{/6}} — i {{7}}wybrała epokę na podstawie najwyższego współczynnika akceptacji, a nie najniższej straty{{/7}}.

Ten wskaźnik akceptacji to liczba decydująca o tym, ile wart jest drafter. W pięciu benchmarkach przy batch size 1 i temperaturze 0, LFM2.5-2.6B-DSpark osiągał średnio 4,83 zaakceptowanych tokenów na krok dekodowania na H100 i 4,42 na M4 Max — mniej więcej połowa bloku została zaakceptowana, a to właśnie tam leży źródło dwukrotnego przyspieszenia.

Przyspieszenia, oznaczone

Wszystkie poniższe liczby pochodzą z własnych pomiarów Liquid AI — SGLang na pojedynczym H100 80GB w BF16 oraz llama.cpp z backendem Metal na MacBooku Pro M4 Max w FP16 GGUF, batch size 1, temperatura 0 — a żadna z nich nie została odtworzona przez niezależną stronę w chwili pisania tego tekstu:

• Średnio na H100 — 2,67×, od 323 do 864 tokenów/s. Wg benchmarków: MATH500 3,06×, HumanEval 2,56×, MBPP 2,64×, GSM8K 2,22×, MT-Bench 2,87×.

• M4 Max średnio — 2.27×, z 61 do 139 tokenów/s. Według benchmarków: MATH500 2.25×, HumanEval 2.63×, MBPP 2.11×, GSM8K 2.36×, MT-Bench 1.99×.

• Wywoływanie narzędzi — w scenariuszach wywoływania funkcji z wieloma narzędziami średnie opóźnienie spadło o 57%.

• Kontekst rodziny — największy drafter w rodzinie, LFM2.5-8B-A1B-DSpark, osiągnął do 3,18× na H100, a drafter 1,2B do 2,87× na M4 Max; powyższe wyniki 2,6B to środek stawki.

Dwie rzeczy dotyczące tych liczb mają znaczenie wykraczające poza średnie. Po pierwsze, są one mierzone przy temperaturze 0 i rozmiarze partii 1 — czyli w konfiguracji, która sprzyja spekulacji i w której najczęściej odbywa się interaktywna praca agenta na urządzeniu. Gwarancja identyczności również tu obowiązuje: dekodowanie spekulatywne weryfikuje każdy proponowany token, więc przy zachłannym dekodowaniu wygenerowany tekst jest dokładnie taki, jaki model docelowy wyprodukowałby samodzielnie. Po drugie, różnica zmniejsza się wraz ze wzrostem współbieżności: na pojedynczym H100, Liquid podaje, że przewaga DSpark zbiega się w okolicach rozmiaru partii 128, więc drafter jest zyskiem pod względem opóźnień dla obciążeń interaktywnych i intensywnie korzystających z narzędzi, a nie srebrną kulą dla surowej przepustowości w maksymalnie obciążonym serwerze.

Co jest potwierdzone, a co nie

Potwierdzone, w tym sensie, że repozytorium jest publiczne i można je zweryfikować: drafter jest udostępniany w formatach Safetensors (BF16) i GGUF; współpracuje z potrenowanym LFM2.5-2.6B, a nie z modelem bazowym; wsparcie od pierwszego dnia trafiło upstream do llama.cpp (z eksperymentalnymi jądrami Metal) i do SGLang; jest licencjonowany na mocy LFM Open License v1.0 firmy Liquid; oraz — co istotne dla każdego, kto planuje z niego korzystać — karta modelu stwierdza, że żaden dostawca wnioskowania go nie obsługuje, więc jest to komponent do samodzielnego uruchomienia.

Jeszcze nie potwierdzono: czy przyspieszenia powtarzają się na innym sprzęcie i w innych konfiguracjach (nikt poza Liquid nie opublikował pomiaru), jak drafter zachowuje się przy próbkowaniu zamiast dekodowania zachłannego, oraz czy wartość 57% opóźnienia wywołań narzędzi utrzymuje się w rzeczywistych środowiskach agentowych poza platformą benchmarkową używaną przez Liquid. Żadne z tych nie są oskarżeniami — wydanie ma dopiero dzień — ale to różnica między obiecującą liczbą a zweryfikowaną.

Uruchamianie tego.

W SGLang używasz kompilacji z obsługą DSpark, uruchamiasz serwer dla docelowego modelu i wskazujesz model szkicujący: algorytm spekulacyjny to DSPARK, ścieżka modelu szkicującego wskazuje LiquidAI/LFM2.5-2.6B-DSpark, a rozmiar bloku jest odczytywany z pliku config.json modelu szkicującego. W llama.cpp ładujesz docelowy plik GGUF, a model szkicujący w postaci GGUF ustawiasz jako model szkicujący, a typ spekulacji ustawiasz na draft-dspark, przy czym rozmiar bloku jest odczytywany z metadanych sidecar. Obie integracje zostały włączone do głównego nurtu, więc nie są potrzebne żadne forki — wystarczy na tyle nowa kompilacja, aby je zawierała.

Kiedy warto dodać

LFM2.5-2.6B-DSpark zasługuje na te dodatkowe ~0,3 GB pamięci, gdy faktycznie wdrażasz agenta 2.6B tam, gdzie Liquid zaprojektował go do działania — na telefonie, laptopie lub urządzeniu brzegowym — w przypadku obciążeń interaktywnych lub związanych z wywoływaniem narzędzi, które są ograniczone opóźnieniami i działają w trybie zachłannym. To jest dokładnie ten profil, w którym 2,27× przyspieszenie na urządzeniu i 57% skrócenie opóźnienia wywołań narzędzi odgrywają swoją rolę. Jest to mniej interesujące, gdy serwujesz przy dużym batchu na serwerze (przyspieszenie zmierza do 1×) lub gdy Twoje obciążenie działa z temperaturą powyżej zera, gdzie podane wartości przestają obowiązywać. A jeśli korzystasz z wariantu 8B-A1B z tej rodziny, zwróć uwagę na ten przypadek brzegowy: jego przyspieszenie na urządzeniu wynosi obecnie tylko około 1,18×, ponieważ weryfikacja tokenów kandydatów aktywuje więcej ekspertów w backendzie Metal llama.cpp — Liquid oznacza to jako znane.

Nic w DSpark nie zmienia tego, gdzie działa agent 2.6B — to z założenia rozwiązanie self-hosted, które będzie działać obok hostowanych modeli, z których już korzystasz. To połączenie lokalnego draftera z kilkunastoma punktami końcowymi API to dokładnie ten rodzaj infrastruktury, do upraszczania której istnieje warstwa routingu: jeden klucz API na 200+ modeli, automatyczne przełączanie awaryjne, gdy dostawca spowalnia, oraz ceny dostawców przepuszczane z 0% narzutu, dzięki czemu porównanie kosztów lokalnych i hostowanych dla agenta klasy 2.6B pozostaje czytelne, zamiast mieszkać w arkuszu kalkulacyjnym.

LFM2.5-2.6B-DSpark należy dziś czytać jako obiecujące, zmierzone przez dostawcę, jeszcze niezweryfikowane niezależnie twierdzenie o szybkości, powiązane z realnym, możliwym do pobrania i uruchomienia checkpointem. Jeśli wdrażasz agenta 2.6B na urządzeniu, drafter jest tani w wypróbowaniu i łatwy do usunięcia — dodaj dwie flagi spekulatywne do polecenia SGLang, zachowaj dekodowanie zachłanne i zmierz na własnym obciążeniu roboczym, zanim zaufasz wartości 2.3×. Repozytorium jest dostępne; niezależna weryfikacja pozostaje otwartą kwestią.