LiquidAI: LFM2.5-DSpark przyspiesza wnioskowanie do 3,2x

LiquidAI opublikowało na Hugging Face nowe checkpointy modeli szkicujących (draft models) opartych na technice DSpark dla trzech modeli z rodziny LFM2.5: LFM2.5–1.2B-Instruct, LFM2.5–2.6B oraz LFM2.5–8B-A1B. Rozwiązanie dodaje ścieżkę spekulatywnego dekodowania, która w zamian za minimalny wzrost zużycia pamięci pozwala uzyskać znaczące przyspieszenie generowania tekstu — bez żadnej utraty jakości wyników.

Zespół LiquidAI twierdzi, że nowe modele szkicujące przyspieszają wnioskowanie nawet 3,18 razy na kartach graficznych i do 2,87 razy przy uruchomieniu lokalnie na urządzeniu. Dodatkowo integracja skraca opóźnienia w scenariuszach wywoływania funkcji (function-calling) o średnio 57% dla modelu LFM2.5–2.6B, co ma bezpośrednie znaczenie dla agentowych zastosowań AI działających offline.

Kluczowe wnioski

• DSpark to trzeci wariant spekulatywnego dekodowania po EAGLE-3 i DFlash, łączący równoległy backbone, lekką sekwencyjną głowę modelowaną jako łańcuch Markowa oraz weryfikator ze harmonogramem pewności.
• Modele szkicujące są niewielkie — mają około 300 mln parametrów, podczas gdy same modele docelowe LFM2.5 są znacznie większe.
• Na GPU H100 średnie przyspieszenie sięga 2,10–2,67x, a na laptopie Apple M4 Max od 1,20x (dla modelu MoE 8B-A1B) do 2,54x (dla 1,2B-Instruct), w zależności od modelu i zbioru danych.
• Wyjście generowane przez model pozostaje identyczne jak przy standardowym greedy decoding — jakość odpowiedzi (pass@1, exact match) nie zmienia się.
• Wsparcie dla llama.cpp i SGLang jest dostępne od pierwszego dnia, a integracja została udostępniona jako open source w głównych repozytoriach tych projektów.

Jak działa DSpark

Faza dekodowania w dużych modelach językowych jest tradycyjnie ograniczona przepustowością pamięci, nie mocą obliczeniową — większość opóźnień powstaje przy przesyłaniu wag z pamięci DRAM do SRAM, a nie przy samych obliczeniach. Spekulatywne dekodowanie rozwiązuje ten problem, wykorzystując lekki model szkicujący do wygenerowania kandydatów na kolejne tokeny, które następnie model docelowy weryfikuje w jednym przebiegu do przodu — dzieląc koszt wczytywania wag na wszystkie weryfikowane tokeny naraz.

DSpark, opisywany przez LiquidAI jako najnowsze podejście w tej rodzinie technik (po EAGLE-3 i DFlash), łączy trzy komponenty:

• backbone w stylu DFlash, warunkowany na cechach kontekstowych modelu docelowego, generujący stany skryte dla wszystkich tokenów szkicu w jednym przebiegu,
• lekką sekwencyjną głowę modelowaną jako łańcuch Markowa między sąsiednimi tokenami, która dodaje zależność między tokenami i zwiększa wskaźnik akceptacji na dalszych pozycjach,
• weryfikator ze harmonogramem pewności, który przewiduje prawdopodobieństwo „przetrwania” każdego tokenu i odrzuca fragmenty o niskiej pewności, gdy koszt ich weryfikacji przewyższyłby zysk.

Zespół zastosował uproszczoną architekturę oparte wyłącznie na warstwach uwagi (attention-only) z 5 warstwami i blokiem o rozmiarze 9. Dla każdego modelu szkicującego przeprowadzono 15 epok treningu na całym zbiorze danych obejmującym SFT, chat, kod i dane związane z wywoływaniem funkcji, wybierając epokę z najwyższym wskaźnikiem akceptacji, a nie z najniższą stratą (loss). Rozmiary komponentów są niewielkie: stos dekodera to 241,2 mln parametrów we wszystkich trzech modelach, projekcja stanów skrytych — 21 mln, głowa Markowa — od 33,6 mln (dla 1,2B-Instruct) do 65,5 mln (dla 2,6B i 8B-A1B), a normy i głowa pewności — jedynie 27,5 tys. parametrów. Łącznie modele szkicujące mają 295,7–327,7 mln parametrów.

Parytet jakości i wyniki wydajnościowe

Kluczowym elementem podejścia jest to, że przy greedy decoding token proponowany przez model szkicujący jest akceptowany tylko wtedy, gdy odpowiada rozkładowi wyjściowemu modelu docelowego. W przypadku odrzucenia miejsce zajmuje token wygenerowany bezpośrednio przez model docelowy. W efekcie generowana sekwencja jest identyczna z bazowym greedy decoding z definicji, więc dokładność na benchmarkach (pass@1 lub exact match) nie ulega zmianie.

Testy przeprowadzono na dwóch platformach: llama.cpp z Metal na laptopie MacBook Pro z chipem M4 Max (wagi FP16 GGUF, do 256 tokenów wyjściowych) oraz SGLang na pojedynczej karcie H100 80 GB w formacie BF16. W obu przypadkach zastosowano rozmiar bloku DSpark równy 9, wielkość batcha 1 i temperaturę 0, a ewaluację przeprowadzono na pięciu zbiorach benchmarkowych: MATH500, HumanEval, MBPP, GSM8K i MT-Bench.

Dla LFM2.5–2.6B przyspieszenie na MacBooku jest szczególnie zauważalne — średnie przyspieszenie wyniosło 2,67x na H100 (z 323 do 864 tok/s) oraz 2,27x na M4 Max (z 61 do 139 tok/s), przy średnim wskaźniku akceptacji 4,81 na 10 możliwych tokenów. LiquidAI zwraca uwagę, że taki poziom interaktywności na urządzeniu przewyższa przepustowość oferowaną przez większość zamkniętych modeli chmurowych (ok. 140 tok/s, w zależności od zbioru danych).

Model LFM2.5–1.2B-Instruct wykazał większą zmienność wskaźników akceptacji w zależności od zbioru danych — od 3,90 (MT-Bench) do 6,02 (MATH500) — co przekłada się na różnice w przyspieszeniu sięgające nawet 52% w zależności od rozkładu tekstu. Średnio przyspieszenie wyniosło 2,10x na H100 (z 656 do 1384 tok/s) i 2,54x na M4 Max (z 138 do 350 tok/s).

Model LFM2.5–8B-A1B, mimo wyższego wskaźnika akceptacji niż w przypadku dwóch modeli gęstych (do 8,52 na 10 dla MT-Bench, dającego 3,02x przyspieszenia na H100), na urządzeniu przyniósł tylko 18-procentowe średnie przyspieszenie. LiquidAI wyjaśnia, że wynika to z obecnej implementacji architektury MoE w backendzie Metal llama.cpp — weryfikacja kilku tokenów naraz aktywuje więcej ekspertów modelu, co generuje większy ruch danych wagowych niż pojedynczy krok dekodowania. Dla MATH500 przyspieszenie na H100 sięgnęło aż 3,18x (z 428 do 1362 tok/s), przy czym na M4 Max wyniosło tylko 1,21x (z 93 do 112 tok/s).

Znaczenie dla branży AI

Publikacja LiquidAI wpisuje się w szerszy trend optymalizacji wnioskowania modeli językowych bez konieczności trenowania nowych, większych architektur. Otwarte udostępnienie integracji z llama.cpp i SGLang oznacza, że przyspieszenie może być wykorzystane od razu przez społeczność open-source, bez konieczności czekania na komercyjne wsparcie. Szczególnie istotny jest wynik dla scenariuszy agentowych — 57-procentowe ograniczenie opóźnień w wywoływaniu funkcji przybliża praktyczne, lokalne wdrożenia agentów AI działających w czasie zbliżonym do rzeczywistego, bez zależności od infrastruktury chmurowej.

DSpark potwierdza, że modele szkicujące o zaledwie kilkuset milionach parametrów mogą znacząco poprawić przepustowość dużo większych modeli docelowych, zachowując przy tym pełną wierność wyjścia względem standardowego dekodowania greedy — co jest kluczowe dla zastosowań wymagających deterministycznych, powtarzalnych odpowiedzi.