LFM2.5-24B-A2B-DSpark ist live auf Hugging Face — Liquid AI hat es einfach noch nicht angekündigt

Die Model Card für Liquid AIs größtes Modell sagt weiterhin, sein Speculative-Decoding-Drafter sei demnächst verfügbar. Der Drafter kommt nicht. LFM2.5-24B-A2B-DSpark hat seit 2026-10-19 ein öffentliches Repository, einen 655 MB großen BF16-Checkpoint, eine vollständige Benchmark-Tabelle, ein GGUF-Sidecar, das am folgenden Abend veröffentlicht wurde, und Launch-Flags für SGLang, die in seine Card eingetragen wurden. Was ihm fehlt, ist eine Ankündigung. LFM2.5-24B-A2B, das 24B-Mixture-of-Experts-Modell, das es beschleunigen soll, bekam am 2026-10-13 einen Blogbeitrag, einen Launch mit Datum, eine Preisliste und einen Playground-Link. Sein Drafter bekam ein Repo und eine Model Card, und Liquid AIs eigene Dokumentationsseite für spekulatives Decoding listet weiterhin nur die Ziele 1.2B, 2.6B, 8B und VL-3B als unterstützt auf. Die dokumentierten KI-Ausfälle und Agent-Vorfälle hinter Releases wie diesem sind gesammelt in the OrcaRouter AI Incident Archive, wo jeder Eintrag eigene Quellen, einen Schweregrad, eine Konfidenzstufe und ein Disputed-Flag enthält.

Diese Lücke ist hier die eigentliche Geschichte, und es lohnt sich, genau zu sein, was sie bedeutet und was nicht. Ein Repository, dessen Gewichte offen sind, dessen Benchmarks sich aus einer CSV-Datei direkt neben dem Modell reproduzieren lassen und dessen Inferenzpfad bereits upstream zusammengeführt wurde, ist eine echte Veröffentlichung, kein Leak. Aber nichts davon wurde vom Anbieter in Prosa bestätigt, kein Dritter hat es gemessen, und die Zahlen in der Karte sind die Zahlen desselben Teams, gemessen auf derselben Hardware, die es ausgewählt hat. Dieser Artikel trennt beides: was das Repository belegt und was eine Behauptung bleibt.

Was ist eigentlich im Repository?

Der Checkpoint ist klein genug, dass die Dateiliste selbst informativ ist. Das Ganze ist eine einzige Datei model.safetensors mit 655.421.522 Bytes – 327,7 Mio. Parameter in BF16 – plus eine Konfiguration, eine Lizenz und ein Benchmark-Verzeichnis. Sonst nichts. Es gibt keinen Tokenizer, keine Embedding-Matrix und keinen LM-Head, denn die Architektur verwendet alle drei beim Laden aus dem Zielmodell wieder. Das ist das Design: Der Drafter muss immer nur wissen, wie er den nächsten Token-Block im Vokabular des Zielmodells errät, nicht, wie er die Welt repräsentiert.

Die Konfiguration bestätigt die Form, die der DSpark-Bericht vom August beschrieben hat. Fünf Full-Attention-Schichten mit Hidden Size 2.048 und Intermediate Size 6.144 mit SiLU/SwiGLU; Grouped-Query-Attention mit 32 Heads und 8 KV-Heads bei Head-Dimension 64; ein Markov-Head mit Rang 256 und ein separater Confidence-Head; Blockgröße 9; Vokabular 128.000; und ein maximales Positions-Embedding von 131.072, was genau dem Kontextfenster des Ziels entspricht. Das einzige Feld, das für diesen Drafter spezifisch ist, ist target_layer_ids: [2, 10, 18, 26, 34] gegenüber num_target_layers: 40 — die fünf Schichten des 24B-Modells, deren Hidden States der Drafter als Kontext liest. Diese Indizes sind der Grund, warum ein für ein LFM2.5-Modell trainierter Drafter nicht einfach auf ein anderes ausgerichtet werden kann.

Die Lizenz ist lfm1.0, dieselbe benutzerdefinierte Lizenz wie im Rest der Familie, was für alle erwähnenswert ist, die ein gebündeltes Target-plus-Drafter-Artefakt weitergeben wollen, statt es intern zu nutzen.

Die Benchmark-Tabelle, als Anbietertabelle gelesen

Die Karte veröffentlicht den Durchsatz für acht Datensätze bei Parallelität 1, 32 und 256 auf einer einzelnen NVIDIA B300 mit FP8-Ziel, einem BF16-KV-Cache und Temperatur 0. Jede unten aufgeführte Zahl stammt von Liquid AI selbst und wurde außerhalb des Unternehmens nicht reproduziert; die Rohdatenzeilen finden sich im Repo unter benchmarks/b300-fp8.csv, wenn Sie die Arithmetik selbst überprüfen möchten.

• Arithmetisches Mittel über die acht Datensätze — 2,38× bei Parallelität 1, 2,69× bei Parallelität 32, 1,71× bei Parallelität 256.

• Beste einzelne Zelle — MBPP bei Parallelität 32, 3,28×, dicht dahinter MATH-500 mit 3,04×.

• Schlechteste Einzelzelle – LiveCodeBench bei Nebenläufigkeit 256, 1,34×, und AIME bei 256, 1,36×.

• Akzeptierte Tokens pro Schritt — durchschnittlich 5,16, gegenüber einer Obergrenze von 10, die durch die Blockgröße plus das Bonus-Token des Ziels festgelegt wird.

• Höchste Akzeptanz — MBPP bei 6,70 Tokens pro Schritt; niedrigste — LiveCodeBench bei 4,02.

Zwei Dinge an dieser Tabelle sind interessanter als die Schlagzeile. Das erste ist, dass die mittlere Beschleunigung höher bei Nebenläufigkeit 32 als bei Nebenläufigkeit 1 ist — 2,69× gegenüber 2,38× —, was der üblichen Geschichte des spekulativen Decodings widerspricht, in der Batching den Vorteil auffrisst. Das zweite ist, dass sie bei 256 zusammenbricht. Bei 256 gleichzeitigen Anfragen erzeugt allein das Zielmodell auf dieser GPU für MATH-500 bereits rund 15.000 Tokens pro Sekunde, und der Beitrag des Drafters fällt auf 1,79×. Ein Serving-Team, das nur „2,4ד liest, würde einen Cluster falsch dimensionieren; die Zahl, die für einen gebündelten Endpoint zählt, ist die 1,71×, und selbst die ist eine B300-Zahl mit einem Nebenläufigkeitsprofil, das die meisten Bereitstellungen nicht erreichen werden.

Der Satz, der sich seit August geändert hat

Als Liquid AI am 20.08.2026 DSpark-Drafter für die Zielmodelle 1.2B, 2.6B und 8B-A1B veröffentlichte, erhob der Blogbeitrag einen starken Anspruch: Da das Zielmodell jedes vorgeschlagene Token verifiziert und Ablehnungen durch seine eigene Wahl ersetzt, „ist die ausgegebene Sequenz daher konstruktionsbedingt identisch mit Baseline-Greedy.“ Die Modellkarte des 8B-Drafters greift den Grundgedanken auf und verspricht „exakt dieselben Ausgaben.“

Die Karte des 24B-Drafters sagt das nicht. Sie besagt, dass das Zielmodell jedes vorgeschlagene Token verifiziert, und dann: „Gleitkommaunterschiede zwischen gebatchter Verifikation und einfacher Dekodierung können unterschiedlichen Text erzeugen, auch bei Greedy-Sampling.“ Sie fügt hinzu, dass die Messungen die Performance bewerten, nicht die Aufgaben genauigkeit.

Dies ist ein sorgfältiger formulierter Satz, und er ist der richtige. Die Batch-Verifikation führt nicht dieselben Gleitkommaoperationen in derselben Reihenfolge aus wie die sequenzielle Dekodierung, daher ist Bitidentität eine Annahme, die in exakter Arithmetik gilt und nicht immer auf echter Hardware. Die Tatsache, dass die neuere Karte dies angibt, während die ältere es nicht tat, ist entweder eine Dokumentationskorrektur oder eine Entdeckung während des Trainings dieses Drafters – das Repository verrät nicht, welche von beiden, und Liquid hat keine Erklärung veröffentlicht. Was das praktisch bedeutet, ist eng begrenzt, aber real: Wenn Ihre Regressionssuite die Modellausgabe Byte für Byte vergleicht, kann das Hinzufügen dieses Drafters sie fehlschlagen lassen, und das ist eine Eigenschaft der Arithmetik und kein Fehler im Draft.

Warum der Verfasser sechs Tage nach seinem eigenen Modell eintraf

Der Zeitablauf ist es wert, dargelegt zu werden, weil er das Schweigen besser erklärt als jede Spekulation über Strategie.

• 2026-08-20 — Liquid veröffentlicht die DSpark-Familie: Drafter für LFM2.5-1.2B-Instruct, LFM2.5-2.6B und LFM2.5-8B-A1B. Ein 24B-Zielmodell existiert noch nicht.

• 2026-08-31 — SGLang integriert PR #31041 und fügt Unterstützung für DSpark-Spekulativdekodierung mit LFM2 und LFM2-MoE hinzu. Der MoE-Pfad, den das 24B-Modell benötigt, landet hier – eineinhalb Monate bevor das Modell, dem er dienen wird, erscheint.

• 2026-10-13 — LFM2.5-24B-A2B erscheint mit einem Blogbeitrag und einem Preis. Am selben Tag wird PR #43939 in SGLang gemergt, wodurch der Server die LFM2-MoE-Konfiguration von Hugging Face direkt wiederverwenden kann.

• 2026-10-19 — das Repository LFM2.5-24B-A2B-DSpark erscheint, samt Gewichten und Benchmarks.

• 2026-10-20 — Das GGUF-Sidecar erscheint: eine einzelne 664-MB-F16-Datei für llama.cpp.

• 2026-10-21 — die Ziel-Modellkarte erhält eine Drafter-Zeile. Sie zeigt weiterhin Demnächst verfügbar.

Liest man diese Abfolge, ist die wahrscheinlichste Erklärung die langweilige. Die Infrastruktur war vor dem Artefakt da; das Artefakt war da, als das Training abgeschlossen war; die Ankündigung ist eine Marketingaufgabe, die noch nicht stattgefunden hat. Nichts im Repository deutet auf einen bewusst leisen Start hin – die Karte ist vollständig, die Benchmarks sind bis hin zum Protokoll dokumentiert, und die SGLang- und llama.cpp-Aufrufe sind vollständig ausgeschrieben. Leise bedeutet hier unangekündigt, nicht versteckt.

Was noch nicht zu wissen ist

Die ehrliche Grenze dieses Beitrags ist eine kurze Liste, und jeder Punkt ist eine echte Lücke und keine Formalität.

Keine unabhängige Messung. Es gibt keinen Eintrag bei Artificial Analysis, keinen Abnahmelauf durch Dritte, keine Reproduktion der Durchsatz-Tabelle. Stand 21.10.2026 verzeichnete das Repository sieben Downloads und einen Like. Jede Geschwindigkeitssteigerung in diesem Artikel stammt vom Anbieter, auf der vom Anbieter gewählten GPU und mit der vom Anbieter gewählten Zielpräzision.

Keine Ankündigung, also keine Einordnung. Wir wissen nicht, ob Liquid dies als Produktionsempfehlung für das 24B oder als Forschungsartefakt beabsichtigt. Der Ton der Karte – vollständige Launch-Flags, eine Familientabelle, ein Kontaktlink – deutet auf Ersteres hin, aber das ist eine Vermutung.

Kein Preis, weil es keinen geben kann. Ein Drafter ist kein bereitgestelltes Modell. Er hat keinen Preis pro Million Token und wird niemals als aufrufbarer Endpunkt in einem Modellkatalog erscheinen. Seine Kosten sind die 655 MB VRAM oder Unified Memory, die er neben dem Zielmodell belegt, plus der zusätzliche Rechenaufwand, einen Block statt eines Tokens zu verifizieren.

Keine Apple-Silicon-Zahlen. Dies ist die größte Lücke, und der nächste Abschnitt erklärt, warum sie wichtiger ist als die anderen.

Die fehlende Mac-Nummer ist die interessante Auslassung.

Das 24B-Modell wird als On-Device-Modell verkauft. Liquids Launch-Post führt mit 184 Tokens pro Sekunde auf einem Apple M5 Max und bezeichnet es als für schnelle, private Agenten auf dem Gerät gebaut. Die Model Card des Drafters hingegen nennt nur B300-Zahlen. Für den 8B-Drafter im August veröffentlichte Liquid sowohl H100- als auch M4-Max-Ergebnisse und war offen über die Lücke zwischen ihnen: Eine mittlere Beschleunigung von 2,54× auf einer H100 wurde auf einem MacBook zu 1,18×. Der genannte Grund war mechanisch — beim Verifizieren von k Tokens werden mehr Experten aktiviert als bei einem einzelnen Decode-Schritt, deshalb zahlt ein MoE-Ziel mehr Gewichtsdatenverkehr pro verifiziertem Token, und das Metal-Backend von llama.cpp machte das noch schlimmer.

LFM2.5-24B-A2B ist ebenfalls ein Mixture-of-Experts-Modell: 64 Experten pro Block mit Top-4-Routing. Derselbe Mechanismus greift, und das 24B ist ein größeres Modell mit einem größeren Expertenpool, der durchgeblättert werden muss. Das beweist nicht, dass der Geschwindigkeitsgewinn auf dem Gerät klein ist – der Drafter wurde speziell für dieses Ziel trainiert, und die Akzeptanzrate ist viel besser als die des 8B-Modells anfangs –, aber es bedeutet, dass genau die eine Zahl, die ein Laptop-Nutzer braucht, die eine Zahl ist, die auf der Karte nicht enthalten ist. Jede Annahme, dass sich das B300-Verhältnis auf einen Mac übertragen lässt, ist als unbestätigt zu behandeln.

Es ausführen – und das eine Flag, das dir zum Verhängnis wird

Auf der GPU ist die veröffentlichte Vorgehensweise SGLang mit dem FP8-Target und angehängtem Drafter, Blockgröße 9 und zehn Draft-Tokens. Das installierte SGLang muss neu genug sein, um den LFM2-MoE-DSpark-Pfad aus PR #31041 und die Konfigurationswiederverwendung aus PR #43939 zu enthalten; bei einem älteren Build erkennt der Server die Drafter-Architektur überhaupt nicht. Beachten Sie, dass die Benchmark-Zahlen das FP8-Target voraussetzen – das BF16-Target verhält sich anders und nicht unbedingt besser, da der Drafter auf eine bestimmte Verteilung der Target-Logits trainiert wurde.

Auf CPU und Apple Silicon ist der Weg llama.cpp mit dem F16-GGUF-Sidecar. Der Sidecar liest seine Blockgröße aus seinen eigenen Metadaten und begrenzt --spec-draft-n-max darauf, sodass eine Draft-Länge von 12 nicht 12 ergibt. Die Timings pro Antwort legen draft_n und draft_n_accepted offen, wobei Letzteres das Feld ist, das man bei der eigenen Workload im Auge behalten sollte: Wenn die Akzeptanz auf dem eigenen Traffic weit unter dem Mittelwert von 5,16 der Karte liegt, kostet der Drafter einen Forward-Pass und bringt wenig, und der ehrliche Schritt ist, ihn abzuhängen.

Was das bedeutet, wenn Sie diese Woche ein Modell auswählen

Für die meisten Teams ist die praktische Konsequenz gering, weil der Drafter die Geschwindigkeit ändert und nicht die Leistungsfähigkeit. LFM2.5-24B-A2B ist das, was Prompts beantwortet; der Drafter ändert nur, wie viele dieser Antworten Sie pro Sekunde erhalten. Wenn das 24B letzte Woche nicht auf Ihrer Shortlist stand, bringt eine schnellere Version davon es dort nicht hin.

Wenn es auf Ihrer Auswahlliste stand, stärkt der Drafter die Argumente für Self-Hosting und bringt für den API-Fall nichts. Diese Unterscheidung sollte man klar benennen: Ein Speculative-Decoding-Checkpoint ist für alle unsichtbar, die einen gehosteten Endpoint aufrufen, denn der Serving-Stack entscheidet, ob er ihn anhängt. Was Sie zu gleichen Bedingungen vergleichen können, ist das Modell selbst gegenüber den Alternativen, an die Sie sonst routen würden – und wenn Sie es gegen etwas wie Qwen3.6-35B-A3B, das Modell, gegen das Liquid bei fünf von acht agentischen Aufgaben benchmarkt, evaluieren, stellt OrcaRouter dieses Vergleichsziel hinter einem einzigen Schlüssel zu 0 % Aufschlag auf den Listenpreis des Anbieters, mit automatischem Failover zwischen Anbietern, bereit. Wir bieten die LFM2.5-Familie derzeit nicht an, daher muss das 24B selbst über die API des Herstellers oder Ihre eigenen GPUs kommen; was wir bieten, ist die andere Seite des Vergleichs ohne einen zweiten Vertrag.

Was würde dieses Bild verändern?

Drei Dinge, geordnet danach, wie stark sie die Story voranbringen würden. Ein Blogbeitrag von Liquid würde die Einordnung klären – ob dies eine empfohlene Produktionskombination oder ein Forschungsrelease ist. Eine veröffentlichte Mac-Messung würde die Behauptung klären, die für die Zielgruppe zählt, für die das 24B gebaut wurde. Und ein unabhängiger Abnahmelauf mit echtem Traffic, statt acht Benchmark-Datensätzen bei Temperatur 0, würde zeigen, ob 5,16 Tokens pro Schritt den Kontakt mit den unübersichtlichen, langen Tool-Calling-Prompts übersteht, für die dieses Modell tatsächlich verkauft wird.

Bis dahin ist das Repository öffentlich, die Gewichte sind herunterladbar, die CSV liegt direkt dort, und die Model Card des Anbieters selbst ist der letzte Ort, an dem man nach Neuigkeiten darüber suchen sollte. Das ist ein ungewöhnlicher Zustand für eine Veröffentlichung – aber er ist real, und das Artefakt wird nicht weniger real, weil niemand den Blogbeitrag geschrieben hat.