LFM2.5-24B-A2B-DSpark vs. LFM2.5-8B-A1B-DSpark: Dieselbe 328M-Datei, zwei ganz unterschiedliche Wetten

Laden Sie eine der beiden Dateien herunter, und Sie erhalten 655.421.522 Byte. LFM2.5-24B-A2B-DSpark und LFM2.5-8B-A1B-DSpark sind bis auf das Byte gleich groß, teilen sich ein Backbone mit fünf Schichten, denselben Markov-Head mit Rang 256, dieselbe Blockgröße von 9 und dasselbe Vokabular mit 128.000 Tokens – und keines von beiden kann auch nur einen einzigen Prompt beantworten, denn beide sind Speculative-Decoding-Drafter, die einzig und allein dazu existieren, Tokens für ein Zielmodell zu raten. Was sie voneinander trennt, ist nicht ihre eigene Spezifikation. Es ist die Frage, gegen welches Ziel sie trainiert wurden und wie viel Belege dafür vorliegen, dass der Trick darauf funktioniert. Das eine hat veröffentlichte GPU- und MacBook-Messungen aus einem Launch-Post; das andere hat eine GPU-Tabelle und keine Ankündigung. Die Wahl zwischen ihnen ist daher überhaupt kein Modellvergleich – sie ist der Vergleich zweier Wetten, und nur eine davon wurde eingelöst. Die dokumentierten KI-Fehlfunktionen und Agent-Vorfälle hinter Releases wie diesem sind im OrcaRouter AI Incident Archive gesammelt, wo jeder Eintrag seine eigenen Quellen, seinen Schweregrad, seine Konfidenzstufe und ein Flag für strittige Fälle mitführt.

Die Dateien sind Zwillinge; die Jobs nicht.

Lies die beiden config.json Dateien nebeneinander und fast jedes Feld stimmt überein: Hidden-Size 2.048, Intermediate-Size 6.144, SiLU-Aktivierung, 32 Attention-Heads über 8 KV-Heads bei Head-Dimension 64, fünf Full-Attention-Schichten, Blockgröße 9, enable_confidence_head: true, ein einfacher Markov-Head vom Rang 256. Die Parameteranzahl ist identisch, weshalb die safetensors-Dateien Byte für Byte übereinstimmen.

Drei Felder unterscheiden sich, und jedes einzelne ist tragend.

• Taps auf Zielschichten — der 8B-Drafter liest Hidden States aus den Schichten 2, 6, 10, 14 und 18 eines 24-Schichten-Zielmodells; der 24B-Drafter liest die Schichten 2, 10, 18, 26 und 34 eines 40-Schichten-Zielmodells. Dies ist das Feld, das die Dateien nicht austauschbar macht.

• Maximale Positionen — 128.000 für den 8B-Drafter gegenüber 131.072 für den 24B, entsprechend den Kontextfenstern ihrer Zielmodelle.

• RoPE-Theta – 5.000.000 gegenüber 10.000.000, festgelegt durch die Positionskodierung des Zielmodells statt durch irgendetwas am Drafter.

Dieses letzte Paar ist der klarste Beweis dafür, dass diese Checkpoints pro Ziel trainiert und nicht aus einer gemeinsamen Basis skaliert wurden. Der Drafter hat keine eigenständige Identität: Seine Eingabeverteilung entspricht dem, wie die Hidden States des Ziels aussehen, und diese ändern sich, wenn sich Architektur und Training des Ziels ändern. Richtet man den 8B-Drafter auf das 24B-Modell, machen ihn allein die Layer-Indizes zu Unsinn; selbst wenn sie übereinstimmten, würden die Logits, die vorherzusagen er trainiert wurde, es nicht tun.

Was jede einzelne tatsächlich beschleunigt

Die Zielsysteme unterscheiden sich stärker, als die Bezeichnung „8B versus 24B“ nahelegt, und der Unterschied verhält sich genau umgekehrt für alle, die davon ausgehen, dass das größere Modell auf dem Gerät der schwerere Brocken ist.

• Gesamt- und aktive Parameter — LFM2.5-8B-A1B umfasst insgesamt 8,3 Mrd. Parameter mit 1,5 Mrd. aktiven pro Token; LFM2.5-24B-A2B umfasst insgesamt 24,0 Mrd. Parameter mit 2,45 Mrd. aktiven.

• Tiefe — 24 Schichten (18 gated Convolutions plus 6 GQA) gegenüber 40 Schichten (30 Convolutions plus 10 GQA).

• Kontext — 128.000 Token gegenüber 131.072.

• Trainingsbudget — 38T Token gegenüber 36T, das kleinere Modell war also im Verhältnis zum größeren nicht untertrainiert.

• Routing – das 8B nutzt ein 64-Experten-MoE mit Top-4-Routing, genau wie das 24B, daher tragen beide die Mehrkosten der Expertenaktivierung, die die Verifikation beeinträchtigen.

Beide sind Reasoning-Modelle, die vor der Antwort nachdenken, was hier mehr zählt als die Parameterzahlen. Die größte Schwäche der spekulativen Dekodierung sind lange, uneingeschränkte Ausgaben, und eine Gedankenkette ist genau das. Die Anbietertabellen zeigen es: Die Zeilen mit der höchsten Akzeptanz in beiden Veröffentlichungen sind Benchmarks mit kurzen Antworten wie MBPP und MT-Bench, und die niedrigsten sind diejenigen, bei denen das Modell einen langen Lösungsweg erfinden muss.

Die Evidenzlücke ist der eigentliche Unterschied

Hier sind die beiden Releases nicht mehr vergleichbar. Der 8B-Drafter wurde am 20.08.2026 im Rahmen einer vollständigen Familienankündigung veröffentlicht, mit Messungen auf zwei sehr unterschiedlichen Maschinen: einer einzelnen H100 mit 80 GB in BF16 über SGLang und einem M4 Max MacBook Pro, der FP16-GGUF-Gewichte über llama.cpp mit experimentellen Metal-Kernels ausführt. Er erreichte im Durchschnitt das 2,54-Fache auf der H100 mit einem Spitzenwert vom 3,18-Fachen bei MATH-500 und nur das 1,18-Fache auf dem MacBook — 90 bis 106 Tokens pro Sekunde, gemittelt über fünf Datensätze.

Der 24B-Drafter hat eine einzige Hardware-Zeile: ein einzelner NVIDIA B300 mit FP8-Ziel, BF16-KV-Cache, Temperatur 0. Er erreicht im Durchschnitt 2,38× bei Parallelität 1, 2,69× bei Parallelität 32 und 1,71× bei Parallelität 256 über acht Datensätze, mit einem Spitzenwert von 3,28× bei MBPP und Parallelität 32. Es gibt keine Mac-Zeile, keine H100-Zeile und keinen Ankündigungsbeitrag, der das Fehlen erklärt.

Für das Modell, dessen ganzes Werbeversprechen auf On-Device-Agenten beruht, ist die fehlende MacBook-Zahl – Liquids Ankündigungspost zum 24B stellt 184 Tokens pro Sekunde auf einem Apple M5 Max voran – die mit Abstand folgenreichste Leerstelle der Veröffentlichung. Das 8B-Ergebnis zeigt, warum sie klein ausfallen könnte: Das Verifizieren eines Token-Blocks aktiviert mehr Experten als das Dekodieren eines einzelnen, ein MoE-Zielmodell bewegt also pro akzeptiertem Token mehr Gewicht. Und die Akzeptanz allein ist nicht der Prädiktor: Der 8B-Drafter erzielte tatsächlich im Schnitt mehr akzeptierte Tokens pro Schritt als das Datenblatt des 24B ausweist (6,95 über fünf Datensätze gegenüber 5,16 über acht) und lieferte auf einem MacBook dennoch nur 1,18×. Das ist der Punkt, den es festzuhalten gilt – beim 8B rettete eine starke Akzeptanz den On-Device-Durchsatz nicht. Davon auszugehen, dass sich das 24B anders verhält, ist eine Wette ohne Zahl dahinter.

Die beiden Tabellen gegeneinander lesen

Die Verhältnisse in den Schlagzeilen sind nicht direkt vergleichbar und sollten nicht voneinander subtrahiert werden. Andere GPU, andere Zielpräzision, andere Datensatz-Sets, andere Parallelitäts-Sweeps. Doch zwei Muster überstehen die Diskrepanz.

Zunächst ist die Obergrenze ähnlich. Die beste H100-Zelle des 8B lag bei Batchgröße 1 bei 3,18× auf MATH-500; die beste B300-Zelle des 24B liegt bei Parallelität 32 bei 3,28× auf MBPP. Drafter dieses Designs landen unabhängig davon, welches Ziel sie bedienen, im selben Band von 1,5×–3,3×, was man erwarten würde, wenn die Drafter-Architektur festgehalten wird und sich nur die Gewichte ändern.

Zweitens, und das ist nützlicher: Am unteren Ende unterscheiden sich die Targets. Die schwächste H100-Zelle des 8B war GSM8K mit 1,29×; die schwächste B300-Zelle des 24B bei Parallelität 256 war LiveCodeBench mit 1,34× und AIME mit 1,36×. Keine der beiden Versionen erzeugt einen Fall, in dem Spekulation kostenlos ist, und beide erzeugen Fälle, in denen sie den Speicher kaum wert ist.

Außerdem gibt es zwischen den beiden Karten eine Dokumentationsänderung, die leicht zu übersehen ist und es wert ist, hervorgehoben zu werden. Das August-Material sagte, die Ausgabe unter Greedy-Decoding sei „konstruktionsbedingt“ identisch mit der Baseline; die 8B-Karte verspricht „exakt dieselben Ausgaben“. Die 24B-Karte warnt stattdessen, dass Gleitkommaunterschiede zwischen gebündelter Verifikation und einfacher Dekodierung unterschiedlichen Text erzeugen können, auch bei Greedy-Sampling. Die spätere Karte ist die vorsichtigere, und wenn Sie Byte-Level-Diffs der Ausgabe in CI ausführen, sollten beide als potenziell nicht identisch behandelt werden, statt dem älteren Versprechen zu vertrauen.

Welche Option für dich relevant ist, entscheidet dein Ziel, nicht dein Budget.

Es gibt kein Szenario, in dem ein Team das eine statt des anderen aufgrund seiner Leistungsmerkmale wählt. Man betreibt das 24B-Modell, weil man die Fähigkeiten eines 24B-Modells auf einer Maschine braucht, die es aufnehmen kann – 14,5 GB bei Q4_K_M in GGUF oder eine einzelne B300 für die FP8-Serving-Konfiguration. Man betreibt das 8B-Modell, weil 8,3B Gesamtparameter bei 1,5B aktiven Parametern das sind, was auf ein Edge-Gerät oder einen Laptop passt, und der Drafter einen Teil der Dekodiergeschwindigkeit zurückgewinnt, die man durch den Wechsel zum kleineren Modell aufgegeben hat. Der Drafter ist ein Zusatz zu dieser ersten Entscheidung, und die Entscheidung wird fast immer anhand von Speicher und Qualität getroffen, lange bevor Spekulation überhaupt Thema wird.

Der einzige Fall, in dem die Wahl tatsächlich zur Debatte steht, ist die Evaluierung. Wenn Sie testen, ob sich die Einführung von DSpark in Ihrem Stack überhaupt lohnt, ist die 8B-Kombination das günstigere Experiment: Sie passt auf eine H100, bietet Mac-Werte, die Sie mit Ihrem eigenen Laptop vergleichen können, und ihr Fehlermodus auf dem Gerät wurde bereits vom Anbieter dokumentiert. Die 24B-Kombination ist das interessantere Produktionsexperiment und das weniger dokumentierte.

Für beide entscheidet der Akzeptanzzähler über das Ergebnis, nicht die Anbietertabelle. SGLang gibt die Akzeptanz des spekulativen Dekodierens pro Anfrage an; llama.cpp meldet draft_n und draft_n_accepted in den Zeitmessungen pro Antwort. Führen Sie Ihre eigenen Prompts zehn Minuten lang aus und dividieren Sie. Liegt die Akzeptanz nahe am Mittelwert der Karte, lohnt sich der Drafter; liegt sie am unteren Ende, kaufen Sie Verifikationsdurchläufe und sollten ihn abkoppeln — und diese Schlussfolgerung gilt für beide Checkpoints, weil der Mechanismus derselbe ist.

Keiner der beiden Checkpoints ist ein Modell, das sich aufrufen lässt.

Das ist der Punkt, an dem Leute hängen bleiben, die diesen Namen in einem Modellkatalog begegnen und annehmen, es handele sich um Menüoptionen. Sie sind keine Endpunkte. Keiner der Drafter hat einen Preis pro Million Tokens, keiner erscheint in einem API-Listing, und keiner wird jemals von einer Plattform, die Modelle bereitstellt, angesteuert – denn die korrekte Paarung ist eine serverseitige Konfiguration, kein Anfrageparameter.

Liquid AI verkauft das 24B-Zielmodell selbst zu 0,10 $ pro Million Eingabe-Tokens, 0,05 $ für gecachte Tokens und 1,00 $ pro Million Ausgabe-Tokens, und etwaige Spekulation, die hinter diesem Preis läuft, ist für den Aufrufer unsichtbar. Das ist heute die übliche Marktform: Die interessante Engineering-Arbeit findet im Serving-Stack statt, und was einen Entwickler erreicht, sind ein Tarif und ein Tokens-pro-Sekunde-Wert. Routing-Plattformen verdienen ihren Platz beim Vergleich oberhalb dieser Ebene – einen Kandidaten neben die Modelle zu stellen, die er schlagen muss. OrcaRouter betreibt einen Endpunkt für mehr als 200 Modelle zu 0 % Aufschlag auf den Listenpreis des Anbieters, sodass sich der Tarif, den Sie sehen, am selben Tag ändert, wenn ein Anbieter seinen Preis ändert, und Failover verhindert, dass ein Kandidatenmodell zu einem Single Point of Failure wird, während Sie es evaluieren. Die LFM2.5-Familie ist heute nicht darunter, daher bleibt ein selbst gehostetes 8B- oder 24B-Modell mit angehängtem Drafter eine lokale Bereitstellung; die Modelle, gegen die es sich zu testen lohnt – Qwen3.6-35B-A3B auf der Agentic-Seite, Gemma 4 26B-A4B auf der Effizienzseite – sind diejenigen, die wir routen.

Was ein Jahr voller DSpark-Releases etabliert hat

Die Familie umfasst jetzt vier Textziele und ein Vision-Ziel, von 1,2B bis 24B, und alle teilen ein Drafter-Rezept: rund 300M Parameter, fünf Attention-Layer, Block 9, trainiert auf den eigenen Hidden States des jeweiligen Ziels. Diese Konsistenz ist der eigentliche Befund. Liquid hat spekulative Dekodierung von einem Forschungsprojekt pro Modell zu einem Fertigungsschritt gemacht – derselbe Drafter, neu ausgerichtet, innerhalb von Tagen nach jedem neuen Modell ausgeliefert. Ob sich dieser Schritt auf Ihrer Hardware lohnt, ist eine Frage Ihres Traffics, und die Antwort unterscheidet sich je nach Workload weit stärker als danach, welche dieser beiden Dateien Sie herunterladen.

Was das 24B-Release zu diesem Bild hinzufügt, ist kein besseres Verhältnis. Es ist das erste Mal, dass ein Drafter ohne die begleitende Dokumentation ausgeliefert wurde – und das erste Mal, dass die eigene Modellkarte des Anbieters Ihnen in klaren Worten mitteilt, dass die Ausgaben möglicherweise doch nicht bitidentisch sind.