LFM2.5-VL-3B-DSpark vs. LFM2.5-VL-3B: Du wählst nicht eines aus, du hängst eines an

Die Suche, die die Leute hierher bringt, ist ein Vergleich, aber die ehrliche Antwort ist, dass LFM2.5-VL-3B-DSpark und LFM2.5-VL-3B nicht zwei Dinge sind, zwischen denen man wählt. Das zweite ist ein Vision-Language-Modell mit 3,1B, das man herunterladen und bereitstellen kann. Das erste ist ein Draft-Modell mit 279,5M Parametern, das nur existiert, um vor dem zweiten zu sitzen und dessen Dekodierung zu beschleunigen. Nimmt man den Drafter aus dem Stack, liefert er nichts; man kann ihn nicht allein benchmarken, weil „allein“ keine Konfiguration ist, die er unterstützt. Der eigentliche Vergleich ist LFM2.5-VL-3B im Alleinbetrieb gegenüber demselben Modell mit angehängtem Drafter.

Wenn man es so liest, reduziert sich die Entscheidung auf eine einzige Frage: Verschaffen Ihnen der zusätzliche Speicher und die zusätzliche Laufzeitkomplexität genug Latenz, um für Ihre Workload von Bedeutung zu sein? Die eigenen Zahlen von Liquid AI sagen Ja für decode-lastige Arbeit und ausdrücklich Nein, wenn Prefill dominiert. Weder die eine noch die andere Seite davon wurde außerhalb des Unternehmens reproduziert.

Die beiden Kontrollpunkte, Seite an Seite

Was zwischen ihnen den Unterschied ausmacht, ist die ganze Geschichte, daher lohnt es sich, die beiden Repositories nebeneinanderzustellen, bevor die Diskussion um die Geschwindigkeit beginnt.

• Rolle — LFM2.5-VL-3B generiert Text und beantwortet Fragen zu Bildern; LFM2.5-VL-3B-DSpark schlägt Tokens vor, die es überprüfen soll, und generiert selbst nichts Nutzbares

• Parameter — 3,1B für das Zielmodell, 279,5M BF16 für den Drafter, was Liquid als einen Anstieg der Anzahl der eingesetzten Parameter um 8,9 % angibt

• Architektur — das Ziel ist ein hybrides Modell, das auf einem LFM2.5-2.6B-Backbone mit einem SigLIP2-NaFlex-Vision-Encoder aufbaut; der Drafter besteht aus 4 Full-Attention-Schichten mit Hidden Size 2.048 und Grouped-Query-Attention plus einem Markov-Head und einem Confidence-Head

• Kontextfenster – 32.768 Token für das Zielmodell; das Entwurfsmodell bringt keinen eigenen Kontext mit und erbt den des Zielmodells.

• Vision-Encoder — SigLIP2 NaFlex 400M auf dem Target; der Drafter hat keinen und sieht das Bild nie direkt

• Vokabular — 128.000, und die Einbettung und der LM-Kopf des Drafters sind an das Zielmodell gebunden statt dupliziert, weshalb die Speicherbelastung geringer ist, als 279,5 Mio. Parameter vermuten lassen würden

Lizenz — beide erscheinen unter Liquids LFM1.0, die auf Hugging Face als „other“ statt als OSI-Lizenz eingestuft wird, lies also die Bedingungen, bevor du einen kommerziellen Einsatz in Erwägung ziehst.

• Formate — das Zielmodell wird als safetensors-, GGUF-, ONNX- und MLX-Quantisierungen ausgeliefert; der Drafter wird als safetensors und als einzelnes F16-GGUF von ungefähr 567 MB ausgeliefert

Eine Zeile in dieser Liste verdient besondere Hervorhebung, weil sie der mechanische Grund dafür ist, dass diese Paarung überhaupt funktioniert: Der Drafter ist kein kleines Vision-Modell. Er hat keinen Vision-Encoder und berührt das Bild nie. Zu dem Zeitpunkt, an dem die Token die verborgenen Schichten erreichen, aus denen er entwirft, sind ein Bild-Patch und ein Text-Token beide nur Tensoren, sodass die Modalität für die Berechnung des Drafters unsichtbar ist. Das ermöglichte es Liquid, eine für Textmodelle entwickelte Technik auf ein VLM zu übertragen, ohne sie neu zu konzipieren.

Was der Verfasser ändert und was er unangetastet lässt

Das Zielmodell ändert sich nicht. Das ist kein Marketing – es ist die Korrektheitseigenschaft des spekulativen Decodings. Beim Greedy-Decoding wird jedes Draft-Token vom Zielmodell verifiziert, sodass die Ausgabe genau das ist, was das Zielmodell allein erzeugt hätte. Unter übereinstimmenden Sampling-Einstellungen bei einer Temperatur ungleich null stimmt die Ausgabeverteilung mit der des Zielmodells überein. Der Drafter tauscht Speicher gegen Zeit und berührt nichts anderes.

Was bedeutet, dass jeder Qualitätswert, den Sie für LFM2.5-VL-3B finden können, unverändert für die gepaarte Konfiguration gilt. In Liquids eigener Evaluierung erreicht das Zielmodell 80,7 auf ScreenSpot-v2, 61,5 auf BLINK, 58,3 auf MuirBench, 73,1 auf MME, 63,3 auf MMStar, 81,3 auf ChartQA und 88,7 auf POPE – alle vom Anbieter angegeben, keine unabhängig reproduziert, und alle gleichermaßen gültig, ob der Drafter angehängt ist oder nicht. Es gibt hier keinen Trade-off zwischen Qualität und Geschwindigkeit abzuwägen, und jede Vergleichsseite, die einen solchen präsentiert, hat das Modell missverstanden.

Was sich jedoch ändert, sind die Kosten eines Tokens in Wall-Clock-Zeit. Liquid misst Decode-Beschleunigungen von 2,04× bis 2,66× auf einer einzelnen H100 in BF16 über SGLang bei Blockgröße 9, 2,30× bis 3,13× auf einem Apple M5 Max über MLX-VLM bei Blockgröße 8 und 1,57× bis 2,14× auf einem M3 Ultra über llama.cpp. Ende-zu-Ende liegen dieselben Durchläufe bei 1,64×–2,27×, 1,56×–2,62× bzw. 1,30×–1,77×. Diese Paare sind das ganze Argument: Decode verbessert sich ungefähr doppelt so stark wie Ende-zu-Ende, und die Lücke ist der Teil der Arbeitslast, den der Drafter nicht berühren kann.

Das Prefill-Problem, wie vom Anbieter dargelegt

Der nützlichste Satz in Liquids eigener Ankündigung ist derjenige, der gegen eine uneingeschränkte Auslegung seiner Schlagzeile argumentiert. Vision-Language-Inferenz zahlt einen Prefill-Kostenaufwand, den Textinferenz nicht hat: Das Bild durchläuft einen Vision-Encoder, und das Sprach-Backbone verarbeitet anschließend die Hunderte visueller Tokens, die dieser Encoder ausgibt. Auf einem Edge-Gerät macht dieser Prefill einen großen Anteil der End-to-End-Latenz aus. Speculative Decoding beschleunigt nur das Decoding – Vision-Encoding und Prefill bleiben unverändert. Wo Prefill dominiert, verwandelt sich eine 3×-Decode-Beschleunigung in einen viel kleineren End-to-End-Gewinn.

Das ist Amdahls Gesetz, angewandt vom Anbieter auf das eigene Produkt, und es sollte beeinflussen, wer diese Seite liest. Eine lange Transkription einer einzelnen eingescannten Seite, eine Bildunterschrift, eine Multi-Turn-Konversation, die ein Bild weiterträgt – decode-lastig, und der Drafter rechtfertigt seine 279,5 Mio. Parameter. Eine kurze Frage zu einem großen hochauflösenden Bild – prefill-lastig, und er tut es nicht. Setzt man dasselbe Ziel auf einen Server bei hoher Nebenläufigkeit, verschiebt sich das Bild erneut: Liquid misst eine Durchsatz-Interaktivitäts-Grenze statt einer einzelnen Zahl und berichtet, dass DSpark seinen Vorteil auf jedem Nebenläufigkeitsniveau behält, während die Lücke mit steigender Nebenläufigkeit kleiner wird.

Zwei kleinere Hinweise zum Geltungsbereich aus derselben Quelle. Alle Messungen verwenden 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 Veröffentlichung. Wenn Ihr Plan war, einen 4-Bit-Ziel-Export mit dem Drafter zu kombinieren, weil der ganze Reiz eines 3B-VLM darin besteht, in wenige Gigabyte zu passen, dann ist diese Kombination nicht das, was gemessen wurde.

Was Sie das Anhängen tatsächlich kostet

Der Speicher ist der sichtbare Kostenfaktor, und die Modellkarte beziffert ihn: 8,9 % mehr Parameter im bereitgestellten Stack. Die Laufzeitkomplexität ist der unsichtbare Kostenfaktor. SGLang benötigt v0.5.19 oder neuer und eine Startzeile, die --speculative-algorithm DSPARK, den Pfad zum Draft-Modell und eine Blockgröße enthält; das Beispiel auf der Modellkarte deaktiviert außerdem den Radix-Cache und legt einen statischen Speicheranteil fest, was Serving-Entscheidungen sind, über die Sie jetzt nachdenken müssen. MLX-VLM benötigt v0.7.2 oder neuer und nimmt den Drafter über --draft-model entgegen, doch die DSpark-Dekodierung verwendet dort derzeit Greedy-Sampling, sodass die Temperatur auf 0 gezwungen werden muss – eine echte Einschränkung, wenn Ihre Anwendung auf Sampling-Vielfalt angewiesen ist. llama.cpp funktioniert über den GGUF-Drafter in Kombination mit dem GGUF-Target, nicht mit dem ursprünglichen safetensors-Checkpoint.

Es gibt noch einen Kostenpunkt, der eher in der Produktion als in einem Benchmark auftaucht: Drafter und Target müssen gemeinsam unterwegs sein. Versions-Skew zwischen ihnen ist ein Fehlerbild, das es in einem Single-Model-Deployment nicht gibt, und eine der beiden unabhängig auszurollen ist jetzt ein Zwei-Artefakt-Problem.

Dies ist eine selbst gehostete Kombination. OrcaRouter routet LFM2.5-VL-3B oder dessen Drafter nicht — Sie laden beide herunter und betreiben sie selbst — die Routing-Frage betrifft also alles, woran das kleine Modell übergibt. In den meisten Deployments, die ein 3B-Edge-VLM mit dem Drafter kombinieren, gibt es weiterhin Anfragen, die das kleine Modell nicht beantworten sollte, und diese an einen einzigen Endpunkt zu senden, der über 200+ Modelle zum Listenpreis des jeweiligen Anbieters abdeckt, mit automatischem Failover, falls ein Anbieter schlechter wird, ist eine einzige Integration statt einer pro Anbieter. Außerdem bedeutet es: Sobald ein Anbieter einen Preis senkt, spiegelt sich das noch am selben Tag in Ihrem Tarif wider statt erst bei der nächsten Vertragsverlängerung.

Welche soll ich herunterladen?

Wenn Ihre Arbeitslast dekodierlastig ist und Ihre Hardware zu den drei von Liquid getesteten gehört, hängen Sie den Drafter an – der Nachteil ist begrenzt, denn die Ausgabe stammt nachweislich vom Target, und der Speicherbedarf liegt unter einem Zehntel eines Modells. Wenn Ihre Latenz vom Prefill dominiert wird, Sie ein quantisiertes Target ausführen oder auf nicht-gieriges Sampling in einer Runtime angewiesen sind, die diese Einschränkung nicht aufgehoben hat, führen Sie LFM2.5-VL-3B allein aus. Es ist aus eigener Kraft schnell: 228 Token pro Sekunde auf einem M5 Max, 116 auf einem AMD Ryzen AI Max+ 395 und 20 auf einem Galaxy S26 Ultra, alles Herstellerangaben, bei rund 3 GB Speicher.

Was Ihnen noch niemand sagen kann, ist, ob Liquids Zahlen auf Ihrer Hardware zutreffen. Der Drafter hatte zum Zeitpunkt des Verfassens 37 Downloads auf Hugging Face und keine unabhängige Reproduktion irgendeiner Zahl in seinen Tabellen. Die technische Umsetzung ist solide, und das Korrektheitsargument ist ein Beweis und keine Behauptung, aber die Größenordnung ist eine Messung – und Messungen aus einem einzigen Labor auf einem einzigen Maschinenpark sind genau die Art von Zahl, die Sie selbst überprüfen sollten, bevor Sie sie in einen Kapazitätsplan aufnehmen.

OrcaRouter erreicht über einen einzigen Schlüssel 200+ Modelle, wobei der Listenpreis jedes Anbieters direkt mit 0 % Aufschlag weitergegeben wird und ein automatisches Failover zwischen Anbietern erfolgt. Listenpreis des Anbieters mit 0 % Aufschlag weitergegeben Die Paarung auf dieser Seite ist in beiden Fällen selbst gehostet – der Router ist für alles zuständig, was das kleine Modell weitergibt, und das bedeutet, dass eine Preissenkung eines Anbieters noch am selben Tag in Ihrem Tarif sichtbar wird.