Liquid AI veröffentlicht LFM2.5-VL-DSpark: 3B-Visionsmodell mit Draft-Modell, Decoding bis zu 3,13-fach schneller
Laut einem Blogbeitrag von Liquid AI aus September 2026 hat Liquid AI für das Vision-Sprachmodell mit offenen Gewichten LFM2.5-VL-3B ein experimentelles DSpark-Draft-Modell vorgestellt, das rund 280 Millionen Parameter hinzufügt (8,9 % mehr relativ zum 3B-Zielmodell), eine Decoding-Beschleunigung von bis zu 3,13-fach auf Geräten und bis zu 2,66-fach auf H100 beansprucht und ab dem ersten Tag llama.cpp, MLX-VLM und SGLang unterstützt.
Was sich geändert hat
Liquid AI hat im September 2026 ein experimentelles DSpark-Draft-Modell veröffentlicht, begleitend zu seinem Vision-Sprachmodell LFM2.5-VL-3B. Dem Herstellerblog zufolge folgt das Draft-Modell dem Architekturansatz des Textmodells LFM2.5-DSpark: In festen Anschluss-Schichten werden Hidden States des Zielmodells erfasst und daraus eine Gruppe von Kandidaten-Tokens entworfen; Bild-Patches und Text-Tokens werden vor Eintritt in diese Schichten in einen gemeinsamen Repräsentationsraum projiziert, sodass das Draft-Modell Hidden States einheitlicher Dimension verarbeitet und der Inferenzalgorithmus mit dem des Textmodells übereinstimmt. Das Draft-Modell nutzt eine 4-schichtige, rein attention-basierte Struktur, Blockgröße 9, etwa 279,5 Millionen Parameter, aufgeteilt in 193 Millionen für den Decoder-Stack, 21 Millionen für die Hidden-State-Projektion, 65,5 Millionen für den Markov-Head sowie 6400 für Norms und Confidence-Head. Der Hersteller gibt an, auf einem M5 Max mit MLX je nach Aufgabe eine Decoding-Beschleunigung von 2,30 bis 3,13-fach und End-to-End 1,56 bis 2,62-fach zu erzielen; auf einem M3 Ultra mit llama.cpp 1,57 bis 2,14-fach beim Decoding; die Decoding- und End-to-End-Werte für H100 weisen im Originaltext offenbar eine Satz-/Layout-Anomalie auf. Der Hersteller betont, spekulatives Decoding sei exakt, das Zielmodell verifiziere jedes vorgeschlagene Token, die gierige Ausgabe sei identisch mit der alleinigen Nutzung des Zielmodells, und das Draft-Modell sei in den Formaten Safetensors und GGUF auf Hugging Face verfügbar.
Auswirkungen für Entwickler
Für Entwickler, die multimodale Modelle lokal oder am Edge einsetzen, liegt die Bedeutung dieser Veröffentlichung nicht in den absoluten Geschwindigkeitszahlen, sondern im Verhältnis der Parameterzahl von Draft-Modell zu Zielmodell – etwa 8,9 % – was bedeutet, dass der zusätzliche VRAM- und Speicherbedarf überschaubar bleibt. Allerdings sind die meisten Beschleunigungswerte Decoding-Metriken; der End-to-End-Gewinn hängt vom Anteil visueller Kodierung und Prefill in der jeweiligen Workload ab, worauf der Hersteller selbst mit dem Amdahlschen Gesetz verweist. Daraus ergibt sich eine Gabelung: Szenarien mit langen Ausgaben, mehrstufigen Dialogen oder Bildbeschreibungen können den vom Hersteller angegebenen End-to-End-Werten nahekommen; Szenarien mit einmaliger langer Bild-Frage-Antwort, bei denen zunächst viele visuelle Tokens verarbeitet werden und die schnell enden, profitieren deutlich weniger. Zudem setzt der Betrieb des Draft-Modells llama.cpp-, MLX-VLM- und SGLang-Branches voraus, die noch nicht in den Hauptzweig eingegangen sind oder spezielle Builds erfordern; der Integrationsaufwand ist nicht zu vernachlässigen. Zu beachten ist: Zum Zeitpunkt dieser Überprüfung enthält der aktuelle Modellkatalog von KimiSeek keine Einträge für LFM2.5-VL-3B oder LFM2.5-VL-DSpark; die genannten API- und Gewichtsverfügbarkeiten stammen aus Herstellerangaben.
Integration und Bewertung
Empfehlung eins: Messen Sie zunächst den Decoding-Anteil an der Gesamtlatenz Ihrer Workload, bevor Sie ein Draft-Modell einführen. Die Quelle erwähnt, dass spekulatives Decoding nur das Decoding beschleunigt, nicht die visuelle Kodierung und das Prefill, und dass auf Edge-Geräten der Prefill-Anteil an der End-to-End-Latenz höher liegt. Voraussetzung ist, dass Sie bereits getrennte Daten zur First-Token-Latenz und zur Decoding-Dauer erheben können; empfohlen wird, mit derselben Gruppe von sechs visuellen Aufgaben (allgemeines VQA, Text-VQA, Bildbeschreibung, Diagramm-VQA, komplexes Schlussfolgern, mehrstufiger Dialog) je eine Baseline- und eine Draft-Modell-Konfiguration laufen zu lassen und als Bewertungsmetrik Perzentile der End-to-End-Latenz statt nur den Decoding-Durchsatz zu verwenden. Wenn Ihre Workload überwiegend aus kurzen Bildern mit langen Textausgaben besteht, kann sich das Draft-Modell lohnen; bei überwiegend einmaliger langer Bild-Frage-Antwort ist die Obergrenze des Nutzens durch das Prefill begrenzt. Empfehlung zwei: Wählen Sie zwischen llama.cpp und SGLang nach der Deployment-Form, nicht nach der beworbenen Spitzenbeschleunigung. Die Quelle nennt unterschiedliche Startweisen: SGLang bindet das Draft-Modell über Parameter wie --speculative-dspark-block-size ein und verlangt ausdrücklich das Abschalten des Radix-Cache; auf Seiten von llama.cpp braucht es --spec-type draft-dspark zusammen mit --spec-draft-n-max 8. Voraussetzung ist, dass Ihr Build den entsprechenden PR enthält, sonst stehen diese Parameter nicht zur Verfügung. Bei der Bewertung empfiehlt es sich, pro Antwort draft_n und draft_n_accepted zu protokollieren und anhand der Akzeptanzrate zu entscheiden, ob Blockgröße 8 oder 9 besser passt; bei niedriger Akzeptanzrate sollte geprüft werden, ob die Aufgabenverteilung von der Trainingsdatenmischung abweicht. Dies sind empfohlene Vorgehensweisen, keine Zusagen des Herstellers.
Grenzen und offene Fragen
Erstens: Zum Zeitpunkt dieser Überprüfung enthält der aktuelle Modellkatalog von KimiSeek keinen exakten Eintrag für LFM2.5-VL-3B oder LFM2.5-VL-DSpark; diese Version ist derzeit also nicht auf KimiSeek gelistet. Die in der Quelle genannten Gewichts-Downloads, Formate und Integrationswege sind Herstellerangaben und belegen keine Verfügbarkeit auf dieser Seite. Zweitens: Im Herstellertext ist an einer Stelle für H100 ein Decoding-Beschleunigungsbereich als „20,4-fach bis 2,66-fach“ angegeben, was offensichtlich eine Layout- oder Übertragungsanomalie darstellt und nicht als verlässliche Obergrenze zitiert werden sollte. Drittens: Der Hersteller bezeichnet das Draft-Modell selbst als experimentell; seine 4-schichtige Struktur und Blockgröße 9 stammen aus Ablationen mit 3, 4 und 5 Schichten, und die Trainingsdatenmischung wurde nach erwarteter Workload gewichtet, weshalb Akzeptanzrate und Beschleunigungsfaktor je nach tatsächlicher Aufgabenverteilung schwanken. Viertens: Die Beschleunigungszahlen stammen aus Herstellerselbsttests auf M5 Max, M3 Ultra und H100 und wurden anhand der sechs Aufgabentypen des MMSpec-Benchmarks bewertet; die Leistung auf anderer Hardware, mit anderen Quantisierungsformaten, Kontextlängen und Batch-Einstellungen wurde nicht unabhängig verifiziert. Fünftens: Die Quelle beschreibt das Modell als offene Gewichte, die frei herunterladbar, feinabstimmbar und einsetzbar seien, doch der Blog nennt keine konkreten Lizenzbedingungen; die Verfügbarkeit von Gewichten ist nicht gleichbedeutend mit einer Open-Source-Lizenz, und Rechte für kommerzielle Nutzung und Weitergabe richten sich nach der tatsächlichen Lizenz auf der Hugging-Face-Modellseite.
Abbildungen aus dem Originalbericht
