LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: Czy naprawdę warto podłączać drafter?

Oto decyzja w jednym zdaniu: LFM2.5-24B-A2B-DSpark to plik z 327,7 mln parametrów, który umieszczasz obok LFM2.5-24B-A2B, aby model 24B szybciej generował ten sam rodzaj wyników. Nie jest alternatywą dla modelu ani czymś, co wybierasz zamiast niego. Jedynym naprawdę istotnym pytaniem, jakie nasuwają te dwie nazwy, jest pytanie inżynierskie — czy podłączyć model szkicujący do swojego wdrożenia, czy go pominąć — a odpowiedź zależy mniej od reklamowanego przyspieszenia Liquid AI niż od dwóch liczb, których nikt nie podaje w materiałach: ile tokenów szkicu zostanie zaakceptowanych na Twoim ruchu i jak dużą współbieżność już utrzymujesz. Udokumentowane awarie AI i incydenty z agentami, które stoją za takimi wydaniami jak to, są zebrane w OrcaRouter AI Incident Archive, gdzie każdy wpis ma własne źródła, poziom istotności, stopień pewności i oznaczenie sporności.

Liquid AI nie opublikowała wpisu o premierze draftera. Repozytorium stało się publiczne 2026-10-19 wraz z wagami, plikiem CSV z benchmarkiem i flagami uruchomieniowymi SGLang, podczas gdy własna karta modelu docelowego wciąż oznacza draftera jako „coming soon”, a strona dokumentacji Liquid dotycząca dekodowania spekulatywnego wymienia tylko modele docelowe 1.2B, 2.6B, 8B i VL-3B. Jest to więc porównanie wydanego artefaktu z wydanym modelem, napisane na podstawie repozytorium, a nie komunikatu prasowego — co oznacza, że każda podana poniżej liczba dotycząca wydajności jest raportowana przez dostawcę i żadna nie została niezależnie odtworzona.

Co autor projektu faktycznie zmienia, a czego nie

Mechanizm ten wart jest trzydziestu sekund, ponieważ determinuje wszystko inne. Dekodowanie tokena jest ograniczone pamięcią: GPU przez większość czasu przesyła strumieniowo wagi do SRAM, zamiast wykonywać obliczenia arytmetyczne. Dekodowanie spekulatywne wykorzystuje to, pozwalając małemu modelowi odgadnąć kilka kolejnych tokenów naraz, a następnie sprawdzając całe to odgadnięcie w rzeczywistym modelu podczas jednego przebiegu w przód. Jeśli odgadnięcie było trafne, wygenerowano dziewięć tokenów mniej więcej kosztem jednego. Jeśli było nietrafne, model docelowy zachowuje własny token, a ty zapłaciłeś nieco więcej.

Co się zmienia: liczba tokenów na sekundę oraz kształt wykorzystania GPU. Co się nie zmienia: wagi modelu, jego okno kontekstu, sposób wywoływania narzędzi ani jego ceny tam, gdzie jest sprzedawany. LFM2.5-24B-A2B zachowuje 24,0B parametrów łącznie, z 2,45B aktywnych na token, 40 warstw podzielonych między bramkowane krótkie sploty i uwagę z grupowanymi zapytaniami, 64 ekspertów na blok z routingiem top-4, kontekst 131 072 tokenów i słownik 128 000 tokenów. Model szkicujący dodaje pięć warstw uwagi, głowicę Markowa rzędu 256 i głowicę pewności oraz ponownie wykorzystuje embeddingi i głowicę LM modelu docelowego, zamiast mieć własne.

Jedno zastrzeżenie przesunęło się między tymi dwoma wydaniami i zasługuje na osobne zdanie. W sierpniu opracowanie Liquid o DSpark mówiło, że emitowana sekwencja jest „z konstrukcji identyczna z bazowym dekodowaniem zachłannym”. Karta modelu draftującego 24B mówi natomiast, że różnice zmiennoprzecinkowe między weryfikacją wsadową a zwykłym dekodowaniem „mogą dawać inny tekst, także przy próbkowaniu zachłannym”. Oba stwierdzenia są obronne — pierwsze jest prawdziwe w arytmetyce dokładnej — ale jeśli Twój system ewaluacyjny porównuje wyniki bajt po bajcie, spodziewaj się, że to zauważy.

Strona kosztów w księdze

Drafter nie jest darmowy. Zajmuje 655 MB w BF16 na GPU (lub 664 MB w F16 GGUF na CPU), siedzi w tej samej puli pamięci co model docelowy, a każdy proponowany przez niego krok kosztuje przejście w przód weryfikacji po bloku tokenów, a nie po pojedynczym tokenie. W przypadku celu MoE ta ostatnia część jest droższa, niż brzmi: weryfikacja dziewięciu tokenów aktywuje więcej ekspertów niż dekodowanie jednego, więc liczba bajtów przenoszonych na zweryfikowany token rośnie, a nie maleje. Liquid wskazał dokładnie to jako powód, dla którego jego 8B drafter osiągnął tylko 1,18× na M4 Max pomimo wysokiej akceptacji.

W porównaniu z tym oszczędności są wystarczająco duże, aby mierzyć je w godzinach GPU. Korzystając z własnych danych B300 dostawcy z benchmarks/b300-fp8.csv, a jedynie dzieląc miliard tokenów wyjściowych przez zaobserwowaną przepustowość:

• MATH-500, współbieżność 1 — 324 tok/s samodzielnie (857 godzin GPU na miliard tokenów) w porównaniu z 853 tok/s z modelem szkicującym (326 godzin GPU). Skrócenie czasu obliczeń o 2,63×.

• MATH-500, współbieżność 256 — 15 423 tok/s samodzielnie (18,0 godzin GPU) wobec 27 579 tok/s z drafterem (10,1 godzin GPU). Redukcja 1,79×.

• GSM8K, współbieżność 256 — 4,491 tok/s samodzielnie (61.9 godz. GPU) w porównaniu z 9,660 tok/s z drafterem (28.8 godz. GPU). Skrócenie o 2.15×.

• LiveCodeBench, współbieżność 256 — 18 812 tok/s samodzielnie (14,8 godz. GPU) wobec 25 231 tok/s z drafterem (11,0 godz. GPU). Zaledwie 1,34× skrócenia — najsłabsza komórka w tabeli.

To są współczynniki przepustowości przeliczone na czas, a nie na pieniądze, ponieważ pieniądze zależą od tego, ile płacisz za GPU-godzinę, a ten artykuł nie zamierza wymyślać stawki. Ale kolejność utrzymuje się przy dowolnej stawce: dołączenie draftującego modelu jest warte od dwóch do trzech godzin na dziesięć dla ruchu związanego z rozumowaniem i generowaniem kodu przy niskiej współbieżności, a przy wysokiej współbieżności jest warte około jednej trzeciej tej wartości. Jeśli twoje wdrożenie 24B to agent dla pojedynczego użytkownika na stacji roboczej, argument jest mocny. Jeśli to nasycony endpoint wsadowy, argument jest realny, ale znacznie słabszy, niż sugeruje nagłówek 2,4×.

Gdzie kreślarz zarabia na siebie, pod względem obciążenia pracą

Rozrzut ośmiu zbiorów danych w tabeli dostawcy nie jest szumem; przekłada się na typy promptów, a to odwzorowanie jest najbardziej użyteczną rzeczą w tym wydaniu. Wskaźnik akceptacji wahał się od 6,70 tokena na krok w MBPP do 4,02 w LiveCodeBench. Zbiory, które uzyskały wysokie wyniki, to te, w których wynik modelu jest ograniczony przez prompt — krótkie funkcje w stylu testów jednostkowych, arytmetyka z weryfikowalną ścieżką, odpowiedzi wielokrotnego wyboru. Te, które uzyskały niskie wyniki, to te, w których model musi wymyślić długie, nieograniczone rozwiązanie: problemy programowania konkursowego i matematyka w stylu AIME.

Ta intuicja powinna towarzyszyć Twojej własnej ocenie. Model rozumujący 24B oferowany do zadań agentowych zużywa większość swoich tokenów wyjściowych na łańcuch myśli, który wygląda bardziej jak LiveCodeBench niż MBPP. Model używany do ekstrakcji strukturalnej, klasyfikacji według schematu lub stałego formatu wywołań narzędzi wygląda znacznie bardziej jak wiersze o wysokiej akceptacji. Jeśli Twoje obciążenie należy do pierwszego rodzaju, spodziewaj się wyniku bliższego dolnej granicy zakresu 1,34× niż górnej 3,28×. Nikt nie opublikował współczynnika akceptacji dla poszczególnych obciążeń dla tego draftora, a osiem zbiorów danych z karty jest najbliższym dostępnym przewodnikiem.

Na tym tle: 24B to model przeznaczony wyłącznie do rozumowania. Liquid twierdzi, że zawsze myśli przed udzieleniem odpowiedzi — szablon czatu wstawia <think> tag automatycznie. To najgorszy możliwy układ dla spekulacji, ponieważ fragment rozumowania to dokładnie ten długi odcinek o niskiej akceptacji. Model szkicujący nadal pomoże; najbardziej pomoże przy końcowej odpowiedzi, a najmniej przy części, która zajmuje najwięcej czasu.

Jak to sprawdzić na własnym sprzęcie w ciągu jednego popołudnia

Nie musisz ufać niczemu z powyższego. Obie ścieżki wnioskowania udostępniają licznik akceptacji, który jest jedyną liczbą decydującą o tym, czy drafter zwraca się na Twoim ruchu.

W SGLang uruchom model docelowy z dołączonym drafterem, rozmiarem bloku 9 i dziesięcioma tokenami draftu, a następnie odczytaj metryki dekodowania spekulatywnego, które serwer raportuje dla każdego żądania. Współczynnik akceptacji w tabeli dostawcy zawiera się między 0,33 a 0,65 w zależności od zbioru danych; przebieg, który wypada znacznie poniżej odpowiedniego wiersza, oznacza, że drafter zgaduje błędnie i płacisz za weryfikację, nie zbierając przyspieszenia. W llama.cpp z sidecarem GGUF F16 czasy dla poszczególnych odpowiedzi zawierają draft_n i draft_n_accepted bezpośrednio. Podziel jeden przez drugi.

Dwa szczegóły operacyjne będą cię kosztować godzinę, jeśli je przeoczysz. Serwer SGLang wymaga kompilacji zawierającej ścieżkę LFM2-MoE DSpark scaloną 31 sierpnia 2026 r. — na jakiejkolwiek starszej wersji architektura draftująca jest po prostu nieznana. A rozmiar bloku jest właściwością checkpointu, a nie dowolnym parametrem: llama.cpp ogranicza --spec-draft-n-max do wartości 9 z metadanych pliku sidecar, więc proszenie o 12 nic nie daje.

Pytanie, na które to porównanie nie może odpowiedzieć

Istnieje wersja pytania „czy podpiąć drafter?”, która nie ma nic wspólnego z GPU, i to właśnie z nią ma do czynienia większość zespołów. Jeśli wywołujesz LFM2.5-24B-A2B przez hostowane API, decyzja o drafterze nie należy do Ciebie. Stos obsługi albo podpina spekulacyjny dekoder, albo nie; widzisz liczbę tokenów na sekundę i cenę, a obie zostały ustalone na wcześniejszym etapie. Console Liquida podaje dla modelu 24B stawkę 0,10 USD za milion tokenów wejściowych, 0,05 USD za buforowane tokeny wejściowe i 1,00 USD za milion tokenów wyjściowych — opublikowaną stawkę, która już odzwierciedla ścieżkę dekodowania, jaką stosują, i która może się zmienić bez powiadomienia.

To jest ten styk, w którym routing pomaga, a nie komplikuje. Wywołanie hostowane i wdrożenie self-hosted to nie tyle konkurencyjne plany, ile dwa ustawienia tego samego pokrętła kosztów: self-hosting wraz z drafterem minimalizuje koszt na token, jeśli Twój wolumen pozwala utrzymać GPU w ciągłym użyciu, a hostowany endpoint minimalizuje pracę potrzebną do uzyskania odpowiedzi. OrcaRouter jest zbudowany pod ten drugi scenariusz — jeden klucz do ponad 200 modeli przy 0% narzutu na cenę katalogową dostawcy, więc zmiana ceny dostawcy pojawia się po naszej stronie tego samego dnia, z automatycznym przełączaniem awaryjnym, jeśli dostawca pogorszy jakość, oraz DSL routingu do rozdzielania ruchu zamiast zakodowania na stałe jednego backendu. Obecnie nie obsługujemy rodziny LFM2.5, więc w przypadku tego konkretnego modelu strona hostowana oznacza własne API Liquid lub własne GPU; porównanie, które warto przeprowadzić, dotyczy modeli, które oferujemy, takich jak Qwen3.6-35B-A3B — model, względem którego Liquid prowadzi benchmarki w zadaniach agentowych — lub Gemma 4 26B-A4B.

Więc: załączyć to czy nie

Dołącz go, jeśli sam obsługujesz LFM2.5-24B-A2B przy umiarkowanym współbieżeniu, zwłaszcza w przypadku danych wyjściowych ustrukturyzowanych lub przypominających ekstrakcję, i jeśli masz 655 MB zapasu obok modelu docelowego. Liczby dostawcy mówią, że skrócisz tam czas dekodowania mniej więcej o połowę lub do jednej trzeciej, a ryzyko jest ograniczone: zły drafter kosztuje jedną rundę weryfikacji, a nie błędną odpowiedź.

Pozostaw to wyłączone, jeśli Twój endpoint jest już obciążony na poziomie setek, jeśli Twoje dane wyjściowe to długie, swobodne rozumowanie albo jeśli potrzebujesz liczb dla Apple Silicon, zanim się zdecydujesz — karta ich nie zawiera, a najbliższy odpowiednik z tej samej rodziny trafił na rynek z wynikiem 1,18× na MacBooku. I oczywiście pozostaw to wyłączone, jeśli w ogóle nie uruchamiasz modelu: drafter to optymalizacja dla wdrożenia, a nie ma czego optymalizować, dopóki wdrożenie nie istnieje.

O resztę rozstrzygnęłyby post producenta i pomiar na Macu. Na dzień 2026-10-21 nie istnieje ani jedno, ani drugie — co jest dziwnym stanem dla wydania, którego wagi można już pobierać — a dla każdego, kto chciałby samodzielnie uruchomić licznik akceptacji, to wyjątkowo tania okazja, by być pierwszym niezależnym wynikiem na tablicy.