LFM2.5-2.6B-DSpark: Das 328M-Draft-Modell, das Liquids On-Device-Agenten 2,3× schneller laufen lässt

Niemand außerhalb von Liquid AI hat LFM2.5-2.6B-DSpark auf eigener Hardware ausgeführt und bisher eine Zahl veröffentlicht. Das ist der ehrliche Ausgangspunkt für dieses Modell, denn das Ganze ist eine Leistungsbehauptung: Es ist kein besseres 2.6B-Modell, sondern ein 328-Millionen-Parameter-Entwurfsmodell, das vor dem 2.6B-agentischen Modell LFM2.5-2.6B sitzt und Tokens vorschlägt, die es verifizieren soll, sodass der Agent etwa doppelt so schnell läuft, ohne seine Ausgabe zu verändern.

LFM2.5-2.6B-DSpark wurde am 20. August 2026 mit einem technischen Artikel auf Hugging Face und einem Begleitpost im eigenen Blog von Liquid veröffentlicht und ist das Flaggschiff einer kleinen Familie von Drafter-Checkpoints für spekulative Dekodierung, die Liquid an diesem Tag veröffentlichte. Alles, was unten in der Geschwindigkeitsspalte steht, wurde vom Anbieter gemessen und ist noch nicht unabhängig bestätigt; alles im Repository, die Formate und die Framework-Unterstützung sind einfach dazu da, überprüft zu werden.

Was DSpark ist, in einem Atemzug

Spekulative Dekodierung ist der Trick, ein günstiges Entwurfsmodell vor dem eigentlichen Modell laufen zu lassen: Das Entwurfsmodell rät die nächsten paar Tokens, das Zielmodell prüft den gesamten Batch in einem einzigen Vorwärtsdurchlauf und behält die Tokens, mit denen es übereinstimmt. Wenn die Vorhersagen richtig sind, bewegt man mehrere Tokens zum Preis von einem, sodass der Durchsatz steigt, ohne die Gewichte des Zielmodells anzutasten. DSpark — die Technik, ursprünglich von DeepSeek-Forschern im Juli 2026 vorgeschlagen und bereits in DeepSeek-V4 im Einsatz — ist eine Version dieses Tricks, die für kleine On-Device-Modelle optimiert ist. Liquid nennt es konfidenzgesteuerte spekulative Dekodierung, und sie hat drei Komponenten: ein paralleler Backbone, der in einem Durchlauf versteckte Zustände für alle Entwurfs-Tokens erzeugt, ein leichter sequenzieller Kopf, der die Abhängigkeit zwischen benachbarten Tokens modelliert, damit die Akzeptanzrate spät im Block nicht zusammenbricht, und ein Verifizierer, der Suffixe mit geringer Konfidenz beschneidet, wenn deren Prüfung mehr kosten würde, als sie einspart.

Genau dieser letzte Aspekt macht DSpark anders als ein einfacher Drafter: Es schiebt nicht immer einen vollständigen Block durch die Verifikation. Wenn die eigene Konfidenz des Drafts anzeigt, dass ein Suffix wahrscheinlich nicht akzeptiert wird, bricht es den Block vorzeitig ab und spart die verschwendete Rechenarbeit. Der Draft-Block besteht aus neun Tokens, daher verifiziert das Zielmodell bis zu zehn auf einmal.

Der Zeichner, in Zahlen

Der LFM2.5-2.6B-DSpark-Checkpoint ist ein reines Attention-Draft-Modell mit 0,3 Mrd. Parametern: fünf vollständige Attention-Schichten (Hidden-Size 2.048, Grouped-Query-Attention mit 32 Heads und 8 Key-Value-Heads), ein Vokabular mit 128K Tokens, ein Markov-Head mit Rang 256 und ein Confidence-Head. Liquid trainierte es 15 Epochen lang auf einer Mischung aus Instruktions-, Konversations-, Code- und Function-Calling-Daten – auf AMD-Hardware – und wählte die Epoche anhand der höchsten Akzeptanzrate statt des geringsten Verlusts aus.

Diese Akzeptanzrate ist die Zahl, die darüber entscheidet, wie viel der Drafter wert ist. Über fünf Benchmarks hinweg erreichte LFM2.5-2.6B-DSpark bei einer Batchgröße von 1 und einer Temperatur von 0 durchschnittlich 4.83 akzeptierte Token pro Dekodierungsschritt auf einer H100 und 4.42 auf einem M4 Max — etwa die Hälfte des Blocks wurde akzeptiert, und genau daher kommen die zweifachen Beschleunigungen.

Die Beschleunigungen, beschriftet

Alle folgenden Zahlen stammen aus Liquid AIs eigenen Messungen — SGLang auf einer einzelnen H100 80GB in BF16 und llama.cpp mit dem Metal-Backend auf einem M4 Max MacBook Pro in FP16 GGUF, Batch-Größe 1, Temperatur 0 — und wurden zum Zeitpunkt dieses Schreibens von keiner unabhängigen Partei reproduziert:

• H100 im Mittel — 2,67×, von 323 auf 864 Token/s. Nach Benchmark: MATH500 3,06×, HumanEval 2,56×, MBPP 2,64×, GSM8K 2,22×, MT-Bench 2,87×.

• M4 Max Mittelwert — 2,27×, von 61 auf 139 Token/s. Nach Benchmark: MATH500 2,25×, HumanEval 2,63×, MBPP 2,11×, GSM8K 2,36×, MT-Bench 1,99×.

• Tool calling — in Szenarien mit mehreren Tool-Funktionsaufrufen sank die durchschnittliche Latenz um 57%.

• Familienkontext — der größte Drafter der Familie, LFM2.5-8B-A1B-DSpark, erreichte bis zu 3.18× auf H100 und der 1.2B-Drafter bis zu 2.87× auf M4 Max; die 2.6B-Zahlen oben sind das Mittelfeld.

Zwei Dinge an diesen Zahlen sind über die Durchschnittswerte hinaus von Bedeutung. Erstens werden sie bei Temperatur 0 und Batchgröße 1 gemessen – der Konfiguration, die Spekulation begünstigt und die für interaktive On-Device-Agent-Arbeit meistens gilt. Die Identitätsgarantie gilt auch dort: Spekulative Dekodierung verifiziert jeden vorgeschlagenen Token, sodass der ausgegebene Text bei Greedy-Dekodierung exakt dem entspricht, was das Ziel allein produziert hätte. Zweitens schließt sich die Lücke, wenn die Nebenläufigkeit steigt: Auf einer einzelnen H100 berichtet Liquid, dass sich der Vorteil von DSpark bei einer Batchgröße von etwa 128 angleicht – der Drafter ist also ein Latenzgewinn für interaktive und tool-lastige Arbeitslasten, aber kein Allheilmittel für den Rohdurchsatz eines voll ausgelasteten Servers.

Was ist bestätigt, und was nicht

Bestätigt, in dem Sinne, dass das Repository öffentlich und überprüfbar ist: Der Drafter wird als Safetensors (BF16) und GGUF ausgeliefert; er paart sich mit dem nachtrainierten LFM2.5-2.6B, nicht mit dem Basis-Modell; Day-one-Support wurde upstream in llama.cpp (mit experimentellen Metal-Kernels) und in SGLang integriert; er ist unter Liquid's LFM Open License v1.0 lizenziert; und — wichtig für alle, die damit planen — die Modellkarte besagt, dass kein Inferenz-Provider ihn anbietet, es also eine Komponente ist, die man selbst ausführen muss.

Noch nicht bestätigt: dass sich die Beschleunigungen auf anderer Hardware und anderen Konfigurationen reproduzieren lassen (niemand außerhalb von Liquid hat eine Messung veröffentlicht), wie sich der Drafter beim Sampling statt beim Greedy-Decoding verhält, und ob die 57%-Angabe zur Tool-Call-Latenz auch in echten Agent-Harnesses über die Benchmark-Harness hinaus Bestand hat, die Liquid verwendet hat. Nichts davon sind Anschuldigungen – das Release ist einen Tag alt – aber sie sind der Unterschied zwischen einer vielversprechenden Zahl und einer verifizierten.

Es ausführen.

Bei SGLang verwenden Sie einen Build mit DSpark-Unterstützung, starten den Server gegen das Zielmodell und benennen den Drafter: Der spekulative Algorithmus ist DSPARK, der Draft-Modellpfad zeigt auf LiquidAI/LFM2.5-2.6B-DSpark, und die Blockgröße wird aus der config.json des Drafts gelesen. Bei llama.cpp laden Sie das Ziel-GGUF mit dem Draft-GGUF als Draft-Modell und setzen den Spek-Typ auf draft-dspark, wobei die Blockgröße aus den Sidecar-Metadaten gelesen wird. Beide Integrationen wurden upstream aufgenommen, daher sind keine Forks erforderlich — es genügt ein Build, das neu genug ist, um sie zu enthalten.

Wann es sich lohnt, etwas hinzuzufügen

LFM2.5-2.6B-DSpark rechtfertigt seinen zusätzlichen Speicherbedarf von etwa 0.3GB, wenn man den 2.6B-Agenten tatsächlich dort einsetzt, wo Liquid ihn platziert haben möchte – auf einem Telefon, einem Laptop oder einem Edge-Gerät – für interaktive oder Tool-Calling-Workloads, die latenzgebunden sind und im Greedy-Modus laufen. Genau in diesem Profil entfalten der 2.27×-On-Device-Wert und die um 57% reduzierte Tool-Call-Latenz ihre Wirkung. Weniger interessant ist dies, wenn man auf einem Server mit hoher Batch-Größe serviert (der Speedup nähert sich 1× an) oder wenn die Workload mit einer Temperatur über Null läuft, da die angegebenen Zahlen dann nicht mehr gelten. Und wenn man die 8B-A1B-Variante der Familie verwendet, ist der Grenzfall zu beachten: Ihr On-Device-Speedup liegt derzeit nur bei etwa 1.18×, weil die Verifizierung der Draft-Tokens im Metal-Backend von llama.cpp mehr Experten aktiviert – Liquid kennzeichnet dies als bekannt.

DSpark ändert nichts daran, wo der 2.6B-Agent läuft — es ist von Grund auf eine Self-Host-Geschichte und wird neben den gehosteten Modellen stehen, die Sie bereits aufrufen. Diese Mischung aus einem lokalen Drafter und einem Dutzend API-Endpunkten ist genau die Art von Verkabelung, die eine Routing-Schicht bündeln soll: ein API-Schlüssel für über 200 Modelle, automatisches Failover, wenn ein Anbieter nachlässt, und Listenpreise der Anbieter ohne Aufschlag, damit der Kostenvergleich zwischen lokal und gehostet für einen Agenten der 2.6B-Klasse nachvollziehbar bleibt, statt in einer Tabellenkalkulation zu leben.

Der richtige Weg, LFM2.5-2.6B-DSpark heute zu betrachten, ist als eine vielversprechende, vom Anbieter gemessene, noch nicht unabhängig verifizierte Geschwindigkeitsangabe, die an einem echten, herunterladbaren, ausführbaren Checkpoint hängt. Wenn Sie den 2.6B-Agenten auf dem Gerät einsetzen, ist der Drafter günstig auszuprobieren und leicht zu entfernen — fügen Sie die beiden spekulativen Flags zum SGLang-Befehl hinzu, behalten Sie Greedy-Decoding bei und messen Sie anhand Ihrer eigenen Workload, bevor Sie der 2,3× vertrauen. Das Repo ist vorhanden; die unabhängige Verifikation ist der offene Punkt.