LFM2.5-VL-3B-DSpark: Liquid AIs 279.5M-Drafter erschien sechs Tage, bevor es überhaupt jemand ankündigte

Es gibt eine Version dieser Geschichte, in der LFM2.5-VL-3B-DSpark ein neues Modell ist. Ist es nicht. Es ist ein Draft-Modell für spekulatives Decoding mit 279,5 Mio. Parametern, das genau einem Zweck dient – Liquid AIs eigenes Vision-Language-Modell LFM2.5-VL-3B schneller zu dekodieren – und es kann eigenständig keine brauchbare Antwort generieren. Der Grund, warum es sich trotzdem lohnt, darüber zu lesen, ist die Zeitachse: Die Gewichte landeten am 18. September 2026 auf Hugging Face, ohne Ankündigung, blieben sechs Tage dort und bekamen erst am 24. September einen Blogbeitrag des Anbieters. Radar entdeckte das Repo in der Lücke.

Diese Lücke ist zugleich die Grenze dessen, was sich im Moment wissen lässt. Alles im Repository – die Parameteraufschlüsselung, die Blockgröße, die Framework-Integrationen, die Lizenz – ist eine Datei auf der Festplatte, die du oder ich öffnen können. Jede Beschleunigungszahl ist vom Anbieter gemessen, aus dem eigenen Benchmark-Harness von Liquid, und niemand außerhalb des Unternehmens hat eine Reproduktion veröffentlicht. Dieser Beitrag hält diese beiden Stapel bewusst getrennt.

Was das Repository tatsächlich enthält

Öffnet man die Modellkarte, ist die Beschaffenheit der Sache eindeutig. LFM2.5-VL-3B-DSpark ist ein Draft-Modell, dessen Ziel in seinen Metadaten festgelegt ist: base_model: LiquidAI/LFM2.5-VL-3B. Man richtet es nicht auf ein anderes Modell aus, und man stellt es nicht allein bereit.

• Gesamtzahl der Draft-Parameter — 279,5M, BF16, davon 193,0M für den 4-Schichten-Decoder-Stack, 65,5M für einen Markov-Kopf, 21,0M für eine Hidden-State-Projektion und 6,4k für Normen plus einen Confidence-Kopf

• Backbone — 4 vollständige Attention-Layer, Hidden Size 2.048, Intermediate Size 6.144 mit SiLU/SwiGLU, Grouped-Query-Attention mit 32 Attention-Heads und 8 Key-Value-Heads, Head-Dimension 64

• Zusätzliche Heads — ein Markov-Head mit Rang 256 und ein Confidence-Head, was DSpark-Drafting von einem einfachen parallelen Drafter unterscheidet

• Blockgröße — 9 während des Trainings; 8 oder 9 bei der Inferenz je nach Hardware und auf Apple Silicon speziell 8

• Vokabular — 128.000, an das Ziel gebunden statt vom Entwurf getragen

• Gewicht im eingesetzten Stack — Laut Liquid erhöht der Drafter die Anzahl der eingesetzten Parameter um 8,9 %

Die 8,9 % sind die Zahl, die man sich merken sollte. Das Verkaufsargument für diese Modellklasse ist nie „schnellere Inferenz ist kostenlos“; es lautet „schnellere Inferenz kostet etwa ein Zehntel des Speicherbedarfs eines Modells“. Bei 279,5 Mio. zusätzlichen Parametern obendrauf auf ein 3,1-Mrd.-Zielmodell ist das eine geringere Zusatzlast, als die Größe des Drafters allein vermuten ließe, weil Embedding und LM-Head an das Zielmodell gebunden sind und nicht dupliziert werden.

DSpark ist eine DeepSeek-Technik, bevor es ein Liquid-Modell ist

Die Namensgebung lädt zu Verwechslungen ein, deshalb lohnt es sich, präzise zu sein. DSpark ist keine Erfindung von Liquid AI und keine Modellfamilie. Es ist ein Framework für spekulatives Dekodieren aus einer separaten Forschungslinie, das in einem Artikel vom Juli 2026 als konfidenzgesteuertes spekulatives Dekodieren mit semi-autoregressiver Generierung beschrieben wird. Seine drei Ideen: ein paralleles Backbone, das einen ganzen Block in einem einzigen Vorwärtsdurchlauf entwirft, ein leichtgewichtiges sequenzielles Modul, das eine gewisse Abhängigkeit zwischen benachbarten Entwurfs-Tokens wiederherstellt, damit die Akzeptanz am Ende des Blocks nicht zusammenbricht, und ein Verifizierer, der das Verifikationsfenster pro Anfrage verkürzt, wenn die eigene Konfidenz des Entwurfs darauf hindeutet, dass der hintere Teil abgelehnt wird.

Was Liquid getan hat, ist, dieses Rezept auf Vision-Language-Modelle anzuwenden und einen Checkpoint auszuliefern. Die Modellkarte ist offen damit, dass dieser Transfer weniger dramatisch ist, als er klingt: Aus Sicht des Drafters ist Modalität irrelevant, denn wenn Tokens die verborgenen Schichten erreichen, sind ein Bild-Patch und ein Text-Token beide nur Tensoren. Deshalb lässt sich eine auf Textmodellen entwickelte Technik auf ein VLM übertragen, ohne neu erfunden zu werden — und deshalb kann der Drafter auch nicht als neue Fähigkeit verkauft werden.

Liquid hatte bereits Text-DSpark-Draft-Modelle veröffentlicht – die Begleitmodelle 2.6B, 8B-A1B und 1.2B-Instruct erschienen im August 2026, GGUF-Exporte folgten am 19. August. Der Vision-Drafter ist dieselbe Idee, erweitert auf den multimodalen Zweig, und der vierte oder fünfte Eintrag einer Reihe, kein Debüt.

Die Speedup-Werte und wer sie gemessen hat

Jeder Wert unten stammt von Liquid selbst, erhoben auf Liquids eigener Benchmarking-Infrastruktur, und keiner davon wurde unabhängig reproduziert. Betrachten Sie sie als Hersteller-Obergrenze, nicht als zu erwartendes Ergebnis. Die Karte trennt Decode-Beschleunigung von End-to-End-Beschleunigung, was mehr zählt als die Schlagzeile.

• Beste Dekodierungsbeschleunigung — 3,13× auf COCO, gemessen mit MLX-VLM auf einem Apple M5 Max bei Blockgröße 8, FP16, Batch-Größe 1, Temperatur 0

• Beste GPU-Decode-Beschleunigung — 2,66× auf COCO, SGLang auf einer einzelnen H100 80GB, BF16, Blockgröße 9

Beste llama.cpp-Decode-Beschleunigung — 2,14× auf COCO, Apple M3 Ultra, Blockgröße 8

• H100-Decode-Bereich über sechs Vision-Aufgaben hinweg — 2,04× bis 2,66×, mit Ende-zu-Ende bei 1,64× bis 2,27×

• M5-Dekodierbereich — 2,30× bis 3,13×, Ende-zu-Ende 1,56× bis 2,62×

• M3 Ultra Dekodierbereich — 1,57× bis 2,14×, End-to-End 1,30× bis 1,77×

• Draft-Akzeptanz – ungefähr 3,2 bis 4,5 akzeptierte Tokens pro Zielverifizierungsdurchlauf, auf allen drei Stacks

Das Muster in diesen Spannen ist der ehrliche Teil. Ende-zu-Ende-Gewinne sind durchweg die kleinere Hälfte jedes Paares, weil der Drafter die Dekodierung beschleunigt und sonst nichts. Zu beachten ist außerdem, dass derselbe Drafter bei derselben Blockgröße auf einem Stack 3,13× und auf einem anderen 1,57× erreicht – die Annahmerate ist eine Eigenschaft von Drafter und Workload, aber der Wall-Clock-Gewinn ist eine Eigenschaft der Hardware und des Overheads der Laufzeitumgebung. Eine Behauptung „2,66× schneller“ ohne zugehörigen Stack ist keine Behauptung, auf deren Grundlage man handeln kann.

Zwei Korrektheitspunkte aus der Karte sind es wert, klar benannt zu werden, denn sie sind es, die einen Drafter in der Produktion überhaupt erst akzeptabel machen. Beim Greedy-Decoding ist spekulatives Decoding exakt: Das Zielmodell verifiziert jedes vorgeschlagene Token, sodass der Text genau der ist, den das Zielmodell allein erzeugt hätte. Unter übereinstimmenden Sampling-Einstellungen bei einer Temperatur ungleich null bleibt die Ausgabeverteilung des Zielmodells erhalten. Liquids Formulierung – man bekommt die Beschleunigung, nicht ein anderes Modell – ist korrekt, soweit sie reicht, und die Karte gibt ehrlich zu, dass eine höhere Temperatur die Akzeptanz senkt und dadurch den Durchsatzvorteil schmälert.

Was Liquids eigener Beitrag zugibt

Der Blogbeitrag vom 24. September ist aus einem Grund nützlicher als die Modellkarte: Er benennt die Grenze. Vision-Sprach-Inferenz zahlt einen Prefill-Aufwand, den Text-Inferenz nicht hat – das Bild muss einen Vision-Encoder durchlaufen, und das Sprach-Backbone muss anschließend die Hunderte visueller Tokens verarbeiten, die dieser Encoder erzeugt. Auf einem Gerät dominiert dieser Prefill die End-to-End-Latenz. Spekulatives Decoding beschleunigt ausschließlich die Dekodierung. Vision-Encoding und Prefill bleiben unberührt. Liquid führt Amdahls Gesetz gegen das eigene Produkt an und weist darauf hin, dass dort, wo Prefill einen großen Anteil der Wall-Time ausmacht, eine starke Decode-Beschleunigung nur eine bescheidene End-to-End-Verbesserung bringt.

Das ist eine echte Einschränkung für die Kaufentscheidung, und es erklärt, warum Time-to-First-Token nicht auf der Liste der Dinge steht, die dieser Drafter verbessert. Es impliziert außerdem, dass die Workloads, die am meisten profitieren, jene sind, die lange Ausgaben aus einem bescheidenen Bild erzeugen – eine Bildunterschrift, eine lange OCR-Transkription, eine mehrrundige Konversation mit einem weitergeführten Bild – und nicht jene, die eine kurze Frage zu einem großen Bild beantworten.

Der Beitrag ergänzt zwei weitere Einschränkungen des Geltungsbereichs. Alle Zahlen beruhen auf 16-Bit-Verarbeitung sowohl für den Vision-Encoder als auch für das Sprach-Backbone, und die Beschleunigung quantisierter Modelle liegt außerhalb des Umfangs dieser Version. Angesichts dessen, dass das ganze Verkaufsargument eines 3B-Edge-VLM darin besteht, in ein paar Gigabyte zu laufen, ist „die Geschwindigkeitssteigerungen werden bei FP16 gemessen“ ein wichtiger Vorbehalt für alle, die planten, es mit einem 4-Bit-Export zu kombinieren. Liquid merkt außerdem an, dass der Drafter vollständig auf AMD-Hardware trainiert wurde.

Es ausführen.

Support ab Tag eins ist real und deckt drei Runtimes ab – mehr, als die meisten Drafter bekommen. SGLang auf NVIDIA erfordert v0.5.19 oder neuer und führt den Drafter über --speculative-algorithm DSPARK mit dem Draft-Pfad und einer Blockgröße von 9. MLX-VLM auf Apple Silicon erfordert v0.7.2 oder neuer und erkennt den Drafter, wenn er mit --draft-model übergeben wird; es gibt einen Haken – DSpark-Decoding in MLX-VLM nutzt derzeit Greedy-Sampling, weshalb die Temperatur auf 0 gesetzt werden muss. Für llama.cpp gibt es ein separates GGUF-Repository mit einem einzigen F16-Export von ungefähr 567 MB, und auf der Karte steht ausdrücklich, dass man den quantisierten Drafter mit dem quantisierten Target und nicht mit dem ursprünglichen safetensors-Checkpoint kombinieren soll.

Wo eine Routing-Schicht hier ihren Platz verdient, ist nicht bei diesem Modell — OrcaRouter routet weder LFM2.5-VL-3B-DSpark noch LFM2.5-VL-3B, und dies ist ein selbst gehostetes Drafter-Paar, das man selbst herunterlädt und betreibt. Sie liegt im restlichen Stack drumherum. Dieselbe Anwendung, die ein kleines Open-Weight-Vision-Modell auf dem Gerät ausführt, hat üblicherweise einen Fallback-Pfad für die Anfragen, die das kleine Modell nicht bewältigen kann, und diesen Pfad auf einen einzigen Endpunkt zu richten, der 200+ Modelle abdeckt — abgerechnet zum Listenpreis des jeweiligen Anbieters ohne Aufschlag, mit automatischem Failover, wenn ein Anbieter schwächelt — ist eine kleinere Integration, als einen zweiten Anbietervertrag aufzusetzen. Der Drafter verbessert ein Bein dieser Architektur; der Router ist das, was das andere Bein davon abhält, ein zweites Projekt zu werden.

Was noch nicht bekannt ist

Das Repository hat zum Zeitpunkt des Verfassens 37 Downloads und 6 Likes. Es gibt keinen Eintrag für diesen Drafter bei irgendeinem öffentlichen Benchmark-Aggregator, keine Reproduktion eines der Speedup-Bereiche durch Dritte und keine unabhängige Messung der Akzeptanzrate auf Hardware, die Liquid nicht getestet hat. Aus offensichtlichen Gründen gibt es auf der Karte außerdem keine Qualitäts-Benchmarks — der Drafter ist konstruktionsbedingt ausgabenerhaltend, die Qualitätswerte gehören also zu LFM2.5-VL-3B, und die Karte verweist auf die Benchmarks dieses Modells, statt eigene zu erfinden.

Ein kleines Detail in den Metadaten verrät, wie neu das ist: Das Modell trägt ein SGLang-Bibliotheks-Tag und ein SGLang-Algorithmus-Flag, das eigens dafür existiert, es aufzurufen. Die Framework-Unterstützung musste vor der Ankündigung landen, was mit dem Abstand von sechs Tagen zwischen dem Repository und dem Blogbeitrag übereinstimmt.

Also: ein echtes, nützliches, eng gefasstes Stück Engineering, eine Woche nach seiner Auslieferung angekündigt, dessen gesamtes Nutzenversprechen eine vom Anbieter gemessene Zahl auf Hardware ist, die Sie möglicherweise nicht besitzen. Wenn Sie LFM2.5-VL-3B auf einer H100 oder einem M-Series-Mac betreiben und Ihre Workload decode-lastig ist, liegen die Speicherkosten bei 8,9 %, und der Nachteil ist nahezu null, weil die Ausgabe nachweislich der Zielausgabe entspricht. Wenn Ihre Latenz vom Prefill dominiert wird oder Sie auf den 4-Bit-Export gesetzt haben, sagt Ihnen Liquids eigener Beitrag, dass er nicht helfen wird. Die Reproduktion, wenn sie kommt, ist das, worauf man warten sollte.

OrcaRouter stellt 200+ Modelle hinter einem Schlüssel zum Listenpreis des Anbieters mit 0 % Aufschlag bereit und drückt den Fallback-Pfad als eine Routing-Schicht statt Anwendungscode aus. Der Drafter wird so oder so selbst gehostet – der Router ist das, was den Teil, den dein kleines Modell weitergibt, davon abhält, ein zweites Projekt zu werden.