LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: ten sam plik 328M, dwa bardzo różne zakłady

Pobierz dowolny z tych plików, a otrzymasz 655 421 522 bajtów. LFM2.5-24B-A2B-DSpark i LFM2.5-8B-A1B-DSpark mają identyczny rozmiar co do bajta, współdzielą pięciowarstwowy szkielet, tę samą głowicę Markowa rangi 256, ten sam rozmiar bloku wynoszący 9 i ten sam słownik o wielkości 128 000 tokenów — a żaden z nich nie potrafi odpowiedzieć na choćby jedno zapytanie, ponieważ oba są modelami szkicującymi do dekodowania spekulatywnego, które istnieją tylko po to, by zgadywać tokeny dla modelu docelowego. Tym, co je różni, nie jest ich własna specyfikacja. Jest nim to, na jakim modelu docelowym je trenowano i jak wiele dowodów istnieje, że ta sztuczka na nim działa. Jeden ma opublikowane pomiary GPU i MacBooka z wpisu o premierze; drugi ma tabelę GPU i żadnej zapowiedzi. Wybór między nimi nie jest więc wcale porównaniem modeli — to porównanie dwóch zakładów, a tylko jeden z nich został wypłacony. Udokumentowane awarie AI i incydenty z agentami, które stoją za takimi wydaniami jak to, zostały zebrane w OrcaRouter AI Incident Archive gdzie każdy wpis zawiera własne źródła, poziom dotkliwości, stopień pewności i flagę sporu.

Pliki są bliźniacze; zadania nie.

Przeczytaj dwa pliki config.json obok siebie i prawie każde pole się zgadza: rozmiar ukryty 2048, rozmiar pośredni 6144, aktywacja SiLU, 32 głowy uwagi na 8 głów KV przy wymiarze głowy 64, pięć warstw pełnej uwagi, rozmiar bloku 9, enable_confidence_head: true, zwykła głowa Markowa rzędu 256. Liczba parametrów jest identyczna, dlatego pliki safetensors zgadzają się bajt po bajcie.

Trzy pola się różnią, a każde z nich odgrywa kluczową rolę.

• Zaczepy warstw docelowych — model szkicujący 8B odczytuje stany ukryte z warstw 2, 6, 10, 14 i 18 docelowego modelu o 24 warstwach; model szkicujący 24B odczytuje warstwy 2, 10, 18, 26 i 34 docelowego modelu o 40 warstwach. To jest pole, które sprawia, że pliki nie są wymienne.

Maksymalna liczba pozycji — 128 000 dla modelu draftującego 8B w porównaniu z 131 072 dla modelu 24B, zgodnie z oknami kontekstu ich modeli docelowych.

• RoPE theta — 5 000 000 kontra 10 000 000, ustalane przez kodowanie pozycyjne modelu docelowego, a nie przez cokolwiek związanego z modelem szkicującym.

Ta ostatnia para jest najwyraźniejszym dowodem na to, że te punkty kontrolne były trenowane osobno dla każdego modelu docelowego, a nie skalowane ze wspólnej bazy. Drafter nie ma niezależnej tożsamości: jego rozkład wejściowy odpowiada temu, jak wyglądają stany ukryte modelu docelowego, a te zmieniają się wraz ze zmianą architektury i treningu modelu docelowego. Skieruj drafter 8B na model 24B, a same indeksy warstw sprawią, że stanie się bezsensowny; nawet gdyby się zgadzały, logity, których przewidywania go uczono, nie byłyby takie same.

Co tak naprawdę przyspiesza każdy z nich

Cele różnią się bardziej, niż sugeruje nazewnictwo „8B versus 24B”, a różnica przebiega w odwrotnym kierunku dla każdego, kto zakłada, że większy model to cięższe obciążenie na urządzeniu.

• Parametry łączne i aktywne — LFM2.5-8B-A1B ma łącznie 8,3 mld parametrów, z czego 1,5 mld aktywnych na token; LFM2.5-24B-A2B ma łącznie 24,0 mld parametrów, z czego 2,45 mld aktywnych.

• Głębokość — 24 warstwy (18 konwolucji bramkowanych plus 6 GQA) w porównaniu z 40 warstwami (30 konwolucji plus 10 GQA).

• Kontekst — 128 000 tokenów wobec 131 072.

• Budżet treningowy — 38 bln tokenów wobec 36 bln, więc mniejszy model nie był niedotrenowany względem większego.

• Routing — model 8B wykorzystuje MoE z 64 ekspertami i routingiem top-4, tak jak model 24B, więc oba ponoszą karę za aktywację ekspertów, która szkodzi weryfikacji.

Oba są modelami rozumującymi, które myślą przed udzieleniem odpowiedzi, co ma tu większe znaczenie niż liczba parametrów. Największą słabością dekodowania spekulatywnego są długie, nieograniczone dane wyjściowe, a łańcuch myśli jest dokładnie czymś takim. Tabele dostawcy to pokazują: wiersze z najwyższym odsetkiem akceptacji w obu wydaniach dotyczą benchmarków krótkich odpowiedzi, takich jak MBPP i MT-Bench, a najniższe te, w których model musi wymyślić długą ścieżkę rozwiązania.

Prawdziwą różnicą jest luka dowodowa.

W tym miejscu oba wydania przestają być porównywalne. Drafter 8B został udostępniony 20.08.2026 w ramach zapowiedzi całej rodziny, wraz z pomiarami na dwóch bardzo różnych maszynach: pojedynczym H100 80 GB w BF16 przez SGLang oraz MacBooku Pro M4 Max uruchamiającym wagi FP16 GGUF przez llama.cpp z eksperymentalnymi jądrami Metal. Uzyskał średnio 2,54× na H100, ze szczytem 3,18× na MATH-500, i zaledwie 1,18× na MacBooku — od 90 do 106 tokenów na sekundę, uśrednione w pięciu zbiorach danych.

Drafter 24B ma tylko jeden wiersz sprzętowy: pojedynczy NVIDIA B300 z modelem docelowym FP8, pamięcią podręczną KV w BF16 i temperaturą 0. Osiąga średnio 2,38× przy współbieżności 1, 2,69× przy współbieżności 32 i 1,71× przy współbieżności 256 na ośmiu zestawach danych, ze szczytem 3,28× na MBPP przy współbieżności 32. Nie ma wiersza dla Maca, wiersza dla H100 ani wpisu ogłoszeniowego wyjaśniającego to pominięcie.

W przypadku modelu, którego cała oferta opiera się na agentach działających na urządzeniu — wpis premierowy Liquid o modelu 24B zaczyna się od 184 tokenów na sekundę na Apple M5 Max — brakująca liczba dla MacBooka jest najistotniejszym pustym miejscem w tym ogłoszeniu. Wynik dla 8B wyjaśnia, dlaczego może być ona niewielka: weryfikacja bloku tokenów aktywuje więcej ekspertów niż dekodowanie jednego, więc cel typu MoE przenosi więcej wag na każdy zaakceptowany token. A sama akceptacja nie jest wyznacznikiem: model draftujący 8B uzyskiwał w rzeczywistości średnio więcej zaakceptowanych tokenów na krok, niż podaje karta modelu 24B (6,95 na pięciu zbiorach danych wobec 5,16 na ośmiu), a mimo to dawał tylko 1,18× na MacBooku. To jest wniosek, który warto zapamiętać — w przypadku 8B wysoka akceptacja nie uratowała przepustowości na urządzeniu. Zakładanie, że 24B zachowuje się inaczej, to zakład bez liczby na poparcie.

Zestawiając obie tabele ze sobą

Główne proporcje nie są porównywalne jak jabłka do jabłek i nie należy ich od siebie odejmować. Inny GPU, inna docelowa precyzja, inne zestawy danych, inne serie testów współbieżności. Ale dwa wzorce przetrwały tę niezgodność.

Po pierwsze, pułap jest podobny. Najlepsza komórka H100 dla 8B wyniosła 3.18× na MATH-500 przy rozmiarze partii 1; najlepsza komórka B300 dla 24B to 3.28× na MBPP przy współbieżności 32. Modele szkicujące tej konstrukcji mieszczą się w tym samym przedziale 1.5×–3.3× niezależnie od tego, któremu celowi służą, czego właśnie można oczekiwać, gdy architektura modelu szkicującego pozostaje stała, a zmieniają się tylko wagi.

Po drugie, i bardziej użytecznie, dolna granica jest tym, gdzie cele się rozchodzą. Najsłabszą komórką H100 modelu 8B było GSM8K przy 1,29×; najsłabszą komórką B300 modelu 24B przy współbieżności 256 było LiveCodeBench przy 1,34× i AIME przy 1,36×. Żadne wydanie nie daje przypadku, w którym spekulacja jest darmowa, a oba dają przypadki, w których ledwie jest warta pamięci.

Między obiema kartami jest też zmiana w dokumentacji, którą łatwo przeoczyć i którą warto zaznaczyć. Materiał z sierpnia mówił, że wynik przy dekodowaniu zachłannym jest identyczny z wynikiem bazowym „z założenia”; karta 8B obiecuje „dokładnie takie same wyniki”. Karta 24B zamiast tego ostrzega, że różnice zmiennoprzecinkowe między weryfikacją wsadową a zwykłym dekodowaniem mogą dawać inny tekst, także przy próbkowaniu zachłannym. Późniejsza karta jest ostrożniejsza i jeśli w CI uruchamiasz porównania różnic w wynikach na poziomie bajtów, obie warto traktować jako potencjalnie nieidentyczne, zamiast ufać starszej obietnicy.

To, który z nich jest dla Ciebie odpowiedni, zależy od Twojego celu, a nie od budżetu.

Nie ma scenariusza, w którym zespół wybiera jeden z nich zamiast drugiego, kierując się samymi zaletami. Uruchamiasz model 24B, ponieważ potrzebujesz możliwości modelu 24B na maszynie, która go pomieści — 14,5 GB przy Q4_K_M w GGUF albo pojedyncza B300 w konfiguracji serwowania FP8. Uruchamiasz model 8B, ponieważ 8,3B parametrów łącznie, z czego 1,5B aktywnych, to to, co mieści się w urządzeniu brzegowym lub laptopie, a model draftujący odzyskuje część szybkości dekodowania, z której zrezygnowałeś, przechodząc na mniejszy model. Model draftujący jest dodatkiem do tej pierwszej decyzji, a decyzja niemal zawsze zapada na podstawie pamięci i jakości na długo, zanim spekulacja w ogóle pojawi się w rozmowie.

Jedynym przypadkiem, w którym wybór jest nadal otwarty, jest ocena. Jeśli testujesz, czy DSpark w ogóle warto wdrożyć w swoim stosie, konfiguracja z 8B jest tańszym eksperymentem: mieści się na jednym H100, ma wyniki dla Maca, które możesz porównać z własnym laptopem, a jej tryb awarii na urządzeniu został już udokumentowany przez dostawcę. Konfiguracja z 24B to ciekawszy eksperyment produkcyjny i ten słabiej udokumentowany.

W obu przypadkach liczbą, która decyduje o wyniku, jest licznik akceptacji, a nie tabela dostawcy. SGLang udostępnia współczynnik akceptacji dekodowania spekulatywnego dla każdego żądania; llama.cpp raportuje draft_n i draft_n_accepted w czasach poszczególnych odpowiedzi. Uruchom własne prompty przez dziesięć minut i podziel. Jeśli akceptacja oscyluje wokół średniej dla karty, drafter się opłaca; jeśli znajduje się na dolnym krańcu, kupujesz przebiegi weryfikacji i należy go odłączyć — a ten wniosek utrzyma się w obu punktach kontrolnych, ponieważ mechanizm jest ten sam.

Żaden z tych checkpointów nie jest modelem, który możesz wywołać.

To jest ten fragment, który zaskakuje ludzi natrafiających na te nazwy w katalogu modeli i zakładających, że to opcje na liście do wyboru. To nie są punkty końcowe. Żaden z modeli typu drafter nie ma ceny za milion tokenów, żaden nie widnieje w ofercie API i żaden nigdy nie będzie celem routingu platformy udostępniającej modele — ponieważ właściwe sparowanie to konfiguracja po stronie serwera, a nie parametr żądania.

Liquid AI sprzedaje sam model docelowy 24B po $0.10 za milion tokenów wejściowych, $0.05 za tokeny z pamięci podręcznej i $1.00 za milion tokenów wyjściowych, a wszelkie domysły dotyczące tego, co stoi za tą ceną, są niewidoczne dla wywołującego. Taki jest obecnie zwykły kształt rynku: interesująca inżynieria dzieje się wewnątrz stosu obsługi, a do dewelopera dociera stawka i liczba tokenów na sekundę. Platformy routingu zasługują na swoje miejsce w porównaniu ponad tą warstwą — stawiając kandydata obok modeli, które musi pokonać. OrcaRouter prowadzi jeden endpoint wśród ponad 200 modeli przy 0% marży względem ceny katalogowej dostawcy, więc gdy stawka dostawcy się zmienia, widoczna stawka zmienia się tego samego dnia, a przełączanie awaryjne chroni model kandydujący przed staniem się pojedynczym punktem awarii podczas jego oceny. Rodzina LFM2.5 nie należy dziś do nich, więc samodzielnie hostowany model 8B lub 24B z dołączonym drafterem pozostaje wdrożeniem lokalnym; modele warte przetestowania przeciwko niemu — Qwen3.6-35B-A3B po stronie agentowej, Gemma 4 26B-A4B po stronie wydajności — to te, które routujemy.

Co ustalił rok premier DSpark

Rodzina obejmuje teraz cztery modele docelowe tekstowe i jeden wizyjny, od 1,2B do 24B, a wszystkie dzielą jeden przepis na draftera: około 300M parametrów, pięć warstw uwagi, blok 9, trenowany na własnych stanach ukrytych modelu docelowego. To właśnie ta spójność jest właściwym odkryciem. Liquid zamienił dekodowanie spekulatywne z projektu badawczego prowadzonego osobno dla każdego modelu w etap produkcji — ten sam drafter, przekierowany, wdrażany w ciągu dni od pojawienia się każdego nowego modelu. Czy warto go wdrożyć na swoim sprzęcie, to pytanie o Twój ruch, a odpowiedź różni się w zależności od obciążenia znacznie bardziej niż w zależności od tego, który z tych dwóch plików pobierzesz.

To, co wydanie 24B wnosi do tego obrazu, nie jest lepszym współczynnikiem. To pierwszy raz, gdy drafter trafił na rynek bez towarzyszącego mu opisu — i pierwszy raz, gdy karta samego dostawcy mówi wprost, że wyniki mogą jednak nie być bitowo identyczne.