Am 20. August veröffentlichte Liquid AI auf Hugging Face eine Reihe von LFM2.5-DSpark-Entwurfsmodellen, die drei eigene Modelle mit spekulativem Decoding ausstatten: LFM2.5-1.2B-Instruct, 2.6B und 8B-A1B. Laut offiziellen Angaben beträgt die Beschleunigung bis zu 3,18-fach, die Ausgabe ist dabei identisch mit der des Originalmodells.
Die Idee hinter spekulativem Decoding ist nicht kompliziert: Ein kleines Modell rät zunächst die nächsten Wörter voraus, das große Modell rechnet nicht mehr Wort für Wort, sondern prüft die gesamte Kandidatenkette in einem einzigen Forward-Pass gebündelt. Stimmt die Vorhersage, wird sie direkt übernommen; liegt sie daneben, wird neu gerechnet. Die eingesparte Zeit steckt komplett im wiederholten Hin- und Herladen der Gewichte.
655 MB für die zwei- bis dreifache Geschwindigkeit
Die Entwurfsmodelle, die Liquid AI diesmal beilegt, sind allesamt sehr klein. Die 1.2B-Version arbeitet mit 295,7 Millionen Parametern, 2.6B und 8B-A1B teilen sich eine Version mit 327,7 Millionen Parametern. Die Architektur besteht aus 5 Schichten Full Attention, einer versteckten Dimension von 2048, einer Zwischenschicht von 6144, 32 Query-Köpfen, die sich 8 KV-Gruppen teilen, und schlägt pro Durchgang 9 Kandidatenwörter vor. Bei BF16-Präzision beträgt der VRAM-Bedarf 655 MB.
Grob überschlagen auf einem Mac mit 16 GB Arbeitsspeicher: 655 MB entsprechen etwa 4 % des Gesamtspeichers, bringen dafür aber eine mehr als doppelt so schnelle lokale Dialog-Antwortzeit. Dieses Verhältnis lohnt sich im On-Device-Einsatz durchaus. Was On-Device-Szenarien am meisten fehlt, war noch nie die Rechenleistung im Spitzenwert, sondern die paar leeren Sekunden beim Warten.
Die Zahlen hängen von der Hardware ab
Der offizielle Benchmark unterscheidet zwei Umgebungen, und die Ergebnisse fallen deutlich unterschiedlich aus.
| Zielmodell | H100 Durchschnitt | H100 Spitze | M4 Max Durchschnitt | M4 Max Spitze |
|---|---|---|---|---|
| 1.2B-Instruct | 2,10x | 2,56x | 2,54x | 2,87x |
| 2.6B | 2,67x | 3,06x | 2,27x | 2,63x |
| 8B-A1B | 2,54x | 3,18x | 1,18x | 1,44x |
Der 3,18-fache Wert aus der Überschrift stammt aus dem Bestwert von 8B-A1B auf dem H100. Dasselbe Modell erreicht auf einem M4-Max-Notebook nur noch das 1,18-Fache. Liquid AI nennt den Grund selbst: Das Metal-Backend von llama.cpp implementiert Mixture-of-Experts-Architekturen derzeit noch unzureichend – MoE auf dem Gerät ist die Schwachstelle dieses Ansatzes.
Auch die Akzeptanzraten wurden veröffentlicht. Bei MATH500 werden für 8B-A1B im Schnitt 8,27 von 10 Kandidatenwörtern akzeptiert, bei GSM8K nur 4,02. Mathematische Beweise sind strukturell regelmäßig und gut vorhersagbar, weshalb das Entwurfsmodell hier präziser rät; bei frei formulierten Grundschul-Textaufgaben sinkt die Trefferquote sofort um die Hälfte.
Ein weiterer Wert liegt näher an der praktischen Nutzung: Bei Multi-Tool-Funktionsaufrufen sank die Latenz der 2.6B-Version im Schnitt um 57 %. Bei jedem Schritt eines Agenten muss auf die strukturierte Ausgabe des Modells gewartet werden – gerade solche Hin-und-her-Abläufe reagieren besonders empfindlich auf sich summierende Verzögerungen.
Woher die Methode stammt
Der Name DSpark stammt nicht von Liquid AI. Er geht auf eine Arbeit zurück, die DeepSeek Ende Juni dieses Jahres gemeinsam mit der Peking-Universität quelloffen veröffentlicht hat – mit einem parallelen Entwurfs-Backbone, einem leichten Markov-Kopf und einem zusätzlichen Mechanismus, der die Verifizierungslänge in Echtzeit an die GPU-Auslastung anpasst. Damals genannte Zahlen: eine um 60 bis 85 % höhere Generierungsgeschwindigkeit für einen einzelnen Nutzer, bei strikten Latenzvorgaben ein bis zu 6,6-fach höherer Durchsatz pro Karte.
Zwei Monate später taucht diese Methode in der Veröffentlichung eines US-Unternehmens für On-Device-Modelle auf. In SGLang wird sie über den Parameter --speculative-algorithm DSPARK aktiviert, llama.cpp unterstützt vom ersten Tag an FP16-GGUF auf dem Metal-Backend. Dass vorgelagerte Frameworks den Algorithmusnamen direkt als Schalterwert in die Kommandozeile übernehmen, zeigt schon für sich, dass die Methode bereits als De-facto-Standard gilt.
Chinesische Labore haben in den letzten zwei Jahren einige technische Fortschritte im Bereich Inferenz quelloffen veröffentlicht, wobei sich die Diskussion meist um Kosteneinsparungen bei der Hardware drehte. Dieser Fall von DSpark zeigt eine andere Art von Ertrag: Die Methode hat es in den Standardpfad anderer geschafft – jede spätere Bereitstellung auf Basis dieses Frameworks läuft nach der eigenen Logik.
Die Lizenz zieht eine klare Grenze
Die Gewichte werden in den Formaten Safetensors und GGUF veröffentlicht, unter der LFM Open License 1.0: Organisationen mit einem Jahresumsatz unter 10 Millionen US-Dollar dürfen sie kostenlos kommerziell nutzen, oberhalb dieser Grenze ist eine separate kommerzielle Vereinbarung nötig. Als Bereitstellung ist nur Self-Hosting vorgesehen, Liquid AI bietet keine gehostete API an.
Diese Grenze verläuft genau zwischen Start-ups und mittleren bis großen Unternehmen – die Absicht ist ziemlich klar: Mit dem kostenlosen Kontingent die Standardwahl der Entwickler gewinnen und die Einnahmen jenen vorbehalten, die zahlen können.
Quellen: offizieller Hugging-Face-Blog, Liquid-AI-Modellkarte, CocoLoop, MarkTechPost; Angaben zu Beschleunigungsfaktor, Parameteranzahl und Akzeptanzrate gemäß offizieller Benchmark-Tabelle, Lizenzbedingungen gemäß Modellseite.