LFM2.5-8B-A1B-DSpark vs LFM2.5-2.6B-Base: Część prędkości vs surowiec

Jeśli uporządkujesz rodzinę LFM2.5 według tego, co każdy punkt kontrolny potrafi zrobić samodzielnie, to LFM2.5-8B-A1B-DSpark i LFM2.5-2.6B-Base trafią na przeciwne końce osi — i żaden z końców nie potrafi odpowiedzieć na pytanie. Pierwszy to model szkicujący o 327,7 mln parametrów, który istnieje wyłącznie po to, aby przyspieszyć generowanie tokenów przez brzegowy model mieszanki ekspertów Liquid AI. Drugi to surowy, wstępnie wytrenowany punkt kontrolny o 2,69 mld parametrów, który istnieje wyłącznie po to, aby zostać dostrojony do czegoś innego. Oba zostały wydane w sierpniu 2026 roku na licencji LFM Open License v1.0 firmy Liquid, oba można zdobyć jednym pobraniem na Hugging Face i oba niezwykle łatwo pobrać przez pomyłkę — ponieważ ich nazwy sprawiają, że brzmią jak dwie wersje tego samego.

Nazwy to pułapka. „DSpark" brzmi jak nowy, iskrzący flagowiec rodziny, a „Base" jak zwykła domyślna opcja, którą faktycznie można uruchomić. Żadne z tych skojarzeń nie jest prawdziwe. Checkpoint DSpark nie potrafi samodzielnie odpowiedzieć na nic — jedynie proponuje tokeny do weryfikacji przez LFM2.5-8B-A1B. Base również nie potrafi odpowiedzieć na nic, ale z przeciwnego powodu — to surowy model bazowy, który przewiduje tekst, ale nigdy nie został dotrenowany do modelu czatu lub agenta. To nie jest rywalizacja; to potok. Jeden checkpoint znajduje się na samym końcu stosu serwowania, a drugi na samym początku treningu.

Dwa punkty kontrolne, które dzielą nazwę, a nie pracę.

LFM2.5-8B-A1B-DSpark (wydany 20 sierpnia 2026 r.) to model szkicowy do dekodowania spekulatywnego: pięciowarstwowa sieć wyłącznie z mechanizmem uwagi, blok dziewięciu proponowanych tokenów na krok oraz głowica Markowa na słowniku 128 000 tokenów modelu docelowego. Ładujesz go obok modelu LFM2.5-8B-A1B — MoE o łącznej liczbie 8,3 mld parametrów i około 1,5 mld aktywnych, który wypuszczono już 28 maja — model szkicowy zgaduje kolejne tokeny, a model docelowy weryfikuje cały blok w jednym przejściu w przód, zatrzymując to, co zaakceptuje. Ponieważ model docelowy sprawdza każdy token, wynik przy zachłannym dekodowaniu jest identyczny z uruchomieniem samego LFM2.5-8B-A1B: „bezstratny z założenia” — jak to ujmuje Liquid. Model szkicowy to część przyspieszająca, a nie mózg. Został wydany razem z pokrewnymi modelami szkicowymi dla LFM2.5-1.2B-Instruct i LFM2.5-2.6B, każdy w formatach Safetensors i GGUF, z obsługą od pierwszego dnia w SGLang i llama.cpp.

LFM2.5-2.6B-Base (wydany 4 sierpnia 2026) to drugi koniec potoku: model bazowy o 2,69 mld parametrów w hybrydowej architekturze 30 warstw — 22 bloki krótkich splotów z podwójną bramką oraz 8 bloków attention z grupowanym zapytaniem — wstępnie trenowany na około 34 bilionach tokenów, z fazą pośredniego treningu rozszerzającą kontekst do 128K. Nie ma szablonu czatu, nie był dostrajany do instrukcji i nie ma opublikowanych benchmarków, a własna karta modelu Liquid zaleca go wyłącznie do szeroko zakrojonego dostrajania. Jego jedynym celem jest bycie surowcem, który czteroetapowy potok post-treningowy — dwie rundy SFT, specjalizacja nauczyciela, destylacja na polityce, a następnie agentowe uczenie przez wzmacnianie — przekształca w agenta wywołującego narzędzia LFM2.5-2.6B. Ta sama rodzina, ta sama licencja, ta sama strona pobierania. Całkowicie inne zastosowania.

Obok siebie: siedem wymiarów, dwie prace

Ponieważ te dwa punkty kontrolne pełnią różne funkcje, uczciwe porównanie rozróżnia role obu stron:

• Co to jest — LFM2.5-8B-A1B-DSpark to model wstępny do dekodowania spekulatywnego o wielkości 0,3B; LFM2.5-2.6B-Base to surowy, wstępnie wytrenowany model bazowy o wielkości 2,69B.

Z czym to działa — szkic DSpark współpracuje z modelem MoE LFM2.5-8B-A1B (8,3 mld łącznie, ~1,5 mld aktywnych na token); wersja Base działa samodzielnie, ale tylko jako niedostrojone przewidywanie tekstu.

• Użycie samodzielne — DSpark sam niczego nie tworzy; jedynie przyspiesza cel. Base generuje tekst, ale nie zapewnia użytecznego zachowania produktu — nie podąża za instrukcjami, nie wywołuje narzędzi, nie stosuje szablonu czatu.

Jakość wyników — DSpark dziedziczy dokładne wyniki zachłannego dekodowania modelu docelowego, ponieważ każdy proponowany token jest weryfikowany; Base z założenia nie ma żadnych opublikowanych benchmarków dla żadnego zadania.

• Szybkość — DSpark uzyskuje według pomiarów producenta średnio 2,54× na H100 (do 3,18× na MATH500) i 1,18× na M4 Max względem swojego celu; wynik niezreprodukowany; Base w ogóle nie podaje szybkości wnioskowania.

• Zajętość pamięci — DSpark dodaje około 0,3 GB wag draftu obok modelu docelowego; Base to pełne 2,69B, uruchamialne w mniej niż 2,5 GB, najmniejszy poważny model bazowy w rodzinie.

• Formaty i dostępność — DSpark jest dostępny w formatach Safetensors i GGUF z obsługą SGLang i llama.cpp od pierwszego dnia; Base jest dostępny w formacie Safetensors oraz GGUF, ONNX i MLX i działa na Transformers, vLLM, SGLang, llama.cpp i MLX. Żaden z nich nie jest dziś obsługiwany przez żadnego dostawcę inferencji — oba są checkpointami do samodzielnego hostowania.

Jedyne liczby w tym starciu pochodziły z jednego laboratorium.

Wszystkie dane ilościowe tutaj to pomiar pojedynczego dostawcy, wykonany w dniu wydania szkicu i jeszcze niepowtórzony niezależnie — traktujcie to jako obiecujące, nie zweryfikowane. Liquid zmierzył LFM2.5-8B-A1B-DSpark przy rozmiarze partii 1, temperaturze 0, na pojedynczym H100 z 80 GB w BF16 pod SGLang oraz na MacBooku Pro z M4 Max w FP16 GGUF pod eksperymentalnymi jądrami Metal llama.cpp. Na H100 para uzyskała średnio 2.54× (418 → 1,074 tokenów na sekundę), z najlepszym pojedynczym wynikiem 3.18× na MATH500 (428 → 1,362 tok/s) i średnią akceptacją około 7 z 10 proponowanych tokenów. Na M4 Max ta sama para uzyskała średnio zaledwie 1.18× (90 → 106 tok/s) — to skrajny przypadek na urządzeniu, który sam Liquid wskazał, ponieważ weryfikacja bloku aktywuje więcej ekspertów w obecnym backendzie MoE na Metal i przenosi więcej ruchu wag przez magistralę pamięci.

Strona Base w tym zestawieniu nie ma żadnych liczb, a ten brak jest sam w sobie specyfikacją. Model LFM2.5-2.6B-Base został wstępnie wytrenowany, a nie dotrenowany; nigdy nie był oceniany pod kątem czatu, użycia narzędzi ani zachowań agentowych, ponieważ nikt nie zamierzał używać go w ten sposób. Jego znaczące liczby mają charakter architektoniczny: 2,69 mld parametrów, 128K kontekstu, tokenizer dla 16 języków, mniej niż 2,5 GB do uruchomienia. Nie benchmarkujesz fundamentu; benchmarkujesz to, w co go dostrajasz.

Jest jedna rodzinna ironia, którą warto przytoczyć, zanim cokolwiek zdecydujesz. Draft, o którym jest ten artykuł — ten dla 8B-A1B — właśnie najmniej zyskuje na laptopie (1.18×), podczas gdy siostrzany draft dla rodziny 2.6B, który przyspiesza potrenowanego siostrzanego modelu tej samej Bazy, osiąga średnio 2.27× na M4 Max, z 57% redukcją opóźnienia w wywoływaniu funkcji wielonarzędziowych. Jeśli docelowym urządzeniem jest telefon lub laptop, a nie box z GPU, to właśnie ścieżka 2.6B jest tam, gdzie rozgrywa się historia szybkości.

Więc który pobierasz?

Nigdy nie musisz wybierać bezpośrednio między tymi dwoma, ponieważ nie są one alternatywami — ale musisz wiedzieć, którą pracę wykonujesz:

Jeśli udostępniasz LFM2.5-8B-A1B na własnych GPU i chcesz uzyskać więcej tokenów na sekundę z tego samego krzemu, LFM2.5-8B-A1B-DSpark to odwracalny dodatek: zbuduj SGLang lub llama.cpp z integracjami DSpark z 20 sierpnia, podaj nazwę draftu w poleceniu uruchomieniowym, pozostaw dekodowanie zachłanne, a rozmiar bloku zostanie odczytany automatycznie z konfiguracji draftu. Zysk to mniej więcej 2,5× większa przepustowość przy zerowej zmianie danych wyjściowych; minus to 0,3 GB dodatkowych wag oraz kompilacja na tyle nowa, aby zawierała te PR-y. Usuń dwie flagi spekulacyjne i wracasz do zwykłego modelu docelowego.

Jeśli chcesz zbudować własnego specjalistę — model domenowy, asystenta dla niestandardowego języka, model dostrojony na zastrzeżonych danych — LFM2.5-2.6B-Base to jeden z najtańszych poważnych punktów wyjścia w ekosystemie otwartych wag: 2,6B, poniżej 2,5 GB, kontekst 128K, wielojęzyczny tokenizator. Punkt kontrolny DSpark w ogóle nie może ci w tym pomóc, ponieważ nie jest modelem bazowym.

Jeśli naprawdę chcesz mieć agenta na urządzeniu od Liquid — wywoływanie narzędzi, zadania wieloetapowe — to nie chcesz żadnego z tych dwóch. Chcesz wytrenowanego LFM2.5-2.6B, a później możesz zdecydować, czy dołożyć do niego własny szkic. Base to surowiec dla ludzi, którzy chcą trenować; szkic 8B-A1B to część przyspieszająca dla ludzi, którzy już wdrażają MoE. Błędem jest pobieranie Base, bo chciałeś szybszego agenta, albo szkicu, bo chciałeś fundamentu do trenowania.

Gdzie te dwa się łączą — i gdzie pasuje router.

Oba checkpointy to przypadki samodzielnego hostowania. Draft to akcesorium warstwy serwującej, które istnieje tylko wewnątrz twojego stosu SGLang lub llama.cpp; Base to artefakt treningowy. Żaden z nich nie pojawia się w żadnym hostowanym katalogu ani nie ma ceny za token. W praktyce oznacza to, że każda z tych ścieżek trafia obok hostowanych modeli, które już wywołujesz — a ten miks to dokładnie ta infrastruktura, którą warstwa routingu ma za zadanie skonsolidować.

Po stronie serwowania ekonomia draftu jest prosta i realna: 2,5× więcej tokenów na sekundę z tego samego GPU to 2,5× mniej czasu i mniej więcej 2,5× mniej GPU dla tego samego obciążenia, bez zmiany jakości. Ale ta dźwignia istnieje tylko wtedy, gdy kontrolujesz inferencję. Gdy wywołujesz 8B-A1B przez API, dostawca zatrzymuje przyspieszenie — wtedy liczy się porównanie po stronie API: co dostawca pobiera i czy obniżka ceny dociera do ciebie tego samego dnia, w którym została ogłoszona. Na tym polega router passthrough: jedno API dla ponad 200 modeli, ceny listowe dostawcy przekazywane z zerową marżą, więc obniżka od sprzedawcy jest natychmiast widoczna po twojej stronie, oraz automatyczne przełączanie awaryjne, aby wzrost opóźnień u jednego dostawcy nie stał się twoim opóźnieniem. Możesz też wystawić własny, samodzielnie hostowany stos LFM przez ten sam punkt końcowy — w ten sposób testujesz zupełnie nowy model draftu na prawdziwym ruchu, bez stawiania na niego ścieżki produkcyjnej.

LFM2.5-8B-A1B-DSpark i LFM2.5-2.6B-Base mają wspólną nazwę rodziny i przeciwstawne zadania: jeden to część przyspieszająca przymocowana do krawędzi MoE, drugi to niewyregulowany mózg, z którego wyrasta agent 2.6B. Żaden z nich nie działa samodzielnie. Wybierz drafter, aby przyspieszyć model MoE, który już obsługujesz na GPU, wybierz Base, aby dostroić fundament 2.6B do czegoś własnego, a jeśli chciałeś działającego agenta, zignoruj oba — ponieważ jedyną wspólną cechą obu punktów kontrolnych jest to, że żaden z nich sam w sobie nie robi niczego, co można by wykorzystać.

Często zadawane pytania

Czy mogę uruchomić LFM2.5-8B-A1B-DSpark samodzielnie?

Nie. To model szkicowy bez samodzielnego wyjścia — proponuje tokeny kandydujące, które następnie weryfikuje model docelowy LFM2.5-8B-A1B, więc istnieje wyłącznie wewnątrz stosu serwującego z dekodowaniem spekulatywnym, zbudowanego na integracjach SGLang lub llama.cpp z 20 sierpnia. Samo jego pobranie nie daje ci niczego, o co mógłbyś zapytać.

Czy LFM2.5-2.6B-Base to punkt kontrolny, który działa na urządzeniu jako agent?

Nie w stanie surowym. Base to surowy, wstępnie wytrenowany fundament bez dostrajania instrukcji i bez szablonu czatu. Model działający jako agent na urządzeniu Liquid to potrenowany LFM2.5-2.6B, który powstaje z Base dzięki czteroetapowemu potokowi potreningowemu — a jeśli chcesz go przyspieszyć, w połączeniu ze szkicem LFM2.5-2.6B-DSpark.