Liquid AI hat LFM2.5-DSpark vorgestellt, Entwurfsmodelle für spekulatives Decoding der LFM2.5-Reihe. Laut einem von Liquid AI auf Hugging Face veröffentlichten Beitrag stehen die Checkpoints in den Formaten Safetensors und GGUF bereit und unterstützen zum Start llama.cpp sowie SGLang.
Kleine Entwurfsmodelle für zwei Laufzeitumgebungen
Die einzelnen DSpark-Entwurfsmodelle umfassen laut Liquid AI jeweils rund 300 Millionen Parameter. Das Unternehmen nennt Unterstützung für llama.cpp und SGLang. Die llama.cpp-Implementierung baue auf dem offiziellen Code auf und sei mit experimentellen Metal-Kernels ausgeführt worden; die SGLang-Implementierung baue auf dessen offizieller DSpark-Implementierung auf.
Für Anwender ist die Verfügbarkeit in Safetensors und GGUF relevant, weil Liquid AI damit sowohl die im Beitrag genannte GPU-Umgebung mit SGLang als auch die lokale Ausführung mit llama.cpp adressiert. Welche weiteren Laufzeitumgebungen, Hardware-Plattformen oder Quantisierungsvarianten unterstützt werden, geht aus dem vorliegenden Material nicht hervor.
Gemeldete Werte hängen an konkreten Testaufbauten
Liquid AI berichtet GPU-Durchsatzmessungen mit SGLang auf einer einzelnen H100 mit 80 GB Speicher in BF16. Für die lokale Messung nutzte das Unternehmen nach eigenen Angaben llama.cpp und Metal auf einem MacBook Pro mit M4 Max, FP16-GGUF-Gewichten und bis zu 256 erzeugten Tokens.
Für LFM2.5-2.6B gibt Liquid AI über verschiedene Multi-Tool-Szenarien hinweg eine durchschnittliche Latenzsenkung von 57 Prozent an. Für LFM2.5-8B-A1B nennt das Unternehmen auf dem Gerät im Mittel nur eine Verbesserung von 18 Prozent, obwohl die Akzeptanzrate gegenüber zwei dichten Modellen gestiegen sei.
Diese Angaben sind Herstellerbenchmarks aus einer einzigen Primärquelle. Sie lassen sich daher nicht ohne Weiteres auf andere Modelle, Prompts, Ausgabelängen, Hardware oder Konfigurationen übertragen. Unabhängige Messungen oder vollständige Vergleichsdaten enthält das Dossier nicht.
Ausgabe soll bei greedy Decoding unverändert bleiben
Laut dem Beitrag ist das erzeugte Ergebnis bei greedy Decoding konstruktionsbedingt identisch mit dem der Baseline. Liquid AI leitet daraus ab, dass Benchmark-Genauigkeit wie pass@1 oder Exact Match unverändert bleibt.
Das ist ein wesentlicher Anspruch für Inferenzoptimierung: Beschleunigung wäre dann nicht mit einer abweichenden Ausgabe im genannten Decoding-Modus erkauft. Die Aussage bezieht sich jedoch ausdrücklich auf greedy Decoding; das bereitgestellte Material beschreibt keine Ergebnisse für andere Decoding-Verfahren.
Einordnung
Die Ankündigung erweitert das LFM2.5-Umfeld um separate Entwurfsmodelle und liefert Implementierungen für eine GPU- und eine On-Device-Konfiguration. Besonders deutlich ist zugleich, dass der ausgewiesene Nutzen modell- und umgebungsabhängig ist: Die von Liquid AI genannten Durchschnittswerte reichen von 18 Prozent On-Device für LFM2.5-8B-A1B bis zu 57 Prozent geringerer Latenz für LFM2.5-2.6B in Multi-Tool-Szenarien.
Ob die Werte unter unabhängigen Tests reproduzierbar sind und wie sich Speicherbedarf, Akzeptanzraten, Energieverbrauch oder Verhalten bei produktiven Lastprofilen entwickeln, bleibt offen.
Wie es weitergeht
Entwickler können die veröffentlichten Checkpoints in den genannten Laufzeitumgebungen gegen ihre eigenen Modelle, Hardware und Workloads testen. Aussagekräftig werden vor allem unabhängige Vergleichsmessungen unter dokumentierten, vergleichbaren Konfigurationen sein.
Änderungsvermerk: Erstmeldung auf Grundlage eines einzelnen, primären Blogbeitrags von Liquid AI auf Hugging Face.